← 所有文章
MiMo-V2 · Notes

MiMo-V2 全解:一台精巧的「追赶机器」

把小米 MiMo-V2 系列(Flash / Pro / 2.5-Pro)的技术报告、发布博客和罗福莉 3.5 小时访谈串成一条线:架构怎么选、训练怎么 scaling、数据和 RL 系统怎么搭,最后落到一个判断——它是一台把已知方法高效组装起来的「追赶机器」,强在工程整合与蒸馏,弱在原创算法与生态闭环。

2026 年 6 月 MiMoMoEHybridAttentionMTPMOPDAgenticRL

目录


    0一句话

    MiMo-V2 用一套「为长上下文效率而生」的稀疏架构(Hybrid Attention + MTP)压低成本,用蒸馏(MOPD)压低后训练时间,在 Agent / Coding 上高效追平 Claude;但它的原创性集中在蒸馏,RL 系统多为已知组件的集成。

    下面按「架构 → 训练 → 数据 → 2.5-Pro → 访谈 → 评价」走一遍,数字均来自 MiMo-V2-Flash 技术报告(arXiv:2601.02780)、小米发布博客与张小珺对罗福莉的访谈。


    1Flash 与 Pro:同源双子

    一个容易被误解的点:Flash 不是先于 Pro 的「热身」,两者是同期训练、架构几乎相同的双子。罗福莉在访谈里说得很直接——大部分训练在 2025 下半年完成,Flash 是相对小的活,训好就发了(2025-12-16);Pro 因为是 1T 级别,训练数值不稳定问题多得多,所以训得更久

    几个反直觉的细节:


    2架构:Hybrid Attention 与参数

    2.1 一张参数表

    FlashPro2.5-Pro
    总参 / 激活309B / 15B>1T / 42B1.02T / 42B
    SWA : GA 比例5 : 17 : 16 : 1
    滑窗大小128128128
    上下文256K1M1M
    专家(总/激活)256 / 8,无共享专家
    开放性开源 (MIT)API-only开源

    Flash 共 48 层 = 39 层 SWA + 9 层 GA,只有第一层用「GA + dense FFN」稳定早期表示,其余都挂稀疏 MoE。SWA / GA 都用 GQA。

    2.2 为什么敢这么稀疏

    128-token 的滑窗加 5:1 比例是相当激进的——长上下文按理会掉点。它能成立靠两件事:

    罗在访谈里补了一条更通用的判断:「Full Attention 的层数比系数比更重要」——更大的模型只要保住 GA 总层数不变、多堆 SWA 层,就能在更大规模上用更高的稀疏比。这也解释了 Pro 为什么敢上 7:1:更大的架构 GA 层数本来就多,拉高稀疏比可以让长文效率和 Flash 持平,而把省下的预算用来 scaling 智能。

    大模型能吃更稀疏,小模型太稀疏会崩。所以这套比例不是固定标准,是随规模变的实验结论。


    3MTP:省 KV、加速,以及为什么不选 MLA

    MTP(Multi-Token Prediction)块刻意做得很轻:用 dense FFN 而非 MoE,用 SWA 而非 GA,每块只有 0.33B。预训练挂一层(提升基座),后训练复制成 K 层,推理时当 draft model 做自投机解码。

    真正值得记的是为什么不选当时主流的 MLA(DeepSeek、Kimi、GLM 都在用)。罗的解释很关键:

    MLA 在设计之初就把访存与计算的比例做到了完美临界点——这意味着它没有富余空间。你想再上 MTP 加速,会立刻卡在计算 bound 上,不划算。所以那些 MLA 模型基本都没上 MTP,也就更慢。

    MiMo 反着来:Hybrid Attention 的 SWA 层省下大量算力,推理时计算严重「剩余」,正好拿 MTP 把这块剩余吃掉,达到访存与计算的再平衡。换句话说,MTP 不是孤立选择,是 Hybrid 架构留出富余后的自然延伸。MLA 的前提(后训练不重要、推理卡固定)在 Agent 时代失效了,而简洁架构留的富余度,恰好给后训练和不同场景适配腾了空间。

    Hybrid Attention 块(5 层 SWA + 1 层 GA)配合 MTP draft 的结构示意
    5 层 128 窗口的滑窗注意力配 1 层全局注意力,省下约 6× 的 KV-cache;省出的算力用 MTP 当 draft model 投机解码——这正是 MiMo 不选 MLA 的逻辑。

    4训练流程:从预训练到 MOPD

    4.1 预训练(27T tokens,FP8)

    Stage 1  0–22T   通用语料,32K 上下文,打基础
    Stage 2  22–26T  上采样代码 + 约 5% 合成推理数据
    Stage 3  26–27T  上下文扩到 256K,上采样长程依赖数据

    FP8 混合精度(attention 输出投影、embedding、输出头保 BF16,MoE router 保 FP32)。

    4.2 后训练:MOPD 三阶段

    MOPD(Multi-Teacher On-Policy Distillation)是这套报告的核心创新,目标是解决「跷跷板」(提升一个能力掉另一个)和「学习低效」:

    1. SFT:打基础指令能力。
    2. 领域专家训练:用独立 RL 分别训 coding / search / tool-use / 数学 / 推理 / 安全等 teacher,每个 teacher 在自己域内做到最强。
    3. MOPD:把多 teacher 融合建模成 on-policy RL——学生从自己分布采样,teacher 通过 reverse-KL 的 token-level reward 给监督,再叠加可验证的 outcome reward(GRPO 风格 ORM)。

    报告里 IcePop 式的训推重要性采样、丢弃训推差异过大的 token,都用在这里。

    MOPD 三阶段:SFT、领域专家 RL、多教师 on-policy 蒸馏
    MOPD 把多个领域 teacher 的能力,通过 token 级 KL reward 蒸给一个学生,再叠加可验证的 outcome reward。能力上界约等于最强 teacher。

    4.3 RL 系统:一张「借了谁」的溯源表

    底座是 SGLang(推理)+ Megatron-LM(训练),训推都 FP8。上面三个扩展模块解决三个具体问题。但把它们逐一拆开看,会发现真正自研的不多

    组件解决什么来源
    R3(Rollout Routing Replay)MoE 训推路由不一致:训练复用 rollout 选中的专家自研 / ma2025
    request-level prefix cache多轮 agent 复用上轮 KV+路由,不用 radix cache 以保路由一致自研
    Data Scheduler序列级调度、按 pass rate 动态采样,解决 GPU 空闲扩展自家 Seamless Rollout Engine
    partial rollout + staleness 截断 IS切分超长轨迹、限制陈旧度Kimi / AReaL
    训推重要性采样丢弃训推差异大的 tokenIcePop
    QK-Clip压住过大的 attention logits 稳训练Kimi
    Toolbox + Tool Manager工具资源 quota/QPS、环境预热、序列级异步 reward自研(基于 Ray)
    ORM advantage可验证 outcome rewardGRPO / DeepSeek

    结论先放这里:MiMo 的 RL 侧是「已知组件的高质量集成」,唯一算法级原创是 MOPD(蒸馏),不是 RL 调度本身。这一点在第 8 节会展开。


    5数据:来源与造法

    Agent 数据沿两个维度 scale:环境多样性算力。四类环境,真实来源做骨架、合成做规模化,reward 全靠可验证信号。

    类型来源 / 造法Reward / Verifier
    Code Agent90K 真实 + 30K 合成 prompt真实 GitHub issues;repo 快照自动建容器环境(8 语言 70% 成功率、1 万+ k8s pod);scaffold 只给 bash / str_replace / finish 三个原子工具,不预设 workflow可验证单元测试
    Terminal Agent~30KStack Overflow / Exchange → 生成 query + Dockerfile + test case,按安装成功率/难度/pass rate 过滤执行 + 测试
    Web Dev Agent真实人写网页 → Playwright 渲染视频 → 多模态判别器筛选;逆向出 query,覆盖 8 类vision verifier 对视频打分(视觉 + 功能 + 可执行)
    Search Agentscaffold(search/open/find);query 由种子实体递归扩展 fact-graph,难度随关系链深度上升可验证答案
    Function-calling合成应用环境,工具集来自 tool-call graph(显式数据依赖 + 隐式逻辑依赖)状态/数据传播校验

    非 agentic 的 reward:可验证域用「程序化工具 + LLM judge」双重;主观维度(helpfulness / safety)用 rubric-based LLM judge 按详细评分表打分。

    两个附录里的工程细节值得记:


    6MiMo-V2.5-Pro(2026-04-27)

    旗舰版第一次开源(permissive license)。1.02T / 42B,Hybrid 6:1,1M 上下文,FP8(E4M3) 混合精度,架构与训练完全沿用 Flash 那套(27T 预训练 + MOPD 三阶段)。

    主打不是榜分,而是长程任务的连贯性——给它人类要几天的活让它自主跑:

    任务结果
    Rust 写 SysY 编译器(北大课设,全流程)672 次工具调用 / 4.3 小时 / 隐藏测试 233/233
    全功能视频编辑器1868 次工具调用 / 11.5 小时 / 8192 行代码
    模拟 EDA(FVF-LDO,TSMC 180nm)接 ngspice + Claude Code 当 harness,约 1 小时,6 指标全达标

    官方提了个新词 harness awareness:模型会主动利用环境能力、管理自己的 memory、塑造 context。Token 效率上,ClawEval 64% Pass³ 每条轨迹只用约 70K tokens,比 Opus 4.6 / Gemini 3.1 Pro / GPT-5.4 少 40–60%。

    注意一个细节:那几个惊艳 demo 都是拿 Claude Code 当 harness 跑的——一部分功劳属于框架,不全是模型。


    7罗福莉访谈:几个判断

    3.5 小时访谈里,几个能落到地的判断(不含鸡汤):


    8评价:为什么说它是「追赶机器」

    前面都是「它做了什么」。这一节是我的判断:MiMo 工程上非常扎实,但有几个值得讨论的局限,让它现在更像「能高效追平、暂时还看不到领跑的支点」。下面几条都带着「这也可能只是阶段性选择」的前提,不是定性它不行。

    MiMo RL 系统的组件溯源:大量集成,原创集中在 MOPD 蒸馏
    把 RL 系统拆开看,多数是已知组件的高质量集成,唯一算法级原创是 MOPD——而蒸馏本质是「压缩已有能力」,不是「探索新能力」。

    8.1 MOPD 本质是「压缩」,不是「探索」

    MOPD 是多教师 on-policy 蒸馏,学生能力上界 ≈ 最强 teacher 的上界。而罗自己承认「RL scaling 的算力跟预训练还不在一个水位,到同水位才会分享」——也就是说真正拓展能力边界的 RL scaling 规模还很小,主力是用蒸馏把已有 teacher 高效合并。蒸馏擅长追赶(搬运+压缩已有能力),RL scaling 才负责发现新能力。这跟它整套「集成已知组件」的工程气质是一致的,也跟 MiniMax 那条押 RL scaling 的路形成对比。

    8.2 「无跷跷板」更像是「大部分域无跷跷板」

    报告 Table 7 主张 MOPD「保留最强 teacher 的能力、无 trade-off」,这在数学/代码等域上确实成立。但同一张表里也有几处回退:Creative Writing 90.1 → 86.2(-3.9)BrowseComp 51.7 → 45.4(-6.3)、GPQA -0.6、SWE -0.8。规律比较清楚:可验证、reward 密集的域涨得稳,创意写作和开放检索这种「软」域会有所回退。

    这其实和 reverse-KL on-policy 蒸馏的已知特性对得上:mode-seeking 倾向 → 多样性收窄。用我之前那篇博客的分析,正好能解释官方表格里那个没被特别强调的 creative writing 掉分——可以看作 benchmark 上的一个实证,而不是说这套方法有硬伤。

    8.3 知识容量是一个值得注意的取舍

    激活参数小(Flash 15B)是为成本和速度做的取舍,代价也写在报告里:SimpleQA 20.6 vs Kimi 35.3、中文 C-SimpleQA 61.5 vs Kimi 77.6、GlobalMMLU 76.6 vs DeepSeek 82,报告自承「knowledge capacity 偏低」。罗的思路是「Context > 参数」——知识尽量靠检索补,这在 Agent 范式下是合理选择,但事实召回(尤其中文知识)能在多大程度上靠检索补齐,还需要观察。

    另一个可以讨论的点是定位:MiMo 当前火力主要压在 agentic / coding,在 general writing(Arena-Hard hard prompt 54.1,低于 Kimi / GPT 的 72)和中文知识上相对偏弱。考虑到小米的消费场景,这两块未来大概率还需要补——当然,这也可能是阶段性的优先级选择,而非能力天花板。

    8.4 它把世界观押在 harness 上,但 harness 不在自己手里

    罗反复强调「模型与 Agent 框架协同进化」。值得说明的是,主流 harness 现在大多已开源——OpenClaw 开源(后被 OpenAI 收购,但开源属性没变),Claude Code 用户侧也已经开源,所以「黑盒」这个说法已经不准确,任何人都能读、能改。

    但这反而凸显了另一个问题:开源意味着大家都能用同一套框架,框架本身不再是壁垒;真正的差异回到「谁的模型 + 谁的分发」。MiMo 目前是把自己的模型接到别人主导的框架上(自家 demo 和研究提速也都在用 Claude Code),而 Anthropic / OpenAI 是「模型 + 自家框架 + 分发」一体。所以 MiMo 真正可能抄不走的护城河,未必在云端 agent 竞赛,而更可能在小米独有的硬件分发(端侧小模型、IoT、机器人)——这也和罗讲「开源取决于你有没有别人短期拿不下的生态位」的逻辑一致。

    8.5 激进稀疏是「优雅退化」,不是「峰值更强」

    GSM-Infinite Hard 从 16K 的 37.7 退到 128K 的 29.0——它的卖点是退化平缓,这点确实做到了;但同时也要看到短上下文上别人推理更强(DeepSeek-V3.2 在 16K 是 50.4),长文推理 MRCR 45.7 vs Gemini 89.7、Terminal-Bench 2.0 38.5 vs Gemini 54.2。换句话说,它的长上下文优势更多体现在成本、速度和检索鲁棒,而不是长文深推理的峰值。这和「为 long context 而生」的叙事并不矛盾,但值得区分清楚:高效 ≠ 推理最强。

    MiMo-V2 是一台精巧的追赶机器:hybrid + MTP 压成本、MOPD 压时间、RL 系统是已知组件的高质量集成。它能高效追平 Claude;至于能否领跑,取决于两件还没看到答案的事——蒸馏之上的 RL scaling 能不能起来,以及它能否把硬件分发这个独有生态位真正用起来。