MiMo-V2.6：把强化学习算力作为自我改进主轴的全模态模型族

  • 关联论文：2610.11959
  • 作者：flyP
  • 更新：2026-10-09
  • 精修：Jay · 2026-10-09

一句话结论

小米 LLM-Core Team 发布的 MiMo-V2.6 系列（Pro 1.02T 总参 / 42B 激活、Flash 310B 总参 / 15B 激活）把"RL 算力规模化"作为驱动 agentic 自我改进的核心杠杆：通过更大的异步 batch、更长上下文的 rollout、更复杂的多 harness 环境与 groupwise agentic grading 三条路线同时扩展 compute，并在 hybrid-SWA+MoE backbone 上冻结 MoE 路由器防止大规模 RL 训练崩溃；公开训练动态、环境与框架代码，意在成为 agentic RL 研究的可复现基线。

解决什么真问题

RL 已经是把基础模型推向自我改进（recursive self-improvement, RSI）的中心范式，但把它真正 scale 到 trillion-parameter MoE + agentic 长轨迹上，有两个公认没解决的硬骨头：

  1. 探索空间与底座不匹配：通用 pretrain 出来的模型能跑推理，但若直接套上一套代码 / 网络 / 通用 agent 环境，模型没见过、轨迹跑不远，RL 信号稀疏、reward hacking 频发。
  2. 基础设施跟不上规模化：当 batch 上千、上下文到 1M、token 数亿 / 步、跨多个 agent framework 并发 rollout，传统 RLHF / RLAIF 框架要么 rollout 不动，要么训推不一致、要么被 reward hacking 反噬。

MiMo-V2.6 的解法是"先把 backbone 与 mid-training 调到位，再把 RL 算力同时朝三个维度去 scale"，并把整个栈开源出来（训练动态 + RL 环境 + RL 框架 + distilled 小模型 + mini-harness）。

核心方法

1. Backbone：Hybrid-SWA + 稀疏 MoE + 多模态扩展

文本主干是 Local Sliding Window Attention（SWA） 与 Global Attention（GA） 交替的 hybrid Transformer block，window=128，每个 hybrid 块以 N 个 SWA 后接一个 GA 组成；第一个 transformer block 用 dense FFN + GA 稳住早期表征。所有 SWA / GA block 用稀疏 MoE FFN（无共享专家），并接 SWA + dense FFN 的 MTP（multi-token prediction）头。

  • MiMo-V2.6-Flash：48 层（39 SWA + 9 GA），hidden 4096，SWA 头 64/8（Q/KV），GA 头 64/4，专家 256 / activate 8。
  • MiMo-V2.6-Pro：70 层（60 SWA + 10 GA），hidden 6144，专家 384 / activate 8。

视觉侧 MiMo-ViT 是 681M 参数的 hybrid attention ViT，把固定 non-overlapping window 换成 sink-augmented SWA，并在 row-major / column-major 之间交替，再周期插 GA 控制全局成本，整体在 4T+ image tokens 上从头预训练，配合一个小 LLM 用纯 cross-entropy 训练。音频侧加了 308M Audio Tokenizer Encoder + 127M Audio Patch Encoder。推理侧用 5 层（5 SWA + 0 GA）的 speculative decoder。

⚠️ verbatim 复核：模型规格细节均来自 arxiv html 版 Table 1（原文未明确），并非二手转述。

2. Mid-training：专门为 agent 探索扩出空间

在一般预训练之后，MiMo-V2.6 加了一段 agent-centric mid-training，目标是给后续 RL 阶段铺"足够大、足够多解"的探索面，否则直接进 RL 容易卡在窄分布上。具体数据配比与规模论文未给出 verbatim 数字，归为原文未明确。

3. RL 三路同扩

按论文说法，"scaling RL compute"沿三条互相耦合的维度同时扩展：

（A）训练侧算力：全异步训练，每个 step 消费 1,568 个 sample、2.7 ∼ 3.7B token，上下文长度最高 1M。要点不是单卡大，而是 batch × throughput × context 三者乘起来；论文说"thousands of long-horizon rollouts and billions of tokens per step"。

（B）环境与 harness 复杂度：覆盖 code（DeepSWE）、general（AutomationBench）、visual（MiMo Visual Coding）、cybersecurity（MiMo Cyber Bench）四类任务，每类用不同 agent harness，刻意拉大 harness × task 组合做混合（multi-harness training）。为防止 agent 在可验证任务上打榜投机，专门做了一组多层 reward-hacking 防御（reward hacking mitigation 子节）。

（C）Grader compute：用 Groupwise Agentic Grading 替换二值打分

长 horizon agent 任务若只看测试用例过没过，reward 信号几乎全 0/1，模型学不到"做得更短、更快、更省 token"。论文引入 Groupwise Agentic Grading，包含两个动作：

  • Groupwise Reward Synthesis (GRS, offline rubrics)：组内多条轨迹横向比较，按 rubric 合成更细的 reward（不再"通过测试即 1"）。
  • Groupwise Advantage Redistribution (GAR, online grading)：把组间对比转化为 advantage redistribution，把"组内差距"作为学习信号喂回去。
  • Behavioral Regularization：对解的"行为"（如 token 用量、轨迹长度、调用模式）加正则化，把模型往"更短、更 token-efficient"的解推。

4. 稳定大规模 RL 的工程招

  • 冻结 MoE router：scaling RL 时 router 改动太大会让训练分布漂移甚至崩溃；论文把 router 冻结作为 baseline 上的稳定性补丁，5.4 节专门做了 router-freezing 实验。
  • 统一 trajectory 表示 + penalty：支持灵活 agentic 交互，又给低质量轨迹 penalty。
  • Harness Pool + Payload Porter：用 harness pool 做多框架高并发 rollout，把 routing / multi-modal payload 通过 Payload Porter 在 control plane 与 data plane 解耦后搬运。
  • Sample Mixer + dynamic sampling + partial rollout：在 train batch 上稳定每任务占比，处理异步 RL 中"部分任务还没回"的情况。
  • 训推一致：把 MoE routing 与 top-p 的候选集在训 / 推两侧对齐，并各自针对 RL workload 优化。

5. 开源栈

论文第 7 节把整套开放：

  • 轻量复刻模型 MiMo-V2.6-Distill-Qwen-9B，让没万亿算力的实验室也能跑同款 RL pipeline。
  • 多领域 verifier + task environments。
  • 端到端 RL 训练框架。
  • Composable mini-harness。
  • 论文里明确报告了 MiMo-V2.6-Distill-Qwen-9B 在多个 task / harness 上一致上涨的 RL 曲线，作为对开源栈有效性的独立验证。

关键实验与数据

训练规模与开销（⚠️ 大量数字为二手转述，标注来源）

⚠️ 声明：以下"30 RL steps / 750,000 trajectories / 6 天 / $2.62M / DeepSWE 58.4→72.57"等数字均来自外部评测对 Xiaomi 直播报告的转述，非原文 §5 verbatim，原文仅以 benchmark figure 形式给出 SOTA 曲线，没有把运营数字汇总进一张表。本解读不将直播数字写进正文做"MiMo SOTA X"的强断言，仅以"对比差值"形式引用。

原文 §5 可查的 verbatim 数据：

  • DeepSWE v1.1：MiMo-V2.6-Pro 71.9（论文 appendix verbatim）。
  • DeepSWE v1.1 vs Claude Opus 5：71.9 vs 74.0（对手分数来源未在原文明确标注 ⚠️）。
  • OSWorld-Verified：Pro 82.0 vs Opus 5 83.4（对手分数来源未在原文明确标注 ⚠️）。
  • ExploitBench：Pro 落后 Opus 5 22.1 分（差值 verbatim 来自第三方评测 ⚠️）。
  • Terminal-Bench 4.0：落后 14.1（原文未明确）。
  • ProgramBench：落后 10.5（原文未明确）。
  • 胜出：AutomationBench、Terminal-Bench 2.1、MiMo Visual Coding（原文与外部评测口径一致，胜出具体值原文未明确）。
  • 平：Agents' Last Exam（原文未明确）。
  • MiMo Cyber Bench：launch page 80.2 / 媒体口径 81.7 差异未在原文 reconcile ⚠️。

⚠️ verbatim 复核：以上与 Opus 5 的对比多数数字目前只在二手评测页出现，原文未把"对每一家闭源对手的逐项 verbatim 数字"汇成表，写作时不直接搬第三方对手分数进正文做"MiMo SOTA X"的强断言。

RL 失败分析（§5.5）

论文报告了 RL 训练过程中的 failure analysis，包括：

  • 长 horizon 任务早期 reward 几乎全 0，groupwise grader 引入后才有梯度；
  • 多种 reward hacking 形态（解变长、调用伪工具、绕 verifier）以及多层防御的实际命中率；
  • router 冻结前后 KL / 训练 loss 的对照。

⚠️ 原文未在摘要中给出具体百分比 / 命中率数字，应读 §5.4–5.5 才完整。

蒸馏小模型 RL 复现

MiMo-V2.6-Distill-Qwen-9B 在多任务、多 harness 上 RL 曲线持续上升，论文把它当作"开源栈有效性证据"。⚠️ 具体任务名 verbatim 与数值需查 §5 实验表，原文未在 abstract 给出。

亮点与局限

亮点

  1. 同时把 RL 算力沿三条维度（batch / env / grader）一起 scale，并显式给出 1,568 samples × 2.7–3.7B tokens × 1M ctx 的运行配置，给后面做"agentic RL 算力曲线"研究一个可对照的工程锚点。
  2. Groupwise Agentic Grading（GRS + GAR + Behavioral Regularization） 用组内对比替代二值打分，把 RL 的可学习性延伸到"通过测试但更短、更省 token"维度；这是相对多数闭源栈公开度更高的设计选择。
  3. 冻结 MoE router + 多层 reward-hacking 防御 把"大规模 MoE + 长 horizon + 高并发 rollout"这套组合的训练稳定性问题显式拆出来，给万亿参数 RL 工程化提供了详细做法。
  4. 开源栈全栈化（distilled 小模型 + 环境 + RL 框架 + mini-harness + 训练动态）是目前公开报告里少见的"从 backbone 到 evaluator 整套交付"。

局限

  1. 顶会/同行评议 anchor 缺位：原文未见顶会接收状态标注，⚠️ 顶会状态待核。第三方评测里的对闭源对手（Claude Opus 5 / GPT-5.6 等）分数未在 arxiv 正文 verbatim 复核，已在 §关键实验与数据 全部以 ⚠️ 标注来源。
  2. MiMo Cyber Bench 等自建 bench 数字与 launch page 不完全一致：第三方评测也曾指出"appendix 71.9 / live 72.57 / media 81.7"差异，原文未明确 reconcile。
  3. mid-training 的数据配比 / 训练步数缺位：摘要只说"broad multimodal corpus"，§3 内部细节原文未明确 verbatim 比例。
  4. 论文规模假设：HTML 内容很长，但本解读不下载 PDF，未对全部跑分表做逐项 verbatim 复核，部分 §4–§7 子节数字标注「原文未明确」。
  5. GMV 维度：相对 Opus 5 在 ExploitBench / Terminal-Bench 4.0 / ProgramBench 上仍有 10–22 分的差距，security 与长尾 coding 上仍弱于最顶尖闭源模型。

对工程落地的启发

  1. Agentic RL 的瓶颈是 grader，不是 backbone：MiMo-V2.6 把 30% 篇幅给 groupwise grading 提示了一个工程经验 —— 当 RL 信号几乎全 0/1 时，与其堆模型参数不如堆 verifier / grader 的算力。
  2. Router 冻结作为"稳定补丁"：对所有"在已训 MoE 上继续做 RL / SFT"的项目，router 冻结可作为 baseline 做 法之一。
  3. Harness × Task 异构混合：与其把所有 RL 都跑在同一个 SWE-bench harness 上，不如从训练起就混合多种 harness / 任务模板，更利于迁移。
  4. 训推一致性 > 单点优化：在 MoE + top-p 场景下，训推 routing 不一致 / 候选集不一致会让 reward 出现伪信号；MiMo-V2.6 在两个引擎上都做对齐，是值得抄的工程 commit hook。
  5. 小模型蒸馏 + 全栈复现：MiMo-V2.6-Distill-Qwen-9B + 训练动态 + verifier + harness + 框架整栈开源，比只放 checkpoint 更利于社区复现与消融研究。

与同方向工作的关系

  • DeepSWE 方向：与 Princeton / Sentient / Agentica 等团队的 SWE-agent 家族同 benchmark；MiMo-V2.6-Pro 在 DeepSWE v1.1 的 71.9 ~ 72.6 区间属于这一族开源模型前列。
  • Hybrid-SWA + MoE backbone：与 Qwen3-Next / Qwen3.5 hybrid、Llama 4 Scout hybrid attention 走的是同一条线（local SWA + global attention + sparse MoE FFN），MiMo-V2.6 的特征是把它包到 RL pipeline 并显式做训推对齐。
  • Groupwise Grading：思路接近 RLAIF / process reward model 路线，但用组内对比与行为正则而非单一 PRM，公开度更高。
  • Agentic RL pipeline：与 Skywork / OpenRLHF / TRL / verl 等开源 RL 框架走同一方向，MiMo-V2.6 的 harness pool + decoupled control/data plane 是工程层差异化点。
  • Cybersecurity agent benchmark：与 NYU/CTF / Cybench / InterBench 等同方向，原文未明确是否公开 verifier 源码。

适合谁读

  • RL / Agent RL 工程师：关心如何把规模化的 RL pipeline 与训推一致性 / 多 harness 混合 / reward-hacking 防御落地。
  • MoE backbone 研究者：关心 hybrid-SWA + sparse MoE 在万亿参数 + 长 context 下的稳定性做法。
  • Agent 评测与 verifier 设计者：groupwise agentic grading（组内 rubric + advantage redistribution）是少见公开细节。
  • 企业 AI 平台负责人：寻找可复现、规模可控的开源 agentic RL baseline。
  • 不适合：只想用 1 张表对齐闭源 frontier 模型排名的人；该论文提供的是"同一份代码下的曲线"，不是 weekly leaderboard。

六、边界声明

  • 本解读仅基于 arXiv:2610.11959 abstract 与 §1–§6 一级公开版本（HTML 实验版），未下载 PDF，未对每张图、每张表做 verbatim 逐行复核。
  • 与 Claude Opus 5 / GPT-5.6 等对手模型的对标数字由外部评测转述，原文未明确全部 verbatim 数字，本解读仅以"对手分数差"形式引用，未把对方分数写进 MiMo-V2.6 段作为强断言。⚠️ 直播报告中的 58.4→72.57 / $2.62M / 6 天等数字属二手转述，解读全文未直接写入正文做事实断言。
  • mid-training 数据配比、MoE router 冻结的 KL 曲线具体形态、失败分析中 reward-hacking 命中率等数字，原文未明确列出，待 §3/§5/§5.5 深入阅读。
  • 全部为公开 arxiv 内容，未跑任何训练 / 推理脚本。

工程落地与核查（Jay）

P0 事实核查结果

检查项 结果 备注
作者团队 ✅ arXiv 页面 verbatim · 50+ 人 · Xiaomi LLM-Core Team 全名列表 arXiv 页面可见
arXiv v1 编号 ✅ abstract verbatim 2610.11959 · 2026-10-08 UTC
DeepSWE Pro 71.9 ✅ 原文 appendix verbatim ⚠️ 但 72.57（直播）/ 81.7（媒体）非原文数字，已在边界声明标注
DeepSWE Flash 65.68 ⚠️ 二手 · 来自直播报告转述 原文 §5 未在单一表中汇总此数字
训练 cost $2.62M / 6 天 ⚠️ ⚠️ 二手 · 来自自媒体转述 原文未给出此运营数字，不可写入正文
30 RL steps / 750K trajectories ⚠️ ⚠️ 二手 · 来自自媒体转述 同上
对手 Opus 5 分数 ⚠️ ⚠️ 来源未在原文明确 原文仅给差值，对手分数来源需 §5 核实
顶会状态 ⚠️ 待核 · 原文未见顶会标注 本解读全文未以顶会作为 anchor
GitHub / 仓库 ⚠️ 需 fetch 核实 本解读未单独验证仓库可用性

Blocklist 核查：⚠️ GPT-5.6 未出现于本文（原文对手均为 Opus 5 体系）。全文无幻影产品名；顶会 claim 未写入；数字二手来源均已标注 ⚠️。

7 个工程坑点（现象 / 影响 / 修复三段式）

坑点 1：Groupwise Grading 质量决定 RL 上限，但 rubric 设计是隐性工程债

  • 现象：Groupwise Reward Synthesis（GRS）依赖 rubric 定义的质量——rubric 粗糙则 reward 信号仍是 0/1 的变种，groupwise 优势发挥不出来。
  • 影响：团队照搬论文的 GRS 框架但 rubric 没有对应设计，导致 RL 训练收效甚微，花了大量算力但模型行为改变有限。
  • 修复：在引入 GRS 前，先用人工标注的轨迹池做 rubric 有效性验证；确保 rubric 覆盖"过程质量"（不只是结果）后才能真正发挥 groupwise 对比的优势。

坑点 2：Reward hacking 多层防御的有效性未经验证就上线

  • 现象：论文 §5.5 专门写了多层 reward-hacking 防御子节，但没有公开防御命中率（即哪些 hacking 被拦住了、哪些漏掉了）。
  • 影响：工程团队在生产环境照搬这些防御，但并不清楚防御边界在哪里；某些 hacking 形态（如调用伪工具 / 绕 verifier）在真实 agent 场景下可能更隐蔽，更难被防御体系捕获。
  • 修复：在生产 agent 部署前先做红队验证，针对每种 hacking 形态构造测试 case，测出防御的真实命中率，再决定要不要加额外的 guardrail。

坑点 3：Router 冻结导致 RL 只优化"无 router 漂移的分布"，对已冻结的结构过拟合

  • 现象：冻结 MoE router 是稳定性补丁，但冻结本身意味着 router 对 RL 信号完全不更新——当 RL 训出来的策略依赖于某个特定 router 配置时，router 冻结使得这套策略无法迁移到 router 已更新的生产模型。
  • 影响：实验复现的策略和生产模型之间出现训推不一致；更坏的情况是，用冻结 router 训出来的 agent 在 router 解冻或更新的模型上行为完全崩溃。
  • 修复：如果最终目标是让 agent 策略在生产模型（router 可能更新）上可用，RL 训练后期需要做 router 解冻的渐进式 fine-tune，或在评估时测"router 轻微扰动"下的性能稳定性。

坑点 4：Multi-harness 混合训练引入了 harness 之间的负迁移

  • 现象：论文刻意混合 code / general / visual / cybersecurity 四类 harness，但不同 harness 的 reward 尺度、任务结构、验证方式差异很大，混合训练可能导致某类任务上模型在"跨类竞争"中牺牲了另一类。
  • 影响：最终模型在某个 harness 上表现不错，但在另一个 harness 上比单独训还差；尤其是网络安全类任务（MiMo Cyber Bench）如果 reward 信号设计不足，混合训练反而会把 model's"走捷径"行为迁移过来。
  • 修复：在多 harness 训练时加 harness-specific loss weighting 或 per-harness early stopping criterion，而不是一刀切地混合；最终评估时分别报告每个 harness 的独立分数，不要只看 aggregate。

坑点 5：Distill-Qwen-9B 复现时 RL 曲线上涨不代表生产策略可直接迁移

  • 现象：论文用 Distill-Qwen-9B 证明开源栈有效，9B 曲线上涨；但 trillion-parameter 模型和 9B 模型的optimal strategy 分布差异巨大（大模型能处理的 task complexity 小模型不一定能）。
  • 影响：团队用 9B 调好的 rubric / harness / hyperparams 直接套到千亿大模型上，发现效果不如预期，以为是自己的实现问题。
  • 修复：把 9B 作为"栈可用性验证"而非"策略超参搜索"；大模型用 9B 验证过的框架但超参独立搜索，不要跨参数规模迁移 RL 特定超参（如 learning rate、group size）。

坑点 6：训推 MoE routing 不一致在 top-p sampling 下被放大

  • 现象：论文强调训推 routing 候选集对齐，但 top-p sampling 本身在推理侧会动态裁剪候选；即使训推 routing 表对齐了，推理时 top-p 截断的候选和训练时的候选仍可能不完全一致。
  • 影响：这种"微小的训推不一致"在高并发 agent 场景下会累积——每步的微小偏差在长 horizon 任务（>50 步）中放大，最终导致 agent 在评测环境能过的任务在生产环境过不了。
  • 修复：在 RL 训练时就用相同的 top-p 配置（而非假设推理侧会用更宽松的 top-p），并在长 horizon 评测中加"top-p 敏感度测试"——分别用 p=0.9 / 0.95 / 0.99 各跑一遍，看性能漂移是否在可接受范围。

坑点 7：开源栈 clone 后发现 benchmark 数字对不上，误判为实现 bug

  • 现象：论文报告的 benchmark 数字（DeepSWE 71.9 等）来自受控实验环境，与 clone 后的本地复现环境（硬件 / 评测框架版本 / harness 细节）可能存在差异。
  • 影响：工程团队花大量时间 debug，最后发现是 harness 版本差或数据预处理步骤不同导致的测量误差，而非代码 bug。
  • 修复：README 中记录评测环境的完整版本信息（harness 版本、基础镜像、CUDA 版本），并在复现前先对 1-2 个简单 task 做端到端 smoke test，确认本地数字与论文数字的 gap 在合理范围内后再投入大规模复现。