Google DeepMindは、テキスト拡散モデルに必ずしも新たな大規模事前学習が必要ではないことを示した。The Decoderが報じた技術レポートで、同社は既存のGemma 4-26B-A4Bを、元のモデルの学習トークン予算の10%未満でDiffusionGemmaへと変換した方法を説明している。

このシステムは、1トークンずつ生成を確定するのではなく、最大256トークンのブロックを並列に生成する。Nvidia H100上では、Googleによればスループットは毎秒およそ1,500トークンに達する。ここには重要なトレードオフがある。DiffusionGemmaは総合的なベンチマーク品質で自動回帰型の前身にまだ及ばないが、この手法は研究者や製品チームにとって、テキスト拡散実験へより低コストで取り組む道を開く可能性がある。

新規の事前学習ではなく後付けの改修

従来の自動回帰型言語モデルは、すでに生成されたトークンから次のトークンを予測し、応答を逐次的に構築する。DiffusionGemmaは別の道を取り、ノイズのあるテキストブロックを何度も精緻化して、出力を使える状態にする。この手法は、言語に適用されているとはいえ、発想としては画像拡散システムに近い。

Google DeepMindは、拡散専用に新しいモデルを設計・学習するのではなく、Gemma 4を出発点にした。第1段階の学習では、破損したテキストブロックを復元する方法をモデルに教えた。第2段階では、強化学習とサンプラー蒸留を組み合わせた。GoogleはこれをSD·RLと呼んでいる。強化学習は応答の改善に使われ、サンプラー蒸留は推論時に必要な精緻化ステップ数を減らした。

この設計判断こそが、レポートの中心的なニュースである。既存の言語モデルが別の生成メカニズムの基盤になり得ることを示唆しており、代替アーキテクチャの探索に必要なコストと時間を下げられる可能性がある。ただし、後付けの改修が最初から拡散向けに学習されたモデルと一貫して同等になることを証明するものではない。

並列生成は速度をもたらすが、条件付きである

レポートによれば、SD·RLは適応後システム内の推論ベンチマーク結果を平均10ポイント改善しつつ、計算ステップごとに処理できるトークン数をほぼ4倍にした。さらにGoogleによれば、DiffusionGemmaの応答は約50%短く、これも速度面の主張に寄与している。

このモデルは、拡散風の生成と元の逐語的なモードを切り替えられるとされる。その柔軟性により、構造化されたタスクには反復的な精緻化を使い、逐次生成のほうが信頼できる場面では従来のデコードを使う、といった運用が可能になるかもしれない。

最も強い性能数値は、なおベンダー報告に基づく。The Decoderは、DiffusionGemmaが単一ユーザー条件のH100で毎秒約1,500トークンに達すると述べている。並行要求が増えると優位性は縮小する。およそ32件の同時リクエストでは、標準的な言語モデルがスループットで追いつくとされる。そのため、導入設計は見出しの速度数値と同じくらい重要になる。

証拠、改善、既知の弱点

Googleのレポートは、並列精緻化が有効になり得るいくつかのタスクを示している。数学の例では、拡散モデルが目に見える出力を確定する前に答えを組み立てられるため、後から修正を付け足すのではなく、初期の誤りを修正できる。レポートはまた、最小限のファインチューニング後に約85%の数独性能を示しており、ベースモデルはこのタスクに失敗するとされる。

構造化出力は、特に実用的なユースケースになり得る。Googleによれば、JSON生成やコード修復は、最終的な構造の大部分が入力によってすでに制約されている場合、2〜3回の精緻化ステップで完了できる。これらの結果は有望だが、独立評価ではなく、モデルの技術レポートに基づくタスク固有の主張である。

レポートは重要な制限も記している。DiffusionGemmaは繰り返しループに陥ることがあり、単語を個別に繰り返すこともある。モデルの学習段階は比較的短く、SD·RL段階は最大品質よりも低い計算要件を優先した。アーキテクチャ、データ、その他の設定はGemma 4から引き継がれているため、拡散生成には最適でない可能性がある。

The Decoderはさらに、このモデルがマルチモーダルタスクで推論セクションを閉じ損ねることがあり、基礎となる答えを必ずしも反映しない理由で測定スコアが下がると報じている。全体性能はなお自動回帰型ベースモデルを下回り、Googleはその一因を後付け戦略と限定的な追加学習に帰している。

ビルダーとエンタープライズチームにとっての意味

AIビルダーにとってDiffusionGemmaは、従来の言語モデルの完成形の置き換えではなく、具体的な研究出発点を提供する。低遅延アシスタント、制約付き生成、対話型システムを検討するチームは、並列精緻化が応答時間を短縮しつつ、許容できない繰り返しや精度問題を生まないかを試せる。

経済性はワークロードの形に左右される。単一ユーザーのアプリケーションは報告されたスループットの恩恵を最も受けやすい一方、高並行サービスでは優位性が小さくなる可能性がある。チームはまた、トークン毎秒の数値だけに頼らず、総レイテンシ、精緻化ステップ、アクセラレータ利用率、修正率を測定する必要がある。

構造化ワークフローは、自由形式の推論よりもこの手法にすぐ適しているように見える。JSON生成、コード修復、その他入力制約が強いタスクでは、ノイズ除去の反復回数が少なくて済むかもしれない。逆に、一貫して高い推論力や洗練された長文回答に依存するアプリケーションは、拡散専用の学習が品質を改善するまで、元の自動回帰型モデルを好むかもしれない。

Hugging FaceでApache 2.0として利用できることは、実験の障壁を下げる。The Decoderは、Interfazeがすでにこれを多言語音声認識に使っていると報じており、別の研究プロジェクトは対話型の放射線レポート生成を探っている。これらは初期導入の兆候ではあるが、広範な本番展開の証拠ではなく、入手可能な情報源は性能や規模について独立した詳細を提供していない。

次に注目すべき点

次の重要なシグナルは、テキスト拡散専用に学習されたモデルが、後付けシステムとの品質差を縮められるかどうかだ。研究者はまた、単一リクエストのベンチマークだけでなく、現実的な同時処理負荷の下でDiffusionGemmaをテストすべきである。

追加評価では、繰り返し失敗、構造化出力の妥当性、推論精度、そして完了したタスクあたりのエネルギーやコストを調べる必要がある。さらに、専門的なファインチューニングが、コーディング、音声認識、企業向け文書生成で信頼できる改善をもたらすかも有用だ。

Googleによる以前のGemini Diffusionデモは、同社がこのアプローチを引き続き検討していることを示しているが、DiffusionGemmaは明示的に実験的と位置づけられている。したがって、このモデルの価値は、標準的な言語モデルをすぐに置き換えることよりも、独立研究や特化した適応をどれだけ迅速に可能にするかで測られるかもしれない。

Creati.aiの視点

DiffusionGemmaが重要なのは、テキスト拡散を適応問題として捉え直しているからだ。既存のモデルから始めることで実験は身近になるが、逐次デコード向けに作られたアーキテクチャと学習レシピを再利用する限界も露わになる。

製品チームにとっての実務的な問いは、並列生成が一般に速いかどうかではない。特定のワークフローに、精度と出力の信頼性を保ちながら、より少ない精緻化ステップの恩恵を受けられるだけの構造があるかどうかだ。DiffusionGemmaは、比較的低い参入コストでその問いを試す手段を開発者に与えるが、ベンチマークの差と同時実行性の制限は、自動回帰型モデルの置き換えという広い主張ではなく、ワークロード単位での慎重な評価を促している。