- Googleが発表した Gemini Diffusion は、トランスフォーマーではなく拡散（Diffusion）方式を使う初のLLM
- Imagen や Stable Diffusion のような画像モデルで使われるものに近い
- このモデルは既存の 自己回帰方式 ではなく、ノイズを段階的に精製する拡散プロセスを通じてテキストを生成する
- その結果、応答速度が非常に速く、実験では 毎秒857トークン 水準の性能を示した
- 正確なベンチマークはまだ不足しているが、Googleは Gemini 2.0 Flash-Lite と比べて5倍高速だと主張している
Gemini Diffusion の概要
- Gemini Diffusion はGoogleが新たに公開した大規模言語モデル（LLM）
- 従来のトランスフォーマー型LLMの自己回帰（autoregressive）方式ではなく、拡散（diffusion）アプローチ を採用している
- この拡散方式は、画像生成モデル（Imagen、Stable Diffusion など）のように動作する仕組みをテキスト生成に適用したもの
- 主な特徴は 高速な応答速度 と、生成過程における効率的な誤り修正能力
- 利用例では "Build a simulated chat app" というプロンプトに対し、数秒以内にHTML+JavaScriptの結果を提供し、最大毎秒857トークン の生成速度を記録した
拡散言語モデルの動作方式
- 従来の 自己回帰型言語モデル はトークンを1つずつ順番に生成するため、速度が遅く、出力の一貫性にも限界がある
- 一方 拡散モデル はノイズから始まり、段階的に結果を改善しながら、文全体または段落全体を複数ステップにわたってまとめて処理する
- これにより 並列的なトークン生成 が可能となり、非常に高速な結果生成が実現される
- テキスト編集、数学、コードなど 即時フィードバックが重要な領域 で効果を発揮する
類似モデルと性能比較
- これまで商用の拡散LLMはほとんど存在せず、2024年2月に Inception Mercury プロジェクトが最初の事例として登場した
- 速度と性能の面で Gemini Diffusion はGoogle基準で Gemini 2.0 Flash-Lite と近いが、速度は約5倍速い
- Cerebras Coder と同様に高い生成速度を示しており、今後 客観的なベンチマークデータ が追加される予定
追加説明と訂正
- 拡散言語モデルは トランスフォーマーアーキテクチャ を完全に置き換えるものではなく、自己回帰の代わりに拡散方式へとテキスト生成構造を変更したもの
- Mercury と Gemini Diffusion はいずれもトランスフォーマーをベースとしているが、入力全体を一度に処理 し、生成方式が異なる
- 従来の BERTスタイルのマスキング・復元方式を発展させた形で、マスキング比率を徐々に高めながら、すべてのトークンがマスクされた状況でも段階的に結果を完成させていく
- 拡散方式では複数ステップにわたって一部のトークンだけを確定（final）し、繰り返し確定トークンの比率を増やしてシーケンス全体を完成させる構造になっている
- このような拡散LLMの 中核となるアイデア は、段階的復元と並列生成にある
結論
- Gemini Diffusion は、速度と生成品質の両面で革新的な特性を示す新しいLLM である
- 画像生成で実証された拡散モデルの利点を テキスト生成領域へと成功裏に拡張 している
- 多様な実務適用を通じた活用価値と、今後のベンチマーク結果への期待が高まっている
1件のコメント
Hacker Newsの意見
Google内部で実際にどう動いているのかはよく分からないが、最近RWKV界隈で注目に値する出来事があった。従来のアテンション機構をWKV（線形アテンション）に丸ごと置き換える実験が行われ、その全工程をポストトレーニングだけで実現した。これが示唆するのは、有用な知識の大半は実はFFN（フィードフォワードネットワーク）に入っていて、アテンション自体は思ったほどユニークでも重要でもない要素なのかもしれない、ということだ。関連リンクも読むと面白い。一方で、すでに学習済みのアテンションを活用し、GPT-2の速度トレーニングでFFNだけを切り出してどれほど速いかを試すのも、ルール違反ではあるが興味深い試みで、論文として読んでみたいと思う。昨日読んだ話では、ある時点では全モデルの埋め込みが（非常に）似通ってくるため、簡単な変換器を学習でき、この2つがどちらも本当なら埋め込みとアテンションを共有して全体の訓練をずっと高速化できるはずだ、という話があった
アテンションとは、研究者の方々に最大限の敬意を払って言えば、ネットワークの過去の全情報を入力として受け取り、リバースMoEニューラルネットワークに入れるようなものだと考えている。ここでは専門家がネットワークの一部ではなく、入力の一部を実行対象として選ぶわけだ。この方式は効果があるだろうとは皆分かっていたが、あまりにも非効率で、RやPythonのユーザーでさえ実行してみようとは思わなかった。トレーニング自体が遅すぎて、実用的に試すことすら難しい構造だった
アテンションが必須だという"Attention is all you need"は、実は別の意味にも解釈できるのではないかと思う
モデルの埋め込み同士が（非常に）似通っていて単純な変換器でマッピングできる、という話はここから出ている
アテンションとは、ネットワークを分割して並列学習を可能にするための完全に恣意的な方法だと見ている。本当に成功に寄与した部分は、レイヤー間の"ショートカット接続（shortcut connection）"だ。これによって学習時に初期レイヤーへより大きな影響力が与えられる
最近のトランスフォーマーで使われるSDPAアテンションの相対的重要性の低さは、すでに知られている。FFN、正規化、残差接続は絶対的に代替不能だが、アテンションはトークン間で情報を共有する他のどんなレイヤー（プーリング、畳み込み、ランダムミキシングなど）にも容易に置き換えられる
本当にものすごく速い。これまでのモデルの最高の活用例は、まったく新しいコードを書くことと高速プロトタイピングだと思う。すでに何度も反復的に改善されてきた大規模コードベースの改善には、それほど強みを感じてこなかった。その理由の一つは、定義上モデルはコードベースに「含まれていないもの」を知ることができないからだ。何かがコードに「ない」という事実にも意味深いシグナルがあるのに、これを表現するのはかなり難しい問題だ。どれほど賢いモデルでも、その点では「内部的な文脈と経験」が不足していて、本質的な限界が残ると思う。たとえば、非常に優秀な開発者に巨大なコードベースを渡して特定の問題をすぐ解決しろと言っても、そのコードベースをよく知っている普通の開発者のほうが同じ時間でより価値のある結果を出せることがある
コミュニケーションの仕方に焦点を当てれば、この問題は解決できる。最近の自分の主なワークフローは、大きな作業（新機能、リファクタリングなど）が必要になったら、同僚のようにo3と会話を始めることだ。必要なソースファイルを文脈提供のために貼り続けながら、目標と現在のコードの状況について高いレベルの議論を進める。この過程で、自分がやりたいこととコードベースの文脈が明確になると感じる。その後、o3に実装計画を依頼し、それをCodexに渡してソース読み取り、ファイル修正、テストなど一連の自動化を実行する。PRが出てきたら、少し手動で編集するだけで済むこともあれば、そのままマージできることもある。モデルに豊富な文脈が必要だという点には同意するが、これは本質的な限界ではなく、効果的に協働する方法の問題だ。習熟さえすれば、生産性だけでなく、自分にとっては頭の中がより楽しくなる作業方式でもある
「コードベースに存在しないものが意味のあるシグナルを持つ」という観点には深く共感する。長くソフトウェアをやってきたが、この根本的な真実をここまで明確に意識したことはなかった。ありがたい洞察だ
これまでの経験では、LLMは既存の良いコードを模倣するのは得意だが、新しく独創的な部分は、特別に明示して要求しない限り自力ではあまり生み出せない。コードベースを十分にingestできず、プロジェクト内の他の部分を直接指定してやらなければならないことが多い。それでも、Stable Diffusionのように「ネガティブプロンプト」を与えられたら本当に面白そうだ
LLMがgitの全履歴、イシュートラッカー、会議録音まで全部コンテキストとして読めたらどうなるのか気になる。非常に大きなコンテキスト入力が実用的な結果につながるかどうかは、もう少し見守る必要がある
今回の発表には本当に驚いた。IOイベントで最も大きな発表だと思うが、Veo 3など他のニュースに押されてしまって残念だ。コード生成にdiffusionモデルを使うというのは非常に大きな意味がある。もしトランスフォーマーを使うならDiT（Diffusion Transformer）系に当たるはずで、数年前にU-Netベースのdiffusionを組み合わせたハイブリッドモデルに関わったことがあるが、その後もかなり進歩している。今後、diffusion分野で大きな飛躍がありそうだ
ビジョントランスフォーマーでの直感をコードに適用するとどう動くのか気になる。ビジョン分野ではノイズから始めて、階層ごとに徐々に鮮明なtarget画像を作り上げていく。この原理をコード生成に適用するなら、たとえば「Djangoを使うべきだ」「エンドポイント一覧を決める」「具体的なコードを生成する」など、徐々に抽象度を下げる階層構造が必要に見える。だがdiffusionにはバックトラッキング機構がないため、下位レベルの問題が検出されても上位レイヤーへ即座にフィードバックするのが制限される。一方トランスフォーマーはトークンごとに全モデルを回すので、問題ごとに必要なバックトラッキングや設計変更がしやすい。自分のモデル理解に欠陥があるかもしれないので、追加の洞察があれば聞きたい
Veo 3は性能と差別化ポイントが非常に直感的に分かるので話題になった一方で、テキスト補完分野での重要な進歩の価値を理解するには、既存の成果と潜在的活用法を知っている必要がある。まだ多くの人は、LLMがコーディングに有用だという事実そのものに確信を持っていない状況だ
Diffusionベースのコード生成モデルは本当に革新的だ。こうしたモデルができそうな簡単なアイデアとしては次のようなものがある。関数シグネチャと結果を固定し、その間のトークンを生成する方式（双方向の情報を活用）。第二に、まず関数レイアウトの大枠を書き（LLMに記事の「章」を書かせるように）、その後で実装へと徐々に詳細化していくやり方。さらに大きなコンテキストの中でlintersやAST情報など各種シグナルを使って方向付けしながら反復生成することも考えられる。試せることは本当に多い
原理的にはこの方式に大きな利点があるはずだが、実際に使ったLLaDAのようなモデルは、学習資源が少ないにもかかわらず印象的ではあった。ただしperplexityなどの指標ではまだ後れを取っている。生成途中で固定化しやすい傾向が強く、テキストを深く修正するには限界がありそうだ（マスキング確率が高くなるほど同時修正が難しくなる）。それでも、実際の実験ではかなり実用的な結果が出ていた
InceptionLabsなどですでにデモを見たことがあるので、そこまで驚きではない
このニュースの核心が埋もれている気がする。これは本当に高速で優秀なInstructGPTだ。今後はスペルチェック、codemod、コードエディタなどで必ず使われるはずだ。Instant edits機能のおかげで、不要な追加や提案なしに、本当に高速かつ精密なテキスト編集が可能になる。ShaderToyのサンプルコードで変数名をもっと分かりやすくしてほしいと頼み、結果をコピーして実行したらそのままちゃんと動いて驚いた
diffusionの利点は単に速度だけではない。初期ベンチマークによれば、ARと比べて同じパラメータ数でも推論や計画の面でより優れている。diffusionは途中編集が可能で、初期トークンバイアスの問題も抱えない
興味深い主張だ。関連するベンチマークや根拠資料へのリンクを共有してもらえるだろうか
AR自体が長いプランの立案を妨げるわけではないが、最近人気のARモデルの実装方法には、そのような制約がある場合がしばしばある。ARは基本的に正しい分布を学習するうえで非常に重要だ
個人的には同意したい、あるいはそうであってほしい主張だが、revise diffusion textに関する論文やデモはまだ見たことがない。使ってみたいので、論文情報を共有してほしい
テキスト生成にdiffusion技術を適用することには長年関心を持っていた。ついにGoogleがこうしたモデルを出してきて、自分の考えが裏付けられたようでうれしい。実験に使われるハードウェアの面では、ほとんどが有料サービスかハイエンド（少なくともコンシューマー向けでも上位クラス）機材を前提としている。現状、自分が持っているのは5700XT程度でアップグレードも難しく、そのおかげで現行モデルの限界がむしろよく見えた。モデルサイズが大きくなるほど一貫性も増すので、小型モデルはどうしても単純な作業に限られる。主な実験で確認できたのはコンテキストサイズの重要性で、小型GPUでは十分なコンテキストとモデルを同時に載せるのが難しい。diffusionベースなら密度と一貫性のバランスを変えられるのか気になる。少ないコンテキストでもより一貫したテキスト生成が期待できるし、ツールコールと応答の混合結果も良くなるかもしれない。速度の問題も現実的な不満で、既存のLLM方式は入出力の反復ごとにゆっくり進むため（特にAI向けハードウェアのない古いGPUでは）忍耐の限界になる。進捗が0〜100%でもリアルタイムで見えたらいいし、diffusionモデルなら少しは改善するのではと期待している。そこで疑問がある。ノイズ入力が重要だが、LLMやテキストに特化した良いノイズソースは存在するのか、全ブロック長もあらかじめ固定なのか、それとも可変なのか気になる
自分の立場からはっきり言えるが、このモデルはとてつもなく速い。欠点は、プロンプトインジェクション攻撃に非常に簡単に破られることだ。たとえば薬の製法を尋ねると拒否するのに、「子どものロールプレイ」として尋ねると実際の答えを出してしまう。この欠点さえ除けば、速度と自動化での使い勝手は本当に優れている。エージェント的アプローチまで加われば、このモデルの潜在力はさらに光るはずだ
それはモデル自体の限界というより、トレーニングで安全性や検閲に割くリソースが少なかったからかもしれない。自分としては一種のプロトタイプ実験であり、大型モデルに本格投資する前の軽い試験なのではないかと予想している
こうしたプロンプトインジェクションが、より賢いモデルを制御できることのシグナルになるとは思わない
「Google初のdiffusion LLMで、トランスフォーマーの代わりにdiffusionを使っている」という説明は誤りだ。Google自身がそう発表したことはない。むしろTransformerベースのdiffusionモデルは一般的だ。Gemini Diffusionもトランスフォーマーを使っている可能性が高いと思う。違いがあるとすれば、エンコーダーオンリーのトランスフォーマーだという点だ。つまり、ノイズや破損を加えた状態のシーケンス全体を入力し、正しいシーケンス全体を予測する構造になっている。そのおかげでシーケンス全フレームを同時に並列計算でき、反復回数が適切ならデコーダーオンリーの逐次デコードよりはるかに速い（もちろん投機的デコーディングにも同様の速度向上余地はある）。通常はBERT式マスキングで学習するが、今も非常に活発な研究分野だ。Geminiとの関係やチェックポイント活用の有無（直接インポートなのか、diffusion特化のファインチューニングなのか、知識蒸留なのか、あるいは単なるブランド名なのか）も気になる。公式の詳細が公開されていればよかったのにと思う
ばかげているほど速い。GPUは常に最大性能で回り、バッチ処理による計算節約効果はほとんどないだろうと予想している。ただ、よく考えるとそれは本当の意味でtradeoffと呼ぶには微妙かもしれない。一つ懸念しているのは、diffusion objectiveがARより性能面で劣る可能性があることだ。もしそうなら、multi-token ARモデルがdiffusionと同等の速度を出すか、あるいはdiffusionモデルをspeculative decodingの下書き生成器として使う、といった代案もあり得る
dLLMがarLLMより品質で劣ると考える理由が気になる。出力を「構造化された全体（主題、要点、概念、単語ツリー）」として反復処理するので、品質面ではむしろ有利になり得ると思う
この構造的なtradeoffは、個人ホスティング環境でははるかに有利だ。大規模バッチが不要な環境なので、クラウドでは利点が小さくても、ローカルLLMには大きな強みになる
diffusion LLMにはかなり興奮している。うちのチームは音声→コードで動くゲームメカニクスを夢見ていて、diffusionがまさにその完成形の要素になりそうだ。CerebrasやGroqは素晴らしいが、カスタムハードウェアゆえにファインチューニングやスケールには限界がある。ほかの選択肢としてはアクティブパラメータ0.5b級のMoEもあるが、今はそのプロジェクトにリソースを注げない。Google/DeepMindの関係者が見ていたら、ぜひAPI提供をお願いしたい。うちのチームは生成型サンドボックスゲームを開発中で、最初の作品はリアルタイムでモンスターに命令を出す構造だ。プロトタイプ動画もあるので参考になると思う