DiffusionGemmaはllama.cppで動作するか？実際の状況

簡単な答え：標準のllama.cppはDiffusionGemmaを実行できません。 サポートはプルリクエスト #24423 にあり、執筆時点ではまだマージされていません。このPRはllama-diffusion-cliという新しい専用バイナリを追加します。DiffusionGemma GGUFに対して標準のllama-cliを実行すると、error loading model: unknown model architecture: 'diffusion-gemma'というエラーが発生します。

DiffusionGemmaが専用バイナリを必要とする理由

DiffusionGemmaは単なるGemma 4のリネームではありません。離散テキスト拡散を使用します。左から右へ1トークンずつ予測するのではなく、完全にマスクされた256トークンのキャンバスから始め、ブロック全体を並列にデノイズしながら繰り返し改良します。これには生成中の双方向アテンション、各デノイズステップでのカスタムサンプリング動作、標準のllama.cpp自己回帰パスとは根本的に異なるモデルランナーが必要です。

PR #24423はこれを既存のllama-cliへのパッチではなく、別バイナリ（llama-diffusion-cli）として実装しています。このPRがmainにマージされるまで、公式のllama.cppリリースにはこれが含まれません。

PR #24423とは何か、使い方

PR #24423はdanielhanchen（Unslothの創設者）によって作成され、diffusion-gemmaアーキテクチャをllama.cppコードベースに追加します。PRは2026年6月10日のDiffusionGemmaリリース以来活発に議論されており、コミュニティメンバーがPR待機中にLinux/WSL2 CUDAとWindows CPUの非公式プレビルドバイナリを公開しています。

PRブランチから自分でビルドする方法：

# llama.cppをクローン
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

# PRブランチをフェッチしてチェックアウト
git fetch origin pull/24423/head:diffusion-gemma-pr
git checkout diffusion-gemma-pr

# ビルド（CUDAの例）
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# 新しいバイナリの場所：
./build/bin/llama-diffusion-cli

CPU専用ビルドの場合は-DGGML_CUDA=ONフラグを省略します。

モデルの実行

信頼できるDiffusionGemma GGUFをダウンロードし（UnslothはHugging Faceのunsloth/diffusiongemma-26B-A4B-it-GGUFに最も広く使われているものを公開しています）、以下を実行します：

./build/bin/llama-diffusion-cli \
  -m ./diffusiongemma-26B-A4B-it-Q4_K_M.gguf \
  -p "拡散テキスト生成と自己回帰テキスト生成の違いを説明してください。" \
  --diffusion-steps 128

--diffusion-stepsパラメータはモデルが実行するデノイズパスの数を制御します。ステップ数が多い = 品質が高い、生成が遅い。128から始めて調整してください。

メモリ要件

モデルはGemma 4 26B A4B MoEアーキテクチャをベースにしているため、メモリ要件は同じです：

• Q4_K_M：約14.4〜18 GB（Unsloths実測値は18 GB）
• Q8：約28 GB
• BF16：約52〜58 GB

26B全体のパラメータをメモリにロードするにもかかわらず、各フォワードパスで活性化するのは約3.8Bのみです。

速度：数字の実際の意味

Googleは標準Gemma 4の最大4倍の生成速度と、単一H100で毎秒1,000トークン以上を主張しています。それらの数字は説明されたハードウェアでは本物です。しかし伝えていないのは：

速度の優位性は条件付きです。 DiffusionGemmaの並列生成は計算プロファイルをメモリ帯域幅制限（自己回帰モデルの特徴）から計算制限（拡散モデルの特徴）に変えます。豊富な計算資源を持つハイエンドNVIDIA GPU（RTX 3090、4090、A100、H100）ではDiffusionGemmaに有利です。ローエンドGPU（RTX 3060、4060）とApple Siliconでは計算格差が逆転し、速度の優位性が完全に消える可能性があります。ヘッドラインの数字を期待する前にハードウェアでベンチマークを確認してください。

品質は低くなります。 GoogleはDiffusionGemmaの全体的な出力品質が標準Gemma 4を下回ると明示しています。これは一時的な制限ではなく、拡散アプローチの速度-品質トレードオフの基本的な特性です。

ランタイム比較

ランタイム	DiffusionGemmaステータス（2026年6月）
llama.cpp（main）	非対応。unknown model architecture: 'diffusion-gemma'
llama.cpp（PR #24423）	llama-diffusion-cli経由で対応。PRブランチからビルド必要。
Unsloth Studio	v0.1.463-beta / 2026.6.6以降対応。最も簡単なローカル方法。
Ollama	非対応。Issue #16664オープン中。
LM Studio	非対応。バンドルされたランタイムにPR #24423が含まれない。
vLLM	2026年6月10日以降完全対応。サービング向け最善策。
HF Transformers	公式Googleリリース経由で対応。

どのパスを使うか

最小限のセットアップでローカルGUIが欲しい場合： Unsloth Studioを使用してください。6月12日のリリースからDiffusionGemmaをネイティブサポートし、推論パラメータを自動処理します。

コマンドラインに慣れている場合： PR #24423からビルドしてllama-diffusion-cliを直接使用してください。拡散パラメータを最も細かく制御できます。

Python環境の場合： Hugging Face Transformersを公式google/diffusiongemma-26B-A4B-itウェイトと共に使用してください。

複数ユーザーへのサービングが必要な場合： vLLMが最初にDiffusionGemmaを完全統合した推論エンジンとしてネイティブサポートを提供しています。

OllamaまたはスタンダードLM Studioユーザーの場合： 待ってください。両方とも同じ根本的なPRに依存しており、カスタムバイナリのビルドなしに回避策はありません。

よくある質問

llama.cppを最新バージョンに更新するだけでDiffusionGemmaサポートが得られますか？
いいえ。PR #24423はmainにマージされていません。公式リポジトリから更新してもdiffusion-gemmaアーキテクチャサポートは追加されません。

ダウンロードできるプレビルドのllama-diffusion-cliバイナリはありますか？
Linux/WSL2 CUDA（sm_86、RTX 30シリーズ）とWindows CPU向けの非公式コミュニティビルドが存在します。GitHubで「llama-diffusion-cli-prebuilt」を検索してください。これらはAnthropicやggml-orgの公式リリースではありません。

DiffusionGemmaは通常のGemma 4より良い出力を生成しますか？
いいえ。Googleは出力品質が標準Gemma 4を下回ると明示しています。優位性は速度であり、特に品質のトレードオフが許容できるコードインフィリングとインライン編集ワークフローに適しています。

OllamaはllaMa.cppをラップしているのに、なぜ失敗するのですか？
Ollamaはアップストリームより遅れた独自バージョンのllama.cppをバンドルしています。Ollamaを更新しても、バンドルされたランタイムにはPR #24423が含まれません。

関連ガイド：

• DiffusionGemmaはLM Studioで動作するか？
• llama.cppでunknown model architecture gemma4を修正する
• Gemma 4 A4BとE4B：どちらのモデルを使うか