Z.ai 称 GLM-5.3 参与搭建并优化 GLM-5.3-Flash 推理基础设施：不到两周投产，吞吐达初始基线三倍

2026 年 9 月 17 日，Z.ai 官方 X 账号并附博客链接，称 GLM-5.3 帮助构建并优化了服务 GLM-5.3-Flash 的推理基础设施。按帖中口径，系统从首次成功运行到生产就绪用时不到两周，端到端吞吐达到初始基线的三倍；关键在于「密集反馈」（dense feedback）——用本地正确性测试、执行轨迹、微基准和端到端测量做针对性假设检验，而不是只依赖总体性能指标。

给出更大的规模：这套服务从零搭建在超过 10 万张国产 AI 加速器组成的集群上，GLM-5.3-Flash 的全部生产推理都运行在这套系统上。周期、规模与性能数字均出自 Z.ai 单方表述，尚无独立核实。

相当一部分工程由 GLM-5.3 驱动的 Infra Agent 承担

据博客，这项工作并非只靠基础设施工程师团队：其中相当一部分由一个以 GLM-5.3 驱动的 Infra Agent（基础设施智能体）完成。Z.ai 称，此前没有人把国产加速器集群部署到这一规模；团队面对的是有限的芯片显存容量与带宽、新的模型架构、100 万 token（词元）上下文窗口和多模态请求。按其描述，生态不成熟、算子支持不全，不少本该写进文档的信息只能靠推测补齐。

Z.ai 给出的分工是：工程师定义优化目标与系统边界，Agent 负责分析、提出假设、修改代码，实验环境提供分层、及时、可验证的反馈。

端到端指标说不出「为什么」

博客解释了为什么要重做反馈这一层：代码库只提供静态上下文，而推理系统的数值偏差和性能回退，往往来自算子实现、并行策略、通信行为、内存管理、服务编排多层之间的动态交互。改动之后，哪怕 Agent 读得懂整个代码库，拿到的反馈若只是「数值精度测试失败」「TTFT（首 token 时间）增加 30%」「输出吞吐下降 20%」，仍然难以判断问题出在哪一层、当前假设错在哪、下一步该测什么。

Z.ai 把可用反馈定为三条标准：足够局部，尽量落到具体的启动参数、代码改动、算子、输入条件或执行区间上；获取廉价及时，能用算子测试或本地微基准回答的问题，不必每次都做完整部署加端到端压测；支持客观验证，改动对不对、性能有没有提升，以参照实现、测试结果和可比实验指标为准。本地验证负责尽早淘汰无效改动；端到端测试负责确认局部收益能否变成真实服务提升、有没有引入新回退。

三个案例：先证对，再谈快

性能优化以数值正确性为前提。团队为并行策略到算子实现建立映射，把系统级部署配置拆成可单独验证的算子级任务，让 Agent 逐一对比分区与非分区执行路径的数值精度。正是在这一步发现了 KDA 算子 Context Parallelism（上下文并行，CP）路径的精度问题：原实现中 tl.dot 在输入为 FP32 时默认用 TF32 计算，误差在状态合并与更新中不断累积，长上下文下更明显。修复是把两处运算显式设为 input_precision="tf32x3"，用三次 TF32 Tensor Core 运算合成更高精度的结果。对应修复已合入开源项目 Flash Linear Attention（），GitHub 显示合并时间为 2026 年 8 月 27 日。

并发问题出在 KV Transfer（KV 缓存传输）。工程师设定了仅 Prefill（预填充）、Prefill 加 KV Transfer、仅 Decode（解码）三类测试场景和验收标准，例如同样负载下 Prefill 加 KV Transfer 与仅 Prefill 的性能差距不应超过 5%。Agent 实测发现部分场景差距超过 20%，把排查收敛到 KV Transfer 的额外开销与并发交互；检查 KV Transfer 时间线后发现，这些场景里 Python 侧的传输执行从未与 DeepEP 的 dispatch/combine 调用区间重叠。沿调用链追到 Python/C++ 边界：所用 DeepEP v1.2.1 的 intranode_dispatch 与 intranode_combine 都没有显式释放 Python GIL（全局解释器锁），dispatch 需要知道收到了多少 token，而这要在 CPU 上等 GPU 返回；锁被持有期间，同进程负责 Mooncake Transfer 的 Python 线程拿不到 GIL，传输任务提交被推迟，KV Transfer 与后续计算错失并行机会。修复是在相关 C++ 执行区间释放 GIL，同条件下差距降到 1% 以内。博客还给出一个旁证：同一版本的 internode_dispatch 早已显式释放 GIL，注释写明就是为了不阻塞其他线程的 KV Transfer。

算子提速与「优化骨架」

算子层面的样本是一个 KDA Decode 算子：为省显存引入 ReplaySSM（以计算换显存）后，执行时间从 v0 到 v1 不降反升；Agent 随后的分块（division）优化把 v1 的执行时间压掉 9.6%；在得知计算是主要瓶颈后，Agent 发现原实现沿 V 维度分块，同样的 FP32 归一化与门控计算被重复四次，于是把分块合并进单个线程块、共享中间结果驻留寄存器、以一次 warp 级（线程束级）归约替代逐块冗余计算，相对 v2 提速 1.71 倍。

方法论上，Agent 从 SGLang、Flash Linear Attention、DeepGEMM 等项目的手写算子里提炼技巧，经增量与消融实验整理成带适用条件、变换方法、资源约束和验证证据的「优化骨架」；验证过的改动再回流骨架库。工程师定目标、定约束，并审查涉及数值语义、并发行为和生产风险的关键改动。

匿名上线 Ox-Alpha：六天处理 62 万亿 token 的真实流量

据博客，GLM-5.3-Flash 曾以匿名名 Ox-Alpha 在 OpenCode 和 OpenRouter 上接受真实使用检验，上线一周内成为两个平台上使用量最大的模型，六天处理超过 62 万亿 token。博客对「生产就绪」的定义，正是能可靠承载这样的生产流量。

这篇博客的标题是 Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure。Z.ai 把这次发布放进「递归自我改进」（Recursive Self-Improvement，RSI）的叙事里：模型参与搭建的系统承载着模型自身的运行，而这类基础设施工作会直接影响下一代模型的训练方式。博客同时回顾，在 GLM-4.7 之前，团队内部用自家模型写代码多少带着义务成分；如今按博客原话，GLM-5.3「正稳步走向取代我们」。

哪些能核对，哪些还是单方说法

可独立核对的是 PR #1180：GitHub 显示这条标题为 [CP] use tf32x3 affine chain in kcp 的 PR 确实于 2026 年 8 月 27 日合并进 Flash Linear Attention 主分支。不到两周的周期、三倍吞吐、超过 10 万张加速器、六天 62 万亿 token，以及「硬件利用率与单 token 成本达到主流 NVIDIA GPU 相当水平」的说法，目前都只有 Z.ai 自己的口径。

截至 9 月 20 日的平台数据显示，这条帖子获得 4,123 次点赞、479 次转发和约 103.6 万次浏览。博客结尾的话是：「当然，我们还没有到达递归自我改进。」而上述关键数字，迄今没有 Z.ai 之外的核对。