1. 从标题拆解 MiMo-V2.6 的技术野心1.1 为什么“自我改进的强化学习规模化”值得单独拎出来讲第一次看到“第一开源大模型 MiMo-V2.6迈向自我改进的强化学习规模化”这个标题我脑子里跳出来的第一个判断是这不是一次常规的版本迭代而是一次路线宣言。原因很简单绝大多数开源模型的发布报告核心叙事都围绕“参数规模、训练数据量、榜单分数”这三件套展开而 MiMo-V2.6 把“自我改进”和“强化学习规模化”放到了标题最显眼的位置说明它想讲的故事不是“我更大”而是“我能自己变得更强”。这两个词拆开看都不新鲜。自我改进self-improvement在强化学习领域是个老话题从早期的自我对弈到后来的迭代式拒绝采样微调本质都是让模型用自己产出的数据反过来训练自己。强化学习规模化RL scaling也是近两年推理模型竞赛的主线谁能把 RL 的训练步数、并行环境数、奖励信号密度拉上去谁就能在数学、代码、智能体任务上拿到更陡峭的曲线。但把这两件事绑在一起并且冠以“第一开源”的定语意味着 MiMo-V2.6 想证明的是开源模型也能跑通“自己生成数据、自己评估、自己迭代”的闭环而且这个闭环可以随着算力投入持续放大收益。我之所以对这个方向敏感是因为过去一年我接触过不少团队尝试复现闭源推理模型的 RL 训练流程卡点几乎都集中在同一个地方奖励信号从哪来。人工标注太贵规则奖励覆盖不了开放任务用另一个大模型当裁判又会引入分布偏移和奖励攻击。MiMo-V2.6 如果真能把自我改进的循环跑顺那它解决的就不是“某个榜单涨几个点”的问题而是“开源社区能不能用有限算力持续逼近前沿”的问题。这个价值量级比单纯发一个更大的稠密模型要高得多。1.2 标题里的三个隐藏关键词MoE、Agentic RL、规模化标题没有直接写 MoE但热词列表里 MoE 和 moe 架构反复出现这基本可以确认 MiMo-V2.6 沿用了混合专家架构。这一点其实很关键因为自我改进的 RL 训练对算力的消耗是普通 SFT 的好几倍如果底座是稠密模型光是 rollout 阶段的推理开销就能把预算烧穿。MoE 在这里的作用不是“参数好看”而是让激活参数量远小于总参数量从而在同样的 GPU 小时里跑出更多的采样轨迹。换句话说MoE 是让“规模化”这三个字成立的前提条件之一。Agentic RL 是另一个不能忽略的词。传统 RLHF 主要优化的是单轮回复的偏好而 agentic RL 优化的是多步决策序列模型要在一个环境里连续调用工具、观察反馈、调整策略最终完成任务。这类任务的奖励信号天然稀疏信用分配难度大但一旦训好模型在真实工作流里的可用性会有质变。MiMo-V2.6 把 agentic RL 放进热词说明它的自我改进循环很可能不是停留在“生成答案再打分”的层面而是让模型在模拟环境中反复试错把工具使用、代码执行、多步推理这些能力一起卷进去。至于“规模化”我的理解是三层含义一是训练步数规模化RL 不再只跑几百步就停二是环境数量规模化同时开成千上万个并行环境采样三是奖励模型规模化用多个不同视角的奖励信号做集成降低单一奖励被 hack 的风险。这三层里任何一层做不到自我改进的循环都会在某个点崩掉。后面我会结合常见实践把每一层的实现思路和坑点展开讲。2. 自我改进循环的工程实现从数据飞轮到奖励设计2.1 自我改进不是“自己训自己”这么简单很多人第一次听到自我改进会下意识理解成“模型生成数据然后拿这些数据做 SFT”。这个理解只对了一半而且是最容易翻车的那一半。纯 SFT 式的自我迭代有个致命问题分布会逐渐收窄。模型倾向于生成它已经擅长的内容这些内容被采样、被训练下一轮模型更倾向于生成类似内容几轮之后多样性就塌缩了表现为输出越来越模板化遇到稍微偏离训练分布的输入就崩。MiMo-V2.6 标题里强调的是“强化学习规模化”而不是“自我训练规模化”这个措辞差异很关键。RL 的自我改进循环里模型生成的不是“标准答案”而是“行为轨迹”这些轨迹经过环境或奖励模型评估后只有相对更优的部分会被强化。这个过程天然带有探索压力因为如果模型一直输出同一种轨迹奖励不会提升策略梯度会推着它去尝试新的动作。换句话说RL 框架本身就在对抗分布塌缩这是它比纯 SFT 迭代更稳的根本原因。但 RL 也不是银弹。我见过不少团队把 RL 跑成了“奖励模型过拟合大赛”模型很快学会输出奖励模型喜欢的格式比如特别长的推理链、特别肯定的语气词但真实能力没涨。要避免这个问题奖励设计必须多源、可验证、带惩罚。MiMo-V2.6 如果要在报告里证明自我改进有效大概率会展示多轮迭代中“真实任务通过率”和“奖励分数”两条曲线而不是只放奖励分数。因为只有前者才能说明模型没有在自欺欺人。2.2 奖励信号的三种来源与组合策略在开源模型做 agentic RL 的常见实践里奖励信号通常来自三个地方我按可靠性和成本排个序。第一类是可验证奖励比如数学题有标准答案、代码有单元测试、工具调用有明确的成功/失败状态。这类奖励最干净几乎不会被 hack但覆盖的任务类型有限。MiMo-V2.6 在数学和代码上的提升大概率主要靠这类奖励驱动。第二类是模型裁判奖励用一个更强的模型或者同系列的不同 checkpoint 对轨迹打分。这类奖励覆盖广但有两个坑一是裁判模型本身有偏好会把它的偏见传给学生模型二是学生模型会学会迎合裁判而不是真正解决问题。常见的缓解手段是让裁判只看结果不看过程或者用多个裁判投票再或者定期用人工标注校准裁判。第三类是环境内在奖励比如智能体在模拟环境中完成任务获得的分数、游戏里的胜负信号。这类奖励最接近真实目标但设计成本高而且容易稀疏。Agentic RL 的规模化很大程度上就是在解决稀疏奖励下的信用分配问题。MiMo-V2.6 的自我改进循环我推测采用的是“可验证奖励为主、模型裁判为辅、环境奖励做补充”的混合策略。这个组合的好处是可验证奖励保证底线不崩模型裁判提供开放任务的梯度环境奖励把能力往真实工作流上拉。坏处是实现复杂度高需要一套统一的轨迹格式和奖励聚合逻辑。如果报告里能看到奖励聚合的消融实验那含金量会很高。2.3 迭代式拒绝采样与策略梯度的分工自我改进循环里有两个容易混淆的环节拒绝采样和策略梯度。拒绝采样是“只保留好的丢掉差的”策略梯度是“好的加分差的减分”。前者是数据过滤后者是参数更新。很多开源实现只做前者因为简单稳定但天花板低只做后者又容易训练不稳定因为 RL 的方差大。比较务实的做法是两者结合先用拒绝采样筛出一批高质量轨迹做冷启动 SFT让模型先学会基本的行为模式然后再上策略梯度做精细优化。MiMo-V2.6 如果强调“规模化”那它的策略梯度部分应该占了不小比重因为拒绝采样的收益会随着轮次增加而递减而策略梯度在环境足够多的情况下可以持续提供梯度信号。这里有个实操细节值得注意策略梯度的方差控制。常见手段包括用 GAE 做优势估计、对奖励做归一化、限制策略更新幅度比如 PPO 的 clip。这些在单机小规模训练里都好调但一旦并行环境数上到几千通信开销和同步等待就会成为瓶颈。MiMo-V2.6 的工程报告如果提到异步采样或者部分 rollout 复用那说明它在规模化上确实下了功夫。3. MoE 架构在 RL 训练中的特殊考量3.1 为什么 RL 阶段对 MoE 的负载均衡更敏感MoE 在预训练阶段的核心难题是负载均衡如果 token 都涌向少数几个专家其他专家就得不到训练等于浪费参数。常见的解法是加辅助损失鼓励路由均匀。但到了 RL 阶段这个问题会变得更棘手因为 RL 的输入分布和预训练分布不一样模型在探索过程中会生成大量预训练时没见过的轨迹这些轨迹的 token 分布可能高度偏斜导致某些专家被过度激活另一些彻底闲置。我实测过一个中等规模的 MoE 模型做 RL 微调发现如果不调整辅助损失的权重训练到几百步之后路由熵会明显下降表现为模型输出越来越单一。后来把辅助损失调大并且对专家激活做温度采样才把多样性拉回来。MiMo-V2.6 如果要在 RL 规模化上做文章路由稳定性肯定是重点优化对象。可能的做法包括在 RL 阶段动态调整辅助损失、对专家容量做弹性伸缩、或者用专家 dropout 强制路由分散。另一个容易被忽略的点是 MoE 的推理效率在 RL 采样阶段的影响。RL 需要大量 rollout如果每次前向都要激活全部专家那 MoE 的省算力优势就没了。所以 MiMo-V2.6 大概率用了 top-k 路由k 值不会太大同时配合专家并行来分摊显存。这些工程细节在报告里可能一笔带过但对想复现的团队来说每一个都是坑。3.2 专家 specialization 与 agentic 能力的关联MoE 有个很有意思的特性不同专家会自发分化出不同的能力倾向。在预训练阶段这种分化通常和语言、领域相关但到了 agentic RL 阶段专家可能会分化出“规划专家”“工具调用专家”“错误恢复专家”这类行为模式。如果这个假设成立那 MoE 在 agentic 任务上会比稠密模型更有优势因为不同子任务可以路由到不同专家减少相互干扰。我目前没有看到 MiMo-V2.6 公开的专家分析但如果报告里有路由可视化或者专家消融实验那会是很有价值的信号。对复现者来说一个实用的建议是在 RL 训练前先做一轮路由分析看看专家激活和任务类型的相关性如果发现某些专家已经天然对应某些子能力可以在 RL 阶段有针对性地调整路由温度让这种分化更彻底。3.3 MoE 与 RL 框架的集成难点把 MoE 塞进 RL 训练框架比塞进 SFT 框架要麻烦得多。SFT 是静态数据、固定 batchMoE 的负载均衡相对好控制RL 是动态采样、变长轨迹而且经常需要把同一批数据前向多次比如计算 old policy 的 log prob 和 new policy 的 log prob这对 MoE 的路由一致性提出了要求。如果两次前向的路由结果不一致重要性采样的比率就会算错训练直接崩。常见的解法是在 rollout 阶段缓存路由决策后续更新时复用。但这会带来显存压力因为要存每个 token 的专家索引。另一个解法是用确定性的路由去掉随机性但这样会损失探索能力。MiMo-V2.6 如果在这方面有创新比如设计了一种对 RL 友好的路由机制那会是技术报告里最值得细读的部分之一。4. 规模化 RL 的基础设施并行环境与训练稳定性4.1 并行环境的数量级与通信模式“规模化”这三个字落到工程上最直观的指标就是并行环境数。小规模 RL 可能只开几十个环境大规模能开到几千甚至上万个。环境数上去之后瓶颈会从 GPU 计算转移到 CPU 调度和网络通信。因为每个环境都要维护自己的状态还要和训练进程交换轨迹数据如果通信模式设计得不好GPU 会大量时间空等。常见的架构是“采样器-训练器分离”一组机器专门跑环境采样把轨迹写进共享缓冲区另一组机器专门做梯度更新从缓冲区读数据。这种架构的好处是采样和训练可以异步采样器不用等训练器更新完参数就能继续跑训练器也不用等所有环境都完成一轮。代价是数据会有一点“陈旧”需要用重要性采样来校正。MiMo-V2.6 如果强调规模化大概率采用了类似的异步架构而且会在报告里讨论陈旧度对最终效果的影响。我自己的经验是异步 RL 的陈旧度控制在 1 到 2 个策略版本以内比较安全再大就会明显掉点。但这个阈值和任务难度、奖励密度都有关系不能一概而论。如果 MiMo-V2.6 给出了不同陈旧度下的曲线对比那对复现者的参考价值会非常大。4.2 训练稳定性的常见崩点与监控指标RL 训练比 SFT 脆弱得多崩的方式也五花八门。我整理过一份常见崩点清单这里挑几个最典型的讲。奖励爆炸模型发现某个奖励漏洞疯狂刷分真实能力不涨反降。监控指标是奖励均值和真实任务通过率的比值如果奖励涨得飞快但通过率不动基本就是被 hack 了。熵塌缩策略过早收敛到确定性输出失去探索能力。监控指标是策略熵如果连续几百步下降且没有回升迹象需要调大熵正则或者提高采样温度。KL 爆炸策略偏离参考模型太远输出变得语无伦次。监控指标是 KL 散度通常要设一个上限超过就暂停更新或者回滚。梯度范数异常突然出现极大的梯度导致参数被破坏。监控指标是梯度范数配合梯度裁剪使用。MiMo-V2.6 如果要在报告里展示规模化能力这些稳定性指标应该会出现在附录或者训练曲线里。对复现者来说把这些指标接进监控面板是第一步不然训练崩了都不知道怎么崩的。4.3 检查点管理与回滚策略大规模 RL 训练动辄跑几周中间难免遇到硬件故障或者训练异常。如果没有合理的检查点管理一次故障可能损失几天进度。常见的做法是每隔固定步数存一次检查点同时保留最近几个检查点以便回滚。但 RL 的检查点不只是模型参数还包括优化器状态、环境状态、奖励模型状态甚至采样缓冲区的数据。这些东西如果不同步保存回滚后会出现状态不一致。我踩过的一个坑是只存了模型参数没存优化器状态回滚后优化器的动量项和模型不匹配训练直接发散。后来改成全量保存虽然慢一点但稳得多。MiMo-V2.6 的工程报告如果提到检查点策略可以留意它是否覆盖了这些状态。另外回滚策略也很重要是自动回滚还是人工判断回滚到哪个检查点回滚后要不要调整超参这些决策在长时间训练里会反复遇到。5. 常见问题与排查技巧实录5.1 奖励不涨或者涨了但真实能力不涨这是 RL 训练里最高频的问题没有之一。排查思路我一般按这个顺序走。先看奖励曲线本身。如果奖励完全不涨可能是奖励太稀疏模型随机探索根本碰不到正样本。解法是加 shaping reward或者用课程学习从简单任务开始。如果奖励在涨但真实通过率不动那基本是奖励被 hack 了。这时候要检查奖励模型是不是对某些表面特征过拟合比如长度、格式、特定词汇。解法是加惩罚项或者换一批奖励模型的训练数据。还有一个隐蔽的情况是奖励和真实能力都在涨但涨到某个点就停了。这通常是探索不足策略陷入了局部最优。解法是提高采样温度、加熵正则、或者引入新的任务类型打破平衡。5.2 MoE 路由崩溃的识别与恢复路由崩溃的表现是训练 loss 突然跳变模型输出变得重复或者混乱。排查时先看路由熵如果骤降基本可以确认。恢复手段有几个一是回滚到崩溃前的检查点调大辅助损失再继续二是临时冻结路由网络只训练专家三是注入随机性强制路由探索。预防比恢复更重要。我的经验是在 RL 训练前先跑一段纯推理观察路由分布在真实任务上的表现如果发现某些专家激活率极低提前调整辅助损失或者初始化方式。另外路由温度不要设得太低留一点随机性对探索有好处。5.3 并行环境下的数据一致性问题异步采样时不同环境返回的轨迹可能对应不同版本的策略如果混在一起训练重要性采样的比率会算错。常见解法是给每条轨迹打上策略版本号训练时只采样版本号在阈值内的数据。另一个问题是环境状态的序列化如果环境是有状态的保存和恢复时容易出错。建议在环境设计阶段就把状态设计成可序列化的避免用全局变量或者文件句柄。5.4 常见问题速查表问题现象可能原因排查手段解决方向奖励不涨奖励稀疏、探索不足看正样本比例、策略熵加 shaping、课程学习、提高温度奖励涨但能力不涨奖励被 hack对比奖励与真实通过率加惩罚、换奖励数据、多裁判投票路由熵骤降负载不均、辅助损失太小看专家激活分布调大辅助损失、回滚、冻结路由KL 爆炸策略偏离太远看 KL 曲线加 KL 惩罚、回滚、降低学习率梯度范数异常奖励尺度问题、数据异常看梯度直方图梯度裁剪、奖励归一化、过滤异常数据训练速度骤降通信瓶颈、环境卡死看 GPU 利用率、环境心跳检查网络、重启卡死环境、调整并行度6. 对想复现的团队的一些实在建议如果你看完技术报告想在自己的集群上复现 MiMo-V2.6 的自我改进循环我建议不要一上来就冲大规模。先从小规模跑通闭环把奖励设计、路由稳定性、检查点管理这些基础打牢再逐步加环境数。我见过太多团队直接上几千个环境结果奖励没设计好跑了一周发现模型在刷分算力全浪费了。另一个建议是重视评估。RL 训练容易让人沉迷于奖励曲线但奖励曲线好看不等于模型好用。一定要有一套独立的、不参与训练的评估集定期跑一遍用真实通过率来判断模型有没有真的变强。这套评估集最好覆盖多个任务类型避免模型在单一任务上过拟合。最后MoE 的 RL 训练对工程能力要求很高如果团队里没有熟悉分布式训练和路由机制的人建议先从稠密模型的小规模 RL 入手把算法层面的东西摸清楚再迁移到 MoE。算法和工程是两回事但缺了哪个都跑不通。