VRAM 12GBで動かせる？話題の「DiffusionGemma」をローカルで検証してみた〜通常Gemma 4との徹底比較〜
こんにちは、かみもとです！
ついにGoogleから「DiffusionGemma」という非常に興味深いモデルがリリースされましたね！
これまでの大規模言語モデル（LLM）は「1トークンずつ順番に次の単語を予測していく」という自己回帰（Autoregressive）モデルが主流でした。
しかし、今回のDiffusionGemmaは、画像生成AIなどでおなじみの「ディフュージョン（ノイズ除去）プロセス」を用いて、テキストのキャンバス全体を一気に生成するという画期的なアーキテクチャを採用しています。
「キャンバス全体を並列で生成できるなら、ローカル環境でも爆速でテキストが出てくるのでは？」
実際その通りで、RTX5090（VRAM 32GB）だと爆速で表示されるようです！ただ、そんな馬鹿高いGPUは持ってない‥。
そこで今回は、うちのローカルAI検証環境（VRAM 12GBのGPU！）を用いて、最新の通常モデル「Gemma 4」と「DiffusionGemma」を実際に動かし、生成速度や品質、そしてローカル環境ならではのハードウェアの壁について徹底的に検証・考察してみました。
1. 従来の「自己回帰」と新しい「Diffusion」の違い
本題の検証結果に入る前に、そもそも「通常Gemma 4」と「DiffusionGemma」は何が違うのか、アーキテクチャの根幹部分を簡単におさらいしておきましょう。
通常のGemma 4（自己回帰モデル）
ChatGPTやClaudeなど、現在主流のほとんどのLLMがこの方式を採用しています。
「むかしむかし、あるところに」と入力されたら、次に続く確率が最も高い「おじいさん」という1単語（トークン）を予測し、次は「むかしむかし、あるところにおじいさん」という文脈から「と」を予測する……というように、前の出力結果に依存して順番にテキストを生成していきます。
確実で文脈の一貫性を保ちやすい反面、「前の単語が生成されないと次の単語を作れない」という計算の直列性がスピードのボトルネックになります。
DiffusionGemma（ディフュージョンモデル）
一方のDiffusionGemmaは、画像生成AIのStable Diffusionなどのように、最初は「完全にランダムなノイズ（デタラメなテキストの塊）」からスタートします。
例えば256トークン分のキャンバス（枠）を用意し、モデル全体がそのキャンバス全体を俯瞰して一気に「少し意味のあるテキスト」へとノイズを除去（デノイズ）します。このステップを複数回繰り返すことで、最終的に綺麗で意味の通った文章を完成させるのです。
最大のメリットは「256トークンを並列に計算できる」こと。理論上は、GPUの並列計算能力を極限まで活かすことができるロマンあふれる仕組みです。面白いですよね！
2. 実行環境のセットアップ
理論上は爆速並列処理ができそうなDiffusionGemmaですが、実際のローカルマシンではどうなるでしょうか。今回の検証に用いたPCのスペックとソフトウェア構成は以下の通りです。
GPU 0: NVIDIA GeForce RTX 4070 (VRAM 12GB)
GPU 1: NVIDIA GeForce RTX 3060 (VRAM 12GB)
RAM: 48GB（計測前空き容量 約42GB）
バックエンド: llama.cpp（Draft PR #24423版、commit `53752ade13c86ef487da2480b1c2b1aace375693`）
＊2026/6/12現在、LM Studioやollamaでは動かせないため、llama.cppを使用。さらにドラフト版プルリクじゃないと動かせません。vllmというのでも動かせるようです。
使用したモデルは以下の2つです。どちらも26B（260億）パラメータのMoE（Mixture of Experts）モデルであり、今回は扱いやすい4bit量子化（Q4）フォーマットを採用しました。
DiffusionGemma: `diffusiongemma-26B-A4B-it-Q4_K_M.gguf` (ファイルサイズ約15.6GB)
通常Gemma 4: `gemma-4-26B-A4B-it-qat-q4_0-gguf` (ファイルサイズ約14.4GB)
ここで感の鋭い方ならお気づきかもしれませんが、今回の環境の最大の弱点は「GPU1枚あたりのVRAMが12GBしかない」ということです。15.6GBのモデルを動かすには、どうしてもVRAMが足りません・・。この「VRAMの壁」が、後のベンチマーク結果に大きな影響を与えることになります。
3. 実測：DiffusionGemma vs 通常Gemma 4
準備が整ったところで、さっそくベンチマークを実行してみましょう！
今回は比較をシンプルにするため、「84 * 3 / 2」という簡単な算数の計算問題を英語で解答させるプロンプトを実行し、出力キャンバスまたは最大出力を「256トークン」に揃えて速度とメモリ使用量を計測しました。
結果はこちらです。
なんと、「うちの環境だと通常のGemma 4の方が圧倒的に速い（約4倍）」という結果が出ました！「並列生成できるDiffusionの方が速いんじゃないの？」という淡い期待は見事に打ち砕かれました・・・。
通常Gemmaの実行結果です。下の方に「88.1トークン/sec」というのが速度ですね。84 * 3 / 2は？と聞いて、Start thinkingして考えている様子が分かります。答え「126」もあっていますね。
今度はDiffusionGemmaの実行結果です。ログが違いますね。9 steps over 1 blocksとか、256-tok canvas x 9.0 steps/blockなど、diffusionモデルならではの出力が出ています。256トークンを12秒ほどで出力しているので、21.3トークン/secということですね。遅い・・・。
とはいえ、ここで単に「Diffusionは遅い」と切り捨てるのは勿体無い。実行時の生ログを見ていくと、なぜ速度差が生まれたのか、技術的な理由が浮かび上がってきました。
4. なぜ速度にこれほど差が出たのか？
ログ解析と追加検証の結果、この速度差はモデルの根本的な劣等性ではなく、「アーキテクチャの特性」と「ローカルのハードウェア・ソフトウェア制約」という2つの要因が推測されます。
理由①：ステップ数の壁（192 tok/s と反復）
生ログを見ると、DiffusionGemmaの1ステップあたりの処理速度（In-step parallel throughput）は、192 tok/s に達しています。これは通常Gemma 4の88.1 tok/sをダブルスコアで上回る、凄まじい並列処理能力です。
しかし、前述の通りDiffusionモデルは「1回の処理でテキストを完成させることができない」という特性を持ちます。ノイズを徐々に取り除いていくため、この処理を何度も反復しなければなりません。
今回の「84 * 3 / 2」の推論では、モデルがテキストを最終的に確定させるまでに「9回のデノイズステップ」を要しました。そのため、192 tok/s という圧倒的な推論速度を持ちながらも、結果的にトータルの生成速度は 21.3 tok/s（256トークンを生成するのに約12秒）まで割り引かれてしまったのです。
画像生成でもstep数は決めますが、イメージあんな感じです。ステップ数を増やせばどんどん速度が遅くなる。精度とのトレードオフです。
理由②：単体GPUのVRAM容量の壁とCPU MoEの影響
「それなら1ステップの処理をもっと速くすればいいのでは？」と考えますが、ここで立ちはだかるのがVRAM 12GBの壁です。
DiffusionGemmaのファイルサイズは約15.6GB。RTX 4070のVRAM 12GBには到底収まりきりません。そのため、今回は `llama.cpp` の機能である `--cpu-moe`（MoE層の計算をCPUとメインRAMに逃がす機能）を使用せざるを得ませんでした。
GPU内で完結すれば高速に計算できますが、PCIeバスを通ってCPUとメインRAMを往復すると膨大なレイテンシ（遅延）が発生します。このCPUへのオフロードが原因で、1ステップの処理に約1.3〜1.4秒もかかってしまい、それが9ステップ繰り返されることで致命的なボトルネックを生んでいると推察されます。
理由③：マルチGPU（llama.cppの未対応とOOM）
「だったらRTX 4070と3060の2枚（合計24GB）を使って、全レイヤーをGPUにフルオフロードすればいいじゃないか」と誰もが考えるでしょう。私も実際に試しましたが、しかし、ここがローカルAIの最も辛いところでした。
現在の `llama.cpp` のDraft版では、DiffusionGemmaをマルチGPUで動かそうとした瞬間に、実装の都合上「KVキャッシュ（Prefix KV cache）」や「GPU上でのサンプリング処理（GPU sampling）」、「サンプルリダクション」といった重要な高速化機能がシステム側で強制的にオフになってしまいました。
これらの最適化が切れると、GPU間で大量のデータを毎ステップCPUを介してやり取りすることになり、実際に2GPUで動かした際の速度は 9.8 tok/s〜11.0 tok/s まで激減してしまいました・・・。
さらに追い打ちをかけるように、Diffusionモデルは自己回帰モデルとは異なり、256トークン分の巨大な「生成用キャンバス」を毎ステップ並列計算するためのCUDAプール（計算バッファ）を大量に要求します。そのため、モデルの重み（15.6GB）自体は24GBのVRAMに収まるはずなのに、追加の計算バッファを確保しようとした段階で「CUDA out of memory（OOM）」でクラッシュしてしまいました。
結果として、DiffusionGemmaは「RTX 4070（12GB）単体 ＋ はみ出た層をCPUで処理」という妥協案でしか動かせなかったのです。これがDiffusionモデルなのに遅くなってしまった原因と推測します。
一方、自己回帰型の通常Gemma 4はバッファ要求量が少なく、2枚のGPUに綺麗に収まりました。そのため、フルGPUの恩恵を100%享受でき、88.1 tok/sという安定した爆速を叩き出せたというわけです。
もちろん、llama.cppの最適化のおかげというのもありますから、Diffusionモデルについても今後最適化が進めば、VRAM 12GBのマルチGPUで高速化できる可能性もあります。
5. 生成品質と回答精度の評価
速度面では通常Gemma 4に軍配が上がりましたが、生成される文章の「品質」はどうでしょうか。Googleが公開している公式モデルカードのベンチマーク数値を比較してみましょう。これは公開情報で、私の環境で実験したわけではないです。
全体を通して、現時点では「通常のGemma 4 26B-A4Bの方が知能・精度ともに上回っている」のが実情です。特にAIMEなどの高度な数学推論や長文読解において、従来モデルの強さが際立っています。学習が足りないのか、まだDiffusionアーキテクチャがこなれていないのか。
また、実際にローカルで動かして気づいた点として、DiffusionGemmaは回答に至るまでの「思考プロセス（Thinking）」が非常に長く出力される傾向がありました。
今回の「84 * 3 / 2」という簡単な算数でも、256トークンのキャンバスでは思考の途中で文字数制限に引っかかってしまい、肝心の最終回答が途切れてしまうことが多々ありました。実利用を想定するならば、コンテキスト長を512トークン以上に長めに確保するか、システムプロンプトでThinkingを無効化するなどの工夫が必須になりそうです。
6. 設定変更で「無理やり」改善することはできない？
技術者たるもの、一度遅いと分かっても諦めきれないものです。「起動オプションをハックして、なんとかDiffusionの速度を改善できないか？」と思い、生ログとにらめっこしながら追加の検証を行いました。
妥協案として、起動オプションにある `Entropy Bound`（もうこれ以上ノイズ除去しなくていいよ、と判定する閾値）を意図的に緩めたり、最大ステップ数を強制的に制限（たとえば `--diffusion-eb-max-steps 4` のように、無理やり4回でストップさせる）することで、見かけ上の生成速度を上げることは可能です。計算回数が減るため、スループットは 40〜50 tok/s 前後まで向上します。
しかし、これは推論の途中で半ば強制的に処理を打ち切ることを意味します。画像生成で例えるなら「まだノイズが残っているざらざらの画像」を出力するようなものです。テキスト生成においてこれをやると、出力テキストの文法が完全に破綻したり、意味不明な単語の羅列が出力されるリスクが跳ね上がります。
実際にパラメータを調整してテストを繰り返しましたが、動的判定（Entropy Bound）の設定を緩めても、モデルが迷ってかえってステップ数が長引くケースもあり、品質と速度のバランスをコントロールするのは非常にシビアでした。
画像生成のように、4Step LoRAみたいなTurbo系の技術が出てくれば改善される可能性はあります。しかし、そもそも通常LLMであるGemmaより高速である触れ込みのDiffusionGemmaですから、そのような技術が出てくるのはまだ先だと思います。そもそもVRAM 12GBで動かすなよ、ということだとは思いますが・・・。VRAM 24GB以上であれば高速に動かせると思います。RTX5090だと700token/secくらい出るそうですし。
7. まとめ：VRAM 12GBの限界
長くなりましたが、今回の検証から導き出される結論は以下の通りです。
「現時点のローカル環境（VRAM 12GB〜24GBクラス）では、自己回帰型の通常Gemma 4の方が圧倒的に扱いやすく、速くて賢い」
DiffusionGemmaが持つ「1ステップで192 tok/s」という並列処理能力は確かに凄まじいポテンシャルを秘めています。しかし、ローカルでその真価を100%発揮するためには、以下のいずれかの条件が揃うのを待つ（あるいは環境を変える）必要がありそうです。
ツールの改良を待つ：`llama.cpp` の開発が進み、マルチGPU環境下でもDiffusionモデルの各種高速化機能やVRAM最適化がサポートされるようになるまで待つ。
ハードウェアを更新する：RTX 3090 や RTX 4090 のように、単体で VRAM 24GB を搭載したハイエンドGPUを使用し、巨大な計算バッファごとモデルをすべて単体GPUのVRAMに載せきる（＝CPUとの通信ボトルネックを完全に無くす）。
まだまだ発展途上の技術であり、現状は従来の自己回帰モデルに分がありますが、「完全にランダムなノイズの塊から、少しずつ意味のある文章が浮かび上がってくる」というテキスト生成のアプローチは、見ていて非常にロマンがあります。LLMのパラダイムシフトを予感させる面白いモデルであることは間違いありません。
今後のllama.cppのアップデートや、より軽量化されたモデルの登場に期待しつつ、引き続きローカルAI技術の限界と可能性を探っていきたいと思います！
参考：llama.cppでDiffusionGemmaを使う手順だけまとめておきました。
最後まで読んでいただき、ありがとうございました！
もしこの記事が「参考になった！」「開発のヒントになった！」「絵が可愛い！」と少しでも感じていただけたら、画面下の【スキ（ハートマーク）】を押していただけると、検証の苦労が吹き飛ぶほど励みになります！
今後も生成AIの技術検証をガシガシ公開していきますので、フォローもぜひよろしくお願いします！
いいなと思ったら応援しよう！
若輩者ですが、サポートいただけると、もっとがんばって記事作成します！