唐杰、GLM团队长文披露智谱RSI最新进展：GLM-5.3已摸到门槛，“正一步步走向取代我们”

智谱正在尝试把大模型推向一个更激进的阶段：让 AI 参与创造下一代 AI。刚刚，智谱创始人、首席科学家唐杰以及GLM团队发布长文披露，GLM 已不再只是辅助工程师写代码，而是开始直接参与自身推理基础设施的建设与优化。在 GLM-5.3-Flash 上线过程中，由 GLM-5.3 驱动的 Infra Agent 在超过10万张国产芯片组成的集群上完成模型适配、系统诊断和性能优化，不到两周将端到端吞吐提升至初始基线的3倍。更重要的是，Agent 已能够根据测试、Trace、Benchmark 等“稠密反馈”自主提出假设、修改代码并验证结果，使模型开始优化承载自身运行的系统。唐杰及GLM团队认为，这还不是完整意义上的递归自我改进（RSI），但已经出现了早期形态：AI 正从“帮助人类研发模型”，走向“参与构建自己的继任者”。下面是分享全文，以飨读者。 在 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 构造最小复现并分析原因