Xiaomi MiMo-V2.5はMacやROCmで動かせるのか
目次
Xiaomi MiMo-V2.5系列がAPI先行で公開された時点では、ウェイトは未公開だった。
その後、Hugging FaceにXiaomiMiMo/MiMo-V2.5とXiaomiMiMo/MiMo-V2.5-Proが公開された。
気になるのは、うちでよくやっている「Macで動くか」「ROCmで動かせるか」だ。
2026年4月30日時点では、普通のMacやEVO-X2級ROCm環境で気軽に試す段階ではない。
ただしllama.cpp側にMiMo V2.5対応PRが出ていて、テキスト単体ならそのうちGGUFで遊べる可能性は出てきた。
公開されたモデルの中身
今回のHugging Faceコレクションには4つある。
| モデル | 総パラメータ | アクティブ | コンテキスト | 位置づけ |
|---|---|---|---|---|
| MiMo-V2.5-Pro | 1.02T | 42B | 1M | テキスト、エージェント、コーディング寄り |
| MiMo-V2.5-Pro-Base | 1.02T | 42B | 256K | Proのベース |
| MiMo-V2.5 | 310B | 15B | 1M | テキスト、画像、動画、音声のオムニモーダル |
| MiMo-V2.5-Base | 310B | 15B | 256K | 通常版のベース |
ライセンスはMIT。
ここはかなり強い。商用利用や再配布の制約が緩いので、動かせるランタイムさえ揃えばローカル勢にも意味がある。
ただ、サイズが問題だ。
Hugging Face APIで見ると、MiMo-V2.5は約310.8Bパラメータ、Proは約1.023Tパラメータ。
どちらもFP8重みを含む構成で、4bit量子化が出たとしても通常版でだいたい150GB級、Proで500GB級を覚悟するレンジになる。
公式の実行例はSGLangとvLLM
モデルカードのデプロイ欄はSGLangとvLLMが前提になっている。
通常版MiMo-V2.5の公式例はSGLangで --tp-size 8、--dp-size 2、FP8量子化、FlashAttention 3系の指定が並ぶ。
vLLM側のレシピも「stable vLLMはまだMiMo V2.5未対応なので専用Dockerイメージを使う」と書いていて、前提ハードウェアは4x H200のTP4だ。
つまり、公式が想定しているのは個人PCではなくデータセンターGPU。
SGLang自体はAMD GPU対応も掲げているが、MiMo-V2.5の公式コマンドはCUDA/Hopper寄りで、ROCm版の同等レシピはまだ見当たらない。
この時点で、うちのEVO-X2やM1 Maxで「とりあえず公式手順を流す」は無理。
Macで動かすならMLXよりllama.cpp待ち
Macで最近うまくいったのはQwen3.6-35B-A3BをM1 Max 64GBでOllamaに流した検証と、MLXでQwen3.6-35B-A3BがOllamaの2倍速だった検証だ。
ただし、あれは35B-A3B、つまり総35Bでアクティブ3BのMoEだから手元で回る。
MiMo-V2.5は通常版でも310B、アクティブ15B。
Qwen3.6-35B-A3Bの約9倍の総パラメータで、アクティブ計算量も5倍。
同じ「MoEだから軽い」と言っても、土台の桁が違う。
MLXについては、現時点でMiMo-V2.5のMLX変換済みモデルやmlx-lm側の明示対応を確認できなかった。
MiMoはcustom_code付きで、ハイブリッド注意機構、FP8重み、MTP、オムニモーダル側のエンコーダなどが絡む。
Qwen系のようにUnslothがすぐMLX 4bitを出してくれるモデルとは事情が違う。
一方で、llama.cppにはMiMo V2.5対応PRが出ている。
PRの説明では、MiMo V2.5とProのテキスト推論対応を追加し、非Proの音声・画像コンポーネントは対象外。
FP8 safetensorsのGGUF変換、TP-aware sharding、fused attention_qkvの扱いも修正対象になっている。
ただし、このPRは4月29日時点で未マージ。
コメントを見ると通常版の変換・量子化は進んでいるが、Pro版は変換でまだ失敗している。
Macで触れる現実的な入口は、PRのマージとテキスト単体GGUF量子化の安定を待ってからになりそうだ。
ROCmは公式ルートよりllama.cppルートが現実的
ROCmについては、LLM-jp-4-32B-A3BをROCm + Strix Haloで回したときの感触が近い。
EVO-X2のRadeon 8060Sは、llama.cppのROCmバックエンドなら32B-A3Bクラスを60 tok/s前後で回せた。
ただしモデルはQ5_K_Mで24.4GB、コンテキスト65K、全部で25GB程度に収まっていた。
MiMo-V2.5は通常版でも、4bit量子化で150GB級になりうる。
EVO-X2の64GB統合メモリでは、ロード以前に容量が足りない。
Proはさらに無理で、個人向けROCm機の話から外れる。
AMD Instinctを複数枚持っているなら話は変わる。
SGLangはAMD GPU対応を持っているし、vLLMもROCmビルドがある。
ただしMiMo-V2.5向けのDay 0レシピはH200前提で、ROCmで同じ並列構成、FP8、注意カーネル、MoE通信がそのまま通るとはまだ言いにくい。
個人環境のROCmで見るなら、公式SGLang/vLLMより、llama.cppのGGUF対応が落ちてくるのを待つほうが筋がいい。
それでも対象はMiMo-V2.5通常版のテキスト推論で、Proやオムニモーダルまで期待すると厳しい。
RunPodで動かす場合
手元が無理ならクラウドGPU。
RunPodはGPU単価が比較的安く、vLLMテンプレートもある。
MiMo-V2.5のvLLMレシピは4x H200（TP4）、FP8前提。
RunPodのH200は141GB VRAM、1GPUあたり$3.59/hr。
4基借りると$14.36/hrで、2時間のお試しなら約$29、1日回しても$115ぐらい。
H200の4GPU Podが空いていない場合の代替候補。
| 構成 | 合計VRAM | 時間単価 | 備考 |
|---|---|---|---|
| 4x H200 | 564GB | ~$14/hr | 公式レシピ通り |
| 4x H100 NVL | 376GB | ~$10/hr | FP8で310GB、KVキャッシュ余裕なし |
| 8x H100 SXM | 640GB | ~$22/hr | SGLangのtp-size 8対応、割高 |
4x H100 NVLは合計376GBで、FP8ウェイト310GBを載せるとKVキャッシュに66GBしか残らない。
1Mコンテキストは到底無理だが、短いプロンプトで動作確認する程度なら入るかもしれない。
ただしレシピの検証環境がH200なので、H100 NVLでFP8カーネルやMoEルーティングがそのまま通る保証はない。
Proは1Tパラメータ、FP8でも1TB級。
8x H200（合計1128GB）でもギリギリで、個人がRunPodで気軽に試す対象ではない。
注意点として、stable版vLLMはまだMiMo-V2.5をサポートしていない。
公式レシピでは専用Dockerイメージ vllm/vllm-openai:mimov25-cu129 を使う。
RunPodのPodはカスタムDockerイメージを指定できるので、このイメージを直接入れればいい。
310B FP8のウェイトはHugging Faceからのダウンロードに数十分かかる。
Pod起動後すぐ推論できるわけではないので、初回はダウンロード待ちの時間も課金に入る。
「一回触ってみたい」「API経由じゃなくて自分の環境で動かしたい」程度なら、4x H200を数時間借りるのが一番手っ取り早い。
Google Cloudで借りたほうが安いか
RunPodの4x H200が$14.36/hrと書いたが、Google Cloud（GCE）のGPUインスタンスと比べるとどうか。
GCEのA3系インスタンスは最小構成が8GPUで、4GPUの選択肢がない。
ただしオンデマンドの8x H100（a3-highgpu-8g）で約$10.42/hr、合計VRAM 640GBなのでRunPodの4x H200（$14.36/hr、564GB）より安くてVRAMも多い。
| 構成 | 合計VRAM | 時間単価 | 備考 |
|---|---|---|---|
| RunPod 4x H200 | 564GB | ~$14/hr | カスタムDocker指定可、起動が早い |
| GCE 8x H100（a3-highgpu-8g） | 640GB | ~$10/hr | オンデマンド、USリージョン最安 |
| GCE 8x H100 Spot | 640GB | ~$1.6/hr | Spot、いつ落ちるかわからない |
| GCE 8x H200（a3-ultragpu-8g） | 1128GB | ~$14/hr | オンデマンド |
| GCE 8x H200 Spot | 1128GB | ~$3.2/hr | Spot |
Spotが圧倒的に安い。
8x H100 Spotなら$1.62/hr、2時間使っても$3.2。
RunPodの4x H200で2時間$29と比べると10分の1以下になる。
ただしSpotはいつプリエンプション（強制停止）されるかわからない。
推論中に落ちても困らない用途、たとえばベンチマークや短いプロンプトの試し打ちなら向いている。
長時間のエージェント実行やサービス公開には使えない。
もうひとつの壁は、A3インスタンスの入手性。
GCEのH100/H200インスタンスはクォータ申請が必要で、アカウントを作ってすぐ借りられるわけではない。
RunPodは登録してクレジット入れたら空きさえあれば即座にPodが立つ。
この「申請なしですぐ使える」差はけっこう大きい。
コスト最適化だけ見ればGCE Spotが圧勝だが、「今すぐ一回だけ触りたい」ならRunPodのほうが手っ取り早い。
数日にわたって何度も実験するならGCEのクォータを通しておく価値はある。
手元機で遊ぶ場合の代替モデル
クラウドを借りればMiMo-V2.5自体は触れる。
ただ「とりあえずローカルでオムニモーダルやMoEを試したい」程度なら、手元で動く別モデルのほうが現実的だ。
| やりたいこと | いまの候補 |
|---|---|
| M1 Max 64GBでローカルLLM | Qwen3.6-35B-A3B |
| Macで速度重視 | Qwen3.6-35B-A3BのMLX 4bit |
| ROCm + Strix HaloでMoE | LLM-jp-4-32B-A3B |
| AMDミニPCで会話用 | EVO-X2 + LM Studio |
MiMo-V2.5自体を追うなら、見る場所はだいたいここに絞れる。
| 確認先 | 見るもの |
|---|---|
| Hugging Faceコレクション | 公式モデル、更新日、ライセンス、ファイル構成 |
| vLLM MiMo-V2.5 recipe | stable対応状況、必要GPU、専用Docker |
| llama.cpp PR #22493 | GGUF変換、Mac/ROCmでの入口、Pro対応の進捗 |