Z.ai 在 9 月 17 日的官方博客里给出了一份少见的工程复盘：GLM-5.3-Flash 的全部生产推理，跑在一个由超过 10 万张国产 AI 加速卡组成的集群上，推理服务从模型首次跑通到上线只用了不到两周，端到端吞吐量相对基线提升了约三倍。更特别的是，干这活的不只是一支基础设施团队——大部分调优工作由一个由 GLM-5.3 驱动的 Infra Agent 完成。模型参与搭建了运行自己的系统。
这篇博客的标题把落点放在 RSI（Recursive Self-Improvement，递归自我改进）上，叙事从"模型开始帮助建造 AI 本身"展开。但剥开叙事外壳，真正有分量的是里面三层工程内容：国产加速卡集群上怎么把推理服务做起来、10 万卡规模的系统怎么在两周内优化到可用、以及让 AI 智能体接手这类系统工程的"密集反馈"方法论。本文按这三层展开。
先交代背景：GLM-5.3-Flash 和 Ox Alpha
GLM-5.3-Flash 是 GLM-5 系列的首个原生多模态模型，总参数量 320B、激活参数量 18B，采用稀疏注意力架构，支持 1M token 上下文窗口。8 月下旬，它以匿名代号 Ox Alpha 在 OpenCode 和 OpenRouter 上接受真实流量测试，一周内成为两个平台上用量最大的模型，六天处理了超过 62 万亿 token，随后 Z.ai 确认身份并开源权重。
匿名评测是近两年模型厂商验证真实工作负载的常用做法：不挂品牌名，让开发者按输出质量和价格投票。Ox Alpha 这轮测试的特殊之处在于，撑住这波流量的推理系统并非跑在 NVIDIA GPU 上，而是 Z.ai 自建的首个十万卡级国产加速卡集群。博客原文的表述是：此前没有人在这类芯片上部署过这个规模的集群，芯片内存容量和带宽相对有限，软件生态不成熟，kernel 支持不全，很多本该有文档的东西只能靠猜。
优化栈：把带宽和显存从瓶颈里抠出来
国产加速卡的两个硬约束是显存容量和显存带宽。Z.ai 的优化思路围绕"用什么换什么"展开：用计算换带宽，用通信换显存。最终落地的优化栈由几项技术组合而成：
| 优化项 | 作用对象 | 解决的问题 |
|---|---|---|
| 节点内张量并行 | 线性注意力、LM Head | 单卡放不下的矩阵运算切到多卡 |
| ReplaySSM | 线性注意力状态管理 | 用重算换显存，压状态缓存占用 |
| W8A8 量化 | 权重与激活 | 权重体积减半，带宽压力同步下降 |
| INT8/FP8/BF16 混合精度缓存 | KV Cache | 长上下文场景的缓存膨胀 |
| Layer Split | 模型层分布 | 通信换显存，单卡不必驻留完整层 |
| EPD 分离架构 | 整个推理流水线 | 编码、预填充、解码各走各的资源池 |
EPD（Encode-Prefill-Decode）分离是这套栈里结构性最强的一项。大模型推理的三个阶段资源画像完全不同：编码和预填充是计算密集型，一次吃进大块输入；解码是访存密集型，每个 token 都要把权重和缓存过一遍。传统部署把三者塞进同一批 GPU，资源互相打架。分离之后各阶段独立扩缩容，KV Cache 通过传输机制在阶段之间接力。这套架构在 NVIDIA GPU 集群上已有成熟实践，难点在国产加速卡上把每一环都跑通——博客没有回避这一点，措辞是"激进"的内存优化加上大量定制。
混合精度缓存量化值得单独说一句。KV Cache 是长上下文推理的第一显存杀手：上下文越长，缓存越大，能并发服务的请求数就越少。对不同层、不同头采用 INT8、FP8、BF16 混合的精度策略，本质是按数值敏感度分配存储精度——对精度敏感的路径保 BF16，其余下探到 INT8。配合 W8A8 权重量化，单位显存能塞下的上下文和并发都翻了几倍。这几项叠加，官方给出的结果是端到端服务性能提升约 3 倍，硬件利用率与单 token 成本"达到与主流 NVIDIA GPU 相当的水平"。
三层反馈：Infra Agent 怎么干活
如果只有上面这些，这是一篇常规的推理优化复盘。这篇博客真正值得记录的是那个 Infra Agent 的工作方式，以及它暴露出的一个普遍问题：AI 智能体做工程，写代码的能力往往不卡壳，卡住它的是反馈的质量。
Z.ai 的观察是：一个改动之后，如果智能体拿到的反馈只是"数值精度测试失败"或"输出吞吐量下降 20%"，它无法判断问题出在哪一层——kernel 实现、并行策略、通信行为、内存管理还是调度编排。端到端指标能告诉它结果变差了，但不能解释为什么。人类工程师处理同样的问题，靠的是经验把负载测试、日志、profiling、微基准这些散落的信息串起来；智能体没有这串信息的组织方式，能用的反馈就是稀疏的。
解法被命名为 dense feedback（密集反馈），核心是三条性质：
反馈要够局部。 反馈应尽可能挂到具体的启动参数、代码改动、kernel、输入条件、线程或代码路径上。比如"融合优化后精度下降"这种报错没有用，换成一个具体请求在改动前后的输出差异，智能体就能构造最小复现、分析原因。
反馈要便宜且及时。 能用 kernel 测试或本地微基准回答的问题，不应该每次都走完整的服务部署和端到端压测。验证周期越短，智能体纠偏越快，在无效假设上浪费越少。
反馈要支持客观验证。 改动对不对、性能有没有提升，由参考实现、测试结果和可比实验指标判定。运行时信号只能提示可能的原因，相关性不等于根因，最终还是要靠对照实验确认。
落到工程上，这套方法论把优化循环拆成三个角色：工程师定目标和系统边界，Infra Agent 负责分析、提假设、改代码，实验环境提供分层、及时、可验证的反馈。博客用三个案例展示了这套循环的运作。
案例一：KDA kernel 的数值精度 bug
正确性验证的第一步是搞清楚推理引擎到底做了哪些计算。Z.ai 建立了并行策略到 kernel 实现的映射，把系统级部署配置拆成智能体可以逐个验证的 kernel 级任务，再对比切分与非切分执行路径在同样输入下的数值误差。
正是这条检查路径发现了 KDA kernel（线性注意力的一个实现）在上下文并行（CP）路径上的数值问题。CP 分片需要合并不同上下文分片的状态，核心计算是：
M = tl.dot(M_chunk, M) # 跨分片合并状态变换
S_next = tl.dot(M, S) + H # 为下一分片更新初始状态原始实现里，Triton 的 tl.dot 默认用 TF32 精度计算以换取性能，即使输入是 FP32。TF32 的尾数只有 10 位，状态反复合并时误差累积，上下文越长越明显。修复方式是显式设置 input_precision="tf32x3"——用三次 TF32 Tensor Core 运算合成一次更高精度的结果，在保住 Tensor Core 性能红利的同时把累积误差压下去。这个修复已合并进开源的 Flash Linear Attention 仓库（PR #1180），其他在国产卡上做线性注意力推理的团队可以直接受益。
案例二：GIL 卡住的 KV Transfer
性能问题的定位从工程师预设的测试场景开始：Prefill 单独跑、Prefill 加 KV Transfer、Decode 单独跑，各设验收标准。比如同样负载下，Prefill + KV Transfer 与 Prefill 基线的性能差距不应超过 5%。智能体实测发现部分场景差距超过 20%，排查方向随即收敛到 KV Transfer 的额外开销与并发交互。
时间线分析给出了关键异常：这些场景里，Python 侧的 KV Transfer 执行始终无法与 DeepEP 的 dispatch/combine 调用区间重叠。顺着调用链查到 Python/C++ 边界，找到了根因：所用版本 DeepEP v1.2.1 的 intranode_dispatch 和 intranode_combine 都没有显式释放 Python GIL（全局解释器锁），而且 dispatch 等待 GPU 返回 token 数量时在 CPU 上忙等。进入 C++ 并不会自动释放 GIL——这些调用持锁期间，同进程里负责 Mooncake Transfer 的 Python 线程拿不到 GIL，传输任务的调度和提交被拖延，本该重叠执行的传输和计算变成了串行。
佐证来自源码对照：同一版本的 internode_dispatch（节点间路径）已经显式释放 GIL，注释写明就是为了不阻塞其他线程的 KV Transfer。修复是在节点内路径的 C++ 执行区间释放 GIL，让传输线程及时推进。修复后同样测试条件下，Prefill + KV Transfer 与 Prefill 单独跑的差距降到 1% 以内。
这个案例对任何做"Python 编排 + C++/CUDA 计算"混合系统的团队都有参考价值：底层传输机制支持异步，不代表高层提交不被阻塞；异步能不能兑现，取决于整条调用链的锁行为。
案例三：优化骨架库与 1.71 倍 kernel 提速
kernel 优化要回答两个问题：怎么判断优化有效，去哪找优化方向。Z.ai 的做法是让 Infra Agent 从 SGLang、Flash Linear Attention、DeepGEMM 等项目的手写 kernel 里提炼优化技术，连同适用条件一起沉淀成"优化骨架"（optimization skeleton）——每条骨架包含适用条件、变换方法、资源约束和验证证据。遇到新 kernel，智能体从骨架起步，用 profiling 和分层测试重新评估 tiling、访存和资源分配；验证有效的改动连同适用条件回流骨架库。
一个 KDA Decode kernel 的演进过程被完整记录：引入 ReplaySSM（用计算换显存）使执行时间从 v0 到 v1 首次上升；智能体的除法优化把 v1 执行时间降了 9.6%；收到"计算是主要瓶颈"的反馈后，智能体发现原实现沿 V 维度切分导致同样的 FP32 归一化和门控计算被重复执行四次，于是把这些 tile 合并进单个线程块、共享中间结果驻留寄存器、用一次 warp 级归约取代逐 tile 重复计算，以牺牲部分并行度为代价从源头消除冗余计算，相对 v2 提速 1.71 倍。
三个案例合起来看，Feedback 的价值不在数量而在能否回答当前问题：海量非结构化日志会淹没关键信号，覆盖不全的 profiling 会把归因带偏，微基准上的收益未必兑现为端到端收益。智能体的工程能力，一部分取决于模型本身，另一部分取决于反馈环境能不能把它每次假设的验证成本压到最低。
边界划在哪里
博客对 RSI 的态度同样明确。Z.ai 明确写了"我们还没有达到递归自我改进"：选择目标、设定边界、评估风险，仍然由人负责，并且"我们相信人类应该在很长一段时间内守住这条线"。在这套 Infra Agent 工作流里，工程师保留的三项职责是：定义优化目标与系统约束、搭建智能体可以直接使用的反馈环境、审查涉及系统架构、异步并发和生产风险的关键改动。智能体的每一步产出仍要过正确性、稳定性和端到端性能三道验收。
换句话说，这更接近"智能体干出了过去需要一个基础设施团队干数周的活"的证据，而不是"模型自己训练自己"的证据。工程判断的方向盘仍在人手里，智能体接手的是假设检验和代码实现这个中间环节。但博客结尾的数字摆在那里：两周，三倍吞吐，10 万张加速卡。这个闭环跑通的次数越多，人和智能体的分工边界就越清晰，也可能越模糊。
对关注国产算力栈的团队，这篇博客还有一层实用信息：Flash Linear Attention 的 PR #1180 数值修复、DeepEP 节点内 dispatch/combine 的 GIL 问题、以及"并行策略到 kernel 映射"的验证方法，都是可以直接复查自己系统的检查项。对关注 AI 工程化的团队，dense feedback 三原则是比"自动优化"更可复用的东西——它描述的对象是环境设计：一套让智能体工程产出可以验收的机制，模型能力只是其中一环。
来源：