这份报告的标题里有“Hard Road”这个词我一开始以为只是修辞。等把MiMo-V2.6的技术报告完整捋过一遍才意识到这几个字写得相当诚实——大模型强化学习RL的Scaling Up真的是一条到处是坑的路。特别是当你想把RL从“小规模实验”推到“大规模生产”难度完全不在同一个量级。这篇先写上篇重点拆解报告里关于RL规模化的问题定义、核心矛盾、以及那些容易被忽略的工程细节。适合正在做大模型后训练、对齐优化、或者RL训练框架的工程师也适合想理解“为什么RL训练这么难”的算法同学。我会结合报告的思路加上我自己的训练经验展开讲争取让你把它当一份实战笔记来用。1. 报告名称里的“Hard Road”到底指什么RL Scaling Up的问题域1.1 预训练Scaling Law为什么不能直接搬到RL先聊一个最容易被忽略的根本问题预训练和RL的“规模化”优化逻辑完全不一样。预训练的时候每个token都有一个明确的目标——预测下一个tokenloss是可微的、平滑的、信息密度很高的。你今天训的模型和昨天训的模型loss都能直接对比曲线的走势基本可预测。所以预训练能很舒服地套用Scaling Law模型变大、数据变多、loss往下掉能力往上走过程虽然贵但至少是“可计划的”。RL就不是这么回事。RL的优化目标是一个奖励信号是标量不是token级的目标。更麻烦的是这个奖励信号经常是不平滑、不完整、甚至可以被“骗”的。你让模型做数学题它的奖励可能就是“答案对不对”做代码题奖励就是“测试用例过没过”。这种信号密度比语言模型预测下一个token要稀疏得多模型在每一步是很难感知“我哪个token导致最后对了”的。所以当你想把RL往大规模推时第一堵墙就是预训练的那套“规模越大效果越好”的规律在RL里会失效。模型变大了奖励曲线不会自动变平滑数据变多了反馈信号不会自动变稳定。你面对的是一个完全不同的优化地形。从报告里的复盘来看MiMo团队对这一点认知很深。他们没有试图把预训练的Scaling Law硬套到RL头上而是重新定义了RL规模化的核心指标不是“训练了多少步”而是“每一步优化是否足够稳定”。这带来一个很实际的工作习惯变化预训练盯lossRL不能只盯reward。reward涨了能力不一定涨reward没涨能力也可能在涨。你需要一套更完整的观测体系。1.2 RL训练链路多出来的完整反馈回路SFT有监督微调的训练链路很简单拿一批标注好的数据前向传播算loss反向传播更新参数。模型和数据之间是“一次性”的关系不需要实时反馈。RL完全不同它多了一整条反馈闭环# RL训练主循环伪代码只看结构 for step in range(total_steps): prompts sample_curriculum() # 选提示 responses policy.generate(prompts) # 采样/生成 rewards reward_function(responses) # 奖励打分 advantages compute_advantage(rewards) # 优势估计 policy.update(prompts, responses, advantages) # 策略更新每一步都依赖上一步的产出形成了一个带实时反馈的闭环。这个闭环放到单卡小实验上很灵活但放到大规模训练里问题就来了延迟变大。生成一批输出可能要几十秒甚至几分钟训练一步却只要几秒。同步等待的话训练卡大部分时间都在空转算力浪费严重。但完全异步又会面临数据新鲜度的问题——你训练用的数据是五分钟前生成的模型已经更新了十几步分布对不上了。噪声叠加。采样有随机性奖励打分有噪声优势估计也不完美这些噪声在闭环里不断被放大。规模越大回路越长信号在传递过程中的损耗和畸变就越严重。失败会被放大。小规模实验里一次rollout的异常样本损失不大大规模训练里一个批次的异常数据可能污染整个训练进程甚至把模型往错误方向带。报告中提到的“Hard Road”我认为指的就是这条闭环在大规模下的脆弱性。它不像预训练那样有一个稳定的预设路径需要持续调整。这也解释了为什么很多团队做RL训练时感觉“每天活得像个消防员”——不是算法水平不够而是这条反馈回路的每一环都值得用一个专门的系统来保证稳定性。上篇先把这个问题完整摆出来后面才知道该往哪里使劲。2. 奖励信号与策略约束RL规模扩展最先崩掉的环节2.1 奖励来源的层次与各自的坑奖励怎么来直接决定了RL训练的稳定性和上限。我按实际项目中的常见做法把奖励来源分成三层每一层都有自己独特的坑。第一层是规则奖励。比如数学题答案比对、代码单测过不过、JSON格式解析成不成功。优点是计算快、可复现零成本获得缺点是信号太稀疏——一道题要么0分要么100分模型很难从中学到“接近正确”的渐进信号。规模化之后还有个隐患规则覆盖不到的地方模型会找到“空子”。举个我见过的例子代码生成任务里模型学会了输出一堆try-catch包裹的代码单测通过了但代码压根没实现功能。这种reward hacking在规模越大时越严重。第二层是判别式奖励模型RM。用人类偏好数据训练一个打分模型对生成结果给出连续分数。这能解决稀疏问题但RM有自己的短板容易过拟合而且会“钻营”。训练时间一长RM对某些特定模式给出异常高分策略模型会利用这个漏洞生成一批“RM喜欢但人不喜欢”的内容。线上经验是RM必须持续更新还要和策略模型形成某种对抗关系不能固定不动。第三层是模型作为评价者比如用更强的LLM当裁判打分。灵活度高能处理开放式任务但成本贵得惊人。而且LLM打分本身有位置偏差、措辞偏差同一条输出换一种问法能差出好几分。这种噪声在大规模RL里会被放大导致训练非常不稳定。报告里关于奖励系统的核心观点我读下来就一句话不能依赖单一奖励源要按任务性质构建分层的奖励结构。对于有标准答案的任务用规则兜底对于主观任务用LM评判但要让多个样本取均值对于奖励信号稀疏的长链路任务还要考虑过程奖励不能只盯结果。这套思路在规模化里不是可选项是必需品。2.2 KL散度模型不“飘”的安全带RL训练的模型本来就是SFT之后的产物语言能力已经不错了。RL要做的是在这个基础上顺着奖励信号继续优化。但这里有个很危险的现象奖励信号只是某个特定维度上的反馈它不代表语言能力的全部。如果放开手脚让模型只沿着奖励方向更新很快你会发现模型开始“飘”——说话不再像正常语言喜欢重复特定句式语无伦次甚至出现乱码。我见过一次长文本RL训练模型为了拿到“结尾带总结”的加分学会了在任何回答后面都写三遍总结整个回答废掉。这就是为什么RL训练一定要有KL散度约束。具体来说训练过程中始终冻结一份参考模型通常是SFT/预训练版本要求当前策略模型每次更新后都不能偏离参考模型太多。偏离程度用KL散度衡量是一个惩罚项加在奖励里。模型偏离越大得到的惩罚越大强迫它留在“正常语言”的安全区域里。报告里有一句话给我印象很深大意是KL散度不是超参数而是预算。你需要在整个训练过程中管理这笔预算——前面可以松一点让模型尽快探索后面要收紧防止过度偏移。而不是随便设一个值就不管了。很多人把KL系数当成一次性的配置项训到一半发现模型已经飘了还以为是数据问题。实际经验是KL系数至少要分阶段调整监控的时候不光看平均值还要看尾部——如果某些prompt的KL输出异常大那本身就是一种警告信号。2.3 Advantage估计与Batch组成信号的方差从哪来奖励信号拿到之后下一步是计算优势Advantage决定哪些行为被强化、哪些被抑制。这一步的核心在于怎么度量“比预期好多少”。最简单的做法是组内相对比较——把同一条prompt的所有采样样本放一起用每个样本的奖励减去组内平均奖励作为优势值。这就是GRPO这类算法的核心思想好处是省掉了一个值网络风险是组内方差可能被低估。实际训练里我踩过一个典型的坑假设一个batch里有简单题和难题简单题大家都能答对奖励都高难题大家全错奖励都低。如果把它们混在一起算优势模型会倾向于认为“简单题不值得学”因为相对优势被压低了同时也不珍惜难题的少量正反馈。结果是训练半天两头都没学到东西。解决办法是把同类型的任务或者同难度的任务放进同一个batch让优势估计在同分布内计算。理想情况下组内既要全对也要全错模型才知道该往哪个方向调整。报告里透露的提示集分组策略本质上就是在解决这个问题——让每次训练更新都能看到丰富的对比信息。另外还有一个容易被忽略的量策略更新的剪切范围。无论PPO还是GRPO更新幅度都会做裁剪防止一步走太远。规模大了之后这个裁剪参数要特别小心——设置太大会让模型更新剧烈训练曲线剧烈抖动太小又会导致进步缓慢。我个人经验是初期稍微放宽后期收紧配合上面提到的KL预算一起管理。3. MiMo-V2.6在RL规模扩展上的取舍逻辑上篇重点3.1 提示集设计难度谱系与负样本价值RL训练里的“数据”其实指的是用来采样的提示集prompt set。这个提示集的好坏几乎决定了训练的上限。模型在提示集上的表现再强也不代表真实能力提升了提示集覆盖不到的领域模型根本不会去优化。报告里提示集的构建逻辑我认为特别值得学习的是难度谱系和负样本价值两个点。难度谱系的意思是提示集不能全是难题也不能全是简单题。模型对太简单的题目已经能全对无法提供梯度等于浪费算力全是太难的题目模型全军覆没连“部分正确”的渐进信号都拿不到训练同样会卡住。比较理想的情况是控制一道题在当前模型下的通过率——我自己的经验是落在40%~70%区间最合适。这个通过率下模型已经能产出一些正确样本作为“锚点”同时还有大量错误样本提供“对比”优势估计的信息量最大。负样本价值指不要忽略那些错误输出。在RL里错误样本不是用来丢弃的它们本身就是训练信号的一部分。模型必须搞清楚“为什么这条路错了”才能更坚定地走正确的路。甚至可以考虑在提示集中刻意加入一些“诱导性”任务看模型能不能对抗奖励hacking的诱惑比如故意给它一个可以通过作弊获得高分的场景如果模型又作弊了说明策略还需要加强。提示集设计还应该动态化。不要训了几千步还在用同一批提示否则模型会慢慢“背题”而不是形成通用能力。定期从更大的候选池里抽样、根据模型在某一难度上的表现调整分布是规模化RL的一部分。3.2 策略更新轨道GRPO、参考模型与稳定化设计算法层面的选择报告里没有故弄玄虚核心就是在PPO和GRPO之间做出适合规模的取舍。GRPO的优势很直接不需要单独训练一个价值模型省一大半训练成本实现也简单特别适合奖励信号相对可靠的场景。但它有个适用范围——组内n个采样样本的质量必须一致如果每个样本的长度差异过大比如一个是50个token一个是2000个tokentoken级归一化带来的额外噪声会让优化方向不稳定。PPO虽然多了个价值模型的开销但优势估计的方差控制更好尤其适合长文本、多步骤推理这类需要更精细反馈的任务。报告里给的方向是任务越结构化、可控性越强越倾向GRPO任务越自由、开放性越强PPO依然有存在价值。稳定化设计方面我观察到报告特别重视三个细节参考模型坚持全程冻结不给它做任何轻量更新。虽然理论上可以边训边更但实践中一更新参考模型KL惩罚的基准就漂了整个训练轨迹马上乱掉。学习率不能照搬SFT那套。RL训练每步的信息量比SFT大得多同样的学习率可能在SFT里平稳在RL里直接发散。采用更保守的峰值学习率加上开头预热结束时逐渐衰减是更稳妥的路径。所有奖励在进入优化器之前都要做归一化。不同任务得分量纲差异很大不归一化就直接加权等于是让奖励分高的任务支配训练方向隐性会杀掉其他任务的学习信号。3.3 评测先行怎么判断RL是真的在涨RL训练最磨人的情况不是崩溃而是**“既没崩也没进步”**——loss稳定下降reward一路走高但你心里的疑团越来越大模型真的更强了吗还是它在讨好奖励函数报告里对这个问题给出了一个很清晰的思路评测不能是训练的“终点验收”必须是训练过程的“中间仪表盘”。具体做法上我特别认可的是passk取代pass1作为主评测指标。RL训练过程中模型生成的随机性本来就大pass1只能说明模型“头脑最清醒的那一次”表现如何在RL早期很可能连续几十个checkpoint都没变化搞得人很焦虑。passk比如pass32、pass64统计的是多次采样的覆盖率方差小得多能更早看到模型探索空间是否变大了。另一个经验是不只看最终checkpoint。每训练几百步保存一个中间checkpoint统一跑评测集看能力曲线的整体趋势。有时候看起来“最后的模型”没有提升但中间某一版的模型泛化性反而更好说明训练算法已经过度拟合奖励信号了。这时候往回滚checkpoint比继续硬训更有效。评测集本身也要隔离。不能拿训练提示集里相似分布的数据来评测模型很容易在千百次采样中“记住”题面或套路。留出一批完全未见过的同一领域题目才能真实反映泛化能力。4. RL工程的隐性功课数据流、并行与容错4.1 异步rollout吞吐与分布一致性的平衡训练卡贵生成卡也贵。如果训练和生成完全同步训练卡会有大量时间在等待生成结果GPU利用率惨不忍睹。几乎所有大规模RL框架都会采用异步思路生成节点持续采集数据训练节点有足够的数据就开始更新两边通过一个经验池做缓冲。但异步的核心矛盾在于数据新鲜度。训练节点更新到第1000步时缓冲区里的数据可能是第980步时生成的分布已经有一定偏差。偏差在可容忍范围内时影响不大如果生成节点跟不上训练速度数据滞后严重策略分布和采样分布差距过大重要性采样估计的修正能力也会失效。我实践中的经验是三个字控节奏。不追求生成节点绝对最快而是通过动态批量大小和最大队列长度让数据延迟保持在一个可控范围。比如把队列上限设成“最多滞后50个训练步”一旦队列过长就自动让训练节点暂时空转确保反馈回路的新鲜度。报告里我猜测也有类似的机制因为从训练稳定性来看一致性优先于吞吐量。另外注意一个容易出问题的细节rollout生成时使用的temperature、top_p这些采样参数必须和训练框架里记录的一致性。有些团队为了降低生成成本改了采样参数结果RL看到的概率分布和实际生成时的完全不是一回事模型学到的东西自然偏离预期。4.2 显存与并行被Reference模型偷走的资源训练LLM模型本来就很吃显存RL训练更狠因为你要同时加载多个模型。典型RL训练进程里至少同时存在四个角色策略模型当前优化的主角需要梯度参考模型用于KL散度计算全程冻结奖励/评判模型给输出打分根据任务决定是否需要常驻GPU优化器状态Adam动量和方差体积大概是模型参数的好几倍光是策略模型加参考模型显存就已经翻了近一倍。如果你在32G显存的卡上做SFT还能勉强塞进7B模型换成RL可能直接OOM。解决思路也很常规参考模型可以量化后放在CPU上每次前向计算时再搬到GPU做一次推理或者利用ZeRO分片把参考模型、优化器状态这些“不求人”的参数均匀切到各卡上。并行策略上RL训练通常躲不开3D并行数据并行处理不同batch的样本张量并行切分超大模型层流水线并行切分层间计算。但RL有一个和预训练不同的点生成阶段rollout和训练阶段对并行的需求完全不同需要设计灵活切换的能力。现在的方案一般是生成阶段用大小批聚合的推理引擎训练阶段再回归传统训练并行。4.3 容错恢复RL训练最容易被低估的工程点预训练中断了重新加载checkpoint接着训就行影响很小。RL中断问题严重得多因为训练状态不仅仅在模型参数里还在经验池中那一堆生成数据中。经验池丢了等于辛辛苦苦采样的数据全白费经验池和训练状态不一致等于模型拿着一堆过期数据训练还得回去重新采样。我在实际项目中遇到过一个经典事故训练作业被自动调度系统kill掉恢复了模型checkpoint但经验池没恢复恢复后的训练步数直接跳了过去等于那几千条经验被白白浪费。更麻烦的是数据分布已经完全改变模型被迫在“没有历史记忆”的状态下重新探索。所以RL训练的容错设计核心是给每个训练步骤建立“事务性”。每一个step相关的数据都要有明确的ID包括step编号、生成批次ID、采用的checkpoint版本、采样参数版本。恢复训练时能精确知道当前模型状态对应哪一批经验哪些经验已经消费过哪些还在队列里。检查点保存的不仅是模型参数还要把经验池元数据、数据队列状态一起固化。报告里从头到尾强调“不要相信任何一次训练会顺利跑到终点”这句话我深有体会。做RL框架而不是做RL算法实验区别就在于你有没有把这套容错机制当成一等公民来设计。5. 从这份报告能带走的三条Scaling Up经验5.1 选对验证信号密集的任务做RL第一站RL的信号强不强直接决定了训练难度。目前RL在实际落地里最能出效果的方向集中在数学、代码这类结果可验证、反馈可自动化的任务。原因很朴素每道题都能给出明确的做对或做错信号反馈密集策略模型能迅速定位问题并修正。这类任务最适合作为RL能力建设的第一站因为训练过程中能观察到的信号足够多算法调优见效快团队能积累信心。反过来对话质量、文章风格、创意写作这类主观任务信号稀疏且不稳定RL训练经常陷入“奖励打完了模型没有任何改进”或者“奖励模型被策略模型玩弄”的局面。不是说不能做而是应该在其他能力建设成熟之后再挑战的任务。报告里MiMo-V2.6的能力提升路径看起来也是类似的先在数学和代码这类规则信号密集的领域把RL训练流程跑通再把经验复用到更开放的任务上。这个顺序值得所有团队参考。5.2 成本结构决定实验节奏先小模型试配方RL实验的成本和SFT完全不是一回事。RL是“无限次重试”的游戏奖励函数要调提示集要调超参数要调每次调整都要重新rollout、重新训练、重新评测算力开销像滚雪球一样膨胀。正确策略是分层实验先在1B或3B的小模型上把奖励函数、提示集配比、超参数范围这些核心变量大体摸清再迁移到更大的模型上正式训练。小模型跑一轮RL只要几个小时坏了再来大模型跑一轮RL要几天甚至更久如果还要反复试错成本会失控。不过迁移也要留意小模型最优的超参数组合在大模型上不会自动成立。大模型在线学习能力更强但仍然需要重新细调。报告里最值得学习的其实不是“最后的模型参数”而是他们整个从“小规模配方”到“大规模生产”的迁移逻辑每一步都验证不跳跃不赌运气。5.3 把失败样本留下来RL实验可解释性的最后防线RL训练里最怕一种情况训练管线一切正常代码没死loss在降reward在涨但模型能力就是没提升甚至变差了。这时候你要回答一个关键问题“到底哪一步出了问题”没有足够的观测数据这个问题根本无法回答。所以我强烈建议任何做RL训练的团队把以下内容落到日志系统里奖励分布直方图而不是只记录平均奖励。分布形态变化比均值变化更重要比如方差突然变大往往意味着某些样例上模型找到了异常优秀或异常糟糕的路径。KL散度累积时间线清楚地看到模型是何时开始“飘出安全区”的。rollout样本回放定期存几条高奖励和低奖励的完整输出肉眼观察模型在语言质量上是否退化。有时候reward在涨但样本看起来全是“空洞的套话”这本身就是信号。每个失败样本的来源——是哪条提示、哪一轮采样、用了什么采样参数。这样当发现模型在某条提示上表现畸变时能快速追溯原因。有了这些数据你才能区分“奖励函数设计问题”“提示集分布问题”“策略更新超参问题”“框架实现bug”这几类常见的失败原因。没有这些一切讨论都只能靠猜测。我自己的体会是ML实验的记录质量和可诊断性直接决定了团队的迭代速度。谁也不能保证每一步都是直线推进但至少要让每一次失败都“死得明白”。这篇先到这里。报告中关于RL训练动态的细节比如具体采样策略、不同任务的奖励权重、损失函数曲线上的异常形态以及他们如何处理“模型重生成同一答案”这类细粒度问题放到下篇继续拆。如果你正在做自己的RL训练框架遇到类似“奖励在涨但能力不涨”的困惑把上面这些工程点先排查一遍很多时候问题就出在最不起眼的地方。