ジェミニ拡散

369日前原文(simonwillison.net)

概要

Googleは Gemini Diffusion を発表し、従来の トランスフォーマー に代わる新手法を導入。
拡散モデル を言語生成に応用し、高速かつ高品質な出力を実現。
Gemini Diffusionは エラー訂正 や編集タスクに優れる。
実際の利用で 857トークン/秒 の応答速度を記録。
Gemini 2.0 Flash-Liteの 5倍の速度 を公式に謳う。

Gemini Diffusionとは何か

Google I/Oで発表された Gemini Diffusion は、Google初の 拡散モデルベースLLM であることを確認。
従来の 自己回帰型言語モデル （autoregressive）は、一度に1単語（トークン）ずつ生成するため、 処理が遅く なりやすいことを指摘。
拡散モデルは ノイズから段階的に出力を洗練 することで、直接テキストを予測するのではなく、 高速な反復生成とエラー訂正 を可能にしていることを強調。
この手法により、 編集作業 や 数式・コード生成 などで優れたパフォーマンスを発揮することを提案。

Gemini Diffusionの特徴と体験

最大の特徴は 生成速度の速さ であることを強調。
実際に「Build a simulated chat app」とプロンプトしたところ、 857トークン/秒 の速度でHTML+JavaScriptページを生成することを確認。
結果は 数秒以内 に返され、Claude Artifactsのような インタラクティブな出力 を実現していることを報告。
Cerebras Coder （Llama3.1-70bを2,000トークン/秒で実行）に近い体感速度であることを比較。
Google公式ページでは「 Gemini 2.0 Flash-Liteの5倍の速度」と記載されており、 低コストモデル と同等以上の性能を実現していることを示唆。

拡散モデルとトランスフォーマーの関係

一部で「トランスフォーマーの代替」と誤解されたが、 正確には自己回帰の代替 であることを訂正。
Mercuryなど従来の 拡散LLM もトランスフォーマーを内部で利用しているが、 因果マスキング（causal masking） を行わず、 入力全体を一度に処理 することが特徴であることを確認。
Gemini Diffusionも トランスフォーマー構造 を採用している可能性が高いと推測すること。

今後の展望と課題

現時点で 独立したベンチマーク は未発表であり、今後の評価が期待されることを指摘。
商用グレードの拡散モデルはこれまで Inception Mercury 程度しか存在せず、Gemini Diffusionが 先駆的存在 であることを強調。
編集・生成速度の向上 による新たな応用分野の拡大を期待すること。

まとめ

Gemini Diffusionは 拡散モデルの高速性とトランスフォーマーの強み を融合した次世代LLMであることを再確認。
今後の 第三者評価 や 実運用事例 の登場が重要であることを提案。

Hackerたちの意見

それは…めちゃくちゃ早いね。今まで見てきたモデルの一番の使い道は、新しいコードや素早いプロトタイピングだと思う。大きな既存のコンテンツを改善する能力については、あまり確信が持てないな。というのも、モデルは定義上、コードベースにないものを知ることができないから、そのネガティブスペースには意味のある信号があるんだよね。ないものをエンコードするのは難しい問題に思えるから、モデルが賢くなっても、その組織的な知識の欠如によってハンデを背負い続けると思う。例えば、すごく優秀な開発者に大きなコードベースを渡して、特定の問題を一発で解決してもらおうとしたら、読む時間も質問する機会もない状態だと、ほとんどの場合、そのコードベースに詳しいあまり優秀でない開発者の方が、同じ問題に取り組むのに同じ労力でより価値を生み出せると思う。

└

モデルを十分に速くすれば、その専門の開発者を瞬時にオンボードできて、彼らが自分の力で解決策を見つけられるようになるよ。特にRAGにアクセスを与えるときはね。時間が経つにつれて、モデルはもっとメモリや組織的な知識のキャプチャを追加して、毎回真っさらな状態から始めることはなくなると思う。

これは埋もれてる気がするけど、すごく早いInstructGPTだね。これ絶対にスペルチェックやコードモッド、コードエディタで使われるよ。インスタントエディット機能は、余計なものや不要な強化なしに、テキスト編集を素早く行えるからね。シャーダートイをコピーして、すべての変数をもっと説明的にリネームするように頼んで、その結果をペーストしてもまだ動いてるのを見たよ。感心した。

ディフュージョンは単なるスピード以上のものだよ。初期のベンチマークでは、ARと比べて推論や計画がより優れていることが示されている。これは、編集ができて、初期トークンバイアスに悩まされないからだね。

└

これはすごく興味深い主張だね - そのベンチマークを教えてもらえる？

└

信じたい主張なんだけど、これに関する論文を教えてもらえる？リバイズディフュージョンテキストステップを示す論文やデモは全然見たことがないんだ。ぜひ使ってみたいんだけど。

└

ARは長期的な計画プロセスを妨げないけど、最近の人気のあるARの実装にはその欠点があるよ。一般的にARは、正しい分布を学ぶのに重要なんだ。

ニットだけど、ディフュージョンはトランスフォーマーの代わりじゃなくて、オートリグレッションの代わりだよ。以前のディフュージョンLLM、例えばMercury [1]はトランスフォーマーを使っているけど、因果マスキングがないから、全ての入力が一度に処理されて、出力生成が明らかに違うんだ。これもトランスフォーマーを使っているんじゃないかと強く疑ってるよ。[1] https://www.inceptionlabs.ai/introducing-mercury

└

面白いね、すぐにブロックディフュージョン [0]を思い浮かべたけど、君の言う通りかもしれない。[0] https://m-arriola.com/bd3lms/

└

画像ディフュージョンモデルも最近はトランスフォーマーを使ってるよ。こちらが元の「ディフュージョントランスフォーマー」の論文だよ: https://arxiv.org/abs/2212.09748 以前の画像ディフュージョンモデルはU-netを使ってた: https://en.wikipedia.org/wiki/U-Net

└

ありがとう、コメントを引用するように投稿を更新したよ。

└

マスク拡散ってのもあるよね？

└

だから、全体の入力が一度に処理されるっていうのがちょっと混乱してるんだけど。自己回帰型LLMも全体の入力を「一度に」処理するから、推測デコーディングみたいなトリックが機能しないわけじゃないよね。これについてもう少し詳しく教えてもらえる？

これめっちゃ速いね。俺の予想だと、ここでのトレードオフはGPUが常に最大の能力で動いてて、バッチ処理からの計算コスト削減がほとんどないってことかな。今考えると、これはあんまりトレードオフじゃないかも。唯一心配なのは、拡散目的がモデルの能力に関してARよりも劣ること。もしそうなら、マルチトークンARモデルが拡散と同じくらいのパフォーマンスを発揮してくれることを願うか、これを投機的デコーディングのためのドラフトモデルとして使えるといいな。

└

なんでdLLMsがarLLMsの品質に匹敵しない（または超えない）と思うの？一般的な考え方としては、出力を構造化された全体（アイデア、ポイント、概念、言葉 - ツリー状）として扱う方が簡単で、それを反復的に処理することで「適切な」品質に向かうはずなんだ。

速いってことは、計算資源をあまり使わないってこと？

└

それとも、もっと平行的に使えるのかな？

なんでペリカンにそんなにこだわってるの？君のストーリーは？

└

僕はもともとイギリス出身なんだ。カリフォルニアに初めて行ったとき、マリン郡の崖の上にいて、編隊が飛んでいくのを見てすごく感動したんだ。でも一緒にいたカリフォルニアの人たちは「うん、いつも見るよ」って感じだった。今はカリフォルニアに住んでるけど、ここでまた見ることができるなんて信じられないよ。ほんとに不思議な形してて、飛べるとは思えないくらい。繁殖羽根の時期は特に美しいんだ。サンフランシスコのすぐ南にあるハーフムーンベイに住んでるんだけど、実はここが世界で2番目に大きいカリフォルニアブラウンペリカンのメガルーストの場所なんだ（僕の好きなペリカンの種類）。実際に2羽を救助したこともあるよ（怪我した鳥をキャリーに入れて動物救助のところに連れて行った）。いろんなAI実験のテーマにするのが楽しいんだ。写真映えもするし、最近PyConのポスターに撮った写真をたくさん使ったよ（でも、ちゃんと見るにはかなりズームしないといけないけどね）：https://static.simonwillison.net/static/2025/poster-full-siz...

研究者に質問なんだけど、dLLMsはシードで固定できるの？100%決定論的にできる？

└

はい

拡散言語モデルにめっちゃワクワクしてる！これが俺たちのボイス・トゥ・コードのゲームメカニクスを思い描いてる通りにスムーズにするためのピースかもしれない。CerebrasとGroqはすごいけど、カスタムハードウェアを使ってるせいで微調整やスケールの能力がかなり制限されてる。もう一つのルートは、ほとんど0.5bのパラメータがアクティブなMoEだけど、それは今は優先できない大きな取り組みになる。--- もしGoogle/Deepmindの誰かがこれを読んでたら、APIアクセスをお願い！俺たちは生成的なサンドボックスゲームを作ってるんだ。最初のタイトルはモンスタートレーナーで、リアルタイムでクリーチャーを指揮できるんだ。ここに初期プロトタイプがあるよ：https://youtu.be/BOwpLyj2Yqw

テキスト生成における拡散技術の使用についてずっと考えてたんだけど、Googleがリリースしたモデルが、僕の考えをある程度裏付けてくれてるのが嬉しいよ。AIを試してる人たちのほとんどは、有料サービスを使ってたり、高性能なハードウェアを運用してる（たとえ消費者向けでも）。今の僕の手持ちの中で一番いいのは5700XTで、それ以上にはまだアップグレードできてないんだ。でも、その制限が今のモデルの欠点についての重要な洞察を与えてくれたのも事実。モデルのサイズがかなり大きくなっていて、一貫性は主にモデルの密度に比例しているようで、小さなモデルは小さなタスクにしか使えなくなってる。長時間の対話やエージェントセッションでの実験から、コンテキストサイズも非常に重要だと感じてるけど、小さなGPUではまともなモデルと十分なコンテキストを同時に収めることができない。拡散技術がこの密度と一貫性の関係を再調整できるのか、限られたコンテキストでも小さなモデルが一貫したテキストの塊を生成できるようになるのか、ちょっと気になるな。僕の視点では、そうなると思う。混合ツールの呼び出しと応答出力も、より良くなる可能性があるし。スピードも、僕やみんなが現代のLLMで抱えている問題の一つだよ。新しい出力を追加するたびに入力を循環させるのは時間がかかる。古いGPUでAI専用ハードウェアがないと、永遠に感じるよ！少なくとも0-100%の進行状況を追跡できるようになれば、今の解決策よりは改善されると思う。今はただLLMが止まるのを待つしかない（または最大推論トークン数に達するまで）。低スペックのGPUでも、拡散モデルが少しでも良いパフォーマンスを発揮してくれることを期待してる。これでいくつかの質問が出てくるね。ノイズを処理している場合、そのノイズはどこから来るの？LLMやテキスト専用の良いノイズのソースはあるの？全体のブロックは事前にサイズが決まっているのか、それとも応答の長さを変えることができるのか？

ハクソク