10 关键问题Q&A
-
Q：什么是 RSI 递归自改进？ A：指 AI 系统能够自主设计、训练下一代后继模型，本文仅展示早期雏形，尚未达成完全自主。 -
Q：GLM-5.3-Flash 部署在什么硬件上？ A：超过十万颗国产 AI 加速卡组成的集群。 -
Q：项目核心亮点成果是什么？ A：从适配到投产不足两周，端到端吞吐提升约 3 倍，成本与利用率对标主流 NVIDIA GPU。 -
Q：稠密反馈和普通端到端指标有什么区别？ A：端到端指标只告诉你结果好坏；稠密反馈提供局部、低成本、可核验信息，定位根因，指导下一步实验。 -
Q：稠密反馈的三大核心特征是什么？ A：局部可归因、获取低成本且及时、支持对照实验客观验证。 -
Q：KDA 算子精度问题是什么原因？怎么修好的？ A：tl.dot 默认 TF32 造成长上下文误差累积；显式设置 tf32x3，在保性能同时降低误差。 -
Q：KV 传输瓶颈根源是什么？ A：DeepEP 节点内分发合并没有释放 GIL 锁，阻塞 Mooncake 传输线程，无法和计算重叠。 -
Q：算子优化骨架是什么？ A：智能体从成熟开源算子提取优化方案、适用条件，形成可复用模板，持续迭代沉淀。 -
Q：工程师和 Infra Agent 如何分工？ A：工程师定目标、系统边界、评审架构与风险；Agent 做分析、写改代码、执行对照实验。 -
Q：文章对递归自改进的底线观点是什么？ A：当前远未实现完整 RSI；目标选择、边界划定、风险评估必须长期由人类把控。
相关链接： https://z.ai/ https://z.ai/model-api https://z.ai/subscribe?utm_source=blog&utm_medium=content&utm_campaign=glm5_launch
在研发 GLM 的过程中，模型时不时会展现出一些让我们意外、甚至感到不安的能力。
2025 年 10 月，我们启动相关研究，尝试增强它的网络安全能力。当时的逻辑很简单：网络安全本就是代码能力的自然延伸。一个能够读懂复杂代码的模型，理应也能看懂代码里的漏洞。我们并未预料到后续的发展。不到一年时间里，我们的安全合作方借助 GLM，在大量真实业务代码库中找出了数千个漏洞。模型开始重塑网络安全领域，但与此同时，也带来了此前不曾存在的风险。为了让这项能力得到负责任的使用，我们不得不设计一套可信访问机制。
最近一次震撼我们的突破，则来自一场更为底层的转变：GLM 正越来越多地参与到 AI 本身的构建工作中。我们亲眼见证，模型完成了一项基础设施任务 —— 放在过去，这需要一支经验丰富的基础设施工程师团队耗费数周时间。当我们意识到，这项工作会直接改变下一代模型的训练方式时，我们更加确信：未来接替我们的，正是我们亲手创造的这些 AI 系统。
坦白说，在 GLM-4.7 之前，我们内部用 GLM 写代码，多少带有一点 “自用扶持” 的意味 —— 毕竟它是我们自研的模型。那个阶段，它在代码场景还没有达到产品市场契合。如今，GLM-5.3 已经成为团队所有人日常开发中不可或缺的编程助手，并且稳步朝着替代人类工程师的方向演进。如果这个趋势持续下去，只要算力与时间充足，它的终极形态将是一套能够完全自主设计、训练后继模型的系统。这就是递归自改进（Recursive Self-Improvement，简称 RSI）。
我们距离这个目标尚且遥远，但它的早期形态已经初现端倪。本文记录的，正是这样一个早期实例。
把一个模型从在新硬件上第一次成功跑通，打磨成一套能够稳定承接线上流量的高性能推理服务，本身是一项浩大的系统工程。GLM-5.3-Flash 的上线，走的正是这条路径。我们在由超过十万颗国产 AI 加速卡组成的集群上，从零搭建了一套完备的生产级推理服务。GLM-5.3-Flash 所有线上推理负载，都运行在这套系统之上。
这件事难度极高。此前还没有人在这个规模部署国产加速卡集群。芯片显存容量与带宽相对有限，同时还要支撑全新模型架构、100 万 token 上下文窗口以及多模态请求。整个生态尚不成熟，算子内核支持不完善，大量本该有文档说明的内容，都只能靠摸索试错。最终项目顺利落地，但完成这项工作的，并不只有基础设施工程师团队；很大一部分工作，是由基于 GLM-5.3 驱动的基础设施智能体（Infra Agent）完成的。
后续的结果大家已经有所了解：GLM-5.3-Flash 以匿名模型代号 Ox-Alpha，在 OpenCode 和 OpenRouter 平台上通过真实流量完成测试。上线一周内，它成为这两个平台使用量最高的模型，六天内处理的 token 总量超过 62 万亿。
我们落地了一系列激进的内存优化方案，包含自研思路：以算力换带宽、以通信开销换设备显存。整套方案融合多项核心技术：线性注意力与 LM Head 的节点内张量并行、ReplaySSM、W8A8 量化、INT8/FP8/BF16 混合精度 KV 缓存量化、层拆分（Layer Split）。在此之上，我们引入了编码 - 预填充 - 解码（Encode-Prefill-Decode，EPD）解耦架构。这些优化叠加之后，端到端服务性能提升约 3 倍，硬件利用率与单 token 成本已经和主流 NVIDIA GPU 处于相近水平。
在整个优化流程中，基础设施智能体的反馈闭环持续运转，GLM-5.3-Flash 从模型初次适配到具备上线条件，耗时不到两周；最终端到端吞吐相比初始基线提升两倍。图 1 展示了 GLM-5.3-Flash 从首次成功运行到正式上线的性能变化曲线。
图 1：GLM-5.3-Flash 端到端吞吐演进过程
在这个过程里，我们慢慢意识到：基础设施智能体的工程能力，不只取决于模型的代码生成与推理能力，更取决于系统能否持续输出可定位根因、有价值的反馈。代码库只提供静态上下文。推理系统里的数值偏差、性能回退、优化目标不达标，往往来自多层组件的动态交互：算子内核实现、并行策略、通信行为、内存管理、服务调度编排，全都可能是诱因。
即便智能体能读懂整套代码库，当它修改代码之后，只收到 “数值精度测试失败”“首 token 输出时延（TTFT）上涨 30%”“输出吞吐下降 20%” 这类反馈，依然很难判断问题出在哪一层、自己的假设错在哪里、下一步该做什么测试。端到端指标只能告诉智能体结果变差了，却解释不了背后的原因。
因此，在提升智能体读写代码能力的同时，我们还要解决一个更底层的系统问题：如何把稀疏的端到端结果，转化为细粒度、可归因的工程反馈，直接指导下一步动作？这也是搭建有效的基础设施智能体反馈闭环的关键。
从端到端指标到可归因反馈
传统推理系统优化并不缺少测试、日志、性能剖析工具或者微基准测试。但这些工具通常分散在不同环节，互相割裂。资深工程师会根据压测结果，确定下一步观测方向，逐层排查算子输出、执行时序、通信事件、线程状态，把不同工具的信息串联起来。
对智能体而言，除非这些观测与验证手段被整理成一套可以直接调用、可复现的工作流，否则它能拿到的有效反馈依然十分匮乏。它可能知道吞吐没有达标，但依旧无法判断：
-
是某个算子耗时过长，还是算力设备处于空闲状态？ -
是 KV 数据传输本身太慢，还是上层调度没能及时发起传输？ -
这项优化在哪些输入形状下生效，又会在什么条件下引发性能回退？
单一的端到端指标回答不了这些问题。于是我们把正确性测试、运行日志、执行追踪、运行时事件、微基准测试和端到端指标，全部纳入智能体迭代工作流，把整套系统优化拆解成可以局部观测、局部验证的步骤。算子级对比校验数值正确性；微基准测试衡量特定输入条件下的局部性能；执行追踪与运行事件，展现计算、等待、通信之间的时序关系。智能体可以根据自己当前的假设，选择合适的验证方式，而不是每次改完代码都要完整部署服务、跑一轮端到端压测。
我们把这套思路称为稠密反馈（dense feedback）。这里的 “稠密”，不是一股脑给智能体灌入海量日志和指标，而是强调三大特征：
第一，反馈具备足够的局部性。尽可能绑定到具体的引擎启动参数、代码改动、算子、输入条件、线程、执行区间或者代码路径，帮智能体缩小问题范围。举个例子：与其只上报 “融合优化之后模型精度下降”，不如给出改动前后同一条请求的输出差异，方便智能体构造最小复现用例、分析根因。
第二，反馈获取成本低、时效快。每当智能体提出假设、修改代码、设计一组对照实验，都要有对应的验证方式。能用算子测试或者本地微基准回答的问题，不必每次都走完整服务部署和端到端压测。更短的验证周期，让智能体可以快速纠偏，减少在无效假设上浪费精力。
第三，反馈支持客观核验。一项改动是否正确、性能是否提升，要依靠参考实现、测试结果、可对比的实验指标判定。运行时信号可以帮智能体锁定可疑方向，但仅仅依靠观测到的相关性，不能确认根因，仍然需要对照实验验证：修改某一条路径，是否真的产生预期效果。
这三点共同决定反馈是否具备行动指导价值。正确性反馈回答：计算结果对不对；系统行为反馈定位：时间消耗在哪里；性能反馈判断：哪种方案效果更好、适用场景是什么。各类验证手段不需要固定顺序，要匹配当前假设，保证每一轮实验都对应一个明确问题。
局部验证和端到端测试各司其职：前者提前筛掉错误、无效改动，筛选值得深入优化的方案；后者确认局部收益能否转化为真实线上服务收益，同时验证改动会不会在真实负载下引入新的性能回退。
基于这套原则，GLM-5.3-Flash 的上线流程搭建起一套由工程师、基础设施智能体、实验环境共同组成的优化闭环：工程师定义目标与系统边界；智能体负责分析问题、提出假设、修改代码；实验环境提供分层、及时、可核验的反馈。这套体系，把过去依靠工程师经验串联起来的排查流程，变成智能体可以持续执行的工程工作流。
图 2：基于稠密反馈搭建的基础设施智能体优化闭环
这个过程里，既有直接提升吞吐的性能优化，也有不会立刻拉高吞吐、但对系统稳定可靠上线必不可少的缺陷修复。下面三个案例，分别展示稠密反馈如何帮助智能体确认 “模型计算是否正确”、解释 “为什么跑得不够快”，以及探索 “如何进一步提速”。
正确性反馈：让智能体判断模型计算是否正确
推理性能优化，必须建立在数值计算正确的基础之上。对智能体来说，验证工作首先要明确推理引擎到底在执行哪些计算。高层并行策略会改变算子输入的切分方式、执行路径以及结果合并逻辑。只在不分片的条件下测试算子输出，不足以覆盖真实部署场景下的行为。
为此，我们建立了一套并行策略到算子实现的映射关系，把系统层面的部署配置，转换成智能体可以单独核验的算子任务。借助这套映射，智能体可以明确：一套并行配置涉及哪些算子、输入如何分片、哪些计算路径需要和不分片的参考实现做对比。
在此基础上，我们让智能体对比不同分片 / 不分片执行路径下的数值精度。针对相同输入，对齐计算语义与输出位置之后，校验不同执行方式得到的结果是否在数值误差允许范围内。这套机制把并行配置、算子路径、观测误差关联在一起。一旦测试发现偏差，智能体可以顺着线索定位到对应的分片方案和计算路径，而不是从头在整个模型层面重新排查。
正是在算子核验过程中，我们发现 KDA 算子上下文并行（Context Parallelism，CP）路径存在数值精度问题。对比 CP 与非 CP 路径的输出差异，我们把排查方向锁定在并行执行带来的状态传递与合并计算上。
上下文并行分片，需要合并来自不同上下文分片的状态，核心计算可以简化为：
M = tl.dot(M_chunk, M) # 跨分片合并状态变换
S_next = tl.dot(M, S) + H # 更新下一分片的初始状态
原始实现里，即便输入是 FP32 精度，tl.dot默认使用 TF32 计算换取更高性能。更低的计算精度，导致变换合并、状态更新过程中误差不断累积，上下文越长，偏差越明显。
修复方案是给两处运算显式指定 input_precision="tf32x3"。该方式组合三次 TF32 张量核运算，输出更高精度结果，在尽可能保留张量核性能优势的同时，降低累积误差。
在这个案例中，反馈环境在问题暴露之前就已经发挥作用：并行策略到算子的映射，定义了测试范围；分片与非分片路径对比，暴露数值偏差；计算精度分析定位根源；回归测试持续验证修复效果。对智能体而言，这套工作流把系统层面的并行设计，转化成可执行、可追踪的正确性校验任务。局部验证通过之后，候选实现依旧要回到目标部署环境，完成模型精度与服务性能的最终验收测试。
这项数值精度修复已经合并进 Flash Linear Attention 上游仓库，详情见：https://github.com/fla-org/flash-linear-attention/pull/1180
系统行为反馈：定位 KV 传输并发瓶颈
针对系统级性能问题，清晰定义的测试场景与性能约束，给智能体提供定位异常、选择分析方向的起点。
负责推理优化的工程师为智能体定义了多组测试场景：仅预填充、预填充 + KV 传输、仅解码，用来隔离不同执行阶段及其组合带来的性能影响，同时为每个场景设定验收标准。例如：相同负载下，“预填充 + KV 传输” 相比纯预填充基线的性能降幅不能超过 5%。
但智能体发现，部分场景里性能差距超过 20%。这条反馈把排查范围锁定在 KV 传输引入的额外开销以及并发交互问题上。智能体随后仔细查看 KV 传输时序，发现一处异常：在这些场景中，Python 侧 KV 传输的执行，从来没有和 DeepEP 的分发 / 合并调用时间段形成重叠。
顺着这个观测结果，智能体开始调研 DeepEP 和 Mooncake 传输之间的并发逻辑，沿着调用链追溯到 Python/C++ 边界。我们当时使用的 DeepEP v1.2.1 版本中，intranode_dispatch和 intranode_combine都没有主动释放 Python 全局解释器锁（GIL）。除此之外，分发操作需要等待 GPU 返回已接收 token 数量，会在 CPU 侧阻塞等待。
关键点在于：进入 C++ 代码并不会自动释放 GIL。当这些调用持有锁时，同一进程里负责 Mooncake 传输的 Python 线程无法及时获取 GIL，传输任务的调度与提交被推迟，KV 传输难以和后续计算并行。即便底层传输本身支持异步执行，上层提交链路被阻塞，预期的并行效果也无法完全发挥。
代码本身也提供了对照依据：同版本里的 internode_dispatch已经主动释放 GIL，注释写明目的就是避免 CPU 等待时阻塞其他线程的 KV 传输。这进一步佐证了智能体对节点内路径问题的判断。
核心修复方案：在对应 C++ 执行区间释放 GIL，让 Mooncake 传输的 Python 线程可以及时推进任务。修复效果需要同时对照时序指标和原始性能约束校验：时序上看调度和传输是否获得与计算重叠的机会；性能指标上确认改动是否真实提升服务表现。相同测试条件下，修复之后 “预填充 + KV 传输” 对比纯预填充的性能差距降到 1% 以内。
图 3：发现并修复 KV 传输并发瓶颈
这个案例里，性能约束先把 “结果不达标” 转化为明确的测试偏差；时序观测把排查范围缩小到两个组件的并发冲突；最后代码分析锁定 GIL 的持有区间。稠密反馈把端到端性能、跨层运行时行为、具体实现细节串联起来，智能体分析的每一步都有证据支撑。
性能反馈：沉淀算子优化经验，转化为系统收益
算子优化要回答两个核心问题：怎么判断一项优化是否生效，以及去哪里寻找有潜力的优化方向。
首先，算子性能评估必须放在推理引擎真实运行环境里。举例来说，给计算算子分配更多资源，或许能缩短它自身耗时，但会挤占 KV 传输算子资源，最终拖慢整条流水线。因此智能体不能只看单个算子时延，要结合目标负载、资源约束、任务重叠关系、端到端收益确立优化目标。
其次，大量优化经验沉淀在 SGLang、Flash Linear Attention、DeepGEMM 等项目手写算子代码中。智能体需要从这些代码里提炼优化手段与适用条件，为当前算子、目标硬件生成候选方案，再通过实验验证实际效果。已有代码提供优化思路；系统反馈决定这套优化在真实环境下是否站得住脚。
我们让 GLM-5.3 驱动的基础设施智能体，学习不同代码仓库、编程语言、硬件平台上已有算子的优化技巧。通过增量实验与消融实验，把这些方法提炼成优化骨架，记录适用条件、变换方式、资源约束、验证结论。遇到新算子时，智能体从这些骨架出发，再结合性能剖析与分层测试，重新调整分块策略、访存方式、资源分配方案。验证通过的改动及其适用条件，会回流补充到骨架库。工程师主要负责定义目标与约束，同时审核涉及数值语义、并发逻辑、线上风险的关键改动。
图 4：一个典型 KDA 解码算子从基线版本到上线版本的性能演进
图 4 展示了一个典型 KDA 解码算子的性能变化。引入 ReplaySSM 以算力换显存，让算子耗时从 v0 到 v1 首次上升；智能体通过分块优化，把 v1 的耗时降低 9.6%；之后收到反馈，计算才是主要瓶颈，智能体发现原始实现在 V 维度上分块，导致相同的 FP32 归一化与门控计算重复执行四次。于是它把这些分块合并进单个线程块，把中间结果保存在寄存器中复用，用一次线程束规约替代每个分块里重复的计算。该方案牺牲了一部分并行度，从根源消除冗余计算，相比 v2 实现 1.71 倍提速。
在这个案例中，GLM-5.3 基础设施智能体从已有实现中汲取优化经验，应用到支撑自身推理的算子上。以优化骨架为起点，调优各个组件，依靠分层测试筛选有效改动，依靠端到端性能确认实际价值。验证得到的经验又回流到骨架库。模型就这样参与优化自身的推理系统；每一次部署积累的经验，都会降低下一轮优化所需的工程成本。
以反馈指引行动，用实验验证假设
以上三个案例共同说明：反馈的价值不在于数量多少，而在于能否帮智能体解答当下的问题。大量无结构日志会掩盖关键信号；覆盖不全的性能剖析会造成错误归因；微基准里跑通的优化，未必能带来端到端收益。搭建反馈环境，不只是提供测试、日志和性能数据，还要明确每一类观测结果能够支撑哪些判断、边界在哪里、哪些结论必须通过进一步实验确认。
工程师在这套流程里承担三项核心职责：定义优化目标与系统约束、搭建可供智能体直接使用的反馈环境、审核涉及系统架构、异步并发、线上风险的关键改动。在这个框架内，智能体提出假设、实现改动、开展实验，再依据反馈保留、修改或者舍弃方案。正确性、稳定性、端到端性能共同构成最终验收标准。
回看 GLM-5.3-Flash 的上线历程：算子数值精度缺陷、跨 Python/C++ 边界的并发问题、核心算子性能调优，分别对应不同层级的工程难题。借助局部测试、跨层观测、分层基准测试，原本模糊的异常现象一步步变成可验证的工程假设。复杂系统问题被拆解成一系列可观测、可实验、可定位结果的迭代步骤。正是在这个反馈闭环中，智能体的代码与推理能力，转化成可核验的工程进展。
由 GLM-5.3 驱动的基础设施智能体参与搭建推理基础设施；工程师与智能体协同优化得到的这套系统，反过来支撑 GLM-5.3-Flash 稳定对外提供服务。模型优化系统，系统运行模型。这项实践证明：想要缩短系统工程周期，不只是把模型能力做强就够，还需要一套智能体工程闭环，让模型持续获取反馈、检验判断、修正动作。
当然，我们距离递归自改进还很远。目标选定、边界设定、风险评估，这些工作依旧由人负责。我们相信，在很长一段时间里，人类都应当守住这条底线。但 “两周上线、吞吐提升两倍、十万颗加速卡集群” 这些数字说明：处在这条边界上的技术进展，不会因为我们主观意愿而放缓脚步。