<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>繁星物语</title><link>https://sql668.github.io/blog/</link><description>Recent content on 繁星物语</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Fri, 18 Sep 2026 12:45:00 +0800</lastBuildDate><atom:link href="https://sql668.github.io/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>GLM 自建推理栈：把「3× 吞吐、10 万国产卡、两周上线」拆开核一遍</title><link>https://sql668.github.io/blog/posts/glm-inference-stack-audit/</link><pubDate>Fri, 18 Sep 2026 12:45:00 +0800</pubDate><guid>https://sql668.github.io/blog/posts/glm-inference-stack-audit/</guid><description>&lt;p&gt;智谱 2026-09-17 在 z.ai 官方博客发了《Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure》，讲 GLM-5.3-Flash 怎么在十万张国产加速器上自建推理栈。中文圈当天就转开了，但对不齐的不是媒体、是口径：官方中文博客稿写「端到端服务性能约 3 倍」「部分场景的性能差距超过 20%」，唐杰 X 写「3.2× 端到端吞吐」「over 30% to under 1%」。两家转载又都同时用了两套数——量子位导语跟唐杰用 3.2×、正文转官方中文博客稿用 3×；爱范儿同一篇里 3.2× 与约 3 倍并存。同一件事，两套数。&lt;/p&gt;</description></item><item><title>用 4B 模型学 Postgres 查询计划：把「81% faster」拆开核一遍</title><link>https://sql668.github.io/blog/posts/4b-postgres-query-plan-audit/</link><pubDate>Thu, 17 Sep 2026 16:30:00 +0800</pubDate><guid>https://sql668.github.io/blog/posts/4b-postgres-query-plan-audit/</guid><description>&lt;p&gt;「比 Postgres 快 81% 的查询计划」是标题，「延迟降低 44.7%」「1.81x 加速」是正文。三个数字不是互相打架，但也不是同一个数字：1.81x 与 44.7% 是同一个加速比的两种基数写法，81% 只能反推为同一个 1.8054× 的「倍率减一」写法，见下——不是耗时下降。&lt;/p&gt;</description></item><item><title>System One Models 与 Jev：不生成字符串的模型，凭什么快两个数量级</title><link>https://sql668.github.io/blog/posts/system-one-jev-typed-output/</link><pubDate>Wed, 16 Sep 2026 14:46:00 +0800</pubDate><guid>https://sql668.github.io/blog/posts/system-one-jev-typed-output/</guid><description>&lt;p&gt;请求路径里放一个模型做判断——这笔转账要不要放行、这条工单要不要升级。现在的做法是发 prompt、解析返回的 JSON：单次请求几秒到几分钟，输出 token 按字计费，而 SLO 是五百毫秒。这个差距调参补不回来。&lt;/p&gt;</description></item><item><title>一次没用零日的入侵：拆解 AI Agent 攻击 RubyGems 的三条真实利用链</title><link>https://sql668.github.io/blog/posts/rubygems-agent-attack-three-chains/</link><pubDate>Tue, 15 Sep 2026 16:45:00 +0800</pubDate><guid>https://sql668.github.io/blog/posts/rubygems-agent-attack-three-chains/</guid><description>&lt;p&gt;9 月 11 日，路透社和华尔街日报同时报道了一件事：OpenAI 的 agent 攻击过 RubyGems.org。当天 Aaron Patterson（Ruby 圈里叫 tenderlove）写了一篇很短的博客，标题是《What a time to be alive》，结尾跟了个 🙃。&lt;/p&gt;</description></item><item><title>这个博客是怎么搭起来的：Hugo + GitHub Pages + PR 流程</title><link>https://sql668.github.io/blog/posts/hello-hugo-github-pages/</link><pubDate>Tue, 15 Sep 2026 14:00:00 +0800</pubDate><guid>https://sql668.github.io/blog/posts/hello-hugo-github-pages/</guid><description>&lt;p&gt;这是本站的第一篇文章，顺手把它的发布流程记录清楚——因为以后每篇文章都走同一条路。&lt;/p&gt;
&lt;h2 id="为什么是静态站点"&gt;为什么是静态站点&lt;/h2&gt;
&lt;p&gt;博客的内容是文章，不是应用。静态站点没有数据库、没有运行时、没有需要维护的服务端进程，托管在 GitHub Pages 上零成本、零运维，而且构建产物就是一堆 HTML/CSS，任何托管都能接。&lt;/p&gt;</description></item></channel></rss>