10万卡集群，两周调优：智谱说AI正走向取代自己

一个模型，在超过10万张国产芯片组成的集群上，从零搭起一套生产级推理服务，把端到端吞吐拉到初始基线的3倍——这件事用了不到两周。

更值得琢磨的是，做成这件事的不是一支资深基础设施团队，而是GLM-5.3驱动的Infra Agent。智谱创始人、首席科学家唐杰与GLM团队在最新长文中披露了这个过程，并给出了一个相当直白的判断：模型正从"帮助人类研发模型"，走向"参与构建自己的继任者"。

他们把这称为递归自我改进（RSI）的早期形态。团队同时强调，这还不是完整意义上的RSI。

从"被迫用"到"离不开"

团队在文中回顾了一段内部心态的变化。在GLM-4.7之前，内部用GLM写代码多少带着被迫的成分，毕竟是自己的"亲儿子"，那时Coding的产品市场契合还没到来。

而今天，GLM-5.3已经成为团队成员每天离不开的Coding伙伴。文中用了一个颇有画面感的说法：它"正一步步走向取代我们"。

这种变化并非只体现在写代码上。2025年10月，团队启动安全能力增强研究，当时的判断很朴素——安全能力是代码能力的自然延伸，能读懂复杂代码的模型，理应也能理解代码中的漏洞。

此后的走向超出了预期。不到一年，安全伙伴使用GLM在真实代码库中发现了数千个漏洞。模型开始改变网络安全的格局，也带来了过去不曾存在的危险。为了让这种能力被负责任地使用，团队不得不为它设计受信访问计划。

稠密反馈：让Agent知道"为什么变差"

GLM-5.3-Flash的上线过程，是这次披露的核心案例。这套系统承载了GLM-5.3-Flash的全部线上推理，而搭建它的过程中，团队面对的是生态不成熟、算子不完备、许多文档基本靠猜的局面。

决定Infra Agent工程效果的，不只是模型自身的代码生成与推理能力。团队发现，更关键的是系统能否持续提供有效、可归因的反馈。

代码库只能提供静态上下文。而推理系统里的精度异常、性能退化，往往来自算子实现、并行策略、通信行为、内存管理与服务调度等多个层面的动态交互。如果一次修改后得到的反馈只是"精度测试未通过"或"TTFT增加30%"，Agent仍然难以判断问题出在哪一层。

端到端指标能告诉Agent"结果变差了"，却无法解释"为什么变差"。团队把测试、日志、执行Trace、运行时事件、微基准测试和端到端指标全部纳入Agent的迭代流程，并将这套组织方式称为"稠密反馈"。

稠密不等于把尽可能多的日志塞给Agent。团队给出了三个特征：

• 足够局部：反馈应关联到具体的引擎启动参数、修改的代码、算子、输入条件或执行区间，帮助Agent缩小问题范围。
• 低成本、及时：能通过算子测试或局部微基准回答的问题，无须每次等待完整服务部署和端到端压测。
• 支持客观验证：修改是否正确、性能是否改善，应由参考实现、测试结果和可比较的实验指标判断，不能仅凭现象之间的相关性确认根因。

围绕这套思路，上线过程形成了一套由工程师、Infra Agent和实验环境共同组成的优化闭环：工程师定义目标与系统边界，Agent负责分析、假设和修改，实验环境提供分层、及时且可验证的反馈。

三个案例：算得对、跑不快、跑更快

团队选取了三个案例，分别对应保证"算得正确"、解释"为什么跑不快"，以及探索"怎样跑得更快"。

第一个案例关于正确性。团队建立了推理引擎并行策略到算子实现的映射，把系统层面的部署配置转化为Agent可以逐项验证的算子任务。正是在这一算子验证过程中，他们发现了KDA算子上下文并行路径的精度问题。

CP切分需要合并不同上下文分片的状态。原实现中，tl.dot即使接收FP32输入，也默认采用TF32计算以提高性能。较低的计算精度使误差在变换合并和状态更新中不断累积，在长上下文下更加明显。

修复方法是将这两处计算显式指定input_precision="tf32x3"，通过三次TF32 Tensor Core运算组合出更高精度的结果，在减轻累积误差的同时尽量保留性能优势。相关精度修复已合并至Flash Linear Attention上游。

第二个案例关于系统行为。推理优化工程师为Agent定义了单独Prefill、Prefill + KV Transfer、单独Decode等测试场景，并设定验收条件：相同workload下，以单独Prefill为基准，Prefill + KV Transfer的性能差距不应超过5%。

Agent在测试中发现，部分场景的性能差距超过了20%。这个反馈把排查范围缩小到引入KV Transfer后的额外开销与并发交互。深入分析时间线后，Agent发现一个异常：KV Transfer的Python侧执行始终没有与DeepEP dispatch/combine的调用区间重叠。

沿调用链进入Python/C++边界后，问题浮出水面。团队使用的DeepEP v1.2.1中，intranode_dispatch和intranode_combine均未显式释放Python GIL；其中dispatch在需要获取接收token数量时，还会在CPU上等待GPU返回信息。

关键在于，进入C++并不意味着自动释放GIL。在这段持锁调用期间，同一进程内负责Mooncake Transfer的Python线程无法及时获得GIL，传输任务的调度与提交因而被推迟，压缩了KV Transfer与后续计算重叠的机会。

源码中还有一个直接的对照：同版本的internode_dispatch已显式释放GIL，注释说明这样做是为了避免CPU等待期间阻塞其他线程中的KV Transfer。

修复的关键，是在相关C++执行区间释放GIL。在相同测试条件下，修复后的Prefill + KV Transfer与单独Prefill的性能差距小于1%。

62万亿token之后

GLM-5.3-Flash以匿名模型Ox-Alpha在OpenCode与OpenRouter上接受真实调用检验。上线一周成为双平台调用量最大的模型，6天token调用量超过62万亿。

支撑这一成绩的技术栈融合了多项关键技术：针对线性注意力和LM Head的节点内张量并行、ReplaySSM、W8A8量化、INT8/FP8/BF16混合精度缓存量化，以及Layer Split等。在此基础上，团队进一步引入Encode–Prefill–Decode分离式架构，实现了端到端服务性能约3倍的提升，硬件利用效率与单Token成本均达到主流NVIDIA GPU的相当水平。

由于Infra Agent参与的反馈闭环贯穿了整个优化过程，GLM-5.3-Flash在不到两周内完成了从模型适配到生产可用的跨越。

团队在文末写道，他们看到模型完成了一项过去需要一支资深infra团队数周才能完成的基础设施工作，并意识到这项工作将直接改变下一代模型的训练方式。于是他们更加确信：继任者，正是自己亲手创造出来的AI。

如果这一趋势延续下去，给足算力、给足时间，终点是一个能够完全自主设计并训练出自己继任者的系统。团队承认还没有走到那里，但早期形态已经出现。