这两天反复在看小米新发的《MiMo-V2.6: The Hard Road to Scaling Up RL》技术报告。坦白说当“RL”、“Scaling Up RL”这种关键词出现在开源模型团队的标题里大多数人的第一反应是又来一个刷分总结。但这篇报告给我的感觉完全不同标题里的“Hard Road”不是修辞是真的把大规模强化学习的难处一件件摊开讲了。现在各路开源模型都在拼推理能力和后训练效果真正愿意把训练过程的弯路、烂坑、策略抉择写明白的报告不多这份算一个。这篇我先拆上篇的重点核心围绕它如何定义规模化RL的难题、以及用什么样的方法论骨架去应对后篇再展开具体训练配置和实验结果。这个报告适合谁看两类人最值得读一类是正在做Post-training、RLHF或者推理方向RL训练的算法工程师另一类是想理解“Scaling Law之后能力增长的真实来源到底是什么”的研究人员。如果只是为了膜拜分数你会发现它远没有其它报告那么“好看”但如果你是要在自己的集群上复现一条“能稳定跑完的RL产线”里面的取舍、监控项、奖励设计和数据组织方式几乎可以直接抄作业。1. 为什么这个报告值得逐字去读推理模型的军备竞赛绕不开RL1.1 Post-training的权重大幅上升RL已经从“调味料”变成“主菜”在以前一个模型的训练重心几乎全部放在预训练阶段后训练无非是SFT做指令跟随再加上一个RLHF对齐人类的“口味”。但为了适配推理模型方向后情况完全变了。SFT负责让模型学会“像样地说话”RL负责让模型学会“真正地把题做对”——这两个目标的评价方式天然不同。SFT的答案是给定输入输出对去拟合它只能让模型模仿数据里的人类路径却很难让模型自己发现更长链路的思考路径。而RL是在一个环境里探索通过奖励信号反复做策略更新能把模型的解题能力推过SFT数据的边界。这也是为什么“Scaling Up RL”不是一个口号而是当前推理模型军备竞赛的决定性因素。我用一个生活化类比来帮大家理解SFT像是让学生做了一万道例题记住了每个题型的标准解法RL则是直接让模型进考场考完只看分数分数不满意就回头想甚至用超出人类常规的方法另辟蹊径。后者上限更高但它所有痛苦的来源也在这里——考场上没有标准答案给分数的那个人还可能给出错误或者有偏见的评分考的次数多了学生可能会学会跳过步骤直接写结果甚至利用评分规则漏洞。1.2 MiMo系列在做什么V2.6处于什么位置MiMo是小米的开源模型系列主打高性能和推理效率。V2.6这个版本从命名就能看出它不是一次拍脑袋的新架构而是同一系列在Post-training阶段的持续迭代产物。这类系列版本号的意义在于模型基座结构基本稳定主要变量放在数据、奖励设计和RL策略上天然适合用来观察RL扩展过程中的规律。如果顺着这个逻辑看V2.6的技术报告更像是一份“RL自我复盘”而不是“架构表演”。它要回答的核心问题大致是当我们把RL训练的规模扩大到一定量级之后哪些直觉仍然成立哪些直觉失效了为什么网络增长、数据增长遵循的规律在RL这里不直接适用这些问题如果深挖下去比单纯公布一个Benchmark分数要有价值得多——因为Benchmark只能告诉你“它能做什么”却无法告诉你“别人怎样低成本复现”。1.3 报告把“难”字摆在台面上这比晒分数更难很多技术报告习惯性地把实验过程包装成一条平滑上升的曲线中间最多加一句“我们对超参做了精细调整”。但大家都知道真正的RL训练曲线像是过山车不是loss稳定下降而是reward忽高忽低、策略突然坍缩、重启好几次都找不到原因。MiMo这份报告让我欣赏的一点是它直接承认“Hard Road”把RL规模化过程中最难的部分拆成了几个层次来讲。这种姿态本身就在传递一个信息RL这个方向还远没有到总结套路的时候每个人都还在摸石头过河。作为读者我建议大家在看这份报告时别只盯着V2.6最终效果而是把它当作一份“规模化RL求生指南”。接下来我把报告里的问题拆解和应对思路用自己的语言展开说一下。2. Scaling Up RL的“Hard Road”到底难在哪先拆清楚问题再谈解法2.1 第一层难训练稳定性在超大规模下被放到显微镜下小规模的RL实验是很容易“显得成功”的模型小、任务简单、单卡或者几卡就能跑哪怕出现一点稳定性问题重新跑一次的成本也不高运气成分可以直接覆盖系统性问题。但把所有变量放大一百倍之后原本偶发的loss spike、熵的突变、策略的剧烈波动都会变成训练的主旋律。大规模RL的稳定性至少包含三层意思策略更新的稳定性、奖励信号的稳定性、训练框架本身的稳定性。策略更新不稳定是算法层的问题——比如PPO类方法对clip范围和KL散度控制极其敏感小规模下你随便设一组参数都能收敛大规模下参数的微小差异就会导致某次更新直接让模型“失忆”。奖励不稳定则是环境层的问题——验证器本身可能带噪声同一个解题过程这次判对下次判错模型就会在噪声信号上反复震荡。至于框架层千卡训练的任何一个节点掉线、任何一次梯度同步超时都可能让整轮迭代直接报废。2.2 第二层难奖励信号的稀疏与噪声RL极易“抄捷径”RL推动模型提升的逻辑是“给高分反馈”。但这个逻辑成立的前提是奖励函数真的能代表“能力变强”。这个前提在大规模任务上非常脆弱。先看稀疏性问题。人类解决一道复杂的数学题中间有一长串推理步骤如果只在最终答案正确时给1分模型收不到任何关于“思路对不对”的中间信号。于是它在前期只能盲搜有效样本率极低。再看噪声问题。如果用一个大模型作为奖励模型去给解题过程打分这个打分模型本身有偏好甚至会被被训练模型的语言风格带偏。表现到训练过程上就是reward越来越高但模型解决真实问题的能力反而停滞——因为它学会了“让打分模型开心”而不是“把题做对”。小米报告里对这种问题给了很清楚的定调不能把奖励设计当成一个理所当然的组件它应该被视为RL系统里最需要纪律性的部分之一。规则优先、模型兜底、层层验证才是规模化RL能走远的底线。2.3 第三层难数据效率与策略坍缩学得越多坏得越快RL训练依赖“探索”也就是持续不断地让模型生成新的解题轨迹。但RL的训练目标又天然倾向“利用”即把概率集中到已经验证能拿高分的路径上。在规模化场景里这种矛盾会迅速演变成策略坍缩——模型生成的内容越来越多地集中在某几种固定的句式或者解答路径上多样性肉眼可见地下降。策略坍缩的最直接恶果是数据飞轮失效。在线RL的样本是策略自身生成的如果策略千篇一律那么下一轮训练的数据分布就越来越窄模型在窄分布上继续优化慢慢变得只能解决“自己见过的小世界”而失去泛化能力。更麻烦的是训练数据里混入大量来自旧策略、甚至失败策略的样本时如何正确利用它们而不污染当前策略也是一个非常精细的工程问题。我自己在实际训练里对这一点体会很深很多时候模型reward曲线还在涨但你把它生成的样本拿出来肉眼看会发现千篇一律、模板腔很重。下一个epoch开始后模型分数没降可评测集上的真实正确率反而掉了。这就是典型的策略坍缩必须靠数据层面的干预才能拉回来。2.4 规模化的本质约束算力、带宽、吞吐构成的工程天花板最后这层难往往最不被重视RL是出了名的工程重活。SFT可以把所有数据一次塞进dataloader训练就是一遍遍过数据RL则必须反复执行“生成→评估→学习→再生成”的闭环每一步都在和基础设施打交道。在千卡规模的训练集群里Rollout阶段需要让actor模型做海量生成推理这里就占了大量算力随后把样本传给critic或者奖励验证器打分又是一轮推理最后才能把打分结果返回给训练进程更新权重。这还没算上中间的特征缓存、经验池序列化、检查点保存和网络通信。任何一个环节吞吐不匹配都会让整条产线的有效利用率掉到50%以下。报告里那套“Hard Road”的叙事实际上把工程侧的困难也讲得很透如果训练框架扛不住规模化算法再精巧也白搭。这是我读过之后特别想提醒同行的一点。3. MiMo-V2.6的方法论骨架在线RL、可验证奖励与负例重训3.1 在线策略迭代没有新样本的RL都是“闭门造车”先聊方法论的第一个支柱坚持做在线采样。所谓在线并不是说每一轮更新都必须用最新权重实时生成而是强调经验数据要跟随策略的演化持续更新。模型今天的能力边界和三天前完全不一样拿旧数据反复训练就是让一个高中生做小学题对能力提升毫无帮助。在实际工程实现上比较常见的做法是维护一组“rollout worker”它们会周期性地拉取最新的actor权重然后对任务池进行采样生成。采样的任务也不是一成不变而是根据当前策略的弱项动态调整难度分布形成一个“策略进化过程中最难啃但最有效”的任务集。MiMo报告强调在线恰好就是为了解决前面提到的问题让模型更多地在自己的薄弱区域反复摸索而不是在自己已经擅长的舒适区里刷分。不过在线策略也有代价——它意味着RL训练没法像SFT那样精确复用同一个数据batch多轮迭代。每次策略更新后旧数据的价值迅速衰减你必须持续购买“新数据”而这个新数据的成本单位是推理算力。这也是RL规模化天然比SFT贵很多的原因。3.2 可验证奖励与验证器设计规则优先、模型兜底、过程把关奖励设计是整份报告里我认为最具实操价值的部分。小米在V2.6里走的是“可验证奖励”的思路意思是能交给确定性规则验证的任务绝不让模型奖励器来打分。最典型的场景是代码执行。模型写出一段代码能不能编译、能不能运行、运行结果对不对这些全部可以交给真实环境去检验。数学题也一样答案能归一化之后做字符串匹配就先用规则匹配。规则给出的分数没有噪声不会受模型偏好影响训练信号自然干净。只有规则完全无法覆盖的开放式生成任务才退一步交给模型奖励器。但模型奖励器不是随便一个模型就能用。报告里的一个关键思想是“验证器也要被验证”给验证器一批已知好坏的数据集做校准测它的错误接受率和错误拒绝率。我理解这种做法等价于先训练一个“严肃的评分员”再让它在真实的RL训练里去阅卷。很多团队在奖励器上翻车就是直接把通用大模型接进去打分完全没有校准步骤最后模型学了一堆怎么溜须拍马的废话。3.3 “负例重训”思路把失败样本重新变成教师奖励函数告诉模型什么好还不够模型还需要学会什么不好。报告里提到的负例利用非常关键把在线rollout过程中判错、判偏、规则验证失败的那些样本专门收集起来形成负例池。负例的用法不只是“做负样本”——更有效的做法是做成困难样本。模型在某个问题上反复失败说明这个点已经越过它的能力边界也说明这里正是RL要攻击的薄弱区域。让模型针对这批失败样本重新做完整推演把从“失败”到“成功”的路径拉出来对比其实就是在给模型制造高质量的反思样本。这个思路很像RFTRejection Sampling Fine-tuning的强化版但区别在于它不是一次性筛选后用SFT训练而是把负例数据持续地回灌到RL迭代里形成一种“越挫越勇”的循环。这个设计在工程上有一个隐性要求数据版本管理必须非常严格。负例池如果混入了策略坍缩时期的垃圾样本再被当成训练目标喂回去模型就会进一步坍缩。所以负例池应该有标记来源批次的能力一旦某个epoch的策略整体劣化对应产出的负例要能一键隔离。3.4 数据配比与课程安排能力提升不看总数据量看难度分布从标题推断加上这个方向的实际需求V2.6肯定还要处理一个老问题不同类型、不同难度的数据以什么比例混合进RL任务池。我的经验是简单任务与困难任务的比例需要动态变化。如果大量刷简单题reward会涨得很快但那是虚假的快速提升——模型没有触碰能力边界如果一上来全上难题又会让生成成功率过低有效学习信号太稀疏。比较合理的做法是按“爬坡”策略开始时以中等难度为主保证一定的成功率让模型稳定拿到正反馈之后逐步掺入更高难度的样本并把训练失败但验证器认为“推理路径有启发性”的样本也保留进回放池。课程顺序看似是个工程细节实际对RL收敛速度影响极大。我看过不少团队的RL产线训练前没有做任何难度分层所有任务随机混合出来的曲线剧烈波动。小米这份报告如果按“Hard Road”的逻辑展开一定也会强调这种分布设计因为它决定了你能在多大算力预算内把模型推到期望水位。4. 配套工程设施让RL真正跑起来的那部分4.1 从Rollout到收样本的在线数据飞轮一段完整的RL训练流水线至少要包含五个环节任务采样、模型生成rollout、奖励评估、策略学习、模型部署回滚。这五个环节需要在同一套框架下被编排起来任何一个环节变成瓶颈整体吞吐就会塌方。以批量大小为例。RL训练的经验池不是一个无限缓冲区它需要限制体积保留最近若干条有代表性且已验证的轨迹。经验池太小样本相关性太强策略更新方差变大经验池太大里面塞了很多旧策略的过期样本又导致当前策略学不动。MiMo这种规模的报告如果给出了经验池容量的设置思路那一定是经过千卡集群多轮试错得出来的我们在自己的场景里可以直接作为初始值参考。另一个容易被忽略的细节是重复样本的剔除。推理任务经常会出现同一道题生成一模一样的错误解法这些重复轨迹既占存储又放大梯度噪声。实践中的做法是按回答结构做hash去重或者对语义相似度过高的轨迹降权采样。别小看这一步它能直接影响RL训练每一步的效率。4.2 训练框架与并行策略别让通信吃掉算力现在的千卡级RL训练通常不会只有一个模型在跑。Actor模型、奖励验证器、Critic模型如果用PPO类方法的话可能同时驻留。这些模型既要独立更新又需要同步数据对并行策略的考验比SFT大得多。业界常见做法是把训练任务和生成任务拆到不同的物理资源上大规模训练集群负责权重更新另一个推理集群专门负责高吞吐生成两组资源之间通过高性能文件系统或者消息队列交换checkpoint和样本元数据。这样做的好处是两个集群的故障域隔离训练侧不会因为某个推理节点故障而阻塞。报告如果大量描述训练框架调优过程说明他们一定在“把训练数据及时运到生成集群”和“把生成轨迹及时运回训练集群”这两个方向上做了大量工作。感想是工程上的大量细节根本不会出现在Benchmark表格里但是它们决定了产线存活的概率。4.3 评估与回滚RL炼丹的监控台SFT的迭代节奏可以按天计而RL的迭代节奏可能按小时甚至按分钟计。因为策略每更新一次生成分布就会发生变化你不能等到第二天才发现昨天某次更新让模型退化了。因此持续评估与自动回滚机制是规模化RL产线的最后一道防线。我的建议是至少每N步保存一个checkpoint并在独立于训练分布的评测集上跑快速评估评测集里既要有规则可验证的客观题也要有人工抽检的开放生成样本。一旦连续几次评估的分值低于某个阈值系统要能自动回滚到最近一个稳定的checkpoint而不是任其带病训练。4.4 实操监控表给RL训练配的“体检清单”监控维度典型指标出现问题时的典型特征工程对策策略稳定性KL散度、熵、梯度范数KL突然上冲、熵骤降、loss spike降低学习率、收紧clip范围、裁剪梯度奖励质量验证器准确率、奖励均值/方差reward均值上升但真实正确率停滞做验证器校准、人工抽检、规则复核样本多样性轨迹重复率、n-gram覆盖率大量解答路径相同、模板腔明显提升探索温度、加多样性惩罚、负例池去重数据新鲜度经验池新旧样本占比经验池大量过期样本导致策略退化控制经验池容量、做加权采样工程稳定性节点故障率、通信超时率、吞吐频繁断点续训、GPU利用率掉坑强化故障转移、拆分离线推理与训练资源这张表其实就是我读完V2.6报告上篇之后结合自己在类似规模的RL产线上踩坑的经验浓缩出来的一个模板。严格来说每个团队都可以把它打印出来贴在工位上。你不需要等报告给你一个万能答案把这五个维度盯住了至少不会死得不明不白。5. 从这份报告里我实际抄到的几条RL经验5.1 把“稳定”当成第一需求给RL配节流阀我过去有一个误解RL训练要追求快速进展分提得越快越好。后来踩了太多次“快速提升后突然崩溃”的坑才意识到在大规模训练里控制更新幅度比追求更新速度重要得多。具体来说就是给策略更新加“软限制”比如设置KL散度的动态阈值一旦超过就自动缩小当前batch的更新步长再比如把reward做标准化防止某几条极端高分样本主导梯度方向。MiMo报告把这条路称为“Hard Road”我很认可这种定性因为它把稳定所需的克制讲得很有分量。5.2 验证器先于策略升级别让模型靠撒谎得分奖励系统是RL的天花板。策略模型的能力再强如果验证器的评分标准混乱最终学习到的方向也是混乱的。正确顺序应该是每轮提升验证器再谈策略。实际操作上我建议每轮训练开始前都做一次“验证器对抗性测试”故意构造一批回答错误但逻辑完整、格式精美的样本验证器必须把它们全部判低分才允许上线。这不是论文里会写的东西但比任何超参搜索都更能保住你的RL训练下线。5.3 每个阶段都要留“锚点”回滚比硬顶更重要训练中期如果发现模型在某类任务上全面倒退第一反应不是调参硬顶而是先回滚到上一个能够稳定生成高质量结果的checkpoint再从那个锚点出发尝试更小的更新。保存checkpoint的成本很低但重新训练浪费的时间成本极高。我自己的体感是大规模RL跑到一半最好的策略不是“相信这轮更新最终会变好”而是“迅速回滚确认锚点再讨论下一步”。这个习惯能帮你省下至少一半的无意义试错。5.4 对后续扩展的思考RL的中间产物值得持续复利最后说一个由这份报告触发的长期想法。大规模RL训练过程中会产生海量的“轨迹数据”成功的、失败的、被验证器打回重写的。这些数据在当下的训练任务里是消耗品但它们完全可以沉淀下来变成下一轮SFT数据、验证器校准数据甚至是预训练阶段用来提升模型先验能力的语料。如果V2.6的后续工作会沿着这个方向走那我推测他们最终的护城河不只是一个高分模型本身而是一整套数据飞轮体系。这套体系意味着每做一轮RL整个数据资产池都在增值下一次训练起点自然更高。这才是“Scaling Up RL”真正可怕的长期效应。文章先聊到这里主线上篇的方法论思路和工程要点差不多就是这些。后面我再去把下篇的训练配置细节、基准结果分析以及那些让人“拍大腿”的失败案例整理出来争取给到能直接落地的实操参考。