文章摘要
GLM-5.3驱动的基础设施智能体，在十万张国产芯片组成的大规模集群上，从零搭建并优化GLM-5.3-Flash生产级推理系统，依托工程师搭建的分层稠密反馈闭环，不到两周将端到端吞吐提升至初始基线的3.2倍，形成“模型优化系统，系统承载模型”的模式，是递归自我改进的早期工程落地雏形，目前核心决策仍由人类主导，尚未实现完整的递归自我改进。

大语言模型正在从辅助工具进化为自主参与系统构建的核心角色，GLM系列模型的实践已经验证了这一趋势的可行性。

据行业观察，相关研发团队披露了一个递归自我改进（RSI）的早期生产落地案例：由GLM-5.3驱动的基础设施智能体，在超过10万张国产芯片组成的大规模集群上，从零搭建并优化了一套生产级推理服务系统。

这套系统从无到有完成了原本需要资深基础设施团队数周才能完成的工作，并且仅用不到两周时间，就将端到端吞吐提升至初始基线的3.2倍。

值得注意的是，这一成果并非简单的AI代码生成，而是覆盖了全链路的系统优化闭环：从算子精度校准、Python/C++跨层并发瓶颈排查，到Kernel层性能调优，智能体能够自主读取系统反馈、提出优化假设、修改代码并开展实验，再根据实验结果持续迭代优化。

举两个典型的优化成果：智能体成功定位了KV Transfer场景下由Python全局解释器锁（GIL）引发的并发阻塞问题，将Prefill+KV Transfer相较于单独Prefill的性能损失从20%以上压缩至1%以内；同时针对KDA Decode算子重新组织计算逻辑，实现了1.71倍的性能提升。

这形成了一个独特的正向闭环：GLM模型优化承载自身的推理系统，而经过优化后的系统，又能更好地支撑新一代GLM模型的运行。

相关技术负责人将这一模式总结为：模型优化系统，系统承载模型。

不过，这一实践距离真正的递归自我改进仍有距离：设定优化目标、划定系统边界、评估潜在风险，这些核心决策仍然由人类工程师主导，研发团队也明确表示目前尚未实现完整的递归自我改进能力。

但这一案例的价值正在于：它让递归自我改进不再是抽象的技术畅想，而是拥有了工程化的生产落地雏形。

在GLM的研发历程中，模型曾多次展现出超出预期的能力，甚至带来了一些值得警惕的变化。2025年10月，团队启动了模型的安全能力增强研究，最初的判断很朴素：具备代码理解能力的模型，自然也能识别代码中的安全漏洞。事实远超最初预期，不到一年时间，基于GLM的安全工具就在真实代码库中发现了数千个潜在漏洞，这不仅改变了网络安全的工作格局，也带来了全新的安全挑战。为了确保这类能力被负责任地使用，团队专门设计了受信访问机制。

而最近一次让团队感到震撼的变化，则是GLM开始深度参与人工智能自身的构建工作。智能体完成了原本需要资深基础设施团队数周才能完成的大规模集群部署工作，这一进展让团队意识到，这类工作将重塑下一代大模型的训练与部署模式，也让团队更加确信：我们的下一代继任者，正是由我们亲手创造的人工智能。

回顾GLM的代码工具化历程，在GLM-4.7版本之前，团队内部使用GLM编写代码更多是出于尝试的心态，彼时代码生成的产品市场契合度尚未成熟。而到了GLM-5.3版本，它已经成为所有研发人员日常依赖的代码助手，正在逐步替代传统的人工编码工作。如果这一趋势持续下去，在充足算力与时间的支撑下，系统最终将实现完全自主设计并训练自身的继任者，这一概念被称为递归自我改进（RSI）。虽然距离完整的RSI仍有差距，但早期的落地形态已经清晰呈现，本文记录的正是其中一个典型案例。

将大模型适配到全新硬件环境，并搭建起稳定承载生产流量的高性能推理服务，是一项复杂度极高的系统工程。GLM-5.3-Flash的上线过程正是如此：团队在超过10万张国产芯片组成的集群上，从零搭建了一套完整的生产级推理系统，所有GLM-5.3-Flash的线上推理请求都运行在这套系统中。

这项工作的难度远超预期：此前从未有过如此大规模的国产芯片集群部署案例，既要应对芯片内存容量与带宽受限的客观限制，还要支持模型100万上下文窗口与多模态请求的特性，同时面临生态不成熟、算子不完善、官方文档缺失的挑战。但最终，这套系统并非由单一团队完成，而是由GLM-5.3驱动的基础设施智能体主导搭建的。

GLM-5.3-Flash以匿名形式在主流代码与模型调用平台接受真实用户检验，上线仅一周就成为双平台调用量最高的模型，6天内的Token调用量超过62万亿。为了优化系统性能，团队采用了一系列激进的内存优化方案，包括以算力换带宽、以通信换显存的定制化策略。最终形成的技术栈融合了多项核心技术：针对线性注意力与LM Head的节点内张量并行、ReplaySSM、W8A8量化、INT8/FP8/BF16混合精度缓存量化，以及Layer Split等。在此基础上，团队进一步引入了Encode-Prefill-Decode（EPD分离式架构），实现了端到端服务性能约3倍的提升，硬件利用效率与单Token成本均达到主流NVIDIA GPU的水平。得益于基础设施智能体参与的全流程反馈闭环，GLM-5.3-Flash仅用不到两周时间就完成了从模型适配到生产可用的全流程，最终端到端吞吐提升至初始基线的3.2倍。

在整个优化过程中，团队逐渐意识到：决定基础设施智能体工程效果的，不仅是模型本身的代码生成与推理能力，更核心的是系统能否为智能体持续提供有效且可归因的反馈。代码库只能提供静态的上下文信息，但推理系统中的精度异常、性能退化或优化目标未达预期，往往来自算子实现、并行策略、通信行为、内存管理与服务调度等多个层面的动态交互。即便智能体能够理解完整的代码库，如果仅能获得“精度测试未通过”“延迟增加30%”或“吞吐下降20%”这类稀疏反馈，它依然无法定位问题的具体层级、分析假设不成立的原因，也无法确定下一步的验证方向。端到端指标只能告知智能体“结果不佳”，却无法解释“为何不佳”。因此，在提升智能体代码编写与修改能力的同时，团队需要解决一个更基础的系统问题：如何将稀疏的端到端结果，转化为细粒度、可归因且能够直接指导后续行动的工程反馈？这正是构建高效基础设施智能体反馈闭环的核心关键。

在传统的推理系统优化流程中，测试、日志、性能分析工具与微基准测试并不匮乏，但这些工具通常分散在不同的工程阶段与工具链中。经验丰富的工程师会根据一次压测结果选择后续的观测手段，逐步检查算子输出、执行时间线、通信事件或线程状态，并将不同工具的信息关联整合。但对于基础设施智能体而言，如果这些观测与验证手段没有被组织为可直接访问、可反复执行的标准化工作流，那么真正可用的反馈依然是稀疏的。智能体可能仅知晓吞吐未达目标，却无法进一步判断：

  • 是某个算子执行耗时过长，还是计算设备处于空闲等待状态？
  • 是KV Transfer本身性能不足，还是上层调度未能及时推进传输？
  • 某项优化适用于哪些输入形状，又会在哪些条件下出现性能退化？

单一的端到端指标无法回答这些复杂问题。

为此，团队将正确性测试、运行日志、执行追踪、运行时事件、微基准测试与端到端指标整合进智能体的迭代流程，将完整的系统优化过程拆解为可局部观测与验证的多个环节。算子级对比用于验证数值正确性，微基准测试用于衡量特定输入条件下的局部性能，执行追踪与运行时事件则用于呈现计算、等待与通信的时间关系。智能体可以根据当前优化假设选择对应的验证手段，无需在每次修改后都等待完整服务部署与端到端压测。团队将这种反馈组织模式称为“稠密反馈”。

这里的“稠密”并非指向智能体输入尽可能多的日志与指标，而是强调反馈需具备三个核心特征：

第一，反馈必须足够局部。它应尽可能关联到具体的引擎启动参数、修改的代码、算子、输入条件、线程、执行区间或代码路径，帮助智能体快速缩小问题排查范围。例如，相较于“引入融合优化后模型精度下降”的笼统反馈，定位到某一具体请求在优化前后的输出差异，更便于智能体构建最小复现场景并分析根因。

第二，反馈必须能够低成本、及时获取。智能体每提出一个假设、执行一次修改或构建一组对照实验，都需要有对应的验证入口。能够通过算子测试或局部微基准回答的问题，无需每次都等待完整服务部署与端到端压测。更短的验证周期可以帮助智能体及时修正优化方向，减少在无效假设上的资源消耗。

第三，反馈必须支持客观验证。修改是否正确、性能是否得到提升，应当由参考实现、测试结果与可对比的实验指标来判断。运行信号可以帮助智能体提出候选根因，但不能仅凭现象间的相关性确认问题，还需要通过控制变量的对照实验，验证针对特定路径的修改是否产生了预期效果。

这三项特征共同决定了反馈的可行动性：正确性反馈回答“是否计算正确”，系统行为反馈定位“时间消耗在何处”，性能反馈则判断“哪种方案在特定条件下效果更优”。验证手段无需按照固定顺序执行，而应与当前优化假设相匹配，让每一轮实验都能明确回答一个问题。局部验证与端到端测试承担着不同的职责：前者用于尽早排除错误或无效的修改，筛选出值得继续推进的候选方案；后者则用于确认局部优化收益能否转化为真实服务收益，以及方案是否会在实际工作负载中引入新的性能退化。

基于上述思路，GLM-5.3-Flash的上线过程形成了由工程师、基础设施智能体与实验环境共同组成的优化闭环：工程师负责定义优化目标与系统边界，智能体承担分析、假设与代码修改工作，实验环境则提供分层、及时且可验证的反馈。三者将原本依赖工程师经验串联的诊断流程，转化为智能体可以持续执行的标准化工程工作流。

这一优化过程既包含直接提升吞吐的性能优化，也包含无法立即体现为吞吐增长但对系统正确稳定上线至关重要的缺陷修复。接下来将通过三个典型案例，说明稠密反馈如何帮助智能体保障“计算正确”、排查“性能瓶颈根源”，并进一步探索“如何实现最优性能”。

推理性能优化必须以数值正确性为前提。对于智能体而言，验证工作需要从明确推理引擎实际执行的计算逻辑开始。高层并行策略会改变算子的输入切分、执行路径与结果组合方式，仅验证单个算子在非切分条件下的输出，无法覆盖其在实际部署中的真实行为。为此，团队建立了推理引擎并行策略到算子实现的映射，将系统层面的部署配置转化为智能体可逐项验证的算子任务。这一映射帮助智能体明确：某一并行配置涉及哪些算子、输入如何被切分，以及哪些计算路径需要与非切分实现进行对照。

在此基础上，团队组织智能体对不同并行切分与非切分路径进行精度对比：针对同一组输入，在对齐计算语义与输出位置后，检查不同执行方式产生的结果是否满足数值误差要求。通过这一方式，并行配置、算子路径与误差结果被关联起来。一旦测试暴露精度偏差，智能体可以从对应的切分方式与计算路径继续排查，无需从整个模型重新开始定位。

正是在这一算子验证流程中，团队发现了KDA算子上下文并行（CP）路径的精度问题。CP与非CP结果之间的偏差，将排查重点聚焦到并行执行引入的状态传播与合并计算上。上下文并行切分需要合并不同上下文分片的状态，其核心计算可以简化为：

M = tl.dot(M_chunk, M)    # 合并各分片的状态变换
S_next = tl.dot(M, S) + H  # 更新后续分片的初始状态

原实现中，tl.dot即便接收FP32输入，也默认采用TF32计算以提升性能。较低的计算精度导致误差在变换合并与状态更新过程中不断累积，在长上下文场景下问题尤为突出。修复方案为：将这两处计算显式指定input_precision="tf32x3"，通过三次TF32 Tensor Core运算组合出更高精度的结果，在减轻累积误差的同时，尽可能保留Tensor Core的性能优势。这一修复已合并至Flash Linear Attention上游仓库，相关PR编号为#1180。

在这个案例中，反馈环境的作用从问题出现前就已启动：并行策略到算子的映射确定了验证对象，切分与非切分路径的对照暴露了数值偏差，计算精度分析解释了偏差根源，回归测试则为修复提供了持续验证的依据。对智能体而言，这一路径将系统层面的并行设计转化为可执行与追踪的正确性验证任务。局部验证完成后，候选实现仍需回到目标部署环境，完成模型级精度与服务性能的最终验收。

对于系统级性能问题，明确的测试场景与性能约束，是智能体判断异常、选择分析方向的起点。推理优化工程师为智能体定义了单独Prefill、Prefill+KV Transfer、单独Decode等测试场景，用于隔离不同执行阶段及其组合对性能的影响，并为各场景设定了验收条件。例如，在相同工作负载下，以单独Prefill为基准，Prefill+KV Transfer的性能差距不应超过5%。但智能体在测试中发现，部分场景的性能差距超过了20%。

这一反馈将排查范围缩小到引入KV Transfer后的额外开销与并发交互问题。智能体随后深入分析KV Transfer的时间线，发现了一个异常现象：在这些场景中，KV Transfer的Python侧执行始终未与DeepEP dispatch/combine的调用区间重叠。这一现象促使智能体开始检查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。这进一步验证了智能体对intranode路径的判断。修复的核心是在相关C++执行区间释放GIL，让Mooncake Transfer的Python线程能够及时推进任务。修复效果需要同时通过时间线与原有性能约束验证：前者检查调度与传输是否获得了重叠执行的机会，后者判断这一变化是否改善了实际服务性能。在相同测试条件下，修复后的Prefill+KV Transfer与单独Prefill的性能差距小于1%。

这一案例中，性能约束先将“未达预期”转化为明确的测试偏差，时间线再将排查方向收敛到两个组件的并发关系，最终通过代码分析定位到GIL的持有范围问题。稠密反馈将端到端性能、跨层运行行为与具体实现关联起来，为智能体的每一步分析提供了可靠依据。

算子优化需要解决两个核心问题：如何判断一次优化是否有效，以及优化方向从何而来。首先，算子性能必须在推理引擎的真实执行环境中进行评估。例如，计算Kernel占用更多资源可能缩短自身耗时，但会压缩KV Transfer Kernel的执行空间，最终拖慢整体流水线。因此，智能体不仅需要关注算子耗时，还需要结合目标工作负载、资源约束、任务重叠与端到端收益，建立正确的优化目标。

其次，大量成熟的优化经验隐含在SGLang、Flash Linear Attention与DeepGEMM等项目的手写Kernel中。智能体需要从这些代码中提炼优化技巧及其适用条件，形成面向当前算子与目标硬件的候选方案，再通过实验验证其实际效果。已有代码提供优化方向，系统反馈则判断优化是否真正成立。团队让GLM-5.3驱动的基础设施智能体从不同代码库、编程语言与硬件平台的存量Kernel中学习优化经验，并通过增量与消融实验，将经验提炼为包含适用条件、变换方式、资源约束与验证证据的“优化骨架”。

面对新算子，智能体以这些骨架为起点，结合性能分析与分层测试重新确定分块、访存与资源分配策略；验证通过的修改及其适用条件会持续回流至优化骨架库。工程师主要负责定义优化目标与约束，并审核涉及数值语义、并发行为与线上风险的关键修改。

典型KDA Decode算子的性能演化过程显示：引入ReplaySSM以计算换内存，导致算子执行时间首次延长（v1相较v0）；随后智能体进行的除法优化将v1的执行时间缩短了9.6%。进一步地，在获得“计算为关键瓶颈”的反馈信息后，基础设施智能体发现原实现沿V维度分块，导致相同的FP32归一化与门控计算被重复执行四次。它将这些分块合并到同一线程块，提前批量计算并共享中间结果，以牺牲部分并行度为代价从源头消除了重复计算，最终实现了1.71倍的性能提升。

这一案例中，由GLM-5.3驱动的算子智能体从存量实现中抽取优化经验，再将这些经验应用到承载自身推理的算子上：它以优化骨架为起点逐项调优，通过分层验证判断每一步修改的去留，通过端到端性能判断实际价值，验证通过的经验则回流至优化骨架库。模型由此参与到自身推理系统的优化中，而每一次上线积累的经验，都能降低下一次优化所需的工程师投入。

三个典型案例共同说明：反馈的价值不在于数量多少，而在于能否帮助智能体回答当前面临的具体问题。大量缺乏结构化的日志可能掩盖关键信号，观测范围不完整的性能分析可能导致错误归因，在微基准测试中成立的优化也未必能转化为端到端的实际收益。因此，构建高效的反馈环境不仅需要提供测试、日志与性能数据，还需要明确每类观测手段能够支持何种判断、存在哪些边界，以及哪些结论必须通过进一步实验才能确认。

在这一过程中，工程师承担三项核心职责：定义优化目标与系统约束，搭建智能体可直接使用的标准化反馈环境，以及审核涉及系统架构、异步并发与线上风险的关键修改。在此基础上，智能体提出优化假设、实施代码修改并开展实验，再根据反馈结果保留、修正或否定当前方案。计算正确性、系统稳定性与端到端性能共同构成最终的验收标准。

回顾GLM-5.3-Flash的上线全过程，算子精度缺陷、Python/C++跨层并发问题与关键算子性能优化，分别对应了不同层次的工程挑战。借助局部测试、跨层观测与分层基准测试，原本模糊的异常现象被逐步转化为可验证的工程假设，复杂的系统问题也被拆解为一系列可观测、可实验、可归因的迭代流程。正是在这样的反馈闭环中，智能体的代码生成与推理能力才真正转化为可落地的工程进展。

由GLM-5.3驱动的基础设施智能体参与推理基础设施的搭建；经过工程师与智能体共同优化的系统，又反过来支撑GLM-5.3-Flash稳定为用户提供服务。正如之前总结的：模型优化系统，系统承载模型。这一实践证明，真正缩短系统工程周期的，不仅是更强的模型能力，更是一套能够让模型持续获取反馈、验证判断并修正行动的智能体工程闭环。

当然，目前距离真正的递归自我改进仍有不小的差距：设定优化目标、划定系统边界、评估潜在风险，这些核心决策依然需要人类工程师来完成，团队也认为在相当长的一段时间内，这一界限应当由人类来把控。但两周、3倍性能提升、10万张芯片集群这些具体的数据表明，这一演进的节奏不会因为我们的主观意愿而放缓。

（全文完）

以上内容不代表本平台立场，仅供读者参考