2025 年 10 月，GLM 团队开始研究如何强化模型的网络安全能力，当时的推理很直白：网络安全是编码能力的自然延伸，能理解复杂代码的模型应该也能理解它的漏洞。他们没有预料到后面会发生什么。不到一年，安全合作伙伴用 GLM 在真实代码库里发现了数千个漏洞，模型开始重塑网络安全这个领域，同时也带来了此前不存在的风险，团队不得不为此设计一套可信访问计划。
但真正让团队震动的不是这件事，而是另一个更根本的转变：GLM 越来越经常地在帮忙构建 AI 本身。
他们观察到模型完成了一项此前需要一支资深基础设施工程师团队数周才能完成的任务。而当意识到这项工作会直接改变下一代模型的训练方式时，他们的判断变得更强了——我们的继任者就是我们自己正在创造的 AI 系统。
一、先看清事件本身
博客标题是「通往递归自我改进」，但内容其实是一份工程复盘。复盘的对象是一个具体的集群和一个具体的模型：
- 规模：超过 10 万张国产 AI 加速器
- 模型：GLM-5.3-Flash，新架构
- 要求：1M token 上下文窗口 + 多模态请求
- 状态：所有生产推理都跑在这套自建系统上，不是实验环境
- 耗时：从初始模型适配到生产就绪，不到两周
- 结果：端到端吞吐相对初始基线提升约 3 倍
还有一个数据点值得单列：GLM-5.3-Flash 曾以匿名模型名 Ox-Alpha 在 OpenCode 和 OpenRouter 上测试，上线一周内成为两个平台使用量最高的模型，六天处理了超过 62 万亿 token。
62 万亿除以六天，大约是每天 10 万亿 token。这个量级意味着这套自建栈不是「能跑通」，而是「能承受真实流量」。这是整件事最有分量的地方——它把「AI 帮忙写基础设施代码」从演示推进到了生产系统。
二、为什么这件事比「AI 写代码」更重
「AI 写代码」已经不算新闻。但这里有三层递进，每一层都比上一层更难。
第一层，对象是自己。 智能体优化的不是业务代码，而是运行自己的推理系统的 kernel 和并行策略。改动带来的收益会直接反映到它自己的服务性能上，这是一个可测量的闭环。
第二层，反馈是物理的。 业务代码的正确性来自测试通过与否；推理系统的正确性来自数值精度、吞吐、延迟这些物理量。后者更难验证，也更容易出现「看起来改对了但实际更慢」的情况。
第三层，约束是不可绕过的。 团队说得很直接：此前没有人以这个规模部署过国产加速器，生态不成熟、kernel 支持不完整、本该有文档的部分只能靠猜。这意味着不能走「照搬成熟方案再调参」的路线，每一个优化决策都要自己推导。
换句话说，这不是把一个已经存在的工作流交给 AI 做，而是在信息严重不足的条件下让 AI 参与开辟一条新路。
三、硬件约束决定了技术路线
理解优化栈之前，先理解约束：相对有限的内存容量与带宽，同时要支撑一个新架构、1M 上下文和多模态输入。
这三者叠加，压力全部落在同一处——显存。1M token 上下文意味着 KV cache 会大到无法整块放下；多模态意味着激活值和中间张量的形状更复杂；新架构可能带来非常规的注意力结构。而内存容量和带宽又都不宽裕。
所以整套优化围绕一个主题展开：用计算换带宽，用通信换显存。 博客的原话就是「aggressive memory optimizations，包括为换取带宽而牺牲计算、为换取设备显存而牺牲通信的自定义方法」。
四、优化栈拆解
最终成型的技术栈有五项，加上一项架构级改动：
| 技术 | 作用层面 | 解决什么 |
|---|---|---|
| 节点内张量并行（线性注意力与 LM Head） | 并行策略 | 把特定层切到节点内多卡，减少跨节点通信 |
| ReplaySSM | 状态空间模型 | 避免重复计算状态空间递归 |
| W8A8 量化 | 权重与激活 | 权重和激活都压到 8 位整数，降低带宽压力 |
| INT8/FP8/BF16 混合精度 cache 量化 | KV cache | 按敏感度分层压缩缓存，不牺牲数值稳定 |
| Layer Split | 层切分 | 让层跨设备分布，缓解单卡显存上限 |
| Encode-Prefill-Decode 分离 | 架构 | 三个阶段拆到不同资源池，各自用最合适的策略 |
其中值得展开两点。
混合精度 cache 量化是这套方案里最讲究的一处。KV cache 是长上下文推理的主要显存开销，但不同部分的数值敏感度并不相同。全压到 INT8 会伤精度，全留 BF16 会爆显存。分层使用 INT8、FP8、BF16，本质上是给缓存做了一次按敏感度分配位宽的调度。
EPD 分离架构是唯一的架构级改动。视觉编码、预填充、解码三阶段的资源画像差别极大：编码是密集计算，预填充同时吃算力和带宽，解码极度受带宽限制且并发请求数最多。混在同一条流水线上部署时，短板资源会拖住整条链路；拆开之后每段可以独立选择并行方式和批处理策略。
这六项叠加的效果是：端到端服务性能提升约 3 倍，硬件利用效率和单 token 成本达到与主流 NVIDIA GPU 相当的水平。
最后这句话的分量需要放在语境里看。它不是「性能提升了 3 倍」，而是在完全不同的硬件生态上，把单位 token 成本追平了行业主流水平。生态不成熟、kernel 不完整、文档靠猜，最终却要在成本这个硬指标上对标成熟生态——这才是这项工程真正的难度所在。
五、真正的瓶颈：反馈归因
整篇博客里，最值得反复读的是这一段判断。
团队说，随着过程推进，他们逐渐意识到 Infra Agent 的工程有效性不只取决于模型的代码生成与推理能力，更取决于系统能否持续提供有用的、可追溯到具体原因的反馈。
这个判断的推论才是关键：
代码库只提供静态上下文。推理系统里的数值差异、性能回退、未达标的优化目标，往往来自跨层的动态交互——kernel 实现、并行策略、通信行为、内存管理、服务编排。
即使智能体能够理解整个代码库，当它看到「数值精度测试失败」、「首 token 延迟上升 30%」、「输出吞吐下降 20%」这样的反馈时，它仍然无法判断：
- 是哪一层造成的
- 自己的当前假设为什么错
- 下一步应该测什么
端到端指标能告诉智能体结果变差了，但不能解释为什么。
这是一个非常精确的观察，也是很多「让 agent 优化性能」的尝试悄悄失败的地方。人们习惯把失败归因于模型不够聪明，于是去换更强的模型；但实际瓶颈在观测层——反馈的信息量不足以支撑假设检验。
博客把这个问题提炼成一个系统问题：如何把稀疏的端到端结果，转化成细粒度、可归因、能直接指导下一步行动的工程反馈？
这个提问方式比任何具体优化都更有迁移价值。
六、性能反馈闭环是怎么运转的
针对上述问题，团队实现的工作流是：
- 智能体从已有实现中提取优化经验，应用到运行自己推理的 kernel 上；
- 从骨架出发逐个组件调优；
- 用分层验证决定哪些改动值得保留；
- 用端到端性能确立这些改动的实际价值；
- 验证过的洞察回流到骨架库。
第 3 步和第 4 步的配合是精髓。分层验证负责过滤——单个 kernel 更快或数值更准，是局部证据；端到端性能负责裁决——局部改进叠加起来是否真的让系统更快。
如果没有第 4 步，局部优化的累积很容易变成全局退化。 这是性能工程里的老问题，只是现在做决策的主体换成了智能体。
第 5 步则解释了为什么这件事会加速：每一轮部署积累的经验，都会降低下一轮优化的工程量。 验证过的洞察进骨架库，下一轮不必从零推导。
这就构成了博客的核心论断：模型优化系统，系统运行模型。
七、离递归自我改进还有多远
团队自己划的边界很清楚：还没有到达 RSI。 选择目标、设定边界、评估风险仍然是人类的责任，而且他们认为人类应该在很长时间内继续守住这条线。
但数字也摆在那里：两周、三倍吞吐、10 万加速器。
这里有一个容易被忽略的区分。目前发生的事，是模型在改造运行自己的基础设施，而不是在设计自己的架构或训练数据配方。前者是后者的必要条件，但不是充分条件。一个能重写自己推理 kernel 的系统，距离一个能提出新注意力机制、设计预训练数据配比、判断哪些能力值得投入的系统，中间还隔着目标设定与价值判断这两道坎。
而这两道坎恰恰是人类目前最不愿意让渡的部分，博客也明确表示不该让渡。
所以更准确的定位是：这是 RSI 的第一块真实拼图，拼图的形状是「模型改造自己的运行时」，而不是「模型设计自己的继任者」。
八、三个可迁移的结论
抛开 RSI 这个宏大的叙事框架，这篇复盘对普通工程团队有三点直接可用的启示。
第一，反馈的粒度决定智能体的上限。 与其继续扩大喂给模型的代码上下文，不如投资可归因的观测能力。让「性能变差了」变成「第 12 层 kernel 的数值误差超阈值，怀疑与并行归约顺序相关」，前者的行动空间是零，后者的行动空间是具体的。很多时候不是模型不够强，是反馈里没有足够的信息供它推理。
第二，优化经验必须沉淀成资产。 验证过的改动回流到骨架库，这个动作把一次性调优变成了复利。没有这一步，每一轮优化都要从零开始，智能体的价值就只有单次任务的效率提升，而没有组织层面的积累。
第三，分层验证与端到端验证缺一不可。 只有分层验证会陷入局部最优，只有端到端验证则无法定位原因。前者回答「这个改动本身对不对」，后者回答「这个改动值不值得要」。
最后回到那个最朴素的观察。团队在博客开头承认，在 GLM-4.7 之前，他们内部用 GLM 写代码时还带着某种义务感——毕竟是自己造的东西。而到了 GLM-5.3，它已经成为团队不可或缺的日常编码伙伴。
从一个「因为是自己做的所以要支持」的工具，变成「没有它就干不下去」的基础设施，中间隔着的不是模型能力的某次跃变，而是一整套让模型能够持续获得可用反馈的工程体系。