10月23日、Karl Weinmeisterが「When to use a diffusion LLM: I compared DiffusionGemma and Gemma 4」と題した記事を公開した。拡散型LLM「DiffusionGemma」と自己回帰型LLM「Gemma 4」を同一アーキテクチャで直接比較し、タスクごとの得意・不得意を実験データで明らかにした内容だ。
拡散型LLMとは何か、なぜ今注目されているか
従来のLLMは自己回帰（AR）方式、すなわちトークンを左から右へ1つずつ生成する。この設計はシンプルで強力だが、「後に来る文脈を参照できない」という構造的制約を抱える。
これに対し、拡散型LLM（Diffusion LLM）は画像生成モデルで成功を収めた拡散過程をテキスト生成に応用したアプローチだ。出力全体をノイズから反復的に精製する仕組みにより、生成中のすべてのトークンが前後の文脈を双方向で参照できる。MDLMやPlaidといった研究がこの方向性を切り開き、近年は実用規模のモデルへの適用が急速に進んでいる。DiffusionGemmaはGoogleがその実験的実装として公開した成果だ。
比較が可能になった理由：同一バックボーン、異なるデコード方式
これまで拡散型LLMと自己回帰型（AR）LLMの比較は、モデルサイズや事前学習データが異なるため公平に行えなかった。Googleが実験的に公開したDiffusionGemma（26B-A4B）と、プロダクション向けのGemma 4（26B-A4B）は、どちらも同じMixture-of-Expertsバックボーン（26Bパラメータ、アクティブ4B）を共有しており、違いはデコード方式だけだ。これにより、アーキテクチャの差を排除した純粋な比較が初めて可能になった。
ブロック拡散の仕組み
DiffusionGemmaは「ブロック拡散（block diffusion）」と呼ばれる手法を採用している。動作の流れは以下のとおりだ。
- プロンプトをKVキャッシュに読み込む
- 256トークンの出力キャンバスをランダムトークンで初期化する
- 複数パスでブロック全体を並列に精製する
- 確信度の低いスロットを再ランダム化しながら繰り返す
- 全256スロットの平均エントロピーが閾値を下回ったら停止する
ARモデルが左から右へ1トークンずつ生成するのに対し、DiffusionGemmaはブロック内で双方向アテンションを使う。つまり、草稿中のすべてのトークンが前後の文脈を参照できる。これは拡散型LLM全般に共通する設計思想であり、DiffusionGemmaに固有の特性ではない。
ただし、停止条件に設計上の課題がある。50トークンの短い回答の後に残る約200スロットはほぼ確実にパディングになるため、平均エントロピーが早々に閾値を下回り、5〜8パスで収束する。内容トークンがまだ安定していない場合でも終了してしまう。この挙動は、特に構造化出力タスクにおいて後述するJSON生成の品質低下（200件中14件のパース失敗）として数字に現れており、本番運用上の懸念点となっている。
実験の概要
テストはGoogle Cloud Run Jobs上でNVIDIA RTX PRO 6000 Blackwell GPUを使用し、バッチサイズ1で実施。10タスクにわたり各200プロンプト（MMLU-Proのみ400）を投入した。
DiffusionGemmaが勝るケース
入力が答えを強く制約するタスク
コピー編集（CoEdIT）では、DiffusionGemmaがSARIスコア0.651 vs. 0.629でGemma 4 ARを上回り、かつ2.7倍高速だった。
- 入力文： "I also believe it would hard to get students to come to schools or stay out schools with session"
- DiffusionGemma： "I also believe it would be hard to get students to come to school or stay after school for sessions."
- Gemma 4 AR： "I also believe it would be difficult to get students to attend school or stay after school for sessions."
DiffusionGemmaは壊れたトークンだけを直し、"hard"や"come to"はそのまま残す。Gemma 4 ARは文法を直しつつ、正常だった語彙まで書き換えてしまう。入力を双方向で参照できるため、必要最小限の修正で収まったと考えられる。
答え→根拠の順序でJSONを出力するタスク
ARモデルの設計上の弱点として知られているのが、「先に総計を書いてから、根拠を書く」順序のJSON出力だ。PII（個人識別情報）を除去し、span_countをredacted_textより先に出力させたところ、Gemma 4 ARはspan_countが自身の[REDACTED]タグ数と一致した割合が**38%にとどまった。DiffusionGemmaは51%**と改善したが、これも本番運用には不十分だ。著者はどちらのモデルでも、カウントはアプリ側コードで行うよう推奨している。
Gemma 4 ARが勝るケース
推論チェーンを伴うタスク
5-shot MMLU-Proでは、Gemma 4 ARが0.792 vs. 0.752と4ポイント上回った。ステップバイステップの推論は各ステップが前のステップの正確な文言に依存するため、左から右へ確定させるARデコードが有利に働く。
構造化JSON出力の安定性
200件のドキュメント処理で、Gemma 4 ARはすべてでJSONのパースに成功した。DiffusionGemmaは14件がjson.loads()に失敗（エスケープ漏れや閉じ括弧後の余分な出力が原因）。Outlinesのような制約付きデコードツールはプレフィックスベースの設計のため、固定プレフィックスが存在しない拡散キャンバスには直接適用できない点も課題だ。
コード補完：インデントは正確、停止が問題
Pythonのコード補完（HumanEval-Infilling）では、正規化前のpass@1がDiffusionGemma 0.475 vs. Gemma 4 AR 0.335と大差がついたが、その差の大半はホワイトスペースと停止動作の違いによるものだった。
- Gemma 4 ARは先頭のインデント（4スペース）を落とす傾向がある
- DiffusionGemmaはインデントを正確に保つが、256トークンキャンバスを埋めるため、関数の残りを繰り返し書いてしまう
インデントを正規化した後の精度はほぼ同等（0.710 vs. 0.750）。1行補完のIDE用途ならGemma 4 ARのほうが1.6倍高速で、後処理も簡単だ。
まとめ：タスク別の使い分け指針
| タスク | 推奨モデル |
|---|---|
| コピー編集・最小限の書き換え | DiffusionGemma（速度・品質ともに有利） |
| タグ付き翻訳 | 同等（DiffusionGemmaが2倍速） |
| 答え先行JSON（span_count等） | DiffusionGemma（ただし本番には不十分） |
| 段階的推論（MMLU-Pro等） | Gemma 4 AR |
| 構造化JSON（安定性重視） | Gemma 4 AR |
| 競技数学（MATH-500） | ほぼ同等 |
| 1行コード補完 | Gemma 4 AR（速度・シンプルさで優位） |
DiffusionGemmaは入力が答えを強く制約するタスク（コピー編集、タグ保持翻訳）と、答え先行スキーマで真価を発揮する。一方、推論チェーンや厳密なJSON出力が求められる場面ではGemma 4 ARが安定している。
詳細はWhen to use a diffusion LLM: I compared DiffusionGemma and Gemma 4を参照していただきたい。
