唐杰老师：那个最小的闭环已经出现了，GLM-5.3正在帮助优化承载它自身运行的系统。两周时间把端到端吞吐量提升到了原来的 3.2 倍技术细节智谱发在自己的官方博客里了：z.ai/blog/glm-built-its-inference-infrastructure

------------------------两周。

从 GLM-5.3-Flash 第一次在国产加速器上跑通，到全部生产流量都由这套硬件承载，只用了两周。与此同时，端到端吞吐量还提升到了原来的 3.2 倍。

但我一直在想的，是这项工作很大一部分究竟是谁完成的：

一个由 GLM-5.3 驱动的 Infra Agent（基础设施智能体）。

也就是说，一个模型正在帮助优化承载它自身运行的系统。

当时的条件并不轻松。

内存和互连带宽都很有限；需要支持 100 万 token 的上下文；还要处理多模态请求；软件栈也远未成熟——缺 kernel 是常态，文档很多时候甚至只能靠猜。

几乎每一项优化，本质上都是一种取舍：

用计算换内存（ReplaySSM）；用通信换内存（节点内张量并行）；用精度换容量（INT8 / FP8 / BF16 混合精度缓存）；通过解耦换取更大的调度自由度（Encode–Prefill–Decode，编码–预填充–解码解耦）。

但最重要的经验，并不是其中某一项具体优化。

Agent 陷入僵局时，原因通常不是它不会写代码，而是它不知道事情为什么会变差。

“吞吐下降了 20%”，只能告诉你系统出了问题。

但它不会告诉你：问题出在哪一层？之前的哪个假设错了？下一步应该验证什么？

用强化学习的话来说，这相当于一个稀疏奖励，同时还伴随着信用分配问题（credit assignment problem）。而一次端到端 benchmark 如果要跑几个小时，探索和试错的速度就会慢得令人难以接受。

资深工程师之所以能处理这类问题，是因为他们脑中其实有一套隐性的“过程奖励”。

他们知道什么时候应该去看 timeline，什么时候该跑 microbenchmark，也知道应该对比哪一层的输出。

所以，我们把这套东西显式化了。

我们把它称为“稠密反馈（dense feedback）”：为 Agent 提供分层的验证接口，并让它可以直接调用。

正确性反馈：算得对不对？

系统行为反馈：时间到底花在了哪里？

性能反馈：在什么条件下，哪个方案更优？

每一种反馈信号都必须满足三个条件：局部、低成本，而且可以被客观验证。

Agent 找出了三个问题。

第一，KDA 的 context-parallel 路径存在精度漂移，而且误差会随着序列长度增加而不断放大。

根因是 TF32 的舍入误差，在连续进行状态矩阵合并时不断累积。

对应的修复现在已经合并进 Flash Linear Attention 上游项目（PR 1180）。

第二，KV 传输实际上从未和 DeepEP dispatch 真正重叠执行。

Agent 一路追踪调用链，跨过 Python / C++ 边界，最后发现节点内通信路径始终没有释放 GIL。

修复之后，数据传输带来的开销从 30% 以上降到了 1% 以下。

第三，一个 decode kernel 因为分块方式的问题，把同一个归一化操作重复计算了四遍。

Agent 重新组织了 kernel，实现了 1.71 倍的加速。

而这个思路来自它总结出的“优化骨架（optimization skeletons）”——它通过阅读 SGLang、FLA 和 DeepGEMM 中已有的 kernel，提炼出了一些可复用的优化模式。

当然，这里也需要明确边界：

目标仍然由人来定义，反馈环境仍然由人来构建，所有高风险修改也都经过人工审核。

但工程师的角色正在发生变化：

从亲自解决问题的人，逐渐变成设计反馈机制的人。

这背后还有一层更深的含义。

一个建立在真实基础设施任务之上、具备分层结构并且可以客观验证的反馈环境，恰恰是训练下一代模型最需要的东西。

Agent 每完成一个任务，都有可能成为训练它下一代继任者的素材和训练场。

我们距离“递归式自我改进”还非常遥远。

但现在，那个最小的闭环已经出现了。

模型优化系统。

系统承载模型。