MiniMax-M2.7 (229B MoE) を 2x Blackwell 96GB で回す: 平均71.9 t/s、ただし商用利用不可
MiniMax-M2.7 (229B MoE, smol-IQ3_KS) を dual RTX PRO 6000 Blackwell 96GB でローカル推論した記録。動画から llama.cpp の slot print_timing を読み起こして 10 点計測し、平均 71.9 t/s、最大 105.9 t/s、56k context までの速度劣化を確認した。性能は強いが modified-MIT による非商用制限が厳しく、benchmark only で撤収した。
結論
MiniMax-M2.7 は、2x RTX PRO 6000 Blackwell 96GB 上でピーク 105.9 t/s、平均 71.9 t/s というかなり強い初速を見せた。229B MoE をローカルでここまで軽快に動かせる時点で、エージェント用途としての実用性はかなり高い。
ただ、最終的に止まったのは性能ではなくライセンスだった。MiniMax-M2.7 は modified-MIT で、商用利用には MiniMax の事前許諾が必要になる。出力品質、ツールの挙動、サイズ感はかなり良かったが、業務や商用ワークフローにそのまま載せにくいため、今回は軽いベンチだけ取り、モデルは削除した。
完全に個人用途に閉じるなら話は別で、Claude や Codex に投げる前の雑なワンクッション、プロンプトやツール呼び出しの荒い当たりを見るテスト用途にはかなり向いていると思う。今回の検証機は dual Blackwell 96GB であり、DGX Spark や Mac Studio (128GB) での運用は未検証だが、サイズ感と挙動の印象としては、個人専用のローカル環境に置く候補としては魅力がある。
前提
今回の計測は、YouTube に上げた 14 分の無編集動画から逆算した。推論ログを別保存し忘れたため、画面右側の llama.cpp ログに出ていた slot print_timing をフレーム単位で読み起こし、10 点サンプリングしている。
検証タスクは、Zed Editor の AI Agent に WordPress 風 Django ブログの仕様を渡し、どこまで自律的に組み上げられるかを見るものだった。
動画リンク: https://www.youtube.com/watch?v=4QIc4A5Yly4
実験環境
| 項目 | 内容 |
|---|---|
| GPU | 2x NVIDIA RTX PRO 6000 Blackwell 96GB |
| CPU | AMD EPYC 9175F |
| RAM | 768GB |
| Engine | ik_llama.cpp (ubergarm fork) |
| Quantization | smol-IQ3_KS |
| Context | 262,144 tokens |
| KV buffer | CUDA0 32,768 MiB + CUDA1 30,720 MiB |
| Prompt cache | 8,192 MiB |
| Graph splits | 3 |
ベンチマーク結果
Token Generation
| フェーズ | KV cache | 速度 |
|---|---|---|
| 初期 | 約2.7k tokens | 105.9 t/s |
| 序盤平均 | 25k tokens 未満 | 77.5 t/s |
| 中盤平均 | 27k-47k tokens | 64.7 t/s |
| 終盤平均 | 54k-56k tokens | 54.3 t/s |
- 平均: 71.9 t/s
- 最大: 105.9 t/s
- 最小: 53.9 t/s
- 劣化率: 2.7k から 56.4k context で -49%
Prompt Processing
| 条件 | 速度 |
|---|---|
| Cold start (2,493 tokens) | 4,067 t/s |
| Cache hit 平均 | 911 t/s |
10 点サンプル
| KV cache | TG |
|---|---|
| 2.7k | 105.9 t/s |
| 18.3k | 79.2 t/s |
| 19.1k | 78.8 t/s |
| 21.2k | 77.1 t/s |
| 23.7k | 75.0 t/s |
| 27.2k | 71.4 t/s |
| 38.4k | 63.8 t/s |
| 46.6k | 58.9 t/s |
| 53.9k | 54.7 t/s |
| 56.4k | 53.9 t/s |
立ち上がりはかなり速いが、長いセッションではほぼ線形に落ちる。56k context 時点でもまだ実用速度ではあるものの、100k を超える長時間セッションは分割前提で考えた方が良さそうだった。
何が生成されたか
Zed Agent に WordPress 風 Django ブログ/CMS の仕様を渡したところ、約 14 分の無編集セッションで以下を生成した。
- Django config 一式
accounts,content,core,media,comments,navigation,seo,taxonomyの 8 app- 各 app の model, admin, app config
- テスト群
- Gitea issue 作成 API 統合
- 50 以上のファイル
セッション中に edit_file の path prefix バグへ自力で気づいて修正しており、単にコードを書くだけでなく、ツールの癖に合わせて立ち回る力も見えた。
進行スクリーンショット
MiniMax-2.5 と比べてどうだったか
MiniMax-2.5 の検証記事では、単体 96GB GPU に Expert Offload を組み合わせて 34-37 t/s を安定維持できた。あちらは長めのコンテキストでも TG が比較的安定していて、Web 生成タスクにそのまま使える実感があった。
今回の M2.7 は厳密な横比較ではない。M2.5 は single GPU + Expert Offload、M2.7 は dual Blackwell + smol-IQ3_KS の full local inference に近い構成で、前提条件がかなり違う。それでも使っていて感じたのは、ツール仕様への順応や出力内容は M2.5 でもかなり良かった一方で、M2.7 にはもう一段余裕があることだった。 m2.5の検証より複雑な仕様にも関わらず、tokenUsageが半分位だった。(今回は66kほど, m2.5の生成には122kほどだった記憶)
M2.5 でも十分に良かったので M2.7 にはかなり期待していたし、実際にサイズ感、ツール仕様、出力内容のどれも申し分なかった。ただ、最終的には性能差よりライセンスで詰んでいるので検証もするつもりはなかったけど、communityのコメント欄も荒れていて、もしかしたらワンチャンスあるかなと期待してベンチだけでもといったあわよくばである。
ライセンスはmodified-mitだけどM2.5とM2.7では全然違うので注意
MiniMax-M2.7 は modified-MIT で、商用利用が自由ではない。 一方で、M2.5 の modified-MIT は少なくとも 2026 年 3 月時点で自分が読んだ範囲では商用利用を妨げる形ではなかった。その差があるので、商用につながる運用を考えるなら、現実的には M2.5 側を fine-tuning するなどして自分のシステムに寄せていく方がまだ筋が良い。
- ベンチマーク用、学習用、個人用途のローカル検証には面白い
- 業務フロー、顧客案件、社内の商用開発ループにはそのまま入れにくい
- 「とりあえず常用ローカルモデルにする」という判断ができない
性能面の評価は高いが、導入可否を決める軸がライセンスになってしまう。生成物や副産物まで含めてどこまで影響が及ぶのかを読み切れず、その不確実さ込みで常用候補にはならない。
計測方法
今回は最初から本番系に組み込む前提ではなかったので、検証自体かなりラフに進めてしまい、推論ログも取り忘れていた。
後から動画の該当箇所だけを Claude に渡し、フレームを指定しながら PP/TG の値を拾って集計したため、数値には読み取り誤差が入っている可能性がある。動画の出力されたものが正としてください。