【No.147】DiffusionGemma — latency PoC ベンチパック
2026年6月10日、Google は DiffusionGemma 実験オープンモデルを公開しました。
離散拡散で最大4倍速推論、26B MoE（4B active）、Apache 2.0、Hugging Face 公開。
品質は Gemma 4 より低く本番は Gemma 4 推奨——latency 勝負の席が Edge・ローカルで変わる候補です。
明日コピペできる深掘り実務パックとしてまとめた。
この記事に含まれるもの
DiffusionGemma 公開の要点 — 2026年6月10日と4倍速推論
Gemma 4 との使い分け — 品質本番 vs 速度実験
latency PoC ベンチ記録テンプレ — H100 1000+ tok/s 比較用
path 選定チェックリスト — code infilling / inline edit 向け
7日 PoC ロードマップ — 完了定義付き
この記事で持ち帰れること
autoregressive Gemma 4 は品質本番、DiffusionGemma は速度実験。code infilling・inline edit 向けに、latency 敏感 path へ PoC 1本を置き、Hugging Face weights でベンチ差を見て選ぶ型が公式の方向性です。
今週試す1手: Hugging Face weights でベンチ1回回す。
2026年6月10日公開 — 4倍速推論と品質トレード
Google 公式ブログ（2026年6月10日）によると、DiffusionGemma は離散拡散で最大4倍速推論。256 token 並列 canvas。26B MoE（4B active）。Apache 2.0、Hugging Face 公開。H100 で 1000+ tok/s が報告されています。品質は Gemma 4 より低く、本番は Gemma 4 推奨です。
例えば、エディタ内 inline edit や code infilling など latency 敏感 path では、4倍速が UX に直結します。ユーザーがキー入力のたびに補完を待つ場面では、1000+ tok/s 級のベンチが体感速度に効きます。一方、長文生成や品質重視の本番 API では Gemma 4 を維持する切り分けが公式推奨です。256 token 並列 canvas はタスクによって恩恵が変わるため、自前の入力長・出力長で再ベンチが必須です。Apache 2.0 で Hugging Face 公開されているため、社内 PoC のライセンス確認も比較的スムーズです。ベンチ・VRAM 条件は Google 公式 docs を正としてください。
公開の要点（Google 公式ベース）
日付: 2026年6月10日
方式: 離散拡散、最大4倍速推論
規模: 26B MoE（4B active）
ライセンス: Apache 2.0、Hugging Face
ベンチ: H100 で 1000+ tok/s、256 token 並列 canvas
品質: Gemma 4 より低い、本番は Gemma 4 推奨
品質本番 vs 速度実験 — path 選定の3要素
DiffusionGemma は速度実験向け、Gemma 4 は品質本番。ベンチ差を見て選ぶのが公式の型です。PoC 結果は「倍率だけ」でなく品質主観と path 名をセットで残すと、後から本番判断を振り返りやすくなります。
path 選定の3要素
latency 要件 — 100ms 台が必要か、秒台でよいか
タスク型 — code infilling / inline edit か、長文生成か
品質許容 — Gemma 4 より低い品質で足りるか
影響1 — Edge/ローカル: latency 敏感 path に PoC 1本
影響2 — 本番 API: Gemma 4 維持、DiffusionGemma は実験枠
影響3 — オープンソース: Apache 2.0 で社内 PoC がしやすい
よくある誤解と切り返し
誤解1: 「4倍速だから Gemma 4 を全面置換」→ 切り返し: 品質は Gemma 4 より低い。本番は Gemma 4 推奨。
誤解2: 「H100 が必須」→ 切り返し: 公式ベンチは H100 条件。自環境で再ベンチ必須。
誤解3: 「すべての推論が4倍」→ 切り返し: 最大4倍速。タスクと canvas 条件で変わる。自環境ベンチが必須です。
latency PoC ベンチ記録テンプレ — 1回分
ベンチ記録
日付: （実行日）
環境: （GPU 型 / VRAM / ドライバ版）
モデル A: Gemma 4 — （model 名 / HF path）
モデル B: DiffusionGemma — （HF weights path）
タスク: code infilling / inline edit / その他 — （1行）
入力長: （トークン数）
出力長: （トークン数）
tok/s A: （数値）
tok/s B: （数値）
倍率: B/A — （数値）
品質主観: A vs B — （OK/NG 1行）
判断: B 採用 path / A 維持 — （1行理由）
完了定義: tok/s に A/B 両方の数字がある。
path 選定チェックリスト — latency 敏感 path 向け
選定チェック
path 名: （例: エディタ inline 補完）
latency SLA: （ms または秒）
品質最低ライン: （Gemma 4 比で許容できるか — Yes/No）
DiffusionGemma 対象: Yes / No
PoC 実施: Yes / No
ベンチ tok/s 記録: Yes / No
本番 model: Gemma 4 / DiffusionGemma / 保留
ロールバック: Gemma 4 に戻す手順 — （1行）
完了定義: 本番 model が1行で決まっている。
7日 PoC ロードマップ — Hugging Face weights
Day 1 — HF weights 取得
Hugging Face から DiffusionGemma weights を取得、README 確認
完了定義: ローカルまたは staging に weights path がある
Day 2 — 環境準備
GPU 環境と VRAM を確認、Google 公式 docs の要件と照合
完了定義: 実行可能環境と1行メモ
Day 3 — Gemma 4 ベースライン
同一タスクで Gemma 4 の tok/s を1回計測
完了定義: ベンチ記録の tok/s A が埋まる
Day 4 — DiffusionGemma ベンチ
同一タスクで DiffusionGemma の tok/s を計測
完了定義: tok/s B と倍率が埋まる
Day 5 — 品質確認
出力品質を1行で主観評価
完了定義: 品質主観行が埋まる
Day 6 — path 選定
path 選定チェックリストを記入
完了定義: 本番 model が決まる
Day 7 — 共有
ベンチ結果を README またはチームに1行共有
完了定義: 共有先が1名以上
✅ 今日は Hugging Face の DiffusionGemma ページを開き、weights path を1行メモする。
ペルソナ別の使い方
Edge/ローカル開発者: code infilling・inline edit path を最優先 PoC。latency SLA 内なら DiffusionGemma 候補。
本番 API 担当: Gemma 4 維持。DiffusionGemma は実験枠のみ。
受託エンジニア: ベンチ記録をクライアント向け「latency 改善 PoC 報告」として提出。
参照
Google 公式ブログ（2026/6/10）。DiffusionGemma 実験オープンモデル。離散拡散で最大4倍速推論。26B MoE（4B active）。Apache 2.0・Hugging Face 公開。
免責
本記事は Google 公式情報ベースの二次解説です。ベンチ・VRAM 条件は Google 公式 docs を正としてください。テンプレは案件の機密・契約に合わせて改変してください。娯楽・要約向けであり、本番採用判断は自己責任で行ってください。
江戸テック瓦版 — AI 時代の生存戦略