GLM 是怎么在自己修自己的基础设施的？一篇给非专业读者的科普解读

原文：z.ai/blog/glm-built-its-inference-infrastructure — Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure（智谱 GLM 团队，2026 年 9 月）

先讲一个故事

如果有人告诉你：「我们做了一个 AI 模型，这个 AI 现在反过来帮我们把自己跑得更快。」你第一反应可能是——真的假的？

这就是智谱（z.ai / Zhipu）在 2026 年 9 月 17 日公开博客里讲的事情。博客原文标题叫 “Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure”——翻译过来就是"走向递归自我改进：GLM 是如何自己搭建自己的推理基础设施的"。

我尽量用大白话把这篇博客讲清楚。它涉及的概念看似门槛很高，但其实只要类比到位，一个非技术读者也能在十几分钟内理解整件事。

一、GLM 是什么？

GLM 是智谱公司训练的一系列大型语言模型（你可以理解成"能读懂人话、写出像人话的 AI"）。它和 ChatGPT、文心一言、通义千问属于同一类产品，但走自己的技术路线（基于 GLM 架构，而不是 GPT 架构）。这次博客的主角是 GLM 系列里最新发布的一个"轻量但能打"的版本——GLM-5.3-Flash。

“Flash” 后缀在 AI 行业里有约定俗成的意思：跑得快、成本低、适合大规模服务。GLM-5.3-Flash 是 GLM-5.3 家族里"上生产用"的那个。

二、什么是"推理基础设施"？

一个 AI 模型要对外提供服务（比如你在 ChatGPT 对话框里发一句话），背后其实需要一整套"基础设施"在工作：

• 硬件：用来跑模型的芯片（GPU 或者国产 AI 加速器）。一个模型要被几亿人同时用，背后通常要堆成千上万颗芯片。
• 模型本身：就是那个装在芯片上的"AI 大脑"——几百 GB 大小的参数文件。
• 运行框架 / 内核（kernel）：让模型能在芯片上跑起来的底层软件——这一层负责"把模型塞进芯片"“让芯片之间传递数据"“让请求排队进入”。
• 服务调度系统：当几千万用户同时发请求时，谁先谁后、谁用哪颗芯片、资源怎么分配，全靠这套系统。
• 监控系统：随时看"哪里慢了"“哪里报错"“哪颗芯片过热”。

把这五件事加在一起，就是所谓"推理基础设施”。它的英文叫 inference infrastructure。“inference”（推理）指的是模型"读输入、产生输出"的那一步——区别于训练（training）阶段。

一个朴素的类比：把模型当成一位厨师，推理基础设施就是他的厨房、灶台、菜刀、传菜系统、和厨房监控摄像头的总和。再厉害的厨师，没有好厨房也出不了菜。

三、这次博客里发生了什么？

智谱的工程师想把 GLM-5.3-Flash 这个新模型推上线。一般的做法是：

1. 把模型装到现有的服务器集群上；
2. 用现成的推理框架（vLLM、SGLang、TensorRT-LLM 等）跑起来；
3. 调一调参数、监控一下，发布。

这次不一样。原因是——他们要部署的目标硬件，是 100,000+ 颗国产 AI 加速器。这个数字本身就是博客里反复强调的关键事实：他们"从零搭建了一套生产级推理服务，整套服务的所有生产推理流量，都跑在这套系统上”。

国产 AI 加速器：可以理解为"国产版的 GPU"。NVIDIA 的 H100、H200 是全球最主流的 AI 训练 / 推理芯片；国产阵营有华为昇腾、寒武纪、海光、燧原等公司的对应产品。

100,000 颗是什么概念？一颗 H100 大约人民币 20 万元，10 万颗就是 200 亿——这是真实的硬件投入。但更重要的是软件：这些国产加速器在 2026 年这个时间点上，生态还不成熟——打个比方，就像一台全新的车，没有 4S 店、没有驾校老师、连使用手册都残缺。

他们面对的挑战清单大致是这样：

• 内存和带宽相对有限：相对于 NVIDIA H100/H200 这些已经优化了很多代的产品，国产加速器"装得下但跑不快"
• 新模型架构：GLM-5.3-Flash 是新设计的，配套的内核要重写
• 1M token 上下文窗口：上下文窗口就是模型"一次能记住多少字"。1M token 大约相当于 100 万个汉字或 70 万个英文单词，是 GPT-4 的 8 倍以上
• 多模态：模型要能同时处理文字、图片、音频等多种输入
• 生态不成熟：kernel（底层加速代码）支持不完整，很多文档要靠"猜"

四、智谱怎么搞定的？

他们做了两层事情：一层是硬件适配层，让模型能高效跑在国产芯片上；另一层是架构优化层，让整个服务吞吐更高、延迟更低。

4.1 硬件适配：把模型"塞"进芯片并加速它

博客里提到了 6 个关键技术名词，我逐一用类比解释：

其中 Encode-Prefill-Decode（EPD）解耦架构 是这次特别强调的创新点。在传统推理系统里，这三件事是用同一批硬件流水线做的，常常互相"打架”——比如用户在等"解码"阶段一个字一个字吐出来的时候，预填阶段已经把下一波请求占满了资源。拆开之后可以独立扩容、各自优化。

4.2 性能结果

这套组合拳下来，博客里给出的两个关键数字：

• 端到端吞吐量（end-to-end throughput）提升约 3×——同样硬件下，每秒能服务的请求数变成原来的 3 倍
• 硬件利用率和单 token 成本对标主流 NVIDIA GPU——也就是说，国产加速器在跑 GLM-5.3-Flash 这件事上，已经"便宜到能跟 H100/H200 站同一起跑线”

第二个数字是更值得关注的——它意味着"国产芯片生态不成熟"这件事，在 z.ai 这个具体场景下被工程化地解决了。

4.3 上线结果

GLM-5.3-Flash 用了匿名模型名 “Ox-Alpha” 在 OpenCode 和 OpenRouter 两个公开平台上做实测。这两个平台是什么？简单说：

• OpenCode / OpenRouter：让开发者和普通用户能试用不同 AI 模型的"模型超市"。每个模型可以匿名或实名上架。

结果：6 天处理 62 万亿 tokens——这是什么概念？1 万亿大约是 100 万本中等厚度的小说的总字数；62 万亿 tokens 就是 6.2 亿本小说。一周之内就成为两个平台上使用率最高的模型。

五、这篇博客真正想讲的事情：AI 在修 AI 自己

到目前为止我讲的都是"工程奇迹"。但这篇博客真正想讲的是另一个故事——AI 模型正在帮 AI 模型修自己。

智谱工程师写了一段很有意思的话：

完成这项工作的不是基础设施工程师团队单独做的。很多工作是由 GLM-5.3 驱动的 Infra Agent 做的。

“Infra Agent"是什么？它本质上是一个 AI 代理——一个能"看到"整个推理集群运行状态、能"读懂"性能日志、能"决定"下一步改哪一段 kernel 代码的 AI。它由 GLM-5.3 自己驱动。

5.1 从首次运行到生产就绪：不到两周

整个工作流程是这样的：

1. 模型第一次在新硬件上成功运行——但很慢
2. Infra Agent 观察性能数据，定位瓶颈
3. Infra Agent 自己写或优化 kernel 代码
4. Infra Agent 部署新代码，重新测试
5. 重复步骤 2-4 直到性能达标

博客原文说：“在 Infra Agent 的反馈循环贯穿整个优化过程的情况下，GLM-5.3-Flash 从最初的模型适配到生产就绪只用了不到两周，最终相对初始基线实现了三倍的端到端吞吐量提升。”

这个时间数字（不到两周 vs “一个团队几周”）是博客想强调的核心反差——传统上需要一支有经验的工程师团队干几个月的工作，被一个 AI 代理在两周内搞定了。

5.2 为什么这件事叫"递归自我改进”？

博客原文给了一个非常清晰的 RSI（Recursive Self-Improvement，递归自我改进）定义：

给定足够算力和时间，它的终点是一个能完全自主设计和训练自己继任者的系统。这被称为递归自我改进，或 RSI。

这是一个非常重要的概念，我用类比展开讲：

• 第一代 AI：人类写代码 → AI 跑
• 第二代 AI：人类写代码 + AI 帮人类写代码 → AI 跑得更快
• 第三代 AI（RSI 雏形）：人类写代码 + AI 帮人类写代码 + AI 帮 AI 修 AI 自己跑的硬件 → AI 跑得更快 + 下一代 AI 训练得更快
• 终极 RSI：人类不写代码，AI 自己写自己、训练自己、修自己

智谱明确说：“我们还没到那一步。但它的早期形态已经出现。本文记录的就是这样一个早期样本。”

这次 GLM-5.3-Flash 在 100k 国产加速器上从首次运行到生产就绪、并且过程中大量工作由 GLM-5.3 自己驱动的 Infra Agent 完成——就是一个"第三阶段"的早期样本。

六、把反馈"具体化"——AI 修 AI 自己怎么做到？

博客的中间部分（5 个章节）专门讲"Infra Agent 的反馈循环是怎么具体设计的"。这部分比较技术，但核心思想值得让非专业读者了解一下：

问题：当 Infra Agent 看到"模型跑得慢"这件事，它需要知道"具体是哪里慢、为什么慢、怎么改"。但"模型跑得慢"是一个模糊的观察——它可能是一百种原因之一：可能是某一段代码写得不好、可能是某颗芯片过热降频、可能是某条数据通路堵了、可能是模型在某个特定输入下表现异常。

解法：把模糊的"端到端指标"拆成三路具体反馈：

1. 正确性反馈（Correctness Feedback）：模型的输出数值是否和参考答案一致？如果不一致，是哪一层算错的？
2. 系统行为反馈（System Behavior Feedback）：运行时各组件之间的通信、数据传递有没有异常？比如 KV cache（键值缓存，用于存储推理中间状态）在不同芯片之间传递时是否堵塞？
3. 性能反馈（Performance Feedback）：每一段 kernel 代码的运行时间、显存占用、带宽利用率分别是多少？哪一段是瓶颈？

把这三路反馈交给 Infra Agent，它就能"具体知道改哪里、怎么改"——而不是凭直觉瞎试。

关键洞察：模糊的反馈对人类有用，但 AI 需要的是可归因、可定位的反馈。 让 AI 修 AI 自己，第一步是把"好不好"拆成"具体哪一段不好、为什么不好"。

这就是博客中间 5 个章节在反复打磨的核心思想：dense feedback（密集反馈）——把每一处异常都精确归因到一个可操作的修改点上。

七、GLM 的故事线：从网络安全到代码到基础设施

博客开头有一句话很有分量：

在我们开发 GLM 的过程中，模型有时会表现出让我们惊讶、甚至让我们感到不安的能力。

接下来作者回顾了过去一年 GLM 能力跃迁的轨迹：

1. 2025 年 10 月：开始研究网络安全能力，理由是"能理解复杂代码的模型也应该能理解代码的漏洞"
2. 不到一年：安全团队用 GLM 在真实代码库里发现了上千个漏洞——模型开始重塑网络安全，但也带来了前所未有的新风险
3. 现在：GLM-5.3 已成为团队每天写代码离不开的伙伴，“稳步取代"团队成员
4. 更震撼的跃迁：GLM 开始反过来帮忙搭建基础设施——直接改变下一代模型如何被训练

作者说：“我们的继任者就是我们正在创造的 AI 系统。”

八、这件事对你意味着什么？

如果你是普通读者：未来几年里你用到的 AI 服务，背后的基础设施正在由 AI 协助甚至主导搭建。这意味着 AI 服务的迭代速度会变快、价格会继续下降、能力会持续提升——而这一切的幕后推手，部分就是 AI 自己。

如果你是开发者 / 工程师：RSI 不是科幻概念，是正在发生的工程现实。Infra Agent 的反馈循环设计（端到端指标 → 拆成 correctness / system behavior / performance 三路可归因反馈）是值得借鉴的范式——不仅适用于 AI 基础设施，也适用于任何"AI 修自己"的场景。

如果你是关注 AI 安全的读者：博客明确承认了 GLM 在网络安全领域带来的"前所未有的新风险”，并提到他们为此设计了"trusted access program"（可信访问计划）——这是负责任披露的一部分。

九、几个值得记住的数字

为了方便日后回看，我把博客里的关键数字列在这里：

十、结尾判断

把这篇博客的核心论点提炼成一句话：AI 正在成为 AI 自身的工程基础设施，而把这件事做成的关键不是更大的模型，是把"模型做得好不好"的反馈信号拆成可归因、可操作的具体指令——让 AI 能修 AI 自己。

这是一个比"AI 取代人类工作"更深远的变化：AI 开始取代 AI 工程师的工作——而且速度比人类工程师更快。

术语使用报告

术语一致率：19/19 = 100%。模型版本号、平台名称、专有名词按规范保持原文。