MiniMax M3.1 Flash GGUFのローカル実行:必要メモリとAPI費用
Unsloth Q2なら160 GiB、Q4なら256 GiBを目安にメモリを確保します。MiniMax対応のllama.cppをビルドし、16Kコンテキストのサーバーを起動します。APIの応答とOpenCodeのファイル読み取りを確認し、GGUF、Apple Silicon向けMLX、DGX Spark向けEXL3、AMDの構成を比較します。トークンの一致率とコーディングの成功率を区別し、ローカル実行とAPIの費用を試算します。
目次

MiniMax M3.1 Flash GGUFをローカルで動かすなら、まずUD-Q2_K_XLと160 GiB+のメモリを目安にしてください。**256 GiB+**を確保できるマシンでは、UD-Q4_K_XLを優先します。たまに使うコーディング用途でハードウェアを新しく買うなら、先にAPIを試す費用を計算してください。
これらは2026-11-06時点のUnslothのメモリ見積もりで、16Kのテキストコンテキストとサーバースロット1つを前提としています。メモリはRAMとVRAMに分けて使用するか、ユニファイドメモリを利用できます。以下では、ローカルAPIサーバーを起動し、OpenCode 1に接続するまでの手順を示します。
M3.1 Flashにはどれだけのメモリが必要ですか?
量子化した重み全体に加え、実行時に使う追加のメモリも確保します。MiniMaxの元のモデルカードによると、パラメータ数は約428Bで、各トークンの計算では23Bが有効になります。有効なパラメータが少ないと計算量は減りますが、読み込む重みが23Bのモデルになるわけではありません。
Unslothは、以下の容量とメモリの目安を公開しています。ダウンロード容量は10進数のGB、メモリ容量はGiBです。
| 量子化形式 | ダウンロード容量 | 重みの容量 | メモリの目安 |
|---|---|---|---|
UD-IQ1_M | 129.4 GB | 120.5 GiB | メモリ制約が厳しい場合の実験用。下記を参照 |
UD-Q2_K_XL | 143.9 GB | 134.0 GiB | 160 GiB+ |
UD-IQ3_XXS | 160.0 GB | 149.1 GiB | 176 GiB+ |
UD-IQ3_S | 175.5 GB | 163.4 GiB | 192 GiB+ |
UD-Q3_K_XL | 194.0 GB | 180.6 GiB | 208 GiB+ |
UD-Q4_K_XL | 249.4 GB | 232.3 GiB | 256 GiB+ |
UD-Q8_K_XL | 259.1 GB | 241.3 GiB | 272 GiB+ |
Unslothは、重み以外に約20–32 GiBをキー・バリューキャッシュ、実行環境、OS用として見込んでいます。このキャッシュには、現在のコンテキストに対するアテンションの状態を保存します。コンテキストやスロットを増やす場合、画像処理や投機的デコードを使う場合は、さらにメモリが必要です。
128 GiBのマシンでは、1-bitの重みだけで空き容量が7.5 GiBまで減ります。これは、上記の追加メモリの目安を下回ります。Q2では、余裕を見込んだUnslothの160 GiBという推奨値を使ってください。
RAMとVRAMの合計は、重みを配置できる容量の見積もりです。両者を自由に置き換えられる、単一のメモリ領域ではありません。CPUに処理を移す場合は、移動した重みを保持できるだけのホストRAMを残してください。選んだモデルをダウンロードするためのディスク空き容量も必要です。
モデルが公表する1Mのコンテキスト長は、このメモリ見積もりで1Mを利用できるという意味ではありません。最初は16Kに設定し、メモリ使用量を確認してから増やしてください。
どの量子化形式を選ぶべきですか?
まずQ2で、手持ちのメモリにモデルが収まるか確認してください。メモリに余裕があれば、実際のコーディング作業でQ4と比較します。Q4がメモリ容量を超える場合は、3-bitの形式を選びます。
Unslothの総合値とカテゴリー別の値は、集計対象が異なります。
| Unslothが報告するtop-1一致率 | UD-Q2_K_XL | UD-Q4_K_XL |
|---|---|---|
| 加重集計した総合値 | 91.5% | 98.0% |
| コーディング | 91.2% | 97.6% |
| 一般的なチャット | 88.5% | 97.3% |
| 数学 | 95.7% | 99.0% |
総合値は、7つのカテゴリーに重みを付けて集計したものです。チャットと数学の行は、それぞれのカテゴリーだけを示します。Q2に91.5%と88.5%の両方の値があるのは、この集計範囲の違いによります。
Top-1一致率は、量子化モデルと参照モデルが同じ最上位トークンを選ぶかどうかを測ります。コーディング作業の成功率ではありません。コーディングの値が91.2%でも、リポジトリへの変更の91.2%がテストに合格するという意味ではありません。
1-bitの総合一致率は約89.9%ですが、メモリ制約が厳しい場合の実験用と考えてください。どの量子化形式でも、実用に使う前にファイル編集、ツールの引数、複数段階の動作を確認します。
Q8はQ4より9.7 GB大きくなります。Unslothは、公開済みの重みを損失なく変換し、NVFP4とBF16の混在形式を保持したものと説明しています。そのため、「8-bit」という名前は、すべてのテンソルが同じ精度で保存されていることを示しません。
ハードウェアに合う実行環境はどれですか?
使用する実行環境に対応した重みと手順を選んでください。EXL3でメモリに収まったという結果だけでは、対応するGGUFも収まるとは判断できません。
以下は、2026-11-06時点の文書で確認された選択肢です。
| ハードウェア | 検討する構成 | 実用上の条件 |
|---|---|---|
| Apple Silicon | MLX-communityのoQ3eモデルとoMLX | 重みの合計は196.152 GB / 182.681 GiBで、ドラフトモデルと画像処理の構成要素も含みます。実行環境とコンテキスト用のメモリを別途加えてください。 |
| DGX Spark 1台 | vcruz305のSAGE-EXL3手順 | 128 GBのGB10システム向けです。構成要素のバージョンが固定され、重みへのアクセスには許可が必要です。テキストのみを処理し、デコードストリームは1つです。 |
| AMD Instinct | AMDのQuark MXFP4モデル | 文書に記載された構成はMI350/MI355、Linux、ROCm 7.2.3です。4つのGPUを使うテンソル並列の例があり、一般的なRadeon向け手順ではありません。 |
| RTX 3090を4枚 | MiniMaxの11月1日のコミュニティ投稿で紹介された独自の推論実装 | MiniMaxは、@superaleshaの手法を、量子化した重み、エキスパートのキャッシュ、システムRAMを組み合わせたものと説明しています。この紹介は、他の構成で同じ性能が出ることを保証しません。 |
初めてGGUFを導入する場合は、以下のllama.cppの手順を使ってください。商用運用の前には、MiniMax Community Licenseの出典表示や通知の条件も確認します。
llama.cppをビルドして16Kのサーバーを起動する
Unslothが案内するMiniMax対応ブランチを使います。2026-11-06時点で、llama.cppのPR #31192はまだ開いた状態で、マージされていませんでした。この例では、確認時点のブランチ先端のコミットに固定しています。
ビルドとダウンロード
UbuntuまたはWSL上のBashを使い、NVIDIA CUDA toolkitを事前にインストールしてください。残りの必要なパッケージを入れ、サーバーをビルドします。
sudo apt-get update
sudo apt-get install -y build-essential cmake git libssl-dev python3-venv curl jq
git clone https://github.com/ggml-org/llama.cpp
git -C llama.cpp fetch origin pull/31192/head:minimax-m31
git -C llama.cpp checkout --detach 6b95a9908d2c7b242817a447708aec38e937e2c0
cmake llama.cpp -B llama.cpp/build \
-DCMAKE_BUILD_TYPE=Release \
-DBUILD_SHARED_LIBS=OFF \
-DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --target llama-server
macOSでは、Xcodeのコマンドラインツール、CMake、Python、jqをインストールし、apt-getのコマンドは省きます。-DGGML_CUDA=ONを-DGGML_CUDA=OFFに変更してください。ビルド文書によると、macOSではMetalが既定で有効になります。
Hugging Face CLIで、Q2の分割ファイルを4つすべてダウンロードします。
python3 -m venv .venv-m31
source .venv-m31/bin/activate
python -m pip install -U huggingface_hub
hf download unsloth/MiniMax-M3.1-Flash-GGUF \
--local-dir unsloth/MiniMax-M3.1-Flash-GGUF \
--include "UD-Q2_K_XL/*"
分割ファイルは同じ場所にまとめておきます。最初のファイルを指定すると、サーバーが全体を読み込みます。
起動と動作確認
スロットは1つ、コンテキストは明示的に16Kに設定し、通常のテキストデコードから始めます。
./llama.cpp/build/bin/llama-server \
--model unsloth/MiniMax-M3.1-Flash-GGUF/UD-Q2_K_XL/MiniMax-M3.1-Flash-UD-Q2_K_XL-00001-of-00004.gguf \
--alias m31-local \
--ctx-size 16384 \
--parallel 1 \
--n-gpu-layers auto \
--jinja \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 0 \
--min-p 0.0 \
--chat-template-kwargs '{"reasoning_effort":"high"}' \
--host 127.0.0.1 \
--port 8080
この疎アテンションの実装では、PRがJinja、Flash Attention、スロット1つを指定しています。llama-serverのオプションでは、GPUへのレイヤー配置を自動調整できます。
このコマンドは、画像用のプロジェクターやDSparkのドラフトモデルを追加しません。APIキーも設定しておらず、ローカルのループバックアドレスだけで接続を受け付けます。
VRAMの確保に失敗する場合は、GPUに置くレイヤー数を減らし、ホストRAMの空き容量を確認してください。総メモリ容量が不足する場合は、より小さい量子化形式を選ぶか、メモリを増やします。CPUへのオフロードを使っても、重み全体を保持するための容量は必要です。
別のBashターミナルを開き、サーバーの準備ができたか確認します。
curl -sS -i http://127.0.0.1:8080/health
HTTP 200と{"status":"ok"}が返ったら、次に進みます。HTTP 503とLoading modelが返る場合は、まだ初期化中です。
続いて、利用できるモデルを確認し、応答を要求します。
curl -sS http://127.0.0.1:8080/v1/models | jq '.data[].id'
curl -sS http://127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
--data '{
"model": "m31-local",
"messages": [
{"role": "user", "content": "Reply with LOCAL_OK."}
],
"reasoning_effort": "low",
"max_tokens": 4096,
"stream": false
}' | jq '{message: .choices[0].message, finish_reason: .choices[0].finish_reason}'
モデル一覧にm31-localがあり、message.contentに指定した回答が含まれることを確認してください。この動作確認では、リクエストの推論レベルlowが、サーバーの既定値highを上書きします。
finish_reasonがlengthの場合は、出力上限を使い切っています。最終テキストがないことをモデルの読み込み失敗と判断する前に、総コンテキストの範囲内で出力上限を増やしてください。
OpenCode 1に接続してツール呼び出しを確認する
OpenCodeの文書にあるカスタムプロバイダー設定で、コーディング用クライアントを接続します。ファイル操作のツールはOpenCodeが実行し、モデルの応答はllama-serverが生成します。
この設定はOpenCode 1の文書に基づきます。OpenCode 1とOpenCode 2は、同じopencodeコマンドを使います。V2をすでに使っている場合は、V1用に別の環境を用意してください。
V1を新しくインストールする場合は、Node.jsとnpmが利用できる状態で次を実行します。
npm install -g opencode-ai
opencode --version
プロジェクトのルートにあるopencode.jsonへ、以下の設定を統合します。既存の設定がある場合は、その内容と組み合わせてください。これは、公式のllama.cppプロバイダーの例に沿った設定です。
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"local": {
"npm": "@ai-sdk/openai-compatible",
"name": "MiniMax local",
"options": {
"baseURL": "http://127.0.0.1:8080/v1"
},
"models": {
"m31-local": {
"name": "MiniMax M3.1 Flash Q2",
"limit": {
"context": 16384,
"output": 4096
}
}
}
}
}
}
このローカル構成では、仮のAPIキーを入れる必要はありません。コンテキスト上限は、起動中のサーバーに合わせています。出力上限は、この例で選んだ応答用の枠であり、モデル自体の最大値ではありません。
package.jsonを含むNodeプロジェクトで、次のコマンドを実行します。ファイル用ツールでpackage.jsonを読み、scripts.testの値、または項目がないことを答えさせる指示です。
opencode run --model local/m31-local \
"Read package.json with a file tool. Report scripts.test, or say it is missing. Do not edit files or run commands."
実際にファイルを読むツールの処理が発生したことを確認し、回答をファイルの内容と照合してください。モデルが「ファイルを読んだ」と述べるだけでは、確認になりません。
クライアントが接続できない場合は、ベースURLの/v1、モデルの別名、サーバーが起動しているかを確認します。テキスト応答は動くのにツールが失敗する場合は、--jinjaを確認してください。リポジトリの編集に進む前に、この限定した確認を繰り返します。
最初のセッションは小さく保ってください。ツールの定義がコンテキストを多く使う場合は、MCPのコンテキスト費用を測るガイドの方法で確認します。その後で、サーバーのコンテキスト長を増やすか判断してください。
ローカル実行よりAPIを選ぶのはどんな場合ですか?
たまに使うためにハードウェアを新しく買う必要があるなら、APIから始めてください。十分な機材をすでに持っている場合や、モデルをローカルで動かす必要がある場合は、ローカル導入を検討します。
2026-11-06時点のMiniMaxの標準API料金は、以下のとおりです。
| 課金項目 | 1 millionトークン当たりのUSD |
|---|---|
| キャッシュされていない入力 | $0.15 |
| キャッシュ済み入力の読み取り | $0.015 |
| 出力 | $0.60 |
これらはAPIの利用量に応じて、アカウント残高から差し引かれる料金です。MiniMaxは、Flashのトークン単価を一律と説明しています。キャッシュの料金計算式では、新規入力、キャッシュヒット、出力を課金対象とし、キャッシュ書き込みの項目は別途加えません。
月間の処理量を、未キャッシュの入力20 millionトークン、課金対象の出力2 millionトークンと仮定すると、次の計算になります。
API token charge = 20 × $0.15 + 2 × $0.60
= $4.20 per month
この例はテキストのみのリクエストを想定し、キャッシュヒットや有料のサーバーツールは含みません。税金や決済時の手数料も除外しています。
比較用に、ローカル実行の予算を次のように仮定します。
Hardware allocation = $3,000 ÷ 36 months
= $83.33 per month
Active electricity = 0.15 kW × 60 hours × $0.20/kWh
= $1.80 per month
Local subtotal = $85.13 per month
ローカル側の数値は、すべて計算用の仮定です。これは確認済みのマシンの見積価格ではなく、そのマシンが60時間で同じ処理量をこなせるという証拠でもありません。購入を判断する前に、待機時の電力、セットアップ、保守、必要な機材の増強費も加えてください。
実際の実行結果を比べるときは、推論レベルを揃えます。MiniMax APIの既定値はmaxですが、このローカルサーバーはhighです。課金対象の出力トークン数を使い、完了したコーディング作業1件当たりの費用を評価してください。再試行や、失敗したツールの処理も費用に含めます。
2026-11-06時点では、BetterTokenにも従量課金で利用できるMiniMax-M3.1-Flashが掲載されています。文書に記載されたOpenAI互換のベースURLはhttps://www.bettertoken.ai/v1です。この経路の費用を計算する場合は、現在の料金を使ってください。
ハードウェアをすでに持っている場合は、例の購入費の配分を、実際に増える費用へ置き換えます。そのうえで、代表的な作業を測定してください。ローカル導入が役立つのは、モデルがメモリに収まり、許容できる時間で採用可能な結果を得られる場合です。