系列说明：这是「智谱 RSI 最新进展深度研究」的上篇，共三篇。上篇（本文）复盘事件并拆解技术；中篇 做 RSI 分级定位与七组数字的口径核查；下篇 谈边界、风险与给三类读者的行动清单。三篇合起来是一份完整报告，也可单独阅读。

从稠密反馈到完全自训练：智谱 RSI 最新进展深度研究（上）· 事件切片与技术解剖

2026 年 9 月 17 日，智谱创始人、首席科学家唐杰与 GLM 团队发布长文，披露 GLM-5.3 驱动的 Infra Agent 在超过 10 万张国产芯片的集群上，参与完成 GLM-5.3-Flash 整套推理服务的适配、诊断与优化，并在不到两周内把端到端吞吐提升到初始基线的 3 倍。长文里最刺眼的一句话是"我们的继任者，正是我们亲手创造出来的 AI"，最克制的一句话却出现在结尾——"我们还没有走到递归自我改进"。

上篇要回答的是技术问题：这件事到底做成了什么？ 答案不是发布会通稿里的数字，而是三个工程案例背后的因果链——以及它们共同构成的一套方法：把"结果变差了"变成"哪里变差了"的稠密反馈。

---

一、事件切片：一封长文、一条时间线、一个前置结论

1.1 长文里那个"震动的时刻"

唐杰与 GLM 团队的长文把三件事绑在了一起：一个产品（GLM-5.3-Flash）、一套方法论（稠密反馈驱动的 Infra Agent）、一个战略命题（递归自我改进）。

真正构成"事件"的是这段自述：

"我们看到模型完成了一项过去需要一支资深 infra 团队数周才能完成的基础设施工作，并意识到这项工作将直接改变下一代模型的训练方式。"

配套的可核查事实是：GLM-5.3-Flash 的全部线上推理，跑在一套由超过 10 万张国产芯片组成、此前无人成功部署过如此规模的集群上；面对国产芯片内存容量与带宽相对受限、生态不成熟、算子不完备（"许多文档基本靠猜"）的条件，从零搭建生产级推理服务的主力，是 GLM-5.3 驱动的 Infra Agent，而不是一支人类 infra 团队。

长文同时给了这次工作的"账"：以匿名模型 Ox-Alpha（中文社区称"牛来"）在 OpenCode 与 OpenRouter 上接受真实调用检验，上线一周成为双平台调用量最大的模型，6 天 token 调用量超过 62 万亿；端到端服务性能相比同一硬件上的初始基线提升约 3 倍。

1.2 一条必须放在一起看的时间线

把过去五个月的公开动作按时间铺开，会发现 9 月 17 日的长文不是孤立事件，而是一条持续了半年、且每一环都能对上号的链条：

日期	事件	与本系列的关系
2026-04-29	智谱官方博客《Scaling Pain：超大规模 Coding Agent 推理实践》	本次技术栈的前史：LayerSplit、PD 分离下的 KV Cache 竞态修复、HiCache 加载时序修复（SGLang PR #22811）
2026-07-11	唐杰内部信《巨浪已来》，提出"摸高计划"四大引擎	首次把"完全自我训练"写进公司战略
2026-08-26	GLM-5.3-Flash 上线并以 MIT 协议开源；同时认领匿名模型 Ox-Alpha	官方发布文首次出现"模型优化系统，系统承载模型"的表述
2026-08-27	fla-org/flash-linear-attention 仓库合入 PR #1180（[CP] use tf32x3 affine chain in kcp）	上篇案例一的上游物证，外部可验证
2026-08-31	2026 中报电话会，唐杰谈 GLM-6.0 方向是"自进化"	出现两个关键口径：infra agent 使算子开发周期缩短一半、单位 token 推理成本较年初下降 80%
2026-09-12/13	港交所公告：配售新 H 股 + 发行可转债，净募约 393 亿港元	约 60%（约 235 亿港元）投向下一代 GLM 与"完全自训练"体系及算力（详见中篇）
2026-09-17	唐杰与 GLM 团队长文	把前四步串成一个可讲述的 RSI 进度叙事

这条链条有个特点：每一步都留下了不同性质的证据——4 月是工程细节，7 月是战略文本，8 月是可下载的模型权重和可合并的上游代码，9 月是资金安排，最后才是叙事。对研究者来说这个顺序恰好是好事：叙事最晚出现，可验证物证先行。

1.3 结论前置

按 RSI 的分级标准，智谱这次做成的，是 L3 级（改进"改进方法"本身）中"基础设施自我优化"这一支的首个公开工程实证。它落在自进化侧（不触模型权重、可回滚、可审计），但闭环收敛在"AI 研发"上——所以它是 RSI 的前体，而不是 RSI 本身。它的核心技术贡献是"稠密反馈"这套反馈工程方法。（完整论证见中篇第三章）

---

二、技术解剖：三个案例，一台"反馈机器"

本节不按长文叙事顺序复述，而按"因果链完整度"重排：每个案例给出现象 → 归因 → 修复 → 验证四段，并在段末抽出可迁移的方法论。因为这次真正值得学的不是三个 bug，而是解决它们的流程。

2.1 稠密反馈：把"结果变差了"变成"哪里变差了"

当 Infra Agent 要优化一套推理系统时，它面对的不是"写代码难"，而是"改完之后不知道发生了什么"。长文的论证链条很干净：

• 代码库只能提供静态上下文；
• 推理系统里的精度异常、性能退化，往往来自算子实现、并行策略、通信行为、内存管理与服务调度多个层面的动态交互；
• 如果 Agent 能通读代码库，但每次修改后得到的反馈只是"精度测试未通过""TTFT 增加 30%""输出吞吐下降 20%"，它仍无法判断问题在哪一层、假设为何不成立、下一步该验证什么；
• 结论：端到端指标只能告诉 Agent「结果变差了」，无法解释「为什么变差」。

于是智谱把正确性测试、运行日志、执行 Trace、运行时事件、微基准测试和端到端指标全部接入 Agent 的迭代流程，并把它们组织成可反复调用的工作流。他们给这套组织方式起名"稠密反馈"，并明确"稠密"不是"日志多"，而是三个特征：

特征	含义	反面（他们明确否定的）
局部	反馈应关联到具体引擎启动参数、修改的代码、算子、输入条件、线程、执行区间或代码路径	"引入融合优化后模型精度下降"这类无法定位的说法
低成本、及时	每个假设、每次修改、每组对照实验都要有验证入口；能用算子测试或局部微基准回答的，不必等完整部署和端到端压测	每次改动都排一次全量压测
可客观验证	由参考实现、测试结果、可比较的实验指标判断，而不是靠现象之间的相关性	拿"运行信号"当根因结论

三类反馈各回答一个不同的问题：正确性反馈回答"是否算对"，系统行为反馈定位"时间消耗在哪里"，性能反馈判断"哪个方案在什么条件下更好"。

最容易忽略、却最重要的设计是局部验证与端到端测试的分工：前者负责尽早排除错误或无效修改、筛选值得推进的候选方案；后者负责确认局部收益能否转化为真实服务收益。两者不能互相替代——这正是很多团队"Agent 改了半天、线上没变"的根源。

2.2 案例一（正确性反馈）：TF32 造成的一次长上下文精度漂移

现象。 Agent 在做"推理引擎并行策略 → 算子实现"的映射时，对不同并行切分路径与非切分路径做逐项精度比对——同一组输入、对齐计算语义与输出位置后检查数值误差。测试暴露出 KDA（线性注意力）算子上下文并行（Context Parallel，CP）路径的结果与非 CP 路径存在偏差。

归因。 检查重点落到并行执行引入的状态传播与合并计算。CP 切分需要合并不同上下文分片的状态，核心计算可简化为：

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

根因极其朴素：tl.dot 即使接收 FP32 输入，也默认采用 TF32 计算以提高性能。TF32 尾数位更少，误差在这种"变换合并 + 状态更新"的链式结构里不断累积，长上下文下更明显。

修复。 将这两处计算显式指定 input_precision="tf32x3"——用三次 TF32 Tensor Core 运算组合出更高精度的结果，在减轻累积误差的同时尽量保留 Tensor Core 的性能优势。

验证与物证。 修复后回到目标部署完成模型级精度与服务性能的最终验收；相关修复已合并至 Flash Linear Attention 上游（PR #1180）。本系列已核实该 PR 真实存在：标题为 [CP] use tf32x3 affine chain in kcp，提交于 2026 年 8 月 27 日，描述明确写着 "avoid precision loss in long context"。

方法论抽取。 这个案例展示了"正确性反馈"如何从问题出现之前就开始起作用：并行策略到算子的映射先定义了验证对象，切分与非切分的对照暴露了偏差，计算精度分析解释了来源，回归测试锁住了结果。对 Agent 而言，这条路径把"系统层面的并行设计"翻译成了"可执行、可追踪的正确性任务"。

一句话记住这个坑：默认值是为性能写的，而正确性往往需要你显式地要一次。

2.3 案例二（系统行为反馈）：一个未释放的 GIL，压住了一次 KV 传输

这是三个案例里最有教学价值的一个：问题跨了 Python/C++ 边界、跨了两个组件，是典型的"端到端指标说不清"的场景。

现象。 推理优化工程师先为 Agent 定义了清晰的测试场景与验收条件：单独 Prefill、Prefill + KV Transfer、单独 Decode 三类场景，用来隔离不同执行阶段的影响。验收条件写明：相同 workload 下，以单独 Prefill 为基准，Prefill + KV Transfer 的性能差距不应超过 5%。 Agent 测出来的差距超过 20%。

注意这一步已经体现了稠密反馈的第一个特征（局部）：性能约束把"没有达到预期"转化成一个明确的测试偏差，而不是一句模糊的抱怨。

归因。 顺着 KV Transfer 的时间线往下看，Agent 发现异常模式：这些场景中 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 与后续计算重叠的机会——"底层传输即使具备异步执行能力，上层提交受阻也会让预期的并行无法充分发生"。

还有一处非常有说服力的同版本内对照：DeepEP v1.2.1 的 internode_dispatch 已经显式释放了 GIL，注释说明理由正是"避免 CPU 等待期间阻塞其他线程中的 KV Transfer"。同一份代码里一条路径做了、一条路径没做——这基本锁死了假设。

修复与验证。 在相关 C++ 执行区间释放 GIL，让 Mooncake Transfer 的 Python 线程能及时推进任务。验证走双轨：时间线确认调度与传输获得了重叠执行的机会；原有性能约束确认实际服务性能改善。结果是：相同测试条件下，Prefill + KV Transfer 与单独 Prefill 的性能差距从 >20% 收到 <1%，远优于 5% 的验收线。

方法论抽取。 这个案例完整展示了"稠密反馈把端到端性能、跨层运行行为和具体实现连接起来"的过程：性能约束（强信号）→ 时间线（跨组件观测）→ 代码分析（跨语言边界）→ 双轨验证。它也说明一件事：Agent 不是靠"读代码库"发现这个问题的，是靠"读时间线"发现的。 没有执行 Trace 这类运行时观测，这个 bug 极难被静态阅读发现。

2.4 案例三（性能反馈）：从存量 Kernel 里提炼"优化骨架"

第三个案例回答另一个问题：优化方向从哪里来？

长文先立了一个判断标准：算子性能必须放在推理引擎的真实执行环境中评价。理由是——计算 Kernel 占用更多资源可能缩短自身耗时，却压缩 KV Transfer Kernel 的执行空间，最终拖慢整体流水线。所以 Agent 不能只盯算子耗时，还要结合目标 workload、资源约束、任务重叠与端到端收益建立优化目标。翻译过来就是：局部最优的 kernel，可能是局部最差的系统。

方向来源指向存量知识：大量优化经验隐含在 SGLang、Flash Linear Attention、DeepGEMM 等项目的手写 Kernel 里。做法是让 GLM-5.3 驱动的 Infra Agent 从不同代码库、不同编程语言、不同硬件平台的存量 Kernel 中学习优化技巧，再通过增量与消融实验，提炼成包含适用条件、变换方式、资源约束、验证证据四要素的"优化骨架"。面对新算子，Agent 以骨架为起点，结合 Profiling 与分层测试重新确定分块、访存与资源分配策略；验证通过的修改及其适用条件，继续回流骨架库。

以下是长文给出的 KDA Decode 算子性能演进：

版本	变更	相对性能	关键信号
v0	门控与激活融合（基础实现）	1.00×	起点
v1	引入 ReplaySSM 支持（以算换存）	0.90×	第一次变慢——为省显存牺牲执行时间
v2	除法优化	执行时间 −9.6%	局部修复
v3	寄存器驻留 + warp 归约；V 维分块合并	1.71×	关键反馈："计算是关键瓶颈"

v2 → v3 的跃升过程值得完整引用：在拿到"计算是关键瓶颈"的反馈后，Agent 发现原实现沿 V 维度分块，导致相同的 FP32 归一化与门控计算被重复执行四次；于是把这些分块合并到同一线程块，提前批量计算并共享中间结果——以牺牲部分并行度为代价，从源头消除了重复计算，最终拿到 1.71×。

三点值得注意：

1. v1 的变慢是被允许的。 ReplaySSM 用算力换显存，短期指标恶化，但它是后续优化的必要前提。若评估只看"这一版有没有更快"，v1 会被回滚，v3 也就不会出现。反馈体系必须允许"有解释的退步"。
2. 1.71× 不是靠发现新算法，而是靠"发现重复计算"。 这是典型的"人类来不及手写"的优化空间：不是数学突破，是对执行结构的重新审视。
3. 产物是"骨架库"，不是"这一版 kernel"。 一条验证通过的优化会带着适用条件回流，成为下一次的起点——这才是复利的来源。

长文对工程角色的界定也随之明确：工程师主要负责定义目标与约束，并审核涉及数值语义、并发行为和线上风险的关键修改。 Agent 提出假设、实施修改、执行实验，再根据反馈保留、修正或否定方案。

2.5 三案例合起来看：一台"反馈机器"的四个零件

零件	作用	案例一（正确性）	案例二（系统行为）	案例三（性能）
验证入口	把模糊异常变成可执行的检查	并行策略 → 算子映射	场景化验收条件（≤5%）	分层微基准 + Profiling
归因链路	从端到端指标收敛到具体位置	切分/非切分对照 → 计算精度	时间线 → 并发关系 → GIL	"计算是瓶颈" → 分块结构
对照实验	排除相关性、锁定因果	数值误差比对	同版本 internode 路径作对照	增量 + 消融实验
回流机制	让经验变成资产	上游 PR + 回归测试	性能约束写回验收标准	优化骨架库

四个零件里，"回流机制"是决定这件事算不算"自我改进"的关键。没有回流，它只是一次成功的工程项目；有了回流，每一轮的经验才成为下一轮的起点。

2.6 放进同业坐标：这次站在哪一类工作里

系统（时间）	改的对象	验证信号	是否回流为可复用资产	与本次的关系
AlphaEvolve（2025）	代码/算子/调度/硬件	可执行测试 + 指标	进化搜索产生的种群	同为"模型优化承载自身的计算栈"，但本次多了跨语言并发与精度类问题
Darwin Gödel Machine（2025）	Agent 自身脚手架代码	SWE-bench 等执行反馈	自改代码	改的是 harness；且批评者指出改写者是一个被冻结的模型
Kevin-32B（2025）	生成 CUDA kernel 的策略（权重）	编译/正确性/性能	训练进权重	走"把算子品味 RL 化"路线；本次走"外部骨架库 + 反馈闭环"路线
DeepSeek 算子工程师自白（2026-09）	算子层人机分工	工程实践	开源 DeepGEMM/DeepEP	同一飞轮的职业视角；本次是厂商视角 + 财务口径
智谱 Infra Agent（2026-08/09）	推理服务栈 + 算子 + 并行 + 并发边界	分层测试/Trace/微基准/端到端	骨架库 + 上游 PR + 验收标准	覆盖面最宽，且明确要求"局部验证 → 端到端验收"双轨

这张表想说明的是：这次并不存在某个"前所未见"的单点技术突破。TF32 精度、GIL 释放、算子分块，单看都是工程师日常会碰的问题。它的特殊性在于把这些问题统一进了一个由模型驱动、可归因、可回流的闭环，并且真的跑完了从适配到上线的全程——创新点是工程组织方式，而不是算法。

---

上篇小结：三个案例合起来，说明这次的核心产出是一套方法而非一个指标。稠密反馈 = 局部 + 低成本 + 可客观验证；它把"结果变差"变成"哪里变差、为什么、下一步验证什么"。

继续阅读：中篇 用 L0–L5 阶梯与验证层级给这件事定级（结论：L3 命中、L4 未到），并逐条核查七个流传最广的数字（3 倍、1/40、10 万卡、62 万亿…）分别成立在什么条件下；下篇 谈五条边界线、五条给工程师的可复用做法与给管理者的五个评审问题。

站内延伸：什么是 RSI（递归自我改进）：定义、谱系与判定手册｜当 AI 开始写算子：RSI 的第一个现实闭环｜RSI 与 Agent 自进化：站内内容地图

本文为公开信息整理与工程逻辑分析，不构成投资建议；数据截至 2026 年 9 月 17 日。