Xiaomiがオープンソースモデル「MiMo-V2.6」を公開:何ができるのか、Opus 5に迫る性能
コードや端末操作、汎用ツールから3D世界、科学研究、Web制作まで。まずはMiMo-V2.6の機能と実際の得意・不得意を見極め、続いて長期エージェントをどのように学習させたのかを解き明かします。
MiMo-V2.6は、Xiaomiが公開した全モダリティ対応のモデルシリーズです。ProとFlashの2つの仕様が用意され、テキスト、画像、動画、音声の入力に対応し、最大コンテキスト長は1Mトークンに達します。コードや端末操作、汎用ツール、視覚的制作、3Dシーン、科学研究タスク向けに活用されており、今回のリリースではモデルの重み、技術報告書、9B蒸留モデル、強化学習環境、学習フレームワークも併せて公開されました。
本モデルを採用すべきかどうかを判断するには、公開資料で示された用途、技術報告書におけるベンチマーク性能、そしてこれらの能力がどのように学習されたのかという3点を分けて見る必要があります。
1. MiMo-V2.6とは何か、何ができるのか
1. 長期タスクを見据えて設計された2つの主力エディション
- MiMo-V2.6-Pro:総パラメータ数 1.02T、トークンあたりのアクティブパラメータ数 42B。
- MiMo-V2.6-Flash:総パラメータ数 310B、トークンあたりのアクティブパラメータ数 15B。
- 最大1Mトークンのコンテキスト:モデルカードでは、長大なコードリポジトリ、ツール呼び出しの実行軌跡、セッションをまたぐエージェントタスクがターゲットシナリオとして挙げられています。
- 全モダリティ入力:681Mパラメータのビジョンエンコーダーが画像と動画を処理し、音声はAudioTokenizerと音声パッチエンコーダーの2段階で処理されます。
2. コード、端末操作、汎用ツール
技術報告書では、ソフトウェアエンジニアリング、端末(ターミナル)操作、汎用ツール呼び出しが主要な評価軸として設定されています。モデルはAgent harnessを通じてシステムプロンプト、ツールインターフェース、コンテキスト管理能力を獲得し、マルチターンのやり取りの中で実行結果を読み取りながら操作を継続します。Xiaomiが公開したスコアによれば、この能力はタスクによって強弱の差が非常に大きく、具体的な数値比較は次節で詳述します。
3. ビジュアルデザインと3D世界
Xiaomiは「テキスト、画像、動画からプレイ可能な3D世界を構築すること」をMiMo-V2.6の応用領域として位置づけ、Blenderによるオブジェクト生成やシミュレーション環境におけるロボットアーム制御を実演しました。付属の動画では、実際に操作可能な3D乗馬シーンが紹介されています。
4. 科学研究の事例:材料スクリーニングと形式証明
Xiaomiは研究者との共同研究事例を2点開示しています。1つは、文献や特許を検索し、PFAS(有機フッ素化合物)の捕捉に用いる金属有機構造体(MOF)材料を計算スクリーニングした事例です。もう1つは、Lean 4を用いてリー・ヨーク(Li-Yorke)の「周期3はカオスを意味する」の主要定理を形式化した事例です。後者は修正・統合を経て6,000行を超えるコードとなり、未完了の証明プレースホルダー(sorry等)を残さずLeanカーネルによって検証されています。動画では、同定理が扱う現象をロジスティック写像の分岐図で視覚化しています。
5. Webページおよびマルチメディア制作
クリエイティブ動画では、ファッション、建築、音楽、ギャラリー、技術解説など、多種多様なWebページの完成例が連続して示されています。さらにXiaomiが挙げた制作タスクには、Figmaや各種画像・動画ツールを呼び出してビジュアル素材を作成することや、約10種類の楽器編成によるオーケストラ楽曲を作曲してMIDIに変換することなどが含まれています。
これらの事例はタスクの種類を示すものですが、再現可能なベンチマークにおいてどのような実力を発揮したのかは、次節のデータを確認する必要があります。
2. 実際の性能はどうなのか:強み、弱み、そしてコスト
1. ベンチマーク評価:タスクごとに一長一短
技術報告書は、コード、汎用ツール、サイバーセキュリティ、ビジュアルエージェントの4分類で結果をまとめています。下表は原図から差異が明確に表れている項目を抽出し、提供元による独自ベンチマークの表記も保持したものです。

| 評価次元とベンチマークテスト | MiMo-V2.6 Pro | MiMo-V2.6 Flash | Claude Opus 5 | GPT-5.6 Sol |
|---|---|---|---|---|
| コードエンジニアリング:DeepSWE v1.1 | 71.9 | 67.9 | 74.0 | 73.0 |
| プログラム再構築:ProgramBench | 26.5 | 26.0 | 37.0 | 25.0 |
| コード能力:MiMo Code Bench (社内独自) | 63.2 | 61.2 | 68.6 | 59.3 |
| 汎用ワークフロー:AutomationBench v1.0.6 | 53.1 | 52.3 | 50.3 | 45.8 |
| プロフェッショナル成果物:GDPval-AA 2.1 | 1673 | - | 1708 | 1588 |
| 基礎ターミナル:Terminal Bench 2.1 | 89.9 | 87.6 | 89.1 | 88.8 |
| 複雑ターミナル:Terminal Bench 4.0 | 34.9 | 28.8 | 49.0 | 39.9 |
| セキュリティ脆弱性悪用:ExploitBench | 47.9 | 25.3 | 70.0 | 78.5 |
| ビジュアルコーディング:MiMo Visual Coding (社内独自) | 72.3 | 71.5 | 70.0 | 73.4 |
この結果から、ある具体的な判断が導き出せます。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はXiaomiが独自に構築したものであり、その結果はそれぞれのテスト環境を念頭に置いて捉える必要があります。
2. 知能—コスト図は何を比較しているのか
Xiaomiが公開したコストパフォーマンス図では、MiMo-V2.6-ProがArtificial Analysis Intelligence Index 46、1タスクあたり約0.13ドルの位置にプロットされ、これをもとに「同等レベルの知能において、コストは世界トップクラスのモデルの約20分の1から60分の1」と総括されています。図の下部には、MiMo-V2.6-ProのデータはXiaomi MiMo提供、その他のモデルはArtificial Analysisの公開データを採用している旨が注記されています。したがって、この図が比較しているのは加重された評価タスクのコストであり、企業の長期ワークフローにおけるエンドツーエンドの総コストではない点に留意する必要があります。

3. 長期エージェントはどのように訓練されたのか
技術報告書では、複数領域のタスク、異なる実行フレームワーク、そしてよりきめ細かい報酬シグナルが、1回の単一な大規模強化学習プロセスに投入されています。
1. 一度の混合強化学習(You Only RL Once)
学習バッチには複数の領域が混合されています:ソフトウェアエンジニアリングとアルゴリズムコードが68%、ビジュアルデザインとUI構築が13%、汎用ツールとオフィスワークフローが12%、サイバーセキュリティが4%、長文コンテキスト追従が3%を占めます。
こうした混合学習を支えるため、強化学習の計算規模は大幅に引き上げられました。1ステップあたり1,568個のプロンプトをサンプリングし、プロンプトごとに16本の軌跡を並列生成(ロールアウト)することで、グローバル全体で1ステップあたり25,088本のインタラクションシーケンス(2.7B〜3.7Bトークンに相当)を生成しました。このフェーズにおいて、Proは約260万ドル相当、Flashは約90万ドル相当のGPU計算リソースを累積で消費しました。Proの計算リソース配分では、環境サンプリング生成が43.8%、勾配更新学習が43.5%、評価・スコアリングを担うグレーダー(Grader)が12.7%を占めています。
2. 同一課題における複数合格解答の選別メカニズム(Groupwise Grading)
ユニットテストは合否のみを判定するものであり、合格した2つのパッチの間にあるエンジニアリング品質の優劣までは判別できません。報告書では、これら軌跡の差異をさらに見分けるために2種類のグループ評価手法を採用しています:
- GRS(グループ報酬合成:Groupwise Reward Synthesis):合格率が概して高いシンプルなタスク向けの手法です。オフライン段階で事前に複数のサンプリング軌跡を比較し、そのタスクに対する「コード実装基準」と「トラブルシューティング・検証行動基準」をまとめます。本番学習時には、グレーダーが環境内で生成されたコードと操作ステップに対して個別に品質スコアを付与し、元のテスト結果と掛け合わせます。同一グループ内で生成されたコードがすべてテストに合格した場合でも、この積の差異によってモデルに微細な勾配方向を提供できます。
- GAR(グループ優位性再分配:Groupwise Advantage Redistribution):合格率にばらつきがある複雑なコードタスク向けの手法で、オンラインのエージェント判定員を採用しています。判定員は同一ワークスペース内で候補軌跡群の成功解と失敗解を同時に比較し、「アプローチの妥当性」「実装の正確さ」「変更箇所の最小化」「外部副作用の回避」「コードのエンジニアリング規範」の5つの次元からランキング付けを行います。平凡なコードの優位性(Advantage)を割り引くことで、変更範囲がより抑制され、構造が堅牢なコードへとプラスの優位性枠を再配分します。なお、不正行為が検知された場合は、有効報酬を即座にゼロにリセットします。
MiMo-V2.6-Flashのコード特化比較実験において、GARを用いなかった場合は対話ターン数とトークン数が急速に増大し、長さ上限に達する軌跡が増加しました。一方、GARを用いた場合はターン数がほぼ安定し、トークン長は緩やかな増加にとどまり、DeepSWE v1.1のavg@3合格率はステップ52まで継続して向上しました。メンテナーによる監査でも、GARを用いない方策では例外の握りつぶし、バリデーションの緩和、エクスポート範囲の過度な拡大といった挙動がより頻繁に見られることが確認されました。
3. 環境の対抗的防御と不正防止の堅牢化
学習中のモデルは、キャッシュ、インストール済みパッケージ、上流リポジトリから、新しいpytestのインストール、GitHubソースファイルのダウンロード、最新コードのクローンなどといった既存の修正手段を探索しようとします。環境構築チームはこれに対し、3層の防御策を講じました:
- 学習前環境のクリーンアップ:過去のコンパイル残渣、キャッシュ、ベンチマーク環境構築時の参考パッチを消去。コードリポジトリのGit履歴を対象課題が修正される前のベースコミットで切り捨て、実行コンテナ内のネットワークを物理的に隔離して外部取得ルートを遮断しました。
- 対抗的攻防(Hack Agent):専用の攻撃エージェントを走らせてキャッシュの漏洩や残存パスを探索させ、発見された脆弱性に基づいて環境をさらに浄化し、再テストを行いました。
- 学習時の実行軌跡監査:回避行動が確認された軌跡の報酬をゼロにリセットしました。報告書によると、確定した不正軌跡の割合はProおよびFlashの全学習期間を通じて2%未満に抑えられています。
4. 疎結合なマルチHarness学習
採用するハーネス(エージェント足場)が異なると、システムプロンプト、ツールインターフェース、コンテキスト管理の方法も変化します。開発チームは同一の最小エージェントループを出発点として、制御可能な複数のmini-harnessを組み合わせ、それらを学習に混在させました。
学習には含まれていないCodex、Claude Code、mini-swe-agentの3つのフレームワークにおいて、DeepSWE v1.1の平均Pass@1は約50%から66%へと上昇し、学習フレームワークと検証用フレームワークとの平均的な性能差も縮まりました。この実験は、コード能力がこれら3つのフレームワークをまたいで転移可能であることを裏付けています。
5. MoEルーターの凍結と実際のエンジニアリング障害
超大規模な長期学習において、システムエンジニアリングは複数の課題に直面しました:
- ルーター崩壊の要因特定と凍結:ルーターを凍結しなかった初期の比較実験では、MoE第9層における負荷の変動係数が20訓練ステップ以内で0.78から2.0へ急上昇し、ピーク負荷は平均値の16倍に達し、休眠状態のコールドエキスパートの割合が0.5%から22%へと増加しました。調査実験の結果、ルーターのパラメータのみを強化学習開始前の値に戻すだけで負荷が初期の均衡状態近くまで回復し、ベンチマークスコアに目立った変化は見られませんでした。これにより原因がルーティングのドリフト(偏向)にあることが判明しました。本番学習でルーターを凍結したところ、負荷指標は比較的安定した範囲を維持しました。
- 学習障害の分析:30訓練ステップの実稼働において、Proは123.1時間、Flashは81.8時間を要し、その間に現実の分散エンジニアリング中断に遭遇しました。中断の誘因には、GPUメモリのダブルビットエラー(DBE)、下位クラスタのPodクラッシュ、オンライングレーダーのネットワークタイムアウト、再起動後に短いタスクが先に終了したことで長さ予測が狂いGPUメモリおよびホストのKVキャッシュプールが枯渇したことなどが含まれます。学習側でも、単一のエキスパート並列ノードが瞬間的に平均の30倍を超えるトークン負荷を抱えてメモリオーバーフロー(OOM)を引き起こしたり、シーケンス長が長すぎてホストCPUのメモリが枯渇したりする問題が発生しました。
6. MOPD2:検証困難な領域への拡張の試み
明確で実行可能な検証ルールが不足している領域(複雑な多段階の科学研究構想、オープンエンドな3Dシーン、クリエイティブデザインなど)に対し、Xiaomiはマルチプレフィックス・マルチティーチャー・オンポリシー蒸留(MOPD2)を導入しました。この手法は、教師軌跡や高品質な合成デモの履歴コンテキストを直接再利用し、それを複数の意思決定プレフィックス(接頭辞)に分解した上で、生徒モデルに指定された中間ノードで1ステップの行動をサンプリングさせて監視を受けさせます。これにより、生徒モデルが軌道から逸脱する問題を緩和し、長大な対話軌跡全体を再実行することによる計算コストを抑えることを目指しています。
4. 何がオープンソース化され、導入のハードルはどれほどか
XiaomiはPro、Flash、および9B蒸留モデルの重みに加え、強化学習環境、学習フレームワーク、mini-harnessを公開しました。Hugging Faceのモデルカードでは、モデルリポジトリのライセンスがMITと記載されています。
1. MiMo-V2.6-Distill-Qwen-9B
この9BモデルはQwen3.5-9Bをベースとしており、まずMiMoが生成した77.4Bトークン(うち27.2Bがlossトークン)を用いて教師あり微調整(SFT)を行い、その後オープンソース環境を用いて強化学習を継続しました。報告書に記載された評価では、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プロジェクトはXiaomi独自のものとなっています。

2. 7,000以上のタスク環境と学習フレームワーク
技術報告書と併せて、バリデータ(検証器)付きの約7,000件のタスク環境が公開されました。内訳はソフトウェアエンジニアリング約3,000件、サイバーセキュリティ約1,000件、一般知識・事務約1,000件、フロントエンド・ビジュアル約2,000件で、その他に1,000件の音楽生成タスクがあり、エンドツーエンドの強化学習フレームワークと組み合わせ可能なmini-harnessが付属しています。これらのリソースにより、直接カスタマイズ可能なタスク、バリデータ、対話フレームワークが提供されます。
3. Proのデプロイ例はマルチノード構成
完全なProモデルは総パラメータ数が1.02Tに達します。モデルカードに記載されたSGLangのサンプルでは、--nnodes 2、テンソル並列 --tp 16、データ並列 --dp 2、エキスパート並列 --ep 16、通信バックエンドにDeepEPを使用しています。モデルカードはこの構成例を最低ハードウェア要件として規定しているわけではありませんが、マルチノードでの運用環境が整っていない場合の現実的な選択肢としては、公式API、ホスティングプラットフォーム、または9B蒸留モデルの利用が挙げられます。
5. どう選ぶべきか
各チームは、タスク要件と自社のインフラ状況に応じて以下のような初期スクリーニングを行うことができます:
1. プロダクトチームおよび技術意思決定者向け
- スクリーニングと再検証:AutomationBenchやDeepSWEなどの公開スコアは、多段階ツール呼び出しやコードタスクにおけるモデルの大まかな立ち位置を把握するのに役立ちます。実際のビジネス選定に入る段階では、自社固有のシステム、API、過去のタスクを用いた代表的な長期タスクセットを構築し、成功率、再試行回数、人間による介入ポイント、総コストを検証すべきです。
- バージョンの選定:
- エンドツーエンドの遅延に極めて敏感なユースケース(リアルタイム対話アシスタント、高スループットな日常的データ抽出など)では、FlashバージョンまたはそのUltraSpeedモードを優先的に検討します。
- 複数ファイルにまたがる複雑なリファクタリングや、ドキュメントを横断する綿密なレビューなど、思考チェーンが長いタスクの場合は、クラウド経由でPro APIを呼び出す構成が推奨されます。
- コスト検証を行う際は、資料にあるタスク単価の数値をそのまま当てはめるのではなく、タスク全体の成功率、再試行回数、手動介入ポイント、トークン消費量、ツール実行時間を包括的に計測する必要があります。
2. アプリケーション開発者およびシステムアーキテクト向け
- アーキテクチャ設計:マルチHarness実験が示すとおり、同一モデルであってもフレームワークが異なればスコアが変動します。アプリケーション側では、本番で採用予定のフレームワーク内で検証を実施し、ツール応答処理、エラーハンドリング、コンテキスト管理を疎結合で差し替え可能なモジュールとして設計しておくことが望まれます。
- 環境の安全な隔離:本番環境のエージェントにコード実行やターミナル権限を付与する際は、タスクごとにアウトバウンド通信、ファイルアクセス、認証情報のパーミッションを最小化し、すべてのツール呼び出しログを記録・保持する構成とすべきです。
3. アルゴリズム研究開発者および大学等の研究者向け
- 参入障壁の低い検証アプローチ:研究者はMiMo-V2.6-Distill-Qwen-9Bとオープンソースのタスク環境から着手し、保有するハードウェア条件に合わせてタスクと学習規模を縮小しながら、特定領域の強化学習、同一課題に対するコード比較評価、不正防止グレーダーの研究を進めることができます。
- 手法の応用展開:決定論的な出力が得られない領域においては、同モデルのグループ評価体系(GAR)やMOPD2のプレフィックス蒸留の発想が参考になります。単一の数値指標では定量化が難しい長期タスクを、いかにして安定した勾配をもたらす優位性シグナルへと変換するかを探る上で有益なアプローチとなります。
実践用持ち帰り資料
Markdown をスクロールして確認し、コピーしてチーム向けに調整できます。
Markdown を読み込み中…
