DiffusionGemma: 4倍高速なテキスト生成

• DiffusionGemmaは、テキスト拡散方式でテキストブロック全体を同時生成する、Apache 2.0ライセンスの26B MoE実験用公開モデル
• 一般的な自己回帰LLMの逐次トークン生成の代わりに256トークン並列生成を使用し、専用GPUで最大4倍高速なテキスト生成を提供
• 推論時には全26Bのうち3.8Bパラメータのみを有効化し、量子化すれば18GB VRAMの範囲内でハイエンド消費者向け専用GPUに適合して動作
• 双方向アテンションと反復的な自己修正により、インライン編集、コード補完、アミノ酸配列、数学グラフのような非線形構造を持つタスクに利点がある
• 速度と並列レイアウト生成を優先した実験モデルのため、全体の出力品質は標準Gemma 4より低く、最高品質が必要なアプリケーションには標準Gemma 4の導入が推奨される

---

開発者にとっての新たな価値

• DiffusionGemmaはテキスト拡散を探求する実験用公開モデルであり、一般的な自己回帰LLMのトークンごとの逐次処理を超えて、テキストブロック全体を同時に生成する
• このモデルはApache 2.0ライセンスで提供される26B Mixture of Experts(MoE)モデルで、GPU上で最大4倍高速なテキスト生成を実現する
• Gemma 4系統のパラメータ当たりの知能とGemini Diffusion researchを基盤とし、生成速度を最大化するための新しい拡散ヘッドを統合している
• 自己回帰型Gemma 4モデルは高品質な本番出力の標準であり続け、DiffusionGemmaは速度が重要な対話型ローカルワークフローを探求する研究者と開発者向けに設計されている

• 主要なトレードオフ

  • 高速推論はデコーディングのボトルネックをメモリ帯域幅から演算へ移し、専用GPUで最大4倍高速なトークン出力を提供する
  • 単一のNVIDIA H100で毎秒1000トークン超、NVIDIA GeForce RTX 5090で毎秒700トークン超を生成する
  • ハードウェアのアクセスしやすさは、26B MoE全体のうち推論時に3.8Bパラメータだけを有効化する構造から生まれる
  • 量子化すれば、ハイエンド消費者向け専用GPUの18GB VRAMの範囲内で動作する
  • 双方向アテンションは各順伝播ごとに256トークンを並列生成し、すべてのトークンが互いを参照できるようにする
  • インライン編集、コード補完、アミノ酸配列、数学グラフのような非線形領域で利点がある
  • 自己修正は、モデルがテキストブロック全体を一度に評価しながら、リアルタイムで誤りを修正するよう反復的に出力を洗練させる方式
  • 実験段階であることと本番用途への推奨事項は明確であり、速度と並列レイアウト生成を優先するため、全体の出力品質は標準Gemma 4より低い

• ファインチューニング例

  • 特定タスクの性能はファインチューニングで改善できる
  • UnslothはDiffusionGemmaを数独が解けるようにファインチューニングしており、数独は各トークンが未来のトークンに依存するため自己回帰モデルが苦手とするタスクである
  • DiffusionGemmaの双方向アテンションは、数独のようなタスクをはるかに容易にする

テキストに拡散を使う理由

• AI研究コミュニティは長年にわたり拡散ベースのテキスト生成を探求してきたが、これを大規模モデルに適用することは依然として課題だった
• DiffusionGemmaは、モデルがハードウェアを利用する方法を変えることでこの問題に取り組む

• 既存モデルとのトレードオフ

  • ほとんどの言語モデルはタイプライターのように左から右へ、一度に1トークンずつ生成する
  • クラウドではサーバーが数千のユーザーリクエストをまとめてバッチ処理し、ハードウェア負荷を共有できるため、この方式は効率的である
  • 単一ユーザーがローカルで実行する場合、単語単位の生成では専用GPUやTPUを十分に活用できず、ハードウェアが次の「キー入力」を待つ時間が長くなる
  • DiffusionGemmaは256トークンの段落全体を同時に下書きし、コンピュータープロセッサにより大きな作業単位を一度に与える
  • この構造は、モデル推論を逐次的なタイプライターから、テキストブロック全体を同時に印刷する大型印刷機へと変えるものだ

• ローカル・低同時実行推論向けの高速化

  • DiffusionGemmaの高速化はローカル推論と低同時実行の推論を念頭に設計されている
  • 高QPSのクラウドサービングでは、自己回帰モデルでも演算を効率よく飽和させるようにデプロイできる
  • 高QPS環境ではDiffusionGemmaの並列デコーディングの利点は小さくなり、サービングコストが高くなる可能性がある
  • スループット上の利点は、単一アクセラレータでの低バッチサイズから中程度のバッチサイズで最も強く現れる

テキスト拡散の仕組み

• テキスト拡散は、視覚ノイズから始めて鮮明な画像へと反復的に改善するAI画像生成に似た手順をテキストへ適用するもの
• 最初の段階であるキャンバスでは、モデルはランダムなプレースホルダートークンで構成されたキャンバスから始める
• 反復改善段階では、モデルが複数回のパスを実行し、正しいトークンを固定したうえで、それを文脈手がかりとして残りを洗練する
• 最終仕上げ段階では、テキストは高品質な出力へと収束する
• モデルが生成中に段落全体を処理できるため、複雑なMarkdown書式を正確に閉じたり、コードをほぼリアルタイムで生成・レンダリングしたりする動作パターンが可能になる

始め方

• 実験用モデル重みは寛容なApache 2.0ライセンスで提供され、Hugging Faceから利用できる
• DiffusionGemma developer guideで統合方法を確認でき、A Visual Guide to DiffusionGemmaで内部メカニズムをより深く見られる
• モデルサービングはMLX、vLLM、Hugging Face Transformersを使って行える
• vLLM統合はRed Hatの支援を受けている
• 迅速な実験のために、組み合わせやすさを重視して設計されたモジュラーJAXツールボックスであるHackable Diffusionベースのファインチューニングチュートリアルが提供されている
• ファインチューニングはUnslothやNVIDIAのNeMoでも試せる
• llama.cppの公式サポートは近日提供予定

最適化と実行環境

• NVIDIAとの協業によりハードウェアスタック全体で最適化が行われ、コンシューマー環境とエンタープライズシステムの双方で互換性と性能を提供する
• コンシューマー環境ではGeForce RTX 5090および4090 GPU向けの量子化をサポートする
• エンタープライズ環境では、高度なNVFP4カーネルを使用するHopperおよびBlackwellで高性能を発揮する
• ローカルなデスクサイド展開向けのNVIDIA DGX SparkとDGX Station、AI専門家向けのRTX PROも対象に含まれる
• NVFP4の4ビット浮動小数点ネイティブサポートは演算スループットを加速し、モデルをより高速かつほぼ無損失の精度で動作させる
• 実行方法は、デスクトップ専用GPU、Gemini Enterprise Agent Platform Model Garden、NVIDIA NIMから選択できる

[GN⁺]

Hacker Newsの意見

• 最近OpenCodeに移って、米国の主要フロンティア研究所製ではないモデルをいろいろ使ってみたが、予想外にいちばん気に入ったのはMercuryだった
  「賢いから」ではなく、とんでもなく速かったからだ。プロンプトを入れて待つ最近のエージェント的な体験というより、ペアプログラミングに近く、AIの利点は得つつもAI以前のコーディング感覚が少し戻ってきて、より楽しかった。プロンプトを入れて待ちながら方向性が合っていることを祈るスロットマシンのようではなく、Gemini Flash LiteやGPT Mini/Nanoのような小さなモデルも、より頻繁に使うようになった。オープンウェイトモデルが出るとのことで期待しており、すぐに試す予定だ

  • テストを速く安く回せて、悪いコードや雑に書かれたコードを見分ける低コストな指標もすばやく作れるなら、時間が重要なときは、遅いがはるかに優れたモデルより、速いが少し劣るモデルのほうが良いかもしれない
    循環的複雑度ではなく実際の複雑度を測る指標を用意し、機能に対して追加された複雑さが合理的な範囲に収まるまで自動で巻き戻すようにしたところ、LLM活用の成果はかなり良かった
  • Mercury-2は素晴らしい。llm-consortiumで仲裁役としてよく使っている
    コンテキストウィンドウが比較的小さいので、より大きなコンソーシアムで使うなら再帰的なメタ・コンソーシアムのように構成できる:
    llm consortium save cns-glm -m glm-5.2 -n 5 --arbiter mercury-2 --judging-method rank
llm consortium save cns-kimi -m k2.6 -n 5 --arbiter mercury-2 --judging-method rank
llm consortium save cns-meta-glm-kimi -m cns-glm -m cns-kimi --arbiter mercury-2 --judging-method synthesis
    あとはcns-meta-glm-kimiにプロンプトを入れれば、kimiとglmでそれぞれ5個の中から最良を選び、その2つの勝者の回答を合成する
  • これがコーディング用ローカルモデルにどれだけ影響するのか気になる。QwenやGemma 4より数倍速い拡散モデルを使うなら、AI以前のように自分でより多く準備する必要はあるだろうが、それがむしろ良い可能性もあり、ローカルで非常に高速かつ低コストなモデルと作業できそうだ
    長く重い計算をしないなら、ローカルハードウェアで動かすコストももっと安くなるのではないかと思う
  • 言いたいことはよく分かる。個人プロジェクトでClaudeが遅すぎていら立っていたので、Google AntigravityとFlashモデルに切り替えたが、速度差はものすごい
    流れに乗りやすくなり、作業にもより集中できる。速度がここまで大きな違いを生むとは思わなかった。Claudeは非常に複雑で大規模なコードベースでは、遅い応答時間と引き換えに得られるタスク複雑度の価値があるが、Antigravityや他の高速モデルは、小さく軽くコードを書いて実行し、デバッグを繰り返したいときにはるかに合っている
  • その通り、速度が核心だ。ボイラープレートのPOJOやデータクラスを300+ tok/sという狂った速度で生成してくれるのは良くて、こういうケースではFlash-LiteのほうがGPT-5.5より有用だ
    遅すぎると、あの忌々しい非同期の待機ループに閉じ込められてしまう

• Googleは引き続き力を見せている。Geminiがコードやエージェント用途でClaudeやOpenAIのモデルより競争力が高くないのは意外だが、Googleに依然として業界最高水準のAI人材がいるのは明らかだ
  ただGoogleは、大規模な思考型LLMよりも、スマートフォン上で動くものやほぼリアルタイムのユースケースに注力しているように見える。こうした効率改善は今後のAIで非常に重要になる可能性が高い。特定のエコシステムに囲い込むため、トークンを補助金のように安く配っていた時代は終わりつつあり、実コストを支払う時が来ている。本当に賢いモデルをコスト効率よく回す方法を見つける企業が勝つだろう。DeepSeekはGPT 5.5やOpus 4.8より一桁以上安く、両者より劣るとはいえ致命的に悪いわけではない。最高のコーディングモデルが人間の時間を十分に節約してくれるなら10倍でも喜んで払うが、最近のベンチマークでGPT 5.5 ProがDeepSeekより200倍以上、Opus 4.8より約30倍高いケースのように、100倍の差になると受け入れにくい

  • FableはOpusの2倍のコストで、GPT-Proともかなり競争力がありそうなので、過敏な安全装置が大きな問題でないなら悪くない選択肢かもしれない
    Googleにもこの領域で独自の「Deep Research」オプションがあり、うまく機能しているようだ。DeepSeekの良い点は、APIコストなしでローカルハードウェア上で動かせることだ。それを重視するなら、OpusやGPTより少し劣っていても大きな問題ではない
  • 結局はGoogleが勝つ気がする。ワット当たり性能とドル当たり性能という重要な部分に集中している
    独自の推論ハードウェアを作っており、レイテンシと計算オーバーヘッドを減らすエッジコンピューティングへ向かっている。大規模LLMはまだコスト効率が良くなく、Googleは競合が消費者に原価割れで「売る」ために投資資金を燃やすのを横目で見ている。AIバブルがはじけた後でもGoogleのような企業は無傷で生き残るだろうし、このバブルは一部巨大企業の化けの皮をはがすものにも見える

• 一部の反応は 拡散方式 の利点を見落としている。スマートフォンやコンピューターGPUのようなエッジ機器では大きな影響があり得る。
  LLMのデコーダーは以前のトークンをすべて考慮する必要があるため、トークンを1つずつ計算する。従来のLLMデコーダーは、複数の推論をバッチでまとめられるほど負荷が十分にあればうまくスケールし、その環境では拡散の利点は限定的だ。エッジでは事情が異なる。推論アクセラレーターはRAMからGB単位の重みを絶えず移動させるために飢餓状態になる。LPDDRx/GDDRxのようなコンシューマー向けRAMはHBMより帯域幅が低く、リクエストが直列なので共通の重み計算をバッチ化できないからだ。拡散はトークンを並列に計算できるため、メモリ帯域幅のボトルネック を緩和する。

  • エッジ機器はメモリ帯域幅が不足しているだけでなく、演算性能 も非常に限られている。実際には大きなバッチがなくても実行可能な演算量はすぐに飽和し、明確な発熱・電力制約に突き当たる。
    エッジ推論で「リクエストが本質的に直列」というのも実は正しくない。同時に複数のリクエスト、つまり複数のチャットが進行しており、KVキャッシュを保持するメモリ容量が十分にあればバッチ処理は適用できる。拡散モデルがより多くの演算でより低い品質を出し、メモリ帯域幅の節約も曖昧なら、どう役立つのかよく分からない。
  • 概ね正しいが、アテンション と自己回帰・因果構造を混同している。より多くの演算を使えなくしている本当の問題は自己回帰・因果構造だ。
    拡散でもアテンションは使えるし、このモデルも実際にアテンションを使っている。

• NVIDIAがこのモデル向けの 無料エンドポイント を提供している。詳細は https://build.nvidia.com/google/diffusiongemma-26b-a4b-it にあり、アカウントを作成し、おそらく電話番号認証も必要だ。
  ペリカンを描かせてみた: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

  • もし非常に高速なモデルなら、アニメーションのフレームをリクエストできるかもしれない。例えば1フレーム目は右足が12時、左足が6時、2フレーム目は右足が3時、左足が9時といった具合だ。
    そうなると、1秒あたりトークン数ではなく、当然 1秒あたりのペリカンフレーム数 を報告すべきだ。
  • 数週間前に登録したが、手順に従ったにもかかわらず、まだアカウントが認証されていない。アカウントが認証されていないと API は使えない。

• DiffusionGemmaのような テキスト拡散モデル がどう動くのかを示す良いビジュアル解説: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

• 数日前までは、Googleが1年前のI/Oで実演したあと 拡散テキスト生成モデル についてまったく話していないと思っていた。
  動かすのが高価すぎるという噂があったが、提示されたチャートのように同じ1x H100ハードウェア上でDiffusionGemmaと通常のGemmaを比較するなら、そうでもなさそうだ。Gemmaより少し弱いこと以外に、この速度の欠点が何なのか気になる。

  • 「この速度の欠点が何なのか気になる」への答えはこの部分だと思う:
    「DiffusionGemmaの速度向上は、ローカルおよび低同時実行性の推論向けに設計されている。高QPSのクラウドサービングでは、自己回帰モデルを効率的にバッチ化して演算を飽和させられるため、DiffusionGemmaの並列デコーディングの利点は小さくなり、サービングコストが高くなる可能性がある」
  • 標準的な 自己回帰モデル なら、ユーザーが256人いるとき、例えば一度に256トークンを生成できる。この方式は1人のユーザーに対して256トークンを生成できるが、複数回の順伝播ステップが必要になる。
    そのため拡散プロセスはより多くのGFLOPsを使い、ユーザー数が十分に多ければ、すでにメモリと演算のバランスを取ることができる。

• 「DiffusionGemmaはこの非効率を逆転させる。単語を順番に予測する代わりに、256トークン段落全体の下書きを同時に作る。コンピュータープロセッサーにより大きな作業の塊を一度に与えることで、ハードウェアを最大限に活用する。モデル推論を、1文字ずつ打つタイプライターから、テキストのブロック全体を同時に印刷する巨大な印刷機へとアップグレードする」
  「推論中は3.8Bパラメーターのみを有効化する、総計26B規模の専門家混合（MoE）モデルとして動作し、量子化すればハイエンドのコンシューマー向け専用GPUの18GB VRAM制限内に十分収まる」
  つまりGemma 4 26Bは、ollamaで自分の24GB GPU上で非常に高速に動く MoEモデル だ。これはスペキュレーティブデコーディングのようにも聞こえるが、MoEモデルではそれは機能しないと思っていた。これを追うのが仕事ではない人にとっては、変化が多すぎて追い切れない。

  • これは既存のgemma4 MoEと紛らわしいことに、パラメーター数がほぼ同じ 別のモデル だ。どちらかがもう一方からどのように学習されたのかは、ざっと見ただけでは不明だ。
    メカニズムはスペキュレーティブデコーディングと同じではない。スペキュレーティブデコーディングは逐次的で、通常は数トークンずつ進む。拡散はそうではなく、テキストブロックを一度に扱う。まだ資料を読んでいないが、拡散ブロック全体で特定の専門家が安定して維持されるように学習したのではないかと推測している。

• 自分の 3090 Ti では宣伝されている速度にはまったく届かないが、回答が「埋まっていく」様子を見るのは面白い。
  Simonの「自転車に乗ったSVGペリカン」テストを試してみたところ、結果はかなりミニマルだが要件は満たしていた: https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- パッチを当てた llama.cpp でQ4量子化を使って動かした結果だ。Simonの結果がどれだけ違うのかも気になる。

• 拡散型推論モデルはどんな形になるのだろうか？ あらかじめ決められた長さの[thinking]ブロックを長く拡散させて、最終出力ブロックはその thinking ブロックの内容を入力の一部として使う、という感じだろうか？
  そして拡散モデルはそもそも出力長をどう決めるのだろう？ 事前に決めたパラメータなのか、それとも途中のどこかで[end]トークンを拡散させるのかが気になる

  • 残りのコメントを読んで、答えを1つ得た。拡散プロセス自体が本質的に推論に似た過程だというのは納得できる: https://www.inceptionlabs.ai/blog/introducing-mercury-2

• すごいとは思うが、ローカルモデルはすでに十分良くても最安のAPIより体感では明らかに劣るので、速度のために品質を少しでも犠牲にしようとはあまり思えない
  ある種のユースケースには確かに価値があるだろうが、実際に本番環境へデプロイしようとしている具体的な事例が気になる

  • 単体テストの作成やブートストラップには向いているかもしれない
    Opus級でなくても作成できるし、反復もしやすい