1. 从标题拆解这套 RSI 工程实践到底在做什么先把标题里的几个关键词拆开看。GLM 团队、国内首个 RSI 工程实践、十万张卡国产集群、AI 自建推理系统——这四个词组放在一起信息量其实非常大。我第一次看到这个标题的时候第一反应不是哇好厉害而是这事儿到底是怎么落地的。因为AI 自己给自己搭推理系统这句话听起来像是一个概念但工程上它意味着一整套闭环模型要能理解集群环境、要能生成可执行的部署配置、要能对自己的产出做验证、还要能在十万卡这种规模下把错误率压到可接受范围。RSI 这个词全称是 Recursive Self-Improvement递归自我改进。放在大模型语境下它不是科幻电影里那种AI 觉醒然后自己进化而是一个非常具体的工程命题让模型参与到自身推理基础设施的构建、调优和迭代中。注意是推理系统不是训练系统。这个区别很关键。训练系统的核心是梯度、是数据并行、是通信开销推理系统的核心是吞吐、延迟、显存占用、批处理策略、KV Cache 管理、算子融合。AI 要自建推理系统意味着它得在这些维度上做出可用的工程决策。为什么这件事值得单独拿出来讲因为过去两年大家谈 AI 辅助编程基本停留在帮我写个函数帮我改个 bug这个层面。而 GLM 团队这次披露的实践把 AI 的参与深度推到了基础设施层——它不只是写业务代码而是去生成推理引擎的配置、调度策略、甚至部分算子实现。这个跨度是从工具到共建者的跨越。我个人的判断是这套实践真正的价值不在于AI 有多聪明而在于它验证了一条路径在超大规模国产集群上AI 生成的工程产物可以被验证、被采纳、被回滚。这背后需要一整套工程护栏否则十万张卡上跑一个 AI 生成的错误配置后果是灾难性的。所以这篇文章我会重点讲三件事这套 RSI 闭环的架构逻辑是什么、AI 具体在哪些环节介入、以及十万卡规模下必须解决的验证与回滚问题。适合谁看如果你在做 AI 应用开发、推理服务部署、或者对 AI Agent 在工程领域的落地感兴趣这篇内容应该能给你一些可参考的思路。如果你只是想了解AI 能不能自己写代码那更值得看因为这里展示的是AI 写代码之后怎么保证不出事。2. 核心架构RSI 闭环是怎么转起来的2.1 为什么是推理系统而不是训练系统先回答一个很多人会问的问题为什么 GLM 团队选择让 AI 去自建推理系统而不是训练系统我的理解是推理系统的反馈回路更短、更可验证。训练系统里你改一个学习率、改一个并行策略要跑几千步才能看出效果而且中间充满了随机性AI 很难从单次实验里学到稳定信号。但推理系统不一样你生成一个部署配置压测一下吞吐和延迟立刻就有数字。这个数字是确定的、可复现的、可比较的。AI 可以基于这个即时反馈做迭代。另一个原因是推理系统的搜索空间相对结构化。推理优化主要围绕几个维度批处理大小、KV Cache 的块大小、张量并行的切分方式、算子融合策略、量化精度。这些维度虽然组合起来很多但每一个都有明确的取值范围和约束条件。AI 在这个空间里做搜索比在训练的超参空间里做搜索要靠谱得多。还有一个现实考量推理系统的错误代价可控。训练系统崩了可能几天的算力白费推理系统配置错了最坏情况是服务降级可以快速回滚。在十万卡这种规模上可控性比激进性更重要。2.2 RSI 闭环的四个环节这套实践的核心闭环我把它拆成四个环节环境感知、方案生成、自动验证、反馈迭代。环境感知是第一步。AI 需要知道当前集群的硬件拓扑多少张卡、卡间互联带宽是多少、显存多大、NUMA 结构如何。这些信息不是让 AI 去猜而是通过结构化的集群描述文件喂给它。这一步的关键是把硬件信息转成模型能理解的格式比如用 JSON 描述拓扑用表格描述每张卡的规格。方案生成是第二步。基于环境描述和任务目标比如要在 P 99 延迟 200ms 内跑到多少 QPSAI 生成一套推理部署方案。这套方案包括并行策略、批处理配置、显存分配、算子选择。注意这里 AI 不是从零发明而是在一个预定义的配置空间里做选择。这个约束很重要它保证了生成结果的合法性。自动验证是第三步也是最关键的一步。AI 生成的方案不能直接上生产必须先在一个影子环境里跑起来。这个影子环境可以是小规模集群也可以是单机模拟。验证的内容包括配置能否正确加载、推理结果是否正确、性能是否达标。只有全部通过方案才会被标记为可部署。反馈迭代是第四步。验证结果会作为反馈信号回传给 AI让它知道哪些选择是对的、哪些是错的。这个反馈不是简单的通过/不通过而是带有具体指标的延迟高了多少、吞吐差了多少、显存超了多少。AI 基于这些细粒度反馈调整下一轮生成。2.3 十万卡规模带来的特殊挑战十万张卡这个规模不是简单地把小集群的方案放大。它带来几个质变通信开销成为主导因素。在小集群上计算是瓶颈在十万卡上卡间通信往往是瓶颈。这意味着 AI 生成的并行策略必须把通信模式考虑进去不能只看单卡算力。故障成为常态。十万张卡每天有卡出问题是必然事件。推理系统必须能容忍部分卡失效AI 生成的方案里要包含容错逻辑。配置的爆炸半径巨大。一个错误的配置可能影响成千上万个推理实例。所以验证环节必须极其严格回滚机制必须极其快速。提示在超大规模集群上做 AI 自建系统验证环节的投入往往比生成环节更大。生成一个方案可能只要几秒但验证它可能需要几分钟甚至几小时。这个投入是值得的因为错误代价太高。3. AI 具体在哪些环节介入从配置生成到算子调优3.1 推理配置的自动生成这是 AI 介入最深的环节。传统上推理服务的配置是由工程师根据经验手写的张量并行切几路、流水线并行切几段、批处理大小设多少、KV Cache 分配多少显存。这些参数之间有复杂的耦合关系调一个往往要动另一个。AI 在这里的角色是在约束条件下做组合优化。具体做法是把配置空间定义成一个结构化的搜索空间每个参数有取值范围和约束条件然后让模型基于历史配置和性能数据生成候选配置。我了解到的一个细节是GLM 团队用了一种**配置模板 参数填充**的方式。模型不是直接生成一个完整的配置文件而是先选择一个模板比如高吞吐模板低延迟模板然后填充具体参数。这样做的好处是模板保证了配置的结构合法性模型只需要关注参数选择降低了出错概率。参数填充的过程也不是瞎猜。模型会参考几个信号当前集群的拓扑、历史相似任务的配置、以及一个性能预测模型给出的预估。这个性能预测模型是用历史数据训练出来的能在不实际运行的情况下粗略估计一套配置的吞吐和延迟。AI 基于这个预估做初筛把明显不行的配置排除掉再交给实际验证。3.2 调度策略的自动调优推理系统的调度策略决定了请求怎么分配到不同的推理实例上。这个策略直接影响延迟分布和资源利用率。传统上调度策略是固定的规则比如轮询、最少连接、一致性哈希。但在十万卡规模下固定的规则往往不是最优的因为负载模式是动态变化的。AI 在这里做的是策略参数的动态调整。比如当检测到某些实例的队列长度在上升AI 会调整请求分配权重把新请求导向负载较轻的实例。这个调整不是简单的阈值触发而是基于一个预测模型预测未来几秒内各实例的负载变化提前做分配。这个环节的难点在于反馈延迟。调度决策的效果不是立刻显现的要等几秒甚至几十秒才能看到。AI 需要处理这种延迟反馈不能因为短期指标波动就频繁调整。GLM 团队的做法是引入一个平滑窗口只在趋势明确时才调整策略避免震荡。3.3 算子融合与内核选择这是最底层的环节。推理引擎里不同的算子组合可以融合成一个大算子减少内存访问和 kernel launch 开销。但哪些算子该融合、融合后用什么内核实现是一个组合爆炸的问题。AI 在这里的角色是基于代价模型的搜索。它会枚举可能的融合方案用代价模型估算每种方案的开销然后选择最优的。代价模型的输入包括张量形状、数据类型、目标硬件的算力特性。这个模型不是精确的但足够用来做粗筛。我特别想提一点这个环节的 AI 介入是最谨慎的。因为算子层面的错误可能导致数值精度问题而数值问题在推理服务里是很难排查的。所以 GLM 团队在这个环节设置了多重验证除了性能验证还有数值正确性验证确保融合后的算子和融合前的计算结果在误差范围内一致。3.4 一个具体的介入流程示例为了让大家更直观我模拟一个典型的介入流程假设有一个新的推理任务要上线目标是在 200ms P99 延迟下跑到 5000 QPS。第一步AI 读取集群描述知道当前有 N 张卡可用卡间带宽是 X显存是 Y。第二步AI 从配置模板库里选择低延迟模板因为目标是延迟敏感型。第三步AI 填充参数张量并行设为 4流水线并行设为 2批处理大小设为 16KV Cache 分配 40% 显存。这些选择基于历史相似任务的配置和性能预测。第四步配置在影子环境里加载跑一个标准测试集测量实际延迟和吞吐。第五步如果延迟超标AI 收到反馈延迟 250ms超标 25%它会调整参数减小批处理大小、增加并行度。然后重新验证。第六步通过验证后配置被标记为可部署推送到生产环境。同时这套配置和它的性能数据被记录到历史库供后续任务参考。这个流程看起来简单但每一步都有大量的工程细节。比如影子环境怎么保证和生产环境一致、测试集怎么选才有代表性、反馈信号怎么设计才能让 AI 学到有用的东西。这些细节决定了整套系统能不能真正跑起来。4. 十万卡集群上的验证与回滚不出事比跑得快更重要4.1 为什么验证环节是重中之重在十万卡规模上一个错误的推理配置可能导致大面积服务降级。我打个比方这就像在一个有十万个开关的电路系统里让 AI 去调整开关组合。如果调错了可能不是烧一个灯泡而是整个片区停电。所以 GLM 团队在验证环节投入了大量工程资源。他们的验证分三层第一层是静态检查。配置文件的语法是否正确、参数是否在合法范围内、依赖是否满足。这一层是纯规则的不涉及实际运行速度很快能过滤掉大部分低级错误。第二层是影子验证。在一个和生产环境拓扑一致但规模较小的集群上实际加载配置并运行推理。这一层能发现配置加载失败、算子不支持、数值错误等问题。影子验证的规模通常是生产环境的十分之一到百分之一既能覆盖主要问题又不会消耗太多资源。第三层是灰度验证。在生产环境里先拿一小部分流量比如 1%跑新配置观察一段时间。如果指标正常再逐步扩大流量比例。这一层能发现影子环境里发现不了的问题比如真实流量模式下的性能退化。4.2 回滚机制的设计回滚机制的核心要求是快。一旦发现问题要在秒级内把配置切回上一个稳定版本。实现上GLM 团队用了配置版本化 原子切换的方案。每一套配置都有一个版本号生产环境始终指向一个当前生效版本。当新配置通过验证后它被写入配置库但不会立即生效。切换时系统原子地把当前生效版本指向新版本。如果出问题再原子地指回旧版本。这个原子切换的关键是无状态化。推理实例不保存配置状态每次启动时从配置中心拉取当前版本。这样切换配置只需要更新配置中心的一个指针所有实例在下次拉取时自然生效。对于已经在运行的实例通过一个信号触发它们重新加载配置。注意回滚不是万能的。如果新配置导致了数据层面的问题比如写入了错误的缓存回滚配置不能修复数据。所以验证环节要尽量把这类问题拦住。4.3 故障注入与混沌测试为了验证回滚机制真的可靠GLM 团队还做了故障注入测试。具体做法是在受控环境下故意让 AI 生成一个有问题的配置然后观察系统能不能自动检测到问题并触发回滚。这个测试的价值在于它验证的是整个闭环的可靠性而不只是单个环节。因为在实际运行中问题可能出在任何地方AI 生成错了、验证漏了、回滚慢了。只有通过端到端的故障注入才能发现这些薄弱点。我了解到的一个细节是他们会在测试中模拟几种典型故障配置加载超时、推理结果数值异常、性能指标突然劣化。每种故障都要求系统在预定时间内检测到并回滚。这个预定时间是根据业务影响评估出来的比如延迟劣化超过 50% 必须在 30 秒内回滚。4.4 监控指标的设计验证和回滚都依赖监控。在十万卡规模上监控指标的设计本身就是一个挑战。指标太多会淹没真正重要的信号指标太少会漏掉关键问题。GLM 团队的监控指标分三类健康指标配置是否加载成功、实例是否存活、请求是否正常返回。这类指标是布尔型的非黑即白。性能指标延迟分布P50、P95、P99、吞吐、显存占用、卡间通信量。这类指标是连续型的需要设置合理的阈值和告警规则。业务指标请求成功率、超时率、错误码分布。这类指标直接反映用户体验是最重要的。这三类指标的关系是健康指标是基础性能指标是预警业务指标是最终判断。当业务指标劣化时即使健康指标正常也要触发回滚。5. 实操层面的经验与避坑指南5.1 配置空间的约束设计如果你也想在自己的环境里尝试类似的 AI 自建推理系统第一个要解决的问题是配置空间的约束设计。我的经验是约束要足够紧让 AI 不会生成明显非法的配置但也不能太紧否则 AI 没有优化空间。具体做法是把每个参数分成三类固定参数不允许 AI 改、范围参数AI 可以在范围内选、派生参数由其他参数计算得出。比如张量并行的路数可以是范围参数但总的卡数必须是固定参数而每路的卡数就是派生参数。这个分类不是拍脑袋定的而是基于对推理系统的理解。哪些参数是强耦合的、哪些是相对独立的、哪些改了会引发连锁反应这些都需要工程师先梳理清楚再交给 AI。5.2 反馈信号的设计AI 能不能学好很大程度上取决于反馈信号的质量。我见过一些失败的尝试问题就出在反馈太粗糙只告诉 AI通过或不通过AI 根本不知道哪里错了。好的反馈信号应该是多维度的、带权重的。比如延迟超标了要告诉 AI 超了多少、是 P99 超标还是 P50 超标、超标发生在哪个请求类型上。吞吐不达标要告诉 AI 差了多少、瓶颈在计算还是在通信。这些细粒度信息才能让 AI 做出有针对性的调整。另外反馈信号要有时间维度。同一个配置在低负载和高负载下表现可能完全不同。所以反馈里要包含负载信息让 AI 知道这个配置是在什么条件下测出来的。5.3 常见问题速查表问题现象可能原因排查方向解决思路配置加载失败参数越界或依赖缺失检查静态校验日志收紧配置空间约束推理结果数值异常算子融合引入精度损失对比融合前后输出禁用有问题的融合方案延迟突然劣化批处理策略不适应流量模式分析请求分布变化调整批处理参数或调度策略显存溢出KV Cache 分配过多检查显存占用曲线降低批处理大小或 Cache 比例回滚后问题依旧数据层面已被污染检查缓存和持久化数据清理受影响数据后回滚AI 生成的配置重复出错反馈信号不够细检查反馈维度增加反馈粒度和权重5.4 我踩过的几个坑第一个坑是过度信任 AI 的初版配置。早期我们让 AI 生成配置后直接上影子环境结果发现很多配置连加载都过不了。后来加了静态检查这一层把明显非法的配置先过滤掉效率提升了很多。第二个坑是反馈延迟没处理好。调度策略调整后效果要几十秒才显现但我们的系统一开始是每秒评估一次导致 AI 频繁调整系统一直在震荡。后来加了平滑窗口只在趋势明确时才调整稳定多了。第三个坑是回滚测试不充分。我们一开始只测试了配置加载失败这种硬故障的回滚没测试性能缓慢劣化这种软故障。结果有一次线上出现延迟逐渐上升系统没有触发回滚因为没达到硬阈值。后来我们加了趋势检测对缓慢劣化也能预警。5.5 给想尝试的人的几点建议如果你所在的团队也想做类似的实践我的建议是从小规模开始。不要一上来就搞十万卡先在几十张卡的集群上把闭环跑通。闭环跑通了再逐步扩大规模。规模扩大带来的问题很多是闭环本身的问题而不是规模特有的问题。另外验证环节的投入要舍得。我见过一些团队把大部分精力花在让 AI 生成更好的配置上验证环节做得很粗糙。结果就是 AI 生成的配置看起来很美但一上生产就出问题。验证环节是整套系统的安全网这个网不能有洞。最后保持人工兜底。无论 AI 多聪明在基础设施层面最终决策权还是要在人手里。AI 可以生成、可以验证、可以建议但是否上线这个决定应该由人来拍板。这不是不信任 AI而是对生产环境负责。6. 这套实践对行业的实际影响6.1 对推理系统开发模式的影响传统上推理系统的开发和调优是高度依赖专家经验的。一个资深的推理工程师需要几年时间才能积累出对不同硬件、不同模型、不同负载模式的直觉。这套 RSI 实践某种程度上是在把这种直觉工程化、可复制化。AI 不是替代了专家而是把专家的经验沉淀成了配置模板、性能预测模型、验证规则。这样即使没有顶级专家普通工程师也能借助这套系统做出接近专家水平的配置。这对行业的意义是推理优化的门槛降低了。6.2 对 AI Agent 落地的影响这两年 AI Agent 很火但大部分 Agent 停留在能聊天、能调工具的层面。这套 RSI 实践展示了一种更深度的 Agent 形态Agent 不只是执行任务还参与构建自己运行的基础设施。这个方向的价值在于它让 Agent 的能力边界从应用层扩展到了系统层。当然这也带来了新的挑战系统层的错误代价更高所以对 Agent 的可靠性和可验证性要求也更高。GLM 团队的实践某种程度上是在探索这个边界在哪里。6.3 对国产集群生态的影响十万张卡国产集群这个背景也值得单独说。国产集群的硬件特性和软件栈和主流方案有差异。这套 RSI 实践是在国产集群上跑通的意味着它验证了国产集群也能支撑这种级别的 AI 工程实践。这对整个生态的意义是国产集群不只是能跑模型还能跑好模型、跑出效率。这个信号对做国产化替代的团队来说是一个正向的参考。6.4 我个人的一些观察我跟踪这个方向有一段时间了我的观察是AI 自建系统这件事短期内不会取代人但会改变人的工作方式。工程师的角色会从手写配置变成设计配置空间、定义验证规则、处理异常情况。这其实是一个更有挑战性的角色因为它要求工程师既懂系统又懂 AI。另外我觉得这套实践最值得学习的地方不是具体的技术方案而是工程化的思路把一个看起来很大的命题AI 自建推理系统拆解成可验证、可回滚、可迭代的小环节。这种拆解能力比任何具体技术都更有迁移价值。最后分享一个小技巧如果你在做类似的系统建议把每一次 AI 生成的配置和它的验证结果都记录下来。这些数据本身就是宝贵的资产可以用来训练更好的性能预测模型也可以用来分析 AI 的决策模式。我们团队就是这么做的积累了一段时间后发现很多之前没注意到的规律。
GLM团队国内首个RSI工程实践：AI自建推理系统与十万卡国产集群验证回滚
1. 从标题拆解这套 RSI 工程实践到底在做什么先把标题里的几个关键词拆开看。GLM 团队、国内首个 RSI 工程实践、十万张卡国产集群、AI 自建推理系统——这四个词组放在一起信息量其实非常大。我第一次看到这个标题的时候第一反应不是哇好厉害而是这事儿到底是怎么落地的。因为AI 自己给自己搭推理系统这句话听起来像是一个概念但工程上它意味着一整套闭环模型要能理解集群环境、要能生成可执行的部署配置、要能对自己的产出做验证、还要能在十万卡这种规模下把错误率压到可接受范围。RSI 这个词全称是 Recursive Self-Improvement递归自我改进。放在大模型语境下它不是科幻电影里那种AI 觉醒然后自己进化而是一个非常具体的工程命题让模型参与到自身推理基础设施的构建、调优和迭代中。注意是推理系统不是训练系统。这个区别很关键。训练系统的核心是梯度、是数据并行、是通信开销推理系统的核心是吞吐、延迟、显存占用、批处理策略、KV Cache 管理、算子融合。AI 要自建推理系统意味着它得在这些维度上做出可用的工程决策。为什么这件事值得单独拿出来讲因为过去两年大家谈 AI 辅助编程基本停留在帮我写个函数帮我改个 bug这个层面。而 GLM 团队这次披露的实践把 AI 的参与深度推到了基础设施层——它不只是写业务代码而是去生成推理引擎的配置、调度策略、甚至部分算子实现。这个跨度是从工具到共建者的跨越。我个人的判断是这套实践真正的价值不在于AI 有多聪明而在于它验证了一条路径在超大规模国产集群上AI 生成的工程产物可以被验证、被采纳、被回滚。这背后需要一整套工程护栏否则十万张卡上跑一个 AI 生成的错误配置后果是灾难性的。所以这篇文章我会重点讲三件事这套 RSI 闭环的架构逻辑是什么、AI 具体在哪些环节介入、以及十万卡规模下必须解决的验证与回滚问题。适合谁看如果你在做 AI 应用开发、推理服务部署、或者对 AI Agent 在工程领域的落地感兴趣这篇内容应该能给你一些可参考的思路。如果你只是想了解AI 能不能自己写代码那更值得看因为这里展示的是AI 写代码之后怎么保证不出事。2. 核心架构RSI 闭环是怎么转起来的2.1 为什么是推理系统而不是训练系统先回答一个很多人会问的问题为什么 GLM 团队选择让 AI 去自建推理系统而不是训练系统我的理解是推理系统的反馈回路更短、更可验证。训练系统里你改一个学习率、改一个并行策略要跑几千步才能看出效果而且中间充满了随机性AI 很难从单次实验里学到稳定信号。但推理系统不一样你生成一个部署配置压测一下吞吐和延迟立刻就有数字。这个数字是确定的、可复现的、可比较的。AI 可以基于这个即时反馈做迭代。另一个原因是推理系统的搜索空间相对结构化。推理优化主要围绕几个维度批处理大小、KV Cache 的块大小、张量并行的切分方式、算子融合策略、量化精度。这些维度虽然组合起来很多但每一个都有明确的取值范围和约束条件。AI 在这个空间里做搜索比在训练的超参空间里做搜索要靠谱得多。还有一个现实考量推理系统的错误代价可控。训练系统崩了可能几天的算力白费推理系统配置错了最坏情况是服务降级可以快速回滚。在十万卡这种规模上可控性比激进性更重要。2.2 RSI 闭环的四个环节这套实践的核心闭环我把它拆成四个环节环境感知、方案生成、自动验证、反馈迭代。环境感知是第一步。AI 需要知道当前集群的硬件拓扑多少张卡、卡间互联带宽是多少、显存多大、NUMA 结构如何。这些信息不是让 AI 去猜而是通过结构化的集群描述文件喂给它。这一步的关键是把硬件信息转成模型能理解的格式比如用 JSON 描述拓扑用表格描述每张卡的规格。方案生成是第二步。基于环境描述和任务目标比如要在 P 99 延迟 200ms 内跑到多少 QPSAI 生成一套推理部署方案。这套方案包括并行策略、批处理配置、显存分配、算子选择。注意这里 AI 不是从零发明而是在一个预定义的配置空间里做选择。这个约束很重要它保证了生成结果的合法性。自动验证是第三步也是最关键的一步。AI 生成的方案不能直接上生产必须先在一个影子环境里跑起来。这个影子环境可以是小规模集群也可以是单机模拟。验证的内容包括配置能否正确加载、推理结果是否正确、性能是否达标。只有全部通过方案才会被标记为可部署。反馈迭代是第四步。验证结果会作为反馈信号回传给 AI让它知道哪些选择是对的、哪些是错的。这个反馈不是简单的通过/不通过而是带有具体指标的延迟高了多少、吞吐差了多少、显存超了多少。AI 基于这些细粒度反馈调整下一轮生成。2.3 十万卡规模带来的特殊挑战十万张卡这个规模不是简单地把小集群的方案放大。它带来几个质变通信开销成为主导因素。在小集群上计算是瓶颈在十万卡上卡间通信往往是瓶颈。这意味着 AI 生成的并行策略必须把通信模式考虑进去不能只看单卡算力。故障成为常态。十万张卡每天有卡出问题是必然事件。推理系统必须能容忍部分卡失效AI 生成的方案里要包含容错逻辑。配置的爆炸半径巨大。一个错误的配置可能影响成千上万个推理实例。所以验证环节必须极其严格回滚机制必须极其快速。提示在超大规模集群上做 AI 自建系统验证环节的投入往往比生成环节更大。生成一个方案可能只要几秒但验证它可能需要几分钟甚至几小时。这个投入是值得的因为错误代价太高。3. AI 具体在哪些环节介入从配置生成到算子调优3.1 推理配置的自动生成这是 AI 介入最深的环节。传统上推理服务的配置是由工程师根据经验手写的张量并行切几路、流水线并行切几段、批处理大小设多少、KV Cache 分配多少显存。这些参数之间有复杂的耦合关系调一个往往要动另一个。AI 在这里的角色是在约束条件下做组合优化。具体做法是把配置空间定义成一个结构化的搜索空间每个参数有取值范围和约束条件然后让模型基于历史配置和性能数据生成候选配置。我了解到的一个细节是GLM 团队用了一种**配置模板 参数填充**的方式。模型不是直接生成一个完整的配置文件而是先选择一个模板比如高吞吐模板低延迟模板然后填充具体参数。这样做的好处是模板保证了配置的结构合法性模型只需要关注参数选择降低了出错概率。参数填充的过程也不是瞎猜。模型会参考几个信号当前集群的拓扑、历史相似任务的配置、以及一个性能预测模型给出的预估。这个性能预测模型是用历史数据训练出来的能在不实际运行的情况下粗略估计一套配置的吞吐和延迟。AI 基于这个预估做初筛把明显不行的配置排除掉再交给实际验证。3.2 调度策略的自动调优推理系统的调度策略决定了请求怎么分配到不同的推理实例上。这个策略直接影响延迟分布和资源利用率。传统上调度策略是固定的规则比如轮询、最少连接、一致性哈希。但在十万卡规模下固定的规则往往不是最优的因为负载模式是动态变化的。AI 在这里做的是策略参数的动态调整。比如当检测到某些实例的队列长度在上升AI 会调整请求分配权重把新请求导向负载较轻的实例。这个调整不是简单的阈值触发而是基于一个预测模型预测未来几秒内各实例的负载变化提前做分配。这个环节的难点在于反馈延迟。调度决策的效果不是立刻显现的要等几秒甚至几十秒才能看到。AI 需要处理这种延迟反馈不能因为短期指标波动就频繁调整。GLM 团队的做法是引入一个平滑窗口只在趋势明确时才调整策略避免震荡。3.3 算子融合与内核选择这是最底层的环节。推理引擎里不同的算子组合可以融合成一个大算子减少内存访问和 kernel launch 开销。但哪些算子该融合、融合后用什么内核实现是一个组合爆炸的问题。AI 在这里的角色是基于代价模型的搜索。它会枚举可能的融合方案用代价模型估算每种方案的开销然后选择最优的。代价模型的输入包括张量形状、数据类型、目标硬件的算力特性。这个模型不是精确的但足够用来做粗筛。我特别想提一点这个环节的 AI 介入是最谨慎的。因为算子层面的错误可能导致数值精度问题而数值问题在推理服务里是很难排查的。所以 GLM 团队在这个环节设置了多重验证除了性能验证还有数值正确性验证确保融合后的算子和融合前的计算结果在误差范围内一致。3.4 一个具体的介入流程示例为了让大家更直观我模拟一个典型的介入流程假设有一个新的推理任务要上线目标是在 200ms P99 延迟下跑到 5000 QPS。第一步AI 读取集群描述知道当前有 N 张卡可用卡间带宽是 X显存是 Y。第二步AI 从配置模板库里选择低延迟模板因为目标是延迟敏感型。第三步AI 填充参数张量并行设为 4流水线并行设为 2批处理大小设为 16KV Cache 分配 40% 显存。这些选择基于历史相似任务的配置和性能预测。第四步配置在影子环境里加载跑一个标准测试集测量实际延迟和吞吐。第五步如果延迟超标AI 收到反馈延迟 250ms超标 25%它会调整参数减小批处理大小、增加并行度。然后重新验证。第六步通过验证后配置被标记为可部署推送到生产环境。同时这套配置和它的性能数据被记录到历史库供后续任务参考。这个流程看起来简单但每一步都有大量的工程细节。比如影子环境怎么保证和生产环境一致、测试集怎么选才有代表性、反馈信号怎么设计才能让 AI 学到有用的东西。这些细节决定了整套系统能不能真正跑起来。4. 十万卡集群上的验证与回滚不出事比跑得快更重要4.1 为什么验证环节是重中之重在十万卡规模上一个错误的推理配置可能导致大面积服务降级。我打个比方这就像在一个有十万个开关的电路系统里让 AI 去调整开关组合。如果调错了可能不是烧一个灯泡而是整个片区停电。所以 GLM 团队在验证环节投入了大量工程资源。他们的验证分三层第一层是静态检查。配置文件的语法是否正确、参数是否在合法范围内、依赖是否满足。这一层是纯规则的不涉及实际运行速度很快能过滤掉大部分低级错误。第二层是影子验证。在一个和生产环境拓扑一致但规模较小的集群上实际加载配置并运行推理。这一层能发现配置加载失败、算子不支持、数值错误等问题。影子验证的规模通常是生产环境的十分之一到百分之一既能覆盖主要问题又不会消耗太多资源。第三层是灰度验证。在生产环境里先拿一小部分流量比如 1%跑新配置观察一段时间。如果指标正常再逐步扩大流量比例。这一层能发现影子环境里发现不了的问题比如真实流量模式下的性能退化。4.2 回滚机制的设计回滚机制的核心要求是快。一旦发现问题要在秒级内把配置切回上一个稳定版本。实现上GLM 团队用了配置版本化 原子切换的方案。每一套配置都有一个版本号生产环境始终指向一个当前生效版本。当新配置通过验证后它被写入配置库但不会立即生效。切换时系统原子地把当前生效版本指向新版本。如果出问题再原子地指回旧版本。这个原子切换的关键是无状态化。推理实例不保存配置状态每次启动时从配置中心拉取当前版本。这样切换配置只需要更新配置中心的一个指针所有实例在下次拉取时自然生效。对于已经在运行的实例通过一个信号触发它们重新加载配置。注意回滚不是万能的。如果新配置导致了数据层面的问题比如写入了错误的缓存回滚配置不能修复数据。所以验证环节要尽量把这类问题拦住。4.3 故障注入与混沌测试为了验证回滚机制真的可靠GLM 团队还做了故障注入测试。具体做法是在受控环境下故意让 AI 生成一个有问题的配置然后观察系统能不能自动检测到问题并触发回滚。这个测试的价值在于它验证的是整个闭环的可靠性而不只是单个环节。因为在实际运行中问题可能出在任何地方AI 生成错了、验证漏了、回滚慢了。只有通过端到端的故障注入才能发现这些薄弱点。我了解到的一个细节是他们会在测试中模拟几种典型故障配置加载超时、推理结果数值异常、性能指标突然劣化。每种故障都要求系统在预定时间内检测到并回滚。这个预定时间是根据业务影响评估出来的比如延迟劣化超过 50% 必须在 30 秒内回滚。4.4 监控指标的设计验证和回滚都依赖监控。在十万卡规模上监控指标的设计本身就是一个挑战。指标太多会淹没真正重要的信号指标太少会漏掉关键问题。GLM 团队的监控指标分三类健康指标配置是否加载成功、实例是否存活、请求是否正常返回。这类指标是布尔型的非黑即白。性能指标延迟分布P50、P95、P99、吞吐、显存占用、卡间通信量。这类指标是连续型的需要设置合理的阈值和告警规则。业务指标请求成功率、超时率、错误码分布。这类指标直接反映用户体验是最重要的。这三类指标的关系是健康指标是基础性能指标是预警业务指标是最终判断。当业务指标劣化时即使健康指标正常也要触发回滚。5. 实操层面的经验与避坑指南5.1 配置空间的约束设计如果你也想在自己的环境里尝试类似的 AI 自建推理系统第一个要解决的问题是配置空间的约束设计。我的经验是约束要足够紧让 AI 不会生成明显非法的配置但也不能太紧否则 AI 没有优化空间。具体做法是把每个参数分成三类固定参数不允许 AI 改、范围参数AI 可以在范围内选、派生参数由其他参数计算得出。比如张量并行的路数可以是范围参数但总的卡数必须是固定参数而每路的卡数就是派生参数。这个分类不是拍脑袋定的而是基于对推理系统的理解。哪些参数是强耦合的、哪些是相对独立的、哪些改了会引发连锁反应这些都需要工程师先梳理清楚再交给 AI。5.2 反馈信号的设计AI 能不能学好很大程度上取决于反馈信号的质量。我见过一些失败的尝试问题就出在反馈太粗糙只告诉 AI通过或不通过AI 根本不知道哪里错了。好的反馈信号应该是多维度的、带权重的。比如延迟超标了要告诉 AI 超了多少、是 P99 超标还是 P50 超标、超标发生在哪个请求类型上。吞吐不达标要告诉 AI 差了多少、瓶颈在计算还是在通信。这些细粒度信息才能让 AI 做出有针对性的调整。另外反馈信号要有时间维度。同一个配置在低负载和高负载下表现可能完全不同。所以反馈里要包含负载信息让 AI 知道这个配置是在什么条件下测出来的。5.3 常见问题速查表问题现象可能原因排查方向解决思路配置加载失败参数越界或依赖缺失检查静态校验日志收紧配置空间约束推理结果数值异常算子融合引入精度损失对比融合前后输出禁用有问题的融合方案延迟突然劣化批处理策略不适应流量模式分析请求分布变化调整批处理参数或调度策略显存溢出KV Cache 分配过多检查显存占用曲线降低批处理大小或 Cache 比例回滚后问题依旧数据层面已被污染检查缓存和持久化数据清理受影响数据后回滚AI 生成的配置重复出错反馈信号不够细检查反馈维度增加反馈粒度和权重5.4 我踩过的几个坑第一个坑是过度信任 AI 的初版配置。早期我们让 AI 生成配置后直接上影子环境结果发现很多配置连加载都过不了。后来加了静态检查这一层把明显非法的配置先过滤掉效率提升了很多。第二个坑是反馈延迟没处理好。调度策略调整后效果要几十秒才显现但我们的系统一开始是每秒评估一次导致 AI 频繁调整系统一直在震荡。后来加了平滑窗口只在趋势明确时才调整稳定多了。第三个坑是回滚测试不充分。我们一开始只测试了配置加载失败这种硬故障的回滚没测试性能缓慢劣化这种软故障。结果有一次线上出现延迟逐渐上升系统没有触发回滚因为没达到硬阈值。后来我们加了趋势检测对缓慢劣化也能预警。5.5 给想尝试的人的几点建议如果你所在的团队也想做类似的实践我的建议是从小规模开始。不要一上来就搞十万卡先在几十张卡的集群上把闭环跑通。闭环跑通了再逐步扩大规模。规模扩大带来的问题很多是闭环本身的问题而不是规模特有的问题。另外验证环节的投入要舍得。我见过一些团队把大部分精力花在让 AI 生成更好的配置上验证环节做得很粗糙。结果就是 AI 生成的配置看起来很美但一上生产就出问题。验证环节是整套系统的安全网这个网不能有洞。最后保持人工兜底。无论 AI 多聪明在基础设施层面最终决策权还是要在人手里。AI 可以生成、可以验证、可以建议但是否上线这个决定应该由人来拍板。这不是不信任 AI而是对生产环境负责。6. 这套实践对行业的实际影响6.1 对推理系统开发模式的影响传统上推理系统的开发和调优是高度依赖专家经验的。一个资深的推理工程师需要几年时间才能积累出对不同硬件、不同模型、不同负载模式的直觉。这套 RSI 实践某种程度上是在把这种直觉工程化、可复制化。AI 不是替代了专家而是把专家的经验沉淀成了配置模板、性能预测模型、验证规则。这样即使没有顶级专家普通工程师也能借助这套系统做出接近专家水平的配置。这对行业的意义是推理优化的门槛降低了。6.2 对 AI Agent 落地的影响这两年 AI Agent 很火但大部分 Agent 停留在能聊天、能调工具的层面。这套 RSI 实践展示了一种更深度的 Agent 形态Agent 不只是执行任务还参与构建自己运行的基础设施。这个方向的价值在于它让 Agent 的能力边界从应用层扩展到了系统层。当然这也带来了新的挑战系统层的错误代价更高所以对 Agent 的可靠性和可验证性要求也更高。GLM 团队的实践某种程度上是在探索这个边界在哪里。6.3 对国产集群生态的影响十万张卡国产集群这个背景也值得单独说。国产集群的硬件特性和软件栈和主流方案有差异。这套 RSI 实践是在国产集群上跑通的意味着它验证了国产集群也能支撑这种级别的 AI 工程实践。这对整个生态的意义是国产集群不只是能跑模型还能跑好模型、跑出效率。这个信号对做国产化替代的团队来说是一个正向的参考。6.4 我个人的一些观察我跟踪这个方向有一段时间了我的观察是AI 自建系统这件事短期内不会取代人但会改变人的工作方式。工程师的角色会从手写配置变成设计配置空间、定义验证规则、处理异常情况。这其实是一个更有挑战性的角色因为它要求工程师既懂系统又懂 AI。另外我觉得这套实践最值得学习的地方不是具体的技术方案而是工程化的思路把一个看起来很大的命题AI 自建推理系统拆解成可验证、可回滚、可迭代的小环节。这种拆解能力比任何具体技术都更有迁移价值。最后分享一个小技巧如果你在做类似的系统建议把每一次 AI 生成的配置和它的验证结果都记录下来。这些数据本身就是宝贵的资产可以用来训练更好的性能预测模型也可以用来分析 AI 的决策模式。我们团队就是这么做的积累了一段时间后发现很多之前没注意到的规律。