DiffusionGemma 速度8.7倍の結論 — RTX 5090 実測で見えた品質の壁

同一 RTX 5090・同一 vLLM・enforce-eager 条件で、拡散 DiffusionGemma は自己回帰 Gemma4 の実測 8.7 倍速でした。Google 公称の「最適化時 約4倍」よりも開きが大きく出ていますが、そのぶん品質は別問題です。Google 自身も全ベンチで Gemma4 に劣ると明言しており、実機でも拡散側は括弧バランス課題で破綻しました。速度最優先の下書き・大量生成なら拡散、本番品質なら自己回帰です。

関連記事としては BlogGemma 4 MTP drafter を今すぐ入れるべきか？ RTX 4070 Ti 12GB でつまずいた3つのポイントと結論RTX 4070 Ti 12GBでGemma 4 MTP drafterを実測。ドラフター0.14GB、ただし最速はvLLMの162.7 tok/s。導入判断を正直にまとめます。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

先に結論です。拡散は実測 8.7 倍速。ただし品質は代償。速度最優先なら拡散、本番品質なら自己回帰です。

拡散 LLM が速い、という話は前からありました。でも「本当にその差が出るのか」「速い代わりに何を失うのか」は、やっぱり気になるところです。実際に RTX 5090 で回してみると、そこがかなりはっきり見えます。机上ではなく、実機で見ると話が締まります。

今回見たのは、Google が 2026-06-10 に公開した拡散言語モデル DiffusionGemma と、同サイズ・同 NVFP4 量子化の自己回帰 Gemma4 です。同一の Vast.ai RTX 5090、同一 vLLM、同一プロンプト、同一 max_tokens で連続計測しました。

• まず結論: 速さは本物、でも品質は別問題
• 拡散LLMと自己回帰LLMは、生成の仕組みが違う
• RTX 5090 実測: 158 tok/s vs 18 tok/s で 8.7倍
• Google公称の約4倍と実測8.7倍がずれる理由
• 品質差: これは「この実行でこう壊れた」という話です
• 512トークンの出力切れと真性バグは分けて見る
• 5090で動かすときの罠: OOM、即EOS、初期化の長さ
• Mercury と DiffusionGemma は同じ拡散でも別物
• 判断基準: 何を使い分けるべきか
• 参考情報
• 注意点・制約
• どのように検証したか
• よくある質問
  • 拡散が速いなら、いつも拡散を使えばいい？
  • 自分の環境でも 8.7 倍になりますか？
  • Mercury と DiffusionGemma はどちらを使うべき？
• 参考リンク
• 関連記事
• 関連リンク
• この記事を書いた人

今回の実測では、DiffusionGemma は Gemma4 の 8.7 倍速でした。しかも、これは誇張ではなく、同一ホスト・同一 vLLM・同一条件での比較です。

ただし、ここで話をきれいにしすぎると実務で危ないです。速度の代償は品質でした。Google 自身も公式ブログで「全ベンチマークで DiffusionGemma は Gemma4 26B A4B に劣る」「最高品質が要るなら標準 Gemma4 を推奨」と明言しています。

なので、結論は単純です。

• 速度最優先の下書き・大量生成・低レイテンシ用途 → DiffusionGemma
• 本番品質が必要 → Gemma4

ここは速度だけで決めると見落としが出ます。速いモデルがそのまま万能、ではありません。ここは一度、足元を見ておく必要があります。

DiffusionGemma は、自己回帰モデルと発想が違います。

• 自己回帰（Gemma4）: 左から1トークンずつ、逐次生成します
• 拡散（DiffusionGemma）: 1ステップで 256 トークンのブロックを並列にノイズ除去し、双方向注意の 256 トークン canvas で生成途中に自己訂正します

この構造だと、1トークンごとのオーバーヘッドに鈍感になりやすいです。だから、理屈の上では速くなり得る。理屈だけで終わらないのが今回のポイントで、実際に速かった、というところまで確認できました。

計測条件は、かなり揃えました。

• Vast.ai の 同一 RTX 5090
• 同一物理ホスト
• 同一 vLLM
• 同一 NVFP4 量子化
• --enforce-eager
• --gpu-memory-utilization 0.75
• --max-model-len 8192
• chat/completions
• 256トークン強制（ignore_eos）
• batch=1 のレイテンシ測定

結果は以下です。

• DiffusionGemma: warm 158 tok/s
• Gemma4: warm 18 tok/s

つまり 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 トークン で、きちんと答えに到達しています。

ただし、これをもって「拡散はコードが苦手」と一般化するのは早いです。あくまで この実行ではこう壊れた、という限定された証拠です。そう書いておくほうが、読後に使える判断材料になります。

今回の比較で、もうひとつ誠実に分けておきたい点があります。

• 二分探索 と debounce は、拡散・自己回帰とも概ね妥当に書けた
• 自己回帰側の末尾が切れているケースは、512トークンのサンプル上限によるもの
• これは 品質欠陥ではなく truncation です

この区別をしないと、評価が雑になります。

• truncation = 計測都合で途中までしか出ていない
• 真性バグ = 最後まで出たが中身が壊れている

今回の比較の価値は、ここを混ぜなかったことにあります。速い・遅いだけではなく、「何が出力切れで、何がロジック破綻か」を分けて見る。これ、地味ですが実務ではかなり効きます。

⚠️ RTX 5090 で DiffusionGemma を触るなら、まずここでつまずきます。

• 素の /v1/completions だと 即EOS で 1 トークンしか出ず、計測にならない
• chat/completions + ignore_eos + min_tokens が必要
• VRAM 不足の OOM は --gpu-memory-utilization 0.9 では厳しく、0.75 に下げると通った
• そのうえで --enforce-eager を付ける必要があった
• 初期化は約20分 と長い
• NVFP4 の MoE は非対応というより、Blackwell / SM120 で FlashInfer CUTLASS backend が選ばれて動く、という理解が近いです

実際に通った起動コマンドは、だいたいこの形でした（拡散側）。

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 を選ぶ理由

• 下書きを大量に吐きたい
• レイテンシをとにかく下げたい
• 多少の品質差を飲める
• ローカル 5090 で、まず速度の効きを見たい

Gemma4 を選ぶ理由

• 本番に出す文章の質が必要
• ロジック破綻を避けたい
• 生成結果の安定性を優先したい

Google 自身も最高品質には標準 Gemma4 を推奨しています。ここは無理に逆張りしないほうがいいです。

今回の結論は、きれいですが、かなり現実的です。速い拡散・正確な自己回帰。これが使い分けの軸です。

https://blog.google/innovation-and-ai/technology/developers-tools/diffusion-gemma-faster-text-generation/

https://www.inceptionlabs.ai/blog/introducing-mercury

https://openrouter.ai/inception/mercury-coder

• 速度比較は同一ホスト・同一設定での結果です。GPU・量子化・同時実行数（バッチ）が変わると tok/s は大きく変わります。
• 8.7 倍は --enforce-eager・batch=1 の latency です。高並列バッチでは差が縮みます。
• 品質サンプルは各課題 n=1 の単発結果です。「拡散はコードが苦手」と一般化はできません。
• Mercury の数値は公称引用で、自分の実測 tok/s とは計測環境（クローズドAPI・H100）が異なります。

• 計測日は 2026-06-15。同一の Vast.ai RTX 5090（同一物理ホスト）で、拡散 DiffusionGemma と自己回帰 Gemma4 を同一 vLLM・同一 NVFP4 量子化・--enforce-eager・--gpu-memory-utilization 0.75・--max-model-len 8192 で立ち上げました。
• 速度は chat/completions に 256 トークンを強制（ignore_eos）し、cold 1 本を捨てて warm 2 本（ブレ ±10% 以内）で確定しました。
• 品質は Python の括弧バランス判定・二分探索、TypeScript の debounce の 3 課題を各 1 回ずつ生成させ、生成結果をそのまま読みました（各 n=1）。
• ハードウェア構成・モデル設定・計測条件・実行日（2026-06）を併記しています。

拡散が速いなら、いつも拡散を使えばいい？

いいえ。速度最優先の下書き・大量生成・低レイテンシ用途なら拡散が有利ですが、本番に出す品質が要るなら自己回帰（Gemma4）です。Google 自身も最高品質には標準 Gemma4 を推奨しています。

自分の環境でも 8.7 倍になりますか？

GPU・量子化・enforce-eager の有無・バッチサイズで倍率は変わります。本記事は RTX 5090・NVFP4・eager・batch=1 の条件です。最適化条件では Google 公称の 約4倍に近づきます。

Mercury と DiffusionGemma はどちらを使うべき？

コード特化で品質も保ちたいなら商用の Mercury、オープン（Apache 2.0）で自前 GPU に載せたいなら DiffusionGemma、という住み分けです。本記事の実測対象は DiffusionGemma / Gemma4 のみです。

• META-MARK: GPU ランキング
• META-MARK: AIモデル別 GPU 選定ガイド

この記事は、実務で AI ツールを活用している開発者・技術者向けに書いています。

• BlogGemma 4 MTP drafter を今すぐ入れるべきか？ RTX 4070 Ti 12GB でつまずいた3つのポイントと結論RTX 4070 Ti 12GBでGemma 4 MTP drafterを実測。ドラフター0.14GB、ただし最速はvLLMの162.7 tok/s。導入判断を正直にまとめます。→
• Bloggemma4:12bがollamaで直った — 0.30.5で3層バグ全解消を実測確認【回避策は不要に】gemma4:12bのSIGFPE、macOS専用配布、日本語崩れを同一環境で実測。ollama 0.30.5で何が直り、何を捨ててよいかを整理します。→
• Bloggemma4:12bはollamaで動かない — 12GB GPUでllama.cpp実測52t/sの最短ルートollamaのHTTP 500やSIGFPEで詰まるgemma4:12bを、llama.cpp経由で12GB GPUに載せる実測手順と判断材料をまとめました。→

• 実際の構成を探すなら、GPU 比較ページやローカルLLM向け構成記事もあわせて見ると判断しやすいです。
• ハードウェア候補は用途別の AI 構成ガイドからたどると、単体製品より違和感なく検討できます。

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！