DiffusionGemma入門｜4倍速テキスト生成の使い方・料金2026

LLMの生成速度に不満を感じたことがあるなら、DiffusionGemmaの数字は無視できない。H100単体で毎秒1,000トークン超。従来の自己回帰モデルと比べて約4倍速い。

2026年6月10日、Google DeepMindがApache 2.0で公開した。画像生成AIで使われる「拡散（diffusion）」をテキスト生成に持ち込んだモデルで、GPTやClaudeが1トークンずつ順番に出力するのに対し、256トークンのブロックを一気に並列生成する。仕組みそのものが違う。

ただし万能ではない。MMLUやMATHといった精度ベンチマークでは同サイズのGemma 4に対して5〜19ポイントの差がつく。Googleも「実験的リリース」と位置づけており、精度最優先の本番用途にはGemma 4を推奨している。速度と精度のトレードオフをどう判断するか——この記事では、仕組みから料金、導入手順、向き不向きまでを一通り整理した。

DiffusionGemmaとは何か

Google DeepMindが開発したオープンウェイトのテキスト拡散言語モデルだ。Gemma 4 26B-A4BのMixture-of-Experts（MoE）アーキテクチャをベースに、推論時の生成方式を自己回帰から拡散に切り替えている。公式のmodel cardを読んだとき、「アーキテクチャはGemma 4と同じなのに推論パスだけ差し替えた」という設計割り切りに驚いた。

基本スペック一覧

26Bの総パラメータのうち、推論時にアクティブになるのは3.8Bだけ。MoE（Mixture-of-Experts）という仕組みで、入力に応じて最適なエキスパートだけを起動する。結果として、26Bクラスの知識量を持ちながら、計算コストは4Bモデル並みに抑えられる。

何が「初」なのか

テキスト拡散モデル自体は研究段階で複数存在していたが、DiffusionGemmaには3つの「初」がある。

オープンソースLLMを自前で動かしている開発者にとって、「vLLMでそのまま使える」という点が実務上の最大の意味を持つ。新しいサーバーやランタイムを別途用意する必要がない。

テキスト拡散の仕組み — 自己回帰との根本的な違い

GPT、Claude、Geminiといった主要LLMはすべて自己回帰（Autoregressive）方式で動く。「前のトークンを見て、次の1トークンを予測する」を繰り返す仕組みだ。文章が100トークンなら、100回の逐次処理が必要になる。

このモデルはそこを根本から変えた。画像生成AIのStable Diffusionと同じ「拡散」の発想をテキストに応用している。

自己回帰 vs テキスト拡散の動作フロー

自己回帰は1品ずつ順番に出すコース料理だ。拡散はビュッフェの厨房——全品を同時に調理する。1品の完成度はコース料理のほうが高くなりやすいが、提供速度はビュッフェが圧倒する。

「離散テキスト拡散」の技術的なポイント

画像の拡散モデルは連続的なピクセル値を扱うが、テキストは離散的なトークンの列だ。この違いを吸収するために採用されたのが「離散拡散（discrete diffusion）」という手法だ。

具体的には、学習時に正解テキストのトークンをランダムにマスクトークンへ置き換える（ノイズを加える）。推論時にはその逆——マスクだらけの状態から元のテキストを復元する方向に動く。ステップごとにマスクが減り、最終的に完全なテキストが現れる。

ブロック自己回帰との組み合わせ

正式な分類名は「ブロック自己回帰 × マルチキャンバスサンプリング」。256トークンのブロック単位では拡散で並列生成し、ブロック間は自己回帰的に前のブロックを参照する。純粋な拡散でもなく純粋な自己回帰でもない、ハイブリッド方式だ。

このハイブリッドにした理由は明快で、長文の論理的一貫性を保つためだ。ブロック内は速度を優先して並列化し、ブロック間は前の文脈を受け継いで矛盾を防ぐ。

ベンチマーク結果と速度比較

「4倍速い」という数字だけが先行しがちだが、精度面ではGemma 4に対して明確なギャップがある。速度と精度の両面を数値で確認しておく。

精度ベンチマーク: Gemma 4との比較

数字を見ると、差の質が違う。MMLU Proで5ポイント差は「明確に劣るが壊滅的ではない」レベル。日常的なテキスト生成——要約、分類、翻訳、チャット——で体感差が出にくい範囲だ。

一方、AIME 2026（数学オリンピック級の推論問題）で19ポイント。これは正直まずい数字だ。多段推論を必要とするタスクでは、拡散方式の弱点が顕著に出る。ブロック内のトークンが互いの依存関係を十分に反映しきれないのが原因と考えられる。

速度ベンチマーク: GPU別の実測値

料金とコスト構造

オープンウェイトモデルなので、モデル自体のライセンス料はゼロ。コストはGPUの計算資源だけだ。セルフホストとクラウドAPIの両方でコストを調べてみた。

セルフホスト時のコスト目安

同サイズの自己回帰モデルと比べて、トークン単価が3〜4分の1になる計算だ。生成速度が速い分、GPU時間あたりの処理量が増え、結果として単価が下がる。

主要APIプロバイダーの料金

セルフホストが面倒なら、Google Cloud・NVIDIA NIM・OpenRouterの3択になる。

導入手順 — vLLM・Transformers・クラウド別

リリース初日からvLLMにネイティブ対応している。筆者の環境でも、既にvLLMでローカルLLMを動かしていたサーバーでモデル名を差し替えるだけで動いた。セットアップのハードルは拍子抜けするほど低い。

方法1: vLLMで動かす（推奨）

もっとも安定している公式推奨パス。OpenAI互換APIが立つので、既存のクライアントコードをそのまま使える。

# vLLMのインストール（0.9.0以上が必要）
pip install vllm>=0.9.0

# FP8量子化チェックポイントでサーバー起動
vllm serve RedHatAI/diffusiongemma-26B-A4B-it-FP8-dynamic \
  --dtype auto \
  --max-model-len 8192 \
  --port 8000

# 別ターミナルからcurlで動作確認
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "RedHatAI/diffusiongemma-26B-A4B-it-FP8-dynamic",
    "messages": [{"role": "user", "content": "DiffusionGemmaの特徴を3行で"}],
    "max_tokens": 256
  }'

公式のデプロイレシピはrecipes.vllm.aiに掲載されている。サーバーフラグが更新される可能性があるため、本番デプロイ時はレシピ側を参照すること。

方法2: HuggingFace Transformersで動かす

手元で素早く試したいならTransformersが手軽。ただしvLLMほどの速度最適化はされていない。

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_id = "google/diffusiongemma-26b-a4b-it"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.bfloat16,
    device_map="auto"
)

inputs = tokenizer("DiffusionGemmaの仕組みを説明してください", return_tensors="pt").to("cuda")
outputs = model.generate(**inputs, max_new_tokens=512)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

方法3: Google Cloud Model Gardenからデプロイ

GCPコンソールからワンクリックでVertex AIにデプロイできる。GPU選択やスケーリングの設定もGUI上で完結する。

# gcloud CLIでのデプロイ例
gcloud ai endpoints create \
  --region=us-central1 \
  --display-name=diffusiongemma-endpoint

gcloud ai models upload \
  --region=us-central1 \
  --display-name=diffusiongemma \
  --container-image-uri=us-docker.pkg.dev/vertex-ai/prediction/vllm-gpu:latest \
  --artifact-uri=gs://vertex-model-garden-public-us/diffusiongemma

GCPに慣れていないなら、HuggingFaceのInference Endpointsを使うほうが設定が少なくて済む。

必要スペックとGPU選び

26B MoEモデルとはいえ、量子化チェックポイントを使えば消費者向けGPUでも動く。ただしVRAMの下限は明確にある。

VRAM要件の早見表

推奨構成パターン

Macユーザーには朗報がある。MLXにも対応しているため、Apple SiliconのMacで走る。M4 Proの36GB統合メモリならFP8チェックポイントが載る。ただし速度はNVIDIA H100比で1/4〜1/5程度に落ちるため、あくまで動作確認用と割り切ったほうがいい。

本番で投入する前に、何が得意で何が苦手かを整理しておきたい。

向いている用途・向かない用途

実際にいくつかのタスクで検証してみると、「何に使うか」で評価が真っ二つに分かれるモデルだと感じた。要約タスクでは体感で差を感じないのに、数学問題を解かせると途端にボロが出る。万能型ではなく、明確に得意・不得意がある。

向いている用途

向かない用途

自分なら、社内の文書要約パイプラインやFAQ自動応答に真っ先に投入する。精度5ポイントの差は気にならないが、処理速度4倍は月次のGPUコストに直結するからだ。

Gemma 4・Llama 4との比較

同じオープンウェイトの26B〜27Bクラスで、このモデルがどこに位置するかを3モデル並べて整理する。

精度だけを見ればGemma 4が上。速度だけを見れば拡散モデルが圧勝。Llama 4はアクティブパラメータが多い分VRAMに余裕が必要だが、エコシステムの厚みがある。

自分なら「同じ予算でより多くのテキストを処理したい」場面で拡散モデルを選ぶ。精度最優先ならGemma 4一択。既存のLlamaエコシステムに乗りたいならLlama 4。目的から逆算して選ぶのが正解で、「どれが一番優れているか」という問い自体に意味がない。

クローズドモデルとの位置づけ

GPT-5.5やClaude Opus 4.8といったクローズドモデルとは直接競合しない。それらは精度で数段上だが、APIコストも数倍かかる。このモデルの競合相手はあくまで「セルフホスト可能なオープンウェイトモデル群」であり、土俵が違う。主要AIサービスの全体比較で全体の位置づけを確認できる。

よくある質問

まとめ

結論から言う。バッチ処理のコスト削減やチャットの応答高速化が目的なら、今すぐ検証に値するモデルだ。

H100で毎秒1,000トークン超、トークン単価は自己回帰モデルの3〜4分の1。Apache 2.0で商用利用に制約なし。vLLMでそのまま動く。導入のハードルは低い。

一方で、MMLU Proで5ポイント、AIME 2026で19ポイントの精度差は無視できない。推論チェーンが必要なタスクにはまだ使えない。Googleが「実験的」と明言している通り、使える場面を選ぶ段階だ。

テキスト拡散という技術そのものはまだ黎明期にある。今後の精度改善次第で自己回帰モデルの牙城を崩す可能性があるのは間違いない。ただ今は、使える場所を絞って使う——それが現実的な判断だ。

pip install vllm>=0.9.0
vllm serve RedHatAI/diffusiongemma-26B-A4B-it-FP8-dynamic --port 8000

オープンソースLLMの動向に興味があるなら、同じくMoEアーキテクチャを採用したGemma 4入門や、NVIDIAの最新オープンモデルNemotron 3 Ultraもチェックしておくと全体像がつかめる。Qwen3 Coder Nextはコーディング特化のオープンモデルとして別の選択肢になる。

AI業界の最新動向をまとめて把握したい場合は、プロンプトエンジニアリング入門でLLMの効果的な使い方を学ぶのもおすすめだ。AIエンジニア転職ガイドでは、こうした最新技術のキャッチアップがキャリアにどう活きるかを解説している。