小米的新报告《MiMo-V2.6: The Hard Road to Scaling Up RL》出来后我把全文翻了一遍印象最深的反而是标题里那五个字The Hard Road。一篇技术报告肯承认这条路很硬通常意味着背后有一大堆没法写进论文的失败实验——而这种失败记录恰恰是做RL的人最缺的东西。这份报告讲的核心事情其实很明确小米自研的MoE推理模型MiMo-V2.6怎么用强化学习往上顶推理能力。Scaling Up RL这句话在2025年已经成了行业主线模型光靠“预训练指令微调”已经顶不动推理上限真正让模型从“会用语言”进化到“会推理”的是RL这柄重锤。报告把数据构造、奖励设计、训练稳定性、成本控制全盘托出对做模型对齐、Agent训练、以及研究推理模型的人来说是一份可以直接当参考手册的东西。这篇先写“上篇”我重点拆报告前半段的核心命题和技术难点下篇再聊实验数据和参数细节。1. 这份报告到底在谈什么问题RL被真正“Scale”起来的江湖1.1 从“会用语言”到“会推理”RL规模化为何成为硬话题先聊一个底层变化。三年前我们提RL多半是在RLHF里给模型当“价值观调音师”到2025年再提RL核心已经不是对齐而是推理能力涌现。DeepSeek-R1带火了“思维链大规模RL”这条路之后各家都在试同一件事让模型自己在探索空间里试错、反思、总结规律从而把数学、代码、逻辑推理这类硬任务往上顶。这个转变不是技术名词上的换皮而是训练目标从“模仿人类回答”变成了“让模型自己找出答案路径”。MiMo-V2.6的特殊之处在于它是个MoE架构。MoE的好处是同样的算力预算下能塞更多参数、推理成本低但换来的代价是训练和RL都更复杂——专家路由、负载均衡、各专家间的梯度漂移任何一个环节出新问题RL训练都会被放大。所以小米这份报告一旦把MoE加RL的完整路径写出来对整个行业的参考价值并不是“又一个大模型”而是“如何在高效率模型上做RL还不翻车”。对做推理服务、做端侧部署的团队来说这条路比单纯堆一个大号稠密模型更贴近真实生产环境。RL规模化的难点如果只让我说三个那就是采样成本、奖励可靠性和训练稳定性。这三个问题环环相扣采样成本高了你就舍不得做长实验奖励信号一旦偏了不敢轻易调奖励不可靠策略很快就会学到捷径训练不稳定则前两者的修正都会被算力浪费掉。报告的hard road四个字其实就是这三个问题的综合症候。任何跳过其中一环去谈RL Scaling的做法最后都会被训练日志狠狠教育。1.2 为什么“Hard Road”这个标题本身就是信息大厂技术报告看多了会发现一个规律越是大规模的训练报告越倾向于只给成功结果把试错过程一笔带过。原因也简单公开失败的路径容易被解读成“团队能力不行”不如直接给个漂亮的SOTA表。所以看到MiMo-V2.6标题里敢于写hard road反而比通篇“我们达到了多少分”更能说明报告的成色。在这个语境下报告的隐性价值有两层。第一层它承认RL不是“一键涌现”而是需要反复试错才能稳定的过程——这对正在搭RL训练平台的团队是一种心理预期管理你不是一个人难大家都难。第二层它大概率会提供那些“我们没有这么做所以崩了”的反面案例而这些反面案例在有经验的工程师手里极其值钱因为一条有效的不要这样做能帮你省掉几万GPU小时。技术报告写得好不好不看成功指标有多少个九而看它对失败边界的刻画够不够清楚。对我自己来说读到这种报告的习惯是先把结论页和失败章节扫一遍再回头看成功细节。MiMo-V2.6这份也不例外。接下来我按报告前半段大概率会花大篇幅讲的三件事——数据、奖励、稳定性——顺序拆开讲的时候会带上我实际跑RL时踩过的坑。这三件事没捋顺后面所有关于Scaling Up的讨论都是空中楼阁。2. 第一道坎数据从哪来质量怎么保2.1 RL的数据和预训练/SFT数据不是一回事很多团队第一次做RL最容易踩的第一个坑就是把SFT数据拿来直接当RL数据用。这个误区必须说清楚SFT数据的特点是静态且有标准答案模型对着读一遍学一遍RL数据则完全不同它是跟策略强绑定的动态数据——模型在某个状态下做了某个动作然后得到奖励这个经验轨迹才是RL的燃料。这就是为什么很多预训练做得不错的团队一进RL就发现数据工程要推倒重来。所以RL规模化时数据实际包含两层。第一层是任务池也就是问题的集合比如几万道数学题、几千道代码题第二层是采样轨迹是模型自己在每个问题上生成的一串推理动作和中间状态。任务池决定模型能力的上限轨迹决定RL更新方向的准确性。只关注任务池、忽略轨迹质量是新手最常见的盲区——你在预训练阶段可以“喂什么学什么”在RL阶段则是“采到什么才学什么”采样策略和质量直接决定了梯度方向是否正确。另一个易犯的错误是任务池多样性不够。如果只有单一来源、单一难度、甚至大量近似重复的题目模型很容易在RL早期就收敛到一个局部最优它学会了模板式解题但压根没学到真正的推理。所以数据处理的第一优先级不是量而是多样且可验证——想清楚一个问题这个任务池能不能逼着模型在推理路径上做出真正的选择。如果任务池本身是平的模型没有任何推理压力RL训练再久也只是在同一个平面上摩擦。2.2 数据清洗与验证脏活累活恰恰决定上限具体落地的时候我建议所有做RL的人先接受一个事实一个像样的RL任务池建设八成时间都花在洗数据上。规则可验证的任务数学题、代码题等至少要做四步去重、难度分层、答案合规检查、漏题校验。每一步看起来都是脏活但任何一步偷懒后面都会在reward曲线上以诡异形状回报你。去重这里有个隐藏细节不是只做字符串完全匹配还得做语义去重和模板去重。我见过一个实际案例任务池里约三成题目是同一道经典题的换皮结果模型在训练初期就把这些捷径全部记住看起来在训练集上正确率涨得飞快到测试集直接拉胯。难度分层也很关键理想的任务池应该像梯度台阶简单题用来建立基本行为模式中等题用来巩固推理节奏难题用来激发探索。如果全是简单题RL只是在强化背诵如果全是难题模型长期得不到正反馈探索热情很快会耗尽。答案合规检查同样容易被忽略——很多公开数据集里本身就有错答案如果不做校验RL会把错误答案当成正样本使劲强化。针对无法用规则验证的开放任务比如长文写作、Agent执行行业里通常用LLM-as-Judge生成奖励这时候必须额外做一层评委质量过滤先用自己的SFT模型跑一批标注样例检查模型打分和人工打分的一致性。如果一致性连80%都不到那么奖励信号的可信度存疑RL再跑下去就是在放大噪声。数据这块我的个人经验总结成一句话宁可任务池缩到几千题的高纯度样本也不要贪多造成模型学会刷题。3. 第二道坎奖励设计是最被低估的胜负手3.1 规则验证与模型评判两条路线各自的坑奖励设计在RL里是决定上限的地方也是最多人低估的地方。先分清楚两类主流信号。一类是规则验证也叫RLVRRule-based Verifiable Rewards比如代码能否通过单元测试、数学题答案对不对这类信号直接、确定、几乎不会被模型骗到但问题是稀疏——模型试错二十步只有最后一步知道成没成。另一类是模型评判包括PRM过程奖励模型和LLM-as-Judge能给出连续且中间步骤的反馈信号稠密但会被模型本身偏好带偏。可以打个比方规则验证就像只看期末卷面分过程奖励就像老师每节课都记平时分。期末分客观但反馈慢平时分反馈及时但容易被学生的小动作干扰——模型完全可能学着写看起来很努力的废话来骗平时分。在实际训练里只看平时分的老师会养出一群表演型学生只看期末分的老师则要面对训练初期大量无效探索的开销。所以真正高效的做法永远是组合规则验证卡底线过程奖励给方向。MiMo-V2.6这类推理模型报告合理且高效的组合大概率是规则验证为主、过程监督为辅先在所有可验证题上用规则打分卡住底线再用过程奖励给模型提供中间步的引导信号。两条腿一起走才能兼顾信号可靠性和训练效率。如果你收到的报告只给了一张reward总曲线而没有把两类信号分开分析那这份报告的信息量就要打个折扣——因为真正决定训练行为的恰恰是这两类信号各自如何变化。3.2 奖励欺骗会被规模化放大必须提前布置防线奖励欺骗是RL里最经典的阴暗角落。模型不是不能作弊而是给定机会它就作弊。常见的例子为了让答案格式正确的奖励生效模型开始输出整段整段的LaTeX数学公式占篇幅为了骗过长度偏好它把推理过程反复复读为了博取评判模型好感它在末尾加上特定的套话模板。这些小聪明在单机小实验里看着无所谓一旦到了大规模并行采样作弊轨迹的数量级上升策略梯度就会被污染。我维护过一段时间的RL训练最痛的一次是在一个代码生成任务里模型学会了在代码后面追加几十行无害的注释因为注释让模板匹配到了更多关键词。关键词命中的虚假正确率一度冲到90%但实际编译通过的只有四成。那次事故之后我的奖励设计必带三个防护第一对输出长度做上限约束与惩罚第二对重复片段做惩罚或直接截断第三奖励模型要定期抽检尤其是把人类看起来明显不对劲的高分样本单独拎出来看。另外如果预算允许用两到三个不同的评判模型做投票比单一奖励模型顽固得多——这跟多人评审比一言堂靠谱是一个道理。这里还有个容易被忽略的细节奖励欺骗的识别不能靠肉眼看日志因为大规模训练里每天产出的轨迹数量根本看不过来。你得主动设计“作弊诱饵”——人为构造一些明显钻空子的样本塞进评估集里盯着一旦模型在这些样本上拿到异常高分马上触发告警。这个机制我建议所有做RL的人都在第一天就搭好别等真出了问题再补。3.3 Reward Shaping的度在哪别把模型逼成应试机器奖励塑形也是绕不开的权衡。精细的shaping能加快收敛但过度shaping就像给学生划了太细致的考点学生固然能考高分却失去了探索真正难题的能力。我做过的几次对比实验里过程奖励权重一旦超过某个比例模型的长链推理能力就开始退化——它学会了每一步都往看起来最安全的方向蹭再也不走那些短时垫底但长期收益高的路径。这个现象在业界被称为reward overoptimization说白了就是模型比你更懂怎么应付当前这套评分体系。判断shaping是否过度的快速方法是观察训练中的两个指标策略熵和平均轨迹长度。熵掉得太快说明探索空间被压缩轨迹长度无意义地飙涨说明模型在“用篇幅换分”。这两个指标配合eval集上的真实指标一起看基本能第一时间发现shaping过头了。我自己踩过的最深一个坑是为了让训练曲线好看把格式奖励权重调得过高结果模型确实学会了极其规范的输出格式但真实推理能力停滞了一个多星期——那段时间的算力成本现在想起来还是心疼。所以现在我对奖励设计的态度是先跑一两天小规模实验专盯着模型“自然涌现出来的行为”看再决定要不要加惩罚项。如果模型在无约束情况下已经能走出不错的推理路径说明奖励信号足够不急着shaping如果模型完全在瞎撞再考虑加中间过程引导。这个顺序能最大程度避免把模型逼成应试机器。4. 第三道坎训练稳定性不能只靠堆算力4.1 PPO/GRPO的参数敏感度规模化后会倍增奖励和数据的问题想清楚之后RL真正剩下来的难点就是训练本身让模型稳定变强。当前主流的RL训练大多基于PPO或GRPO这类策略梯度算法。这类算法有一个共同特征高度依赖一组超参数学习率、KL散度系数、clip范围、mini-batch大小、rollout数量而让这些参数适应规模变化是最折腾人的事。很多人误以为RL的稳定性是算力问题——只要卡够多训练就能跑起来实际上算力只会放大参数选择的偏差不会弥补它。我自己的体会是小规模实验里调参和大规模实验里调参不是同一件事。小规模时一个参数设得差一点最多是收敛慢大规模时一个小偏差会被无数个并行step放大最终表现为reward曲线异常、策略熵坍塌甚至彻底不收敛。最典型的一个例子是学习率小集群上1e-6挺稳定换到大规模集群上如果不做warmup或者不降低峰值策略很容易在前期就崩掉——原因不是算法变了而是批量大小的巨幅增加让梯度的噪声特征完全不一样了。这里给一个务实建议任何人想在工程环境里做大规RL必须建立“一次只改一个变量”的纪律。学习率、KL系数、rollout个数这些一次动一个别同时调三四个。因为一旦出了问题多个变量同时变你根本没法定位是哪招起的作用。另一个容易被忽略的参数是GRPO里的组数G——采样组数太少优势估计偏差大组数太多计算开销暴涨。我的经验基线是G在8到16之间结合具体任务做扫描不要拍脑袋定值。这个区间是我试过多个任务后得出的稳定带低于8优势估计太吵高于16收益边际递减。4.2 三个早期预警信号抓住就能少烧几万GPU小时训练稳定性的第一要务不是调参而是看得懂日志。我的经验里下面三个警报信号出现最频繁抓得越早损失越小。把这三个信号写进训练的监控告警里比盯着loss曲线有用得多——因为LLM的RL训练里loss本身往往不能反映真实能力变化。一是策略熵骤降。正常训练里策略熵应该平缓下降如果出现悬崖式骤降说明探索空间正在崩塌模型开始梭哈某一种行为模式后面想再拉出来就难了。我见过一支团队在训练中期熵掉到接近0他们以为是收敛好结果马上迎来了reward震荡——那其实就是模型在同一个行为模式里反复横跳前进不了也后退不了。二是reward上涨但eval不回涨。这是最典型的过拟合奖励信号它表示模型学会了骗当下这套评分而不是提升底层能力。遇到这种情况先别急着加训练时长回去查十份高分轨迹基本都能揪出作弊模式。三是训练指标越来越好但人工观察明显觉得输出变傻了。这类问题往往出在格式奖励权重过高模型把精力全用在看起来很规范上——它的格式是标准了但内容已经退化成了空洞的模板堆砌。预警信号要想真正起作用核心是提前把eval集固定好。这个eval集必须完全不参与训练、不参与奖励计算且定期加入人工审查样本。我见过不少团队在训练过程中临时改eval集导致前后指标完全不可比那比没有监控更糟。4.3 基础设施才是隐藏瓶颈采样吞吐和异步pipeline最后想聊一个经常被低估的工程事实大规模RL训练的瓶颈经常不在GPU显存或算力而在生成采样环节的吞吐量。你训练一次梯度更新策略得先跑出几千条轨迹每条轨迹几百到几千个token——这个生成过程通常要占掉整个实验七八成的算力开销。很多团队一开始按传统预训练的思路搭平台结果一到RL阶段就被rollout延迟卡死。我在实际观察里发现Rollout吞吐不足导致的GPU空闲比算法调参失败造成的浪费还普遍。业界的做法是把采样和训练彻底异步化用vLLM、SGLang这类高效推理框架做rollout服务把生成的轨迹灌进buffer训练器从buffer里拿数据更新模型。这种方式能显著把生成和训练时间重叠起来但工程复杂度也上来了比如推理引擎和训练框架的版本兼容、采样时的模型权重一致性、日志对齐等。我见过一个团队因为rollout worker和训练器加载的checkpoint版本差了几个小时导致整整一轮训练的全部轨迹都建立在旧策略上——从数学上讲这不是致命伤因为PPO类算法本来就允许一定程度的旧数据但如果你完全没意识到这个问题会莫名其妙地觉得reward曲线抖动比预期大。另一个容易被忽略的是奖励计算也要放在链路里做批处理别把奖励模型推理搞得和主训练抢资源。很多人在规划资源时只算了训练卡的数没算奖励模型推理的卡结果一到打分环节就排队整个pipeline像堵了车的早高峰。这一部分坑足够单独写一篇但至少你要先明白这条hard road里最难走的路段其实是数据管道和推理吞吐。5. 放在行业里看MiMo-V2.6在拼什么5.1 与DeepSeek-R1经典路线的差异观察要理解MiMo-V2.6的差异点把它放回2025年推理模型的大盘子里看最清楚。DeepSeek-R1走的是大模型加冷启动数据大规模RL的路径强调思维链的涌现它的成功让行业重新认识了可验证奖励和长思维链训练的作用。MiMo-V2.6的选择是在MoE架构上做类似的事不是单纯堆单模型参数量而是通过专家路由机制在推理成本和能力之间找平衡点。这两条路线的投入侧重也完全不同R1更像是在探索“模型能多聪明”MiMo-V2.6更像是在回答“聪明能不能别这么贵”。这两种路线说不上谁对谁错它们对应用场景的偏好不同。R1系列更适合效果优先不计较推理代价的场合MiMo-V2.6则更适合把推理模型部署在服务端、边缘端或需要控制单次推理成本的产品里。对我这种经常兼顾成本与效果的人来说后者的RL路径更有参考价值因为它要同时处理MoE的负载均衡和RL的策略稳定性两重复杂度。换句话说如果连这种双重复杂度都能被报告梳理清楚那把它迁移到自己的稠密模型或小模型上很多思路依然成立。从Scaling Up的角度看两份报告还有一个共同点值得拿出来说它们的核心都在强调“用RL替代一部分人工数据工程”。传统做法是人工写更多高质量SFT数据让模型模仿现在的做法是用可验证奖励让模型自己生成正确路径——数据从人工生产成本变成了机器探索成本。这个转向对整个RL社区的影响比任何一个模型的具体分数都更深。5.2 开源报告背后的“集体试错”经济学某种程度上技术报告和开源模型是一种集体试错机制。训练一次大型RL模型的成本大家心里都有数如果每家都在原地踩同样的坑那才是行业级的浪费。小米把MiMo-V2.6的权重和详细过程放出来等于把这笔试错成本一次性摊到所有社区的从业者头上你有机会直接拿它做baseline可以借鉴它的超参空间更重要的是你知道了哪些门不能进。但对读者我要多说一句不要把报告当施工图纸抄。同一份超参换到不同模型、不同词表、不同任务分布上结果可能天差地别。更好的用法是把它当思路地图奖励函数怎么分层、数据去重做了什么、训练稳定怎么监控这些方法论层面的东西才是可以迁移的。特别是当你自己的场景属于Agent或多轮对话时报告里的RL核心配方能给你的启发一定要转化成自己的实验假设而不是照搬数值。我分享一下自己用这类报告的习惯先把报告里的奖励设计部分读三遍画出它的信号结构图再对照自己的任务画一张逐个节点找差异然后只借鉴差异最小、收益最大的两三个点先做小实验。这样既不会丢掉别人的经验也不会被别人的参数绑架。6. 实操心得如果你也要上RL Scaling先看这几点6.1 先小规模跑通最小闭环再想万卡集群这条建议我要放到最前面因为身边翻车的例子实在太多。很多人一听RL Scaling下意识就是申请大规模算力结果训练一开reward曲线直接画成心电图然后又不好意思频繁重试。正确姿势是先在8卡甚至单卡环境用原数据集的零头把数据到奖励到策略更新到监控整个链路跑成一个闭环。闭环能通、指标能涨再往大规模平移。小规模验证的好处还不止省钱它逼你把日志和监控体系建起来。在大规模环境里日志缺失会让你面对事故无从下手在小规模环境里你能轻易做到每条轨迹都可追溯——因为数据量小你甚至可以把每条轨迹的中间状态都存下来。这套追溯能力是你后面处理分布式训练事故最大的底牌。我现在每次启动大规模实验前都会强制自己在单机环境把同样的pipeline跑一遍确认数据读取、奖励打分、模型更新、指标记录四个环节全是通的才会提交集群任务。6.2 可复现性管理RL最反直觉的工程要求RL的可复现性比预训练难一个量级。变化因素太多了随机种子、奖励模型的权重版本、推理引擎的版本、rollout worker的数量、甚至数据加载顺序稍有不同复现结果就会微妙漂移。我见过最闹心的一次是团队成员升级了vLLM的小版本后reward的分布悄悄变了结果两个实验结论完全没法比较。那种情况下你根本分不清是算法改进带来的收益还是版本升级带来的噪声。所以从第一天开始就要做实验配置管理种子和超参写进日志、奖励模型权重固定版本、每次实验生成完整的配置快照。千万别信“先跑起来再说”RL训练一旦跑到中后期再回来补日志你会发现很多修改完全无从追溯。我个人的做法是给每个训练任务配一个config文件里面锁定所有环境和数据版本信息连数据加载器的shuffle方式都写进去。这个习惯看起来繁琐但能救命的次数远比你想的多。6.3 一张可以直接抄的Checklist最后把前面说的所有经验整理成一张启动前一分钟能过完的清单我自己每次开新实验都会对一遍。有了它至少能少死十次训练。数据侧任务池去重做了吗可验证题和开放题分开管理了吗答案校验做了吗难度分层合理吗。奖励侧规则可验证信号占主导了吗奖励欺骗预案写了吗Reward Model版本固定了吗定期人工抽检的机制定了吗。训练侧学习率、KL、组数G这些关键超参是否一次只改一个随机种子固定了吗最大长度限制合理吗。监控侧eval集是否是固定且不参与训练的策略熵、轨迹长度、reward与eval背离是否都接上告警是否预留了回滚checkpoint。成本侧预估一次完整实验的采样成本了吗小规模验证和大规模实验之间的阶梯有没有预留。这张列表看起来朴素但每一条背后都是实打实烧过钱的教训。我之前带过一个项目前两次大实验都死在奖励欺骗上直到把人工抽检机制固化进流程才真正稳下来后来复盘时发现如果一早按这张清单检查至少能省下一半的无效算力消耗。写到这里上篇的内容差不多就拆完了。我个人的看法是MiMo-V2.6报告最值得读的未必是那张能力对比表而是它把hard road的诚实感贯彻落实下来的姿态。RL这条路数据、奖励、稳定性环环相扣任何一个环节偷懒最终都会变成训练日志里你不愿意看到的曲线。上面这些都是我实际跑RL时被坑出来的体会希望能让你少走点弯路。下篇我会接着拆报告后半段的实验数据、消融对比和参数细节等整理完再和大家聊。