MiMo V2.5 Proの単一・dual GPU計測
MiMo V2.5 Pro IQ2_SをBlackwell 96GB×1/×2で動かし、decode 12.4–12.5/16.5–16.6 tok/sを測りました。LLM導入に向け、expert配置とMTP・QKVの未対応箇所を確認します。
Xiaomi MiMo V2.5 Pro(1.02T total / 42B active)の IQ2_S GGUF を RTX PRO 6000 Blackwell Max-Q で動かしました。マルチエージェントの常駐 orchestrator 候補として、速度と tool use を確認しています。
動画リンク: https://www.youtube.com/watch?v=tviNguY-HRE
decode は GPU 1枚の12.4–12.5 tok/sから、2枚の16.5 tok/s前後に約33%増えました。2枚使う割に改善が小さく、バッチのデータセット生成用として検討しています。モデルは MIT ライセンスです。
今回確認した点です。
- decode は single GPU で 12.4-12.5 tok/s、dual GPU で 16.5-16.6 tok/s
- head / tail 寄せの配置では伸びが弱かったため、今回は expert tensor を比較的バランス良く配置した
- llama.cpp の MTP support は merge 済みだが、MiMo の
mimo2MTP tensor はこの実行時点では使われていない - ik_llama.cpp は MiMo 2.5 対応自体はあるが、fused QKV layout を読めず、この量子化では未検証になった
環境
| 項目 | 内容 |
|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q 96GB x 2 |
| CPU | AMD EPYC 9175F 16-Core, SMT disabled |
| RAM | 約 755GB DDR5 ECC, 6000 MT/s |
| Runtime | ggml-org/llama.cpp:full-cuda13 |
| Blackwell | native FP4 enabled |
使用したのは AesSedai/MiMo-V2.5-Pro-GGUF の IQ2_S です。quant table は297.45 GiB、2.50 BPWです。XiaomiMiMo/MiMo-V2.5-Pro の model card は MIT、1.02T total / 42B active、hybrid attention、3-layer MTP、最大1M context としています。
| 項目 | 内容 |
|---|---|
| Model | MiMo V2.5 Pro |
| Architecture | mimo2 |
| Parameters | 1.02T total / 42B active |
| Quantization | IQ2_S |
| GGUF size | 297.45 GiB |
| Layer layout | blk.0-blk.69 active layers, blk.70-blk.72 MTP heads |
起動コマンド
GPU 1枚では GPU 0のみを使い、一部 expert を CUDA0に置きました。
podman run --rm \
--device nvidia.com/gpu=0 \
-p 8000:8000 \
--shm-size 8g \
--cap-add=SYS_NICE \
-v /mnt/data/models/models--AesSedai--MiMo-V2.5-Pro-GGUF:/models:ro,Z \
ggml-org/llama.cpp:full-cuda13 \
--server \
-m /models/snapshots/a8205a14c95fd13018a7776bf0778d1edb6ba2be/IQ2_S/MiMo-V2.5-Pro-IQ2_S-00001-of-00008.gguf \
--ctx-size 49152 \
-fa on -fit on \
-ngl 99 \
-ctk q8_0 -ctv q8_0 \
-ot "blk\.([0-3]|1[6-7]|2[6-7]|3[6-7]|4[6-7]|5[5-7]|6[6-9])\.ffn_.*_exps.*=CUDA0,exps=CPU" \
--no-mmap \
--parallel 1 \
--threads 15 \
--threads-batch 27 \
--batch-size 12288 \
--ubatch-size 6144 \
--jinja \
--kv-unified \
--host 0.0.0.0 --port 8000 \
--alias grandpa
2枚では CUDA0 / CUDA1に expert を分散しました。非 expert は -ngl 99 で GPU に載せ、Flash Attention を使います。
podman run --rm \
--device nvidia.com/gpu=all \
-p 8000:8000 \
--shm-size 8g \
--cap-add=SYS_NICE \
-v /mnt/data/models/models--AesSedai--MiMo-V2.5-Pro-GGUF:/models:ro,Z \
ggml-org/llama.cpp:full-cuda13 \
--server \
-m /models/snapshots/a8205a14c95fd13018a7776bf0778d1edb6ba2be/IQ2_S/MiMo-V2.5-Pro-IQ2_S-00001-of-00008.gguf \
--ctx-size 49152 \
-fa on -fit on \
-ngl 99 \
-ctk q8_0 -ctv q8_0 \
-ot "blk\.([0-3]|1[6-7]|2[6-7]|3[6-7]|4[6-7]|5[5-7]|6[6-9])\.ffn_.*_exps.*=CUDA0,blk\.([4-6]|1[8-9]|2[8-9]|3[8-9]|4[8-9]|5[8-9]|6[2-5])\.ffn_.*_exps.*=CUDA1,exps=CPU" \
--no-mmap \
--parallel 1 \
--threads 15 \
--threads-batch 27 \
--batch-size 12288 \
--ubatch-size 6144 \
--jinja \
--kv-unified \
--host 0.0.0.0 --port 8000 \
--alias grandpa
Expert Tensor 配置
| 配置先 | layer |
|---|---|
| CUDA0 | blk.0-blk.3, blk.16-blk.17, blk.26-blk.27, blk.36-blk.37, blk.46-blk.47, blk.55-blk.57, blk.66-blk.69 |
| CUDA1 | blk.4-blk.6, blk.18-blk.19, blk.28-blk.29, blk.38-blk.39, blk.48-blk.49, blk.58-blk.59, blk.62-blk.65 |
| CPU | 残りの expert tensor |
1枚では CUDA0が約18層、CPUが約52層の expert です。2枚では CUDA0約18層、CUDA1約17層、CPU約35層になりました。
297.45 GiBは192GB VRAMに入りません。attention / norm / embedding は GPUに置き、expert のみ -ot regexで分けました。細かい layer 配置の探索は行っていません。
ベンチマーク結果
計測値です。
Single GPU (1x RTX PRO 6000):
prompt eval time = 27716.99 ms / 15594 tokens ( 1.78 ms per token, 562.62 tokens per second)
eval time = 13512.61 ms / 169 tokens ( 79.96 ms per token, 12.51 tokens per second)
prompt eval time = 4185.57 ms / 136 tokens ( 30.78 ms per token, 32.49 tokens per second)
eval time = 164812.58 ms / 2048 tokens ( 80.47 ms per token, 12.43 tokens per second)
Dual GPU (2x RTX PRO 6000):
prompt eval time = 24150.56 ms / 15594 tokens ( 1.55 ms per token, 645.70 tokens per second)
eval time = 7892.13 ms / 131 tokens ( 60.25 ms per token, 16.60 tokens per second)
prompt eval time = 3109.48 ms / 160 tokens ( 19.43 ms per token, 51.46 tokens per second)
eval time = 123901.10 ms / 2048 tokens ( 60.50 ms per token, 16.53 tokens per second)
| 指標 | Single GPU | Dual GPU | 改善 |
|---|---|---|---|
| Long prefill | 562.62 tok/s | 645.70 tok/s | +14.8% |
| Short prefill | 32.49 tok/s | 51.46 tok/s | +58.4% |
| Decode short | 12.51 tok/s | 16.60 tok/s | +32.7% |
| Decode long | 12.43 tok/s | 16.53 tok/s | +33.0% |
decode は12.4–12.5から16.5–16.6 tok/sに約33%増えました。GPU側の expert が増え、CPU計算と転送の割合が減ったためと考えています。
2枚でも約35層の expert は CPUに残ります。選ばれた active expert を CPUで計算し、GPUと同期する経路が残ることが、16.5 tok/s付近の制約と考えています。
prefill は long で+14.8%、short で+58.4%でした。短い入力ほどGPUの並列度が効いた可能性がありますが、原因を分離した測定ではありません。
MTP はまだ使えていない
3-layer MTP heads の blk.70–blk.72 は GGUF にありますが、今回 llama.cpp は使いませんでした。
W model has unused tensor blk.70.attn_output.weight (size = 106954752 bytes) -- ignoring
W model has unused tensor blk.70.attn_norm.weight (size = 24576 bytes) -- ignoring
W model has unused tensor blk.70.attn_sinks.weight (size = 512 bytes) -- ignoring
W model has unused tensor blk.70.ffn_norm.weight (size = 24576 bytes) -- ignoring
W model has unused tensor blk.70.ffn_gate.weight (size = 106954752 bytes) -- ignoring
W model has unused tensor blk.70.ffn_down.weight (size = 106954752 bytes) -- ignoring
W model has unused tensor blk.70.ffn_up.weight (size = 106954752 bytes) -- ignoring
W model has unused tensor blk.70.nextn.eh_proj.weight (size = 80216064 bytes) -- ignoring
W model has unused tensor blk.70.nextn.enorm.weight (size = 24576 bytes) -- ignoring
W model has unused tensor blk.70.nextn.hnorm.weight (size = 24576 bytes) -- ignoring
W model has unused tensor blk.70.layer_output_norm.weight (size = 24576 bytes) -- ignoring
... (same for blk.71, blk.72)
llama.cpp PR #22673 は2026-05-16に masterへ mergeされ、例では --spec-type draft-mtp と --spec-draft-n-max を使います。ただし今回の mimo2 MTP tensor は認識されず、読み込み時に破棄されました。
Xiaomi の model card は MTP の output speed 3xを示しています。今回は未使用なので、その改善は測れていません。仮に+50%なら dualで24 tok/s台となり、使用中の orchestrator 23–40 tok/sに近づきます。対応後に再測定する予定です。React SPA Spec の初動は動画で確認できます。
ik_llama.cpp では fused QKV で止まる
MiMo 2.5 support が mergeされた ik_llama.cpp でも試しましたが、この GGUF は読み込めませんでした。TG改善を期待した検証です。
エラーは fused QKV layout に関するものでした。
Image: registry.home.arpa/ik_llama:latest (main branch with #1723 "Support Mimo-2.5")
Memory required for model tensors + cache: 314076 MiB
Memory available on all devices - compute: 92720 MiB
llm_load_tensors: ggml ctx size = 0.66 MiB
llama_model_load: error loading model: check_tensor_dims: tensor 'blk.0.attn_q.weight' not found
llama_model_load_from_file: failed to load model
llama_init_from_gpt_params: error: failed to load model
ik_llama.cpp issue #1769 では fused QKV が原因とされています。Xiaomi の safetensors と ggml-org系変換は attn_qkv を使います。ik_llama.cpp は attn_q / attn_k / attn_v を期待し、blk.0.attn_q.weight が見つかりません。取得前に quant の QKV layout を確認する必要があります。
separate Q/K/V の GGUF か、load時の un-merge 対応があれば再検証できます。今回動いたのは llama.cpp mainline の hybrid です。
コード生成タスクでの挙動
React SPA Spec の scaffold に美容室予約 SPA を作るタスクも試しました。完走前に停止したため、スコアはありません。
初動では次の tool use を確認しました。
package.json、vite.config.ts、tsconfig.json、src/を順に見てから着手したnpm installで依存関係を整えてから実装に入った- ディレクトリを作ってからファイルを書く順序を守った
- TypeScript の discriminated union で予約ステータスを設計した
str_replaceで既存ファイルを差分編集し、丸ごと壊さなかったpackage.jsonがnpm install後に変わったことを検知して読み直した
terminal、既存ファイル、依存関係の操作を確認できました。LLM導入で開発支援を行う候補として、長時間の完走と出力品質は次に検証する必要があります。
ライセンスまわり
MiMo は MIT の1T級 MoE で、agentic workloadを想定しています。記事時点の候補は200B超の DeepSeek V4、GLM-5.1、MiMoです。Kimi-K2.6などでは商用提供時に売上に応じた追加条件の確認が必要な場合があり、候補ごとのライセンスを区別しています。
今回確認できた範囲
GPU 1枚で約12 tok/s、2枚で約16.5 tok/sを確認しました。MTPの実行と、ik_llama.cpp での読み込みは未検証のままです。
Claude / Codex を使ってデバッグや実装を進めています。将来の課金と利用制限を考え、ローカルの代替基盤を年内に仕上げたいと考えています。token単位課金に寄るという見方は予測です。
