MiniMax-M3.1-Flashを2-bit GGUF化、150GBローカル実行の条件

Unslothは日本時間10月26日夜、MiniMax-M3.1-Flashをローカルで動かす2-bit GGUFを公開した。投稿では150GBのメモリで実行でき、元の重みに対するtop-1一致度を91.5%保つとしている。ただし今回の新しさはモデル自体ではない。MiniMaxが10月19日に公開したモデルへ、Unslothが10月26日のv0.1.911-betaで量子化版と実行経路を加えた更新だ。

2-bitにも二つあり、「91.5%」は正答率ではない

Unslothの配布ページには、134.9GBのUD-IQ2_XXSと143.9GBのUD-Q2_K_XLがある。91.5%という集約値は後者のものだ。比較すると、1-bit版は129.4GBで約89.9%、4-bit版は249.4GBで98.0%とされる。容量差が小さい1-bitより品質を取り、4-bitからは100GB以上を削る中間案、と見ると位置づけが分かりやすい。

ここでの91.5%は、一般的なベンチマークの正答率ではない。Unslothの解説によれば、コーディング、数学、会話、ツール、多言語、推論、エージェントの7領域で、量子化前と同じ次トークンを選ぶ割合を重み付けした独自評価だ。個別の重みと完全な評価データは公開ページでは確認できない。また、MiniMaxが示す公式モデルのベンチマークを、そのまま2-bit版の性能とみなすこともできない。投稿の「45%小さい」も比較基準が明記されていないため、本稿では容量だけを比較した。

150GBは入口で、余裕のある条件ではない

同じガイドでも、要件表は2-bit版をRAMとVRAMの合計、またはユニファイドメモリ150GBとしている一方、UD-Q2_K_XLの詳細では160GB以上を推奨する。後者は16Kのテキスト文脈、同時実行1枠という条件だ。長い文脈、画像入力、DSparkによる投機的デコードには、さらにメモリが必要になる。

元モデルは約428Bの総パラメータを持つMoEで、各トークンでは約23Bを使う。それでもローカル実行時は量子化済みの重み全体をメモリへ収める必要がある。「動く計算量が23B級」だから小さなマシンで足りる、という話ではない。150GBは実用的な余白まで保証する数字ではなく、構成を検討し始める最低線に近い。

現時点では対応版llama.cppのビルドが必要

10月27日確認の手順では、llama.cppのMiniMax-M3.1対応PR #31192をビルドし、UD-Q2_K_XLの4分割ファイルをすべて取得する。画像も扱うなら、約1.74GBのmmproj-BF16.ggufが別に必要だ。対応PRが正式リリースへ入る時期は未確定で、導入手順は今後変わり得る。

Hugging Face上のGGUFにはホスト推論のInference Providerが付いていない。これはダウンロードして対応ランタイムで動かす配布物で、MiniMaxのAPI提供とは別の利用経路だ。大容量メモリをすでに持ち、ローカル管理を優先する人には具体的な選択肢が増えた。一方で、150GBという一語だけで導入を決めるより、量子化方式、文脈長、画像の有無、ランタイムのビルドまで一組で見たい。

参考資料

• Unsloth：MiniMax-M3.1-Flash ローカル実行ガイド
• unsloth/MiniMax-M3.1-Flash-GGUF
• Unsloth v0.1.911-beta
• MiniMaxAI/MiniMax-M3.1-Flash
• MiniMax M3.1 Flash 公式発表

参照したX投稿

Unsloth（@unslothai）の元投稿