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のローカル実行:必要メモリと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_M129.4 GB120.5 GiBメモリ制約が厳しい場合の実験用。下記を参照
UD-Q2_K_XL143.9 GB134.0 GiB160 GiB+
UD-IQ3_XXS160.0 GB149.1 GiB176 GiB+
UD-IQ3_S175.5 GB163.4 GiB192 GiB+
UD-Q3_K_XL194.0 GB180.6 GiB208 GiB+
UD-Q4_K_XL249.4 GB232.3 GiB256 GiB+
UD-Q8_K_XL259.1 GB241.3 GiB272 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_XLUD-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 SiliconMLX-communityのoQ3eモデルとoMLX重みの合計は196.152 GB / 182.681 GiBで、ドラフトモデルと画像処理の構成要素も含みます。実行環境とコンテキスト用のメモリを別途加えてください。
DGX Spark 1台vcruz305のSAGE-EXL3手順128 GBのGB10システム向けです。構成要素のバージョンが固定され、重みへのアクセスには許可が必要です。テキストのみを処理し、デコードストリームは1つです。
AMD InstinctAMDの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です。この経路の費用を計算する場合は、現在の料金を使ってください。

ハードウェアをすでに持っている場合は、例の購入費の配分を、実際に増える費用へ置き換えます。そのうえで、代表的な作業を測定してください。ローカル導入が役立つのは、モデルがメモリに収まり、許容できる時間で採用可能な結果を得られる場合です。

LLM ワークフローを最適化しませんか?

単一 API でモデルを接続し、キーと AI コストを管理できます。

無料で始める