六天烧两千万：大规模强化学习训练开源MoE模型全拆解

1. 从一条热搜说起：为什么这次开源模型的动作值得关注

前几天刷到一条消息，说某团队在六天时间里烧掉了两千多万算力成本，就为了训练一个开源模型，而且多个 Agent 基准测试的成绩直接对标闭源旗舰。这个数字乍一看挺吓人，但如果你真的在大规模强化学习这条路上走过一遭，就会明白这个烧钱速度其实一点都不夸张——甚至可以说，这已经算是控制得比较克制的了。

我自己过去两年一直在做强化学习相关的工程落地，从最早的离线强化学习（比如 IQL 这类方法）到后来的大语言模型 RLHF、再到最近这一波 Agent 方向的 RL 训练，踩过的坑基本能写一本小册子。所以当我看到“押注大规模 RL”这个说法的时候，第一反应不是惊讶，而是好奇：他们到底在哪些环节做了取舍？MoE 架构下怎么做负载均衡？Agent 基准测试又是怎么设计的？

这篇文章我想聊的不是某一条新闻本身，而是借这个由头，把“大规模强化学习训练一个开源 MoE 模型”这件事从头到尾拆一遍。包括为什么现在大家开始押注 RL、MoE 架构在训练和推理时的真实开销、Agent 基准到底测的是什么、以及一个普通开发者如果想复现类似思路，应该从哪里下手。不管你是刚接触强化学习入门的新手，还是已经在做 Agent 开发的工程师，我都尽量把话说透，让你看完能直接抄作业。

先给一个整体判断：这一波开源模型之所以能在 Agent 基准上比肩闭源旗舰，核心不在于模型参数堆得多大，而在于后训练阶段的大规模强化学习做得足够扎实。预训练决定了模型的下限，而 RL 后训练决定了它在真实任务里的上限。这也是为什么“六天烧掉两千多万”这件事，钱主要花在了 RL 的采样和 rollout 上，而不是预训练。

2. 大规模强化学习到底在训什么：从 RLHF 到 Agent RL

2.1 强化学习在大模型里的三个层次

很多人一听到“强化学习”就想到 Gymnasium 里的 CartPole，或者机械臂强化学习那种连续控制任务。但大语言模型语境下的强化学习，和传统深度强化学习算法列表里的那些东西，虽然数学框架一样，工程形态完全不同。我把它分成三个层次，方便你建立坐标系。

第一个层次是偏好对齐，也就是经典的 RLHF。用一个奖励模型去打分，然后用 PPO 或者 GRPO 这类算法去优化策略。这个阶段的目标是让模型的输出更符合人类偏好，本质上还是在“调语气、调风格”。

第二个层次是可验证奖励的强化学习，比如数学题、代码题。这类任务的好处是奖励可以自动判定，不需要单独训一个奖励模型，直接用规则或者单元测试就能给出 0/1 的反馈。现在很多开源模型在数学和代码上的进步，主要来自这个阶段。

第三个层次就是Agent 强化学习，也是这次热搜里最核心的部分。Agent 任务的特点是：多轮交互、有工具调用、有环境反馈、奖励稀疏且延迟。比如让模型去操作一个浏览器完成订票，或者调用一堆 API 完成一个数据分析任务，中间任何一步错了，最后可能全盘皆输。这种任务的 RL 训练难度，比前两个层次高一个数量级。

提示：如果你刚开始接触强化学习入门，建议先把第二个层次跑通，也就是找一个有标准答案的任务集，用 GRPO 或者类似的算法做一遍。Agent RL 的复杂度会让你在还没理解奖励设计之前就迷失在工程细节里。

2.2 为什么是“大规模”：规模带来的质变

“大规模 RL”这个词里的“大规模”，体现在三个维度上，缺一不可。

第一是采样规模。Agent 任务的 rollout 特别长，一个任务可能要几十轮交互，每轮都要调用模型推理。六天烧掉两千多万，绝大部分钱就花在这里。你可以粗略算一下：假设一次完整 rollout 平均 20 轮，每轮生成 500 token，一个任务就是 1 万 token 的生成量。如果同时跑几千个环境，每天产生的 token 量是亿级别的。这个量级的推理成本，用最贵的卡跑，一天几百万很正常。

第二是环境规模。Agent 训练需要大量并行的环境，每个环境是一个独立的沙箱，里面有工具、有状态、有反馈。环境数量不够，采样效率就上不去，GPU 就会空转等数据。这也是为什么 Agent 框架的设计直接决定了训练效率。

第三是算法规模。当 batch size 大到一定程度，PPO 这类算法的方差问题会变得很突出，需要引入各种技巧，比如优势归一化、KL 惩罚的动态调整、以及重要性采样的修正。这些在论文里都是一句话，在工程里都是几天的调试。

2.3 MoE 架构给 RL 训练带来的额外变量

这次模型用的是 MoE 架构，这就让事情更有意思了。MoE 的核心思想是：每次前向只激活一部分专家，这样总参数量可以做得很大，但单次计算量可控。听起来很美，但在 RL 训练里会引入几个新问题。

首先是负载均衡。如果所有 token 都路由到同几个专家，那其他专家就是浪费，而且被选中的专家会过载。所以训练时通常要加一个负载均衡损失，强制让 token 均匀分布到各个专家。这个损失的系数很敏感，太大影响主任务，太小起不到均衡作用。

其次是显存问题。经常有人问“MoE 架构要全部参数进显存吗”，答案是：训练时基本是的，因为反向传播需要所有被激活专家的梯度，而且优化器状态也要占显存。推理时可以只加载部分专家，但训练阶段很难省。这也是为什么 MoE 的训练成本比同激活量的稠密模型高不少。

最后是RL 特有的不稳定性。MoE 的路由本身是离散的，加上 RL 的奖励信号又是稀疏的，两者叠加会让训练曲线非常抖。我见过不少团队在 MoE 上做 RL，前几千步 loss 看着还行，突然就崩了，排查半天发现是某个专家的路由概率塌缩了。

3. Agent 基准测试到底测什么：别被数字忽悠了

3.1 Agent 基准的常见类型

热搜里说“多个 Agent 基准比肩闭源旗舰”，这句话信息量其实不大，因为 Agent 基准这个筐里装的东西差别很大。我按难度和代表性给你排一下。

很多模型宣称在 Agent 基准上表现好，其实测的是第一类，也就是单轮工具调用。这种任务用 prompt engineering 就能做得不错，不一定需要大规模 RL。真正能体现 RL 价值的是后面几类，尤其是需要多轮交互和错误恢复的任务。

3.2 评测里的“水分”在哪里

我自己做过 Agent evals，深知这里面的门道。几个常见的注水点：

一是环境太干净。真实环境里工具会报错、网络会超时、页面会变样，但很多评测环境是理想化的，工具永远返回正确格式。这种环境下训出来的模型，一到生产就露馅。

二是任务可枚举。如果评测集的任务类型就那么几种，模型很容易过拟合到这些模式上。真正难的是开放域任务，但开放域又没法自动评分，所以大家还是倾向于用封闭集。

三是评分标准宽松。有些基准只看最终答案对不对，不看中间过程。这就导致模型可能用错误的方式碰对了答案，实际能力被高估。

注意：看一个模型的 Agent 能力，别只看总分，要看它在“需要多轮交互”和“需要错误恢复”这两类子任务上的表现。这两项才是 RL 后训练真正能拉开差距的地方。

3.3 从基准到生产：差距有多大

我个人的经验是，一个模型在标准 Agent 基准上能到 70 分，放到真实业务里大概只能发挥 40 分的水平。差距主要来自三个方面：环境的噪声、任务的长尾、以及工具的不稳定。

所以如果你是想用开源模型做 Agent 开发，我的建议是：先拿基准筛一遍，选出两三个候选，然后一定要用自己的业务数据做一轮小规模评测。这一步不能省，否则上线后你会发现基准分数完全是幻觉。

4. 六天两千万：钱到底花在哪了

4.1 算力成本拆解

我们来做个粗略的账。假设用的是高端训练卡，单卡每小时成本按市场价算，一个千卡集群跑一天就是几十万。六天下来，光机器成本就几百万。但这只是基础，真正的大头在推理采样。

Agent RL 的采样和普通 RLHF 不一样。普通 RLHF 一次生成一个回复就完事，Agent RL 要生成一整条轨迹，中间还要调用工具、等待环境反馈。这意味着 GPU 在很多时候是在等，而不是在算。为了不让 GPU 空转，就得开更多的并行环境，而每个环境背后又是一份推理资源。

我算过一个账：一个中等规模的 Agent RL 训练，采样和训练的计算量比例大概是 5:1 甚至 10:1。也就是说，你花在生成轨迹上的算力，是花在梯度更新上的五到十倍。这就是为什么“烧钱”主要烧在采样上。

4.2 为什么不能省这笔钱

有人会问，能不能用离线数据代替在线采样？这就是 IQL 这类离线强化学习想解决的问题。但在 Agent 任务上，离线数据有几个致命问题。

第一，离线数据覆盖不了模型自己会走到的状态。Agent 任务的状态空间是组合爆炸的，你收集的数据再多，也只是汪洋大海里的一瓢。模型一旦走到数据没覆盖的状态，就不知道该怎么办了。

第二，离线数据里的动作是旧策略产生的，和新策略的分布不匹配。这个问题在离线 RL 里叫分布偏移，处理起来很麻烦，通常需要重要性采样或者保守估计，效果往往不如在线采样。

第三，Agent 任务的奖励延迟很长，离线数据很难做信用分配。你不知道是哪一步导致了最后的成功或失败，梯度信号就传不下去。

所以在大规模 Agent RL 上，在线采样基本是绕不开的。这笔钱省不了，只能想办法提高采样效率。

4.3 提高采样效率的几个实操方向

虽然钱省不了，但效率可以优化。我总结几个实际有效的方向。

一是环境复用。一个环境跑完一个任务后，不要销毁，重置状态继续用。环境的创建和销毁开销在 Agent 训练里占比不小，复用能省不少。

二是异步采样。采样和训练解耦，采样进程持续往缓冲区里塞数据，训练进程从缓冲区取数据。这样 GPU 不会因为等数据而空转。代价是数据会稍微“旧”一点，需要用重要性采样修正。

三是课程学习。先训简单任务，再训难任务。简单任务的 rollout 短，采样快，能快速让模型学到基本能力。等模型有一定基础了，再上难任务，这时候成功率高了，有效样本的比例也高。

四是奖励塑形。稀疏奖励是采样效率的杀手。如果能设计一些中间奖励，比如“正确调用了工具给 0.1 分”，能显著加快学习速度。但要注意别过度塑形，否则模型会钻空子。

5. 想复现类似思路：普通开发者的入手路径

5.1 先搞清楚你需不需要大规模 RL

不是所有场景都需要大规模 RL。如果你的任务比较简单，比如单轮工具调用，那用 prompt engineering 加少量微调就够了。大规模 RL 适合的是：任务复杂、多轮交互、有明确成功标准、且你有足够的算力预算。

我见过不少团队，明明任务很简单，非要上 RL，结果投入产出比很差。所以在动手之前，先问自己三个问题：任务是不是多轮的？有没有自动化的成功判定？失败的成本是不是很高？三个都是“是”，才值得考虑 RL。

5.2 从小规模开始：单机也能跑通流程

如果你决定要试，别一上来就搞千卡集群。先用单机或者几台机器，把整个流程跑通。具体来说：

第一步，选一个开源模型，最好是带 MoE 的，这样能顺便熟悉 MoE 的负载均衡代码。模型不用太大，几 B 参数的就行。

第二步，搭一个简单的 Agent 环境。不用太复杂，比如一个能查天气、能算数的工具集就够了。关键是环境要能自动判定成功与否。

第三步，用 TRL 或者类似的库做 RL 训练。TRL 对强化学习的封装比较好，入门门槛低。先用 GRPO 跑一遍，看看能不能学到东西。

第四步，观察训练曲线。如果 reward 一直不涨，先检查奖励设计；如果涨了又崩，检查 KL 惩罚和负载均衡损失。

这个流程跑通，你对 Agent RL 的全貌就有感觉了。之后再考虑扩大规模。

5.3 工具链选型：别重复造轮子

现在做 Agent RL 的工具链已经比较成熟了，没必要什么都自己写。我列几个常用的：

• 训练框架：TRL、verl、OpenRLHF，各有侧重。TRL 上手快，verl 适合大规模。
• 环境框架：自己写简单的就行，复杂的可以用现成的 Agent 框架，但要注意和训练框架的对接。
• 评测工具：Agent evals 这块开源的不多，很多团队是自己搭。建议先用公开基准，再补自己的业务评测。
• MoE 相关：负载均衡的代码在主流模型实现里都有，直接参考就行，别自己从头写。

提示：工具链的选择要看你的团队规模。小团队优先选上手快的，大团队才考虑性能和扩展性。别为了“先进”而选一个团队驾驭不了的工具。

6. 实操中的坑与排查：我踩过的那些雷

6.1 训练不稳定的典型表现与处理

Agent RL 训练不稳定是常态，稳定才是意外。我遇到过的典型问题有这么几类。

奖励不涨。最常见的原因是奖励太稀疏，模型随机探索根本碰不到正样本。解决办法是加中间奖励，或者用课程学习从简单任务开始。

奖励涨了又崩。通常是 KL 散度失控，模型跑偏了。检查 KL 系数是不是太小，或者奖励模型是不是被 hack 了。

MoE 路由塌缩。表现为某几个专家的使用率接近 100%，其他专家闲置。这是负载均衡损失系数太小导致的，调大一点通常能缓解。

显存溢出。Agent RL 的显存占用比普通训练高，因为要保存多条轨迹。解决办法是减小 batch size，或者用梯度检查点。

6.2 常见问题速查表

6.3 几个容易被忽略的细节

第一，工具返回的格式要统一。Agent 训练里，工具返回的格式如果不一致，模型会花大量精力去解析格式，而不是学任务本身。建议在环境层做一层标准化。

第二，超时处理要明确。真实环境里工具会超时，训练时也要模拟这种情况，否则模型学不会处理超时。但超时时间设多少，需要根据任务调。

第三，随机种子要固定。Agent 任务的随机性很大，不固定种子的话，两次实验没法对比。这个看起来是小事，但实际影响很大。

第四，日志要记全。除了 loss 和 reward，还要记每个工具的成功率、平均交互轮数、专家使用率。这些指标在排查问题时非常有用。

7. 开源模型做 Agent 的现状与个人判断

7.1 开源和闭源的差距在缩小，但没消失

从最近的趋势看，开源模型在 Agent 基准上确实追得很猛。这背后的原因，一是 RL 后训练的方法越来越成熟，二是社区在数据和方法上的共享越来越充分。但差距还是有的，主要体现在复杂任务和长尾场景上。

闭源旗舰的优势在于，它们有更多的资源去做数据清洗和奖励建模，而且可以反复迭代。开源模型受限于算力和数据，通常只能在一个方向上做到极致。所以你会看到，开源模型在某些基准上能打平，但换个任务就掉下去了。

7.2 对开发者的实际意义

对普通开发者来说，开源模型变强是好事。以前做 Agent 开发，要么用闭源 API 花大钱，要么用开源模型效果差。现在开源模型能用了，成本能降不少。

但要注意，开源模型的部署和维护成本不低。尤其是 MoE 模型，推理时需要足够的显存，而且要做负载均衡。如果你只是小规模用，可能还是 API 更划算。如果量大，自部署才有优势。

7.3 后续可以关注的方向

我个人比较关注两个方向。一是更高效的 RL 算法，现在的采样效率还是太低，如果能用更少的样本学到同样的能力，成本能降一个数量级。二是更好的评测方法，现在的 Agent 基准还是太粗糙，没法真实反映模型在生产环境的表现。

另外，MoE 和 RL 的结合还有很多没解决的问题，比如路由的稳定性、专家的专业化。这些问题的解决，可能会带来下一波开源模型的质变。

最后分享一个我自己的体会：做 Agent RL，最难的不是算法，而是环境。一个好的环境设计，能让训练效率翻倍；一个糟糕的环境，能让再好的算法也白搭。所以如果你要入这个坑，先把环境搭好，再谈算法。这个顺序不能反。