DiffusionGemma: 4倍速のテキスト生成

2026年6月11日原文(blog.google)

概要

DiffusionGemma は、Google AIが公開した新しい高速テキスト生成モデル
最大4倍の推論速度 を専用GPUで実現、インタラクティブなローカルワークフロー向け
Mixture of Experts（MoE） 構造により高効率、18GB VRAMで動作可能
双方向アテンション と自己修正機能で非線形テキスト生成や編集に強み
実験的なモデルであり、高品質出力には従来のGemma 4推奨

DiffusionGemma：超高速テキスト生成モデルの登場

DiffusionGemma は、テキスト拡散（text diffusion）という新手法を採用した オープンソース実験モデル
Apache 2.0ライセンス で公開、研究者や開発者が自由に利用可能
26B Mixture of Experts（MoE） 構造、推論時は 3.8Bパラメータ のみ活性化
従来の自己回帰型LLM （1トークンずつ生成）とは異なり、 256トークンを同時生成
Gemma 4ファミリー の知能効率と Gemini Diffusion研究 を基盤に開発

主な特徴と利点

推論速度の大幅向上 ：専用GPU上で 最大4倍速、NVIDIA H100で 毎秒1000トークン超
ハードウェア要件の低減 ：量子化時、 18GB VRAM のハイエンドGPUで動作
双方向アテンション ：すべてのトークンが相互に参照でき、 非線形編集やコード補完 に有利
自己修正機能 ：生成ブロック全体を一度に評価・修正できるため、 リアルタイムでの誤り訂正 が可能
ローカル・インタラクティブ用途 に最適化、 インライン編集や高速反復 作業に強み

注意点と推奨事項

出力品質はGemma 4より劣る ため、 最高品質が必要な用途はGemma 4 を推奨
ファインチューニング により特定タスクで性能向上可能
- 例：UnslothによるSudoku解決のファインチューニング
高QPSクラウド用途 では利点が減少し、 コスト増加の可能性
Apple Silicon Mac など ユニファイドメモリ型 では速度向上が限定的

テキスト拡散方式の仕組み

AI画像生成 の拡散モデルと同様、 ノイズから段階的に洗練
- キャンバス ：ランダムなプレースホルダトークンから開始
- 反復精緻化 ：複数回パスで正解トークンを確定、文脈手がかりとして他を修正
- 最終仕上げ ：高品質なテキストへ収束
全体ブロック処理 により、 複雑なMarkdownやコード生成 もリアルタイムで実現

導入・活用方法

Hugging Face で モデル重み公開、 Apache 2.0ライセンス でダウンロード可能
DiffusionGemma開発者ガイド や ビジュアルガイド で詳細解説
MLX、vLLM（Red Hat対応）、Hugging Face Transformers で効率的にサーブ
Hackable Diffusion（JAXツールボックス） でファインチューニング実験が可能
- Unsloth、NVIDIA NeMo によるファインチューニングもサポート
- llama.cpp への公式対応も近日予定
NVIDIAハードウェア最適化 済み（RTX 5090/4090、Hopper、Blackwell等）
- NVFP4（4bit浮動小数点） 対応で高速・高精度推論
- DGX Spark、DGX Station、RTX PRO などエンタープライズ環境でも利用可能
Gemini Enterprise Agent Platform Model Garden や NVIDIA NIM 経由でクラウド実行も可能

まとめ

DiffusionGemma は、 スピード重視のローカルAIアプリケーション に新たな選択肢を提供
インタラクティブな編集、非線形生成、リアルタイム応答 などの用途に最適
高品質が必須の場合は従来のGemma 4 を活用し、 用途に応じて使い分け が推奨

Hackerたちの意見

数日前、Googleが1年前のI/Oでデモをした拡散テキスト生成モデルについて全然話さないなって思ってたんだ。噂では運用コストが高すぎるって言われてるけど、同じ1x H100ハードウェアを使ったチャートを見る限り、DiffusionGemmaと通常のGemmaを比較してもそうは思えない。Gemmaよりちょっと性能が劣る以外に、このスピードのデメリットは何なんだろうって気になる。

└

このスピードのデメリットが何なのか気になる。「DiffusionGemmaのスピードアップは、ローカルでの低並列推論向けに設計されています。高QPSのクラウドサービスでは、自己回帰モデルを展開して効率的に計算を満たすことができるため、DiffusionGemmaの並列デコーディングはリターンが減少し、サービングコストが高くなる可能性があります。」

└

標準の自己回帰モデルでは、例えば256人のユーザーがいる場合、一度に256トークンを生成できるけど、このアプローチでは一人のユーザーのために256トークンを生成するには、いくつかのフォワードステップが必要になる。だから、拡散プロセスはもっと多くのGFLOPsを必要とする。ユーザーが十分にいる場合、メモリと計算をバランスさせることができるんだ。

DiffusionGemmaのようなテキスト拡散モデルがどう機能するかの良いビジュアル説明: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

これが未来だと思う。5年後には大きな変化に繋がるような、ちょっと意外な動きだね。

└

これがローカルモデルの未来かもしれない。ただ、拡散モデルはテキストに関して自己回帰モデルよりも若干性能が劣るから、パフォーマンスは少し落ちる。スピードが大きな利点なんだけど、ローカル推論の自己回帰モデルは主にメモリに依存してる。トークンを一つずつ処理するから、各トークンごとに全ての重みを読み込む必要があるんだ。MTPは小さいモデルでトークンをドラフトして、大きいモデルで並行して検証することで少し助けてくれるけど、トークンを順番に処理する必要があるし、無効なドラフトトークンを捨てる必要もあるから、スピードアップには限界がある。でも、ホスティングされたモデルでは、多くのトークン生成をバッチ処理できるから、計算をフルに活用できてメモリ帯域幅のボトルネックがなくなる。だから、すでにほぼ最大効率で動いてるんだ。ホスティングされたモデルでは、拡散の利点が薄れてしまう。確かに、自己回帰モデルで多くのユーザーに並行して応答する代わりに、一人のユーザーに対して拡散を行うことでわずかに遅延を減らすためにお金を払うこともできるかもしれないけど、それが精度を下げることを考えると、どこで本当にそれを求めるのかは難しい。自己回帰モデルと同等の性能に持っていけない限り、ローカルモデル以外ではあまり意味がない気がする。

└

現状のままだと、ほぼ確実に無理だと思う。あまり進展がない理由は、拡散モデルと自己回帰モデルの間に質のギャップがかなり大きいから。ここでのベンチマークを見てみれば、大きな落ち込みがあって、一番難しいベンチマークでの落ち込みが一番大きい。さらに、拡散モデルのスピードの利点はスケールでほぼ無効化されるから、これはローカルモデルの開発にしか魅力がない。ローカルモデルを訓練しているほとんどの人は、やっぱり質と推論効率を重視してるからね。

最近、OpenCodeに切り替えて、アメリカ以外のフロンティアラボのモデルをいくつか試してみたんだ。意外にもお気に入りになったのはMercury（拡散モデル）だった。賢いからじゃなくて、めっちゃ速かったから。プロンプトを出して待つというSOTAエージェント的な体験じゃなくて、ペアプログラミングみたいな感じだった。正直、もっと楽しかったし、AIが出る前のコーディング体験を思い出させてくれた。プロンプトを出して待って、うまくいくことを願うスロットマシンみたいな感じじゃなかった。Gemini Flash LiteやGPT Mini/Nanoみたいな小さいモデルももっと使うようになったし。とにかく、オープンウェイトモデルが楽しみで、うまく機能することを願ってる。できるだけ早くテストしてみるつもりだ。

└

テストを早く安く実行できて、悪い/雑なコードを示すメトリクスが安くて早く生成できるなら、時間を重視するなら、悪いけど早いモデルが、遥かに優れた遅いモデルを上回ることもあるよ。真の複雑さを測るメトリクスを導入した後、結構いい結果が出てる。追加の複雑さが機能に対して合理的な範囲内に収まるまで、すべてを自動的に押し戻してるんだ。

└

もう少し具体的に使い方を教えてもらえる？あなたのワークフローはどんな感じ？

└

それで、ちょっとした編集をしてるの？

└

これがローカルで使われるコーディングモデルにどれだけ影響するのか気になるな。QwenやGemma 4よりもx倍速い拡散モデルを使うことを想像できる。もっと「プレAI」な作業をしなきゃいけないのはいいことだし、ローカルで扱うには非常に速くて安いモデルが手に入ると思う。長時間重い計算をしないから、ローカルハードウェアで動かすのも安上がりなんじゃないかな？

Hacker Newsで議論の続きを見る

ハクソク