GLM-5.3 驱动的 Infra Agent 已在10万张国产芯片集群上完成推理基础设施的自主适配与优化端到端吞吐提升至初始基线3倍其能基于稠密反馈Trace/Benchmark/测试自主提出假设、修改代码并验证呈现递归自我改进早期形态。AI 开始参与构建自身运行系统而非仅辅助人类开发安全能力从代码理解自然延伸至真实漏洞挖掘已发现数千个实际漏洞受信访问机制成为高能力模型落地的必要前提。适合AI系统工程师、大模型基础设施研发者、AI安全研究员阅读。日程已上线 95%10.22-24 #[QCon 上海站] 20大专题、100重磅议题集结上海交通大学、香港科技大学等知名高校教授及阿里、腾讯、字节、小红书、微软等头部企业技术专家围绕 Harness AI 时代的工程实践等相关议题展开分享点击了解详情智谱正在尝试把大模型推向一个更激进的阶段让 AI 参与创造下一代 AI。刚刚智谱创始人、首席科学家唐杰以及 GLM 团队发布长文披露GLM 已不再只是辅助工程师写代码而是开始直接参与自身推理基础设施的建设与优化。在 GLM-5.3-Flash 上线过程中由 GLM-5.3 驱动的 Infra Agent 在超过 10 万张国产芯片组成的集群上完成模型适配、系统诊断和性能优化不到两周将端到端吞吐提升至初始基线的 3 倍。更重要的是Agent 已能够根据测试、Trace、Benchmark 等“稠密反馈”自主提出假设、修改代码并验证结果使模型开始优化承载自身运行的系统。唐杰及 GLM 团队认为这还不是完整意义上的递归自我改进RSI但已经出现了早期形态AI 正从“帮助人类研发模型”走向“参与构建自己的继任者”。下面是分享全文以飨读者。在 GLM 的研发过程中模型时常会涌现出一些令我们惊喜、甚至让我们感到不安的能力。2025 年 10 月我们开始启动安全能力增强研究。当时的判断很朴素安全能力是代码能力的自然延伸能够读懂复杂代码的模型理应也能够理解代码中的漏洞。我们没有预料它此后的走向不到一年安全伙伴使用 GLM 在真实代码库中发现了数千个漏洞。模型开始改变网络安全的格局也带来了过去不曾存在的危险。为了让这种能力能够被负责任地使用我们不得不为它设计受信访问计划。最近一次感到震动的时刻来自一个更加根本的变化GLM 开始越来越多地参与构建人工智能本身。我们看到模型完成了一项过去需要一支资深 infra 团队数周才能完成的基础设施工作并意识到这项工作将直接改变下一代模型的训练方式我们更加确信我们的继任者正是我们亲手创造出来的 AI。坦白说在 GLM-4.7 之前我们内部用 GLM 写代码多少带着被迫的成分毕竟是自己的“亲儿子”。那时Coding 的 PMF 还未到来今天GLM-5.3 已经成为每个人每天离不开的 Coding 伙伴正一步步走向取代我们。如果这一趋势延续下去给足算力、给足时间它的终点是一个能够完全自主设计并训练出自己继任者的系统。这被称为递归自我改进Recursive Self-Improvement, RSI。尽管我们还没有走到那里但它的早期形态已经出现。这篇文章记录的正是其中一个早期案例。用稠密反馈驱动 Infra Agent 优化推理系统从让模型在新硬件上成功运行到构建一套能够稳定承载生产流量的高性能推理服务是一个庞大的系统工程。GLM-5.3-Flash 的上线同样经历了这一过程。在超过 10 万卡国产芯片组成的集群上从零搭建了一套完整的生产级推理服务GLM-5.3-Flash 的全部线上推理都运行在这套系统之上。这项工作并不容易。此前没人成功部署过如此大规模的国产卡集群面对芯片内存容量和带宽相对受限的挑战以及需要支持新结构的模型 1M 上下文窗口和多模态的请求生态不成熟算子不完备许多文档基本靠猜。最终这件事做成了做成它的不是一支团队而是 GLM-5.3 驱动的 Infra Agent。后面的故事大家都已经知道了GLM-5.3-Flash 以匿名模型 Ox-Alpha 在 OpenCode 与 OpenRouter 上接受真实调用检验。上线一周成为双平台调用量最大的模型6 天 token 调用量超过 62 万亿。这次我们实施了一系列激进的内存优化包括以算力换带宽、以通信换显存等定制化方案。最终形成的技术栈融合了多项关键技术针对线性注意力和 LM Head 的节点内张量并行、ReplaySSM、W8A8 量化、INT8/FP8/BF16 混合精度缓存量化以及 Layer Split 等。在此基础上我们进一步引入 Encode–Prefill–DecodeEPD分离式架构实现了端到端服务性能约 3 倍的提升硬件利用效率与单 Token 成本均达到主流 NVIDIA GPU 的相当水平。由于 Infra Agent 参与的反馈闭环贯穿了整个优化过程使 GLM-5.3-Flash 在不到两周的时间内完成了从模型适配到生产可用的跨越最终将端到端吞吐提升至初始基线的 3 倍。图 1 展示了 GLM-5.3-Flash 从首次运行到正式上线的性能演进路线。 图 1GLM-5.3 Flash 的性能演进。在这一过程中我们逐渐认识到决定 Infra Agent 工程效果的不只是模型自身的代码生成与推理能力更取决于系统能否持续为它提供有效、可归因的反馈。代码库只能提供静态上下文而推理系统中的精度异常、性能退化或者性能优化目标未达成预期往往来自算子实现、并行策略、通信行为、内存管理与服务调度等多个层面的动态交互。即使 Agent 能够理解整个代码库如果一次修改后得到的反馈仅仅是“精度测试未通过”“TTFT 增加 30%”或“输出吞吐下降 20%”它仍然难以判断问题出现在哪一层、当前假设为何不成立以及下一步应当验证什么。端到端指标可以告诉 Agent“结果变差了”却无法解释“为什么变差”。因此在增强 Agent 编写和修改代码能力的同时我们还需要解决一个更基础的系统问题如何将稀疏的端到端结果转化为细粒度、可归因且能够直接指导下一步行动的工程反馈这也是构建高效 Infra Agent 反馈闭环的关键。从端到端指标到可归因反馈在传统的推理系统优化中测试、日志、性能分析工具和微基准测试并不缺失但它们通常分散在不同工具和工程阶段中。经验丰富的工程师会根据一次压测的结果选择下一种观测手段逐步检查算子输出、执行时间线、通信事件或线程状态并将来自不同工具的信息联系起来。对于 Agent 而言如果这些观测和验证手段没有被组织成可直接访问、反复执行的工作流真正可用的反馈仍然是稀疏的。它可能知道吞吐没有达到目标却无法进一步判断是某个算子执行时间过长还是计算设备处于空闲等待状态是 KV Transfer 本身性能不足还是上层调度未能及时推进传输某项优化对哪些输入形状有效又会在哪些条件下发生退化单一的端到端指标无法回答这些问题。为此我们将正确性测试、运行日志、执行 Trace、运行时事件、微基准测试和端到端指标纳入 Agent 的迭代流程把完整的系统优化过程拆分为可以局部观测和验证的环节。算子级对比用于验证数值正确性微基准测试用于衡量特定输入条件下的局部性能执行 Trace 和运行时事件则用于呈现计算、等待与通信之间的时间关系。Agent 可以根据当前假设选择相应的验证手段而不必在每次修改后都等待完整服务部署和端到端压测。我们将这种组织方式称为“稠密反馈”。这里的“稠密”并不意味着向 Agent 输入尽可能多的日志和指标而是强调反馈具有三个特征。第一反馈需要足够局部。 它应尽可能关联到具体的引擎启动参数、修改的代码、算子、输入条件、线程、执行区间或代码路径帮助 Agent 缩小问题范围。例如相比“引入融合优化后模型精度下降”定位到某个具体请求在优化前后的输出差异更有助于 Agent 构造最小复现并分析原因。第二反馈需要能够低成本、及时地获得。 Agent 每提出一个假设、执行一次修改或构造一组对照实验都应有相应的验证入口。能够通过算子测试或局部微基准回答的问题无须每次都等待完整服务部署和端到端压测。更短的验证周期可以帮助 Agent 及时修正方向减少在无效假设上的投入。第三反馈需要支持客观验证。 修改是否正确、性能是否改善应由参考实现、测试结果和可比较的实验指标判断。运行信号可以帮助 Agent 提出候选原因但不能仅凭现象之间的相关性确认根因还需要通过控制变量的对照实验验证针对特定路径的修改是否产生了预期变化。这三项特征共同决定了反馈是否具有可行动性正确性反馈回答“是否算对”系统行为反馈定位“时间消耗在哪里”性能反馈则判断“哪个方案在什么条件下更好”。验证手段不必按照固定顺序执行而应与当前假设相匹配使每轮实验都能回答一个明确的问题。局部验证与端到端测试在这一过程中承担不同职责前者用于尽早排除错误或无效的修改筛选值得继续推进的候选方案后者则负责确认局部收益能否转化为真实服务收益以及方案是否会在实际工作负载下引入新的退化。围绕上述思路GLM-5.3 Flash 的上线过程形成了一套由工程师、Infra Agent 和实验环境共同组成的优化闭环工程师定义目标与系统边界Agent 负责分析、假设和修改实验环境提供分层、及时且可验证的反馈。三者共同将原本依赖工程师经验串联的诊断过程转化为 Agent 可以持续执行的工程工作流。 图 2基于稠密反馈的 Infra Agent 优化闭环。这一演进过程既包含直接推动吞吐增长的性能优化也包含不会立即体现为吞吐提升、却决定系统能否正确和稳定上线的缺陷修复。下面选取三个案例分别说明稠密反馈如何帮助 Agent 保证“算得正确”、解释“为什么跑不快”并进一步探索“怎样跑得更快”。正确性反馈Agent 知道模型是否算对推理性能优化必须以数值正确性为前提。对于 Agent验证从明确推理引擎实际执行了哪些计算开始。高层并行策略会改变算子的输入切分、执行路径和结果组合方式仅验证一个算子在非切分条件下的输出还不足以覆盖它在实际部署中的行为。为此我们建立了推理引擎并行策略到算子实现的映射将系统层面的部署配置转化为 Agent 可以逐项验证的算子任务。这一映射帮助 Agent 明确一种并行配置涉及哪些算子输入如何被切分以及哪些计算路径需要与非切分实现进行对照。在此基础上我们组织 Agent 对不同并行切分与非切分路径进行精度比较。对于同一组输入在对齐计算语义与输出位置后检查不同执行方式产生的结果是否满足数值误差要求。这样并行配置、算子路径和误差结果就被关联起来。测试一旦暴露偏差Agent 可以从对应的切分方式和计算路径继续检查而不必从整个模型重新开始定位。正是在这一算子验证过程中我们发现了 KDA 算子上下文并行Context ParallelCP路径的精度问题。CP 与非 CP 结果之间的偏差使检查重点落到了并行执行引入的状态传播与合并计算上。CP 切分需要合并不同上下文分片的状态其核心计算可以简化为M tl.dot(M_chunk, M) # 合并各分片的状态变换S_next tl.dot(M, S) H # 更新后续分片的初始状态原实现中tl.dot即使接收 FP32 输入也默认采用 TF32 计算以提高性能。较低的计算精度使误差在变换合并和状态更新中不断累积在长上下文下更加明显。修复方法将这两处计算显式指定input_precisiontf32x3通过三次 TF32 Tensor Core 运算组合出更高精度的结果在减轻累积误差的同时尽量保留 Tensor Core 的性能优势。这个案例中反馈环境的作用从问题出现之前就已经开始并行策略到算子的映射确定了验证对象切分与非切分路径的对照暴露了数值偏差计算精度分析解释了偏差来源回归测试则为修改提供了持续检验的依据。对 Agent 而言这条路径把系统层面的并行设计转化为可以执行和追踪的正确性任务。局部验证之后候选实现仍需回到目标部署完成模型级精度与服务性能的最终验收。相关精度修复已合并至 Flash Linear Attention 上游详见 PR #1180。系统行为反馈定位 KV Transfer 的并发瓶颈对于系统级性能问题明确的测试场景和性能约束是 Agent 判断异常、选择分析方向的起点。我们的推理优化工程师为 Agent 定义了单独 Prefill、Prefill KV Transfer、单独 Decode 等测试场景用来隔离不同执行阶段及其组合对性能的影响并为各场景设定验收条件。例如在相同 workload 下以单独 Prefill 为基准Prefill KV Transfer 的性能差距不应超过 5%。然而Agent 在测试中发现部分场景的性能差距超过了 20%。这个反馈将排查范围缩小到引入 KV Transfer 后的额外开销与并发交互。Agent 随后深入分析 KV Transfer 的时间线发现一个异常在这些场景中KV Transfer 的 Python 侧执行始终没有与 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 对 intranode 路径的判断。修复的关键是在相关 C 执行区间释放 GIL让 Mooncake Transfer 的 Python 线程能够及时推进任务。修复效果需要同时通过时间线与原有性能约束验证前者检查调度与传输是否获得了重叠执行的机会后者判断这一变化是否改善了实际服务性能。在相同测试条件下修复后的 Prefill KV Transfer 与单独 Prefill 的性能差距小于 1%。 图 3发现并修复 KV Transfer 并发瓶颈。这个案例中性能约束先把“没有达到预期”转化为明确的测试偏差时间线再将排查方向收敛到两个组件的并发关系最终由代码分析定位到 GIL 的持有范围。稠密反馈由此把端到端性能、跨层运行行为和具体实现连接起来为 Agent 的每一步分析提供依据。性能反馈让算子优化从存量经验出发并转化为系统性能提升算子优化需要解决两个问题如何判断一次优化是否有效以及优化方向从哪里来。首先算子性能必须放在推理引擎的真实执行环境中评价。例如计算 Kernel 占用更多资源可能缩短自身耗时却压缩 KV Transfer Kernel 的执行空间最终拖慢整体流水线。因此Agent 不仅需要关注算子耗时还要结合目标 Workload、资源约束、任务重叠和端到端收益建立正确的优化目标。其次大量优化经验隐含在 SGLang、Flash Linear Attention 和 DeepGEMM 等项目的手写 Kernel 中。Agent 需要从这些代码中提炼优化技巧及其适用条件形成面向当前算子和目标硬件的候选方案再通过实验验证其实际效果。已有代码提供优化方向系统反馈判断优化是否真正成立。我们让 GLM-5.3 驱动的 Infra Agent 从不同代码库、编程语言和硬件平台的存量 Kernel 中学习优化经验并通过增量与消融实验将其提炼为包含适用条件、变换方式、资源约束和验证证据的“优化骨架”。面对新算子Agent 以这些骨架为起点结合 Profiling 与分层测试重新确定分块、访存和资源分配策略验证通过的修改及其适用条件继续回流骨架库。工程师主要负责定义目标与约束并审核涉及数值语义、并发行为和线上风险的关键修改。 图 4典型 KDA Decode 算子从基础实现到生产版本的性能演进。图 4 展示了典型 KDA Decode 算子的性能演化过程。引入 ReplaySSM 以算换存导致算子执行时间第一次延长v1 相比 v0Agent 进行的除法优化将 v1 的执行时间缩短了 9.6%。进一步地在获得计算是关键瓶颈的反馈信息后Infra Agent 发现原实现沿 V 维度分块使相同的 FP32 归一化与门控计算被重复执行四次。它将这些分块合并到同一线程块提前批量计算并共享中间结果以牺牲部分并行度为代价从源头消除了重复计算获得了 1.71× 的性能提升。这个案例中GLM-5.3 驱动的算子 Agent 从存量实现中抽取优化经验再把这些经验用在承载自身推理的算子上它以骨架为起点逐项调优由分层验证判断每一步去留由端到端性能判断实际价值通过验证的经验回流骨架库。模型由此参与了自身推理系统的优化而每一次上线积累的经验又降低了下一次优化所需的工程师投入。让反馈驱动行动让实验验证假设三个案例共同说明反馈的价值不在于数量而在于能否帮助 Agent 回答当前问题。大量缺少结构的日志可能掩盖关键信号观测范围不完整的 Profiling 可能导致错误归因在 Microbenchmark 中成立的优化也未必能够转化为端到端收益。因此构建反馈环境不仅需要提供测试、日志和性能数据还需要明确每类观测能够支持什么判断、存在怎样的边界以及哪些结论必须通过进一步实验才能确认。工程师在这一过程中承担三项关键职责定义优化目标与系统约束构建 Agent 可以直接使用的反馈环境以及审核涉及系统架构、异步并发和线上风险的关键修改。在此基础上Agent 提出假设、实施修改并执行实验再根据反馈保留、修正或否定当前方案。正确性、稳定性与端到端性能共同构成最终的验收标准。回顾 GLM-5.3 Flash 的上线过程算子精度缺陷、跨越 Python 与 C 边界的并发问题以及关键算子的性能优化分别对应不同层次的工程挑战。借助局部测试、跨层观测与分层 Benchmark原本模糊的异常现象被逐步转化为可以验证的工程假设复杂的系统问题也被拆解为一系列可观测、可实验、可归因的迭代过程。正是在这样的反馈闭环中Agent 的代码与推理能力才真正转化为可验证的工程进展。由 GLM-5.3 驱动的 Infra Agent 参与推理基础设施的建设经过工程师与 Agent 共同优化的系统又反过来支撑 GLM-5.3 Flash 稳定地面向用户提供服务。模型优化系统系统承载模型。 这次实践表明真正缩短系统工程周期的不只是更强的模型能力更是一个能够让模型持续获得反馈、验证判断并修正行动的 Agent 工程闭环。当然我们还没有走到递归自我改进。选择目标、设定边界、判断风险仍然是人的工作而且我们认为在相当长的时间里这条线应当由人来守。但两周、三倍、十万卡这些数字告诉我们这条线不会因为我们希望它慢一点就慢下来。