GLM，已经开始参与构建GLM了。
清华大学计算机系教授、智谱创始人唐杰刚刚分享了一个他们内部观察到的RSI早期案例：
GLM-5.3驱动的Infra Agent，在超过10万张国产芯片组成的集群上，从零参与搭建并优化了一套生产级推理系统。
不到两周，端到端吞吐直接提升至初始基线的3.2倍。
关键是，这背后可不是简单的“AI写代码”。
从算子精度问题，到Python/C++跨层并发瓶颈，再到Kernel性能优化，Agent已经能自己读取系统反馈、提出假设、修改代码、跑实验，再根据结果继续迭代。
比如它定位出了KV Transfer场景中Python GIL导致的并发阻塞，把Prefill+KV Transfer相比单独Prefill超过20%的性能损失，压到了1%以内；还在KDA Decode算子上，通过重新组织计算拿到了1.71×的性能提升。
也就是说，一个有点“套娃”的闭环已经出现了：
GLM优化运行GLM的系统，而这套被优化后的系统，又继续承载新的GLM。
唐杰把它概括成一句话：
模型优化系统，系统承载模型。
当然，这距离真正意义上“AI完全自主设计并训练自己的继任者”还很远。
目标怎么定、边界怎么划、风险怎么判断，目前依然是人类工程师在负责。
智谱自己也明确强调，他们还没有实现RSI。
但这篇分享值得仔细看的原因正在这里：
RSI第一次有了非常工程化、甚至已经跑进生产环境的雏形，超越了“未来某一天AI会自己变强”的抽象讨论。
以下是唐杰分享的技术Blog原文，enjoy。
“最近一次感到震动的时刻”
在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–Decode（EPD分离式架构），实现了端到端服务性能约3倍的提升，硬件利用效率与单Token成本均达到主流NVIDIA GPU的相当水平。
由于Infra Agent参与的反馈闭环贯穿了整个优化过程，使GLM-5.3-Flash在不到两周的时间内完成了从模型适配到生产可用的跨越，最终将端到端吞吐提升至初始基线的3倍。
图1展示了GLM-5.3-Flash从首次运行到正式上线的性能演进路线。
△图1：GLM-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 Parallel，CP）路径的精度问题。
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的性能优势。
这个案例中，反馈环境的作用从问题出现之前就已经开始：
并行策略到算子的映射确定了验证对象，切分与非切分路径的对照暴露了数值偏差，计算精度分析解释了偏差来源，回归测试则为修改提供了持续检验的依据。
对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相比v0）；Agent进行的除法优化将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工程闭环。
当然，我们还没有走到递归自我改进。
选择目标、设定边界、判断风险，仍然是人的工作，而且我们认为，在相当长的时间里，这条线应当由人来守。
但两周、三倍、十万卡这些数字告诉我们，这条线不会因为我们希望它慢一点就慢下来。
（全文完）
参考链接：
https://x.com/jietang/status/2100482019088060470
热门跟贴