“两周”。清华大学教授、智谱创始人唐杰在最新博文中，用两个字概括了 GLM-5.3-Flash 一次基础设施升级的速度。
根据他的描述，从在国内加速器上首次运行，到承担全部生产流量，只用了两周，期间端到端吞吐量提升 3.2 倍 。
这一次，GLM-5.3-Flash 被部署在超过 10 万颗中国制造 AI 加速器组成的集群上，还要同时面对有限的内存和互连带宽、100 万 token 上下文窗口、多模态请求以及并不成熟的软件生态。
最终，Infra Agent 让系统端到端吞吐量达到初始基线的约 3 倍。
更有意思的是，GLM团队发现，Agent真正的瓶颈并不是“不会写代码”。
原文写道，“端到端指标只能告诉 Agent 结果变差了，却无法解释为什么。”
例如，当吞吐量下降 20%，Agent不知道究竟是哪一层出了问题，也不知道下一步应该测试什么。
于是团队建立了一套“密集反馈”系统，把正确性测试、运行日志、执行追踪、微基准和端到端指标组合起来，让 Agent持续获得局部、低成本、可验证的反馈。
这其中，三个案例尤其值得注意。
第一个，Agent发现 KDA 上下文并行路径存在精度漂移，随着长上下文增加而加剧，最终定位到 TF32 舍入误差累积，修复已经合并进 Flash Linear Attention 的 PR 。
第二个，KV Transfer 与 DeepEP 调度始终没有形成预期重叠。Agent一路追踪 Python/C++ 调用链，发现节点内路径没有释放 GIL。修复后，Prefill + KV Transfer 相比 Prefill-only 的性能差距从超过20%降至1%以内。
第三个，一个 Decode 内核因为分块方式，把相同的归一化和 gating 计算重复了 4 次。Agent重构后获得 1.71 倍加速。而它的优化思路，则来自阅读 SGLang、Flash Linear Attention、DeepGEMM 等项目后提炼出的“优化骨架”。
唐杰因此提出一个更值得讨论的问题，工程师的角色正在改变——从“解决问题的人”，变成“设计反馈的人”。
他称，这套真实基础设施上的分层反馈环境，本身可能成为训练下一代模型的重要“训练场”。
GLM团队表示，“我们还没有达到递归自我改进。”但最小的循环已经出现，即模型优化系统，系统服务模型。
以下为智谱团队发布的论文——
《迈向递归自我改进：GLM 如何构建自己的推理基础设施》
随着 GLM 的发展，我们有时会看到模型展现出令我们惊讶、甚至不安的能力。
2025 年 10 月，我们开始研究如何增强 GLM 的网络安全能力。当时的逻辑很直接：网络安全是编程能力的自然延伸。一个能够理解复杂代码的模型，也应该能够理解其中的漏洞。
但我们没有预料到接下来会发生什么。
不到一年时间，我们的安全合作伙伴使用 GLM 在真实代码库中发现了数千个漏洞。模型开始改变网络安全领域，同时也带来了此前并不存在的风险。
为了让这种能力能够被负责任地使用，我们不得不设计一套可信访问计划。
最近一次真正让我们感到震动的事情，则来自更加根本性的变化：GLM 正越来越多地参与 AI 本身的构建。
我们看到模型完成了一项基础设施任务。如果过去由人来完成，这项任务可能需要一支经验丰富的基础设施工程师团队花费数周时间。
当我们意识到，这项工作将直接改变下一代模型的训练方式时，我们更加确信：我们的继任者，就是我们正在亲手创造的 AI 系统。
坦率地说，在 GLM-4.7 之前，我们内部使用 GLM 编程多少带有一些“义务”成分。毕竟，这是我们自己创造的模型。
当时，GLM 在编程领域的产品市场匹配（Product-Market Fit）还没有真正到来。
而如今，GLM-5.3 已经成为团队每个人每天都离不开的编程伙伴，并且正在稳步走向“取代我们”。
如果这一趋势继续下去，在拥有足够算力和足够时间的情况下，其终点将是一个能够完全自主地设计并训练自己的下一代模型的系统。这就是所谓的“递归自我改进”（Recursive Self-Improvement，RSI）。
我们还没有达到那个阶段，但它的早期形态已经开始出现。
本文记录的就是这样一个早期案例。
从首次运行到生产服务
把一个模型从新硬件上的首次成功运行，变成能够稳定承载生产流量的高性能推理服务，是一项规模巨大的系统工程。
GLM-5.3-Flash 的上线经历了同样的过程。
我们从零开始，在一个由超过 10 万颗中国制造 AI 加速器组成的集群上，构建了一套完整的生产级推理服务。
目前，GLM-5.3-Flash 的全部生产推理流量，都运行在这套系统上。
这并不容易。
此前没有人在这样的规模上部署过中国制造的 AI 加速器集群。
我们面临相对有限的芯片内存容量和带宽，同时还必须支持全新的模型架构、100 万 token 上下文窗口以及多模态请求。
软件生态尚不成熟，内核支持并不完整，很多本应该有文档说明的内容，只能靠猜测。
最终，这项工作完成了。
而且完成它的并不只是一支基础设施工程师团队。
其中大量工作由一个由 GLM-5.3 驱动的 Infra Agent 完成。
接下来发生的事情已经广为人知。
GLM-5.3-Flash 曾以匿名模型名 Ox-Alpha 在 OpenCode 和 OpenRouter 上接受真实用户测试。
上线后一周内，它成为两个平台上使用量最高的模型。6 天内处理了超过 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 倍。
图 1：GLM-5.3-Flash 端到端吞吐量的演进。
从端到端指标到可归因反馈
在这一过程中，我们逐渐意识到，Infra Agent 的工程能力不仅取决于模型的代码生成和推理能力，更取决于一个问题：系统能否持续提供有用、并且能够追溯到具体原因的反馈。
代码库只能提供静态上下文。推理系统中的数值差异、性能下降和优化目标未达成，往往来自多个层级之间的动态交互，包括内核实现、并行策略、通信行为、内存管理、服务编排。
即使一个 Agent 能理解整个代码库，当修改之后得到这样的反馈：
“数值精度测试失败。”
“TTFT 增加了 30%。”
“输出吞吐量下降了 20%。”
它仍然很难判断究竟是哪一层出了问题？为什么当前假设是错的？下一步应该测试什么？
端到端指标只能告诉 Agent 结果变差了，却无法解释为什么。
因此，除了提升 Agent 写代码、改代码的能力，我们还必须解决一个更加基础的系统问题：如何把稀疏的端到端结果，转化为细粒度、可归因的工程反馈，并直接指导 Agent 的下一步行动？
这也是构建有效 Infra Agent 反馈循环的关键。
从端到端指标到“密集反馈”
传统推理系统优化并不缺少测试、日志、性能分析工具和微基准测试。
但这些工具通常分散在不同的软件和工程阶段。
经验丰富的工程师会利用负载测试结果决定下一步观察什么，然后逐步检查内核输出、执行时间线、通信事件或线程状态，并把不同工具中的信息联系起来。
但对 Agent 来说，如果这些观察和验证方法没有被组织成可以直接调用、重复执行的工作流，那么它真正能够利用的反馈仍然非常有限。
它可能知道吞吐量没有达到目标，却不知道是某个特定内核运行太慢？还是计算设备处于空闲状态？是 KV Transfer 本身太慢？还是更高层的调度没有及时推进传输？某项优化究竟在哪些输入形状下有效？又在哪些条件下出现性能倒退？
单一端到端指标无法回答这些问题。
因此，我们把正确性测试、运行日志、执行追踪、运行时事件、微基准测试以及端到端指标全部纳入 Agent 的迭代工作流。
整个系统优化过程被拆分成一系列能够局部观察、局部验证的步骤。内核级比较用于验证数值正确性。
微基准测试用于测量特定输入条件下的局部性能。
执行追踪和运行时事件则揭示计算、等待和通信之间的时间关系。
这样，Agent 可以根据当前假设选择合适的验证方法，而不必每修改一次代码，都等待完整服务部署和端到端负载测试。
我们称这种方法为“密集反馈”（dense feedback）。
这里的“密集”，并不是指给 Agent 尽可能多的日志和指标。
它强调三个特征。
第一，反馈必须足够局部化。
它应该尽可能与具体的引擎启动参数、代码修改、内核、输入条件、线程、执行时间段或者代码路径绑定，从而帮助 Agent 缩小问题范围。
例如，与其告诉 Agent“融合优化之后模型精度下降了。”不如直接指出某个具体请求在修改前后的输出差异。
后者能够更好地帮助 Agent 建立最小复现，并分析问题原因。
第二，反馈必须便宜且及时。
每当 Agent 提出一个假设、进行一次修改或者设计一组受控实验，都应该有相应的方法验证。
可以通过内核测试或局部微基准回答的问题，不应该每次都要求完整部署服务、进行端到端负载测试。
更短的验证周期能够让 Agent 及时纠正方向，并减少在错误假设上浪费的时间。
第三，反馈必须支持客观验证。
一个修改是否正确、性能是否提高，应当由参考实现、测试结果和可比较的实验指标决定。
运行时信号可以帮助 Agent 找到潜在原因，但单纯的相关性并不能证明根因。
仍然需要受控实验来验证，对某个具体路径进行修改是否产生了预期效果。
这三个特征共同决定了反馈是否真正具有可执行性。
正确性反馈回答“计算正确吗？”系统行为反馈回答：“时间花在哪里？”性能反馈回答：“哪个方案更好？在什么条件下更好？”
验证方法不需要遵循固定顺序，而应该与当前假设匹配，让每次实验都回答一个具体问题。
局部验证和端到端测试在这个过程中承担不同角色。
前者尽早淘汰错误或无效的修改，并找出值得继续研究的方案。
后者则确认局部收益是否真正转化为服务性能提升，以及在真实负载下是否产生新的回归。
基于这些原则，GLM-5.3-Flash 的上线建立了一套由工程师、Infra Agent 和实验环境共同组成的优化循环。
工程师定义目标和系统边界。Agent 负责分析、提出假设以及修改代码。实验环境提供分层、及时、可验证的反馈。
三者共同把过去依赖工程师经验连接起来的诊断过程，变成了 Agent 可以持续执行的工程工作流。
图 2：围绕密集反馈构建的 Infra Agent 优化循环。
正确性反馈：帮助 Agent 判断模型是否正确计算
推理性能优化必须建立在数值正确性之上。对于 Agent 而言，验证首先要明确推理引擎究竟执行了哪些计算。
高层并行策略会改变内核输入如何分割、执行哪些路径，以及最终如何组合结果。
因此，只在没有分区的条件下测试一个内核的输出，并不足以覆盖真实部署环境中的行为。
为了解决这个问题，我们建立了从推理引擎并行策略到内核实现的映射。
这样，可以把系统级部署配置转换成 Agent 能够单独验证的内核级任务。
Agent 可以确定某种并行配置涉及哪些内核、输入如何被分割，以及哪些计算路径需要与未分区实现进行比较。
在此基础上，我们让 Agent 比较不同分区和未分区执行路径之间的数值精度。
对于相同输入，在统一计算语义和输出位置之后，检查不同执行方法的结果是否满足数值误差容忍范围。
这把并行配置、内核路径和实际观察到的错误连接起来。
一旦测试发现差异，Agent 就可以继续调查对应的分区方案和计算路径，而不是重新从整个模型层面开始排查。
正是在这一内核验证过程中，我们发现了 KDA 内核 Context Parallelism（CP）路径中的一个数值精度问题。
CP 与非 CP 结果之间的差异，把调查方向指向了并行执行过程中新增的状态传播和合并计算。
CP 分区需要合并来自不同上下文分片的状态，其核心计算可以简化为：
原始实现中，即使输入为 FP32，tl.dot 默认仍采用 TF32 计算，以换取更高性能。
这种较低的计算精度导致状态变换合并和状态更新过程中误差不断累积，而且随着上下文长度增加，问题更加明显。
解决方法是对两个操作显式设置：
input_precision="tf32x3"这种方法结合三个 TF32 Tensor Core 操作产生更高精度的结果，在尽可能保留 Tensor Core 性能优势的同时，降低累积误差。
在这个案例中，反馈环境甚至在问题暴露之前就已经发挥作用。
并行策略到内核的映射定义了需要测试什么。
分区与未分区路径的比较暴露出数值差异。
计算精度分析解释了问题来源。回归测试则持续验证修复结果。
对于 Agent 而言，这套工作流把系统级并行设计转化成了可执行、可追踪的正确性任务。
完成局部验证后，候选实现仍必须返回目标部署环境，最终接受模型级精度和服务性能测试。
这些数值精度修复已经被合并到上游 Flash Linear Attention。
具体细节见 PR 。
系统行为反馈：找到 KV Transfer 并发瓶颈
对于系统级性能问题，明确的测试场景和性能约束可以给 Agent 一个发现异常、选择分析方向的起点。
我们的推理优化工程师为 Agent 定义了不同测试场景，包括单独 Prefill；Prefill + KV Transfer；单独 Decode。
目的是隔离不同执行阶段及其组合所产生的性能影响。同时，他们也为每个场景设置了验收标准。
例如，在相同工作负载下，Prefill + KV Transfer 与 Prefill-only 基线之间的性能差距不应超过 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-only 之间的性能差距从超过 20% 降到了 1% 以下。
图 3：发现并修复 KV Transfer 并发瓶颈。
这个案例中，性能约束首先把“没有达到预期”转化成一个明确的测试差异。
随后，时间线把调查范围缩小到两个组件之间的并发问题。最终，代码分析精确定位到 GIL 被持有的范围。
密集反馈把端到端性能、跨层运行时行为和一个具体实现细节连接起来，为 Agent 的每一步分析提供证据。
性能反馈：把已有内核优化经验转化成系统级收益
内核优化需要回答两个问题：如何判断一项优化是否有效？以及，从哪里找到值得尝试的优化方向？
首先，内核性能必须在推理引擎实际运行环境中进行评估。
例如，给一个计算内核更多资源，可能缩短它自身的执行时间，却同时减少分配给 KV Transfer 内核的资源，最终反而拖慢整个流水线。
因此，Agent 不能只关注单个内核的延迟。
它必须结合目标工作负载、资源约束、任务重叠情况以及端到端收益，确定正确的优化目标。
第二，大量优化经验已经被写入 SGLang、Flash Linear Attention 和 DeepGEMM 等项目中的手写内核。
Agent 需要从这些代码中提取优化技术及其适用条件，针对当前内核和目标硬件提出候选方案，并通过实验验证实际效果。
现有代码提供优化方向。系统反馈则决定这些优化在实际运行中是否成立。
我们让由 GLM-5.3 驱动的 Infra Agent 从不同代码库、编程语言和硬件平台中的现有内核学习优化技术。
通过逐步实验和消融实验，它把这些技术提炼成所谓的：“优化骨架”（optimization skeletons）。
其中包含适用条件；转换方法；资源约束；验证证据。
面对新的内核时，Agent 从这些骨架出发，再通过性能分析和分层测试重新评估 tiling、内存访问和资源分配策略。
经过验证的修改及其适用条件，又会被反馈回“优化骨架”库。
工程师主要负责定义目标和约束，并审查涉及数值语义、并发行为和生产风险的关键修改。
图 4：一个代表性 KDA Decode 内核从基线实现到生产版本的性能变化。
引入 ReplaySSM，用计算换内存之后，内核执行时间首先从 v0 增加到 v1。
随后，Agent 的 division 优化让 v1 的执行时间降低了 9.6%。
接下来，在收到“计算是主要瓶颈”的反馈后，Infra Agent 发现，原始实现沿 V 维度进行 tiling，导致相同的 FP32 normalization 和 gating 计算被重复执行了 4 次。
Agent 将这些 tile 合并进一个 thread block，让共享的中间结果留在寄存器中，并用一次 warp-level reduction 替代每个 tile 中重复执行的计算。
牺牲一部分并行性后，它从源头消除了重复计算。
最终，相比 v2 实现，取得了：1.71 倍加速。
在这个案例中，由 GLM-5.3 驱动的 Infra Agent 从已有实现中提取优化经验，并将其应用到自己运行推理的内核中。
它从优化骨架开始，对每个组件进行调整，通过分层验证决定哪些修改应该保留，再利用端到端性能确定这些修改的实际价值。
经过验证的经验随后继续进入优化骨架库。因此，模型开始参与优化自己的推理系统。
而随着每次部署积累经验，下一轮优化所需要的人类工程工作也随之减少。
让反馈驱动行动，让实验检验假设
这三个案例说明，反馈的价值并不取决于数量，而取决于它是否能够帮助 Agent 回答眼前的问题。
大量没有结构的日志可能掩盖关键的信号。覆盖不完整的性能分析可能导致错误归因。
一个在微基准测试中有效的优化，也不一定能够转化为端到端收益。
因此，构建反馈环境不仅仅是提供测试、日志和性能数据。
还必须明确每一种观察能够支持什么判断？
它有什么局限？哪些结论必须通过进一步实验确认？
在这一过程中，工程师承担三个关键职责：定义优化目标和系统约束；构建 Agent 能够直接使用的反馈环境；审查涉及系统架构、异步并发和生产风险的关键修改。
在这个框架中，Agent 提出假设、实施修改并运行实验，然后利用反馈保留、修改或者否定当前方案。
最终验收标准由正确性、稳定性和端到端性能共同决定。
回顾 GLM-5.3-Flash 的上线过程：内核中的数值精度 Bug、跨越 Python/C++ 边界的并发问题，以及关键内核的性能优化，分别代表了不同层级的工程挑战。
通过局部测试、跨层观察和分层基准测试，最初模糊的异常被逐渐转化成可以验证的工程假设。
复杂的系统问题被拆解成一系列可观察、可实验验证、结果可归因的迭代。
正是在这个反馈循环中，Agent 的代码能力和推理能力被转化成了可验证的工程进展。
由 GLM-5.3 驱动的 Infra Agent 帮助构建了推理基础设施。
这套由工程师和 Agent 共同优化的系统，又反过来让 GLM-5.3-Flash 能够可靠地为用户提供服务。
模型优化系统；系统运行模型。这项工作表明，要缩短系统工程周期，仅仅拥有更强的模型能力是不够的。
还需要一个 Agent 工程循环，让模型能够持续获得反馈、检验自己的判断，并修改自己的行动。
当然，我们还没有达到递归自我改进。选择目标、设定边界和评估风险，仍然是人类的责任。
我们认为，在很长一段时间里，人类都应该继续守住这条边界。
但是，两周、3 倍吞吐量、10 万颗加速器这些数字告诉我们：这一边界上的进展，并不会仅仅因为我们希望它放慢，就真的放慢。
热门跟贴