Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure

发表时间: 2026-09 · Blog post by Z.ai (z.ai)

原文: https://z.ai/blog/glm-built-its-inference-infrastructure

主要贡献

随着GLM模型的不断发展，其展现出的能力逐渐从代码编写自然延伸至网络安全漏洞发现，甚至开始介入构建AI系统自身的基础设施。本文的核心目标是探讨并展示GLM-5.3如何作为一个Infra Agent，参与构建和优化其自身的推理系统（GLM-5.3-Flash），从而迈向递归自我改进（Recursive Self-Improvement, RSI）的早期形态。

本文的主要创新点与贡献包括：

1. 超大规模国产硬件部署：在一个包含超过10万张国产AI加速器的集群上，从零开始成功构建了完整的生产级推理服务，解决了芯片内存、带宽受限以及生态不成熟等系统工程挑战。
2. Infra Agent的深度参与：大部分系统级优化工作由基于GLM-5.3驱动的Infra Agent执行，在不到两周的时间内将端到端吞吐量提升了3倍，使硬件利用效率和每token成本达到主流NVIDIA GPU的水平。
3. “密集反馈”（Dense Feedback）机制的提出：为了解决单一端到端指标无法指导Agent进行归因分析的问题，提出并构建了包含局部性、低成本及时性、以及支持客观验证的密集反馈工作流，将复杂的系统问题拆解为Agent可执行、可验证的工程迭代步骤。

背景知识与设计原则

系统工程挑战：将模型从首次在新硬件上成功运行推进到能可靠处理生产流量的高性能推理服务是一项重大的系统工程任务。GLM-5.3-Flash的发布也经历了同样的路径。作者在一个包含超过10万张国产AI加速器的集群上从零开始构建了完整的生产级推理服务。GLM-5.3-Flash的所有生产推理均运行于此系统之上。

硬件限制与Agent介入：这项工作并不容易。此前无人在此规模下部署过国产加速器集群。团队面临芯片内存容量和带宽相对有限的问题，同时还需要支持新模型架构、1M token的上下文窗口以及多模态请求。由于生态系统不成熟、算子支持不完善，许多本应有文档说明的内容只能靠猜测。最终，这项工作得以完成，且并非仅由基础设施工程师团队独立完成，大部分工作是由基于GLM-5.3驱动的Infra Agent执行的。

上线后的表现：随后的情况大家已经很熟悉了。GLM-5.3-Flash以匿名模型名Ox-Alpha在OpenCode和OpenRouter上通过实际使用进行了测试。在发布不到一周的时间内，它成为了这两个平台上使用最多的模型，在六天内处理了超过62万亿个token。

激进的内存优化策略：团队实施了一系列激进的内存优化，包括用计算换取带宽、用通信换取设备内存的自定义方法。最终的技术栈结合了几个关键技术：用于线性注意力（linear attention）和LM Head的节点内张量并行（intra-node tensor parallelism）、ReplaySSM、W8A8量化、使用INT8/FP8/BF16的混合精度缓存量化，以及Layer Split。在此基础上，引入了编码-预填充-解码（Encode-Prefill-Decode, EPD）分离架构。这些优化共同将端到端服务性能提升了约3倍。硬件利用效率和每token成本均达到了与主流NVIDIA GPU相当的水平。

优化过程与性能演进：通过贯穿整个优化过程的Infra Agent反馈循环，GLM-5.3-Flash在不到两周的时间内从最初的模型适配达到了生产就绪状态，最终端到端吞吐量相对于初始基线提升了三倍。图1展示了GLM-5.3-Flash从首次成功运行到生产发布的性能轨迹。

静态代码与动态交互的局限性：在这个过程中，团队逐渐意识到Infra Agent的工程效率不仅取决于模型的代码生成和推理能力，更取决于系统能否持续提供可追溯到具体原因的有用反馈。代码库仅提供静态上下文。推理系统中的数值差异、性能回退和未达成的优化目标通常源于多个层面的动态交互，包括算子实现、并行策略、通信行为、内存管理和服务调度。

端到端指标的不足：即使Agent能够理解整个代码库，在代码修改后收到诸如“数值精度测试失败”、“TTFT增加30%”或“输出吞吐量下降20%”等反馈，仍然会让它难以确定是哪个层面出了问题、为什么当前的假设是错误的，以及接下来应该测试什么。端到端指标只能告诉Agent结果变差了，但无法解释原因。

构建可归因反馈的根本问题：因此，在提升Agent编写和修改代码能力的同时，需要解决一个更基础的系统问题：如何将稀疏的端到端结果转化为细粒度的、可归因的工程反馈，从而直接指导下一步行动？这也是为Infra Agent构建有效反馈循环的关键。

传统调试与Agent工作流的差异：传统的推理系统优化并不缺乏测试、日志、性能分析工具或微基准测试（microbenchmarks）。但这些通常散落在不同的工具和工程阶段中。经验丰富的工程师利用负载测试的结果来决定接下来观察什么，逐步检查算子输出、执行时间线、通信事件或线程状态，并将不同工具的信息连接起来。

Agent面临的稀疏反馈困境：对于Agent而言，除非这些观察和验证方法被组织成可直接访问、可重复的工作流，否则它实际能使用的反馈仍然是稀疏的。它可能知道吞吐量未达到目标，但依然无法确定：是某个算子耗时太长，还是计算设备处于空闲状态？是KV传输（KV Transfer）本身太慢，还是更高层的调度未能及时推进传输？某个优化在哪些输入形状下有效，又在什么条件下会发生回退？

密集反馈的引入：单一的端到端指标无法回答这些问题。因此，团队将正确性测试、运行时日志、执行轨迹、运行时事件、微基准测试和端到端指标整合到Agent的迭代工作流中，将完整的系统优化过程拆解为可以在本地观察和验证的步骤。算子级别的对比验证了数值正确性。微基准测试测量特定输入条件下的局部性能。执行轨迹和运行时事件揭示了计算、等待和通信之间的时间关系。Agent可以根据当前的假设选择合适的验证方法，而不是在每次修改后都等待完整的服务部署和端到端负载测试。

密集反馈的核心定义：团队将这种方法称为“密集反馈”（dense feedback）。这里的“密集”并不意味着给Agent提供尽可能多的日志和指标。相反，它强调三个特征。

反馈必须足够局部化：首先，反馈必须足够局部化。只要可能，反馈应与特定的引擎启动参数、代码更改、算子、输入条件、线程、执行区间或代码路径绑定，帮助Agent缩小问题范围。例如，与其报告“融合优化后模型精度下降”，指出特定请求在修改前后的输出差异能为Agent构建最小复现和分析原因提供更好的基础。

反馈必须获取成本低且及时：其次，反馈必须获取成本低且及时。每当Agent提出假设、进行修改或构建一组对照实验时，它应该有合适的方法进行验证。可以通过算子测试或本地微基准测试回答的问题，不应每次都要求进行完整的服务部署和端到端负载测试。更短的验证周期有助于Agent及时纠正路线，在无效假设上少费精力。

反馈必须支持客观验证：第三，反馈必须支持客观验证。更改是否正确以及性能是否提升，应由参考实现、测试结果和可比较的实验指标来决定。运行时信号可以帮助Agent识别可能的原因，但仅靠观察结果之间的相关性无法确定根本原因。仍然需要对照实验来验证对特定路径的更改是否产生了预期的效果。

反馈类型的协同作用：这三个特征共同决定了反馈是否具有可操作性。正确性反馈回答“计算是否正确？”。系统行为反馈识别“时间花在了哪里？”。性能反馈确定“哪种方法效果更好，在什么条件下更好？”。验证方法无需遵循固定的顺序。它们应与当前的假设相匹配，以便每次实验都能回答一个特定的问题。

局部验证与端到端测试的定位：局部验证和端到端测试在这个过程中扮演着不同的角色。前者尽早排除错误或无效的更改，并识别值得深入研究的候选方案。后者确认局部收益是否转化为实际的服务提升，以及提议的更改是否在实际工作负载下引入了新的回退。

构建基于密集反馈的优化循环：基于这些原则，GLM-5.3-Flash的发布建立了一个由工程师、Infra Agent和实验环境共同参与的优化循环。工程师定义目标和系统边界。Agent负责分析、提出假设和修改代码。实验环境提供分层、及时且可验证的反馈。它们共同将以前由工程师经验串联的诊断过程转化为Agent可以持续执行的工程工作流。

优化循环的实践意义：这一进展既包括直接提高吞吐量的性能优化，也包括虽然不能立即提高吞吐量但对正确、可靠地启动系统至关重要的bug修复。接下来的三个案例说明了密集反馈如何帮助Agent确保系统“计算正确”、解释“为什么运行不够快”，以及探索“如何让它运行得更快”。

方法细节

数值正确性验证的起点：推理性能优化必须建立在数值正确性的基础之上。对于Agent而言，验证始于确切建立推理引擎执行了哪些计算。高层并行策略改变了算子输入的划分方式、执行路径的选择以及结果的组合方式。仅仅在未划分的条件下测试算子的输出，不足以覆盖其在实际部署中的行为。

建立并行策略到算子的映射：为了解决这个问题，团队建立了从推理引擎并行策略到算子实现的映射，将系统级的部署配置转化为Agent可以单独验证的算子级任务。这种映射帮助Agent识别并行配置涉及哪些算子、输入如何划分，以及哪些计算路径需要与未划分的实现进行比较。

基于执行路径的数值比对：在此基础上，团队让Agent比较不同划分和未划分执行路径下的数值精度。对于相同的输入，在对齐计算语义和输出位置后，它会检查不同执行方式的结果是否满足数值误差容限。这就将并行配置、算子路径和观察到的误差联系了起来。一旦测试暴露出差异，Agent就可以继续调查相应的划分方案和计算路径，而不是在整个模型层面重新开始诊断。

KDA算子上下文并行的精度问题：正是在这个算子验证过程中，团队发现了KDA算子上下文并行（Context Parallelism, CP）路径中的一个数值精度问题。CP和非CP结果之间的差异将调查方向指向了并行执行引入的状态传播和合并计算。

CP划分的核心计算逻辑：CP划分需要合并来自不同上下文分片（shards）的状态。其核心计算可以简化如下：

M = tl.dot(M_chunk, M)     # 合并跨分片的状态变换
S_next = tl.dot(M, S) + H  # 更新下一个分片的初始状态

计算精度导致误差累积：在原始实现中，tl.dot默认使用TF32计算以追求更好的性能，即使其输入是FP32。这种较低的计算精度导致误差在变换合并和状态更新过程中不断累积，并且在长上下文中变得更加明显。

提升精度的修复方案：修复方案是明确将这两个操作设置为input_precision="tf32x3"。这结合了三个TF32 Tensor Core操作以产生更高精度的结果，在减少累积误差的同时，尽可能保留Tensor Core的性能优势。

反馈环境在问题排查中的作用：在这个案例中，反馈环境在问题浮出水面之前就开始发挥作用了。并行策略到算子的映射定义了需要测试的内容。划分和未划分路径之间的比较暴露了数值差异。对计算精度的分析解释了差异的来源。回归测试为验证更改提供了持续的基础。对于Agent来说，这个工作流将系统级并行设计转化为了可执行、可追溯的正确性任务。在本地验证之后，候选实现仍需返回到目标部署环境中，进行模型级精度和服务性能的最终验收测试。

开源社区贡献：这些数值精度修复已经合并到上游的Flash Linear Attention中。详情请参见【参考文献1，PR #1180+2025+Github+https://github.com/fla-org/flash-linear-attention/pull/1180】 。

定义测试场景与性能约束：对于系统级性能问题，明确定义的测试场景和性能约束为Agent识别异常和选择分析方向提供了起点。

隔离执行阶段以设定验收标准：团队的推理优化工程师为Agent定义了测试场景，包括仅预填充（Prefill alone）、预填充+KV传输（Prefill + KV Transfer）以及仅解码（Decode alone），以隔离不同执行阶段及其组合对性能的影响。他们还为每个场景设定了验收标准。例如，在相同工作负载下，预填充+KV传输与仅预填充基线之间的性能差距不应超过5%。

定位KV传输并发瓶颈：然而，Agent发现在某些场景下该性能差距超过了20%。这一反馈将调查范围缩小到了KV传输引入的额外开销和并发交互上。随后，Agent详细检查了KV传输的时间线，并发现了一个异常：在这些场景中，Python端的KV传输执行从未与DeepEP调度/组合（dispatch/combine）调用区间发生重叠。

深入分析Python/C++边界的并发机制：这一观察引导Agent调查DeepEP和Mooncake Transfer之间的并发性，顺着调用链追溯到Python/C++边界。在团队使用的DeepEP v1.2.1版本中，intranode_dispatch和intranode_combine都没有显式释放Python GIL（全局解释器锁）。此外，当调度需要接收到的token数量时，它会在CPU上等待GPU返回该信息。

GIL阻塞导致调度延迟：关键点在于，进入C++并不会自动释放GIL。当这些调用持有锁时，同一进程中负责Mooncake Transfer的Python线程无法及时获取GIL。因此，传输任务的调度和提交被延迟，减少了KV传输与后续计算重叠的机会。即使底层的传输机制支持异步执行，较高层的提交阻塞也会阻止预期的并行性充分实现。

源码对比印证诊断结果：源代码也提供了一个直接的对比：同一版本中的internode_dispatch已经显式释放了GIL，并附有注释解释这是为了避免在CPU等待时阻塞其他线程中的KV传输。这进一步支持了Agent对节点内路径的评估。

修复方案与双重验证：关键的修复是在相关的C++执行区间内释放GIL，允许Mooncake Transfer的Python线程及时推进其任务。该修复必须针对时间线和原始性能约束进行双重验证。前者检查调度和传输是否获得了与计算重叠的机会；后者确定这一更改是否提高了实际的服务性能。在相同的测试条件下，修复后预填充+KV传输与仅预填充之间的性能差距降至1%以下。

密集反馈连接分析步骤：在这个案例中，性能约束首先将“未达预期”转化为明确定义的测试差异。时间线随后将调查范围缩小到两个组件之间的并发性。最后，代码分析精确锁定了持有GIL的范围。密集反馈连接了端到端性能、跨层运行时行为以及具体的实现细节，为Agent分析的每一步提供了证据。

算子优化的两个核心问题：算子优化必须回答两个问题：如何确定优化是否有效，以及去哪里寻找有希望的优化方向。

在实际执行环境中评估算子性能：首先，必须在推理引擎的实际执行环境中评估算子性能。例如，给计算算子分配更多资源可能会缩短其自身的执行时间，但留给KV传输算子的资源就会减少，最终拖慢整体流水线。因此，Agent必须超越单个算子的延迟，在目标工作负载、资源约束、任务重叠和端到端收益的背景下确立正确的优化目标。

从现有代码库提取优化专业知识：其次，大量的优化专业知识蕴含在如SGLang、Flash Linear Attention和DeepGEMM等项目的手写算子中。Agent需要从这些代码中提取优化技术及其适用条件，为当前算子和目标硬件开发候选方案，并通过实验验证其实际效果。现有代码提供了优化方向；系统反馈决定了这些优化在实践中是否站得住脚。

构建与应用优化骨架：团队让由GLM-5.3驱动的Infra Agent从跨越不同代码库、编程语言和硬件平台的现有算子中学习优化技术。通过增量实验和消融实验，它将这些技术提炼为包含适用条件、转换方法、资源约束和验证证据的“优化骨架（optimization skeletons）”。对于一个新的算子，Agent从这些骨架出发，然后使用性能分析和分层测试来重新评估分块（tiling）、内存访问和资源分配策略。经过验证的更改及其适用条件会反馈到骨架库中。工程师主要负责定义目标和约束，并审查涉及数值语义、并发行为和生产风险的关键更改。

KDA Decode算子的性能演进过程：图4展示了一个代表性KDA Decode算子的性能演进。引入ReplaySSM以计算换取内存导致了算子执行时间的首次增加，从v0变到v1。随后，Agent的除法优化将v1的执行时间减少了9.6%。接着，在收到计算是主要瓶颈的反馈后，Infra Agent发现原始实现沿着V维度进行分块（tiled along the V dimension），导致相同的FP32归一化和门控计算被重复了四次。它将这些分块合并到一个单一的线程块（thread block）中，将共享的中间结果保留在寄存器中，并用单个warp级别的归约（warp-level reduction）替换了冗余的每分块计算。通过牺牲部分并行性，它从源头上消除了冗余计算，并实现了比v2快1.71倍的加速。

模型参与系统优化的闭环：在这个案例中，由GLM-5.3驱动的Infra Agent从现有实现中提取了优化专业知识，并将其应用于运行自身推理的算子中。从骨架出发，它对每个组件进行调优，使用分层验证来决定保留哪些更改，并依赖端到端性能来确立其实际价值。经过验证的见解随后流回骨架库。因此，模型参与了优化自身的推理系统，而每次部署积累的经验又减少了下一轮优化所需的工程努力。

实验环境

• 硬件配置：

  • 部署于包含超过100,000张国产AI加速器（Chinese-made AI accelerators）的集群上。
  • 硬件环境面临芯片内存容量和带宽相对有限的客观限制。

• 模型架构关键参数：

  • 部署模型为GLM-5.3-Flash。
  • 支持1M token的超长上下文窗口。
  • 支持多模态请求。

• 软件配置与依赖：

  • 并行与内存优化策略：节点内张量并行（intra-node tensor parallelism）、ReplaySSM、Layer Split、EPD（Encode-Prefill-Decode）分离架构。
  • 量化方案：W8A8量化，以及使用INT8/FP8/BF16的混合精度缓存量化。
  • 核心依赖库：DeepEP（版本v1.2.1）、Mooncake Transfer、Flash Linear Attention。
  • 算子开发环境：涉及Triton语言（如tl.dot函数）及TF32/FP32精度控制。

实验结果

1. 端到端服务性能提升：

   • 实验内容：在10万张国产加速器上，通过Infra Agent不断迭代应用内存优化、并行策略及EPD分离架构。
   • 实验结果：在不到两周的时间内，GLM-5.3-Flash的端到端吞吐量相对于初始基线提升了约3倍（引用图1）。
   • 分析结论：通过软硬件协同优化，硬件利用效率和每token成本达到了与主流NVIDIA GPU相当的水平。该模型在OpenCode和OpenRouter上发布六天内处理了超过62万亿个token，验证了系统在真实生产负载下的可靠性。

2. KV传输并发瓶颈修复实验：

   • 实验内容：对比“仅预填充（Prefill alone）”与“预填充+KV传输（Prefill + KV Transfer）”场景下的性能差异。
   • 实验结果：修复前（由于DeepEP C++调用未释放Python GIL导致阻塞），两者性能差距超过20%；通过在C++执行区间释放GIL修复后，在相同测试条件下，两者的性能差距降至1%以下（引用图3）。
   • 分析结论：解决了Python/C++跨语言边界的并发阻塞问题，使得调度和传输获得了与计算重叠的机会，大幅提升了实际服务性能。

3. KDA Decode算子性能演进实验：

   • 实验内容：Infra Agent利用“优化骨架”对KDA Decode算子进行多轮迭代优化。
   • 实验结果：引入ReplaySSM后执行时间增加（v0到v1）；除法优化使执行时间减少9.6%（v1到v2）；随后通过消除V维度分块带来的冗余计算并替换为warp级别归约，实现了相对于v2版本1.71倍的加速（引用图4）。
   • 分析结论：Agent能够有效地从现有开源库中提取优化策略，通过牺牲部分并行性从源头上消除冗余计算，最终将内核级优化转化为系统级的显著收益。

结论

本文展示了GLM-5.3作为一个Infra Agent，如何深度参与并主导了其自身推理系统（GLM-5.3-Flash）的基础设施构建与优化。研究表明，反馈的价值不在于数据量，而在于能否帮助Agent回答当前的问题。通过构建包含正确性、系统行为和性能三个维度的“密集反馈”环境，团队成功将模糊的系统异常转化为可测试的工程假设，使Agent能够在两周内完成传统需要资深工程师团队耗时数周的复杂系统工程任务。

在这个过程中，工程师的职责转变为定义优化目标、设定系统约束、构建反馈环境以及审查关键风险，而Agent则负责提出假设、实施更改和运行实验。最终实现了“模型优化系统，系统运行模型”的正向循环。

未来展望方面，尽管目前尚未完全达到完全自主的“递归自我改进（RSI）”阶段，选择目标、设定边界和评估风险仍需人类把控，但在10万张加速器上两周内实现三倍吞吐量提升的工程奇迹表明，AI系统参与构建其下一代继任者的进程正在不可逆转地加速推进。