RTX 5090でDiffusionGemmaとGemma4を実測比較。8.7倍速の代償は品質でした。下書き用途と本番用途の分かれ目を整理します。
TL;DR: 同一 RTX 5090・同一 vLLM・enforce-eager 条件で、拡散 DiffusionGemma は自己回帰 Gemma4 の実測 8.7 倍速でした。Google 公称の「最適化時 約4倍」よりも開きが大きく出ていますが、そのぶん品質は別問題です。Google 自身も全ベンチで Gemma4 に劣ると明言しており、実機でも拡散側は括弧バランス課題で破綻しました。速度最優先の下書き・大量生成なら拡散、本番品質なら自己回帰です。
先に結論です。拡散は実測 8.7 倍速。ただし品質は代償。速度最優先なら拡散、本番品質なら自己回帰です。
拡散 LLM が速い、という話は前からありました。でも「本当にその差が出るのか」「速い代わりに何を失うのか」は、やっぱり気になるところです。実際に RTX 5090 で回してみると、そこがかなりはっきり見えます。机上ではなく、実機で見ると話が締まります。
今回見たのは、Google が 2026-06-10 に公開した拡散言語モデル DiffusionGemma と、同サイズ・同 NVFP4 量子化の自己回帰 Gemma4 です。同一の Vast.ai RTX 5090、同一 vLLM、同一プロンプト、同一 max_tokens で連続計測しました。
今回の実測では、DiffusionGemma は Gemma4 の 8.7 倍速でした。しかも、これは誇張ではなく、同一ホスト・同一 vLLM・同一条件での比較です。
ただし、ここで話をきれいにしすぎると実務で危ないです。速度の代償は品質でした。Google 自身も公式ブログで「全ベンチマークで DiffusionGemma は Gemma4 26B A4B に劣る」「最高品質が要るなら標準 Gemma4 を推奨」と明言しています。
なので、結論は単純です。
これは少し意外でした。速いモデルがそのまま万能、ではありません。ここは一度、足元を見ておく必要があります。
DiffusionGemma は、自己回帰モデルと発想が違います。
この構造だと、1トークンごとのオーバーヘッドに鈍感になりやすいです。だから、理屈の上では速くなり得る。理屈だけで終わらないのが今回のポイントで、実際に速かった、というところまで確認できました。
計測条件は、かなり揃えました。
--enforce-eager--gpu-memory-utilization 0.75--max-model-len 8192chat/completions256トークン強制（ignore_eos）結果は以下です。
つまり 8.7 倍速（平均同士の比）です。内訳を正直に出しておくと、拡散の warm 2 本は 145 と 171 tok/s（平均 158）で、2 本の開きはやや大きめでした。自己回帰は 18 前後で安定しています。拡散側の低いほう（145）で保守的に見ても 145 ÷ 18 ≒ 8 倍なので、結論は変わりません。
ここで大事なのは、単に「拡散が速い」で終わらせないことです。batch=1 の latency ではこの差が効く一方で、高並列では差が縮むことがあります。ローカル 5090 で自分の目の前に返ってくる速度を知りたいなら、batch=1 の値を見るのが筋です。
Google の公称では、最適化条件で 約4倍 とされています。今回の実測は 8.7倍 でした。
この差は、どちらかが間違っているという話ではありません。条件が違います。
ポイントは --enforce-eager です。32GB の 5090 に収めるためにはこれがほぼ必須でしたが、これが 自己回帰側に不利 に働きます。自己回帰は CUDA グラフの恩恵を受けやすいのに対し、拡散は 256 トークン単位で並列に進むため、per-token オーバーヘッドの影響を受けにくい。
つまり、eager 条件では差が開きやすい。ただし正直に言うと、Google の4倍は H100＋最適化スタック、今回は 5090＋素の vLLM＋eager と、ハードもソフトも違います。eager を主因とみていますが、そこだけを切り分ける実験まではしていません（ここは推定です）。逆に言えば、Google の「約4倍」と今回の「8.7倍」は、どちらも「拡散が劇的に速い」という同じ方向の結果です。
速度の話だけだと、実務では判断を誤ります。なので品質も見ました。
Google 自身が「DiffusionGemma は全ベンチマークで Gemma4 に劣る」と言っている以上、ここを曖昧にするのは不誠実です。実機でも、その差は出ました。
今回の単発テストでは、拡散側が 括弧バランス判定（is_balanced_brackets） で破綻しました。以下は DiffusionGemma が実際に出力したコードです（生成結果ママ・モデル自身のコメント込み）。
def is_balanced_brackets(s: str) -> bool:
"""
Checks if the brackets (), [], and {} in a string are balanced.
"""
stack = []
mapping = {")": "(", "]": "[", "}": "{"}
for char in s:
if char in mapping.values():
# Pop the top element if stack is not empty, else push a dummy value
top_element = stack.pop() if stack else '#'
if mapping[char] != top_element:
return False
elif char in mapping.values():
# Push opening brackets onto the stack
stack.append(char)
return not stack
mapping.values() は開きカッコ（( [ {）の集合です。つまり最初の if は「開きカッコのとき」の分岐なのに、その中で閉じカッコ専用の辞書 mapping[char] を引いています。開きカッコは mapping のキーに無いので KeyError で落ちます。しかも、続く elif char in mapping.values() は 直前の if と同じ条件なので到達不能（dead branch）。さらにテスト側にも assert is_balanced_brackets("(()")) is False と余分な ) の構文エラーがありました。
ここは重要なので明言します。これは出力切れではありません。480 トークンで完走しており、末尾が切れたわけではなく、真性バグです。
一方、自己回帰側（Gemma4）は同じ課題を stack の push/pop で教科書どおりに正答しました（こちらも生成結果ママ）。
def is_balanced_brackets(s: str) -> bool:
"""
Checks if the input string has balanced (), [], and {} brackets.
"""
stack = []
mapping = {")": "(", "]": "[", "}": "{"}
for char in s:
if char in mapping.values():
stack.append(char)
elif char in mapping.keys():
# If stack is empty or top of stack doesn't match the opening bracket
if not stack or stack.pop() != mapping[char]:
return False
return len(stack) == 0
開きカッコは push、閉じカッコは「スタック先頭と対応が合うか」を mapping.keys() 側で正しく判定しています。483 トークン で、きちんと答えに到達しています。
ただし、これをもって「拡散はコードが苦手」と一般化するのは早いです。あくまで この実行ではこう壊れた、という限定された証拠です。そう書いておくほうが、読後に使える判断材料になります。
今回の比較で、もうひとつ誠実に分けておきたい点があります。
この区別をしないと、評価が雑になります。
今回の比較の価値は、ここを混ぜなかったことにあります。速い・遅いだけではなく、「何が出力切れで、何がロジック破綻か」を分けて見る。これ、地味ですが実務ではかなり効きます。
⚠️ RTX 5090 で DiffusionGemma を触るなら、まずここでつまずきます。
/v1/completions だと 即EOS で 1 トークンしか出ず、計測にならないchat/completions + ignore_eos + min_tokens が必要--gpu-memory-utilization 0.9 では厳しく、0.75 に下げると通った--enforce-eager を付ける必要があった実際に通った起動コマンドは、だいたいこの形でした（拡散側）。
vllm serve nvidia/diffusiongemma-26B-A4B-it-NVFP4 \
--enforce-eager \
--gpu-memory-utilization 0.75 \
--max-model-len 8192 \
--host 0.0.0.0 --port 8000
計測は素の /v1/completions ではなく chat/completions に投げ、ignore_eos と min_tokens で 256 トークンを必ず出させています。実際の計測リクエストはこの形です。
curl -s http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"nvidia/diffusiongemma-26B-A4B-it-NVFP4",
"messages":[{"role":"user","content":"Write a binary search in Python."}],
"max_tokens":256, "min_tokens":256, "ignore_eos":true,
"temperature":0, "stream":false}'
このへんは、カタログを見ているだけでは見えません。実際に回して初めて分かる地雷です。
拡散 LLM の話になると Mercury を思い出す人もいるはずです。そこは分けて考えたほうがいいです。
Mercury は Inception Labs の商用拡散 LLM で、コード特化です。公称では Copilot Arena で速度 1 位・品質 2 位タイ、H100 で 1109 tok/s（Mini）、HumanEval 88-90% と、品質もかなり保っています。
一方、DiffusionGemma は汎用のオープンモデル で、Apache 2.0、vLLM にネイティブ対応する初の拡散 LM です。今回の実測は DiffusionGemma / Gemma4 だけを対象にしていて、Mercury はクローズドなので、公称引用にとどめます。対決表にはしません。
つまり、同じ「拡散」でも役割が違います。
最後に、実務の判断に落とします。
DiffusionGemma を選ぶ理由
Gemma4 を選ぶ理由
Google 自身も最高品質には標準 Gemma4 を推奨しています。ここは無理に逆張りしないほうがいいです。
今回の結論は、きれいですが、かなり現実的です。速い拡散・正確な自己回帰。これが使い分けの軸です。
https://www.inceptionlabs.ai/blog/introducing-mercury
https://openrouter.ai/inception/mercury-coder
--enforce-eager・batch=1 の latency です。高並列バッチでは差が縮みます。--enforce-eager・--gpu-memory-utilization 0.75・--max-model-len 8192 で立ち上げました。chat/completions に 256 トークンを強制（ignore_eos）し、cold 1 本を捨てて warm 2 本（ブレ ±10% 以内）で確定しました。いいえ。速度最優先の下書き・大量生成・低レイテンシ用途なら拡散が有利ですが、本番に出す品質が要るなら自己回帰（Gemma4）です。Google 自身も最高品質には標準 Gemma4 を推奨しています。
GPU・量子化・enforce-eager の有無・バッチサイズで倍率は変わります。本記事は RTX 5090・NVFP4・eager・batch=1 の条件です。最適化条件では Google 公称の 約4倍に近づきます。
コード特化で品質も保ちたいなら商用の Mercury、オープン（Apache 2.0）で自前 GPU に載せたいなら DiffusionGemma、という住み分けです。本記事の実測対象は DiffusionGemma / Gemma4 のみです。
この記事は、実務で AI ツールを活用している開発者・技術者向けに書いています。
K.Hirano です。1984年生まれ、現役のハードウェア系エンジニアとして 22 年ほど現場にいます。トラブル解決は 2000 件を超えました。
AI 駆動開発では Codex / Claude Code / Gemini / OpenRouter を日常的に検証していますが、いつも先に疑います。本当に使えるのか、本当に得なのか。
今回の DiffusionGemma も、速いかどうかだけでなく、実務で使うときにどこが詰まるかまで見ました。速さだけ見て飛びつくと、品質の穴で戻されます。逆に、品質だけを見て新しい選択肢を避けると、下書き生成や大量生成の効率を取り逃がします。
その線引きが、今回の実測でかなりはっきりしました。
META-MARK × AI
ローカルAIを動かすGPU、ちゃんと選べていますか？
VRAM・性能・コスパをMetaScoreで数値化。AIアプリ別の推奨ハードウェア要件も確認できます。