DiffusionGemma 26B-A4B 完全解説：自己回帰を捨てた Google の「ブロック並列」テキスト拡散が拓く Open-Weight Frontier 第 7 モデル

自己回帰の限界と、テキスト拡散への回帰

2026 年 6 月 10 日、Google DeepMind は DiffusionGemma を Apache 2.0 で公開した。Gemma 4 26B A4B の MoE バックボーンに、昨年 5 月の I/O で発表された Gemini Diffusion の研究成果を統合した「ブロック並列デコード」モデルである。

中心的な主張は明確だ。「H100 で 1000 tok/s 以上、GeForce RTX 5090 で 700 tok/s 以上」 をローカル推論で実現する。Google 公式の表現は次の通りである。

“Most language models act like a typewriter, generating one token at a time from left to right. In the cloud, this is efficient because servers can batch thousands of user requests together to share the hardware load. But when run locally for a single user, this word-by-word process leaves your dedicated GPU or TPU underutilized. DiffusionGemma reverses this inefficiency. Instead of predicting words sequentially, it drafts an entire 256-token paragraph simultaneously.” ― Brendan O’Donoghue & Sebastian Flenhagenhag, Google Research

クラウドで 1 万リクエストをバッチする前提なら自己回帰が最適解だ。しかし、ローカルで 1 ユーザーが 1 GPU を占有する状況では、HBM 帯域が律速になり、Tensor Core の大半が遊んでしまう。DiffusionGemma はこの「遊んでる計算資源」を 256 トークンのキャンバス並列ノイズ除去で叩く。

アーキテクチャの本質：Block Autoregressive Diffusion

既存報道（GIGAZINE / 窓の杜 / ITmedia / note.com npaka / Yahoo! / gihyo.jp）はいずれも Google 公式ブログを要約したニュースサマリーに留まっている。本稿では Hugging Face 公式 model card と recipes.vllm.ai の実測値から、3 つの構造的特徴を抽出する。

1. スペック表：Gemma 4 と完全に揃えた 26B/3.8B MoE

つまり、ベースのアーキテクチャは Gemma 4 と同一であり、追加されたヘッドは「離散拡散デコーダ」のみ である。MoE・エキスパート数・256K コンテキストはすべて Gemma 4 から継承しており、既存の Gemma 4 エコシステム（vLLM / Transformers / MLX / Unsloth / NVIDIA NeMo / llama.cpp）がそのまま使える。

2. 生成方式：自己回帰ではなく 256 トークン・キャンバスの反復ノイズ除去

[エンコーダ]  prompt → KV cache（prefilling）
[拡散デコーダ]  256 トークンのキャンバスを初期化（全プレースホルダー）
              ↓
        双方向アテンション + エントロピー境界サンプリング
              ↓
        完成したキャンバスをエンコーダに渡し、KV cache に追加
              ↓
        次の 256 トークン・キャンバスへ（block autoregressive）

重要なのは、1 キャンバス内が双方向、1 キャンバス間が自己回帰 というハイブリッドである。完全な双方向ではない。これは vLLM Recipes ドキュメントでも強調されている重要な実装上の制約であり、KV cache 容量とのトレードオフで生まれた妥協点だ。

3. 速度向上の正確な内訳

Google 公式の「最大 4 倍」はローカル・低並列時の話でしかない。vLLM Recipes の実測（SPEED-Bench, 単一 H100, 並列度 1）を以下に展開する。

ここから読み取れる構造は単純だ。

• スループット（Output TPS）は 1.9 倍——「最大 4 倍」と公式が謳う数字は複数 GPU・特殊条件下
• E2E レイテンシは 3.3 倍速い——ユーザーの体感速度としては意味のある向上
• TTFT は 9.2 倍遅くなる（53 ms → 489 ms）——キャンバス全体の初期化と数ステップのデノイズが必要なため、ストリーミング開始が遅い
• 純粋な生成速度（Gen TPS）は 6.2 倍——出力が完全に生成されたあとのトークン流量

チャットボットの様に 1 トークンずつ表示する UX では TTFT の遅さが目立つ。「入力 → 完了」 で計る UX では 3.3 倍速く、「一括出力をバッチ処理」 するワークロードでは 6.2 倍速い。これが「双方向性で得て、単方向性で失う」の正確な構造である。

ベンチマーク詳細：「4 倍速だが 6 倍誤る」の数値的根拠

Hugging Face 公式 model card のベンチマーク表は、Gemma 4 26B A4B（instruction-tuned、Entropy Bound サンプラー）との直接比較を提供する。

決定的傾向：事実性が問われるタスクで 5-20pt 劣後し、HLE（Humanity’s Last Exam）でのみ Gemma 4 を上回る。これは直観に反する結果だが、拡散デコーダが「初期解を多並列サンプリング → 反復修正」する性質上、難問の「発想の分布」が広いタスクでは有利に働く一方、確定的な事実を出力するタスクでは単方向の自己回帰に劣る。

コミュニティ検証：「6 倍誤り」の真偽

r/LocalLLaMA の 6 月 12 日の投稿 Diffusion Gemma is 4x faster, but makes 6x more mistakes! は、実務家からの批判的検証として重要だ。

“We gave each the same three tasks: write a Steve Jobs biography, the history of Tetris, and the story of BeOS — every next topic less popular than the previous one. The less popular the topic, the worse it got: 4 mistakes on Jobs, 12 on Tetris, 12 on BeOS. Google says it themselves in the launch post: quality is lower, use regular Gemma 4 when facts matter.”

つまり主観的知名度の高いタスクでは 4 ミス、ニッチなタスクでは 12 ミス（3 倍） という分布。HLE で Gemma 4 に勝つ一方で、Web 検索の事前データに依存する単純事実生成では品質が落ちる。「3 倍速い半面、ニッチ事実で 3 倍誤る」と要約できる。これは Google 公式の「品質は標準 Gemma 4 より低い」という但し書きと整合的だが、Codeforces -289 ELO のような競技プログラミング領域での 17% 性能劣化は、業務利用において看過できない。

実装ガイド：vLLM Recipes の「罠」と必須フラグ

recipes.vllm.ai のデプロイガイドは、Gemma 4 にはない DiffusionGemma 固有の罠を 4 つ指摘している。

docker run -itd --name diffusiongemma \
  --ipc=host --network host --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:gemma \
  --model google/diffusiongemma-26B-A4B-it \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --gpu-memory-utilization 0.85 \
  --attention-backend TRITON_ATTN \
  --generation-config vllm \
  --hf-overrides '{"diffusion_sampler":"entropy_bound","diffusion_entropy_bound":0.1}' \
  --diffusion-config '{"canvas_length": 256}' \
  --enable-chunked-prefill

OpenAI 互換サーバー経由での利用は標準的だ。

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

response = client.chat.completions.create(
    model="google/diffusiongemma-26B-A4B-it",
    messages=[{"role": "user", "content": "Write a poem about the ocean."}],
    max_tokens=512,
    temperature=0.7,
)

thinking モード（reasoning）も利用可能で、extra_body={"chat_template_kwargs": {"enable_thinking": True}} で有効化、max_tokens=32768 まで拡張できる。

Open-Weight Frontier 第 7 モデル：6 月の勢力図

6 月時点で Open-Weight（Apache 2.0 / MIT / OpenMDW）フロンティアモデルを時系列で並べると、DiffusionGemma は第 7 モデルとなる。

重要な観察は、6 月の Open-Weight 勢は明確に 3 つの設計思想に分岐 していることだ。

1. 知能追求型（Nemotron 3 Ultra, GLM 5.2）——Artificial Analysis Intelligence Index を最大化し、クローズドのフロンティアと戦う
2. 効率追求型（Command A+, MiMo UltraSpeed, DiffusionGemma）——特定ハードウェア・特定ワークロードで 2-10 倍の効率向上を狙う
3. 統合プラットフォーム型（Gemma 4 12B, MiMo Code）——マルチモーダル・長時間コンテキスト・Harness 一体型

DiffusionGemma は 2 番目に属し、「1 ユーザーが 1 GPU を占有するローカル推論」 という制約に特化している。バッチサーバーでの QPS 最大化は範囲外で、これは Google 自身が公式に「クラウド高トラフィック環境では自己回帰モデルの方が効率的な場合がある」と但し書きを書いている。

日本企業 4 つの採用シナリオ

6 月 12 日の米 BIS による Fable 5 米国フロンティアモデル輸出管理、続く 6 月 13 日の AWS Bedrock の 30 日データ保持強制を受けて、日本企業の AI モデル選択は「データ主権 × 出力品質 × 推論速度」の 3 軸判断に変わった。DiffusionGemma はこの新しい意思決定空間にどの様に位置づけられるか。

シナリオ 1：Fable 5 緊急代替（24 時間以内に手を打つ必要のある企業）

6 月 14 日の輸出管理発表後、Fable 5 を本番運用していた日本企業には 24-72 時間の切り替え猶予 しか残されていない。Open-Weight への即時移行先として、DiffusionGemma は Nemotron 3 Ultra より推論速度が圧倒的に速いため、「同等のコストで 5-10 倍の QPS が出る」 可能性がある。注意点として、Codeforces -289 ELO / MMMU Pro -19.5pt の品質劣化を許容できるワークロード（社内ナレッジ Q&A、ログ分析、定型文書生成）に限定する。

シナリオ 2：AWS Bedrock Fable 5 データ越境を回避したい企業

6/13 記事 で詳述した通り、AWS Bedrock の provider_data_share API 経由では Fable 5 推論データが AWS 境界外に出る。日本企業は「データ越境を許容しない」というコンプライアンス要件から Open-Weight を選ぶ。この場合の代替 4 モデル（Nemotron 3 Ultra / Gemma 4 12B / Command A+ / DiffusionGemma）の比較は次の通り。

速度が第一要件なら DiffusionGemma、品質が第一要件なら Nemotron 3 Ultra、ローカル省メモリなら Gemma 4 12B という棲み分けが現実解となる。

シナリオ 3：6/15 Agent SDK 課切替後のローカル開発環境

6/5 記事 の Claude Agent SDK サブスクリプション分離（6/15 締切）以降、長時間セッションのサイレント停止リスクが顕在化した。代替ハーネスとして MiMo Code v0.1 が有力だが、「ハーネスの中身は OpenAI 互換エンドポイントを叩く」 ため、ローカル LLM バックエンドが必要となる。DiffusionGemma は vLLM 経由で OpenAI 互換 API を提供するため、MiMo Code + DiffusionGemma という OSS 完結エージェント構成が組める。

# mimocode.json の例
{
  "provider": "openai",
  "baseUrl": "http://localhost:8000/v1",
  "model": "google/diffusiongemma-26B-A4B-it",
  "agents": {
    "explore": { "maxSteps": 100 },
    "build": { "maxSteps": 200 }
  }
}

この構成なら Agent SDK のクレジット消費ゼロ、データ越境ゼロ、推論レイテンシ 6.2 倍速。ただし品質低下を許容できるタスク（定型コード生成、テストスキャフォールド、ログ整形）に限定する必要がある。

シナリオ 4：コード補完 IDE プラグインの内製

Apple Silicon Mac（ユニファイドメモリ）の場合、DiffusionGemma の速度向上は限定的だが、MLX サポート により M3/M4 Max の 64GB ユニファイドメモリで動かせる。VSCode 拡張 Continue の Ollama プロバイダー経由で、Tab 補完をローカル LLM にオフロードする用途は TTFT 489 ms でも許容範囲。「クラウドの補完候補が出るまでの待ち時間」と体感は同等だ。Gemma 4 12B と同じ 18GB 量子化で動くため、エディタのメモリ予算に収まる。

設計思想の 3 つの限界

最後に、Google 公式が自認する 3 つの限界を押さえておく。

1. 「最大 4 倍」は特殊条件——単一 H100・並列度 1・SPEED-Bench 条件下。バッチサーバーや RTX 4090 では 1.5-2.5 倍程度に縮む
2. TTFT 489 ms——ストリーミング開始が遅い。チャットボット UX ではユーザー体感が悪化する場合がある
3. 「facts matter な用途には Gemma 4 を使え」——公式が品質劣化を明言。AIME -19.2pt / Codeforces -289 ELO / MMMU Pro -19.5pt は実利用の境界線

結論：Open-Weight Frontier の 3 つ目の「分枝」

DiffusionGemma は、6 月の Open-Weight フロンティアが「知能追求」「効率追求」「統合プラットフォーム」の 3 つに分岐した中の、「ローカル効率追求」 の極に位置づけられる。1 ユーザーが 1 GPU を占有するワークロードで 6.2 倍の生成速度を出す設計は、Nemotron 3 Ultra（長時間エージェント TCO 最適化）、MiMo UltraSpeed（8×B200 エンタープライズバッチ）、Gemma 4 12B（ノート PC 統合メモリ）といった他の 6 月 Open-Weight モデルと明確に補完関係にある。

Fable 5 の米国 BIS 輸出管理下、AWS Bedrock のデータ越境問題、Agent SDK の 6/15 課切替が重なる日本企業にとって、Apache 2.0 でローカル実行でき、かつ 1000 tok/s を叩き出せる という DiffisionGemma の特性は、ニッチだが確実に需要のある選択肢だ。品質劣化を許容できるワークロードの線引きさえ明確にできれば、データ主権時代の日本 AI エンジニアリングにおいて価値ある一石となる。

内部リンク

• 6/13 AWS Bedrock Fable 5 データ保持で ZDR 契約無効化 ― 6/9 からの Fable 5 政策変更と DiffisionGemma の代替ルート
• 6/13 MiMo Code v0.1 エージェントハーネス ― 6/15 課切替後のハーネス代替
• 6/10 MiMo-V2.5-Pro-UltraSpeed 1000 tok/s ― 8×B200 エンタープライズバッチ側の対応モデル
• 6/6 Nemotron 3 Ultra 長時間自律エージェント ― 品質追求側の対応モデル
• 6/4 Gemma 4 12B エンコーダフリー ― ローカル省メモリ側の対応モデル
• 5/26 Cohere Command A+ 218B MoE ― 2×H100 量子化側の対応モデル
• 6/5 Claude Agent SDK 分離 ― 6/15 課切替のコンテキスト
• 6/14 Fable 5 米 BIS 輸出管理 ― 6/12 輸出管理発表

この記事はAIによって生成され、人間の編集を経て公開されています。 Appwright AI は AI によるコンテンツ制作の可能性を探求する実験的プロジェクトです。