小米这份《MiMo-V2.6: The Hard Road to Scaling Up RL》技术报告名字起得很直白——Scaling Up RL的路不好走。我是在模型发布那几天看到的这份文档读完第一感受是终于有人愿意把RL训练里那些“平时不敢公开”的工程细节写出来了。市面上聊RL训练的帖子不少但大多数都停留在“用GRPO、上规则奖励、batch开大一点”这个层面真正的硬骨头——并行策略怎么选、vLLM吞吐率为什么上不去、GPU天天坏怎么办——很少有报告愿意展开讲。MiMo-V2.6这份报告恰好把这些都摆在了台面上。这份报告本质上讲的是小米拿一个已经具备不错推理能力的蒸馏版模型在纯RL不依赖SFT条件下继续训练最终在MATH-500这类数学基准上把正确率从大约七成多拉到九成左右。听起来只是一个效果数字的跃升但背后的工程投入非常大。如果你正在做或者准备做reasoning model的RL训练或者你只是想搞清楚“scaling up RL”到底难在哪这篇拆解应该对你有用。我按上篇和下篇两部分来读上篇聚焦技术路线与主链路设计下篇聚焦基础设施层面的工程细节。今天先讲上篇。1. 报告在讲什么从蒸馏模型到纯RL的艰难一跃1.1 先看它的起点一个已经会做数学题的模型要理解MiMo-V2.6在做什么得先回到它的起点。MiMo-V2.6不是从零训练出来的模型它的底座是MiMo-V2.5——一个通过蒸馏方式获得的模型通俗点说就是让一个很强的教师模型输出解题过程拿这些数据去训练一个更小的学生模型。蒸馏版的问题在于它已经具备相当不错的数学解题能力但输出风格和推理习惯还停留在“普通聊天模型”的层面。报告中有一组数据让我印象很深蒸馏版MiMo-V2.5在MATH-500上的正确率大概在77%左右这已经是一个能打的数字了但经过纯RL训练后的MiMo-V2.6这个成绩提升到了九成上下。十几分的提升在数学基准上非常可观。更关键的是这个提升是在没有额外SFT数据、没有依赖更强教师模型的情况下实现的。换句话说报告想表达的核心观点之一是蒸馏版模型里其实已经有了推理能力只是它不知道如何在回答里稳定地把推理过程展现出来。RL做的不是“教会它新知识”而是把已有的解题能力对齐到我们期望的输出模式上。1.2 报告的核心结论RL不是让模型“学会”而是让它的偏好对齐很多团队做RL时会陷入一个误区——把RL当成一个“补课”工具指望它能给模型灌输更多知识。但MiMo-V2.6的结果恰恰说明当模型能力已经达到一定水位时RL真正解决的问题是偏好对齐。解释一下这个“偏好”是什么意思。模型在训练过程中会形成自己的一种输出倾向。比如蒸馏版模型可能用到正确的数学推导但最后答案格式不统一、推理链条太短、中间步骤跳跃、甚至会在不该犹豫的地方反复试探。这些都不是“知识缺陷”而是“行为习惯问题”。RL用奖励信号去调整这些行为习惯让正确的解法以更高的概率被选中让推理过程变得更完整、更稳定。报告里有个说法让我觉得非常准确——RL训练像是在给运动员做比赛训练。运动员的基本动作早就练到位了但真正到了赛场上怎么分配体力、怎么在不同对手面前调整策略这些需要通过实战来打磨。模型也一样知识底座是预训练和蒸馏打好的但“在推理任务中稳定发挥”这件事确实需要RL来校准。1.3 报告的整体结构训练策略与基础设施两条线读这份报告你会发现它内部其实是两条线索在并行推进。第一条是RL的训练策略就是这个模型具体怎么训练的包括数据怎么配、奖励怎么设、优化算法怎么调、整个训练流程怎么设计。第二条是RL的基础设施也就是把训练策略真正跑在大规模集群上时遇到的各种工程问题。这两条线对读者的价值完全不一样。训练策略部分适合算法背景的读者你可以从中看到别人踩过哪些坑、做过哪些选择基础设施部分则更适合工程师去研究因为涉及并行策略、通信优化、故障处理这些实打实的问题。坦白说很多公开报告会把工程部分一笔带过但MiMo-V2.6反其道而行之工程细节写得非常实在。这也是这份报告最难得的地方。2. 纯RL主链路设计数据、奖励与训练策略2.1 为什么选择从蒸馏模型开始先讲第一个关键选择为什么从一个蒸馏模型出发而不是直接拿基础模型上RL原因其实不复杂——RL训练非常敏感模型的内在能力决定了训练上限。如果你从一个刚做完预训练的基础模型开始它连复杂的数学推导都还不稳策略梯度给出的奖励信号很容易被噪声淹没。模型需要尝试很多次才能碰巧做对一道题而错误的尝试占绝大多数梯度信号会被这些大量失败样本稀释训练自然很难稳定收敛。蒸馏模型相当于帮RL省掉了“从零探索”的过程。教师模型已经把解题模式示范过一遍学生模型学会了这些模式RL只需要去重排这些模式的优先级——哪些应该多输出、哪些应该少输出。这个起点使得训练数据量可以相对小训练轮次也能更快见效。报告里把这条路称为“从蒸馏迈向RL的务实路径”我觉得这个定位很准确。2.2 数据规模不大但训练轮次要足数据是RL里最容易让人纠结的部分。MiMo-V2.6的处理方式非常克制数据量不大大概几万条数学问题远少于预训练动辄上万亿token的规模但每一道题都经过筛选覆盖了基础计算、代数、几何、竞赛题等不同类型难度和题型分布都做了人为控制。训练轮次方面报告给出的方向是让模型在相对少的数据上反复多轮学习。这和很多人的直觉相反——有人会认为RL需要海量数据模型才见得多、学得广。但报告的实际经验是在数学推理这个场景下精选数据加多轮次的效果比堆数据数量的效果更好。因为每一轮训练后模型的表现都在变之前的错题会变成新的难点重复训练时模型对这些难点的处理会越来越细腻。如果每轮都换全新的数据模型反而没有机会对薄弱环节进行反复修正。这里我个人再补充一点数据里应该包含一部分“有难度梯度”的题不能全是简单题也不能全是竞赛题。简单题帮模型巩固已有能力中高难度题提供有效的学习信号。MiMo-V2.6的数据配比思路值得抄作业。2.3 奖励设计规则校验为什么够用奖励是RL里影响成败最大的一环MiMo-V2.6选择了一条很多人想做但不敢做的路——只用基于规则的结果奖励不要过程奖励也不要额外训练奖励模型。怎么理解“基于规则的结果奖励”就是检查模型给出的最终答案是否和标准答案一致一致就给高分不一致就低分。这要求任务本身必须有可验证的答案数学题天然满足这个条件。报告里没有采用重构过程奖励的方案主要原因在于过程奖励需要训练一个额外的奖励模型而奖励模型本身又会引入新的问题比如reward hacking、过拟合到奖励模型的偏好上、训练不稳定等。有个形象的类比是你要判断一个人会不会游泳不需要全程录像分析他的手部动作和呼吸节奏只需要看他在水里能不能游到对岸。数学题也是一样结果对了就说明大概率推理方向是对的过程中的小瑕疵可以让格式约束去兜底。这种设计当然有牺牲——无法精细约束过程的每一步质量。但报告用了一个很聪明的补救方式在prompt里做显式的格式要求让模型必须按特定结构输出推理过程。这样一来虽然奖励函数不关心过程但模型在格式约束下推理过程的完整性也被间接保证了。2.4 优化算法与KL约束GRPO的调教要点训练算法的选择上MiMo-V2.6遵循了当前推理模型训练的主流路线使用类似GRPO的在线策略优化方法。GRPO的核心特点是不需要训练一个独立的critic网络来估计状态价值而是用同一个prompt采样出来的一批样本在组内做相对比较用组内奖励的相对高低来估计优势值。这个思路的好处非常明显省掉了critic模型的训练开销资源消耗更低训练过程更稳定。在数学推理这种任务里奖励本身是确定性的组内相对比较已经能提供足够好的优势信号。如果任务本身奖励噪声大GRPO的优势估计方差就会变大那就得考虑换PPO或者加critic。但GRPO也有需要仔细调的地方。组内采样数量G值直接影响到优势估计的质量G值太小优势估计方差大训练不稳定G值太大虽然估计更平滑但每次迭代的采样成本成倍上升。报告给出的经验是取一个适中的G值同时配合一个比较小的KL系数来限制策略的偏移。KL约束这里也要多说两句。RL训练过程中策略会因为奖励信号的驱动不断更新如果没有约束模型可能会越来越偏离它最初的能力分布出现奖励分数很高但回答质量明显变差的情况。KL散度惩罚就是用来拉住这个“漂移”的。系数设太大模型的更新幅度太小训练效果差设太小模型又容易放飞自我。这个系数的调节需要结合训练过程的参考模型选择一起看。3. Scaling Up的工程真相当RL跑在千卡集群上3.1 并行策略DP、TP、PP怎么组合才合理读到这里如果你以为RL和普通大模型训练只是数据量和奖励函数的区别那就低估了它。RL的复杂度提升不光来自算法更来自它同时包含了训练和推理两个环节而这两个环节对资源的需求完全不同。训练侧喜欢大batch和模型并行倾向于把模型参数切分到多张卡上做并行计算推理侧则更看重吞吐率和显存占用希望在单位时间内生成尽可能多的token。MiMo-V2.6在千卡规模集群上的做法是把数据并行DP、张量并行TP和流水线并行PP多种策略组合起来并阶段性地把参数从训练引擎同步到推理引擎。组合并行策略说起来容易做起来全是细节。每种并行方式都有自己的通信开销TP的all-gather、PP的micro-batch传输、DP的梯度同步叠加在一起会让通信模式变得非常复杂。报告里明确提到了一个现象在TP8的配置下NCCL通信开始频繁出现卡顿甚至超时。原因在于TP的集合通信操作非常依赖卡间带宽8张卡一组意味着每次前向和反向传播都要做多轮全量同步一旦某个节点网络抖动整组训练都被拖住。排查这类问题有一个实用的思路先用性能分析工具看通信算子占总耗时的比例确定瓶颈在通信还是计算再用超时日志对比不同TP尺寸下的耗时分布判定是配置不合理还是硬件问题。这个经验不只适用于RL任何大规模并行训练都适用。3.2 vLLM吞吐率掉到30%问题出在sub-token mask这一节是整份报告里最让我觉得“值回票价”的部分。MiMo-V2.6在2000卡规模下跑RL时发现vLLM的token吞吐率只能达到设计峰值的30%左右。按照常规思路第一反应一般会先怀疑显存不够、并发参数没调好、或者是模型太大导致batch上不去——但报告排查下来真正的问题出在Attention softmax里一个叫sub-token mask的算子上。解释一下这个sub-token mask。在推理模型的训练中模型输出会涉及内部推理token和最终答案token等不同角色。为了让注意力机制正确处理这些token之间的关系需要在softmax层加入特定的mask逻辑。问题在于通用实现的mask逻辑为了兼容各种边界情况在算子层面引入了大量不必要的分段计算和内存访问。小规模应用时这点开销无所谓但到了2000卡规模、每秒要生成海量token的时候这个算子的低效被放大了好几倍直接把吞吐率拖到了谷底。修复方向不算神秘——重写这部分算子把mask语义封装成更高效的kernel减少冗余计算。这事最值得思考的地方在于大规模RL的瓶颈往往不在“大模型”身上而藏在“小算子”里。你很难在小规模环境发现这类问题但一上规模它就成了拦路虎。如果有团队正在做千卡级RL我建议一早就对推理框架里的算子做性能摸底别等吞吐率崩了再排查。3.3 每天2.5%的GPU故障率容错不是可选项报告中另一个毫不避讳的工程现实是集群每天大约有2.5%的GPU需要重启。这个数字单看不大但换算到2000卡的集群里意味着每天有几十张卡出问题。一轮RL训练往往要跑好多天只要中途出现几次故障处理不及时整个训练就要反复回滚到checkpoint浪费的有效算力非常可观。我过去自己的训练经验里也有类似感受大规模训练里你不可能指望一个集群“稳定跑完一轮”。对故障率要有预期并且提前把容错写进系统设计。MiMo-V2.6的处理方式我认为很有参考价值——做故障感知的调度把新任务分配到健康节点上避开已知故障卡同时把checkpoint保存频率和故障发生的平均间隔对齐尽量减少每次回滚丢失的进度。关于checkpoint频率这里其实有一个权衡。频率太高保存本身会占用大量IO和存储资源频率太低一旦出现故障回滚的代价会很大。比较实用的做法是先统计集群的实际故障间隔分布再倒推一个合理的checkpoint周期。很多团队一上来就设一个“看起来很合理”的固定值但其实没有结合自己的硬件环境做校准出了问题才被动。3.4 目标网络更新一个容易被低估的细节最后再聊一个很多人不重视的细节目标网络的更新时机问题。在PPO、GRPO这类算法中通常会有一个参考模型reference model来约束策略的更新幅度计算KL散度惩罚时要用它。问题是这个参考模型应该多久更新一次如果长期不更新策略会在训练过程中越走越远KL惩罚项逐渐失真模型可能悄悄偏离原本的能力分布在数学题上的输出变得更加激进甚至胡言乱语。如果更新太频繁参考模型又和策略模型绑得太紧KL约束形同虚设整个训练退化成没有参考的裸优化。MiMo-V2.6的讨论比这个更深入一层因为并行策略会影响更新语义。在数据并行、张量并行、流水线并行等不同模式下参数同步的时机和顺序都不同目标网络的更新语义也随之不同。如果团队没有意识到这个问题不同并行策略下跑出来的RL训练行为会很不一样看起来像玄学实际上没有对齐更新语义。这个细节在单机八卡的环境里几乎不显形但一旦上到千卡规模就是影响稳定性的一个关键变量。下篇我应该会专门展开讲这部分。4. 这份报告给我的几条现场笔记4.1 想复现这条路线先选对任务类型如果你看完这份报告也动了“拿RL训练一个推理模型”的心思我的第一条建议是从规则可验证的任务入手。数学题、代码题、逻辑推理题这些都可以。规则可验证意味着奖励信号干净、确定、可复现。数学题答案不就错、代码题能不能跑通编译和测试这些都有明确标准。为什么强调这一点因为主观任务的奖励设计实在太容易翻车。对话质量、文章风格、内容相关性这些要么需要训练一个奖励模型要么需要引入人工反馈。奖励模型的训练本身就是一个新项目它有自己的一套坑等着你踩。而规则可验证任务完全不依赖这些奖励函数写一个规则判定器就够了RL训练的主线可以保持纯粹。4.2 数据精选优于数据堆量第二条经验来自报告里的数据策略几万条精选数学题训练多个轮次效果优于盲目堆几十万条数据。这里面的原因我在前面解释过再补充一点实操层面的理解。RL训练中每轮迭代模型的表现都不一样上一轮做错的题下一轮可能变成新的难点上一轮已经掌握得很好的题下一轮又可能被“遗忘”。只有让模型反复轮训同一批高质量数据它才有机会在这些难度波动中持续修正自己的策略。如果每一轮都换新数据模型还没来得及巩固薄弱环节新的挑战又来了训练就变成“到处点火、到处灭火”。所以数据纳入门槛要高可以少但每题都要过关并且难度分布必须有梯度。把一两道偏题难倒模型不算本事稳定的综合提升才是目标。4.3 工程预算要提前算好故障、回滚、监控第三条经验最不性感但最关键。MiMo-V2.6的经验告诉我们大规模RL训练里故障不是“意外情况”而是“日常状态”。你需要在项目启动前就把故障率、回滚窗口、监控策略这些内容纳入预算。我建议每个团队在开始RL训练之前至少做三件事第一统计历史训练里GPU故障的平均间隔算出合理的checkpoint周期第二准备一套自动容错和恢复流程别等故障发生了再找人去手动处理第三把集群的健康状态监控和任务调度打通让新任务自动避开已知故障节点。这三件事做完你的RL训练稳定性就已经超过大多数团队了。4.4 推理侧优化是RL提速的关键最后一条笔记来自vLLM吞吐率那个案例它提醒了我一个经常被忽视的事实RL训练里rollout阶段的token生成往往是整个训练循环里耗时最长的环节。模型采样要生成大量的候选答案每一步都要经过推理引擎这个阶段的吞吐率直接决定了训练的总时长。很多团队在RL提速上把注意力全部放在训练侧调并行、调梯度同步、调学习率但推理侧可能还跑在了一个很粗糙的配置上。MiMo-V2.6的30%吞吐率案例说明一旦推理引擎出现算子或配置问题再怎么优化训练算法都是白费功夫。建议在做RL提速的时候先做推理侧的profiling再回头调训练参数顺序反了很容易白忙活。看完这份报告我个人最大的体会其实是RL规模化这件事技术路线大家都能讲得头头是道真正拉开差距的地方在于工程细节。很多人以为最难的环节是设计奖励函数实际跑起来才发现通信、算子、故障、同步每一个环节都可能让训练计划延期。今天上篇先讲到这里下篇我会重点拆解报告中关于并行通信优化、目标网络更新语义、以及更多工程层面的实操细节。如果你也正在做推理模型的RL训练欢迎带着问题来交流。