MiMo-V2.5 の技術仕様
| 仕様 | MiMo-V2.5 |
|---|---|
| モデルID | mimo-v2.5 |
| プロバイダー | Xiaomi MiMo |
| モデルタイプ | ネイティブなオムニモーダル基盤モデル |
| アーキテクチャ | スパースMixture-of-Experts |
| 総パラメータ数 | 310B |
| 活性化パラメータ数 | 15B |
| コンテキストウィンドウ | 1Mトークン |
| 最大出力 | 128Kトークン |
| 入力モダリティ | テキスト、画像、動画、音声 |
| 出力 | テキスト |
| ビジョンエンコーダ | 729MパラメータのViT |
| オーディオエンコーダ | 261MパラメータのAudio Transformer |
| ツール呼び出し、Web検索、構造化出力、ストリーミング、コンテキストキャッシュ | はい |
| ライセンス | MIT |
310B/15B のアーキテクチャは特に重要です。MiMo-V2.5 は一般的な意味での 15B モデルではありません。15B は各トークンで活性化されるパラメータ数であり、完全な MoE は 310B のパラメータを含みます。本モデルは 256 のルーティングエキスパートを使用し、トークンごとに 8 エキスパートを活性化します。
MiMo-V2.5 とは？
MiMo-V2.5 は、Xiaomi が「オムニモーダルな知覚」と「エージェント用途」を中心に設計した次世代のマルチモーダルモデルです。
従来のテキスト専用LLMとは異なり、MiMo-V2.5 はネイティブに画像、動画、音声、テキストを理解します。Xiaomi は、モデルが情報を知覚し、推論し、その後にツールを使用したりアクションを実行したりする必要がある長コンテキスト・マルチモーダル・エージェントのシナリオを想定しています。
開発者にとっての重要な現行バージョンの注意点として、Xiaomi は旧 MiMo-V2 モデルを2026年6月30日に廃止し、V2.5 シリーズへの移行を推奨しています。
そのため、新規統合では mimo-v2.5 が、旧来の mimo-v2-pro、mimo-v2-omni、mimo-v2-flash よりも適切なモデルIDとなります。
MiMo-V2.5 の主な特徴は？
ネイティブなオムニモーダル理解
MiMo-V2.5 の決定的な特徴は、マルチモーダリティがモデルに直接統合されている点です。
受け付けるのは:
- テキスト
- 画像
- 動画
- 音声
これにより、開発者は各モダリティを個別に処理してその結果をテキストLLMへ渡すのではなく、複数の情報タイプを横断して推論するアプリケーションを構築できます。Xiaomi はこれをネイティブなフルモーダル知覚と表現しています。
実用例として、長尺の動画と音声トラック、テキストの質問を同時に受け取り、イベントを特定して何が起きたかを説明し、構造化された回答を生成する動画分析エージェントが挙げられます。
1M トークンのコンテキストウィンドウ
MiMo-V2.5 は最大 100万トークンのコンテキストと、最大 128K トークンの出力をサポートします。
これは次の用途で特に有用です:
- 大規模ドキュメントの分析
- 長尺動画の理解
- リポジトリレベルのコーディング
- 長時間のリサーチセッション
- マルチステップのエージェント
- 長い対話
- 大規模な企業ナレッジベース
この 1M コンテキストは単なるマーケティング上の数値ではありません。Xiaomi は特に、長尺動画のトラッキング、長大なドキュメント分析、長時間にわたる時系列推論を対象ワークロードとして挙げています。
エージェント指向のツール利用
MiMo-V2.5 は関数呼び出し、Web検索、構造化出力、ストリーミングをサポートします。
これにより、テキスト生成に限定されたモデルよりもエージェント用途で大幅に有用になります。
典型的なワークフローは次のようになります:
知覚 → 推論 → 検索 → ツール呼び出し → 結果分析 → 継続
これは、リサーチエージェント、コーディングアシスタント、カスタマーサポートエージェント、マルチモーダル自動化に特に有効です。
スパース MoE の効率性
MiMo-V2.5 は、1トークンあたり 15B の活性化パラメータを用いる 310B パラメータのスパースMoEアーキテクチャを採用しています。
バックボーンは 48 レイヤーで構成され、そのうち 39 レイヤーがスライディングウィンドウ・アテンション、9 レイヤーがフルアテンションです。このハイブリッド設計は、非常に長いコンテキストを計算上扱いやすくすることを意図しています。
開発者にとって重要な区別は、活性化パラメータ数は総メモリ要件を意味しないという点です。310B パラメータのモデルをセルフホストすることは、依然として大規模なインフラを要します。
ハイブリッド・スライディングウィンドウ・アテンション
MiMo-V2.5 は、スライディングウィンドウ・アテンションとグローバルアテンションを組み合わせています。
アーキテクチャは 128 トークンの SWA ウィンドウを用い、39 の SWA レイヤーと 9 のフルアテンションレイヤーで構成されます。
このアーキテクチャ上の選択は、各レイヤーでフルアテンションを維持すると長コンテキスト推論が著しく高コストになるため、1M トークンのコンテキスト対応に特に関連します。
マルチトークン予測
MiMo-V2.5 には、約329M パラメータを持つ3 つの MTP レイヤーが含まれます。MTP 設計は、投機的デコーディングによって推論効率を高め、より効率的な強化学習の学習を支援することを意図しています。
ベンチマークにおける MiMo-V2.5 の性能は？
MiMo-V2.5 は、コーディング、ターミナルエージェント、リサーチエージェント、マルチモーダルエージェントタスクを対象としたベンチマーク結果を公開しています。現行の Hugging Face モデルカードは以下の結果を報告しています:
| ベンチマーク | MiMo-V2.5 | 評価対象 |
|---|---|---|
| SWE-Bench Pro | 56.1 | ソフトウェア工学 |
| Terminal-Bench 2.0 | 65.8 | ターミナル／エージェントタスク |
| Claw-Eval General | 62.1 Pass³% | 一般的なエージェント能力 |
| Claw-Eval Multimodal | 23.8 Pass³% | マルチモーダル・エージェント能力 |
| Claw-Eval Multi-Turn | 63.2 Pass³% | マルチターン・エージェント |
| ResearchClawBench | 16.91 | リサーチエージェントのタスク |
これらの数値は慎重に解釈する必要があります。
SWE-Bench Pro の 56.1 は意味のあるソフトウェアエンジニアリング能力を示し、Terminal-Bench 2.0 の 65.8 はターミナルや開発環境と対話するエージェントに特に関連性があります。
同時に、一般系の Claw-Eval スコア（62.1）とマルチモーダルスコア（23.8）の差は有益な示唆を与えます。つまり、強力な一般エージェント性能が、すべてのマルチモーダル・エージェントタスクで同等の性能を自動的に意味するわけではないということです。
本番評価では、単一のリーダーボード数値に頼るのではなく、自身のワークロードでテストすべきです。
MiMo-V2.5 と MiMo-V2.5-Pro の比較
MiMo-V2.5 と MiMo-V2.5-Pro は同じ V2.5 世代に属しますが、最適化の対象が異なります。
| 仕様 | MiMo-V2.5 | MiMo-V2.5-Pro |
|---|---|---|
| 総パラメータ数 | 310B | 1.02T |
| 活性化パラメータ数 | 15B | 42B |
| コンテキスト | 1M | 1M |
| マルチモーダル入力 | テキスト／画像／動画／音声 | エージェント特化 |
| 主な位置付け | オムニモーダル・エージェント | 複雑なエージェント＆コーディング |
| ルーティングエキスパート数 | 256 | 384 |
| トークンあたりのエキスパート数 | 8 | 8 |
| LLM レイヤー数 | 48 | 70 |
| MTP レイヤー数 | 3 | 3 |
区別は明快です。
ネイティブなマルチモーダル理解と効率的な汎用エージェントには MiMo-V2.5 を。最も難易度の高い推論、コーディング、長期的エージェントワークロードには MiMo-V2.5-Pro を。
Xiaomi のモデル選定ガイドでは、画像・音声・動画コンテンツの理解には mimo-v2.5 を、複雑な推論や長文処理には mimo-v2.5-pro を推奨しています。
MiMo-V2.5 のユースケース
マルチモーダルAIエージェント
MiMo-V2.5 は、ドキュメント、画像、動画、音声を精査してからアクションを決定する必要があるエージェントの中核モデルとして機能できます。
長コンテキストのドキュメント分析
1M トークンのコンテキストにより、次の分析に適しています:
- 大規模な法務文書コレクション
- 技術ドキュメント
- 研究アーカイブ
- 大規模なコードベース
- 企業ナレッジベース
コーディングエージェント
エージェント系ベンチマークとツール利用能力により、リポジトリを精査し、バグについて推論し、ツールを実行し、解決策を反復するコーディングアシスタントに適しています。
動画理解
MiMo-V2.5 は動画生成を主目的とするのではなく、理解のための入力モダリティとして動画を扱います。
想定されるアプリケーションには以下が含まれます:
- 動画要約
- 長尺動画の質問応答
- 動画検索
- イベント検出
- 教育用動画の分析
- 監視映像の分析
音声・映像アシスタント
音声と視覚情報の両方を受け付けるため、話し言葉の指示と視覚的コンテキストを組み合わせて解釈できるアシスタントを構築できます。
長時間稼働の自律エージェント
長いコンテキストとエージェント的訓練の組み合わせにより、単一の応答でタスクを完了するのではなく、多数の中間ステップにわたって状態を維持するワークフローに適しています。
MiMo-V2.5 の制限事項
MiMo-V2.5 の仕様は印象的ですが、いくつかの実務的な制限に注意が必要です。
第一に、1M コンテキストだからといって、すべてのアプリケーションが最大ウィンドウで最適性能を発揮するとは限りません。長コンテキスト推論には依然として相当なメモリ、帯域幅、レイテンシの考慮が伴います。
第二に、本モデルは非常に大規模な MoE システムです。1トークンあたりの活性化パラメータは 15B に過ぎませんが、完全なモデルは約 310B パラメータを含み、小型の密モデルを動かすのに比べてセルフホスティングの負担はかなり大きくなります。
第三に、マルチモーダルベンチマークの性能はタスクによって大きく変動し得ます。Claw-Eval の結果が一般系スコアよりもマルチモーダルスコアで大きく低いことは、アプリケーション固有のテストの必要性を裏付けます。
最後に、モデルのエコシステムは GPT、Claude、Gemini を取り巻く成熟したエコシステムに比べるとまだ新しい段階です。そのため、ミッションクリティカルな本番導入の前に、ツールチェーン、プロバイダー互換性、構造化出力の挙動、ツール呼び出しの信頼性を評価すべきです。
CometAPI で MiMo-V2.5 API を使う方法
MiMo-V2.5 は、確立された LLM エコシステムと互換性のある API パターンに従うため、API 集約プラットフォームに特に適しています。Xiaomi 自身が OpenAI および Anthropic 互換の API アクセスを提供しています。
CometAPI では、他の対応モデルと同様の基本ワークフローで統合できます。
ステップ 1: CometAPI の API キーを取得
CometAPI アカウントを作成またはログインし、API キーを取得します。
import os
COMETAPI_KEY = os.environ["COMETAPI_KEY"]
ステップ 2: MiMo-V2.5 モデルを設定
モデルを次のように設定します:
mimo-v2.5
そして CometAPI の互換 API エンドポイントを使用します。
正確なエンドポイントとリクエストスキーマは、デプロイ前に最新の CometAPI モデル／API ドキュメントに照らして確認してください。
ステップ 3: マルチモーダルとエージェントのワークフローを構築
mimo-v2.5 のより興味深い用途は、通常のテキストチャットではありません。マルチモーダル推論と外部ツールを組み合わせ、次のようなワークフローを構築できます:
ユーザー入力 → 画像／動画／音声の理解 → 推論 → ツール呼び出し → 結果分析 → 次のアクション
これにより、自律的なリサーチエージェント、コーディングエージェント、マルチモーダルなカスタマーサポート、長コンテキストの企業向けアシスタントに特に魅力的です。
なぜ CometAPI 経由で MiMo-V2.5 を使うのか？
MiMo-V2.5 はマルチモデル API 環境で特に有用です。なぜなら、開発者はプロバイダーごとに別個のインフラスタックを構築することなく、GPT、Claude、Gemini、DeepSeek など他のエージェントモデルと比較したい場合があるからです。
アプリケーションに次が必要な場合、CometAPI は有用です:
- 統一された API レイヤー
- 複数の AI モデルファミリーへのアクセス
- 容易なモデル切り替え
- API キー管理の一元化
- 迅速なモデル比較
- 実験と本番のための単一の統合レイヤー
特にエージェント性能と推論コストのトレードオフを評価するチームにとっては、最大手のプロプライエタリモデルが自動的に最良だと仮定するのではなく、MiMo-V2.5 をフラッグシップモデルと並べてテストする価値があります。