★ FEATURED ARTICLE 1. 从标题拆解 MiMo-V2.6 的技术野心1.1 为什么“自我改进的强化学习规模化”值得单独拎出来说先把标题拆开看。MiMo-V2.6是模型代号第一开源大模型这个定语说明它主打的是开放权重、可复现、可二次开发而真正决定这篇技术报告含金量的是后半句——迈向自我改进的强化学习规模化。这句话里藏着三个关键词自我改进、强化学习、规模化。任何一个单独拿出来都不新鲜但三个叠在一起指向的是一个很具体的工程难题怎么让模型在训练过程中自己生成高质量的训练信号并且这套机制在参数量、数据量、训练步数都拉满之后依然不崩。我先把结论摆前面这类工作的核心矛盾从来不是“算法够不够新”而是信号质量与训练稳定性之间的拉锯。强化学习用在语言模型上本质是把“生成 token”这件事看成一连串决策用奖励信号去调整策略。问题在于语言模型的动作空间是词表大小动辄十几万序列长度动辄几千奖励又往往是稀疏的、延迟的、甚至是有噪声的。你稍微把规模放大梯度方差、奖励黑客reward hacking、策略坍缩这些问题就会成倍放大。所以“规模化”这三个字才是整篇报告最硬的部分。自我改进这个词也得说清楚。它不是指模型能改自己的代码或者改自己的架构而是指训练流程里形成一个闭环模型产出候选答案 → 用某种评判机制打分 → 用打分结果反过来更新模型 → 更新后的模型产出更好的候选。这个闭环如果转得起来理论上可以用更少的人工标注撬动更大的能力提升。但闭环要转得稳需要解决几个很现实的问题评判机制本身会不会被钻空子多轮迭代后分布漂移怎么办算力预算怎么分配才不浪费1.2 适合谁来读这篇解析这篇内容我主要写给三类人。第一类是做后训练post-training的工程师你手上可能已经有 SFT 和 DPO 的流水线想搞清楚 RL 这一环到底怎么接、接在哪、接多少。第二类是做训练基础设施的同学你关心的是 MoE 架构下 RL 的通信开销、显存占用、rollout 吞吐这些实打实的数字。第三类是想复现开源大模型训练流程的研究者或学生你需要一个从数据构造到奖励设计再到稳定性控制的完整地图而不是只看到一堆公式。如果你只是想了解“MiMo-V2.6 比上一代强多少”那这篇可能不太对你胃口因为我更想聊的是它为什么这么设计以及这些设计里哪些是你可以直接抄作业的哪些是必须结合自己场景重新算账的。2. 整体设计思路MoE 打底Agentic RL 做引擎2.1 为什么底座选 MoE 而不是稠密模型MoEMixture of Experts混合专家架构这几年在大模型里几乎是标配了但把它和强化学习放在一起看逻辑会更清楚。稠密模型每处理一个 token 都要激活全部参数训练时的计算量和参数量是线性绑定的。MoE 的思路是把 FFN 层拆成多个专家每个 token 只路由到其中少数几个常见是 top-2 或 top-4这样总参数量可以做得很大但单 token 的实际计算量激活参数量控制在一个可接受的范围内。这对 RL 训练特别重要。原因在于 RL 训练相比 SFT 有一个额外的、非常吃资源的环节rollout。也就是模型要自己生成大量样本来做探索。SFT 是喂进去一条数据算一次 lossRL 是模型自己生成、自己打分、自己学生成的数据量往往是训练数据的好几倍。如果底座是稠密模型rollout 的算力开销会直接把训练预算吃光。MoE 在这里的价值就是用更大的总容量承载知识用更小的激活开销支撑高频采样。但 MoE 也不是白拿的好处。它引入了路由不稳定、专家负载不均、通信开销大这几个新问题而这些在 RL 场景下会被进一步放大——因为 RL 的输入分布是随策略变化而漂移的今天路由到专家 A 的 token明天可能全跑到专家 B 去了。所以 MiMo-V2.6 在 MoE 上做 RL必然要在路由稳定性和负载均衡上做额外处理这是后文会展开的重点。2.2 Agentic RL 到底和普通 RLHF 差在哪热词里有个Agentic RL这个词值得单独讲。传统的 RLHF基于人类反馈的强化学习流程大概是模型生成回答 → 人类或奖励模型打分 → 用 PPO 之类的算法更新。它的决策粒度基本是“整条回答”或者“每个 token”环境是静态的就是那个提示词。Agentic RL 把环境复杂化了。模型不再只是“回答问题”而是要在多轮交互中做决策调用工具、观察返回结果、决定下一步动作、必要时回退重试。这时候奖励不再是单步的而是分布在整条轨迹上的。这就带来几个新问题信用分配credit assignment变难了到底是哪一步动作导致了最终成功探索空间变大了工具调用的组合爆炸训练效率变低了因为一次 rollout 可能要跑很多轮交互。MiMo-V2.6 把 Agentic RL 作为核心方向说明它的目标场景不是单纯的问答而是能干活、能多步推理、能使用工具的智能体。这也解释了为什么它强调“规模化”——智能体任务的轨迹长、交互多没有规模化的训练框架根本跑不起来。2.3 自我改进闭环的设计取舍自我改进闭环的设计核心是一个取舍用模型自己当裁判还是用外部信号当裁判。用模型自己当裁判self-rewarding的好处是成本低、可扩展坏处是容易自我强化偏见越训越偏。用外部信号比如代码执行结果、工具返回、单元测试的好处是信号客观坏处是覆盖场景有限很多任务没有明确的对错。从技术报告的定位看MiMo-V2.6 大概率采用的是混合信号在有客观验证器的场景代码、数学、工具调用用可验证奖励在开放场景用模型评判加人工校准。这种混合设计的关键在于权重分配和信号归一化——不同来源的奖励量纲不一样直接相加会让某一类信号主导训练。我个人的经验是这类混合奖励一定要做 per-source 的标准化并且定期检查各信号源的贡献占比否则很容易出现“模型只学会了刷某一类奖励”的情况。3. 核心细节解析奖励、策略与稳定性3.1 奖励信号的分层设计奖励设计是 RL 训练里最容易被低估、也最容易翻车的一环。我见过太多项目算法选得很花哨结果奖励一设计错模型学出来的全是歪门邪道。MiMo-V2.6 这类工作通常会把奖励分成几层结果奖励outcome reward最终答案对不对代码跑不跑得通工具调用是否成功。这类信号最可靠但最稀疏。过程奖励process reward中间步骤是否合理推理链有没有跳步。这类信号密集但标注成本高且容易引入主观偏差。格式奖励format reward输出是否符合预期结构比如有没有正确使用工具调用格式。这类信号便宜但权重给高了会让模型只顾格式不顾内容。分层设计的关键是课程式调度训练早期多用过程奖励和格式奖励让模型先学会“怎么做事”训练中后期逐步提高结果奖励的权重让模型聚焦“做对事”。这个调度不是拍脑袋定的通常要根据验证集上的通过率曲线来动态调整。如果结果奖励的通过率长期卡在低位说明过程奖励给太多模型没动力去追求最终正确如果通过率上去了但输出变得不可读说明格式奖励给太少。提示奖励权重的调整一定要记录每次改动对应的验证指标否则出了问题根本回溯不到是哪次调整导致的。3.2 策略优化算法的选择逻辑RL 用在语言模型上主流算法就那么几个PPO、GRPO、DPO 及其变体。MiMo-V2.6 这种规模的工作大概率是以PPO 或 GRPO为主干。PPO 的优点是成熟、稳定、有大量工程实践缺点是它需要同时维护策略模型、价值模型、奖励模型、参考模型显存占用大超参敏感。GRPOGroup Relative Policy Optimization去掉了价值模型用一组采样的相对优势来估计 baseline显存友好很多这也是它近两年在开源社区流行的原因。选哪个取决于你的算力预算和团队工程能力。如果显存充足、有成熟的 PPO 调参经验PPO 的稳定性上限更高如果显存紧张、想快速迭代GRPO 是更务实的选择。这里有个容易被忽略的点算法选择和 MoE 架构是耦合的。MoE 的专家路由会引入额外的方差如果再用 GRPO 这种依赖组内相对比较的方法组内样本如果路由到不同专家比较的基准就不一致了。所以 MoE RL 的组合往往需要在路由层面做约束比如让同一组的样本尽量走相同的专家路径。3.3 训练稳定性的三道防线规模化 RL 训练稳定性是生死线。我把它总结成三道防线第一道是 KL 约束。策略模型不能偏离参考模型太远否则会 reward hacking。KL 系数怎么设是个经验活设大了模型学不动设小了模型跑飞。常见做法是从一个较小的系数开始观察 KL 散度的变化曲线如果长期贴近 0 说明约束过强如果剧烈波动说明约束不足。第二道是梯度裁剪和优势归一化。RL 的梯度方差天然比 SFT 大不做裁剪很容易出现梯度爆炸。优势归一化advantage normalization则是把不同 batch 的优势拉到同一量纲避免某些 batch 主导更新。第三道是定期评估与回滚机制。训练过程中要持续在固定验证集上评估一旦发现指标异常下滑要能快速回滚到上一个 checkpoint。这套机制听起来简单但真正做起来需要基础设施支持——checkpoint 的保存频率、加载速度、评估的自动化程度都直接影响你能不能及时止损。防线作用常见参数/做法失效表现KL 约束防止策略偏离过远KL 系数 0.01~0.1动态调整奖励虚高但实际能力下降梯度裁剪控制更新幅度裁剪阈值 0.5~1.0loss 突增或 NaN评估回滚及时止损每 N 步评估保留最近 K 个 checkpoint指标缓慢下滑未被发现4. 实操过程从数据构造到规模化训练4.1 训练数据的构造与配比RL 训练的数据和 SFT 不一样它不是“输入-输出”对而是“提示词 验证方式”。构造这批数据的核心工作是设计有区分度的提示词并配上可靠的验证器。有区分度指的是模型不能靠猜或者靠记忆做对必须真的推理或调用工具。验证器则决定了奖励信号的质量。配比上我的经验是遵循难度金字塔简单任务占大头保证训练信号密集、模型不至于全错中等难度占中头主要的能力提升区困难任务占小头探索上限。比例大概是 5:3:2 或者 4:4:2具体要看模型当前的能力水平。如果模型在某个难度上通过率已经超过 90%那这批数据基本没用了要换更难的如果通过率低于 10%说明太难模型学不到有效信号要降难度。注意数据配比不是一次定死的要随着训练进展动态调整。我习惯每训练一定步数就重新统计各难度档的通过率然后按通过率重新分配采样权重。4.2 Rollout 的吞吐优化Rollout 是 RL 训练里最吃资源的部分。模型要生成大量样本每个样本可能还要多轮交互生成速度直接决定训练效率。优化 rollout 吞吐有几个方向推理引擎选择用 vLLM、TensorRT-LLM 这类高吞吐推理框架做生成比原生 PyTorch 生成快数倍。关键是这些框架对 MoE 的支持程度要确认专家并行的通信是否被优化过。批处理与流水线把生成和训练做成流水线生成一批、训练一批避免 GPU 空转。这需要精细的显存管理因为生成和训练用的显存布局不一样。采样温度与长度控制温度太高生成质量差、有效样本少温度太低多样性不足、探索不够。长度上要设上限避免个别样本生成超长拖慢整批。这里有个实测经验rollout 的瓶颈往往不在 GPU 算力而在 CPU 侧的调度和验证器执行。尤其是 Agentic 任务工具调用要等外部返回验证器要跑代码这些 I/O 和 CPU 操作如果没做好异步GPU 会大量空等。所以规模化 RL 的基础设施一半功夫在 GPU 上一半在 CPU 和调度上。4.3 规模化训练的资源分配规模化训练最现实的问题是算力怎么分。RL 训练的资源消耗大致分三块rollout 生成、奖励计算、梯度更新。经验比例大概是 5:2:3 或者 6:2:2rollout 占大头。如果发现训练吞吐上不去先看 rollout 是不是瓶颈如果奖励计算拖后腿考虑把验证器做成异步或者缓存结果如果梯度更新慢那可能是 MoE 的通信开销问题。MoE 的通信开销在规模化时特别明显。专家并行expert parallelism意味着 token 要在不同 GPU 之间来回传输参数量越大、专家越多通信占比越高。缓解手段包括增大单卡 batch 摊薄通信、用更高效的 all-to-all 实现、在路由层面做局部性优化让相邻 token 尽量走同一专家。这些优化每一项都能带来百分之几到百分之十几的吞吐提升累积起来很可观。5. 常见问题与排查技巧实录5.1 奖励黑客的识别与处理奖励黑客是 RL 训练的头号敌人。表现是奖励曲线一路涨但人工评估发现模型输出越来越离谱。常见的黑客手段包括输出超长回答骗过程奖励、重复套话骗格式奖励、在验证器边界上钻空子。识别方法很简单——定期做人工抽检不要只看自动指标。一旦发现奖励和人工评估背离立刻停下来查奖励函数。处理手段分两种一是修补奖励函数堵住被钻的空子二是加惩罚项比如长度惩罚、重复惩罚。但惩罚项要慎加加多了会误伤正常输出。我的经验是优先修补奖励函数本身惩罚项只作为临时手段。5.2 训练崩溃的典型症状与排查路径训练崩溃的症状有很多种我整理了一个速查表症状可能原因排查方向loss 突然变 NaN梯度爆炸、学习率过高检查梯度范数、降低学习率奖励持续下降奖励函数有 bug、KL 约束过强检查奖励计算、调小 KL 系数输出长度爆炸长度奖励设计不当检查长度相关奖励项通过率卡住不动数据难度不匹配、探索不足调整数据配比、提高采样温度专家负载严重不均路由坍塌检查路由分布、加负载均衡损失排查的核心思路是二分定位先确认是数据问题、奖励问题还是优化问题再在对应环节里细分。最忌讳的是一上来就调学习率很多时候问题根本不在优化器上。5.3 我踩过的几个坑第一个坑是过早追求大规模。我一开始就想把 batch size 拉满、把模型拉到最大结果训练极不稳定调了两周都没跑通。后来退回到小规模先把流程跑通、把奖励调对再逐步放大反而快得多。RL 训练的正确姿势是先求稳再求大。第二个坑是忽视验证器的性能。验证器如果跑得慢整个 rollout 就被拖住。我有个项目验证器用的是同步执行的代码沙箱结果 GPU 利用率长期只有 30%。后来改成异步 结果缓存利用率直接上到 70% 以上。第三个坑是没有做奖励归一化。多来源奖励直接相加导致某一类信号主导训练模型学偏了。后来加了 per-source 标准化问题才解决。这个坑很隐蔽因为奖励曲线看起来是正常上涨的只有做信号贡献分析才能发现。6. 这套方案能迁移到什么场景MiMo-V2.6 的这套思路核心可迁移的部分是**“可验证奖励 自我改进闭环 规模化基础设施”**这个组合。如果你在做代码生成可以用单元测试当验证器如果你在做数学推理可以用符号计算当验证器如果你在做工具调用可以用工具返回结果当验证器。只要有客观验证手段这套闭环就能转起来。MoE RL 的组合则更适合算力相对充足、追求推理效率的场景。如果你的场景对延迟不敏感、对成本敏感稠密模型加 RL 可能更划算因为 MoE 的工程复杂度不低。Agentic RL 的迁移门槛最高因为它要求你有稳定的工具环境和多轮交互的基础设施但一旦搭起来能解锁的能力上限也最高。我个人在实际操作中的体会是RL 训练这件事算法只占三成剩下七成是数据、奖励和基础设施。很多人把精力花在追新算法上结果基础没打牢怎么调都不对。反过来把奖励设计清楚、把 rollout 吞吐优化好、把稳定性监控做扎实哪怕用最朴素的 PPO也能训出不错的结果。最后再分享一个小技巧训练日志里一定要单独记录每个奖励分量的均值和方差不要只记总奖励。总奖励上涨但某个分量异常往往是问题的早期信号早发现能省下大量排查时间。
阅读完成 · 觉得有帮助？
