DiffusionGemmaをDGX Spark (GB10)のNIMで動かして、Gemma 4 26B MTPと比較してみた

はじめに

Googleから、拡散型のテキスト生成モデル DiffusionGemma が公開されました。

通常のLLMは、トークンを左から右へ順番に生成していく自己回帰型です。
一方、DiffusionGemmaは、画像生成などで使われてきた拡散モデルの考え方をテキスト生成に応用したモデルです。

GoogleやNVIDIAの記事では、かなり高い生成速度が出るとされており、NVIDIAの記事では、DGX Spark上で150 tokens/sec級という数字も出ています。

では、実際にGB10上で動かすとどうなるのか。
今回は、DiffusionGemmaをNVIDIA NIMで起動し、これまで使っていた Gemma 4 26B A4B NVFP4 + vLLM MTP と比較してみます。

結論から言うと、面白い結果になりました。

単発生成ではDiffusionGemmaが平均約106.8 tok/s。
4並列では最大155.3 tok/s。
Gemma 4 26B MTP比では、長文生成で約3.4倍高速でした。

ただし、会話の最初の一言、つまりfirst token / first contentの速さでは、Gemma 4 26B MTPの方が有利でした。

つまり、DiffusionGemmaは「普通の会話LLMを全部置き換えるモデル」というより、長めの生成や短い構造化出力を高速に返す用途に強いモデルとして見るのがよさそうです。

今回の環境

今回の環境は以下です。

• NVIDIA GB10

• NVIDIA NIM

• DiffusionGemma 26B A4B IT

• 比較対象：Gemma 4 26B A4B NVFP4 + vLLM MTP

• API形式：OpenAI互換 /v1/chat/completions

• クライアント：Windows PowerShell

DiffusionGemma側は、今回は安定性を優先してNVIDIA NIMを使いました。

NIMのコンテナは以下です。

nvcr.io/nim/google/diffusiongemma-26b-a4b-it:latest

起動ログ上では、BackendはvLLMで、OpenAI互換APIとして /v1/chat/completions が有効になっていました。

主なログ上の情報は以下です。

NIM VERSION: 1.7.0-variant
Backend: vLLM
vLLM version: 0.21.0
precision: nvfp4
profile: throughput
max_num_seqs: 4
max_model_len: 262144

モデルロード時のGPU使用量は、ログ上では約18.16 GiBでした。

まずは単純な短文応答

最初に、短いプロンプトで比較しました。

一言で自己紹介して

ここで見たのは、単なるtokens/secではありません。

デジタルヒューマンや音声会話では、全文の生成速度よりも、まず「最初の本文がいつ返ってくるか」が重要です。

そのため、以下を見ました。

• first content latency

• total latency

結果は以下です。

モデル            first content平均     total平均   挙動
DiffusionGemma   約925ms                約925ms    0.9秒後に完成文がまとまって返る
Gemma 4 26B MTP  約320ms                約1038ms   早く出始めて、ストリーミングで返る

Gemma 4 26B MTPは1回目にウォームアップらしき外れ値がありました。
それを除くと、first contentは約105ms前後でした。

つまり、会話の出だしはGemma 4 26B MTPの方が速いです。

DiffusionGemmaは、少しずつトークンを返すというより、一定時間後に完成した文章がまとまって返ってくるような挙動でした。

音声会話でTTSにすぐ流し込みたい場合は、Gemma 4 26B MTPの方が体感は良さそうです。

長文生成ベンチマーク

次に、1024 tokensを出力させる長めのプロンプトで比較しました。

プロンプトは、自己回帰型LLMと拡散型テキスト生成モデルの違いについて、日本語で長めに説明させる内容です。

測定は非streamリクエストで行い、usage.completion_tokens とリクエスト全体の処理時間から completion tokens/sec を計算しました。

結果は以下です。

モデル            平均処理時間	completion tokens	平均tok/s			最大tok/s
DiffusionGemma		9.62秒		1024				106.8 tok/s			113.8 tok/s
Gemma 4 26B MTP		32.26秒		1024				31.8 tok/s			32.8 tok/s

DiffusionGemmaは、今回の単発リクエスト条件では平均106.8 tok/s、最大113.8 tok/sでした。

NVIDIAの記事ではDGX Spark上で150 tok/s級という数字も出ていますが、少なくとも私のGB10 + NIM + OpenAI互換API + 単発リクエスト条件では、150 tok/sには届きませんでした。

ただし、同じ条件でGemma 4 26B MTPは平均31.8 tok/sだったため、DiffusionGemmaは約3.4倍高速でした。

これはかなり大きな差です。

単純な長文生成では、DiffusionGemmaはかなり速いです。

4並列で投げた場合

次に、DiffusionGemmaへ4本同時にリクエストを投げました。

NIMの起動ログでは max_num_seqs: 4 となっていたため、単発よりも4並列の合計スループットを見る方が、NIMのスループット性能に近い可能性があります。

やったことは単純です。

• 同じ1024 tokens生成リクエストを4本同時に投げる

• 4本すべてが完了するまでの壁時計時間を測る

• 合計4096 tokens / 壁時計時間で aggregate tok/s を計算する

結果は以下です。

Round	合計completion tokens	壁時計時間	合計tok/s
1		4096					35.85秒		114.2
2		4096					29.41秒		139.3
3		4096					26.38秒		155.3
4		4096					29.33秒		139.7
5		4096					29.17秒		140.4

5回平均では137.8 tok/s。
最大では155.3 tok/sでした。

つまり、私の環境でも、条件次第では150 tok/s級は確認できました。

ただし、常時150 tok/sを安定して出すというより、4並列時の合計スループットで150 tok/s前後に届く、という見方が正確そうです。

また、4並列時は1リクエストあたりの速度は30〜40 tok/s程度まで落ちました。

つまり、

単一ユーザーの体感速度 → 単発リクエストが有利
サーバ全体の処理量 → 4並列時の合計スループットが有利

という結果です。

「150 tok/s」という数字を見ると、単発リクエストで常に150 tok/s出るように見えますが、少なくとも私の環境では、そういう挙動ではありませんでした。

JSON出力ではDiffusionGemmaが強かった

さらに、短い構造化出力でも比較しました。

例えば、以下のような画面状態の変化をJSONにする用途です。

前の画面:
Dockerコンテナ起動時に port 8000 is already allocated というエラーが出ていた。

今の画面:
vLLM server started.
model loaded successfully.
OpenAI API server is ready.

これを以下のようなJSONに変換させます。

{
  "changed": true,
  "state": "success",
  "should_speak": true,
  "utterance": "エラーが解消し、サーバーが正常に起動しました。"
}

ここでは、最初の文字が返る時間ではなく、制御に使えるJSONが完成した時間を測りました。

厳格なスキーマと、should_speak の判断基準も入れています。

結果は以下です。

モデル				policy_ok	first policy OK平均		最大値
DiffusionGemma		10/10		746.4ms					869ms
Gemma 4 26B MTP		10/10		1037.1ms				1122ms

この比較では、DiffusionGemmaが明確に速い結果になりました。

Gemma 4 26B MTPは、first content自体は約164msと速いです。
しかし、JSONとして完成して、制御に使える状態になるまでには約1秒かかりました。

一方、DiffusionGemmaは、0.7〜0.8秒程度で完成済みのJSONを返していました。

この挙動は、拡散型テキスト生成モデルらしいと感じます。

途中から少しずつ出すのではなく、短い完成形をまとめて返す用途に向いているように見えます。

結果の整理

今回の結果をまとめると、こうなります。

用途						有利だったモデル
会話の出だし					Gemma 4 26B MTP
TTSへのストリーミング			Gemma 4 26B MTP
単発1024 tokens生成			DiffusionGemma
4並列合計スループット			DiffusionGemma
短いJSON出力					DiffusionGemma
画面状態やログ状態の一次判定	DiffusionGemma
深い説明や品質重視の回答		Gemma 4 26B MTPなど通常LLM

DiffusionGemmaは、普通の会話LLMとして全面的に置き換えるモデルではなさそうです。

むしろ、以下のような用途に向いているように感じました。

• 短い構造化出力

• ログや画面状態の要約

• JSON生成

• Markdown整形

• 長めの下書き生成

• 複数リクエストのまとめ処理

逆に、会話の最初の一言をすぐ出したい場合や、TTSへストリーミングで流し込みたい場合は、Gemma 4 26B MTPの方が扱いやすいです。

デジタルヒューマン用途で考える

私はローカルAIデジタルヒューマンをGB10上で動かす実験をしています。

音声入力、LLM、VLM、TTS、画面文脈認識などをローカル環境に集約して、クラウドに依存しないデジタルヒューマンを作る試みです。

この用途では、LLMに求める処理は大きく2種類あります。

1つ目は、ユーザーと自然に会話する処理。
2つ目は、画面やログの状態を短く判断して、システム制御に使える形にする処理です。

今回の結果を見る限り、この2つはモデルを分けた方が良さそうです。

会話本体:
Gemma 4 26B MTP

画面状態・ログ状態のJSON化:
DiffusionGemma

DiffusionGemmaを本体の会話LLMとして全面採用するというより、画面変化やログ変化をすばやくJSON化する「反射神経」として使う方が合っていると思います。

例えば、以下のような短い判断を高速に返す用途です。

{
  "changed": true,
  "state": "success",
  "should_speak": true,
  "utterance": "エラーが解消し、サーバーが正常に起動しました。"
}

こういうJSONが1秒未満で返るなら、デジタルヒューマン側は「今話すべきか」「黙るべきか」「次に何を見ればいいか」を軽く判断できます。

これは、単なるチャット性能とは別の価値です。

注意点

もちろん、今回の結果だけで、DiffusionGemmaの方がGemma 4より賢い、という話にはなりません。

Google自身も、DiffusionGemmaは実験的なモデルであり、最高品質を求める用途では通常のGemma 4を推奨しています。

実際、今回の比較でも、細かい情報保持ではGemma 4 26B MTPの方が良い場面がありました。

例えば、DiffusionGemmaは「エラーが解消した」と要約し、Gemma 4 26B MTPは「ポート競合が解消した」と、より具体的な原因語を残す傾向がありました。

そのため、DiffusionGemmaを使う場合は、プロンプト側で「重要な原因語を保持する」ように指定した方が良さそうです。

また、今回の数値はあくまで私の環境での実測です。

NIMのバージョン、モデルの量子化、プロンプト長、出力長、並列数、ネットワーク、ウォームアップ状態によって結果は変わると思います。

まとめ

今回、GB10上のNVIDIA NIMでDiffusionGemmaを動かし、Gemma 4 26B MTPと比較しました。

結果は以下です。

NVIDIA記事の150 tok/s級という数字については、私の環境でも4並列時の最大値として155.3 tok/sを確認できました。

ただし、単発リクエストで常時150 tok/s出るわけではなく、4並列時の合計スループットとして150 tok/s級に届く、という見方が正確そうです。

DiffusionGemmaは、会話LLMの全面置き換えというより、高速な構造化出力エンジンとしてかなり面白いです。

ローカルAIでは、すべてを1つのモデルにやらせるよりも、役割に応じてモデルを使い分ける方が現実的です。

今回の結果を見る限り、私のローカルAIデジタルヒューマンでは、以下の役割分担が良さそうです。

Gemma 4 26B MTP:
会話、説明、ストリーミング応答

DiffusionGemma:
画面状態、ログ状態、短いJSON、長文生成、一次判定

DiffusionGemmaは、ローカルAIの「頭脳」そのものというより、画面やログの変化に反応する「反射神経」としてかなり使い道がありそうです。

GB10のようなローカルAI環境では、こういう高速なサブモデルを組み合わせていく方が、体感として面白いシステムになりそうです。

 本日はここまで。
2026/6/12