一条被悄悄改写的生产线

9 月 17 日，智谱（Z.ai）发了一篇技术博客，标题里有个很少见的词：递归自我改进。讲的不是模型又刷了多少榜，而是 GLM-5.3-Flash 的推理服务，怎么在一套超过十万张国产 AI 加速卡的集群上从零搭起来。更值得琢磨的是：这套系统里相当一部分工程工作，不是基础设施团队做完的，而是由跑在 GLM-5.3 上的一个 Infra Agent 完成的。结果是：从模型在新硬件上第一次跑通，到能承接真实生产流量，周期不到两周，端到端吞吐相比最初基线提升约 3 倍；上线前它以匿名模型名 Ox-Alpha 在 OpenCode 和 OpenRouter 跑真实流量，一周内成为两个平台使用量最大的模型。

数据中心机房中的 GPU 加速器集群

难点其实很土：生态不成熟，文档不存在

十万卡级别的国产加速器集群此前没有先例。显存容量和带宽相对有限，还要支持新的模型架构、100 万 token 上下文和多模态请求；内核支持不完整，很多本该写在文档里的东西只能靠猜。他们用了一连串偏“抠”的优化：张量并行、ReplaySSM、W8A8 量化、混合精度缓存量化、Layer Split，再叠加 Encode-Prefill-Decode 分离架构，才把端到端性能拉高约三倍，硬件利用率和单 token 成本做到与主流 NVIDIA GPU 相当。

真正的瓶颈不是写代码，而是“反馈”

博客里最有价值的一段，是承认智能体效能的天花板不在生成代码的能力。代码库只能提供静态上下文，而推理系统里的数值偏差、性能回退，往往来自内核实现、并行策略、通信行为、显存管理、服务编排这些层之间的动态相互作用。一句“数值精度测试失败”或“首 token 延迟涨了 30%”，对人是线索，对智能体几乎等于没有信息——它不知道是哪一层的问题，也不知道下一个实验该测什么。

于是他们把校验做“稠密”：把正确性测试、运行日志、执行轨迹、微基准和端到端指标都接入智能体的迭代流程。稠密不等于日志越多越好，而要满足三点：足够局部（能定位到具体内核、输入条件和代码路径）、获取便宜且及时（内核级测试能回答的，不必每次都全量部署压测）、能客观验证（靠参考实现和控制变量实验，而不是观测之间的相关性）。

三个案例，三种典型故障

一是精度问题。智能体在校验中发现 KDA 内核的上下文并行路径数值对不上：tl.dot 默认按 TF32 计算，哪怕输入是 FP32，误差在长上下文的状态合并中不断累积；修法是显式指定 tf32x3，该修复已合并回 Flash Linear Attention 上游。二是并发问题。团队要求“仅 Prefill”与“Prefill + KV 传输”的性能差距不超过 5%，实测超过 20%；智能体顺着时间线追到 Python/C++ 边界，发现节点内接口没有释放 GIL，而进入 C++ 并不等于自动释放 GIL，修完后差距降到 1% 以内。三是内核优化。一个 KDA Decode 内核原本沿 V 维度切分，同一份归一化和门控计算被重复四遍；智能体把切片合并进单线程块、中间结果留在寄存器，用一次 warp 级归约替掉重复计算，换来 1.71 倍加速。这些被验证的技巧会沉淀成带适用条件的“优化骨架”，供下一个内核复用。

给产业实践的三点参考

很多人把智能体落地想成“给它一个仓库，让它自己改”，这篇博客给出的答案恰恰相反：智能体真正吃的是反馈环境，不是代码库。其次，人的职责被重新划线但并未消失：定目标与系统边界、搭可用的反馈环境、审核涉及数值语义与并发行为的关键改动，仍然属于工程师。

对国内做 AI 应用落地的团队，结论更直接：当单卡算力不再是最稀缺的东西，“用工程手段补上不成熟的硬件生态”本身就是一种能力。这和中小企业做数字化是同一个道理——难点通常不在买什么，而在把反馈闭环搭起来。