DGX Spark / GB10(MTP)の本命はGemma 4 26B A4B NVFP4だった話

tsuru_mitsu

2026年5月14日 00:00

31B Dense寄り構成から、26B A4B構成に評価を更新

結論から書きます。

DGX Spark / GB10上でGemma 4を使うなら、現時点では Gemma 4 26B A4B NVFP4 がかなり有力です。

前回は Gemma 4 31B を BF16 / NVFP4 / MTP で比較し、最終的に「31B NVFP4 + MTP はバックエンド判断LLMとして有望」という結論にしました。

ただ、今回はその後に試した nvidia/Gemma-4-26B-A4B-NVFP4 が、速度面でかなり強い結果になりました。

通常生成の結果は以下です。
short / medium / 制御JSON は、前回と同じベンチ条件で測定しています。

通常生成ベンチの比較です。短〜中応答と制御JSONでは、26B A4B NVFP4 + MTP 32k が最も高速でした。

| 構成 | short | medium | 制御JSON |

| 31B NVFP4 + MTP | 16.34 tok/s | 16.87 tok/s | 19.79 tok/s |
| 26B A4B NVFP4 no-MTP 64k | 31.82 tok/s | 32.05 tok/s | 31.77 tok/s |
| 26B A4B NVFP4 + MTP 32k | 54.85 tok/s | 57.07 tok/s | 61.03 tok/s |

また、長文コンテキストでも 26B A4B NVFP4 no-MTP 64k はかなり安定していました。

この長文テストで見たいのは、単なる最大context長ではありません。
実運用では、長い会話履歴や作業ログの中に、重要な決定事項が埋もれます。

たとえば、

どの構成が最速だったか
どの数値を採用判断に使うか
GB10をどの役割で使う方針にしたか
なぜ長いcontextを使うのか

といった情報です。

AI NPCやデジタルヒューマン、あるいはバックエンド判断LLMでは、最後の数ターンだけを見ても判断できない場面があります。

そのため今回は、長い擬似ログの中に正解データを埋め込み、最後にそれをJSONで回収できるかを見ました。

つまり、このテストは「長い文章を入れられるか」ではなく、長い履歴の中から、後の判断に必要な情報を見失わずに取り出せるか を見るためのものです。つまり「長いログを読ませたら、昔の重要な決定を忘れずに拾えるか」というテストの結果とお考え下さい。

| 構成 | 入力規模 | prompt_tokens | elapsed_sec | 抽出 |

| no-MTP 64k | 300 blocks | 25,902 | 11.918 sec | 正解 |
| no-MTP 64k | 600 blocks | 50,802 | 28.583 sec | 正解 |
| no-MTP 64k | 700 blocks | 59,102 | 35.837 sec | 正解 |

ここまでみての、現時点の使い分けはこうです。

※短〜中応答や制御JSONは MTP 32k、長文prefill中心の処理は no-MTP 64k を使う想定です。Dense構成は速度目的ではなく、品質や統合性の比較用として残します。

| 用途 | 推奨構成 |

| 普段使いチャット | 26B A4B NVFP4 + MTP 32k |
| VRM / AI NPC会話 | 26B A4B NVFP4 + MTP 32k |
| 制御JSON生成 | 26B A4B NVFP4 + MTP 32k |
| 50k級ログ解析 | 26B A4B NVFP4 no-MTP 64k |
| 長期一時記憶 | 26B A4B NVFP4 no-MTP 64k |
| Dense品質比較 | 31B NVFP4 + MTP |

短〜中応答や制御JSONは MTP 32k。
長文prefillは no-MTP 64k。
この分け方がよさそうです。

ここでいう 64k context は、モデルが一度に読める文章量の上限を指します。
ざっくり言えば、AIに渡せる「作業メモ」や「会話履歴」の広さです。
今回の長文テストでは、長い擬似ログの中に重要な決定事項を埋め込み、最後にそれを正しく回収できるかを見ました。

ただし、今回の話は単純に「MoE/A4Bが速いから正解」という話ではありません。

MoE/A4Bが速いのは、推論時に使う有効計算量が軽いので、当然です。
それでも最初にDense寄りの31Bを主流候補として見ていたのは、速度ではなく 統合性 を重視したかったからです。

AI NPCやデジタルヒューマンでは、単発回答の速さだけでなく、人格・口調・判断軸が長く維持されることが重要になります。

今回の結論はこうです。

速度面では 26B A4B NVFP4 が明確に有利。
ただし、人格や判断軸の統合性はモデル内部に丸投げせず、
外部状態管理・プロンプト設計・会話履歴管理で補強する。

以下、実際の検証内容です。

検証環境

環境は前回と同じです。

Machine: DGX Spark / GB10
Architecture: aarch64
GPU: NVIDIA GB10
Driver: 580.142
CUDA: 13.0
Docker利用
Container: vllm/vllm-openai:nightly-aarch64
vLLM: 0.20.2rc1.dev246+g28ee78af5

今回使ったモデルは以下です。

Target:
  nvidia/Gemma-4-26B-A4B-NVFP4

MTP assistant:
  google/gemma-4-26B-A4B-it-assistant

1. 26B A4B NVFP4 no-MTP 4k

まずはMTPなし、max_model_len=4096 で起動しました。

sudo docker run --rm -it \
  --name gemma4-26b-a4b-nvfp4-vllm \
  --gpus all \
  --ipc=host \
  --network host \
  -v ~/hf-cache:/root/.cache/huggingface \
  --env HF_TOKEN="$HF_TOKEN" \
  --env HUGGING_FACE_HUB_TOKEN="$HF_TOKEN" \
  vllm/vllm-openai:nightly-aarch64 \
  --model nvidia/Gemma-4-26B-A4B-NVFP4 \
  --served-model-name gemma4-26b-a4b-nvfp4 \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 4096 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 1 \
  --gpu-memory-utilization 0.90 \
  --trust-remote-code

速度は以下です。

前回の31B NVFP4 + MTPが、
short 16.34
medium 16.87
制御JSON 19.79 tok/s
だったので、この時点で26B A4B no-MTPの方が速いです。

2. 26B A4B NVFP4 no-MTP 64k

次に、max_model_len=65536 で起動しました。

sudo docker run --rm -it \
  --name gemma4-26b-a4b-nvfp4-vllm-64k \
  --gpus all \
  --ipc=host \
  --network host \
  -v ~/hf-cache:/root/.cache/huggingface \
  --env HF_TOKEN="$HF_TOKEN" \
  --env HUGGING_FACE_HUB_TOKEN="$HF_TOKEN" \
  vllm/vllm-openai:nightly-aarch64 \
  --model nvidia/Gemma-4-26B-A4B-NVFP4 \
  --served-model-name gemma4-26b-a4b-nvfp4-64k \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 65536 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 1 \
  --gpu-memory-utilization 0.90 \
  --trust-remote-code

通常ベンチの結果は以下です。

26B A4B NVFP4 no-MTP の比較
64k contextで起動しても、短〜中応答や制御JSONでは4k時とほぼ同じ速度。

| 構成 | short | medium | 制御JSON |

| no-MTP 4k | 31.94 | 32.16 | 31.85 |
| no-MTP 64k | 31.82 | 32.05 | 31.77 |

64kにしても、短〜中程度の通常生成ではほぼ速度低下がありませんでした。

3. 長文コンテキストテスト

次に、64k構成で長文コンテキストテストを行いました。

擬似的な作業ログを大量に並べ、その中に重要情報を前方・中間・後方に分散して埋め込み、最後にJSON形式で抽出させるテストです。

ここでいう `blocks` は、擬似的な会話ログの単位です。

1 block は、User / Assistant / Observation / Next を含む短い作業ログです。
このblockを 300 / 600 / 700 個並べ、その途中に重要情報ブロックを複数箇所へ挿入しています。

そのため、`300 blocks` は単に300行という意味ではなく、擬似会話ログ300単位分に近い長文入力です。

抽出はログ中に埋め込んだ `IMPORTANT_FACTS` の内容を、最後の質問に対して正しくJSON化できたかを見ています。

判定対象は以下の5項目です。

- 最速だった構成
- 制御JSONでの tok/s
- BF16 no-MTP と比べた改善倍率
- GB10の推奨用途
- context長を長期一時記憶として使う意味

今回のテストでは、25k / 50k / 59k tokens のいずれでも、これらの項目を正しく取り出せました。

{
  "fastest_config": "NVFP4 + MTP",
  "control_json_tokens_per_sec": 19.79,
  "improvement_over_bf16_no_mtp": 5.25,
  "recommended_role_for_gb10": "バックエンド判断LLM",
  "context_memory_value": "1ターンあたり約4000 token級のやり取りを想定し、長期一時記憶としてcontext長を活かす。",
  "confidence": "high"
}

結果は以下です。

前回の31B NVFP4 + MTPとの比較は以下です。

長文prefill込みでも、26B A4Bの方がかなり軽い結果になりました。

4. MTPを有効化する

次に、26B A4BでもMTPを試しました。

最初に、31B assistantを組み合わせました。

Target:
  nvidia/Gemma-4-26B-A4B-NVFP4

Assistant:
  google/gemma-4-31B-it-assistant

これは失敗しました。

a and b must have same reduction dim, but got [s47, 8192] X [10752, 1024]

hidden dimensionが合っていません。

26B A4B target に 31B assistant を組み合わせるのは不成立です。（当たり前ですが、一応試してみました）

正しい組み合わせはこちらでした。

Target:
  nvidia/Gemma-4-26B-A4B-NVFP4

Assistant:
  google/gemma-4-26B-A4B-it-assistant

起動コマンドは以下です。

sudo docker run --rm -it \
  --name gemma4-26b-a4b-nvfp4-vllm-mtp \
  --gpus all \
  --ipc=host \
  --network host \
  -v ~/hf-cache:/root/.cache/huggingface \
  --env HF_TOKEN="$HF_TOKEN" \
  --env HUGGING_FACE_HUB_TOKEN="$HF_TOKEN" \
  vllm/vllm-openai:nightly-aarch64 \
  --model nvidia/Gemma-4-26B-A4B-NVFP4 \
  --served-model-name gemma4-26b-a4b-nvfp4-mtp \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 4096 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 1 \
  --gpu-memory-utilization 0.90 \
  --speculative-config '{"model":"google/gemma-4-26B-A4B-it-assistant","num_speculative_tokens":2}' \
  --trust-remote-code

この構成は起動し、通常生成も通りました。

MTP 4kの結果は以下です。

MTPは明確に効いています。

5. MTP 32k

次に、max_model_len=32768 でMTPを試しました。

sudo docker run --rm -it \
  --name gemma4-26b-a4b-nvfp4-vllm-mtp-32k \
  --gpus all \
  --ipc=host \
  --network host \
  -v ~/hf-cache:/root/.cache/huggingface \
  --env HF_TOKEN="$HF_TOKEN" \
  --env HUGGING_FACE_HUB_TOKEN="$HF_TOKEN" \
  vllm/vllm-openai:nightly-aarch64 \
  --model nvidia/Gemma-4-26B-A4B-NVFP4 \
  --served-model-name gemma4-26b-a4b-nvfp4-mtp-32k \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 32768 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 1 \
  --gpu-memory-utilization 0.90 \
  --speculative-config '{"model":"google/gemma-4-26B-A4B-it-assistant","num_speculative_tokens":2}' \
  --trust-remote-code

結果は以下です。

32k contextでも、通常生成速度はほぼ落ちませんでした。

この結果から、会話・制御JSON用途では MTP 32k がかなり有力です。

6. MTP 32kで長文を読ませる

ただし、MTPは主にdecodeを高速化する仕組みなので、長文prefillにも効くとは限りません。

そこで、25k tokens級の同じ長文入力を使い、`no-MTP 64k` と `MTP 32k` を比較しました。

| 構成 | 入力tokens | 出力tokens | elapsed_sec | 正解データ回収 |

| no-MTP 64k | 25,902 | 127 | 11.918 sec | 成功 |
| MTP 32k 　 | 25,902 | 127 | 13.274 sec | 成功 |

結果として、MTP 32kの方が少し遅くなりました。

これは、MTPが主に出力生成、つまりdecode側を高速化する仕組みだからだと考えています。

今回の長文テストは、入力が25,902 tokensに対して、出力は127 tokensだけです。
つまり、処理時間の中心は「長い入力を読むprefill」であり、出力生成部分は短いです。

そのため、MTP/speculative decodingの効果は出にくく、むしろassistant側のオーバーヘッドが乗った可能性があります。

この結果から、短〜中応答や制御JSONでは `MTP 32k`、長文prefill中心の処理では `no-MTP 64k` を使うのがよさそうです。

なお、本記事の起動例は64k context維持を目的とした検証構成であり、省メモリ運用の推奨値ではありません。
省メモリで起動する場合は、`--gpu-memory-utilization` の値を下げ、必要に応じて `--max-model-len` を 32768 / 16384 / 8192 などに落としてください。

7. DenseとMoE/A4Bの考え方

今回の結果だけ見ると、こう言えます。

26B A4Bの方が速い。
だから26B A4Bでいい。

MoE/A4BがDenseより速くなりやすいのは自然です。
総パラメータ数に対して、推論時に使う有効計算量が小さくなりやすいからです。

問題は速度だけではありません。

最初にDense寄りの31Bを主流候補として見た理由は、統合性です。

AI NPCやデジタルヒューマンでは、単発の回答品質だけでなく、人格・口調・判断軸・会話方針が長く維持されることが重要になります。

Denseモデルは、推論時の経路が比較的一貫しています。
常にモデル全体を通って出力が作られるため、出力の癖や判断基準を観察しやすい。

一方、MoEでは、入力に応じてrouterがエキスパートを選択します。
つまり、Denseモデルのように常に同じ重み全体を通るわけではありません。

この構造は効率面では有利です。
一方で、AI NPCやデジタルヒューマンのように人格・口調・判断軸の一貫性を重視する用途では、注意点にもなります。

同じキャラクターとして会話しているつもりでも、話題や文脈によって選ばれるエキスパートが変わることで、出力の癖や判断の方向性が微妙にずれる可能性があります。

もちろん、MoEだから必ず人格が分裂する、という意味ではありません。
モデル全体としては、routerや学習によって統合されています。

ただし、長期会話やキャラクター運用では、単発の速度やベンチマークだけでなく、"同じ存在として振る舞い続けられるか"を見る必要があります。

この点が、最初からMoE/A4Bを本命にしきれなかった理由です。

8. 今回の結論

今回の結論は、単純な「MoEが速いから勝ち」ではありません。

DenseにはDenseの良さがあります。
特に、AI NPCやデジタルヒューマンのような用途では、人格・判断軸・文脈理解が一つの存在としてまとまっている感覚が重要です。

その点では、Denseモデルの方が扱いやすいのではないか、という仮説を持っています。
ただし、これは今回の速度ベンチで証明した話ではなく、AI NPC運用上の設計仮説です。

ただし、GB10上での実測を見ると、26B A4B NVFP4の速度差はかなり大きいです。

特にMTP 32kでは、通常生成で55〜61 tok/s程度まで出ています。

この速度差を考えると、GB10上ではDenseを常用本命にするより、MoE/A4Bを主軸にした方が現実的です。

ただし、MoEに統合性を丸投げは怖いと考えています。

速度:
  MoE/A4B + MTP

長文prefill:
  MoE/A4B no-MTP 64k

人格・記憶・判断軸:
  外部状態管理とプロンプト設計で補強

そのため、自分で使うとした場合、最終的な構成案は以下を考えています。

会話・制御用:
  26B A4B NVFP4 + MTP 32k

長文解析用:
  26B A4B NVFP4 no-MTP 64k

品質比較・統合性確認用:
  31B NVFP4 + MTP

前回、「次は26B A4B NVFP4を試す」と書きました。

実際に試してみたら、普通に本命でした。

GB10上でGemma 4を使うなら、まず26B A4B NVFP4が、ある程度の性能を担保しつつ、ストレスなく使えそうです。

本日はここまで

2026/5/14