模型优化系统，系统跑模型：GLM 用 Infra Agent 把推理吞吐提到约 3 倍

原文来源：Z.ai Blog — GLM 团队用 GLM-5.3 驱动的 Infra Agent 搭建并优化自己的生产推理栈，两周内把端到端吞吐提升约 3 倍，单 token 成本做到与主流 NVIDIA GPU 相当。

智谱这篇技术博客的开头很直白：在开发 GLM 的过程中，模型有时会展现出让他们惊讶、甚至不安的能力。

2025 年 10 月，团队开始研究怎么加强模型的网络安全能力。当时的推理逻辑很简单：网络安全是编码能力的自然延伸，能看懂复杂代码的模型，应该也能看懂代码里的漏洞。后面发生的事情超出了预期——不到一年，他们的安全合作方用 GLM 在真实代码库里挖出了上千个漏洞。模型开始改变网络安全行业的格局，同时也带来了以前不存在的风险，为此他们不得不专门设计一套可信访问机制。

真正让团队感到震动的是另一件事：GLM 越来越多地在帮忙构建 AI 本身。他们眼看着模型完成了一项原本需要一队资深基础设施工程师做上几周的任务。当意识到这些工作会直接影响下一代模型的训练方式时，他们的感受是——我们的接班人，正是我们自己造出来的 AI 系统。

坦白说，在 GLM-4.7 之前，团队内部用 GLM 写代码多少是出于「毕竟是自家做的」。那时编码模型的产品市场契合度还没到。到了 GLM-5.3，它已经成了团队每个人日常离不开的编码伙伴，并且正在稳步往「替代我们」的方向走。如果这个趋势持续，给足算力和时间，终点就是一个能完全自主设计并训练自身后继者的系统——也就是所谓的递归自我改进（Recursive Self-Improvement，RSI）。

现在当然还没到那一步，但雏形已经出现。这篇文章记录的就是其中一个早期案例。

从第一次跑通到生产上线

把一个模型从「在新硬件上第一次跑通」变成「能稳定承接线上流量的高性能推理服务」，是一项相当大的系统工程。GLM-5.3-Flash 的发布走的也是这条路：他们在 10 万张以上国产 AI 加速器组成的集群上，从零搭出一套生产级推理服务，GLM-5.3-Flash 的全部线上推理都跑在这套系统上。

这件事的难度在于没有先例。此前没有人部署过这个规模的国产加速器集群；芯片的显存容量和带宽相对有限；同时还要支持新的模型架构、100 万 token 的上下文窗口和多模态请求。整个生态不成熟，kernel 支持不完整，很多本该有文档的地方只能靠猜。最终这些工作做完了，但完成它的不只是基础设施工程团队——其中很大一部分由一个跑在 GLM-5.3 上的 Infra Agent 承担。

接下来的事情大家都熟悉了。GLM-5.3-Flash 以匿名模型名 Ox-Alpha 在 OpenCode 和 OpenRouter 上接受真实流量测试，上线一周内就成为两个平台上使用量最高的模型，六天处理了超过 62 万亿 token。

为了把性能压出来，团队做了一连串激进的内存优化，其中包括用算力换带宽、用通信换显存的自定义方案。最终的技术栈里包含几个关键手段：针对线性注意力和 LM Head 的节点内张量并行、ReplaySSM、W8A8 量化、INT8/FP8/BF16 混合精度缓存量化，以及 Layer Split。在此之上，他们又引入了 Encode-Prefill-Decode（EPD）分离式架构。这些优化叠加起来，把端到端服务性能提到约 3 倍，硬件利用率和单 token 成本都达到与主流 NVIDIA GPU 相当的水平。

在 Infra Agent 的反馈回路全程参与的情况下，GLM-5.3-Flash 从最初的模型适配到具备生产可用性，用了不到两周，端到端吞吐相对初始基线提升到约 3 倍。

关键不在模型会不会写代码

在整个过程中，团队逐渐意识到一件事：Infra Agent 的工程效率不只取决于模型的代码生成和推理能力，更取决于系统能不能持续给出「能追溯到具体原因」的反馈。

代码库只提供静态上下文。而推理系统里的数值偏差、性能回退、优化目标落空，往往来自多个层面的动态交互——kernel 实现、并行策略、通信行为、内存管理、服务编排。

即便 agent 能读懂整个代码库，「精度测试失败」「TTFT 涨了 30%」「输出吞吐掉了 20%」这类反馈仍然不够用：它依然不知道该找哪一层的问题、自己的假设为什么错、下一步该验证什么。端到端指标只能告诉 agent 结果变差了，说不清为什么。

所以除了提升 agent 写改代码的能力，还要解决一个更底层的系统问题：怎么把稀疏的端到端结果，变成能直接指导下一步动作的、细粒度且可归因的工程反馈？ 这也是为 Infra Agent 搭出有效反馈回路的关键。

传统推理系统优化并不缺测试、日志、性能分析工具和微基准。它们在工程师手里是够用的：老手会看着压测结果决定下一个该观察什么，逐步去看 kernel 输出、执行时间线、通信事件、线程状态，再把不同工具的信息串起来。

但这些东西如果不被组织成 agent 可以直接调用、可以重复执行的流程，agent 拿到的反馈就依然稀疏。它可能知道吞吐没达标，却仍然无法回答下面这些问题：

• 是某个 kernel 太慢，还是计算设备在空转？
• 是 KV Transfer 本身慢，还是上层调度没能及时推进传输？
• 这个优化对哪些输入形状有效，在什么条件下会回退？

单一的端到端指标回答不了这些。于是团队把正确性测试、运行时日志、执行 trace、运行时事件、微基准和端到端指标全部纳入 agent 的迭代流程，把整个系统优化过程拆成可以本地观察和验证的小步：kernel 级对比验证数值正确性，微基准测量特定输入条件下的局部性能，执行 trace 和运行时事件揭示计算、等待、通信之间的时序关系。agent 可以针对当前假设选择合适的验证手段，而不是每改一次都要等一次完整的服务部署和端到端压测。

他们把这种做法叫「稠密反馈」（dense feedback）。这里的「稠密」不是指给 agent 灌越多日志和指标越好，而是强调三个特点。

第一，反馈要足够局部。 能挂到具体的引擎启动参数、代码改动、kernel、输入条件、线程、执行区间或代码路径上就挂上去，帮 agent 缩小问题范围。比如不要说「融合优化后模型精度下降」，而是给出某个具体请求在改动前后的输出差异——这样 agent 才有依据去构造最小复现、分析原因。

第二，反馈的获取成本要低、要快。 agent 提出假设、做出修改、构造对照实验之后，总得有合适的方式去验证。能用一次 kernel 测试或本地微基准回答的问题，就不该每次都去跑全量部署加端到端压测。验证周期越短，agent 越能及时纠偏，也越少在没结果的假设上耗工夫。

第三，反馈要支持客观验证。 改动对不对、性能有没有变好，应该由参考实现、测试结果和可对比的实验指标来决定。运行时信号可以帮 agent 找到可能的原因，但观察之间的相关性本身不能确立因果。要确认某个路径上的改动是否产生预期效果，还得靠对照实验。

这三条决定了反馈是否「可用」。正确性反馈回答「算得对不对」，系统行为反馈回答「时间花在哪儿」，性能反馈回答「哪种做法更好、在什么条件下更好」。这些验证手段不必按固定顺序来，而应该匹配当前假设，让每次实验都回答一个具体问题。

本地验证和端到端测试在这里分工不同：前者尽早淘汰错误或无效的改动、筛出值得深挖的候选；后者确认局部收益能否转化为真实的服务提升，以及改动会不会在真实负载下引入新的回退。

基于这些原则，GLM-5.3-Flash 的发布建立了一个由工程师、Infra Agent 和实验环境三方组成的优化回路：工程师定义目标和系统边界，agent 负责分析、假设和改代码，实验环境提供分层的、及时的、可验证的反馈。原本靠工程师经验串起来的排查过程，就这样变成了 agent 可以持续执行的工程流程。

这个过程既包括直接提升吞吐的性能优化，也包括不会立刻提升吞吐、但对系统正确稳定上线必不可少的 bug 修复。下面三个案例分别说明这条回路怎么帮 agent 确认「算得对」、搞清「为什么不够快」、探索「怎么才能更快」。

案例一：发现 kernel 里的数值精度问题

推理性能优化必须建立在数值正确的前提上。对 agent 来说，验证的第一步是搞清楚推理引擎到底做了哪些计算。上层的并行策略会改变 kernel 输入的切分方式、执行路径的选择和结果的合并方式，只在非切分条件下测 kernel 输出，覆盖不到真实部署时的行为。

为此他们建立了一份「并行策略到 kernel 实现」的映射，把系统级部署配置翻译成 agent 可以逐个验证的 kernel 级任务。有了这份映射，agent 就能判断某个并行配置涉及哪些 kernel、输入怎么切分、哪些计算路径需要跟非切分实现做对比。

接下来让 agent 对比切分与非切分执行路径的数值精度：同样的输入，在统一计算语义和输出位置之后，检查不同执行方式的结果是否满足数值误差容忍度。这样就把并行配置、kernel 路径和观测到的误差串了起来。一旦测试暴露差异，agent 可以顺着对应的切分方案和计算路径继续查，而不必从整个模型这一层重新开始排查。

正是在这个 kernel 验证过程中，他们发现了 KDA kernel 的 Context Parallelism（CP）路径存在数值精度问题。CP 与非 CP 结果的差异，把排查方向指向了并行执行引入的状态传播与合并计算。

CP 切分需要合并来自不同上下文分片的状态，其核心计算可以简化为：

M = tl.dot(M_chunk, M)      # 合并跨分片的状态变换
S_next = tl.dot(M, S) + H   # 更新下一个分片的初始状态

原始实现里，tl.dot 默认按 TF32 计算以换取更好的性能——即使输入是 FP32。这个较低的计算精度导致误差在变换合并和状态更新过程中不断累积，上下文越长越明显。

修复方式是给两个操作显式指定 input_precision="tf32x3"：把三次 TF32 Tensor Core 运算组合起来得到更高精度的结果，在尽量保留 Tensor Core 性能优势的同时减少累积误差。

这个案例里，反馈环境在问题浮出水面之前就已经起作用了：并行策略到 kernel 的映射定义了要测什么，切分与非切分路径的对比暴露了数值差异，对计算精度的分析解释了误差来源，回归测试则提供了持续验证改动的基础。对 agent 而言，这套流程把系统级的并行设计变成了可执行、可追溯的正确性任务。本地验证之后，候选实现仍然要回到目标部署环境，通过模型级精度和服务性能的最终验收。这些数值精度修复已经合入了上游的 Flash Linear Attention（见 PR #1180）。

案例二：Python 和 C++ 边界上的并发瓶颈

对系统级性能问题，明确的测试场景和性能约束能给 agent 一个下手点，用来识别异常并确定分析方向。

团队的推理优化工程师为 agent 定义了测试场景——单独 Prefill、Prefill + KV Transfer、单独 Decode——以便把不同执行阶段及其组合的性能影响分离开，并为每个场景设定了验收标准。比如同一负载下，Prefill + KV Transfer 与只有 Prefill 的基线之间，性能差距不应超过 5%。

但 agent 发现有些场景下差距超过 20%。这条反馈把排查范围缩小到 KV Transfer 引入的额外开销和并发交互。agent 随后细看 KV Transfer 的时间线，发现一个异常：在这些场景里，Python 侧的 KV Transfer 执行从未与 DeepEP 的 dispatch/combine 调用区间重叠。

顺着这条线索，agent 去查 DeepEP 与 Mooncake Transfer 之间的并发，沿调用链追到了 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。这进一步支持了 agent 对节点内路径的判断。

修复的关键是在相关 C++ 执行区间释放 GIL，让 Mooncake Transfer 的 Python 线程能及时推进任务。修复后既要看时间线，也要对照最初的性能约束：前者检查调度和传输是否获得了与计算重叠的机会，后者判断改动是否真的提升了服务性能。同样的测试条件下，Prefill + KV Transfer 与单独 Prefill 的性能差距从 20% 以上降到了 1% 以内。

这个案例里，性能约束先把「不符合预期」变成一条明确的测试差异，时间线把排查范围缩小到两个组件之间的并发问题，代码分析最后定位到 GIL 的持锁范围。稠密反馈把端到端性能、跨层运行时行为和具体的实现细节串成一条证据链，agent 每一步分析都有依据。

案例三：把已有的 kernel 优化经验搬到自己的推理栈上

kernel 优化要回答两个问题：怎么判断一个优化有效，以及去哪儿找值得做的优化方向。

第一，kernel 性能必须在推理引擎真实的执行环境里评估。比如给某个计算 kernel 更多资源可能缩短它自己的执行时间，却让 KV Transfer kernel 拿到的资源变少，最后整条流水线反而更慢。所以 agent 不能只盯着单个 kernel 的延迟，而要在目标负载、资源约束、任务重叠和端到端收益的语境里确立正确的优化目标。

第二，大量优化经验藏在 SGLang、Flash Linear Attention、DeepGEMM 这些项目的手写 kernel 里。agent 需要从这些代码中提炼优化技巧及其适用条件，针对当前 kernel 和目标硬件提出候选方案，再用实验验证实际效果。已有代码提供优化方向，系统反馈决定这些优化在实践里站不站得住。

团队让跑在 GLM-5.3 上的 Infra Agent 跨代码库、编程语言和硬件平台学习现有 kernel 的优化技巧，通过增量和消融实验，把它们蒸馏成包含适用条件、变换方法、资源约束和验证证据的「优化骨架」。面对新 kernel 时，agent 从这些骨架出发，再用 profiling 和分层测试重新评估 tiling、访存和资源分配策略。验证过的改动及其适用条件回流到骨架库。工程师主要负责定义目标与约束，并审查涉及数值语义、并发行为和生产风险的关键改动。

其中一个代表性案例是 KDA Decode kernel 的性能演进。引入 ReplaySSM 用算力换显存之后，kernel 执行时间第一次上升（v0 到 v1）。agent 做的除法优化把 v1 的执行时间降低了 9.6%。接着，在收到「计算是主要瓶颈」的反馈后，Infra Agent 发现原实现沿 V 维度切 tile，导致相同的 FP32 归一化和门控计算被重复做了四遍。它把这些 tile 合并进同一个 thread block，把共享的中间结果留在寄存器里，用一次 warp 级归约替代了逐 tile 的重复计算——牺牲一部分并行度，换来从源头上消除冗余计算，相对 v2 提速 1.71 倍。

这个案例里，跑在 GLM-5.3 上的 Infra Agent 从已有实现中提炼优化经验，再用到自己所服务的推理 kernel 上。它从骨架出发逐项调优，用分层验证决定保留哪些改动，用端到端性能确定实际价值，验证过的洞见再回流骨架库。模型就这样参与优化了自己的推理系统，而每一轮部署积累的经验，又降低了下一轮优化所需的工程投入。

反馈要驱动行动，实验要检验假设

三个案例合起来说明一件事：反馈的价值不在数量，而在它能不能帮 agent 回答眼前这个问题。大量非结构化日志会淹没关键信号，覆盖不全的 profiling 会导致错误归因，微基准里成立的优化未必能变成端到端收益。所以搭一个反馈环境，不只是提供测试、日志和性能数据，还要说明每类观测能支撑什么判断、边界在哪、哪些结论必须靠进一步的实验确认。

在这个框架里，工程师有三项关键职责：定义优化目标和系统约束；搭建 agent 可以直接使用的反馈环境；审查涉及系统架构、异步并发和生产风险的关键改动。agent 则负责提出假设、实施改动、跑实验，再依据反馈决定保留、修正还是放弃当前做法。正确性、稳定性和端到端性能共同构成最终验收标准。

回头看 GLM-5.3-Flash 的发布过程：kernel 里的数值精度 bug、跨越 Python/C++ 边界的并发问题、关键 kernel 的性能优化，分别代表不同层面的工程挑战。通过本地测试、跨层观测和分层基准，最初模糊的异常被逐步转成可测试的工程假设。复杂的系统问题被拆解成一连串可观察、可实验、结果可归因的迭代。也正是在这个反馈回路里，agent 的编码和推理能力才转化成可验证的工程进展。

跑在 GLM-5.3 上的 Infra Agent 帮着建起了推理基础设施；这套由工程师和 agent 共同优化的系统，回过头来让 GLM-5.3-Flash 能稳定地服务用户。模型优化系统，系统跑模型。 这项工作说明，压缩系统工程周期靠的不只是更强的模型能力，还需要一个能让模型持续获得反馈、检验判断、修正行动的 agent 工程回路。

当然，他们离递归自我改进还很远。选择目标、划定边界、评估风险仍然是人的责任，他们认为在很长一段时间里都应该如此。但那些数字——两周、3 倍吞吐、10 万张加速器——说明这个边界上的进展不会因为人们希望它慢下来就慢下来。