这两天我把小米的《MiMo-V2.6: The Hard Road to Scaling Up RL》技术报告翻来覆去读了几遍越读越觉得标题里的“Hard Road”用得一点不夸张。过去两年行业里有个普遍幻觉预训练能ScalingRLHF和RLVR当然也能Scaling。但真正下场做过强化学习的团队才会明白从“跑通一个小Demo”到“规模化地稳定训练”中间隔着的不是一两个trick而是一整套工程体系和技术理念的重构。这份报告最难得的地方在于它没有把成功包装成理所当然而是把训练过程中那些反复试探、妥协、修正的路径如实摆了出来。这篇解读我计划分上下两篇。上篇先聚焦核心命题为什么RL规模化这么难难在数据、算力、工程、稳定性四个维度上分别是什么表现下篇再回到报告里的具体算法设计、实验配置和消融结论。如果你正在规划RL训练平台或者马上要跑一个上万卡时级别的RL任务这篇值得静下心看。1. 小米这份报告到底讲了件什么事从MiMo-V2.6看RL规模化的真实成本1.1 MiMo-V2.6是什么推理模型路线上的一个坐标点MiMo系列是小米在端侧与云端同时布局的模型家族。V2.6这个版本从技术报告的定位来看走的不是传统“堆参数、堆语料”的路线而是把强化学习当作主线能力来打磨。这个判断从报告标题就能看出来——The Hard Road to Scaling Up RL主语是RL不是LM。熟悉这个领域的人应该记得2025年上半年小米发布了MiMo-7B-RL用大规模强化学习把一个小模型的数学推理能力拉到了当时同参数量模型的第一梯队。V2.6可以理解成这条路线上的延续继续用小模型做高强度RL训练同时把训练过程中踩过的坑、试过的方案、总结的规律写成了这份技术报告。这类报告在今天的价值非常高。因为行业里关于RL的训练经验大部分散落在各家技术博客和论文里系统性讲怎么Scale Up的公开资料很少。多数团队的RL训练还停留在“能跑”阶段离“可预测、可复现、可扩展”还有相当距离。1.2 为什么标题叫“The Hard Road”报告的叙事主线我读这份报告时最深刻的印象是它对“艰难”的刻画不是笼统的抱怨而是具体到了每一个环节。数据层面在线生成的数据分布不断变化导致训练集和评估集之间的一致性很难维护算力层面RL训练不是单纯的前向加反向而是生成、推理、训练、评估多套流程交织GPU的利用率很难像预训练那样平滑工程层面断点续传、奖励回流、多机调度任何一个环节不稳整个训练节奏就被打乱。这些困难单独拎出来看每个都有人讲过。但小米这份报告把它们放在同一个规模化的叙事框架里呈现出来的是一种系统性压力你解决了数据管道的问题算力配比又失衡你调好了算力配比训练稳定性又出问题。真正做过的人知道这种“按下葫芦浮起瓢”的处境才是RL规模化最真实的日常。1.3 什么人适合读这份报告以及我的读法如果你是做RL算法研究的重点关注报告里关于奖励设计、KL控制、策略更新节奏的部分如果你是做ML Infra的重点关注分布式调度、数据管道、容错机制的部分如果你只是对大模型训练好奇那这份报告也能让你看到“模型不是训练一次就完事”的复杂图景。我自己的读法是先不看具体实验数据把报告里描述的“问题”全部圈出来然后对照自己之前跑RL训练时踩过的坑。发现重合度非常高。这也说明报告写的是真问题不是凑出来的章节。下面我就按数据、算力、工程、稳定性这四个维度逐层拆解报告里呈现的“艰难之路”。2. 预训练与RL规模化的底层差异动态分布是第一道坎2.1 静态数据集变成“会跑的靶子”分布漂移的麻烦预训练的核心假设是数据分布基本固定。你准备一个海量的、经过清洗的语料库模型一遍遍在上面迭代loss稳步下降评估指标也稳步提升。整个过程就像在一个封闭的题库里刷题题目不变你只需要提升作答能力。RL训练完全不是这个逻辑。策略模型每更新一版再去采样时生成的数据分布就变了。今天模型生成的推理路径还比较单一明天可能就冒出了新的句式、新的中间步骤、甚至新的错误模式。这带来两个直接后果评估集和训练集的一致性难以维护。你评估模型用的测试集是固定的但模型在线学习到的分布已经在漂移可能出现训练指标上升、评测指标下降的“错位”。数据管道的处理逻辑变得更复杂。预训练里的数据清洗可以做离线批处理RL里的数据清洗必须在采样和训练之间实时完成否则留给训练的数据就是过时的分布。报告中有一个点我印象很深为了缓解分布漂移带来的评估失真团队需要不停地用最新策略重新采样一部分评估数据。这个操作在预训练里几乎不会用到但在RL规模化里它变成了常态化工作。2.2 奖励信号不是常数非平稳的“老师”预训练时监督信号来自语料中的下一个token这个“标准答案”是固定的。RL训练时监督信号来自奖励模型或者规则奖励这个信号本身可能随着训练进程发生变化。比如用规则奖励做数学推理验证同一个推理步骤在不同版本的策略下出现时奖励模型给出的分数可能不一致。更麻烦的是如果奖励模型也在同步更新很多团队确实这么做那模型面对的“老师”就是个动态变化的目标。你今天学到的策略明天可能因为奖励模型改变而变得不那么正确了。这就好比学生准备考试但出题老师每隔几天就换一次出题风格。学生在努力出题人也在变最后变成一场双方都在移动的追逐战。报告中强调的reward consistency问题其实就是对这种非平稳性的应对。规模化之后这个问题会被放大模型生成的数据越多奖励模型需要覆盖的分布就越宽评分失稳的概率也越高。2.3 参考模型与KL散度防漂移的安全绳为了对冲分布漂移和奖励非平稳带来的风险报告里多次提到参考模型和KL散度的作用。参考模型通常是RL训练前那个经过SFT的模型它代表了一个“还没被RL带偏”的基线。PPO训练时策略模型每产生一个新输出都会计算它相对于参考模型的KL散度并把这个散度作为惩罚项加进奖励里。这个机制的核心目的是防止策略更新太快导致模型输出偏离原本的语言分布太远。我自己的实操体会是KL系数要非常小心地做自适应调整。系数开大了模型学不动奖励上不去系数开小了模型迅速漂移生成文本开始出现重复、语无伦次、甚至“奖励黑客”行为。小米报告里披露的自适应KL调整策略方向是靠谱的——它不是固定一个系数跑到底而是根据当前KL散度与目标值的偏差动态增减权重。这个细节看似不起眼实际能省下大量调参时间。3. 算力账要重新算扩展律失效与三种计算资源的博弈3.1 为什么Scaling Law在RL训练中“失灵”大家熟悉的Scaling Law主要描述预训练场景在固定数据分布下模型参数量、数据量、算力量与最终loss之间存在可预测的幂律关系。你按比例放大这三个维度效果基本可以预期。但在RL训练里这条规律很难直接套用。原因在于RL训练的计算消耗没有一个固定的“数据预算”。策略模型要先把数据生成出来才能拿去训练。生成多少数据、数据质量如何、哪些数据值得反复训练这些问题本身就依赖模型当前的状态。于是你面临的是一个“计算回路”算力投入影响模型质量模型质量反过来决定后续算力怎么分配。报告里把这个问题总结得很清晰RL的Scaling不只是加大算力还要同步扩大“生成—训练—评估”整个闭环的吞吐能力。任何一个环节掉队整体扩展效果就会被卡住。3.2 Actor、Critic与Rollout生成之间的资源配比RL训练的计算负载可以拆成三类Rollout生成策略模型做推理采样产出大量候选答案。这一步是典型的“高并发、长序列”负载占用大量显存和算力。Actor训练对采样数据进行梯度更新类似常规的训练负载但输入数据是动态生成的。Critic训练价值模型训练用于计算advantage负载介于前两者之间。我见过很多团队在起步阶段犯同一个错误把绝大多数GPU都分给训练只留少量GPU做采样。结果训练器永远在等数据GPU空转率极高。小米报告里推测也应该做过类似的配比实验核心结论与社区共识一致生成和训练之间的吞吐必须匹配否则总吞吐会被短板卡死。做配比时可以按一个粗略公式估算。假设一台GPU做Rollout生成的吞吐是 $T_{gen}$tokens/s做Actor训练的吞吐是 $T_{train}$tokens/s每个训练step需要消费 $N$ 条轨迹每条轨迹长度约 $L$那么生成侧至少需要 $N \cdot L / T_{gen}$ 秒来备料训练侧处理这批数据需要 $N \cdot L / T_{train}$ 秒。要让两边不互相等待生成侧GPU数量 $G_{gen}$ 与训练侧GPU数量 $G_{train}$ 的关系应大致满足 $G_{gen} \cdot T_{gen} \approx G_{train} \cdot T_{train}$。当然这只是静态估算真实场景里还要考虑采样延迟、批大小、KL计算等开销但它能帮你找到一个合理起点。3.3 KV Cache与生成批处理被忽略的隐性瓶颈很多人以为RL的推理瓶颈只在算力但实际训练中我发现KV Cache的管理才是真正的隐性成本。在线采样时模型要同时处理成百上千条序列每条序列长度可能达到数千token。如果推理框架不能高效管理KV Cache显存会迅速被吃满生成吞吐直接腰斩。好的做法是使用支持PagedAttention这类机制的推理引擎把KV Cache分块管理减少显存碎片。另一个实用技巧是Prefix Caching数学推理Prompt的开头部分是固定的把这段公共前缀的KV Cache缓存住后续采样的开销能省不少。报告里对推理框架的选择我认为大概率也是沿着提升生成吞吐这个方向走的。还有一个常常被忽略的点生成端的Batch策略。RL采样的序列长度差异极大短的几十token长的上千token。如果按常规方式做动态batching调度器本身也可能成为瓶颈。把生成请求切成合适的微批次或者在流式采样中保持连续填充能显著提升GPU利用率。这个优化在实验规模小时看不出来一旦扩展到上万卡时收益非常明显。4. 工程层面的硬仗框架选型、数据管道与断点续传4.1 从Megatron到Ray分布式RL框架的选型逻辑RL训练框架的选型比预训练复杂得多。预训练只需要一个高效的单任务训练框架比如Megatron-LM、DeepSpeed但RL训练需要一个能同时编排多种任务类型训练、采样、评估、奖励计算的调度系统。目前社区的主流方案有几种基于Megatron做核心训练再用Ray等框架做任务调度。基于vLLM/SGLang做高性能生成侧配合训练侧框架。自研一体化的RL训练平台。各自有取舍。Megatron擅长稠密计算但处理动态生成任务时很笨重vLLM在生成吞吐上极强但训练能力有限Ray可以协调资源但需要自己搭建很多组件。小米这种体量的团队大概率走的是混合方案训练侧用成熟的分布式训练框架采样侧用专业推理引擎中间用统一调度层串起来。报告想说的可能是不要期望有一个框架能包打天下RL规模化本质上是多个成熟组件的系统工程。我个人的经验也支持这个判断之前尝试过把所有功能塞进一个自研框架里后期维护成本非常高。模块化、各司其职反而更容易定位问题。4.2 奖励反馈数据管道把标注当作实时流传统监督学习的训练数据是文件批处理准备好一批数据打好标签训练。RL完全不同模型一边生成奖励信号一边回流训练器一边消费。这个“流式”属性要求数据管道具备几个能力低延迟奖励结果产生后要尽快送到训练器否则策略更新滞后样本价值下降。可重放训练中断或数据处理出错时要能重新消费未完成的数据不能丢样本。负载均衡生成速度是波动的数据管道要能缓冲峰值避免训练器饿死。我之前踩过一个坑奖励计算服务因为一个偶发bug返回了一大批全零奖励训练器没有做输入校验直接把这些数据当成正常样本消费了。那个训练步的梯度更新基本等于随机噪声直接把loss打飞了。所以数据管道一定要有一个“异常哨兵”实时监控奖励分布的均值和方差出现连续异常时自动熔断。小米报告里提到的训练不稳定性我怀疑至少有几次就和这类问题相关。4.3 检查点与容错RL训练中的“高危作业”预训练出问题的概率低一天写一次checkpoint基本够用。RL训练不同bug率显著更高奖励奖励异常、调度器崩溃、节点OOM每个都是常态化风险。checkpoint保存频率太低损失几小时训练进度会是灾难性浪费。在RL训练里我推荐至少每个“数据消费周期”保存一次checkpoint这个周期通常对应一次完整的生成—训练流水。保存时不仅要存模型参数、优化器状态、学习率调度器还要存当前的经验池缓冲区和奖励模型状态。很多团队只存了参数恢复训练后发现分布和之前对不上等于白恢复。还有一个细节RL训练的checkpoint恢复要做“双端校准”。训练端恢复模型权重生成端要恢复采样随机种子和Prompt队列状态。两边不对齐恢复后训练的分布就会和中断前产生裂缝进而影响评估结果的一致性和可比性。这个我在跑长周期RL任务时吃过亏后来把这套对齐逻辑直接固化在工程代码里每次恢复都自动校验。5. 训练稳定性的暗礁崩溃、奖励黑客与熵坍缩5.1 训练崩溃的三种典型形态RL训练的稳定性问题比普通训练高出不止一个量级。报告里虽然是用“Hard Road”概括但具体到现象我总结为三种典型形态形态典型表现常见根因排查方向Loss Spike某个step loss突然暴涨数倍随后无法回落异常batch数据、奖励信号突变、学习率过大检查数据管道、reward分布监控、临时降低LR熵坍缩策略过早变得确定性输出多样性骤降熵奖励系数过小、KL约束失效调大entropy coefficient、检查KL target循环锁死模型反复生成相同文本探索完全停滞经验池被同质样本污染、奖励函数局部最优增加采样多样性、重置部分经验池这三种形态我在实际训练中全部遇到过。最隐蔽的是熵坍缩。模型表面上loss在降奖励在涨但生成的回答越来越单一最后退化成模板复读机。如果只盯奖励曲线很难发现模型已经“死”了。所以我在训练面板上一定会同时盯住response的多样性指标比如生成文本的n-gram重复率。5.2 奖励黑客模型学会了敷衍奖励黑客是RL训练里最“聪明”的敌人。模型发现某种行为模式能拿到高奖励而不管这个行为是否真的符合人类意图。最常见的形式包括数学推理里模型为了格式正确而牺牲逻辑严谨性。对话任务里模型学会了迎合奖励模型的偏好而不是回答真正有用。代码生成时模型尽量输出能被规则检查通过的模板代码但实际功能是空壳。解决奖励黑客需要组合拳。首先奖励函数本身要设计得多层次既要看最终答案也要看中间步骤的质量过程奖励其次规则奖励和模型奖励的结果要交叉校验分歧过大的样本要单独审查最后KL散度不能给太松的绳子否则模型探索空间太大很容易找到“刷分”的死角。小米报告里提到用过程奖励模型PRM来强化中间推理步骤的监督这方向我是认可的。纯结果奖励在复杂推理任务里区分度太低两个不同的错误步骤可能得到完全相同的分数模型根本不知道该优化哪里。过程奖励相当于给每个推理楼梯都装了传感器模型更清楚自己错在哪一级。5.3 控制熵与温度防止策略过早“油尽灯枯”训练中另一个稳定性的来源是采样温度。预训练里温度主要是推理时的参数RL训练里它直接影响探索质量。温度过低模型倾向选概率最高的token探索效率差策略容易固化温度过高生成质量崩塌有效样本比例急剧下降。我做RL训练时的经验是初始温度设置在1.0到1.2之间随着训练推进逐步降低用一个退火曲线控制。这个过程中要持续监控生成样本的token熵如果熵下降太快说明探索空间在收窄需要适当提升温度或者提高熵奖励的系数。MiMo报告里关于RL训练超参的描述如果仔细看应该也能找到类似的温度退火策略。还有一个实用细节不要只用一个温度采样。可以同时用几个不同温度跑并行rollout把低温柔和高温生成的样本混合进经验池。低温柔保证样本质量高温柔负责探索新路径。这个做法简单粗暴但对提升策略覆盖面非常有效。6. 写在“上篇”结束后我的几点观察与下篇关注点这份报告读下来我最深的感受是MiMo-V2.6团队把一个经常被当成“炼丹玄学”的过程试图变成一门可记录的工程学科。每一处困难都不是一笔带过而是给出了对应的尝试和调整思路。这种诚实本身就让报告很有价值。报告中还有不少没有直接点名但处处暗示的事情。比如训练稳定性和数据质量之间的微妙关系比如调度框架里隐藏的隐性等待时间比如从单机实验跨越到多机集群时遇到的非线性障碍。这些内容都需要结合训练日志佐证下篇等我对照更多数据和实验配置后再展开。我自己在实际操作中的体会是RL规模化没有银弹。它更像是打磨一套精密仪表数据管道、算力配比、训练稳定性、奖励设计任何一个模块的不成熟都会成为整个系统的短板。读这份报告时我最推荐的姿势是不看结论先看问题然后对照自己的训练系统逐个环节检查有没有同款隐患。如果你现在也在规划自己的RL训练任务上篇提到的数据分布漂移、算力配比失衡、检查点恢复对齐、奖励信号异常熔断建议优先排查。我们下篇见。