★ FEATURED ARTICLE 1. 从标题拆解 MiMo-V2.6 的技术野心1.1 这个标题到底在说什么第一次看到《MiMo-V2.6通过扩展强化学习实现模型自我提升》这个标题我的直觉是这不是一篇普通的模型发布公告而是一份技术报告。标题里有两个关键词特别扎眼——扩展强化学习和模型自我提升。前者说的是方法路径后者说的是目标状态。把这两个词放在一起其实是在描述一个闭环模型不再只是被动地吃数据、做下一词预测而是通过强化学习这套机制在训练过程中不断给自己出题、打分、纠偏从而实现能力上的自我迭代。MiMo-V2.6 这个命名方式说明它是一个迭代版本前面的 V2.x 系列应该已经积累了若干代经验。从公开的技术报告惯例来看这类版本号通常意味着架构层面有延续性但在训练范式上做了关键升级。结合热搜词里反复出现的MoE、RL、LLM基本可以判断MiMo-V2.6 是一个基于混合专家架构的大语言模型核心卖点是把强化学习的规模推到了一个新的量级并且这套 RL 流程是围绕自我提升设计的而不是单纯做人类偏好对齐。1.2 为什么自我提升这四个字值得单独拎出来在大模型圈子里自我提升不是一个新词但真正把它做成工程闭环的团队并不多。早期的做法通常是先用监督微调把模型拉到及格线再用人类反馈强化学习做偏好对齐。这套流程的问题在于人类标注是有上限的——成本高、速度慢、覆盖场景有限。当模型能力越来越强人类能提供的有效信号反而越来越少。MiMo-V2.6 技术报告里强调的扩展强化学习我理解核心在于两点一是把 RL 的训练信号来源从纯人类偏好扩展到模型自身可验证的任务上二是把 RL 的规模做大让模型在大量可自动判定对错的任务上反复试错。这就像教一个学生早期需要老师手把手批改作业到了高年级可以让他自己做题、自己对答案、自己总结错题本。老师的作用从逐题批改变成设计题库和评分标准。这个转变的工程意义非常大。它意味着模型的提升不再线性依赖标注团队的人力而是可以随着算力投入持续放大。这也是为什么标题里用的是扩展scaling这个词——它暗示这套 RL 方法是可扩展的不是小打小闹的技巧。1.3 适合谁来读这份技术报告如果你是大模型训练方向的工程师这份报告的价值在于它给出了 RL 扩展的具体工程细节奖励怎么设计、训练怎么稳定、MoE 架构下 RL 有什么特殊坑。如果你是算法研究者值得关注的是它如何定义可验证任务以及如何避免奖励黑客。如果你只是对大模型技术感兴趣的开发者报告里关于 MoE 和 RL 结合的部分能帮你理解当前开源模型和头部模型之间的差距到底在哪。我个人的判断是MiMo-V2.6 这份报告最值得反复读的不是最终刷出来的 benchmark 数字而是中间那些我们试了什么、什么没work、最后怎么绕过去的记录。这些才是真正能迁移到你自己项目里的东西。2. 核心架构与训练范式的选型逻辑2.1 为什么是 MoE 而不是稠密模型MiMo-V2.6 选择 MoE混合专家架构这个决策背后有很现实的算力账。稠密模型要提升能力最直接的办法是加参数但参数一加每次前向传播的计算量就跟着涨推理成本线性上升。MoE 的思路是把模型拆成多个专家子网络每次输入只激活其中一小部分。这样总参数量可以做得很大但单次计算量控制在可接受范围。用一个生活化的类比稠密模型像一家所有菜都由一个全能厨师做的餐厅厨师要会做川菜、粤菜、日料、甜点培养成本极高而且每道菜他都要亲自上手。MoE 像一家有多个专精厨师的餐厅来了川菜订单就派川菜师傅来了甜点就派甜点师傅每个师傅只需要精通自己那一块整体出品效率更高。但 MoE 不是没有代价。它最大的挑战是负载均衡——如果所有输入都涌向同一个专家其他专家就闲置了等于白养。所以 MoE 训练里通常要加辅助损失来鼓励专家分流。MiMo-V2.6 在 RL 阶段还要额外考虑一个问题RL 的梯度信号和 MoE 的路由机制会相互影响路由不稳定会导致训练震荡。这一点在后面的实操部分我会展开讲。2.2 强化学习在 LLM 训练里的位置很多人容易把 RL 和 SFT监督微调混为一谈其实两者解决的问题完全不同。SFT 是模仿——给模型看大量标准答案让它学会在类似输入下输出类似结果。RL 是试错——模型自己生成多个候选答案根据奖励信号调整生成策略好的行为被强化差的行为被抑制。MiMo-V2.6 的技术路线我推测是典型的三段式预训练打底、SFT 对齐格式、RL 提升能力上限。RL 之所以关键是因为它能让模型探索到 SFT 数据里没有的解法。SFT 的天花板是标注数据的质量而 RL 的天花板是奖励函数的设计水平。只要奖励函数能准确判断什么是好答案模型就有可能通过大量采样找到人类标注者都没想到的更优解。这也是自我提升的技术基础当任务本身可验证比如数学题有唯一答案、代码能跑通测试用例模型就可以自己生成大量候选、自己判定对错、自己更新策略形成一个不依赖人工标注的正反馈循环。2.3 扩展强化学习的三个扩展维度标题里的扩展不是随便用的。结合当前 RL 训练的主流实践扩展通常发生在三个维度上第一是数据扩展。可验证任务的规模要足够大否则模型很快会过拟合到有限的任务集上。MiMo-V2.6 应该构建了一个覆盖面很广的任务池涵盖数学、代码、逻辑推理等可自动判定的领域。第二是采样扩展。RL 需要模型对同一个问题生成多个答案来估计策略梯度。采样数量越多梯度估计越准但计算成本也越高。扩展采样意味着在单位训练步内生成更多候选这对推理引擎的吞吐提出了很高要求。第三是训练步数扩展。RL 训练容易出现奖励饱和——模型很快学会拿高分的套路然后停滞。要持续提升需要不断调整任务难度分布让模型始终处在跳一跳够得着的区域。这需要一套动态的课程机制。这三个维度里我认为最难的是第三个。数据扩展和采样扩展本质上是堆资源而课程设计是真正的算法活。MiMo-V2.6 报告里如果有关于难度调度的细节那是最值得细读的部分。3. 强化学习流程的关键细节与实操要点3.1 奖励函数设计可验证任务是核心抓手RL 训练成败的第一决定因素是奖励函数。MiMo-V2.6 走的是可验证任务路线这意味着奖励不是来自一个训练好的奖励模型reward model而是来自确定性的验证器。数学题对答案、代码跑单元测试、逻辑题检查约束满足这些都是可验证的。这样做的好处非常明显奖励信号没有噪声不存在奖励模型被忽悠的问题。但坏处也很直接可验证任务的覆盖面有限。写作、开放问答、创意生成这些任务没有唯一正确答案很难用规则验证。所以 MiMo-V2.6 的能力提升大概率集中在推理密集型任务上而不是全面开花。我在实际做 RL 训练时踩过的一个坑是验证器写得太严格导致模型大量输出被判错奖励信号稀疏训练几乎不动。后来改成部分给分——比如数学题答案格式对但计算错给 0.3 分格式和答案都对给 1 分——训练才跑起来。这个经验对做类似项目的人应该有用。3.2 策略梯度估计与方差控制LLM 的 RL 训练通常用策略梯度方法最主流的是 PPO 及其变体。核心思想是对每个问题采样多个答案根据奖励高低调整每个答案的生成概率。奖励高于平均的答案提高其概率低于平均的降低其概率。这里有个技术细节很关键优势估计。直接用原始奖励做梯度方差会非常大训练不稳定。常见做法是减去一个基线baseline通常是同一问题下所有采样答案的平均奖励。这样做的效果是模型只关心相对好坏不关心绝对分数梯度方差大幅降低。MiMo-V2.6 作为大规模 RL 训练肯定在方差控制上做了不少工作。我推测它可能用了组内归一化group normalization之类的技巧把同一 prompt 下的多个采样作为一个组组内做标准化。这种做法在近期的开源 RL 实现里很常见效果也确实稳。3.3 MoE 架构下 RL 训练的特殊处理MoE 和 RL 结合有一个稠密模型没有的坑路由漂移。RL 训练会改变模型的输出分布而 MoE 的路由网络是根据输入特征决定激活哪些专家的。当输出分布变化时路由决策也会跟着变可能导致某些专家突然被大量激活另一些被冷落。这种不均衡会进一步加剧训练震荡。常见的应对手段有两个。一是冻结路由网络只训练专家网络和注意力层。这样做的好处是路由稳定坏处是模型失去了根据任务动态调整专家分配的能力。二是给路由加一个熵正则项鼓励路由分布保持一定的多样性避免坍缩到少数专家。我个人的经验是在 RL 训练早期路由确实容易乱这时候可以先用较小的学习率让模型适应等奖励曲线稳定后再逐步放大学习率。MiMo-V2.6 报告里如果提到了路由相关的稳定性技巧那对做 MoERL 的团队来说是刚需。3.4 训练稳定性KL 约束不能省RL 训练最怕的是模型跑偏——为了拿高奖励生成一些人类看起来莫名其妙但恰好能通过验证器的内容。这就是所谓的奖励黑客。防止这个问题的主要手段是加 KL 约束在优化奖励的同时惩罚当前策略偏离参考策略通常是 SFT 后的模型太远。KL 系数的选择是个经验活。系数太大模型不敢探索能力提升有限系数太小模型放飞自我输出质量崩坏。我试过的做法是动态调整训练初期用较大的 KL 系数稳住等模型适应了 RL 流程再逐步放松。MiMo-V2.6 作为大规模训练应该有一套自适应的 KL 调度策略。注意KL 约束是参考策略和当前策略之间的散度参考策略一旦选定就不要中途更换否则约束会失效训练容易崩。4. 完整实操流程与关键环节复现4.1 整体训练流水线拆解如果要复现 MiMo-V2.6 这类扩展强化学习的训练流程整体流水线大致分四个阶段阶段一基础模型准备。拿一个预训练好的 MoE 基座先做 SFT让模型学会遵循指令、输出格式规范。这一步的产出是参考策略后续 RL 的 KL 约束就锚定在它身上。阶段二任务池构建。收集或生成大量可验证任务按难度分层。数学题可以从简单算术到竞赛级证明代码题可以从单函数实现到多文件项目。每个任务都要配一个确定性验证器。阶段三RL 训练循环。对每个任务用当前策略采样多个答案验证器打分计算优势更新策略。同时监控 KL 散度、奖励均值、答案长度等指标。阶段四评估与迭代。在留出任务集上评估看能力是否真的提升而不是过拟合到训练任务。根据评估结果调整任务难度分布进入下一轮。这个流水线听起来直白但每个阶段都有大量工程细节。下面我挑几个最关键的展开。4.2 任务难度调度让模型始终跳一跳够得着RL 训练最理想的状态是模型成功率维持在 50% 左右。成功率太高任务太简单梯度信号弱成功率太低任务太难模型几乎拿不到正奖励也学不动。实现难度调度的常见做法是维护一个任务难度估计。每轮训练后统计每个任务的成功率把成功率过高的任务标记为太简单成功率过低标记为太难然后从任务池里补充中等难度的新任务。MiMo-V2.6 作为大规模训练任务池应该有自动生成和难度标注的机制。我实操时的经验是难度调度不要做得太激进。如果每轮都大幅调整任务分布模型会一直在适应新分布反而学不到稳定能力。比较稳的做法是每 N 轮调整一次且每次只替换一小部分任务。4.3 采样与推理的工程优化RL 训练的计算开销大头在采样。每个训练步要对一批任务各生成多个答案这本质上是一次大规模推理。如果推理引擎效率低整个训练就被拖垮。优化方向有几个。一是用连续批处理continuous batching把不同长度的生成请求动态打包提高 GPU 利用率。二是用 KV 缓存复用同一 prompt 的多个采样可以共享前缀的 KV 缓存只对分叉后的部分重新计算。三是控制生成长度RL 训练里模型容易生成越来越长的答案来凑正确性需要设置长度惩罚。MiMo-V2.6 报告里如果提到采样吞吐的具体数字可以拿来估算它的训练规模。比如每步采样多少条、每秒生成多少 token这些数字能反推出它用了多少卡、训练了多久。4.4 奖励归一化与优势计算的具体实现这一块是 RL 训练的数学核心我用伪代码说明常见实现# 对每个 prompt 采样 G 个答案 rewards [verifier(prompt, answer) for answer in answers] # 形状 [G] # 组内归一化计算优势 mean_r sum(rewards) / G std_r sqrt(sum((r - mean_r)**2 for r in rewards) / G eps) advantages [(r - mean_r) / std_r for r in rewards] # 策略梯度损失简化版 pg_loss 0 for i, answer in enumerate(answers): ratio exp(logprob_current(answer) - logprob_old(answer)) clipped_ratio clip(ratio, 1 - eps_clip, 1 eps_clip) pg_loss -min(ratio * advantages[i], clipped_ratio * advantages[i]) / G # 加上 KL 惩罚 kl_penalty kl_divergence(current_policy, reference_policy) total_loss pg_loss beta * kl_penalty这段代码里eps是防止除零的小量eps_clip是 PPO 的裁剪系数通常取 0.2beta是 KL 惩罚系数。实际训练里这些超参都要调而且不同任务可能需要不同的值。提示组内归一化要求每个 prompt 至少采样 4 个答案否则均值和方差估计不准。采样数越多越稳但成本也越高一般 8 到 16 是常见区间。5. 常见问题与排查技巧实录5.1 奖励不涨或涨到一半停滞这是 RL 训练最常见的问题。排查顺序我一般是这样先看奖励分布。如果所有答案奖励都差不多说明任务太简单或太难模型没有区分度。如果奖励方差很大但均值不涨说明模型在探索但没找到正确方向可能是奖励函数设计有问题。再看 KL 散度。如果 KL 一直很小说明模型不敢偏离参考策略探索不足需要调小 KL 系数。如果 KL 爆炸式增长说明模型跑偏了需要调大 KL 系数或降低学习率。最后看答案长度。如果长度持续增长但奖励不涨模型可能在凑字数需要加长度惩罚。5.2 训练过程中突然崩溃RL 训练崩溃的表现通常是奖励断崖式下跌、KL 散度飙升、生成内容变得重复或无意义。原因可能是学习率过大、某个 batch 的奖励异常、或者 MoE 路由坍缩。应急处理是回滚到上一个 checkpoint降低学习率检查最近的数据里有没有异常样本。预防措施是加梯度裁剪、监控每个 batch 的奖励分布、定期保存 checkpoint。5.3 MoE 专家利用率严重不均如果发现某些专家几乎不被激活说明路由出了问题。可以检查路由 logits 的分布如果某个专家的 logit 持续偏高说明路由坍缩了。解决办法是加负载均衡损失或者临时冻结路由网络让专家先各自学好。5.4 常见问题速查表问题现象可能原因排查方向解决手段奖励不涨任务难度不匹配统计成功率分布调整任务池难度奖励方差小任务太简单看答案是否高度相似补充难题KL 爆炸学习率过大或奖励异常检查梯度范数降学习率、加梯度裁剪答案越来越长长度未惩罚统计平均长度加长度惩罚项专家利用率不均路由坍缩看路由 logits 分布加负载均衡损失训练震荡batch 间奖励波动大看奖励曲线增大 batch size、组内归一化5.5 几个容易被忽略的实操心得第一个心得验证器要先自测。在正式训练前拿一批已知正确答案的样本过一遍验证器确保它不会误判。我见过验证器把正确答案判错的情况导致模型学了一堆错误行为。第二个心得保留一部分任务不参与训练。这些留出任务用来评估模型是否真的泛化了而不是记住了训练任务的答案。留出集的比例一般 5% 到 10%。第三个心得RL 训练不要一次跑太久。训练时间越长模型越容易过拟合到奖励函数的漏洞上。比较稳的做法是训练一段时间就评估一次发现评估指标不再提升就停而不是死磕训练奖励。第四个心得记录每个任务的采样答案。出问题时可以回溯看模型到底生成了什么。这些日志在调试奖励黑客问题时特别有用。6. 从 MiMo-V2.6 看 RL 训练的未来走向6.1 可验证任务的天花板在哪MiMo-V2.6 走的可验证任务路线能力上限取决于可验证任务的覆盖面。数学、代码、逻辑这些领域天然可验证但写作、对话、创意这些领域很难。如果 RL 训练只在这些可验证领域做模型可能变成偏科生——推理很强但表达和交互能力没跟上。我推测 MiMo-V2.6 的后续版本会往两个方向走一是扩展可验证任务的边界比如用形式化方法验证更多类型的推理二是把 RL 和奖励模型结合用奖励模型处理不可验证任务同时用可验证任务校准奖励模型减少奖励黑客。6.2 自我提升的边界与风险模型自我提升听起来很美好但有个根本问题模型能提升到超过它自己判断能力的水平吗如果验证器是模型自己写的那验证器的水平就是天花板。所以真正的自我提升前提是有一个比模型当前能力更强的验证信号。这个信号可以来自形式化系统、可以来自人类专家、也可以来自多个模型的交叉验证。另一个风险是能力退化和价值观漂移。RL 训练只优化奖励函数定义的目标如果奖励函数没覆盖某些重要维度模型可能在这些维度上退化。比如只优化数学正确率模型可能变得只会输出答案不会解释过程。所以 RL 训练必须配合全面的评估体系不能只看单一指标。6.3 对做 RL 训练的团队的建议如果你正在或准备做 LLM 的 RL 训练我的建议是先把 SFT 做扎实再碰 RL。SFT 没做好RL 的参考策略就是歪的KL 约束锚在一个差模型上训练很难好。然后从小规模开始用几百个任务跑通流程确认奖励能涨、训练稳定再逐步扩大任务池和采样规模。工具选型上推理引擎优先选支持连续批处理和 KV 缓存复用的训练框架优先选支持 MoE 和分布式 RL 的。不要自己从零造轮子除非你的团队有很强的系统能力。最后RL 训练是个需要耐心的活。奖励曲线不会一直涨中间会有平台期、会有回退关键是建立一套可靠的监控和回滚机制让每次实验都能快速定位问题。MiMo-V2.6 这份报告最大的价值就是把这些工程细节摊开给你看让你少走一些弯路。
阅读完成 · 觉得有帮助？
