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

こんにちは。梅雨のじめじめした日が続きますが、今回はスカッとする速さの話から始めます。

同じ RTX 5090・同じ条件で比べると、拡散型の DiffusionGemma は、ふつうの Gemma4 の 8.7 倍の速さで文章を出しました。ただ、速さの代わりに品質を払っています。Google 自身も「全ベンチマークで Gemma4 に劣る」と明言していて、私の実機でも、拡散側は括弧の対応をチェックするコードを壊して書きました。速さ最優先の下書きや大量生成なら DiffusionGemma、本番に出す品質が要るなら Gemma4。これが今回の結論です。

比べたのは、Google が 2026-06-10 に公開した拡散言語モデル DiffusionGemma と、同じサイズ・同じ NVFP4 量子化量子化（Quantization）AI モデルの数値を少ない桁数で表し直して、ファイルと必要なメモリを小さくする手法。詳しく →（モデルを軽く圧縮して載せる方法）の Gemma4 です。拡散 LLMLLM（大規模言語モデル）大量の文章で学習し、人のように文章を読み書きできる大きな AI のモデル。詳しく → は速い、という話は前からありましたが、「本当にその差が出るのか」「速い代わりに何を失うのか」は、実機で回さないと分かりません。同一の 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 倍という数字は、同じホスト・同じ vLLM・同じ設定で並べた結果です。条件をそろえたうえでの差なので、速さそのものは本物だと見ています。

ただ、ここを「速いほうが勝ち」で片付けると、実際に使う場面で困ります。Google は公式ブログで「全ベンチマークで DiffusionGemma は Gemma4 26B A4B に劣る」「最高品質が要るなら標準 Gemma4 を推奨」と書いています。作った本人がそう言っている以上、速さと品質は分けて考えるのが筋です。

使い分けを一言で書くと、こうなります。

• 速さ最優先の下書き・大量生成・レイテンシレイテンシ（遅延）操作や要求をしてから、その結果が返ってくるまでにかかる待ち時間。詳しく →（返事が返ってくるまでの待ち時間）を下げたい用途 → DiffusionGemma
• 本番に出す品質が必要 → Gemma4

Gemma4 のような「自己回帰」のモデルは、文章を左から1トークン（単語のかけら）ずつ順番に書いていきます。一方の DiffusionGemma は、256 トークンのかたまりを一度に用意して、ノイズを取り除くように並列で仕上げていきます。256 トークン分の下書き用紙（canvas）を前後両方向から見渡せるので、書いている途中で自分の誤りを直すこともできます。

1トークンずつ書くたびに発生する手間に左右されにくいので、理屈の上では速くなり得ます。今回確かめたかったのは、その理屈が実機でも数字に出るかどうかで、結果ははっきり出ました。

計測条件は次のとおりそろえています。計測日は 2026-06-15 です。

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

速さの単位は tok/s（1秒あたりに出せるトークン数）です。最初の1本（cold）は準備運動として捨て、温まった後の2本（warm・ブレ ±10% 以内）で確定させました。

• 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、つまり1人が1つずつ頼んだときの待ち時間だという点です。この使い方では差がよく効きますが、たくさんの依頼を同時にさばく高並列の使い方では差が縮むことがあります。手元の 5090 で、自分の目の前に返ってくる速さを知りたいなら、batch=1 の値を見るのが合っています。

Google の公称は、最適化した条件で 約4倍 です。私の実測は 8.7倍 と、公称より開きが大きく出ました。

これはどちらかが間違っているというより、条件の違いです。鍵になっているとみているのが --enforce-eager です。32GB の 5090 に収めるにはこの設定がほぼ必須でしたが、これは自己回帰側に不利に働きます。自己回帰は CUDA グラフ（GPU への命令をまとめて流す仕組み）の恩恵を受けやすいのに、eager ではそれが使えません。拡散は 256 トークン単位で並列に進むので、1トークンごとの手間の影響をもともと受けにくい。だから eager 条件では差が開きやすい、という読みです。

ただし、Google の4倍は H100＋最適化済みのソフト、今回は 5090＋素の vLLM＋eager で、ハードもソフトも違います。eager を主な原因とみていますが、そこだけを切り分ける実験まではしていないので、ここは推定です。どちらにしても、「約4倍」と「8.7倍」は、拡散が大幅に速いという同じ方向を指しています。

品質は、Python の括弧バランス判定・二分探索、TypeScript の debounce の 3 課題を、それぞれ 1 回ずつ（各 n=1）生成させ、出てきたコードをそのまま読みました。

差がはっきり出たのは、括弧の対応が取れているかを調べる 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 と、) が1つ多い構文エラーがありました。

これは出力が途中で切れたせいではありません。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 トークンで、きちんと答えまでたどり着きました。

ただ、これだけで「拡散はコードが苦手」と言い切るのは早いです。各課題 1 回ずつの単発結果なので、言えるのは この実行ではこう壊れた というところまでです。

残りの2課題、二分探索と debounce は、拡散・自己回帰とも概ね妥当に書けていました。Gemma4 側の出力が末尾で切れているものはありますが、これは 512 トークンというサンプルの上限に当たっただけで、品質の欠陥ではなく truncation（出力切れ）です。

私が比べるときに混ぜないようにしているのが、この2つの区別です。

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

ここを一緒にすると、「途中で切れたから負け」のような雑な評価になってしまいます。速い・遅いに加えて、何が出力切れで何がロジックの破綻かを分けて見ておくと、実際に使うときの判断材料として残ります。

RTX 5090 で DiffusionGemma を動かすなら、まずここでつまずくはずです。

• 素の /v1/completions だと 即EOS（すぐ「終わり」の合図を出す）で 1 トークンしか出ず、計測にならない
• chat/completions + ignore_eos + min_tokens が必要
• VRAMVRAMグラフィックボードに載っている、GPU 専用の高速なメモリ。詳しく → 不足の 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 を思い浮かべる方もいると思います。ただ、この2つは分けて考えたほうがいいです。

Mercury は Inception Labs の商用の拡散 LLM で、コード向けに特化しています。公称では Copilot Arena で速度 1 位・品質 2 位タイ、H100 で 1109 tok/s（Mini）、HumanEval 88-90% と、品質もかなり保っています。

一方の DiffusionGemma は汎用のオープンモデル で、ライセンスは Apache 2.0、vLLM にネイティブ対応した初の拡散 LM です。

Mercury はクローズドなので、私は測っていません。上の数字は公称の引用で、計測環境（クローズドな API・H100）も今回の実測とは違うため、対決表にはしていません。住み分けとしては、コード特化で品質も保ちたいなら商用の Mercury、オープンなモデルを自分の GPU に載せたいなら DiffusionGemma、という形になります。

最後に、どちらを使うかの判断に落としておきます。

DiffusionGemma を選ぶ理由

• 下書きを大量に出したい
• レイテンシをとにかく下げたい
• 多少の品質差を飲める
• 手元の 5090 で、まず速さの効き目を見たい

Gemma4 を選ぶ理由

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

自分の環境でも 8.7 倍になるかというと、そうとは限りません。GPU・量子化・enforce-eager の有無・同時に処理する数（バッチ）で倍率は大きく変わります。今回は RTX 5090・NVFP4・eager・batch=1 の条件で、最適化した条件なら Google 公称の約4倍に近づきます。

Google 自身も、最高品質には標準 Gemma4 を勧めています。ここは無理に逆張りしないほうがいいと私は考えています。速い拡散と、正確な自己回帰。これが使い分けの軸です。

Gemma4 をローカルの GPU で動かす話は、Gemma 4 MTP drafter を今すぐ入れるべきか？ RTX 4070 Ti 12GB でつまずいた3つのポイントと結論 でも書いています。

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

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

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