DiffusionGemmaとは｜4倍速い拡散型LLMの仕組み・スペックとローカルでの動かし方

DiffusionGemmaは、Google DeepMindが2026年6月10日にApache 2.0ライセンスで公開した実験的なオープンモデルです。GPTやGeminiのように文章を1トークンずつ左から右へ生成するのではなく、画像生成で実績のある拡散（ディフュージョン）方式をテキストに応用し、専用GPU上で最大4倍の生成速度を狙います。この記事では、自己回帰型との違いと高速化の仕組み、25.2B（活性3.8B）のMoE構成といったスペック、標準Gemma 4とのベンチマーク差、そしてvLLM・MLX・LM Studio・llama.cppでローカル実行する具体的な手順までを、公式モデルカードとGoogle開発者ブログの一次情報に基づいて整理します。

まとめ：DiffusionGemmaの要点

• 正体：Google DeepMindの実験的オープンモデル（Apache 2.0）。テキスト拡散方式で256トークンのブロックを並列生成し、H100で毎秒1000トークン超・RTX 5090で700トークン超を出す。
• 速さの源：1フォワードパスで15〜20トークンを確定させる並列化（H100はFP8低バッチ時に毎秒1100トークン超）。推論のボトルネックをメモリ帯域から計算性能へ移す設計で「最大4倍」を実現する。
• スペック：総25.2B・推論時の活性は3.8BのMoE（Gemma 4の26B-A4Bベース）。NVFP4量子化で約18GB VRAM、コンテキスト最大256K、35言語超対応・画像/動画入力可。
• 品質：MMLU ProやGPQAなどほぼ全ベンチで標準Gemma 4を下回る。Googleも「最高品質が要る用途はGemma 4を推奨」と明言する速度特化モデル。
• 動かし方：vLLM・Transformers・MLX・SGLangが公開初日から対応。LM Studioは現状非対応、llama.cppは専用のllama-diffusion-cliとGGUFが必要。

DiffusionGemmaの基本概要と自己回帰型LLMとの違い

まずこのモデルの位置付けと、既存のLLMと何が根本的に異なるのかを押さえます。生成方式の違いを理解すると、後述する速度と品質のトレードオフが腑に落ちます。

Google DeepMindが2026年6月に公開した実験的オープンモデル

DiffusionGemmaは、Gemmaシリーズに拡散型という新しい選択肢を加えたオープンウェイトモデルです。Googleはこれを本番の最高品質を狙う製品ではなく「research model（研究向けの実験的モデル）」と明確に位置付け、速度が重要な対話的ワークフローを探索する研究者・開発者に向けています。重みはHugging Face・Kaggle・Google CloudのVertex AI Model Gardenで配布され、誰でもダウンロードして手元の拡散型言語モデルを検証できます。

1トークンずつの自己回帰型と256トークン並列生成の違い

GPT・Gemini・Claudeといった主流LLMは自己回帰方式で、文章を左から右へ1トークンずつ予測します。確実な反面、出力が長くなるほど待ち時間も比例して増えます。DiffusionGemmaは256トークン分のブロックをまとめて生成し、複数回のパスで段階的に精緻化する並列方式を採ります。Googleはこの違いを「タイプライターから印刷機への移行」にたとえており、最初はランダムに見えるトークン群が処理を繰り返すうちに意味の通る文章へ収束します。逐次処理からブロック単位の同時処理へ発想を転換した点が、最大4倍という速度向上の起点です。

主要LLMとの生成アーキテクチャ比較

両者は優劣ではなく、得意分野の異なる補完関係にあります。生成アーキテクチャの観点で対比すると使い分けの軸が見えます。

拡散型テキスト生成に取り組む事例はGoogle以外にもあり、Inception LabsのMercuryが商用の代表例です。自己回帰型が主流である事実は変わりませんが、大手がオープンモデルとして拡散型を配布した意味は小さくありません。

最大4倍の速度を生む拡散生成の仕組み

「最大4倍」はどう実現されるのか。処理工程を段階ごとに分解し、高速化の原理と副次的な利点まで掘り下げます。

ランダムなキャンバスから出力を確定する3段階の生成工程

生成プロセスは概念的に3段階で進みます。画像生成の拡散モデルがノイズから絵を浮かび上がらせるのと同じ発想です。

1. ランダムなプレースホルダートークンで埋めた「キャンバス」を用意する
2. キャンバス全体に複数回のパスを実行し、確信度の高いトークンから順に確定させ、それを文脈として周囲の解決に使う
3. 処理を繰り返してテキスト全体が最終出力へ収束する

要点は、確定済みトークンが次パスの手がかりになる連鎖です。前のトークンの完成を待たないため、待ち時間の構造そのものが自己回帰型と変わります。公式モデルカードはこの中核を「ブロック自己回帰型のマルチキャンバスサンプリング」と説明し、エンコーダーがプロンプトを処理してKVキャッシュを作り、デコーダーがキャンバス全体に双方向アテンションを適用します。キャンバス内は並列・キャンバス間は逐次という二層構造で長文を組み立てます。

1フォワードパスで15〜20トークンを確定する並列化の効果

公式モデルカードには、DiffusionGemmaが1回のフォワードパスで15〜20トークンを確定させると明記されています。自己回帰型が1パスで1トークンしか出せないのと比べると、1パスあたりの確定量が桁違いです。この積み重ねが、低バッチ・FP8条件のH100で毎秒1100トークン超という速度につながります。ただし1パスあたりの計算量自体は増えるため、パス数比がそのまま速度比になるわけではありません。それでも実測で最大4倍の差が出るのは、GPUの並列計算能力を遊ばせず使い切る構造だからです。

ボトルネックをメモリ帯域から計算性能へ移す設計原理

自己回帰型のデコードは、1トークンごとにモデルの重みをメモリから読み出す必要があり、律速になるのは計算能力ではなくメモリ帯域幅です。演算性能がデータ読み出し待ちで遊んでしまいます。DiffusionGemmaは256トークンをまとめて処理するため、1回の重み読み出しに対する計算量が大幅に増え、ボトルネックが計算性能側へ移ります。GPUの進化は演算性能の伸びが特に大きいため、計算律速のアーキテクチャは新しいGPU世代の恩恵を受けやすく、将来さらに速度差が開く余地があります。

双方向アテンションがもたらす編集・穴埋めの強み

256トークンを同時に処理する構造上、生成中の全トークンが互いを参照できる双方向アテンションが成立します。自己回帰型は各トークンが自分より前の文脈しか見られませんが、拡散型は「これから書かれる後ろの内容」も踏まえて各位置の語を決められます。これはコードの穴埋め補完のように未来側の文脈が答えを制約するタスクで有利に働きます。Googleは数式のグラフ構造やアミノ酸配列のような非線形データ、構造化された編集、生成中のMarkdown自己整形にも利点があると説明しており、単なる高速化にとどまらない質的な違いを持ち込んでいます。

主要スペックと動作要件（25.2B MoE・256K・18GB VRAM）

導入判断の前提になる数字を項目ごとに確認します。いずれも公式モデルカードの記載に基づきます。

総25.2B・推論時は3.8Bのみ活性化するMoE構造

「26Bクラス」と呼ばれますが、モデルカードの正確な総パラメータは25.2Bです。Mixture of Experts（MoE）構造のため推論時に活性化するのは3.8B（38億）にとどまり、モデル全体の知識量と実際の計算コストを切り離せます。この構造はベースのGemma 4「26B-A4B」から受け継いだもので、全128エキスパートのうち8つと共有エキスパート1つを活性化させる疎な設計です。A4Bという名称はアクティブパラメータが約4B規模であることを示します。拡散方式は1パスあたりの計算量が増える方式なので、推論コストを抑えるMoEとの組み合わせは速度特化モデルとして理にかなっています。Gemma 4の詳細はGemma 4のモデル一覧と必要スペックで確認できます。

H100で毎秒1000トークン超・RTX 5090で700トークン超の実測速度

公表されている生成速度は、データセンター向けとコンシューマー向けの両方で具体値が示されています。

コンシューマー向けのRTX 5090でも毎秒700トークン超に達する点が特徴で、クラウドの大規模インフラに頼らず手元のワークステーションでこの速度を体験できます。ただし「最大4倍」はハードウェアやタスクの条件で変動する上限であり、すべての環境で一律4倍になるわけではありません。

量子化で18GB VRAMに収まる設計とコンテキスト・多言語対応

DiffusionGemmaはNVFP4形式に量子化した状態で約18GBのVRAMに収まる設計とされ、RTX 5090や4090クラスのハイエンドコンシューマーGPUなら単体で動かせます。ただし18GBはモデル本体の数字で、実運用ではコンテキスト長に応じたメモリが別途必要になるため、長い入力を扱う場合は24GBクラスでも余裕が想定より減る点に注意してください。コンテキストは最大256Kトークンで、標準で35言語超に対応（事前学習データには140超の言語を含む）します。さらにテキストに加えて画像・動画の混在入力に対応し、動画はフレーム列として最大60秒まで処理できます。ただし出力はテキストのみで、画像や動画を生成する機能はありません。

Gemma 4との品質比較と速度・品質の使い分け

速度を得る代わりに何を諦めるのか。Google自身が公表しているトレードオフを直視し、標準Gemma 4との使い分けの基準を整理します。

ほぼ全ベンチマークでGemma 4 26B A4Bを下回る品質

公式モデルカードのベンチマークでは、DiffusionGemmaは同規模の標準モデルGemma 4 26B A4Bをほぼ全項目で下回ります。これはGoogleが公表のうえで認めている差であり、隠されたトレードオフではありません。

例外的に難問集のHLEでは上回りますが、全体傾向を覆すものではありません。これは拡散型アーキテクチャ固有の限界ではなく、あくまで「速度に焦点を当てた実験的モデル」としての設計判断の結果です。とはいえ実用判断としては、品質要件が明確なタスクへ安易に投入すれば期待外れになりやすいという事実は重く受け止める必要があります。

速度優先か品質優先かを判断する実務的な軸

Googleは公式に「最高品質を求めるアプリケーションには標準のGemma 4を推奨する」と明言しています。この指針を実務に引きつけると、判断軸は「出力をそのまま成果物にするか」です。顧客向けの文章生成や正確性が問われる要約など出力品質が直接価値になる用途はGemma 4、人間が手を入れる下書き・試行錯誤・リアルタイム編集のように応答速度が体験を左右する用途はDiffusionGemma、と役割分担させるのが現実的です。次の3点で検討すると迷いにくくなります。

• 出力の用途：人が手を入れる下書きなら速度優先、そのまま成果物になるなら品質優先
• 利用環境：ローカル・低並列・GPU専有なら拡散型、大規模クラウドのバッチ処理なら自己回帰型
• 体験要件：リアルタイムの対話性が価値の中心ならDiffusionGemma、応答待ちが許容されるバックグラウンド処理なら標準モデル

大規模クラウドのバッチ処理では自己回帰型が有利になる逆転

見落としやすいのが、大規模なクラウド展開では速度優位が逆転し得る点です。Google自身が、高QPSのクラウドサービングでは並列デコードの効果が薄れ、かえってサービングコストが高くなる場合があると注記しています。理由は推論効率の構造にあります。自己回帰型の弱点であるメモリ帯域のボトルネックは、多数のリクエストをまとめて処理するバッチングで緩和でき、1回の重み読み出しで複数ユーザーの計算を進められます。拡散型は単一リクエストの低遅延に強い反面、大規模バッチでの総スループットでは優位が薄れます。つまり「常に4倍速い」のではなく「単一アクセラレータ上の低〜中バッチで最大4倍速い」が正確な理解です。多数ユーザー向けサービスを速度の数字だけで移行判断すると、期待と逆の結果を招きかねません。

ローカルで動かす方法（vLLM・MLX・LM Studio・llama.cpp）

ここが導入で最もつまずきやすい部分です。DiffusionGemmaは拡散型ゆえに従来のローカルLLMランタイムと動作条件が異なり、「いつものツールで開けない」ことが起こります。入手からツール別の対応状況までを具体的に押さえます。

Hugging Faceからの入手とvLLMでの起動

重みはHugging Faceでgoogle/diffusiongemma-26B-A4B-itとして公開されており、Apache 2.0のオープンウェイトなのでアカウントがあればダウンロードできます。公開初日から対応する中で最も実績があるのがvLLMで、GSCでも「diffusiongemma vllm」が本記事の主要な流入クエリになっています。基本的な起動は次のとおりです。

pip install vllm
vllm serve google/diffusiongemma-26B-A4B-it \
  --max-model-len 262144

コンテキストは最大262144（256K）トークンです。まずは短いプロンプトで生成挙動とVRAM使用量を確認し、入力長を段階的に伸ばしていくと安全です。サーバー用途で高速サービングを組むならvLLM、標準的な検証はTransformersが扱いやすい選択になります。

Apple Silicon（Mac）はMLXかUnsloth Studioで動かす

GSCでは「diffusiongemma mac」「macos」といったクエリが継続的に発生しており、Macでの実行需要は明確です。Apple SiliconではMLXが公式対応しますが、拡散型に対応するのはmlx-vlm 0.6.3以降で、古いバージョンでは読み込めません。GPUを持たない開発者でもMacで動かせる点は朗報ですが、注意点があります。ユニファイドメモリ構成のApple Siliconは推論がメモリ帯域律速になりやすく、Gemma 4と比べた高速化の効果は専用GPUほど大きく出ない場合があると公式ブログが注記しています。Macで手軽に試すなら、macOS対応のUnsloth Studio（オープンソースのローカルAI用Web UI）も有力で、4bit精度なら18GB以上のメモリが目安です。

LM Studioでは現状動かない理由と代替手段

「diffusiongemma lm studio」は流入クエリの上位ですが、結論から言うと2026年6月時点でLM StudioはDiffusionGemmaを実行できません。LM Studioが同梱するランタイム側が拡散型アーキテクチャに未対応だからです。具体的には、Apple Silicon向けにLM Studioが同梱するmlx-vlmは0.4.5で、DiffusionGemmaに必要な0.6.3以降を満たしません。もう一方の同梱ランタイムである標準のllama.cppも、後述のとおり拡散型の生成に対応していません。LM Studioは現状カスタムのllama.cppバイナリへの差し替えもできないため、GGUFを入れても生成まで至らないのが実情です。LM Studioで使い慣れている場合の代替は、(1)MLX（mlx-vlm 0.6.3以降）を直接使う、(2)Unsloth Studioを使う、(3)vLLMで立てる、の3択になります。同じくローカルUIでGemma 4を動かしたい場合の設定はLM StudioでのGemma 4の動かし方が参考になります。

llama.cppは専用のllama-diffusion-cliとGGUFが必要

「diffusiongemma llama.cpp」も一定の需要がありますが、標準のllama-cliやllama-serverではDiffusionGemmaを生成できません。拡散型の生成ループが自己回帰型と根本的に異なるため、専用のllama-diffusion-cliランナーが要ります。現状はDiffusionGemma対応のプルリクエスト（ggml-org/llama.cpp のPR）からビルドし、Unslothが配布するunsloth/diffusiongemma-26B-A4B-it-GGUFを組み合わせて動かす形です。公式のllama.cpp本体への統合は近日提供予定とアナウンスされており、これが実現すればVRAMの少ないマシンでも試せるユーザー層が広がります。導入時期を検討する際は、公式発表だけでなく利用予定ツールのリリースノートやコミュニティの動作報告も確認しておくと確実です。

対応ツールと最適化済みGPU環境の一覧

公開初日から複数の主要フレームワークに対応しています。推論用と学習用で対応の性格が異なる点に注意してください。

GPU最適化はNVIDIAと協力して実施され、コンシューマー向けはRTX 5090/4090、エンタープライズ向けはHopper・Blackwell世代でNVFP4カーネルによる最適化が施されています。NVFP4は4ビット浮動小数点の低精度演算で計算スループットを高める技術で、計算律速の拡散型と相性が良い組み合わせです。DGX SparkやDGX Station、RTX PROも対応環境に含まれます。クラウドではVertex AI Model GardenやNVIDIA NIM経由でも利用できます。GPU選定の目安は、個人検証ならRTX 4090以上、チームでの本格検証や低遅延サービスならHopper世代以降のデータセンターGPUです。

実務での適用場面（インライン編集・コード補完）

速度と双方向アテンションという2つの強みが、どの作業で実利になるのか。Googleが想定するユースケースを軸に見ていきます。

双方向アテンションを生かしたインライン編集

Googleが筆頭に挙げるのがインライン編集です。文章の途中を書き換える、段落の間に文を挿入するといった作業では、対象箇所の「前」と「後ろ」の両方の文脈を踏まえる必要があります。左から右へしか文脈を見られない自己回帰型に対し、全トークンが相互参照できるDiffusionGemmaは構造的に相性が良い領域です。エディタで文章を選択し「ここをもっと簡潔に」と指示した瞬間に候補が返るような体験は、毎秒700トークン超のローカル速度があれば待ち時間のストレスがほぼ消えます。品質面で標準モデルに譲っても、人間が最終判断する編集用途なら弱点は実用上の問題になりにくい領域です。

前後の文脈を同時参照できるコード補完・コードインフィル

コードの穴埋め補完（コードインフィル）も有力です。関数の前半と後半が確定した状態で中間のロジックを埋める状況では、未来側の文脈が答えを強く制約するため、双方向アテンションの利点が最も直接的に現れます。補完候補の表示に数秒かかるツールは賢くても使われなくなりがちで、ローカルGPUで毎秒数百トークンを出せる速度は開発体験に直結します。ソースコードを外部クラウドへ送らずに済む点も、機密性の高いコードベースを扱う企業には見逃せない利点です。速度・双方向の文脈参照・ローカル完結の3要素が揃う、相性の良い応用分野といえます。

ローカル低遅延アプリ・エッジ用途と非線形データへの応用

AIアシスタントの実行環境がクラウドからラップトップ・エッジへ広がる中で、限られたハードウェアで高速に動くモデルの価値は高まっています。ネットワークが不安定でも動くオフラインの執筆支援、応答遅延が許されない接客端末、社外秘データでクラウド送信できない社内アプリなどが具体的な方向性です。加えてGoogleは、数式のグラフ構造やアミノ酸配列のように「左から右へ読む」前提が成り立たない非線形データへの応用にも言及しています。公式ブログでは、各マスが互いを制約し合うため自己回帰型が苦手とする数独を、Unslothがファインチューニングして解かせたデモが紹介されました。ただし専門分野への応用の多くは現時点では可能性の提示であり、有効性は各分野の検証を待つ段階です。

商用利用とApache 2.0ライセンス・導入前チェック

技術的に魅力的でも、利用条件と運用リスクを把握しないままの導入は禁物です。業務利用で避けて通れない論点を整理します。

改変・再配布・商用利用を認めるApache 2.0の条件

DiffusionGemmaはApache 2.0ライセンスで公開され、商用利用・改変・再配布・私的利用のいずれも認められています。従来のGemmaシリーズの一部がGemma独自規約で提供されてきたのに対し、条件が広く知られた定番ライセンスを採ったことは企業利用のハードルを下げ、法務確認も進めやすくなります。一方で寛容なライセンスにも義務はあり、再配布時にはライセンス文書の同梱、著作権表示の保持、改変時の変更点の明示が求められます。NOTICEファイルがあれば内容の引き継ぎも必要です。Apache 2.0には特許ライセンス条項も含まれ、特許訴訟を起こすとライセンスが終了する規定もあるため、法務確認では全文を確認しておくと安心です。

実験的モデルを本番投入する前のチェック項目

ライセンス上は商用可でも、Googleが一貫して「実験的・研究向け」と説明し品質もGemma 4を下回ることを踏まえると、本番適性は利用者自身が検証して判断すべき領域です。速度4倍のインパクトだけで導入が先行しないよう、次の項目を確認してから進めてください。

• 出力品質の実測：自社の実タスクでGemma 4など標準モデルと品質を比較したか
• 速度効果の確認：自社の利用環境（同時接続数・GPU構成）で速度優位が実際に出るか
• 誤出力の影響範囲：出力がそのまま顧客や意思決定に届く構成になっていないか
• 検証体制：人間のレビュー工程と、問題発生時の切り戻し手順が定義されているか
• ライセンス対応：表記義務や社内ポリシーとの整合を法務と確認したか

特定モデルへの依存度を下げるため、モデル差し替えを前提にした抽象化層を用意しておくと、実験的モデルの仕様変更や後継移行にも耐えやすくなります。限定した工程で実測しながら適用範囲を広げ、切り戻し手順と運用知識を複数人で共有しておくことが、オープンモデル運用の成否を分けます。

よくある質問

DiffusionGemmaはLM Studioで動きますか？

2026年6月時点では動きません。LM Studioが同梱するランタイムが拡散型に未対応で、Apple Silicon向けのmlx-vlmは0.4.5（必要なのは0.6.3以降）、標準のllama.cppも拡散型の生成に対応していないためです。代替として、MLX（0.6.3以降）を直接使う、Unsloth Studioを使う、vLLMで立てる、のいずれかを選んでください。

MacやApple Siliconで動かせますか？

動かせます。MLX（mlx-vlm 0.6.3以降）またはmacOS対応のUnsloth Studioを使います。4bit精度なら18GB以上のメモリが目安です。ただしユニファイドメモリはメモリ帯域律速になりやすく、Gemma 4と比べた高速化の効果は専用GPUほど大きくは出ない場合があります。

必要なVRAM（メモリ）はどれくらいですか？

NVFP4量子化で約18GBが目安で、RTX 5090/4090クラスなら単体で動きます。ただしこれはモデル本体の数字で、コンテキスト長に応じたメモリが別途必要です。長い入力を扱うなら24GBクラスでも余裕を見ておくと安全です。

llama.cppやOllamaで使えますか？

標準のllama-cli/llama-serverでは生成できません。拡散型専用のllama-diffusion-cli（DiffusionGemma対応PRからビルド）とUnsloth配布のGGUFを組み合わせる必要があります。公式のllama.cpp本体への統合は近日提供予定です。

DiffusionGemmaとGemma 4はどちらを使うべきですか？

最高品質が要る用途（顧客向け生成・正確な要約など）は標準Gemma 4、速度が体験を左右する用途（下書き・リアルタイム編集・コード補完）でローカル低並列ならDiffusionGemma、という使い分けです。Google自身も品質重視ならGemma 4を推奨しています。

商用利用できますか？

できます。Apache 2.0ライセンスで商用利用・改変・再配布が認められています。ただし実験的モデルのため、本番投入前に自社タスクでの品質検証と、再配布時のライセンス表記義務の確認を行ってください。

関連記事

• Gemma 4とは｜モデル一覧・必要スペック(VRAM)・量子化(GGUF/AWQ)・ローカル実行を解説【2026年版】
• Gemma 4 12Bのリリースで変わるローカルAI開発の前提条件
• LM StudioのMCP設定とGemma 4の動かし方｜OAuth・MTP高速化・Web検索