智谱GLM-5.3：10万卡集群与Infra Agent工程复盘

2026 年 9 月 17 日，智谱（Z.ai）发布技术文章《GLM Built Its Inference Infrastructure》，披露 GLM-5.3-Flash 背后的大规模推理基础设施，以及 GLM-5.3 驱动的 Infra Agent 如何参与这套系统的建设和优化。

这套生产级推理系统从零开始搭建，运行在超过 10 万张国产 AI 加速卡组成的集群上。

目前，GLM-5.3-Flash 的全部生产推理均运行在这套系统中。

从模型首次成功运行在新硬件上，到具备生产环境要求，整个过程不到两周。

经过一系列系统级优化，GLM-5.3-Flash 的端到端吞吐相较最初基线提升约 3 倍。

智谱称，最终系统的硬件利用效率和单 Token 成本已经达到与主流 NVIDIA GPU 相当的水平。端到端吞吐则相较初始基线提升约 3 倍。

更特别的是，这套系统的大量工程工作并非完全由传统基础设施团队完成。

智谱为此构建了一套由 GLM-5.3 驱动的 Infra Agent，让模型直接参与推理系统分析、问题定位、代码修改和性能优化。

按照智谱的描述，一个过去可能需要有经验的基础设施工程团队花费数周完成的任务，这一次有相当一部分由 Infra Agent 参与完成。

模型开始参与建设运行自己的系统

GLM-5.3-Flash 的部署并不轻松。

一方面，这是一套超过 10 万张国产 AI 加速卡的大规模集群。

智谱称，此前还没有人在如此规模上部署国产加速器。

另一方面，团队面临相对有限的芯片显存容量和带宽，同时需要支持新的模型架构、最长 100 万 Token 上下文以及多模态请求。

相关软件生态也不够成熟，部分 Kernel 支持不完整，一些本应能够从文档中获得的信息只能依靠测试和推断解决。

为此，智谱进行了大量针对硬件特性的推理优化，包括用于线性注意力和 LM Head 的节点内 Tensor Parallel、ReplaySSM、W8A8 量化、INT8/FP8/BF16 混合精度 Cache 量化，以及 Layer Split。

在此基础上，团队进一步采用 Encode-Prefill-Decode（EPD 解耦架构）。

这些优化最终让 GLM-5.3-Flash 的端到端服务性能相较初始基线提升约 3 倍。

GLM-5.3-Flash 端到端吞吐性能演进

整个过程中，Infra Agent 一直处于优化反馈循环之中。

智谱逐渐发现，决定 Infra Agent 工程能力的并不只是模型会不会写代码、推理能力有多强，更关键的是系统能否持续向模型提供足够细致、能够定位具体原因的反馈。

因为大模型推理系统的问题往往跨越多个层级。

一次性能下降可能来自 Kernel，也可能来自并行策略、通信、内存管理或者 Serving 调度。

如果系统只告诉 Agent“首 Token 延迟增加 30%”或者“输出吞吐下降 20%”，模型知道结果变差了，却很难判断究竟哪里出了问题。

为此，智谱提出了“Dense Feedback（密集反馈机制）”。

这里的“Dense”并不是单纯提供更多日志，而是要求反馈具有三个特点，足够局部、能够快速获得，并且可以客观验证。

Agent 不只是看到最终吞吐量，而是可以继续检查具体 Kernel、输入 Shape、代码路径、执行时间区间、线程状态和通信过程，再针对自己的判断进行实验。

智谱将正确性测试、运行日志、Execution Trace、Runtime Event、Microbenchmark 和端到端指标纳入同一套 Agent 工作流。

能够通过 Kernel Test 验证的问题，不必每次都重新部署完整服务进行压力测试；局部测试通过后，再进入真实工作负载下的端到端验证。

基于密集反馈构建的 Infra Agent 优化闭环

由此形成一套完整循环：

1）工程师负责定义目标和系统边界；

2）Infra Agent 负责分析问题、提出假设和修改代码；

3）实验环境负责提供分层、及时、可验证的反馈；

4）Agent 再根据结果保留、修改或者放弃当前方案。

一个精度 Bug：问题最终找到 TF32

智谱披露的第一个案例发生在 KDA Kernel。

在验证 Context Parallelism，也就是 CP 路径时，团队发现 CP 与非 CP 路径的结果存在数值差异。

Infra Agent 沿着状态传播和合并过程继续检查，最终定位到 tl.dot。

原始实现中，即使输入数据为 FP32，tl.dot 为获得更高性能仍会默认使用 TF32 计算。

短距离计算中的误差可能并不明显，但在长上下文情况下，状态不断进行转换和合并，误差会逐渐累积。

最终，相关操作被显式设置为 input_precision=“tf32x3”。

这种方式通过三次 TF32 Tensor Core 运算获得更高精度，在降低累计误差的同时，尽可能保留 Tensor Core 的性能优势。

这一数值精度修复随后已经合并进入 Flash Linear Attention 上游项目。

第二个问题藏在 Python GIL

第二个案例涉及 KV Transfer。

工程师为 Infra Agent 设置了几个独立测试场景，包括单独运行 Prefill、Prefill + KV Transfer，以及单独 Decode。

其中一项要求是，相同工作负载下 Prefill + KV Transfer 相对于 Prefill-only 的性能差距不得超过 5%。

但实际测试中，部分场景的差距超过了 20%。

Infra Agent 随后分析 KV Transfer 的运行时间线，发现一个异常现象，Python 侧的 KV Transfer 与 DeepEP 的 dispatch/combine 调用没有发生预期中的重叠。

进一步沿着 Python/C++ 调用链分析后，问题最终指向 Python GIL。

智谱当时使用的 DeepEP v1.2.1 中，intranode_dispatch 和 intranode_combine 没有显式释放 GIL。

其中，dispatch 在需要获取接收到的 Token 数量时，还需要在 CPU 侧等待 GPU 返回数据。

进入 C++ 并不代表 Python GIL 会自动释放。

这些调用占用 GIL 时，同一进程内负责 Mooncake Transfer 的 Python 线程无法及时获得 GIL，因此 KV Transfer 任务的调度和提交被延迟。

即使底层传输机制支持异步执行，上层任务没有及时提交，也无法真正形成计算和传输并行。

解决方法是在相关 C++ 执行阶段释放 GIL。

修复后，在相同测试条件下，Prefill + KV Transfer 相对于 Prefill-only 的性能差距从超过 20% 降到了不足 1%。

KV Transfer 并发瓶颈的发现与修复

Infra Agent 自己优化运行 GLM 的 Kernel

第三个案例发生在 Kernel 性能优化。

智谱没有让 Infra Agent 每次从零开始寻找优化方法，而是让 GLM-5.3 学习 SGLang、Flash Linear Attention、DeepGEMM 等项目中已经存在的手写 Kernel。

Agent 从不同代码库、不同编程语言和不同硬件平台中提取优化经验，再通过增量实验和消融实验，总结出一套“Optimization Skeleton”。

这些“优化骨架”记录一种优化适用于什么场景、如何转换、有哪些资源限制，以及此前通过了哪些实验验证。

面对新的 Kernel，Infra Agent 可以先从这些已有经验出发，再根据 Profile 和实际测试结果调整 Tiling、内存访问和资源分配。

智谱以一个 KDA Decode Kernel 为例。

由于采用 ReplaySSM，以计算换内存，Kernel 最初出现了一次性能下降。

Infra Agent 随后进行除法优化，先将执行时间缩短了 9.6%。

继续分析后，Agent 发现原始实现沿 V 维度进行 Tiling，导致同一组 FP32 归一化和 Gating 运算被重复计算 4 次。

Infra Agent 随后将这些 Tile 合并到一个 Thread Block 中，将共享中间结果保存在寄存器中，并利用一次 Warp-level Reduction 取代此前的重复计算。

这一方案牺牲了一部分并行度，却从源头减少了重复计算，最终相较前一版本获得 1.71 倍加速。

一个典型 KDA Decode Kernel 从基线实现到生产版本的性能演进

智谱强调，Kernel 自身跑得更快并不一定代表整个推理系统更快。

例如，一个计算 Kernel 占用了更多硬件资源，即使自身耗时下降，也可能挤占 KV Transfer 所需资源，最终导致整条推理流水线反而变慢。

因此，每项局部优化最后仍需要回到真实推理环境，通过端到端性能测试验证。

6 天处理超过 62 万亿 Token

GLM-5.3-Flash 此前曾以匿名模型 Ox-Alpha 的身份在 OpenCode 和 OpenRouter 上接受真实用户测试。

智谱称，该模型推出后一周内成为两个平台使用量最高的模型，并在 6 天内处理超过 62 万亿 Token。

大规模真实流量也成为这套推理基础设施的一次生产验证。

与单纯依靠 Benchmark 不同，真实 Coding Agent 和长上下文请求会持续触发模型推理、KV Cache 读写、数据传输和任务调度，一些在小规模实验中很难出现的性能和并发问题会因此暴露出来。

智谱认为，这也是 Infra Agent 需要“Dense Feedback”的原因。

Agent 必须知道“计算结果是否正确”“时间究竟消耗在哪里”，以及“哪一种方案在什么情况下更快”，而不仅仅获得一个最终吞吐数字。

智谱首次直接谈到 RSI

这篇文章还有一个值得关注的背景，智谱首次直接将这类工程实践与 Recursive Self-Improvement，也就是递归自我改进联系起来。

智谱表示，在 GLM-4.7 之前，GLM 在 Coding 场景中的实际表现还不够成熟，团队内部使用时也带有一定的“自家模型”因素。如今到了 GLM-5.3，它已经成为团队日常开发中不可缺少的 Coding Partner。

到了 GLM-5.3，GLM 已经成为团队成员日常开发中不可缺少的 Coding Partner。

智谱进一步提出，如果这一趋势延续，在拥有足够算力和时间的情况下，其理论终点是一套能够完全自主设计和训练自己下一代模型的系统，也就是 RSI。

不过，智谱同时明确表示：“我们还没有到达那里。”

云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。

作者: 云头条

查看原文 →