MiMo-V2.6 是小米发布的全模态模型系列，包含 Pro 与 Flash 两个规格，支持文本、图像、视频和音频输入，最大上下文长度为 1M token。它被用于代码与终端、通用工具、视觉创作、3D 场景和科研任务；这次发布还开放了模型权重、技术报告、9B 蒸馏模型、强化学习环境与训练框架。

判断它是否值得使用，需要分开看三件事：发布材料展示了哪些用途，技术报告中的评测表现如何，以及这些能力是怎样训练出来的。

一、MiMo-V2.6 是什么，能做什么

1. 两个主力版本，面向长任务而设计

• MiMo-V2.6-Pro：总参数量 1.02T，单 token 激活参数 42B。
• MiMo-V2.6-Flash：总参数量 310B，单 token 激活参数 15B。
• 1M token 最大上下文：模型卡把长代码仓库、工具调用轨迹和跨会话智能体任务列为目标场景。
• 全模态输入：681M 参数视觉编码器负责图像与视频，音频由 AudioTokenizer 和音频 patch encoder 两级处理。

2. 代码、终端与通用工具

技术报告把代码工程、终端操作和通用工具调用作为主要评测方向。模型通过 Agent harness 获得系统提示、工具接口和上下文管理能力，再在多轮交互中读取结果、继续操作。小米公布的成绩显示，这一能力在不同任务上的强弱差异很大，具体数据放在下一节比较。

3. 视觉设计与 3D 世界

小米把“由文本、图像或视频构建可玩的 3D 世界”列为 MiMo-V2.6 的应用方向，并展示了 Blender 对象生成和仿真环境中的机械臂控制。配套视频呈现的是一个可操控的 3D 骑马场景。

4. 科研案例：材料筛选与形式化证明

小米披露了两个与研究人员合作的案例：一个是检索文献和专利、计算筛选用于捕获 PFAS 的金属有机框架材料；另一个是在 Lean 4 中形式化李–约克“周期三蕴含混沌”的主要定理。后者经修订整合后超过 6,000 行代码，由 Lean 内核验证且没有未完成的证明占位符。视频用 logistic map 分岔图呈现该定理所讨论的现象。

5. 网页与多媒体创作

创意视频连续展示了时尚、建筑、音乐、画廊和技术说明等多种网页成品。小米同时列出的创作任务还包括调用 Figma 与图像、视频工具制作视觉素材，以及创作约十种乐器编制的管弦乐并转成 MIDI。

这些案例展示了任务类型；模型在可重复评测中的表现，还要看下一节的数据。

二、性能到底如何：强项、短板与成本

1. 基准评测：不同任务互有胜负

技术报告汇总了代码、通用工具、网络安全和视觉智能体四类结果。下表从原图中选出能体现差异的项目，并保留发布方自建基准的标记。

这组结果支持一个具体判断：Pro 在 AutomationBench 和 Terminal Bench 2.1 上略高于表中的对照模型，DeepSWE v1.1 与 Claude Opus 5 相差 2.1 分；到了 Terminal Bench 4.0，差距扩大到 14.1 分，ExploitBench 与 GPT-5.6 Sol 相差 30.6 分。MiMo Code Bench、MiMo Cyber Bench 和 MiMo Visual Coding 由小米自建，其结果应放在对应测试设置中理解。

2. 智能—成本图比较的是什么

小米发布的成本效益图把 MiMo-V2.6-Pro 标在 Artificial Analysis Intelligence Index 46、每项任务约 0.13 美元的位置，并据此概括为“同等智能水平下成本约为国际领先模型的 1/20 至 1/60”。图下注明：MiMo-V2.6-Pro 的数据由 Xiaomi MiMo 提供，其他模型采用 Artificial Analysis 公开数据。因此，这张图比较的是其加权评测任务成本，不是企业长流程的端到端成本。

三、长程智能体是怎样训练出来的

技术报告把多领域任务、不同运行框架和更细的奖励信号放进同一次大规模强化学习过程。

1. 一次混合强化学习（You Only RL Once）

训练批次混合了多个领域：软件工程与算法代码占 68%、视觉设计与界面构建占 13%、通用工具与办公流占 12%、网络安全占 4%、长上下文遵循占 3%。

为了支撑这种混合训练，强化学习的计算规模大幅提升：单步采样 1,568 个提示词，每个提示词并行滚动 16 条轨迹，单步全局产生 25,088 条交互序列，包含 2.7B 至 3.7B 个 token。在这一阶段，Pro 累计消耗约 260 万美元的 GPU 算力，Flash 消耗约 90 万美元。在 Pro 的算力分配中，环境采样生成消耗了 43.8%，梯度更新训练占 43.5%，负责评估打分的判分器（Grader）占 12.7%。

2. 同一道题多份通过答案的分流机制（Groupwise Grading）

单元测试只能判断通过或失败，分不出两份通过补丁的工程质量。报告采用两种群组评分方法继续区分这些轨迹：

• GRS（群组奖励合成）：针对通过率普遍较高的简单任务，先在离线阶段对比多个采样轨迹，总结出针对该任务的“代码实现标准”与“排查验证行为标准”。在正式训练时，判分器在环境内对生成的代码与操作路径独立打出质量分，并将其与原始测试结果连乘。即使同一组生成的代码全部通过测试，乘积差异依然能为模型提供精细的梯度方向。
• GAR（群组优势再分配）：针对通过率参差不齐的复杂代码任务，采用线上智能体裁判。裁判在同一个工作区内同时对比一组候选轨迹中的成功解与失败解，从方法合理性、实现精准度、修改最小化、避免外部副作用、代码工程规范五个维度进行排序。系统通过降权平庸代码的优势值，将正向优势额度转移给那些修改范围更克制、结构更严谨的代码；若检测到作弊，则直接将有效奖励置零。

在 MiMo-V2.6-Flash 的代码专项对照实验中，不使用 GAR 时，交互轮数和 token 数迅速增长，更多轨迹触及长度上限；使用 GAR 后，轮数大致稳定，token 长度缓慢增长，DeepSWE v1.1 的 avg@3 通过率持续提升到第 52 步。维护者审计还观察到，未使用 GAR 的策略更常出现吞掉异常、放宽校验和扩大导出范围等做法。

3. 环境对抗与防作弊加固

训练中的模型会从缓存、已安装软件包或上游仓库寻找现成修复，例如安装新版 pytest、下载 GitHub 源文件或克隆最新代码。环境团队据此加入三层防护：

• 训练前环境净化：清理历史编译残留、缓存以及基准环境构建过程中的参考补丁；将代码仓库的 Git 历史截断至目标问题修复前的基础提交节点，并在运行容器中施行网络物理隔离，断绝外部抓取渠道。
• 对抗式攻防（Hack Agent）：让专门的攻击智能体搜索缓存泄露和遗留路径，根据发现继续清理环境，再重新测试。
• 训练期轨迹审计：将确认存在绕过行为的轨迹奖励置零。报告记录的已确认作弊轨迹占比在 Pro 和 Flash 的整个训练过程中都低于 2%。

4. 解耦的多 Harness 训练

不同 Harness（智能体脚手架） 会改变系统提示、工具接口和上下文管理方式。团队从同一个最小 Agent 循环出发，组合出多种可控的 mini-harness，并把它们混入训练。

在没有参与训练的 Codex、Claude Code 和 mini-swe-agent 三个框架上，DeepSWE v1.1 的平均 Pass@1 从约 50% 升到 66%，训练框架与留出框架之间的平均差距也缩小。这个实验支持的是代码能力可以跨这三种框架迁移。

5. 冻结 MoE 路由器与真实工程故障

在超大规模长程训练中，系统工程遭遇了多重挑战：

• 路由器崩溃的归因与冻结：在未冻结路由器的早期对照试验中，MoE 第 9 层的负载变异系数在 20 个训练步内从 0.78 升至 2.0，峰值负载达到均值的 16 倍，冷专家比例从 0.5% 升至 22%。排查实验发现，只把路由器参数恢复为强化学习开始前的值，负载就接近初始平衡，基准表现没有明显变化。这把原因指向了路由漂移。正式训练冻结路由器后，负载指标保持在较稳定的范围内。
• 训练故障分析：在 30 个训练步的实际运行中，Pro 历经 123.1 小时，Flash 历时 81.8 小时，期间经历了真实的分布式工程中断。中断诱因包括 GPU 显存双比特错误（DBE）、底层集群 Pod 崩溃、线上判分网络超时，以及重启后短任务先结束导致长度预测失真而耗尽显存与主机 KV 缓存池；在训练侧，甚至出现过单个专家并行节点瞬时承载超过均值 30 倍的 token 负载从而引发显存溢出，以及序列过长导致主机 CPU 内存耗尽等问题。

6. MOPD2：向难验证领域的扩展尝试

针对缺乏明确可执行校验规则的领域（如复杂多步骤科研构想、开放式 3D 场景与创意设计），小米引入了多前缀多教师在策略蒸馏（MOPD2）。该方法通过直接复用教师轨迹或高质量合成示范的历史上下文，将其拆解为多个决策前缀，让学生模型在指定中间节点采样单步动作并接受监督，旨在缓解学生模型脱离轨道的问题，并控制重跑整条长交互轨迹的算力成本。

四、开源了什么，部署门槛多高

小米发布了 Pro、Flash 和 9B 蒸馏模型权重，以及强化学习环境、训练框架和 mini-harness；Hugging Face 模型卡将模型仓库标为 MIT 许可。

1. MiMo-V2.6-Distill-Qwen-9B

这个 9B 模型以 Qwen3.5-9B 为底座，先用 MiMo 生成的 77.4B token（其中 27.2B 为 loss token）做监督微调，再使用开源环境继续强化学习。报告列出的评测中，SFT 和后续 RL 都带来了增益。

例如，SWE-bench Pro 从基础模型的 32.0 提升到 SFT 后的 44.6，再到单 Harness RL 后的 47.6；AutomationBench 从 5.0% 提升到 30.3% 和 33.1%；Terminal Bench 2.1 从 27.0 提升到 37.1 和 52.8。完整表格还包含网络安全和视觉编码任务，其中 MiMo Code、MiMo Cyber 和 MiMo Visual 的 mini 项目由小米自建。

2. 7K+ 任务环境与训练框架

随技术报告发布的还有约 7,000 个带验证器的任务环境：软件工程约 3k、网络安全约 1k、通用知识与办公约 1k、前端与视觉约 2k，另有 1k 音乐生成任务，并配套端到端强化学习框架和可组合的 mini-harness。这些资源提供了可直接改造的任务、验证器和交互框架。

3. Pro 的部署示例是多节点配置

完整 Pro 有 1.02T 总参数。模型卡中的 SGLang 示例使用 --nnodes 2、张量并行 --tp 16、数据并行 --dp 2、专家并行 --ep 16 和 DeepEP 通信后端。模型卡没有把这组示例写成最低硬件要求；没有多节点服务条件时，可选入口包括官方 API、托管平台和 9B 蒸馏模型。

五、怎么选

不同团队可以按任务和基础设施做第一轮筛选：

1. 面向产品团队与技术决策者

• 初筛与复测：AutomationBench、DeepSWE 等公开得分可以帮助判断模型在多步调用和代码任务上的大致位置。进入业务选型后，应改用企业自己的系统、API 和历史任务构建代表性长任务集，观察成功率、重试次数、人工接管点和总成本。
• 版本选择：
  • 若场景对端到端延迟极为敏感（如实时交互助手、高并发日常数据提取），优先选择 Flash 版本 或其 UltraSpeed 模式；
  • 若涉及复杂的多文件代码重构、跨文档深度审查等长思考链路，建议通过云端调用 Pro API；
  • 成本测试应记录完整任务的成功率、重试次数、人工接管点、token 用量和工具运行时间，而不是直接套用图中的每任务成本。

2. 面向应用开发者与系统架构师

• 架构设计：多 Harness 实验表明，同一个模型换框架后成绩会变化。应用侧应在准备采用的框架中测试，并把工具返回、错误处理和上下文管理拆成可替换模块。
• 环境安全隔离：给生产智能体开放代码执行或终端权限时，应按任务最小化出网、文件与凭据权限，并记录每次工具调用。

3. 面向算法研发与高校研究者

• 较低门槛的切入路径：研究者可以从 MiMo-V2.6-Distill-Qwen-9B 与开源任务环境入手，按自己的硬件条件缩小任务与训练规模，研究特定领域强化学习、同题代码对比评分和防作弊判分。
• 方法迁移：在非确定性输出领域，可重点借鉴其群组打分体系（GAR）与 MOPD2 的前缀蒸馏思路，探索如何将难以通过单一数值量化的长程任务转化为可提供稳定梯度的优势信号。