1. 从能对话到会进化MiMo-V2.6 到底在解决什么问题大模型圈子这两年有个很明显的分水岭2023 年大家在比谁的模型能聊2024 年比谁的模型能干活到了 2025 年之后真正拉开差距的变成了——谁的模型能自己变强。MiMo-V2.6 这份技术报告最抓人的地方不是它又刷了多少榜单而是它把自我改进这件事从论文里的概念往工程可复现的方向推了一大步。关键词里那几个词——强化学习、MoE、Agentic RL——其实已经把这篇文章的骨架交代清楚了它是一套围绕强化学习规模化搭建起来的开源大模型训练体系。先说清楚它是什么。MiMo-V2.6 是一个开源大模型采用 MoEMixture of Experts混合专家架构核心卖点是在后训练阶段大规模引入强化学习并且把自我改进作为训练目标之一。它能做什么简单讲就是让模型在复杂任务里通过试错、反馈、再试错的方式逐步提升推理、工具调用、多步决策这类能力而不是单纯靠堆人类标注数据。适合谁看如果你在做模型后训练、Agent 系统、强化学习落地或者只是想知道开源模型现在到底走到哪一步了这篇都值得细读。我先把一个容易混淆的点讲透。很多人一听自我改进就联想到科幻片里的 AI 自己改自己代码其实不是。这里的自我改进指的是模型在强化学习循环里利用自己生成的数据、自己产生的反馈信号去优化下一轮策略。它依然需要奖励函数、需要环境、需要训练框架只不过数据来源从纯人工变成了模型自产为主。这个区别非常关键因为它决定了整套系统的工程重心——你不再主要纠结标注质量而是要纠结奖励信号设计、采样效率、训练稳定性这三件事。为什么这件事现在才被认真做因为强化学习在大模型上一直有个尴尬小规模能跑通一放大就崩。样本效率低、奖励稀疏、策略漂移、训练不稳定随便一个都能让几个星期的算力打水漂。MiMo-V2.6 的价值就在于它把规模化这三个字当成核心命题来解而不是当成一个附带说明。下面我会从架构、RL 机制、Agentic 场景、工程落地几个角度把它拆开讲中间穿插我自己踩过的坑和能直接抄的做法。2. MoE 架构为什么成了强化学习规模化的地基2.1 稀疏激活让大和快不再互斥MoE 的核心思想其实很朴素模型总参数量可以很大但每次前向只激活其中一小部分专家。打个比方一家公司有 200 个专家但每个项目只叫最相关的 8 个人来开会既保留了知识广度又控制了单次成本。MiMo-V2.6 走的就是这条路——总参数规模撑起容量激活参数控制住计算量。这件事对强化学习为什么重要因为 RL 训练最烧的不是单次前向而是海量的采样和反复的策略评估。一个 Agent 任务可能要 rollout 几十上百步每一步都要过模型。如果每步都激活全部参数成本会直接爆炸。MoE 的稀疏激活把单步成本压下来才让大规模 RL 采样在经济上成立。换句话说MoE 不是为了炫技它是 RL 规模化的成本前提。但 MoE 也不是白拿的好处。它带来两个新麻烦一是负载均衡如果路由总把 token 塞给少数几个专家其他专家就饿死了训练效率反而下降二是路由稳定性RL 训练里策略一直在变路由分布也跟着抖容易让训练更不稳。MiMo-V2.6 在报告里对这两点都有针对性设计这也是判断一个 MoE 模型工程成熟度的关键。2.2 专家路由与 RL 训练稳定性的耦合我自己的经验是MoE 做 RL 最容易被忽视的坑就是路由和策略的耦合震荡。普通预训练里数据分布相对固定路由很快收敛到稳定模式。但 RL 里策略每更新一次产生的数据分布就变一次路由跟着变专家负载跟着变梯度也跟着变——三个变量互相影响很容易形成正反馈式的震荡。常见的应对思路有这么几类我列个表对比一下方便你判断 MiMo-V2.6 这类方案大概站在哪个位置方案做法优点代价路由冻结RL 阶段固定路由参数训练稳丧失适应性负载均衡损失加辅助 loss 约束专家使用通用、简单可能牺牲表达力路由噪声注入训练时给路由加扰动提升探索调参敏感分阶段解耦先训路由再训策略稳定流程复杂从工程实践看负载均衡损失 分阶段解耦是当前比较主流的组合MiMo-V2.6 大概率也在这条路线上做了加强。这里给一个可以直接参考的辅助损失写法思路伪代码具体系数要按你的规模调# MoE 负载均衡辅助损失示意 # router_logits: [num_tokens, num_experts] # expert_mask: [num_tokens, num_experts] 路由选择结果 tokens_per_expert expert_mask.float().sum(dim0) # 每个专家分到多少 token fraction_per_expert tokens_per_expert / num_tokens # 使用比例 router_prob softmax(router_logits, dim-1).mean(dim0) # 平均路由概率 # 让使用比例和路由概率尽量一致避免强者恒强 aux_loss num_experts * (fraction_per_expert * router_prob).sum() total_loss policy_loss 0.01 * aux_loss # 系数通常取 0.001~0.01注意辅助损失的系数是个很敏感的旋钮。调太大模型会为了公平牺牲专业性专家变得同质化调太小又压不住负载失衡。我的建议是从 0.001 起步观察专家使用熵再逐步微调。2.3 容量因子一个被低估的调参点MoE 里还有个参数叫容量因子capacity factor它决定每个专家最多能接收多少 token超出的会被丢弃或走残差。这个值设小了token 被丢信息损失设大了显存和计算浪费。在 RL 场景下因为序列长度波动大Agent 任务动辄几千 token容量因子的设置比预训练更棘手。我的实操建议是RL 阶段把容量因子适当调高宁可浪费一点算力也别丢 token。原因是 RL 的奖励信号本来就稀疏如果关键决策步的 token 被丢了梯度直接断掉训练会莫名其妙地不收敛而且这种问题极难排查——你看着 loss 曲线正常但模型就是学不会。这个坑我踩过排查了两天才定位到是容量因子太小导致长序列尾部 token 被丢。3. 强化学习规模化MiMo-V2.6 真正想啃的硬骨头3.1 为什么规模化是 RL 在大模型上的死穴强化学习不是新东西David Silver 那套经典理论早就成熟了。但把 RL 搬到千亿参数的大模型上问题完全变了味。经典 RL 假设环境轻量、采样便宜而大模型 RL 里一次 rollout 就是一次完整推理成本高得离谱。这就导致两个连锁反应样本效率必须极高否则算力扛不住训练必须极稳否则一次崩盘就浪费掉大量算力。MiMo-V2.6 把规模化写进标题说明它要解决的不是能不能跑 RL而是能不能把 RL 稳定地放大到有意义的规模。这里面涉及几个核心机制我逐个拆。第一个是采样效率。RL 的样本效率低本质是因为梯度估计方差大。降低方差的手段包括baseline 设计、优势函数估计、重要性采样修正等。在大模型场景下常用的做法是类似 PPO 的裁剪机制配合 GAE广义优势估计来平衡偏差和方差。这套东西在 MiMo-V2.6 这类系统里基本是标配区别在于工程实现的质量。第二个是奖励设计。Agentic RL 的奖励往往不是单一标量而是多维的任务是否完成、步骤是否高效、工具调用是否正确、输出是否合规。怎么把这些揉成一个稳定的训练信号是门手艺。常见做法是分项奖励加权求和但权重怎么定、要不要做归一化、稀疏奖励怎么补每个选择都影响成败。3.2 从 PPO 到更稳的策略优化几个关键取舍大模型 RL 目前主流还是 PPO 系但 PPO 在超大规模下也有它的问题对超参敏感、KL 约束难调、训练容易在后期崩。所以很多团队会在 PPO 基础上做改良。我把几个常见方向列出来方便你对照理解 MiMo-V2.6 可能的技术选择KL 惩罚 vs KL 约束惩罚是加在 loss 里约束是硬性截断。前者好调但可能约束不足后者稳但可能过度保守。优势估计的归一化batch 内归一化能稳训练但会引入 batch 间不一致长序列任务里要小心。裁剪范围PPO 的 clip 范围设小更稳但学得慢设大学得快但容易崩通常 0.1~0.2 之间。参考模型更新频率KL 参考模型是固定还是缓慢更新直接影响策略能走多远。这里有个我自己的经验KL 系数不要设成常数。训练初期策略离参考模型近KL 小可以放开学训练后期策略漂移大KL 涨得快这时候如果系数还是常数要么约束不住要么把模型压死。比较稳的做法是设一个目标 KL 值用自适应系数去追这个目标类似这样# 自适应 KL 系数示意 target_kl 0.01 kl_coef 0.1 kl compute_kl(policy_logprobs, ref_logprobs) if kl target_kl * 1.5: kl_coef * 1.5 # KL 超标加大惩罚 elif kl target_kl * 0.5: kl_coef * 0.7 # KL 太小放松约束 kl_coef clip(kl_coef, 0.01, 1.0)提示这个自适应逻辑看着简单但它能救回很多训练到一半突然崩的案例。我见过太多团队用固定 KL 系数前期学得好好的中期突然 reward 断崖式下跌八成就是 KL 失控。3.3 离线 RL 与在线 RL 的混合思路热词里出现了 IQLImplicit Q-Learning这类离线强化学习算法这其实点出了一个重要趋势纯在线 RL 太贵纯离线 RL 又学不到新东西混合才是出路。MiMo-V2.6 这类系统很可能采用了离线预热 在线精调的混合范式。离线阶段用已有的高质量轨迹数据训练一个初始策略让模型先学会基本操作避免在线阶段从零探索浪费算力。在线阶段再用实时 rollout 的数据做精细优化。这个思路的好处是离线数据提供了稳定的起点在线数据提供了持续改进的动力。IQL 这类算法的价值在于它能在不查询环境的情况下从离线数据里估计出较好的策略特别适合做预热。但混合范式有个坑离线数据和在线数据的分布不一致。如果离线数据太干净在线阶段遇到脏数据就容易崩如果离线数据太杂预热出来的策略又不够精。我的建议是离线数据要尽量贴近真实部署场景的分布宁可稍微脏一点也别用过度清洗的数据否则在线阶段会水土不服。4. Agentic RL当模型开始用工具做事4.1 Agentic 场景对 RL 提出了什么新要求Agentic RL 是这份报告的关键词之一也是当前最热的方向。传统 RL 里模型输出一个动作环境给一个反馈回合结束。但 Agent 场景复杂得多模型要调用工具、要读返回结果、要根据结果决定下一步、可能几十步才完成一个任务。这对 RL 提出了几个新要求。第一是长程信用分配。一个任务成功了到底是哪一步的功劳是第一步规划对了还是中间某次工具调用选对了这个功劳分配问题在长序列里极其困难。常见做法是用折扣因子往回传但折扣因子设小了早期步骤学不到设大了噪声又大。第二是稀疏奖励。很多 Agent 任务只有最终成功/失败信号中间没有反馈。这导致模型很难知道我差一点就成功了和我完全跑偏了的区别。解决办法通常是设计中间奖励比如步骤数惩罚、无效调用惩罚但中间奖励设计不好会引入偏见让模型学会刷奖励而不是真解决问题。第三是环境交互成本。Agent 要真的调工具、真的执行代码每次交互都有延迟和成本。这要求采样策略必须高效不能盲目探索。4.2 工具调用类任务的奖励设计实操我拿一个具体的工具调用场景来讲这样更直观。假设任务是查天气并给出穿衣建议模型需要调用天气 API、解析返回、生成建议。奖励怎么设计一个可用的分项奖励框架是这样的奖励项说明建议权重任务完成最终答案是否正确1.0工具调用正确性是否调了正确的工具、参数对不对0.3步骤效率是否用了过多无效步骤-0.1/步格式合规输出是否符合要求格式0.2幻觉惩罚是否编造了工具没返回的信息-0.5这套设计的关键在于负奖励要克制。我见过不少团队把惩罚设得很重结果模型变得极度保守宁可什么都不做也不愿冒险最后任务完成率反而下降。惩罚的作用是划边界不是吓唬模型。权重上正向奖励应该占主导负向奖励只用来纠正明显错误。还有个细节工具调用的参数正确性比调用本身更重要。模型很容易学会我要调工具这个动作但参数经常错。所以奖励设计里参数正确应该单独给分而不是和调用了工具混在一起。这样模型才能学到调对而不是调了就行。4.3 多轮交互中的策略漂移问题Agent 任务通常多轮交互这就带来一个隐蔽的问题策略漂移。模型在第 1 轮表现很好到第 5 轮、第 10 轮就开始跑偏忘记初始目标或者陷入重复循环。这在 RL 训练里表现为短序列任务学得很好长序列任务怎么都上不去。根因通常是上下文管理和信用分配的耦合。模型在长上下文里早期信息被稀释策略更新时又主要受近期步骤影响导致忘记初心。应对手段有几个一是在奖励里显式加入目标一致性检查二是用层次化策略高层管规划、低层管执行三是在训练数据里刻意增加长序列样本的比例。我自己的经验是长序列能力不能靠自然涌现必须刻意训练。如果你发现模型在 3 步以内任务上表现优秀但 10 步以上就崩别指望加大数据量能自动解决得从奖励设计和课程学习入手逐步拉长训练任务的步数。5. 自我改进闭环从训练一次到持续进化5.1 自我改进的三个层次自我改进这个词容易被神化我把它拆成三个可操作的层次你就明白 MiMo-V2.6 大概在哪个段位了。第一层自我采样。模型自己生成候选答案用奖励模型或规则筛选出好的再拿去训练。这是最基础的自我改进本质是自举bootstrapping。难点在于筛选标准要可靠否则会把错误当正确学进去。第二层自我评估。模型不仅生成答案还能评估自己答案的好坏。这要求模型具备一定的元认知能力。实现上通常训练一个 critic 模型或者让同一个模型扮演生成者和评估者两个角色。难点是评估的校准——模型容易高估自己。第三层自我修正。模型发现错误后能主动修正并把修正过程作为训练信号。这是最高层次也是最难的。它要求模型能定位错误、生成修正方案、验证修正效果形成一个完整闭环。MiMo-V2.6 作为开源模型大概率在第一层和第二层之间做了扎实的工程实现第三层可能还在探索。判断依据是第三层需要极强的推理和验证能力目前即便是顶尖闭源模型也做得不够稳。5.2 自举训练中的数据质量陷阱自我改进最诱人的地方是数据不用愁了模型自己产。但这里有个巨大的陷阱错误累积。如果模型某次生成错了筛选机制没拦住这个错误就被当成正确样本学进去下一轮模型更可能犯同样的错再被学进去……几轮之后模型就自信地错了。防这个坑核心是筛选机制的严格性。宁可少要数据也别要脏数据。具体做法包括多重验证规则 模型 人工抽检、置信度过滤只保留高置信样本、多样性约束避免同类错误反复出现。我见过一个团队为了快速扩数据把筛选阈值放得很松结果三轮自举之后模型能力不升反降回滚重来浪费了两周。还有个反直觉的点自举数据里要保留一定比例的失败样本。只学好样本模型学不会什么不该做。把失败样本配上负奖励反而能帮模型划清边界。这个思路在 RL 里叫对比学习效果往往比纯正样本训练更好。5.3 奖励模型会不会成为瓶颈自我改进闭环里奖励模型Reward Model是裁判裁判的水平决定了运动员的上限。如果奖励模型有偏见模型就会朝着偏见方向优化这就是著名的奖励黑客reward hacking。常见表现是模型学会了讨好奖励模型而不是真正解决问题。比如奖励模型偏好长回答模型就疯狂注水偏好特定格式模型就死抠格式不管内容。防这个坑手段有奖励模型集成多个 RM 投票、定期用人工数据校准 RM、在奖励里加入多样性惩罚。我的判断是奖励模型的质量会是 MiMo-V2.6 这类系统长期竞争力的关键。架构可以抄RL 算法可以复现但高质量的奖励信号是稀缺资源。谁能把奖励模型做得又准又稳谁就能在自我改进这条路上走得更远。6. 工程落地把论文变成能跑的训练系统6.1 训练框架与并行策略的选择聊完原理落到工程。大模型 RL 训练对框架的要求很特殊既要支持大规模并行推理rollout又要支持训练policy update还要在两者之间高效切换。目前主流的开源工具里训练侧常见的是 DeepSpeed、Megatron 这类推理侧有 vLLM、SGLang 这类。RL 框架则需要在两者之上做编排。选型时我建议关注几个点rollout 和 train 的权重同步开销、显存复用效率、对 MoE 的原生支持。MoE 模型的并行比稠密模型复杂专家并行Expert Parallelism和数据并行、张量并行怎么组合直接影响吞吐。如果框架对 MoE 支持不好你会花大量时间在通信优化上。并行策略上一个经验法则是推理阶段用专家并行 数据并行训练阶段用张量并行 流水并行。因为推理是 memory-bound训练是 compute-bound两者的最优并行方式不同。切换时的权重重排resharding开销要重点优化否则会成为瓶颈。6.2 显存与吞吐的平衡技巧RL 训练显存压力大因为同时要装策略模型、参考模型、奖励模型、优化器状态、rollout 的 KV cache。几个省显存的实操技巧参考模型和奖励模型用低精度它们只做前向用 FP8 甚至 INT8 量化精度损失可接受。KV cache 分页管理长序列 rollout 的 KV cache 是大头用 PagedAttention 这类技术能显著降显存。梯度检查点训练侧开 gradient checkpointing用时间换显存通常能省 30%~50%。offload 策略优化器状态 offload 到 CPU训练慢一点但能跑更大模型。吞吐方面rollout 的 batch 组织方式很关键。Agent 任务的序列长度差异大如果按最长序列 padding浪费严重。用变长序列 动态 batching能提升不少吞吐。这个优化看着小但在大规模训练里能省下可观的算力。6.3 训练监控哪些指标必须盯RL 训练不像监督学习loss 下降不代表变好。必须盯的指标我列一下指标正常表现异常信号平均奖励稳步上升后趋稳突然下跌或长期不动KL 散度在目标值附近波动持续飙升策略熵缓慢下降骤降过早收敛专家使用熵保持较高骤降负载失衡序列长度分布稳定异常增长注水裁剪比例10%~30%过高更新过猛注意策略熵骤降是最危险的信号之一意味着模型过早收敛到局部最优探索能力丧失。这时候要么加大熵奖励要么回滚到之前的 checkpoint。我见过太多训练看着正常但熵已经掉到接近零最后模型完全不会探索。7. 我踩过的坑和几条实在建议聊了这么多原理和工程最后分享几条我自己在 RL 训练里踩出来的经验都是文档里不会写的。第一条先跑通小规模再谈规模化。很多人一上来就想复现大模型 RL结果卡在环境配置、数据格式、奖励对齐这些琐事上。我的做法是先用一个 1B 以下的小模型把整条链路跑通确认奖励信号、训练稳定性、评估流程都没问题再往上放大。小规模跑通可能只要一天大规模踩坑可能浪费一周。第二条奖励函数要可解释。如果你的奖励函数复杂到自己也说不清每项在干嘛那训练出问题你根本没法排查。我习惯把奖励拆成几个独立可测的项每项单独记录这样一旦模型行为异常能快速定位是哪项奖励在作祟。第三条checkpoint 要勤存回滚要果断。RL 训练崩盘是常态不是意外。我一般每 N 步存一次一旦发现指标异常立刻回滚到最近的健康 checkpoint而不是试图救当前训练。救回来的概率很低浪费的时间却很多。第四条评估集要独立且贴近真实场景。训练用的奖励和评估用的指标必须分开否则你会陷入奖励涨了但实际能力没涨的幻觉。评估集要覆盖真实部署的各种边界情况别只用干净的测试数据。第五条别迷信单一算法。PPO、IQL、GRPO 这些算法各有适用场景没有银弹。MiMo-V2.6 这类系统能成功靠的不是某个神奇算法而是整套工程体系的扎实。算法是骨架工程是血肉缺一不可。最后说个我观察到的趋势开源大模型的竞争正在从预训练规模转向后训练质量。MiMo-V2.6 把强化学习规模化作为核心卖点说明这个转向已经发生。对做落地的人来说这意味着后训练和 RL 工程能力会比单纯堆算力更值钱。谁能把自我改进闭环跑稳谁就能用更少的算力做出更强的模型。这条路还很长但方向已经清楚了。 
长河君 · 2026/10/6 22:02:50 · 阅读 1.2k MiMo-V2.6 技术报告解读：强化学习规模化与自我改进的工程实践
1. 从能对话到会进化MiMo-V2.6 到底在解决什么问题大模型圈子这两年有个很明显的分水岭2023 年大家在比谁的模型能聊2024 年比谁的模型能干活到了 2025 年之后真正拉开差距的变成了——谁的模型能自己变强。MiMo-V2.6 这份技术报告最抓人的地方不是它又刷了多少榜单而是它把自我改进这件事从论文里的概念往工程可复现的方向推了一大步。关键词里那几个词——强化学习、MoE、Agentic RL——其实已经把这篇文章的骨架交代清楚了它是一套围绕强化学习规模化搭建起来的开源大模型训练体系。先说清楚它是什么。MiMo-V2.6 是一个开源大模型采用 MoEMixture of Experts混合专家架构核心卖点是在后训练阶段大规模引入强化学习并且把自我改进作为训练目标之一。它能做什么简单讲就是让模型在复杂任务里通过试错、反馈、再试错的方式逐步提升推理、工具调用、多步决策这类能力而不是单纯靠堆人类标注数据。适合谁看如果你在做模型后训练、Agent 系统、强化学习落地或者只是想知道开源模型现在到底走到哪一步了这篇都值得细读。我先把一个容易混淆的点讲透。很多人一听自我改进就联想到科幻片里的 AI 自己改自己代码其实不是。这里的自我改进指的是模型在强化学习循环里利用自己生成的数据、自己产生的反馈信号去优化下一轮策略。它依然需要奖励函数、需要环境、需要训练框架只不过数据来源从纯人工变成了模型自产为主。这个区别非常关键因为它决定了整套系统的工程重心——你不再主要纠结标注质量而是要纠结奖励信号设计、采样效率、训练稳定性这三件事。为什么这件事现在才被认真做因为强化学习在大模型上一直有个尴尬小规模能跑通一放大就崩。样本效率低、奖励稀疏、策略漂移、训练不稳定随便一个都能让几个星期的算力打水漂。MiMo-V2.6 的价值就在于它把规模化这三个字当成核心命题来解而不是当成一个附带说明。下面我会从架构、RL 机制、Agentic 场景、工程落地几个角度把它拆开讲中间穿插我自己踩过的坑和能直接抄的做法。2. MoE 架构为什么成了强化学习规模化的地基2.1 稀疏激活让大和快不再互斥MoE 的核心思想其实很朴素模型总参数量可以很大但每次前向只激活其中一小部分专家。打个比方一家公司有 200 个专家但每个项目只叫最相关的 8 个人来开会既保留了知识广度又控制了单次成本。MiMo-V2.6 走的就是这条路——总参数规模撑起容量激活参数控制住计算量。这件事对强化学习为什么重要因为 RL 训练最烧的不是单次前向而是海量的采样和反复的策略评估。一个 Agent 任务可能要 rollout 几十上百步每一步都要过模型。如果每步都激活全部参数成本会直接爆炸。MoE 的稀疏激活把单步成本压下来才让大规模 RL 采样在经济上成立。换句话说MoE 不是为了炫技它是 RL 规模化的成本前提。但 MoE 也不是白拿的好处。它带来两个新麻烦一是负载均衡如果路由总把 token 塞给少数几个专家其他专家就饿死了训练效率反而下降二是路由稳定性RL 训练里策略一直在变路由分布也跟着抖容易让训练更不稳。MiMo-V2.6 在报告里对这两点都有针对性设计这也是判断一个 MoE 模型工程成熟度的关键。2.2 专家路由与 RL 训练稳定性的耦合我自己的经验是MoE 做 RL 最容易被忽视的坑就是路由和策略的耦合震荡。普通预训练里数据分布相对固定路由很快收敛到稳定模式。但 RL 里策略每更新一次产生的数据分布就变一次路由跟着变专家负载跟着变梯度也跟着变——三个变量互相影响很容易形成正反馈式的震荡。常见的应对思路有这么几类我列个表对比一下方便你判断 MiMo-V2.6 这类方案大概站在哪个位置方案做法优点代价路由冻结RL 阶段固定路由参数训练稳丧失适应性负载均衡损失加辅助 loss 约束专家使用通用、简单可能牺牲表达力路由噪声注入训练时给路由加扰动提升探索调参敏感分阶段解耦先训路由再训策略稳定流程复杂从工程实践看负载均衡损失 分阶段解耦是当前比较主流的组合MiMo-V2.6 大概率也在这条路线上做了加强。这里给一个可以直接参考的辅助损失写法思路伪代码具体系数要按你的规模调# MoE 负载均衡辅助损失示意 # router_logits: [num_tokens, num_experts] # expert_mask: [num_tokens, num_experts] 路由选择结果 tokens_per_expert expert_mask.float().sum(dim0) # 每个专家分到多少 token fraction_per_expert tokens_per_expert / num_tokens # 使用比例 router_prob softmax(router_logits, dim-1).mean(dim0) # 平均路由概率 # 让使用比例和路由概率尽量一致避免强者恒强 aux_loss num_experts * (fraction_per_expert * router_prob).sum() total_loss policy_loss 0.01 * aux_loss # 系数通常取 0.001~0.01注意辅助损失的系数是个很敏感的旋钮。调太大模型会为了公平牺牲专业性专家变得同质化调太小又压不住负载失衡。我的建议是从 0.001 起步观察专家使用熵再逐步微调。2.3 容量因子一个被低估的调参点MoE 里还有个参数叫容量因子capacity factor它决定每个专家最多能接收多少 token超出的会被丢弃或走残差。这个值设小了token 被丢信息损失设大了显存和计算浪费。在 RL 场景下因为序列长度波动大Agent 任务动辄几千 token容量因子的设置比预训练更棘手。我的实操建议是RL 阶段把容量因子适当调高宁可浪费一点算力也别丢 token。原因是 RL 的奖励信号本来就稀疏如果关键决策步的 token 被丢了梯度直接断掉训练会莫名其妙地不收敛而且这种问题极难排查——你看着 loss 曲线正常但模型就是学不会。这个坑我踩过排查了两天才定位到是容量因子太小导致长序列尾部 token 被丢。3. 强化学习规模化MiMo-V2.6 真正想啃的硬骨头3.1 为什么规模化是 RL 在大模型上的死穴强化学习不是新东西David Silver 那套经典理论早就成熟了。但把 RL 搬到千亿参数的大模型上问题完全变了味。经典 RL 假设环境轻量、采样便宜而大模型 RL 里一次 rollout 就是一次完整推理成本高得离谱。这就导致两个连锁反应样本效率必须极高否则算力扛不住训练必须极稳否则一次崩盘就浪费掉大量算力。MiMo-V2.6 把规模化写进标题说明它要解决的不是能不能跑 RL而是能不能把 RL 稳定地放大到有意义的规模。这里面涉及几个核心机制我逐个拆。第一个是采样效率。RL 的样本效率低本质是因为梯度估计方差大。降低方差的手段包括baseline 设计、优势函数估计、重要性采样修正等。在大模型场景下常用的做法是类似 PPO 的裁剪机制配合 GAE广义优势估计来平衡偏差和方差。这套东西在 MiMo-V2.6 这类系统里基本是标配区别在于工程实现的质量。第二个是奖励设计。Agentic RL 的奖励往往不是单一标量而是多维的任务是否完成、步骤是否高效、工具调用是否正确、输出是否合规。怎么把这些揉成一个稳定的训练信号是门手艺。常见做法是分项奖励加权求和但权重怎么定、要不要做归一化、稀疏奖励怎么补每个选择都影响成败。3.2 从 PPO 到更稳的策略优化几个关键取舍大模型 RL 目前主流还是 PPO 系但 PPO 在超大规模下也有它的问题对超参敏感、KL 约束难调、训练容易在后期崩。所以很多团队会在 PPO 基础上做改良。我把几个常见方向列出来方便你对照理解 MiMo-V2.6 可能的技术选择KL 惩罚 vs KL 约束惩罚是加在 loss 里约束是硬性截断。前者好调但可能约束不足后者稳但可能过度保守。优势估计的归一化batch 内归一化能稳训练但会引入 batch 间不一致长序列任务里要小心。裁剪范围PPO 的 clip 范围设小更稳但学得慢设大学得快但容易崩通常 0.1~0.2 之间。参考模型更新频率KL 参考模型是固定还是缓慢更新直接影响策略能走多远。这里有个我自己的经验KL 系数不要设成常数。训练初期策略离参考模型近KL 小可以放开学训练后期策略漂移大KL 涨得快这时候如果系数还是常数要么约束不住要么把模型压死。比较稳的做法是设一个目标 KL 值用自适应系数去追这个目标类似这样# 自适应 KL 系数示意 target_kl 0.01 kl_coef 0.1 kl compute_kl(policy_logprobs, ref_logprobs) if kl target_kl * 1.5: kl_coef * 1.5 # KL 超标加大惩罚 elif kl target_kl * 0.5: kl_coef * 0.7 # KL 太小放松约束 kl_coef clip(kl_coef, 0.01, 1.0)提示这个自适应逻辑看着简单但它能救回很多训练到一半突然崩的案例。我见过太多团队用固定 KL 系数前期学得好好的中期突然 reward 断崖式下跌八成就是 KL 失控。3.3 离线 RL 与在线 RL 的混合思路热词里出现了 IQLImplicit Q-Learning这类离线强化学习算法这其实点出了一个重要趋势纯在线 RL 太贵纯离线 RL 又学不到新东西混合才是出路。MiMo-V2.6 这类系统很可能采用了离线预热 在线精调的混合范式。离线阶段用已有的高质量轨迹数据训练一个初始策略让模型先学会基本操作避免在线阶段从零探索浪费算力。在线阶段再用实时 rollout 的数据做精细优化。这个思路的好处是离线数据提供了稳定的起点在线数据提供了持续改进的动力。IQL 这类算法的价值在于它能在不查询环境的情况下从离线数据里估计出较好的策略特别适合做预热。但混合范式有个坑离线数据和在线数据的分布不一致。如果离线数据太干净在线阶段遇到脏数据就容易崩如果离线数据太杂预热出来的策略又不够精。我的建议是离线数据要尽量贴近真实部署场景的分布宁可稍微脏一点也别用过度清洗的数据否则在线阶段会水土不服。4. Agentic RL当模型开始用工具做事4.1 Agentic 场景对 RL 提出了什么新要求Agentic RL 是这份报告的关键词之一也是当前最热的方向。传统 RL 里模型输出一个动作环境给一个反馈回合结束。但 Agent 场景复杂得多模型要调用工具、要读返回结果、要根据结果决定下一步、可能几十步才完成一个任务。这对 RL 提出了几个新要求。第一是长程信用分配。一个任务成功了到底是哪一步的功劳是第一步规划对了还是中间某次工具调用选对了这个功劳分配问题在长序列里极其困难。常见做法是用折扣因子往回传但折扣因子设小了早期步骤学不到设大了噪声又大。第二是稀疏奖励。很多 Agent 任务只有最终成功/失败信号中间没有反馈。这导致模型很难知道我差一点就成功了和我完全跑偏了的区别。解决办法通常是设计中间奖励比如步骤数惩罚、无效调用惩罚但中间奖励设计不好会引入偏见让模型学会刷奖励而不是真解决问题。第三是环境交互成本。Agent 要真的调工具、真的执行代码每次交互都有延迟和成本。这要求采样策略必须高效不能盲目探索。4.2 工具调用类任务的奖励设计实操我拿一个具体的工具调用场景来讲这样更直观。假设任务是查天气并给出穿衣建议模型需要调用天气 API、解析返回、生成建议。奖励怎么设计一个可用的分项奖励框架是这样的奖励项说明建议权重任务完成最终答案是否正确1.0工具调用正确性是否调了正确的工具、参数对不对0.3步骤效率是否用了过多无效步骤-0.1/步格式合规输出是否符合要求格式0.2幻觉惩罚是否编造了工具没返回的信息-0.5这套设计的关键在于负奖励要克制。我见过不少团队把惩罚设得很重结果模型变得极度保守宁可什么都不做也不愿冒险最后任务完成率反而下降。惩罚的作用是划边界不是吓唬模型。权重上正向奖励应该占主导负向奖励只用来纠正明显错误。还有个细节工具调用的参数正确性比调用本身更重要。模型很容易学会我要调工具这个动作但参数经常错。所以奖励设计里参数正确应该单独给分而不是和调用了工具混在一起。这样模型才能学到调对而不是调了就行。4.3 多轮交互中的策略漂移问题Agent 任务通常多轮交互这就带来一个隐蔽的问题策略漂移。模型在第 1 轮表现很好到第 5 轮、第 10 轮就开始跑偏忘记初始目标或者陷入重复循环。这在 RL 训练里表现为短序列任务学得很好长序列任务怎么都上不去。根因通常是上下文管理和信用分配的耦合。模型在长上下文里早期信息被稀释策略更新时又主要受近期步骤影响导致忘记初心。应对手段有几个一是在奖励里显式加入目标一致性检查二是用层次化策略高层管规划、低层管执行三是在训练数据里刻意增加长序列样本的比例。我自己的经验是长序列能力不能靠自然涌现必须刻意训练。如果你发现模型在 3 步以内任务上表现优秀但 10 步以上就崩别指望加大数据量能自动解决得从奖励设计和课程学习入手逐步拉长训练任务的步数。5. 自我改进闭环从训练一次到持续进化5.1 自我改进的三个层次自我改进这个词容易被神化我把它拆成三个可操作的层次你就明白 MiMo-V2.6 大概在哪个段位了。第一层自我采样。模型自己生成候选答案用奖励模型或规则筛选出好的再拿去训练。这是最基础的自我改进本质是自举bootstrapping。难点在于筛选标准要可靠否则会把错误当正确学进去。第二层自我评估。模型不仅生成答案还能评估自己答案的好坏。这要求模型具备一定的元认知能力。实现上通常训练一个 critic 模型或者让同一个模型扮演生成者和评估者两个角色。难点是评估的校准——模型容易高估自己。第三层自我修正。模型发现错误后能主动修正并把修正过程作为训练信号。这是最高层次也是最难的。它要求模型能定位错误、生成修正方案、验证修正效果形成一个完整闭环。MiMo-V2.6 作为开源模型大概率在第一层和第二层之间做了扎实的工程实现第三层可能还在探索。判断依据是第三层需要极强的推理和验证能力目前即便是顶尖闭源模型也做得不够稳。5.2 自举训练中的数据质量陷阱自我改进最诱人的地方是数据不用愁了模型自己产。但这里有个巨大的陷阱错误累积。如果模型某次生成错了筛选机制没拦住这个错误就被当成正确样本学进去下一轮模型更可能犯同样的错再被学进去……几轮之后模型就自信地错了。防这个坑核心是筛选机制的严格性。宁可少要数据也别要脏数据。具体做法包括多重验证规则 模型 人工抽检、置信度过滤只保留高置信样本、多样性约束避免同类错误反复出现。我见过一个团队为了快速扩数据把筛选阈值放得很松结果三轮自举之后模型能力不升反降回滚重来浪费了两周。还有个反直觉的点自举数据里要保留一定比例的失败样本。只学好样本模型学不会什么不该做。把失败样本配上负奖励反而能帮模型划清边界。这个思路在 RL 里叫对比学习效果往往比纯正样本训练更好。5.3 奖励模型会不会成为瓶颈自我改进闭环里奖励模型Reward Model是裁判裁判的水平决定了运动员的上限。如果奖励模型有偏见模型就会朝着偏见方向优化这就是著名的奖励黑客reward hacking。常见表现是模型学会了讨好奖励模型而不是真正解决问题。比如奖励模型偏好长回答模型就疯狂注水偏好特定格式模型就死抠格式不管内容。防这个坑手段有奖励模型集成多个 RM 投票、定期用人工数据校准 RM、在奖励里加入多样性惩罚。我的判断是奖励模型的质量会是 MiMo-V2.6 这类系统长期竞争力的关键。架构可以抄RL 算法可以复现但高质量的奖励信号是稀缺资源。谁能把奖励模型做得又准又稳谁就能在自我改进这条路上走得更远。6. 工程落地把论文变成能跑的训练系统6.1 训练框架与并行策略的选择聊完原理落到工程。大模型 RL 训练对框架的要求很特殊既要支持大规模并行推理rollout又要支持训练policy update还要在两者之间高效切换。目前主流的开源工具里训练侧常见的是 DeepSpeed、Megatron 这类推理侧有 vLLM、SGLang 这类。RL 框架则需要在两者之上做编排。选型时我建议关注几个点rollout 和 train 的权重同步开销、显存复用效率、对 MoE 的原生支持。MoE 模型的并行比稠密模型复杂专家并行Expert Parallelism和数据并行、张量并行怎么组合直接影响吞吐。如果框架对 MoE 支持不好你会花大量时间在通信优化上。并行策略上一个经验法则是推理阶段用专家并行 数据并行训练阶段用张量并行 流水并行。因为推理是 memory-bound训练是 compute-bound两者的最优并行方式不同。切换时的权重重排resharding开销要重点优化否则会成为瓶颈。6.2 显存与吞吐的平衡技巧RL 训练显存压力大因为同时要装策略模型、参考模型、奖励模型、优化器状态、rollout 的 KV cache。几个省显存的实操技巧参考模型和奖励模型用低精度它们只做前向用 FP8 甚至 INT8 量化精度损失可接受。KV cache 分页管理长序列 rollout 的 KV cache 是大头用 PagedAttention 这类技术能显著降显存。梯度检查点训练侧开 gradient checkpointing用时间换显存通常能省 30%~50%。offload 策略优化器状态 offload 到 CPU训练慢一点但能跑更大模型。吞吐方面rollout 的 batch 组织方式很关键。Agent 任务的序列长度差异大如果按最长序列 padding浪费严重。用变长序列 动态 batching能提升不少吞吐。这个优化看着小但在大规模训练里能省下可观的算力。6.3 训练监控哪些指标必须盯RL 训练不像监督学习loss 下降不代表变好。必须盯的指标我列一下指标正常表现异常信号平均奖励稳步上升后趋稳突然下跌或长期不动KL 散度在目标值附近波动持续飙升策略熵缓慢下降骤降过早收敛专家使用熵保持较高骤降负载失衡序列长度分布稳定异常增长注水裁剪比例10%~30%过高更新过猛注意策略熵骤降是最危险的信号之一意味着模型过早收敛到局部最优探索能力丧失。这时候要么加大熵奖励要么回滚到之前的 checkpoint。我见过太多训练看着正常但熵已经掉到接近零最后模型完全不会探索。7. 我踩过的坑和几条实在建议聊了这么多原理和工程最后分享几条我自己在 RL 训练里踩出来的经验都是文档里不会写的。第一条先跑通小规模再谈规模化。很多人一上来就想复现大模型 RL结果卡在环境配置、数据格式、奖励对齐这些琐事上。我的做法是先用一个 1B 以下的小模型把整条链路跑通确认奖励信号、训练稳定性、评估流程都没问题再往上放大。小规模跑通可能只要一天大规模踩坑可能浪费一周。第二条奖励函数要可解释。如果你的奖励函数复杂到自己也说不清每项在干嘛那训练出问题你根本没法排查。我习惯把奖励拆成几个独立可测的项每项单独记录这样一旦模型行为异常能快速定位是哪项奖励在作祟。第三条checkpoint 要勤存回滚要果断。RL 训练崩盘是常态不是意外。我一般每 N 步存一次一旦发现指标异常立刻回滚到最近的健康 checkpoint而不是试图救当前训练。救回来的概率很低浪费的时间却很多。第四条评估集要独立且贴近真实场景。训练用的奖励和评估用的指标必须分开否则你会陷入奖励涨了但实际能力没涨的幻觉。评估集要覆盖真实部署的各种边界情况别只用干净的测试数据。第五条别迷信单一算法。PPO、IQL、GRPO 这些算法各有适用场景没有银弹。MiMo-V2.6 这类系统能成功靠的不是某个神奇算法而是整套工程体系的扎实。算法是骨架工程是血肉缺一不可。最后说个我观察到的趋势开源大模型的竞争正在从预训练规模转向后训练质量。MiMo-V2.6 把强化学习规模化作为核心卖点说明这个转向已经发生。对做落地的人来说这意味着后训练和 RL 工程能力会比单纯堆算力更值钱。谁能把自我改进闭环跑稳谁就能用更少的算力做出更强的模型。这条路还很长但方向已经清楚了。