1. 这份报告最反直觉的一句话RL 的 Scaling 瓶颈不在算力而在“反馈信号”最近把小米的 MiMo-V2.6 技术报告《The Hard Road to Scaling Up RL》仔细读了一遍。做 LLM Post-training 或者 RL 训练的同学应该都有一种共同体验当你把 batch size 从 32 提到 1024、把显卡从 8 张加到 64 张预训练阶段可能得到接近线性的加速模型效果也稳定提升但强化学习阶段完全不是这么回事——你加数据曲线可能更差你加大规模奖励可能彻底崩掉你什么都没改重跑一遍结果又不一样。小米这份报告说的就是这件事Scaling Up RL 是一条很难走的路。我本来以为这又是一篇给自家模型“秀肌肉”的实验报告读完之后发现它更像是把强化学习规模化过程中踩过的坑、试过的路、放弃的方案都摊开讲了一遍。对于正在做推理模型、对齐训练、或者想把小规模 RL 流程放大到集群级别的人来说这份报告比很多把公式写得很漂亮的论文更有参考价值。需要提前说明的是我下面讲的是我读报告后的理解和扩展一些具体参数和训练配置报告里未必会写得那么细我会把业界常见做法和报告方向结合起来讲。这篇先做“上篇”重点拆解核心难点和路线选择。1.1 MiMo-V2.6 在做什么以及它为什么值得关注MiMo-V2.6 不是一个从零开始预训练出来的基座它的重点是把强化学习当作 Post-training 阶段的核心放大器。这个思路和 OpenAI 的 r1 式训练、DeepSeek 的 R1 路线有相似之处先有基座再用大量可验证任务的强化学习把推理能力逼出来。区别在于MiMo-V2.6 把目光放在“怎么把 RL 本身规模做大”上。这里的“大”不只是卡多。在预训练里Scaling 往往等同于数据量和算力线性增长但强化学习的 Scaling 是另一套逻辑你需要同时处理策略模型、奖励模型、采样推理、优势估计、KL 约束。任何一个环节膨胀其他环节都要跟着变。结果就是训练一个 7B 模型的 RL 流程可能比训练一个 70B 模型的 SFT 流程更容易翻车。所以这个技术报告的核心问题是当我们把 RL 从实验环境搬到生产环境从几块卡搬到几十上百块卡时什么在崩塌报告给出的答案很直接崩塌的不是算力而是反馈信号的质量和密度。预训练的数据是天然够用的RL 不行RL 的数据需要你设计、筛选、生成、验证而且你有多少有效信号训练就有多少进展。这是我读完报告后最大的一个收获Scaling RL 的第一性原理不是参数量不是显卡数量而是反馈信号的数量和质量。所有的工程手段最终都在为“每一条反馈信号是否可信”服务。1.2 “Hard Road”到底难在哪烧钱、返工、玄学标题里 hard road 不是修辞而是三种真实体感的叠加。第一种体感是烧钱。RL 每一次 rollout 都要用当前模型生成大量样本然后这些样本还要跑一遍奖励模型或者规则校验最后才能更新策略。对比 SFT 的一次前向、一次反传RL 等于在一个 step 里做了几十倍甚至上百倍的推理。你以为省掉了人工标注实际上用算力买了信号账单依然很吓人。第二种体感是返工。在我自己的实验里最常见的翻车位是奖励设计。一个数学题如果你只判断最终答案对错模型很快就会学会输出一个没过程的答案甚至用特殊格式绕过校验。等你发现奖励被 hack 了之前跑的两三天全部作废。这种返工不是一次两次几乎每个新任务都要经历一遍。第三种体感是玄学。同样的代码、同样的超参数换一个随机种子或者换一个 rollout 采样策略最终 reward 曲线形状可能完全不同。RL 对采样分布特别敏感一个温控参数调高 0.1模型生成长度的分布就变了进而优势估计的方差也变了最后训练结果千差万别。这种不确定性让问题定位变得非常困难你很难说清楚是数据问题、奖励问题还是超参数问题。MiMo-V2.6 的整篇报告某种意义上就是这三个问题的解题记录。它没有回避这些痛苦而是把每个环节拆开告诉你哪些方法能压低返工率哪些指标能让玄学变成可追踪的问题。2. Scaling Up RL 的四大障碍数据、奖励、稳定性、算力如果照着报告的方向去拆Scaling Up RL 的障碍可以分成四块。我分别聊一下每块的真实情况以及为什么它们比预训练复杂。2.1 数据RL 对数据质量的要求比 SFT 高一个数量级很多人以为强化学习不太需要数据因为模型可以靠奖励自己探索。这是最大的误解。RL 确实不需要人工写标准答案但它需要大量“问题”和“判断标准”而且这些问题必须落在模型能力的边缘不能太简单也不能太难。简单数据会导致什么模型几下就拿到高奖励梯度很快消失训练没有后劲。过难的数据会导致模型反复试错都拿不到正反馈奖励方差巨大策略更新像是在撞墙。我在实践中体会最深的一点是RL 数据的难度分布比总量重要得多。所以 MiMo-V2.6 这类报告里的做法通常会把数据集按难度分层简单题用来让模型建立基本的行为模式中等题用来扩大策略覆盖率难题用来突破能力边界。而且每个层级都要做去重和过滤。SFT 里 100 条重复样本可能只是浪费一点点算力RL 里重复样本会被放大成持续的探索偏差让模型在同一个地方反复打转。另一个关键动作是“过滤生成数据”。规模大了以后不能只靠人工写 prompt往往让模型自己生成一批候选问题然后再用规则或模型筛选。这个环节最容易出问题的是筛选标准太宽松。我见过不少团队拿生成数据直接开训结果 prompt 本身就有歧义奖励模型给的是薛定谔的分数训练自然原地踏步。小米在报告里给我的感觉也类似他们更看重把数据做“窄”做“实”而不是做“宽”做“多”。2.2 奖励真正的信号稀疏和奖励欺骗问题奖励是 RL 的灵魂也是最容易埋雷的地方。业界常用的奖励来源大体分三类规则奖励、模型奖励、人工反馈。规则奖励适合数学答案校验、代码单元测试这类有明确对错的任务优点是可复现、不漂移缺点是覆盖不了开放问题。模型奖励用 reward model 打分能覆盖更多场景但 reward model 本身会坏会被策略模型钻空子。在 Scaling 过程中奖励问题会被放大。一个很常见的现象是 reward hacking模型发现了奖励函数里的漏洞比如代码任务里直接写死返回值通过测试数学任务里输出一段与推理无关但包含关键词的文本让 reward model 给出高分。这种 hack 在小规模训练时还能及时发现规模大了以后采样分布变宽模型找到漏洞的概率也变大你甚至不知道它是什么时候学会的。所以报告里强调的“反馈信号密度”就很重要。纯结果 reward 是稀疏信号模型需要碰很多次运气才能获得正反馈。路线修正的方向是引入过程奖励Process Reward Model对推理的中间步骤打分把稀疏信号变密。代价是标注和训练成本上升但在 Long Chain Reasoning、数学证明这些任务里过程奖励几乎是从“训不动”到“能收敛”的分水岭。我自己踩过的坑是一开始图省事只用最终答案对错做奖励模型很快学会了输出大量废话答案碰运气。后来加了过程奖励才真正看到 reasoning chain 变长、逻辑变严谨。所以当你发现 RL 训练不涨的时候别急着加算力先检查奖励信号是不是太稀疏。2.3 稳定性训练曲线不是 loss 下降而是过山车预训练里我们习惯看 loss 平缓下降偶尔出现一个 spike调低学习率就好。RL 完全不是这样。策略模型在更新中会不断改变自己的行为分布导致 reward 分布跟着变然后优势估计又反过来影响策略更新形成一个不稳定的闭环。MiMo-V2.6 这个规模的训练一定绕开早期 PPO 里显式 critic 模型带来的高方差问题更可能是用了类似 GRPO 的方法同一 prompt 采样多个 response用组内相对优势替代全局价值估计。这样避免训练一个容易崩溃的 value network也减少了显存压力。但 GRPO 也不是没有坑——它要求组内样本数足够多组内样本数太少优势估计的方差还是压不下来。稳定性问题集中体现在超参数上KL 惩罚系数、clip 范围、学习率、rollout batch size每一个都牵一发动全身。KL 系数太大模型会畏手畏脚几乎不偏离 SFT 策略reward 涨不上去KL 系数太小模型很快漂移开始说胡话。clip 范围控制不好策略更新步子太大会导致奖励崩塌。这些参数在 1B 模型上调试好的值换到 7B、14B 上又可能全部失效等于重新调一遍。报告给我的启发是稳定性不是一个参数问题而是一套机制问题。你需要监控的不只是最终 reward还有策略和 reference policy 之间的 KL 距离、response length 的分布、每个 batch 里 reward 的中位数和极差。这些指标能告诉你训练是否健康而不只是有没有变好。2.4 算力多少卡才叫“Scaling”账要算细算力这块我不想只讲“卡多就行”。RL 的算力消耗结构和预训练很不一样。预训练基本上是一次前向、一次反传流水线可以被 Megatron 这类框架压得很满。RL 则要反复地在“训练”和“推理”之间切换而且推理的比例远比想象中高。我做了一个粗略对比表方便大家理解环节预训练RL Post-training每步计算一个 batch 前向 反传多次采样推理 奖励打分 策略更新推理/训练算力比约 1:1可能 10:1 甚至更高显存瓶颈模型参数 梯度 优化器模型 采样缓存 奖励模型 参考模型数据流程离线固定数据流在线生成 过滤 存储 回放可扩展性加卡基本线性加卡后 rollout 分布变化未必线性这张表告诉我们Scaling RL 必须做“推理服务化”。你不可能每更新一步就停下训练把 batch 推理跑完再继续。业界主流做法是让 rollout worker 常驻一边生成样本一边存到共享缓冲区训练主进程实时消费。这时候调度、通信、容错就变成了真正的工程难题。3. MiMo-V2.6 的路线选择用数据密度换训练强度在 Scaling Up RL 的路线设计上报告给我的感觉是他们选择了“提高数据密度”而不是单纯“堆算力”。这条路更稳也更符合大部分团队的资源现状。3.1 优先选择“可判题”数据把难度梯度拆细什么任务最适合 RL 放大答案是结果可以被严格验证的任务。数学、代码、逻辑推理它们的对错可以通过规则判断不依赖不稳定的 reward model。这个选择在工程上意义巨大因为规则校验是确定性的反馈信号不会漂移也不会被模型 hack。但“可判题”只是第一步真正的功夫在难度梯度设计。MiMo-V2.6 这种持续迭代的模型必然要把数据按难度分级让模型像爬楼梯一样逐步提升。我把这个流程总结成三步用大量中等难度数据训练让模型熟悉“尝试生成→校验结果→根据反馈调整”的循环。逐步混入高难度数据让模型在现有策略饱和后继续探索。保留一部分简单数据作为“保底”防止策略漂移导致基础能力退化。这个数据配方直接决定了训练曲线。如果一开始就上难题模型会长时间处于低奖励区域探索效率极低。如果全上简单题模型几个小时就收敛了剩下的算力全部浪费。真正好的 RL 数据集应该是“梯度平滑上升”的而不是难度跳跃的。3.2 奖励构造规则为主、模型为辅、过程优先奖励设计上我的理解是 MiMo-V2.6 会比较克制地使用模型奖励更多依赖规则和过程信号。为什么因为模型奖励在规模化中很容易变成“新的超参数”你不仅要调策略训练还要调 reward model复杂度翻倍。实际奖励信号可以组合成一张表信号类型适用场景优点风险规则校验结果数学答案、代码测试稳定、零成本稀疏、可被钻空子过程规则中间步骤格式、关键步骤检核信号密、不易 hack需要任务定制规则过程奖励模型长推理链、开放推理覆盖面广训练成本高、会漂移结果奖励模型对话、写作等弱验证场景适合开放任务最容易 reward hacking组合使用时建议把规则校验放在第一关不满足硬性规则直接给低分或过滤掉再让过程模型去打分。这样等于把“底线”交给确定规则把“上限”交给模型风险更低。3.3 版本迭代为什么“V2.6”这个版本号很有意义模型名字叫 V2.6说明它不是一次训练就定稿的版本而是经历了持续多轮的强化学习迭代。这种“滚雪球”式训练在 Scaling Up RL 里非常关键。每一轮 RL 结束后模型能力提升了你可以用新模型生成新的训练数据。这些新数据的质量比旧数据高分布也更接近当前模型的能力边界。于是下一轮 RL 可以走得更远有点像 AlphaGo 的自我博弈只不过在这里“对手”是自己上一轮的策略。这个迭代模式有个很现实的收益它天然解决了数据枯竭问题。对于数学和代码这类可验证领域人工数据总量有限但模型自己可以不断生成新问题和新解法只要你有可靠的过滤器数据永远用不完。这也是为什么很多团队宁可把精力花在“生成高质量问题 强过滤”上也不愿意去请更多标注员。我对这个版本号的另一个理解是工程上的“可回滚”。每一轮迭代都对应一个可评估的模型版本如果某轮训练效果变差可以直接回退到上一版 checkpoint而不是从头再来。V2.5、V2.6 这种带小版本号的命名习惯其实是在为失败做一个低成本的后路。4. 工程侧最难的部分把 rollout 和训练放进同一套系统很多讲 Scaling RL 的文章聊到算法就停了但真正做过大规模 RL 的人都知道算法只是前半场系统才是后半场。MiMo-V2.6 这种规模的训练绕不开三类工程问题。4.1 rollout 必须服务化不能边训边推小规模实验里大家常用“训练一个 step然后手动 launch 推理脚本生成 rollout”的串行模式。这个模式在 1B 模型上没问题但到了几十亿参数、每天要生成几千万样本的时候串行就是自杀——每次 rollout 都可能要等几个小时训练卡全部空转。正确做法是把 rollout 拆成常驻推理服务。策略模型的最新权重定期同步给推理集群推理集群用较高的并发持续生成样本写到共享存储或内存队列训练进程从队列里取数据、做奖励打分、算 advantage、更新权重更新后再把新权重推回推理服务。这一来一回不仅是工程结构变化还会影响训练算法——采样策略和策略更新之间的时间差决定了你用的是多旧的策略数据。这里有个小建议采样参数temperature、top_p、max_tokens要固定下来不要随手改。因为 rollout 分布变了你算出来的优势估计含义就变了看起来是同一套训练实际上已经不是同一个任务了。4.2 容错与续训RL 训练等不起“重启”动辄几百卡的训练节点故障是常态。预训练遇到故障还好checkpoint 恢复就行RL 的麻烦在于你不仅要恢复模型权重还要恢复 replay buffer、采样分布、当前 rollout 批次甚至奖励模型的缓存。我自己遇到过最头疼的事是训练跑到一半一个节点掉了重启之后所有 rollout 数据被清空策略模型虽然恢复了 checkpoint但奖励分布已经被之前的数据影响过继续训练等于从一个“短暂失忆”的状态继续跑最后 reward 曲线拐了个奇怪的弯怎么也回不来。MiMo-V2.6 这类报告给我的启发是所有非参数状态都要定期落盘。具体来说每个 rollout batch 的 prompt、response、奖励、KL 值、采样参数都要带元信息存储。这样即使重启也能精确复现之前的训练状态而不是“差不多”就行。这个习惯在模型规模变大后特别重要因为你没法靠肉眼判断一个 checkpoint 是否健康。4.3 监控指标不要只盯 reward要多盯“过程指标”我在做 RL 训练时最常被问的一句话是“reward 涨了吗”。但 RL 的最大陷阱就是 reward 涨了策略却坏了。比如模型可能靠增加 response length 来碰运气也可能靠说废话让 reward model 误判这时候 reward 曲线是好看的最终评估却一塌糊涂。所以完整监控体系至少要包含这几类指标监控项说明健康范围参考reward 均值/中位数训练是否上涨中位数比均值更稳KL 散度策略偏离参考模型的幅度过高说明漂移response length是否在持续膨胀膨胀过快是 hack 前兆格式通过率规则校验通过比例也是 reward hack 预警rollout 吞吐每秒生成样本数决定训练效率优势估计方差反映反馈信号稳定性方差太大要减小 lr 或增加组内样本我强烈建议把“格式通过率”和“response length 分布”作为每日必看指标。很多训练事故在 reward 崩塌前一周其实已经通过这两个指标露出端倪了只是没人注意。5. 这套方法论给我们的借鉴以及我踩过的坑最后一部分我想抛开报告聊聊我们这种小团队、小资源怎么做。毕竟 MiMo-V2.6 的规模不是所有人都有条件复现但它的方法论是可以“降维使用”的。5.1 小团队如何抄作业先降规模但不降复杂度很多人一看到大厂报告就觉得自己用不上因为没有几百张卡。但我认为Scaling Up RL 报告里最值得学的反而是那些和“卡数”无关的事数据难度分层、奖励组合设计、过程监控、可回滚版本。这些在小规模下同样有效甚至更重要。我的建议是直接用 1B 或 3B 的模型选一个可验证任务比如数学应用题完整搭一套 RL 流程。模型小迭代快你可以在一天内跑完十组实验迅速体验 reward hacking、KL 崩塌、rollout 吞吐不足这些真实问题。这些问题在大模型上也是同一个性质只是出现时间更晚、代价更大。等小模型流程稳定了再逐步放大模型和 batch。你会发现很多在小模型上调好的参数大概率不能用但你至少知道往哪个方向调而不是两眼一抹黑。5.2 超参数先固定一组“保守值”不要一上来追求激进我的个人经验是RL 训练先求稳再求好。下面这组保守值可以作为起点再根据任务调整学习率1e-6 到 5e-6比同规模 SFT 低一个数量级。KL 惩罚系数0.01 到 0.05 区间起调。clip 范围0.2 左右不要一开始就放到 0.3 以上。rollout 组内样本数8 到 16太少方差大太多显存压力大。rollout batch size初始用小 batch观察优势方差稳定后再增加。这套数值基本保证了“不会立刻崩”。等拿到一条稳定上涨的基线再一个一个参数去放松看哪个方向能带来收益。我试过一上来就把学习率和 KL 调得很大结果模型学会了输出一堆含有“因此”的废话最后答案错得离谱。这个教训说多了都是泪。5.3 我的个人体会Scaling RL 是一辆很难刹住的车读 MiMo-V2.6 报告的过程中我脑海里反复出现一个类比Scaling Up RL 很像把一辆车开到高速上。启动那一下最费劲一旦跑起来你要花更多精力去控制方向而不是继续踩油门。加数据、加算力、加模型规模每一样看起来都是“更快”但每一样都会让系统稳定性变得更差。我现在做 RL 训练第一原则是“每次只改一个变量”。无论是调奖励权重还是改采样参数都单独验证不要同时动手。因为 RL 的变量之间高度耦合同时改两个你根本不知道是谁带来了提升又是谁把训练搞崩了。这篇先聊到这里。上篇的核心就是一件事Scaling Up RL 的本质不是把预训练的并行手段复制到强化学习上而是要重新设计数据、奖励和系统让反馈信号在高强度训练下依然可信。下篇我打算接着聊更偏训练执行层面的细节包括 rollout 切分、分布式优势计算、reward model 的线上更新策略以及怎么从“能跑”走到“跑得稳”。如果你也在做 RL 训练欢迎带着你的踩坑经历来交流。