Google、DiffusionGemmaでテキスト生成を最大4倍高速化へ

Google は 2026年6月10日、テキスト拡散を使う実験的なオープンモデル「DiffusionGemma」を発表しました。自己回帰型の LLM がトークンを順番に生成するのに対し、DiffusionGemma はブロック単位でテキストを並列に生成・修正する設計で、専用 GPU 上では最大4倍の高速なテキスト生成を狙うモデルです。

要点

• DiffusionGemma は、Gemma 4 ファミリーを土台にした 26B Mixture of Experts の実験的オープンモデルです
• テキスト拡散により、256トークン規模のブロックをまとめて生成・修正し、低レイテンシのローカル推論を狙います
• Google は、専用 GPU で最大4倍の高速化、H100 で 1000トークン/秒超、GeForce RTX 5090 で 700トークン/秒超という目安を示しています
• 速度の利点は、低から中程度のバッチサイズや1ユーザー向けのローカル実行で特に出やすい一方、高 QPS のクラウド配信では利点が薄れる場合があります
• 実験的モデルであり、品質が最優先の用途では標準の Gemma 4 を使う判断も残ります

今回のブログ記事で語られていること

Google Blog の記事は、DiffusionGemma を単なる「Gemma の新モデル」としてではなく、テキスト生成の作り方を変える実験として説明しています。従来の多くの LLM は、前のトークンを受けて次のトークンを1つずつ出すため、1人のユーザーがローカル GPU で使う場面では、計算資源を十分に使い切れないことがあります。DiffusionGemma はこの前提を変え、ランダムなトークン列から始めて、複数回の更新で文章全体を整えていく方式を採ります。

記事で強調されている数字は、専用 GPU 上で最大4倍の高速なテキスト生成、H100 で 1000トークン/秒超、GeForce RTX 5090 で 700トークン/秒超という点です。ただし、この数字は「どんな環境でも一律に4倍速い」という意味ではありません。Google は、低から中程度のバッチサイズ、単一アクセラレータ、ローカルや低同時実行の推論で特に利点が出やすいと説明しています。逆に、高 QPS のクラウドサービングでは自己回帰型モデルでも計算資源を飽和させやすく、DiffusionGemma の並列デコードがコスト面で不利になる可能性にも触れています。

モデルの構成としては、26B の Mixture of Experts で、推論時には 3.8B パラメータを活性化する設計です。量子化すれば 18GB VRAM 程度の高性能コンシューマー GPU に収められるとされ、ローカルのインライン編集、素早い試行錯誤、コード補完、非線形なテキスト構造の生成などが想定ユースケースとして挙げられています。256トークンを並列に扱い、双方向の注意機構で文章ブロック全体を見ながら修正できる点も、通常の左から右への生成とは異なる読みどころです。

一方で、記事は DiffusionGemma を本番向けの万能置き換えとしては位置づけていません。速度と並列生成を優先するため、全体的な出力品質は標準の Gemma 4 より低いと説明されており、品質を最優先する用途では標準の Gemma 4 が推奨されています。つまり、今回の発表は「より速いモデルが出た」というだけでなく、ローカル推論、低レイテンシ UI、リアルタイム編集、研究用途で、自己回帰型とは別の生成方式を試す材料が増えたと読むべきです。

提供面では、Hugging Face での重み配布、開発者ガイド、vLLM、Transformers、MLX、Unsloth、NVIDIA NeMo などの周辺ツールへの言及があります。Google は NVIDIA との最適化にも触れており、RTX 5090/4090、Hopper、Blackwell、DGX Spark、DGX Station、RTX PRO などでの利用経路を示しています。これは、モデル発表と同時に、ローカル・ワークステーション・エンタープライズ GPU の実行環境を広く想定しているということです。

実務で確認したいポイント

まず確認すべきなのは、自社の用途が DiffusionGemma の強みと合っているかです。低レイテンシのローカル補完、インライン編集、短い反復生成、ユーザー単位の対話的ワークフローでは検証する価値があります。一方で、高品質な長文生成、厳密な推論、安定した本番 API、同時実行が多いクラウドサービングでは、標準の Gemma 4 や別の自己回帰型モデルとの比較が必要です。

次に、速度の測定条件を固定する必要があります。GPU 種別、VRAM、量子化設定、バッチサイズ、プロンプト長、出力長、ランタイム、温度などが変わると、最大4倍という数字の意味も変わります。既存モデルと同じプロンプトを流すだけでなく、DiffusionGemma が想定する 256トークン単位の並列生成や編集型タスクで評価するのが現実的です。

最後に、実験的オープンモデルとしての運用ルールも確認してください。ライセンス、モデル取得元、社内データとの接続範囲、ログ、評価データセット、ガードレール、失敗時のフォールバックを決めないまま高速化だけを理由に導入すると、品質や安全性の問題を見落とします。

今回のブログ記事が関係する人

• ローカル GPU やワークステーションで LLM 推論を高速化したい機械学習基盤チーム
• エディタ、コパイロット、エージェント UI など、応答遅延が体験に直結する機能を作る開発チーム
• Gemma 系オープンモデルを評価しており、標準の自己回帰型モデル以外の選択肢を試したい研究・検証チーム
• NVIDIA GPU、vLLM、Transformers、MLX、Unsloth などの実行環境を運用するインフラ担当者

結局、今回のブログ記事をどう読むべきか

DiffusionGemma は、Gemma ファミリーに新しい速度重視の選択肢が加わった発表です。ただし、読むべき中心は「最大4倍」という数字そのものではなく、テキスト生成を逐次処理からブロック単位の並列更新へ寄せることで、どのワークロードに新しい設計余地が生まれるかです。

実務では、まずローカル推論や低同時実行のインタラクティブ用途に絞って、既存の Gemma 4 や Gemini 系モデルと速度、品質、コスト、安定性を比較するのが妥当です。品質が最優先の業務処理へすぐ置き換える発表ではなく、低レイテンシ体験を作りたいチームが、限定された検証環境で評価すべき新しいモデルとして扱うのが安全です。