Google DiffusionGemma完全ガイド｜4倍速テキスト生成の仕組みと限界【2026年6月】
「コード補完の速度が変わった。ただしGemma 4を全部置き換えるつもりで使うと失望する」。Hacker Newsのスレッド（#48478471）でDiffusionGemmaを試した開発者たちが共通して述べたのは、このモデルの立ち位置だ。速さの価値は本物。万能の後継機として見ると期待外れ。
2026年6月10日、GoogleはDiffusionGemmaをApache 2.0ライセンスで公開した（公式ブログ）。H100上で1100トークン/秒超。従来の自己回帰モデルと比べて最大4倍の速度だ。重みはHugging Faceで誰でも入手できる。ただしGoogleは「実験的」と明示している。
- ローカルLLMの導入・更新を検討しているエンジニア
- コード補完やインライン編集の速度に不満がある開発者
- Gemma 4やLlama 4との違いを知りたい人
- テキスト拡散モデルの技術的な仕組みに興味がある研究者・学生
なぜ今、テキスト拡散モデルが注目されるのか
拡散モデルがテキスト生成に応用される試みは2021年から続いてきた。2023年10月にスタンフォード大のLou、Meng、Ermonが発表したSEDDが初めてGPT-2相当の品質に到達し、2024年6月のMDLM（NeurIPS 2024採択）が実用レベルに押し上げた。2025年にはInception LabsがMercuryという商用拡散LLMをAPIとして公開し、H100で1000トークン/秒を実証した。
そこにGoogleが2026年6月10日、Apache 2.0で無償公開したのがDiffusionGemmaだ。前日のFable 5リリース（入力$10/MTok、出力$50/MTok）との対比で「最速モデルが同日に有料で出て、翌日に無料の高速ローカルモデルが出た」という文脈は開発者コミュニティで強く意識された（Decrypt報道）。
アーキテクチャ：256トークンを一度に描く
従来の自己回帰モデル（Gemma 4、GPT-5.5等）は左から右へ1トークンずつ生成する。前のトークンが確定しないと次に進めない逐次処理だ。GPUの計算能力は余っているのにメモリ帯域がボトルネックになる。
DiffusionGemmaは発想が逆だ。まず256トークン分を「マスクされた状態」として一括で持ち、ノイズ除去を繰り返して全体を同時に確定させる。VentureBeatによれば、生成途中に「前後の文脈を見ながら自己修正」できるのが最大の特徴だ。双方向アテンションを使うため、すでに生成したトークンだけでなく「まだ確定していないトークンの文脈」も参照できる。これは自己回帰モデルでは構造的に不可能な動作だ。
MoE構造も速度に貢献している。総パラメータは25.2B（26Bクラス）だが、推論時に動くのは128エキスパートのうち8つのみ、実質3.8Bだ。Gemma 4 26Bと同じ計算コストで、diffusion処理によって1フォワードパスで複数トークンを同時確定できる。
スペックと動作要件
| 項目 | 値 |
|---|---|
| 総パラメータ | 25.2B（MoE） |
| 推論時アクティブ | 3.8B |
| 生成ブロックサイズ | 256トークン |
| コンテキストウィンドウ | 256K |
| H100速度（FP8） | 1,100+ トークン/秒 |
| RTX 5090速度 | 700+ トークン/秒 |
| RTX 4090速度（GGUF） | 200〜400 トークン/秒 |
| VRAM（NVFP4量子化） | 約18GB |
| ライセンス | Apache 2.0 |
Simon Willison（simonwillison.net）がプレビューで試したところ、2,409トークンを4.4秒で生成したと報告している。推論フレームワークはHugging Face Transformers、vLLM、SGLang、MLXに対応。OllamaはGGUFが存在するが通常版では動かず、llama.cpp の未マージPR（#24423）または専用CLIが必要だ（Zenn / lifona）。
なお、Apple SiliconでM3 Max（96GB RAM）で試したユーザーが6〜28トークン/秒しか出なかったとllama.cppのGitHub Issue #24529で報告している。速度優位はNVIDIA GPUのCompute-bound環境限定だ。
ベンチマーク：速さの代償
Google自身がモデルカードで正直に開示している品質差が重要だ。
| ベンチマーク | Gemma 4 26B（自己回帰） | DiffusionGemma | 差分 |
|---|---|---|---|
| MMLU Pro | 82.6% | 77.6% | -5.0pt |
| GPQA Diamond | 82.3% | 73.2% | -9.1pt |
| AIME 2026（数学） | 88.3% | 69.1% | -19.2pt |
数学推論で19ポイント以上の差が出る。Googleは「品質重視の本番用途にはGemma 4を推奨する」と明言している（公式ブログ）。速度を取るか品質を取るか、用途を明確にして選ぶ必要がある。
一方で強みがある分野もある。数独パズルデータセットでファインチューニングした実験では、ベースモデルの正解率0%が、わずか12回のデノイジングステップで80%に到達した（GIGAZINE）。双方向アテンションが、制約付き生成タスクで本領を発揮する例だ。
使うべき場面、避けるべき場面
向いている用途
- コードのインライン編集・補完: 双方向アテンションにより前後のコードを同時参照できる。FIM（Fill-in-the-Middle）が追加訓練なしでネイティブに動く
- 低レイテンシが要件のツール: バッチサイズ1〜8で最大のパフォーマンス。インタラクティブなコーディングアシスタント、リアルタイム文章補完に有利
- 制約付き生成タスク: テンプレート穴埋め、構造化テキスト生成、非線形なテキスト構造
- ローカルGPU単独運用: 月$10〜$200の従量課金を避けたい個人・スタートアップ向け
避けた方が良い用途
- 品質重視の本番環境: 数学・推論・コーディングベンチマーク全般でGemma 4より5〜19ポイント劣る。Google自身がGemma 4推奨と明言
- 高並列サーバーサービング: バッチサイズ32以上ではKVキャッシュ再利用の仕組みが自己回帰モデルと異なり、効率面で逆転する可能性がある
- ストリーミングチャットUI: 256トークンまとめてリリースする方式のため、1トークンずつ流れるチャット体験と相性が悪い
- Apple Siliconローカル: M3 MaxでH100比1/40程度の速度しか出ないという報告がある
開発者・ユーザーの声
リリース直後、Sundar Pichai（Google CEO）はXで「DiffusionGemmaは競走馬だ。256トークンを一度に生成することで最大4倍速い」と投稿した（出典）。
vLLMチームは「これがvLLMで正式サポートする初の拡散LLM」と発表し、H200で1,288トークン/秒（FP8）を独立検証した（vLLM Blog）。
Zennでは実際に試した開発者（lifona）が「RTX 5090 + llama.cpp PRで動かすのにかなり手間がかかった。通常のOllamaは不可。動いたときの速度は本物だが、日本語テキストの品質劣化バグがある」と報告した。
日本語コミュニティ（note.com）では「チャットは死んだ」という挑発的なタイトルの記事も登場（KeiTy）。拡散モデルが従来のChatGPT型UIを変える可能性を論じたものだ。Qiitaでは（picnic）ベンチマーク分析と双方向コンテキストの優位性が詳しく解説された。
Hugging FaceのMerve Noyan（@mervenoyann）は「4倍速でComputeバウンド。コーディングでも優れている」と評価した。
- Ollamaは未対応（2026年6月時点）。llama-diffusion-CLIまたはvLLMが必要
- 日本語テキストの品質劣化が報告されている。英語優先タスクでの利用が現状では無難
- Apple Siliconでの速度優位はない。NVIDIA GPU専用と考えること
- Google自身が「実験的リリース」と明示。品質重視の本番用途にはGemma 4を選ぶこと
Gemma 4の全モデルを比較する
DiffusionGemmaのベースとなったGemma 4ファミリーの全スペックと選び方を解説。
関連記事
- Google Gemma 4完全ガイド｜全4モデルの性能・実行環境を徹底比較
- Meta Llama 4完全ガイド｜Scout・Maverickの違いとローカル実行方法
- Claude Fable 5とMythos 5が米政府指令で停止した経緯と代替策
本記事の情報は2026年6月15日時点のものです。DiffusionGemmaは「実験的リリース」と明示されており、仕様・性能・対応ツールは今後変更される可能性があります。投資判断や業務利用の最終的な意思決定は、公式ドキュメントを確認のうえ自己責任で行ってください。
