MiniMax-2.5 230B MoEをIQ5K量子化でBlackwell GPU上で実行：生成速度35 tok/s・長コンテキスト65kの検証結果

MiniMax-2.5 230B MoEをIQ5K量子化で、NVIDIA RTX PRO 6000 Blackwell上で実行。Prompt評価時の速度ブレ（125-314 tok/s）、生成時の安定性（35-37 tok/s），KV キャッシュ動作，expert CPU配置の影響を詳細検証。

info

技術メモとして残していた ObsidianノートにAIの要約を利用しています。

背景

MiniMax-2.5 230B MoEは，256個の専門家を持つ混合専門家モデルで，特に長コンテキスト処理と知識集約型タスク向けに設計されている。ローカル環境での運用を検討する際，GPUメモリ制約と生成速度のバランスを取るため，IQ5K量子化でのベンチマークを実施した。

RTX PRO 6000 Blackwell Max-Q（96GB VRAM）環境で，65,536トークンの長コンテキスト設定下での実行可能性と性能を定量的に評価することが目的。

目的

MiniMax-2.5 230B MoE IQ5K量子化の実行可能性をBlackwell環境で確認
Prompt評価（prefill）と生成（decode）の速度を分離して計測
expert CPU配置設定（-ot exps=CPU）の影響度を把握
65,536トークンのKV キャッシュ動作とprompt cacheの安定性を検証

実験環境

項目	仕様
GPU	NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition（VRAM: 96GB, Compute Capability: 12.0）
CPU	Intel（実際はAMD EPYC相当，AVX/AVX2/AVX512対応）
メモリ	768GB DDR5
モデル	MiniMax-2.5（アーキテクチャ: minimax-m2）, 230B.A10B（MoE）
量子化	IQ5_K（表示上5.5 bits per weight, モデルサイズ: 157.77 GiB）
コンテキスト長	65,536トークン
Runtime	llama.cpp（commit: 1cb7e1bf, build: 4192）

実施内容

起動コマンド

  podman run --rm -it \
  --device nvidia.com/gpu=all \
  -p 8081:8080 \
  --shm-size 16g \
  --cap-add=SYS_NICE \
  -v "$MO":/models:ro,Z \
  $IMG \
  --host 0.0.0.0 --port 8080 \
  -m "$MODEL" \
  --no-mmap --jinja \
  -c 65536 \
  --threads 13 --threads-batch 25 \
  -b 2048 -ub 2048 \
  -ngl 99 \
  -ot exps=CPU \
  -ctk f16 -ctv f16 \
  --warmup-batch \
  -fa on

主要パラメータ説明

-c 65536: コンテキスト長を65,536トークンに設定
–threads 13: CPU処理用スレッド数
-ngl 99: GPU層を99層offload（ほぼ全層をGPUで計算）
-ot exps=CPU: MoE expertの重みをCPU配置に強制
-fa on: Flash Attention有効化
–no-mmap: メモリマップなしで直接ロード

ベンチマーク実行

8回のリクエストサイクルで，プロンプト長・生成長を変動させて計測。HTTP /chat/completions エンドポイント経由でのレスポンスタイムを記録。

結果

メモリ配置（実測値）

メモリ領域	サイズ
CPU buffer	157,356 MiB（IQ5K重み本体）
CUDA0 buffer	3,578.73 MiB（計算用一時バッファ）
KV cache (CUDA0)	15,872 MiB（K: 7.75 GiB + V: 7.75 GiB）
Compute buffer (CUDA0)	1,990 MiB

KV キャッシュはf16で確保され，65,536コンテキスト下でのメモリ配置は安定。GPU側の計算バッファは約2 GiB程度で，実運用に支障なし。

ベンチマーク結果（8ラン）

Run	Prompt tok	PP ms	PP tok/s	Gen tok	Gen ms	Gen tok/s	Total tok	Total ms	Total tok/s
1	753	3,517	214.07	215	6,079	35.37	968	9,597	100.87
2	386	2,266	170.36	196	5,563	35.23	582	7,829	74.34
3	297	1,840	161.38	240	6,816	35.21	537	8,656	62.04
4	341	2,053	166.12	783	22,651	34.57	1,124	24,703	45.50
5	1,264	6,152	205.46	734	21,259	34.53	1,998	27,411	72.89
6	942	4,377	215.21	921	26,849	34.30	1,863	31,226	59.66
7	938	4,338	216.23	157	4,576	34.31	1,095	8,914	122.84
8	1,075	6,097	176.32	1,351	40,019	33.76	2,426	46,116	52.61

統計サマリー

メトリクス	Prompt tok/s	Gen tok/s	Total tok/s
Mean	190.64	34.66	73.84
Median	190.89	34.55	67.46
Min	161.38	33.76	45.50
Max	216.23	35.37	122.84

Prompt Evaluation速度のばらつき

プロンプト評価（Prefill）は125-314 tok/sとブレが大きく，以下の要因が推定される：

キャッシュヒット率: 同一プロンプトの再利用時はキャッシュが効く
KV操作の処理コスト: prompt cacheが15.8 GiBまで蓄積されると，古いエントリ削除や一貫性チェックのコストが増加
NUMA/ページング: 157 GiB CPU側メモリへのアクセスパターンが統一されない

生成速度の安定性

生成（decode）は33.76-35.37 tok/sにほぼ張り付いており，expert計算がCPU側に寄っているため，PCIe/メモリ帯域のボトルネックが支配的であることを示唆。

考察

Expert CPU配置の影響

ログ上は「offloaded 63/63 layers to GPU」と表示されるものの，実際には -ot exps=CPU で256個のexpert重み（MLP層）がCPU配置されている。これにより：

PCIe経由のアクティブexpert転送: 各生成ステップで8個のアクティブexpertのみをCPUからGPUへ読み込む
メモリ帯域のボトルネック化: expert計算の往復転送がリンク飽和の原因に
生成速度の上限: 35 tok/s前後という安定値は，PCIeスループット制約を示唆

Prompt Cacheの動作

ケースBのログから，prompt cacheが実際に機能していることを確認：

6,029トークンで1,460 MiB保存
23,104トークンで5,595 MiB保存
上限8,192 MiB内で動作

同一システムプロンプトを何度も使用する運用なら，キャッシュ再利用により初回のprefill速度低下を緩和できる。

Flash Attentionの有効性

flash_attn=1有効下で，KV キャッシュが15.8 GiBまで積み上がっても，メモリアクセスパターンの最適化により，マトリクス計算効率が維持されている可能性が高い。

感想

起動・HTTP待受・KV確保・flash-attn有効化まで一通り安定して動作する構成であることが実証された。65,536コンテキストでのサーバ稼働は技術的に実現可能。

ただし，性能の詰めは -ot exps=CPU と –no-mmap の2点を改善せずに他の微調整だけ行うと効果が限定的 になることに注意。特にexpert計算がCPU寄りになっている場合，PCIeバンド幅制約が覆い隠せない。

tokenizer設定の警告（special_eos_id is not in special_eog_ids）が出ていることも，停止条件やタグ解釈の不安定性につながるため，調査・修正が推奨される。

再現方法

1. モデル取得

  huggingface-cli download TheBloke/MiniMax-2.5-A10B-IQ5_K-GGUF

2. llama.cpp サーバ起動

上記「実施内容」のコマンドを参照。$MODEL は ggufファイルのパス，$IMG はllama.cpp container imageとなる。

3. ベンチマーク計測

  curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "minimax",
    "messages": [{"role": "user", "content": "Your prompt..."}],
    "max_tokens": 1024
  }' | jq .usage

レスポンスJSON内の prompt_eval_count / prompt_eval_duration と completion_tokens / completion_eval_duration から tok/s を算出。複数回リクエストして平均値を取得。

補足ノウハウ

Expert Offload戦略の選択肢

-ot exps=CPU はメモリ効率（GPU側を小さく保つ）重視だが，性能は損なわれる。代替案：

-ot exps=GPU: expertもGPU配置（VRAM使用量増，高速化）
mixed offload: 頻繁に使うexpertはGPU，稀なexpertはCPU（複雑だが中庸）

No-mmap の影響

--no-mmap は全ての重みをメモリに直接ロードするため，起動時間が遅く（プロセス初期化時に157 GiBを読み込む），また NUMA環境でのページング傾向が増す。代替案としてメモリマップを有効化して初期化速度を短縮できるが，アクセスパターンによってはページフォルト増加もある。

Tokenizer設定エラー

special_eos_id is not in special_eog_ids は，モデル側のtokenizer.jsonとllama.cppの解釈ズレを示す。モデル公開元のtokenizer設定を確認し，必要なら llama.cppの特殊トークンマッピングを明示的に指定（--special-tokens-file など）。

コンテキスト長と実効バッチサイズの関係

コンテキスト長が大きいほど，KV キャッシュのメモリ占有率が高くなり，実行時バッチサイズを自動調整する際に効率が低下しやすい。-b 2048 -ub 2048 の設定は上記環境では安定だが，異なるGPU・メモリ構成では要調整。

MiniMax-2.5 230B MoEをIQ5K量子化でBlackwell GPU上で実行：生成速度35 tok/s・長コンテキスト65kの検証結果

背景 link

目的 link

実験環境 link

実施内容 link

起動コマンド link

主要パラメータ説明 link

ベンチマーク実行 link

結果 link

メモリ配置（実測値） link

ベンチマーク結果（8ラン） link

統計サマリー link

Prompt Evaluation速度のばらつき link

生成速度の安定性 link

考察 link

Expert CPU配置の影響 link

Prompt Cacheの動作 link

Flash Attentionの有効性 link

感想 link

再現方法 link

1. モデル取得 link

2. llama.cpp サーバ起動 link

3. ベンチマーク計測 link

補足ノウハウ link

Expert Offload戦略の選択肢 link

No-mmap の影響 link

Tokenizer設定エラー link

コンテキスト長と実効バッチサイズの関係 link

関連トピック link

背景

目的