ローカルでLLM（大規模言語モデル）を動かすとき、GPUはその演算能力の大半を持て余している。自己回帰型モデルは1トークンずつ順番に生成する構造上、処理の大半がメモリからの読み出し待ちに費やされ、GPU本来の並列演算能力はほとんど使われない。Google DeepMindが2026年6月11日に公開した「DiffusionGemma」は、この構造的な問題に正面から向き合う。26B（260億）パラメータのMoE（Mixture of Experts）アーキテクチャを採用し、画像生成AIと同じ拡散（デノイジング）原理でテキストを生成することで、H100単体で1,000 tokens/secを超える速度を実現した。ただし、その速度の源泉がそのまま「クラウドでは使えない理由」にもなっている。
テキスト拡散の仕組み：なぜGPUを遊ばせないのか
自己回帰型LLMは、トークンを1つ出力するたびにモデル全体のパラメータをメモリから読み込み直す。バッチサイズが1（シングルユーザー）の場合、GPUのテンソルコアは計算対象がほとんどない状態で待機し続ける。ボトルネックはコンピュートではなく、メモリ帯域幅だ。
ランダムノイズから始めて、256トークンのブロックを1フォワードパスで一括処理する。画像生成の拡散モデルがピクセル全体を同時にデノイズしていくのと同じ原理で、テキストの「全体像」を段階的に確定させていく。この設計により、メモリ帯域幅のボトルネックをコンピュートにシフトさせ、1トークン順次生成の制約を構造的に回避する。Brendan O'Donoghue氏（Google DeepMind）は「デコードのボトルネックをメモリ帯域幅からコンピュートへシフトすることで、専用GPUで最大4倍の速度を実現した」と述べている（原文："By shifting the decoding bottleneck from memory bandwidth to compute, we achieve up to 4x speed improvements on dedicated GPUs"）。
256トークンの一括処理は、バッチを大きくすることとは本質的に異なる。バッチサイズを上げれば複数リクエストを同時処理できるが、それは複数ユーザーへの並列対応だ。DiffusionGemmaが狙うのは単一ユーザーのリクエスト1件の処理を、GPU演算資源を使い切る形で完了させることにある。ローカル開発者が単独でモデルを使う環境でこそ、この設計の恩恵が最大化される。
推論時のアクティブパラメータは3.8Bに絞られている。総パラメータ26BのうちMoEが効率的にルーティングすることで、量子化時に18GB VRAMで動作し、RTX 5090などの高エンド消費者向けGPUでの実行を可能にしている。これが「26B規模のモデルを一般向けGPUで走らせる」という現実的な要件を満たす設計上の核心だ。
数字で見る速度：H100で1,000 t/s、RTX 5090で700 t/s
比較対象は同等サイズの自己回帰型Gemmaモデルをシングルユーザー・ローカルGPU環境で動かした場合だ。Google・NVIDIAが共同で報告した主要プラットフォームの測定値は以下のとおりだ。
- NVIDIA H100（単一GPU）: 1,000+ tokens/sec
- NVIDIA GeForce RTX 5090: 700+ tokens/sec
- NVIDIA DGX Station: 最大800 tokens/sec
- NVIDIA DGX Spark: 150 tokens/sec（NVIDIAによる）
Googleの内部ベンチマークでは、DiffusionGemma（1,107 tokens/sec）対Gemma 4 26B A4B（303 tokens/sec）という数値が示されており、倍率は約3.65倍に相当する。Google・NVIDIAが公称する「最大4倍」はこの実測値を丸めた表現とみられる。
Gemini Diffusionが昨年のGoogle I/O 2025で披露した際の数値（1,479 tokens/sec、Gemini 2.0 Flash-Lite相当）と比べると、DiffusionGemmaのH100値はそれに近い水準にある。研究段階で示されたパフォーマンスをオープンウェイトモデルとして実装し直した結果が、この数値に表れている。
4倍速の代償：品質とユースケースのトレードオフ
速度の改善には明確なコストが伴う。Googleのベンチマーク比較では、DiffusionGemmaはMMMU（マルチモーダル理解）、MMLU Pro（専門知識）、AIME 2026（数学）、LiveCodeBench v6（コーディング）、GPQA Diamond（科学）、tau2-bench（ツール利用）の全カテゴリでGemma 4を下回った。Googleは現段階での品質水準を「実験的」と明示しており、速度より品質が求められる用途には向かない。
クラウド推論との相性も制約として理解しておく必要がある。高スループット・高並行性が求められるクラウド環境では、自己回帰型モデルのほうが効率的に動作する。バッチサイズを大きくとれるクラウドでは、自己回帰型でもGPUの稼働率を高められるためだ。DiffusionGemmaの強みは「ローカル・低並行性」という限られた条件下でのみ発揮され、クラウドAPIとして提供した場合、むしろコストが増大する可能性がある。
品質トレードオフを踏まえたうえで、この速度が意味を持つのはプロトタイピング・開発中のコード補完・データ変換など、応答のリアルタイム性が重要かつ生成物の厳密な精度が必ずしも必要でない場面だ。本番環境の推論よりも開発ループの高速化という用途が、現段階での現実的な活用領域になる。
非線形タスクへの適性：双方向アテンションが開く扉
自己回帰型モデルは左から右へ一方向にテキストを生成するため、後続のコンテキストを参照できない。双方向アテンション（bi-directional attention）を持つDiffusionGemmaでは、生成中のトークンが前後の文脈を同時に参照しながらデノイズされていく。この特性は特定のタスク類型でアーキテクチャ上の根本的な差を生む。
既存テキストの中間部分を書き換えるインライン編集では、前後の文脈を同時に踏まえた生成が構造的に可能になる。コード穴埋め（FIM: Fill-In-the-Middle）でも同様で、関数の前後を参照しながら中間のロジックを補完する動作が自然に行われる。Googleは数独（Sudoku）の解法生成も例示しており、前後の制約を同時に考慮しながら答えを導く非線形タスクとの親和性を示している。
アミノ酸配列生成のような生物情報科学的な応用例も言及されており、左から右の順序に意味的な制約がないタスクでは、一方向生成モデルに対してアーキテクチャ上の構造的な優位を持つ可能性がある。ただし、これらはベンチマーク上の測定値として現時点で示されているわけではなく、設計特性から導かれる理論的な適性の段階だ。
今から試せる環境：どのツールを選ぶか
RTX・DGX全製品ラインでのDay-1対応をNVIDIAが発表したことで、公開初日からハードウェア対応の幅が整っている。NVFP4量子化による最適化を含むNeMoフレームワークへの統合が実施されており、RTX 5090でのNVFP4利用時には特に速度の恩恵が大きい。
エコシステム側では用途別に選択肢が揃っている。vLLM（Red Hat統合版、高スループット推論対応）・MLX（Apple Silicon最適化）・Unsloth（推論高速化・量子化特化）・NeMo（NVIDIA統合フレームワーク）・Hackable Diffusion（JAX実装、研究向けカスタマイズ）が即日サポートを開始した。llama.cppは近日対応予定で、量子化を含む幅広いハードウェア環境への展開が進む見込みだ。Hugging Faceへのモデルウェイト公開とApache 2.0ライセンスの組み合わせにより、商用利用・改変・再配布の制限がない点も開発者エコシステムへの普及を後押しする。
競合としてInception社のMercury 2（2026年初頭に登場）が拡散方式テキスト生成の先行事例として存在するが、DiffusionGemmaはNVIDIA全プラットフォームの同日対応という体制で、開発者が試しやすい環境を整えている。逐次生成の壁を崩すというアプローチ自体は新しくないが、オープンウェイトで実装し、18GB VRAMという現実的なハードウェア要件に収めたことで、これまで研究者の関心にとどまってきたテキスト拡散モデルが実際の開発ワークフローに入り込む余地が生まれた。品質面での制約が解消されるかどうかが、この技術の本格的な普及を左右する次の評価ポイントになる。
