DiffusionGemma: 並列拡散による4倍高速なテキスト生成

DiffusionGemmaは、逐次的なトークン生成を並列テキスト拡散に置き換えることで、4倍高速な推論を実現します

DiffusionGemmaは、従来の自己回帰型の大規模言語モデル（LLM）のレイテンシのボトルネックを解消するために設計された、実験的なオープンウェイトモデルです。一度に1トークンずつ生成するのではなく、テキストのブロック全体を同時に生成することで、専用GPU上で最大4倍高速なテキスト生成を実現します。Apache 2.0ライセンスの下でリリースされたこのモデルは、26B Mixture of Experts (MoE) アーキテクチャを採用しており、推論時には3.8Bパラメータのみをアクティブ化するため、量子化時にはハイエンドのコンシューマー向けGPUの18GB VRAM制限内に収めることが可能です。

メモリ帯域幅のボトルネックの解決

従来のLLMは「タイプライター」のように動作し、トークンを左から右へと逐次的に生成します。リクエストをバッチ処理できる高並列なクラウドサービングでは効率的ですが、このプロセスはローカルのシングルユーザー推論においては非効率的です。ローカル環境では、システムが実際に計算を行う時間よりも、RAMからプロセッサへ重みを移動させることに多くの時間を費やすため、GPUが十分に活用されないことがよくあります。

DiffusionGemmaは、ボトルネックをメモリ帯域幅から計算量へとシフトさせます。単一の次のトークンを予測する代わりに、256トークンのパラグラフを同時にドラフトします。この「印刷機」のようなアプローチは、ハードウェアの計算能力を飽和させ、ローカルアクセラレータ上で大幅な速度向上をもたらします。

  • NVIDIA H100: 1000+ tokens per second.
  • NVIDIA GeForce RTX 5090: 700+ tokens per second.

技術的アーキテクチャと機能

DiffusionGemmaは、Gemma 4ファミリーおよびGemini Diffusionの研究に基づいた、新しい拡散ヘッドを統合しています。その動作ロジックはAI画像生成と同様です。ランダムなプレースホルダー・トークンのキャンバスから始まり、テキストが最終的な出力へと収束するまで、複数回のパスを通じて反復的に洗練させていきます。

主要な技術的利点

  • 双方向アテンション: 256トークンが並列に生成されるため、すべてのトークンがブロック内の他のすべてのトークンにアテンションを向けることができます。これにより、モデルはコードのインフィリング、インライン編集、数学的グラフ、アミノ酸配列などの非線形タスクに非常に適しています。
  • インテリジェントな自己修正: モデルはテキストブロック全体を一度に評価するため、洗練プロセスの中でリアルタイムに間違いを修正することができます。
  • ハードウェア最適化: モデルはNVFP4 (4-bit floating-point) カーネルをサポートしており、HopperおよびBlackwellアーキテクチャ上で、精度をほぼ損なうことなく計算スループットを加速させます。

トレードオフと実用化

DiffusionGemmaは、生の出力品質よりも、速度と並列レイアウトを優先しています。その全体的な品質は、標準的な自己回帰型Gemma 4モデルよりも低くなります。したがって、Googleは、最大限の品質を必要とするアプリケーションには標準のGemma 4を推奨し、DiffusionGemmaは速度が重要なインタラクティブなローカルワークフロー向けに意図されています。

開発者エコシステムと統合

DiffusionGemmaは、迅速な実験を目的として設計されており、以下の主要なAIフレームワークと互換性があります。

  • サービング: MLX、vLLM (Red Hatとの統合を含む)、およびHugging Face Transformersを介してサポートされています。llama.cppへの公式サポートは保留中です。
  • ファインチューニング: 開発者は Hackable Diffusion JAX toolbox、Unsloth、または NVIDIA NeMo を使用できます。ファインチューニングの顕著な例としては、Unslothを使用してモデルに数独を解かせる例があり、これは双方向アテンションが自己回帰型モデルよりも明確な利点を提供するタスクです。
  • デプロイメント: Hugging Face、Gemini Enterprise Agent Platform Model Garden、および NVIDIA NIM を介して利用可能です。

コミュニティの洞察と分析

開発者の間での技術的な議論では、拡散モデルがプロンプトとレスポンスの間の待ち時間を減らすことで、「ペアプログラミング」の体験を体験に変える可能性が強調されています。

"It was more of a pair-programming experience instead of the SOTA agentic experience of prompting and waiting... It felt less of a slot machine where you prompt, wait, and hope it went in the right direction." — @vineyardmike

他の貢献者は、エッジデバイスにおけるメモリ帯域幅の問題の重要性を強調しています。

"On edge you have a different problem: your inference accelerator is starved while sloshing GB of weights back and forth from RAM... Diffusion can compute tokens in parallel which relieves the memory bandwidth bottle neck." — @samuelknight

ツール呼び出しや推論といった特定のドメインにおけるモデルの性能に関する疑問は残っています。一部のユーザーは、モデルが前の行を再編集できる能力により、モデルがモノリシックなツール呼び出しよりも、むしろ「変更ストリーム」や複数のファイルにわたる一連連鎖的な編集操作に適していることを示唆しています。

Sources