DiffusionGemmaをローカルで動かす｜量子化時に約18GB VRAMで載る拡散LLM、自己回帰比で最大4倍速の理屈

DiffusionGemmaとは、拡散方式で文章を生成するGoogle製のオープンウェイト言語モデル。

ローカルでテキスト生成AIを速く動かしたいなら、2026年6月に登場したDiffusionGemmaは選択肢の中身を一度組み替える存在です。Google DeepMindが公開したこのモデルは、画像生成で使われてきた拡散（ディフュージョン）の技術を文章生成に持ち込み、自己回帰型LLMが抱えてきたメモリ帯域の制約を別の角度から回避します。Googleの主張では、GPU上で従来の自己回帰モデル比、最大4倍の出力速度。量子化すれば約18GBのVRAMに収まり、ハイエンドのコンシューマーGPUでローカル実行できる、というのが触れ込みでした。ただし速さには代償もあります。本記事では「何が新しいのか」「なぜ速いのか」「自分の環境で動くのか」を、公式の一次情報に沿って整理しました。

この記事の要点

・DiffusionGemmaは拡散方式で複数トークンを並列に精製し、自己回帰LLMのメモリ帯域ボトルネックを回避する
・量子化で約18GB VRAMが目安。GPU上で自己回帰比、最大4倍速（Googleの主張）を狙う
・出力品質は主要ベンチの多くでGemma 4を下回る。公式窓口はHF Transformers（Diffusers版も）/vLLM/MLX/SGLang（標準のllama.cpp・Ollamaは未対応）

DiffusionGemmaとは｜拡散方式でテキストを生成する言語モデル
1. 自己回帰（AR）方式との違い
2. Dream・Mercuryなど拡散系LLMの系譜
なぜ自己回帰LLMはメモリ帯域がボトルネックになるのか
1. 「帯域ボトルネック」と「演算ボトルネック」の違い
拡散LLMが最大4倍速くなる理屈
1. speculative decodeとの位置づけの違い
DiffusionGemmaとGemma 4の違い
約18GB VRAMでローカルに動かす要件と注意点
1. 16GB級GPUユーザーが取れる現実的な選択肢
実務での使われ方と民生ハードの広がり
まとめ｜DiffusionGemmaは何を変えるのか
よくある質問
参考資料

DiffusionGemmaとは｜拡散方式でテキストを生成する言語モデル

DiffusionGemmaとは、Google DeepMindが2026年6月に公開した、拡散方式でテキストを生成するオープンウェイトの言語モデルです。ライセンスはApache 2.0で、誰でもダウンロードして利用できます。Gemmaファミリーの一員でありながら、春に登場したGemma 4とは生成の仕組みが根本から異なる点が特徴。総パラメータは約25.2B（26Bクラス）のMoE（Mixture of Experts、複数の専門家ネットワークを切り替える構造）で、推論時にアクティブになるのは3.8Bだけです。エキスパートは全128個のうち8個がアクティブ、共有エキスパートが1個という構成になっています。

従来のLLMは、文章を「トークン」と呼ぶ単位に区切り、それを1個ずつ前から順に予測していきます。これが自己回帰（AR：autoregressive）方式。DiffusionGemmaは、1トークンずつの逐次生成から、256トークン単位の「キャンバス」を並列に精製する方式へ切り替えます。画像生成モデルであるStable DiffusionやFluxに近い手順で、ランダムなトークンで埋めたキャンバスをノイズ除去のように何度も精製し、ブロック分のトークンをまとめて仕上げていきます。ただし256トークンを超える長い出力では、完成したブロックを履歴に加えてから次のブロックへ進むため、ブロック間は自己回帰的に働きます（公式には block-autoregressive multi-canvas sampling と呼ばれる方式）。

ランダムなトークンで埋めたキャンバスを用意し、最終的な出力に到達するまでそれらを精製していく。

Google 公式ブログ「DiffusionGemma — Faster Text Generation」より（blog.google）

並列に精製するブロックのサイズは256トークン。最大256Kトークンのコンテキストに対応し、入力はテキスト・画像・動画（動画はフレーム列として処理）、出力はテキストです。推論で扱える言語は35以上、事前学習に使われた言語は140以上に及びます。基盤はGemma 4の26B-A4Bアーキテクチャで、そこに拡散方式の生成ヘッドを統合した設計。土台は既存のGemmaと地続きで、生成の作法だけを画像モデル寄りに付け替えた、と捉えると分かりやすいでしょう。

自己回帰（AR）方式との違い

両者の差は「トークンを並べる順番」に集約されます。自己回帰方式は、いま生成したトークンを次の入力に回し、左から右へ一方向に書き進めます。文章としての一貫性を保ちやすい反面、1トークン生成するたびにモデルのパラメータをメモリから読み出す必要がある。拡散方式は最初にブロックの下書き（キャンバス）を置き、何度も塗り直して完成へ近づけます。書き始めの段階でブロック全体の「枠」が存在するため、1回のパスでキャンバス全体を評価し、確信度の高い複数トークンをまとめて確定していけるわけです。この一括評価が速度に効いてきます。

Dream・Mercuryなど拡散系LLMの系譜

拡散方式の言語モデルはGoogleが最初ではありません。先行例としてDream 7B（DREAM）や、Inception LabsのMercuryが知られています。これらはいずれも大きな高速化を示していますが、品質との関係はモデルや比較対象、タスクによって異なります。速度を優先した設計では最高品質の自己回帰モデルに届かないケースがある一方、速度重視の自己回帰モデルと競合する品質を示した例もあります。背景の数字として、Mercury Coder MiniはH100で毎秒1,109トークン超を出すと報告されました。速度と品質のバランスは設計と用途しだい、というのが拡散系LLM全体の現在地だと言えます。

なぜ自己回帰LLMはメモリ帯域がボトルネックになるのか

自己回帰LLMがローカルで重くなる主因は、演算量ではなくメモリ帯域にあります。トークンを1個生成するごとに、モデルの重み（アクティブパラメータ）をVRAMからGPUの演算器へ繰り返し供給する必要があり（CPUオフロード時にはシステムRAMからGPUへの転送も加わります）、この往復が速度の上限を決めるからです。GPUの演算ユニットがいくら速くても、データが届くのを待つ時間が長ければ性能を出し切れません。この状態をメモリ帯域ボトルネック（memory-bandwidth-bound）と呼びます。

加えて、自己回帰方式はKVキャッシュ（Key-Valueキャッシュ：過去のトークンの計算結果を保持する領域）を抱えます。これは生成済みのトークンを再計算せずに済ませる仕組みですが、コンテキスト長に比例して増えていく。長文を扱うほどVRAMを圧迫し、容量の壁にぶつかりやすくなります。ローカルLLMで「16GBに収まる・あふれる」が常に話題になるのは、重みのサイズだけでなく、このKVキャッシュの伸びが効いているためです。VRAMの基礎については当サイトの別記事で容量の目安を整理しています。

クラウドの推論では、この帯域の問題を「数を捌くこと」で薄めています。数百〜数千のリクエストを同時に処理し、メモリから一度読み出したパラメータを多数の要求で使い回す。こうすると演算とメモリ帯域のバランスが取れます。ところが手元のノートやデスクトップ1台では、同時に走らせる要求がせいぜい1〜数件。読み出したパラメータを使い回す相手がいないため、帯域ボトルネックがそのまま表面化してしまいます。ローカル環境こそ、自己回帰方式の弱点が出やすい場所なのです。

「帯域ボトルネック」と「演算ボトルネック」の違い

帯域ボトルネックは「データの運搬待ち」で性能が頭打ちになる状態、演算ボトルネック（compute-bound）は「計算そのもの」が上限を決める状態を指します。自己回帰のトークン逐次生成は前者に偏り、GPUの演算ユニットは余り気味になりがち。逆に拡散方式は、ブロック単位で大量のトークンを同時に処理するため、その余っていた演算力を使い切る方向に振れます。同じGPUでも、ワークロードの性質によって「どこで詰まるか」が変わる――この見取り図を押さえておくと、次の「なぜ速いか」がすっきり理解できます。

拡散LLMが最大4倍速くなる理屈

DiffusionGemmaが速いのは、メモリ帯域ボトルネックのワークロードを演算ボトルネックへ寄せ替えるからです。Googleは、GPU上で自己回帰モデル比、最大4倍のテキスト生成速度をうたっています（あくまでメーカーの主張値で、条件次第で上下します）。各パスで256トークンのキャンバス全体を並列に評価し、そのうち確信度の高い複数トークンをまとめて確定していく（公式モデルカードでは、1回のパスで確定するのは概ね15〜20トークン、キャンバス全体を最大48回のノイズ除去ステップで反復精製するとされます）ため、トークンごとにパラメータを読み直す自己回帰のオーバーヘッドを避けられる、という理屈です。

具体的な速度の例として、NVIDIA H100単体で毎秒1,000トークン超。コンシューマー向けではGeForce RTX 5090で毎秒700トークン超に達するとされます。いずれも公式系の計測値であり、当サイトの環境で測ったものではありません。

注意したいのは、「最大4倍」と「18GB」を同じ計測の話として結びつけないこと。4倍はGPU上での自己回帰比の高速化主張であり、18GBは量子化時のVRAM収容目安です。別々の文脈の数字なので、「18GBで4倍出る」と読み替えるのは誤りになります。クラウドのように高い同時処理数（高QPS）が前提の環境では、自己回帰側も並列で効率を取り戻すため、拡散方式の速度優位は縮みます。低並列のローカル環境でこそ差が出やすい、という方向の最適化だと理解しておくと実態に近いでしょう。

speculative decodeとの位置づけの違い

自己回帰LLMを速くする既存手法に、speculative decode（投機的デコード：小さなモデルで先読みし、本体モデルでまとめて検証する方式）があります。これは自己回帰の枠組みを保ったまま生成を加速するアプローチ。対してDiffusionGemmaは生成方式そのものを拡散に置き換えます。二次情報ではありますが、The Registerによれば、speculative decodeを有効にしたGemma 4 12B比で約2.25倍という比較も示されました。ただし公式モデルカードの比較対象は同規模のGemma 4 26B-A4Bであり、12B比や2.25倍はあくまで帰属付きの参考値として扱うのが妥当です。

DiffusionGemmaとGemma 4の違い

DiffusionGemmaとGemma 4の最大の違いは、生成方式と、その結果として現れる「速度と品質のトレードオフ」にあります。Gemma 4は自己回帰でじっくり品質を取りに行くモデル、DiffusionGemmaは拡散方式で速度を取りに行く実験的モデル、という住み分けです。土台のアーキテクチャ（26B-A4B）は共有していても、出力の性格は別物になります。

比較項目	DiffusionGemma	自己回帰LLM（Gemma 4 など）
生成方式	離散拡散（ブロック内は並列精製・ブロック間は自己回帰）	自己回帰（1トークンずつ逐次）
ボトルネック	演算ボトルネック（compute-bound）寄り	メモリ帯域ボトルネック
KVキャッシュ	あり。確定済みの256トークンブロック単位で追加され、総量は履歴長に応じて増加	コンテキスト長に比例して増加
速度の狙い	低並列ローカルで最大4倍速	高並列クラウドで効率化
出力品質	主要ベンチの多くでGemma 4より低い（同26B-A4B比）	DiffusionGemmaより高い傾向
対応ランタイム	HF Transformers（Diffusers版も） / vLLM / MLX / SGLang（標準llama.cpp・Ollamaは未対応）	llama.cpp / Ollama 含め広範

品質差は数字でも確認できます。同じ26B-A4B構成のGemma 4と比べると、DiffusionGemmaはMMLU Proで77.6%対82.6%、GPQA Diamondで73.2%対82.3%、LiveCodeBench v6で69.1%対77.1%と、いずれも下回りました。差は極端ではなく、HLE（no tools）ではDiffusionGemmaが11.0%対8.7%と上回る項目もありますが、主要ベンチマークの多くではGemma 4が上です。

ではどちらを選ぶべきか。回答の正確さや難しい推論・コーディングの質を最優先するなら、現状はGemma 4が無難です。一方、対話の下書きや大量のテキストをとにかく速く吐き出したい、低並列のローカルで体感速度を上げたい、という用途ならDiffusionGemmaが刺さります。速度を測った数値（tok/s）と、品質・実用適性（コーディングの安定性やツール呼び出しの確実さ）は別の次元。後者は本記事では評価していないため、ご自身のタスクで確かめるのが確実です。

約18GB VRAMでローカルに動かす要件と注意点

DiffusionGemmaをローカルで動かす目安は、量子化モデルをGPUに載せる際の約18GBのVRAMです。Googleが約18GBとして示しているのはこの量子化時のVRAM目安であって、システムRAMを含めて「メモリ全般が18GBあればよい」という話ではありません。システムRAMへのオフロードやCPU実行は別の構成で、同じ速度が得られるとは限りません。参考までに、非量子化（BF16）の公式Transformers例では、重みだけで約52GB（26Bパラメータ×2バイト）になります。実行時のピークはランタイム・バッファ・KVキャッシュのぶん上振れするため、単体のコンシューマGPUには収まりません。

実行環境（ランタイム）は、Hugging Face Transformersが箱出しで対応します。Hugging FaceではTransformers版に加えてDiffusers版も提供されており、今後の新機能は主にDiffusers側へ追加される予定です（Transformers版は主にバグ修正の扱い）。高スループット用途にはvLLMが対応し、Apple Silicon向けにはMLXも利用可能です。SGLangも対応先で、公式モデルカードには pip install sglang と sglang.launch_server の実行例、Docker での起動例まで掲載されています。なおApple Siliconは演算とメモリ帯域の比が低いため、拡散方式による高速化の恩恵は限定的になります。公式リポジトリを読み込む最小構成のイメージは次の通りです。

# transformers>=5.11.0 が必要
from transformers import DiffusionGemmaForBlockDiffusion, AutoProcessor

model_id = "google/diffusiongemma-26B-A4B-it"  # 公式の標準（非量子化）リポジトリ
model = DiffusionGemmaForBlockDiffusion.from_pretrained(
    model_id,
    dtype="auto",
    device_map="auto",
)
processor = AutoProcessor.from_pretrained(model_id)
# 注: この標準の非量子化 (BF16) 構成は重みだけで約52GB。実行時ピークはさらに上振れする。
# 約18GBでの実行には、対応する量子化モデルと推論ランタイムが別途必要。

約18GBという目安には注意点が3つあります。第一に、この約18GBは量子化時のVRAM目安で、VRAM 16GBのGPU（RTX 5080など）には収まりません。実行時の余裕も含めると、24GB級以上のGPU（RTX 4090・RTX 5090など）が現実的です。第二に、当サイトの検証環境にRTX 5080は含まれますが、DiffusionGemma自体の実測はしておらず、本記事の速度はH100/RTX 5090/DGXなど公式系の計測値の引用に留めています。第三に、公式の対応窓口はHugging Face Transformers（Diffusers版も）・vLLM・MLX。SGLangも公式モデルカードに導入手順と起動例が載っています。llama.cppはmainlineへの正式統合が未完了（PRはDraft段階）で、標準のllama-cli/llama-serverではまだ生成できませんが、実験的なPRブランチと専用のllama-diffusion-cliを使えばGGUFを実行できます。標準のOllamaでは未対応です。

DiffusionGemmaもKVキャッシュを使います。プロンプトを処理する自己回帰エンコーダーがKVキャッシュを作り、256トークンのキャンバスが1ブロック完成するたびに、それをエンコーダーで処理してKVキャッシュへ追加し、次のキャンバスを生成します。通常の自己回帰モデルのようにトークンごとにKVを伸ばすのとは使い方が異なりますが、「KVキャッシュなし」ではありません。メモリはこのKVキャッシュに加えて、ブロックの反復精製にも使うプロファイルになります。ローカルでGemma系をどう動かすかという全体像は、姉妹サイトのローカルLLMとは？Ollama × Gemma 4でコードを外に出さず使うAI環境を初心者向けに解説もあわせて読むと、ソフト側の前提が掴みやすいでしょう。

16GB級GPUユーザーが取れる現実的な選択肢

VRAM 16GBクラスのGPUしか手元にない場合、現状でDiffusionGemmaを無理に動かそうとするより、対応ランタイムが揃うのを待つのが堅実です。HF TransformersやvLLMはGPUメモリが足りていれば動きますが、約18GB目安に届かない構成では素直に載りません。16GB級で日常的にローカルLLMを使いたいなら、当面は量子化済みの自己回帰モデル（7B〜14Bクラスなど）を選ぶほうが安定します。DiffusionGemmaは「いずれ降りてくる新方式」として観測しつつ、llama.cppの正式対応やより小さい派生が出た段階で再検討する、という構えが現実的です。

実務での使われ方と民生ハードの広がり

DiffusionGemmaの実務での位置づけは、低並列のローカル環境で「速いテキスト生成」を担う実験的な選択肢、というものです。下書きの大量生成、対話アプリのレスポンス短縮、オフラインでのテキスト整形など、品質よりスループットが効く場面に向きます。逆に、厳密な事実確認や難度の高いコード生成のように品質が最優先される業務では、Gemma 4のような自己回帰モデルを併用する形が無難でしょう。

土台となる民生ハードの裾野も広がっています。NVIDIA公式によれば、個人向けにAIエージェントを手元で動かすことを狙ったDGX Sparkや、データセンタークラスのGPUを積むDGX系の構成が登場し、大容量のユニファイドメモリを備えた専用機が市場に出てきました。ローカルでエージェントを安全・私的に走らせるには、それに見合うハードが要る、という流れです。ただし、大容量のユニファイドメモリ（DGX Sparkは128GB）が有利なのは大きなモデルを載せる収容力であって、それだけで高速とは限りません。NVIDIA公称値ではDGX Sparkが毎秒約150トークンで、RTX 5090の700トークン超やH100の1,000トークン超には及びません。演算ボトルネックへ寄せても、メモリ帯域が広いGPUほど速度は伸びます。

実務で使い始める際に知っておくと便利なのが、ランタイムの確認。DiffusionGemmaの公式の対応窓口はHF Transformers（Diffusers版も）／vLLM／MLX／SGLangで、標準のOllamaやllama.cppではまだ動きません（llama.cppは実験ブランチのみ）。手元の環境がこのいずれかに乗っているかを先に確かめてから、GPUのVRAMが約18GB目安に届くかをチェックすると、つまずきが減ります。

一般的な市場動向として、NPUを備えた軽量ノートも増え、ローカルでAIを扱う裾野は広がっています（ただしDiffusionGemmaが公式にNPU対応を示しているわけではありません）。とはいえDiffusionGemma自体は、速度を取りに行った代わりに品質ではGemma 4に譲る、まだ完全な性能向上には至っていない実験的なモデル。「速い＝そのまま優れている」と読み替えず、測った次元（速度）と測っていない次元（品質・用途適性）を分けて評価するのが、現時点での誠実な向き合い方です。

アーキテクチャ	離散拡散方式（ブロック自己回帰型・block-autoregressive multi-canvas）
パラメータ	約25.2B（26Bクラス）MoE・推論時アクティブ3.8B
エキスパート	全128・アクティブ8・共有1
入出力	入力=テキスト・画像・動画／出力=テキスト
コンテキスト長	最大256Kトークン
メモリ目安	量子化時で約18GB VRAM
公称速度	GPU上で自己回帰比最大4倍（Googleの主張）
ライセンス	Apache 2.0（オープンウェイト）
対応ランタイム	HF Transformers（Diffusers版も） / vLLM / MLX / SGLang（標準llama.cpp・Ollamaは未対応、llama.cppは実験ブランチのみ）

まとめ｜DiffusionGemmaは何を変えるのか

DiffusionGemmaが持ち込んだのは、自己回帰LLMのメモリ帯域ボトルネックを、拡散方式で演算ボトルネックへ振り替えるという発想です。要点は3つ。まず仕組みとして、ランダムなトークンのキャンバスをブロック単位で反復精製し、複数トークンを並列に確定していく（ブロック間は自己回帰）。次に速度として、GPU上で自己回帰比、最大4倍（Googleの主張）を狙い、H100で毎秒1,000トークン超、RTX 5090で毎秒700トークン超が公式に示された。そして現状の制約として、品質は同規模のGemma 4に主要ベンチの多くで劣り、メモリ目安の約18GB（量子化時のVRAM）はVRAM 16GBのGPUには収まらず、標準のllama.cpp/Ollamaは未対応です（llama.cppは実験ブランチのみ）。

最初に拡散方式とAR方式の違い、つまり「なぜ速いか」を押さえ、次にご自身のGPUが約18GB VRAM目安と対応ランタイムを満たすかを確認する。この順で見ていくと、DiffusionGemmaを試すべき環境かどうかを自分で判断できます。今すぐ16GB級で動かすより、対応ランタイムの拡充を待つ選択も十分に合理的。新方式の現在地を正しく見極めて、次の一手を選んでください。

よくある質問

Q. DiffusionGemmaはRTX 5080（16GB）で動きますか？

RTX 5080の16GB VRAMだけに、公式が示す約18GBの量子化構成を完全に載せることはできません。実験的なGGUFやCPUオフロードで技術的に動かせる可能性はありますが、標準構成ではなく、公式の速度も期待できません。標準のllama.cpp/Ollamaは未対応で、当サイトでもRTX 5080での動作確認はしていません。実行時の余裕も含めると、24GB級以上のGPU（RTX 4090・RTX 5090など）が現実的です。

Q. なぜ拡散方式だと速くなるのですか？

自己回帰LLMはトークンごとにパラメータをメモリから読み出すため、メモリ帯域がボトルネックになります。拡散方式はブロック単位で複数トークンを並列に精製し、余っていたGPUの演算力を使い切る演算ボトルネックへ寄せ替えるため、低並列のローカル環境で速度が出やすくなります。

Q. Gemma 4とどちらの品質が上ですか？

主要ベンチマークの多くではGemma 4が上です。同じ26B-A4B構成で比較すると、MMLU Pro・GPQA Diamond・LiveCodeBench v6のいずれもDiffusionGemmaが下回りました（HLE no toolsのように上回る項目もあります）。DiffusionGemmaが狙うのは品質ではなく速度で、両者は速度と品質のトレードオフの関係にあります。

Q. Ollamaで使えますか？

現時点では標準のOllamaでは使えません。公式が対応窓口として挙げているのはHugging Face Transformers（Diffusers版も）・vLLM・MLX・SGLang。標準のllama.cppはmainline統合が未完了（PRはDraft段階）で、それに依存する標準のOllamaも今すぐには動かせません。ただしllama.cppの実験的なPRブランチと専用CLI（llama-diffusion-cli）ではGGUFを実行できます。対応状況は公式の更新を確認してください。