DiffusionGemma：Googleが拡散モデルをテキスト生成に持ち込む

Google DeepMind が DiffusionGemma を公開しました。Gemma 系列の中でも実験色の強い新しい分岐です。従来の大規模言語モデルのように「一度に 1 token を予測する」自己回帰の道をそのまま進むのではなく、拡散モデルの考え方をテキスト生成に持ち込んでいます。まずノイズを含むテキストキャンバスを作り、複数回のデノイズを通じて段落全体を徐々に収束させます。

Google の位置づけは明確です。これは研究者と開発者が低遅延のローカル対話型テキスト生成ワークフローを探るための実験的オープンモデルであり、標準 Gemma 4 を全面的に置き換える本番品質モデルではありません。

まず要点

項目	DiffusionGemma
公開日	2026-06-10
モデル種別	実験的オープンモデル
基盤	Gemma 4 backbone + Gemini Diffusion research
アーキテクチャ	26B total Mixture of Experts、推論時は 3.8B パラメータをアクティブ化
生成方式	256-token canvas に対する並列デノイズによるテキスト拡散
ライセンス	Apache 2.0
速度目標	専用 GPU で最大約 4x のテキスト生成速度向上
典型的なハードウェア	量子化後は高性能コンシューマー GPU の 18GB VRAM 範囲でデプロイ可能
入手方法	Hugging Face、Kaggle、Google Cloud Model Garden

注目すべき点は二つあります。第一に、これは小型モデルではなく 26B MoE です。第二に、推論時にアクティブになるのは 3.8B パラメータだけで、生成のボトルネックをできるだけメモリ帯域から計算へ移そうとしています。

普通の LLM と何が違うのか

従来の自己回帰 LLM はタイプライターのように、左から右へ 1 token ずつ生成します。この方式は安定して成熟しており、高品質な長文出力にも向いています。ただしローカルで単一ユーザーが推論する場面では現実的な問題があります。GPU が十分に使われないことが多く、ボトルネックは重みの反復読み出しと token ごとのデコードになりがちです。

DiffusionGemma は別の考え方を取ります。最初に 256 token のランダムなプレースホルダーキャンバスを作り、その後で複数回の並列 refinement を行います。各ラウンドではキャンバス上の token が互いに見えます。モデルは前の文脈だけを見るのではなく、ブロック内で双方向 attention を使えます。

これにより、次の三つの結果が生まれます。

生成は厳密な左から右ではなく、ブロック全体が一緒に収束する。
生成中に前の位置の誤りを修正できる。
コード infilling、インライン編集、形式の閉じ、数独のような非線形制約タスクにより自然に対応できる。

つまり DiffusionGemma は「同じ道でより大きなモデル」を追うのではなく、テキスト生成の別ルートを試しています。テキストを、繰り返し磨けるキャンバスとして扱うという発想です。

なぜ速くなる可能性があるのか

Google が繰り返し強調している要点は、DiffusionGemma がボトルネックを memory bandwidth から compute へ移そうとしていることです。

自己回帰モデルは 1 token を生成するたびにモデル重みへ何度もアクセスします。単一ユーザー、ローカル推論、低 batch の場面では、GPU の計算能力が十分に使われないことがあります。DiffusionGemma は一度に 256 token canvas を処理するため、GPU に大きな並列仕事を与え、tensor cores を動かしやすくします。

Google が示した数値は次の通りです。

単一の NVIDIA H100 で 1000 tokens/s 超。
NVIDIA GeForce RTX 5090 で 700 tokens/s 超。
専用 GPU で最大約 4x のテキスト生成速度向上。

ただし、この速度には境界があります。Google も、DiffusionGemma の加速効果は主にローカル、低同時実行、単一アクセラレータ、低〜中程度 batch の推論に向くと説明しています。高 QPS のクラウドサービスでは、自己回帰モデルが大きな batch によってハードウェアを使い切れるため、DiffusionGemma の並列デコードの優位性は小さくなり、場合によってはサービングコストが上がることもあります。

ここは重要です。これはあらゆるデプロイの万能アクセラレータではなく、「ローカルのリアルタイム対話」に向けた新しい道筋に近いものです。

アーキテクチャはどう動くのか

開発者ガイドでは、より具体的な説明があります。DiffusionGemma の生成過程は二つの段階に分けられます。

Prefill / Incremental Prefill

causal attention を使って prompt を読み取り、文脈を KV cache に書き込みます。長文の場合、モデルは各 256-token block が完了した後、その結果を KV cache にコミットし、次のブロックを処理します。
Denoising

bidirectional attention を使って現在の canvas を反復的にデノイズします。現在ブロック内の query token は、キャンバス上の他の token を見られるだけでなく、すでに KV cache に書き込まれた過去の文脈も利用できます。

この設計は block autoregressive denoising と呼ばれます。順序性を完全に捨てるのではなく、長文ではブロック間の順序安定性を保ちながら、各ブロック内部を並列生成します。

この折衷は合理的です。完全並列では長文の一貫性が難しく、完全自己回帰では逐 token のボトルネックに戻ります。DiffusionGemma は「ブロック間は順序、ブロック内は拡散」を選んでいます。

向いている場面

DiffusionGemma が最も向いているのは普通のチャットではなく、低遅延、高速な書き換え、局所補完、全体制約が必要な対話的場面です。

典型的には次のような方向があります。

インライン編集：ユーザーが一文を変更し、モデルが局所的な置換をすばやく補う。
コード infilling：ファイルの先頭から末尾まで書くのではなく、途中の穴を埋める。
Markdown / JSON / XML などの形式の閉じ：モデルが出力ブロック全体を同時に見られるため、括弧、タグ、リスト構造を修正しやすい。
非線形テキスト構造：グラフ、表、数独、アミノ酸配列、数学的グラフ構造など。
ローカルのリアルタイムツール：入力中に更新が必要な開発者ツール、エディタプラグイン、デスクトップ AI アシスタント。

公式開発者ガイドには数独 fine-tuning の例もあります。ベースモデルは数独を解くために特別に訓練されておらず、成功率はほぼ 0% です。しかし簡単な JAX SFT recipe で微調整すると、数独タスクの正答率が 80% に上がり、推論ステップ数も減ります。この例が示したいのは「数独向けモデル」ということではなく、双方向デノイズが強い制約、多変数、全体整合性を必要とするタスクに向いているという点です。

向いていない場面

DiffusionGemma はまだ実験モデルであり、速度だけを見て判断するべきではありません。

Google は明確に、速度と並列レイアウト生成を優先しているため、全体的な出力品質は標準 Gemma 4 より低いと述べています。最高品質を求めるアプリケーションでは、標準 Gemma 4 のデプロイが推奨されます。

また、次の場面には必ずしも向きません。

高品質な長文執筆。
高同時実行のクラウド API サービス。
出力安定性と事実正確性が非常に重要な本番タスク。
Apple Silicon の統一メモリアーキテクチャに主に依存するローカル推論。

最後の点も公式説明に由来します。DiffusionGemma の加速はアクセラレータ上の高い arithmetic intensity に依存します。Apple Silicon のような統一メモリアーキテクチャは推論時にメモリ帯域に制約されやすく、自己回帰モデルに対する同等の相対加速が見えない可能性があります。

デプロイとツールチェーン

DiffusionGemma は Hugging Face から重みを取得でき、Kaggle と Google Cloud Model Garden からもアクセスできます。公式開発者ガイドには vLLM のローカル OpenAI-compatible server の例があります。

1
2
3
4
5
6
7
8
9


vllm serve google/diffusiongemma-26B-A4B-it \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --gpu-memory-utilization 0.85 \
  --attention-backend TRITON_ATTN \
  --generation-config vllm \
  --hf-overrides '{"diffusion_sampler": "entropy_bound", "diffusion_entropy_bound": 0.1}' \
  --diffusion-config '{"canvas_length": 256}' \
  --enable-chunked-prefill

公式が触れているエコシステムには次のものがあります。

vLLM
Hugging Face Transformers
SGLang
MLX
Hackable Diffusion
Unsloth
NVIDIA NeMo
NVIDIA NIM

さらに、llama.cpp 対応も近日中とされています。ローカルモデル利用者にとって重要なシグナルですが、実際に対応が入るまでは、動くツールチェーンを基準に確認する必要があります。

Gemma 4 との関係

DiffusionGemma は Gemma 4 の代替品ではありません。Gemma 4 ファミリー上の実験的分岐に近いものです。

次のように考えられます。

標準 Gemma 4：品質優先の本番出力に向く。
DiffusionGemma：速度優先、低遅延、ローカル対話、非線形生成の探索に向く。

Gemma 4 backbone と Gemini Diffusion 研究の上に作られていますが、目的は単純に benchmark を上げることではありません。テキスト拡散が開発者ワークフローを変えられるかを検証することです。特に、自己回帰生成方式が苦手としてきたリアルタイムエディタ、コード中間補完、構造化コンテンツの即時修正などが対象になります。

注目する理由

DiffusionGemma が注目に値するのは、すぐに「最強テキストモデル」になるからではありません。テキスト生成の基本仮定を少し横にずらしているからです。

ここ数年、テキストモデルはほぼ自己回帰路線が前提でした。この路線は成熟していますが、出力を自然に線形過程にします。先に前半を書き、その後を書き、早い段階で書いた誤りは戻って修正しにくい。拡散式テキスト生成は別の可能性を出します。まず全体を組み、局所を繰り返し修正し、ブロック全体を一緒に明瞭にするという方法です。

これは開発者ツールに特に想像の余地があります。実際の編集は空白文書から下へ一直線に書くものではありません。挿入、削除、補完、形式修正、局所修正、中間の穴埋めが含まれます。DiffusionGemma の構造は、この「局所編集 + 全体制約」に近いものです。

まとめ

DiffusionGemma は実験的オープンモデルであり、中心的な見どころは、従来の逐 token 生成をテキスト拡散とブロック内並列デノイズで置き換えることです。専用 GPU、ローカル低同時実行、リアルタイム対話の場面では明確な速度優位をもたらす可能性があり、インライン編集、コード補完、構造化テキスト、多変数制約タスクにも向いています。

ただし、Gemma 4 の本番品質代替ではありません。現段階では研究、ツールプロトタイプ、開発者実験に向きます。選定時には「汎用最強モデル」ではなく、「低遅延対話モデル」の欄に置くべきです。

参考資料：