DiffusionGemmaのローカルデプロイ：vLLMでGoogleのテキスト拡散モデルを動かす

前回は DiffusionGemma がなぜ注目に値するのかを整理しました。これは従来の逐 token 自己回帰生成ではなく、テキスト拡散と 256-token canvas 上の並列デノイズを使うため、低遅延のローカル対話、インライン編集、コード補完に向いています。

今回はより具体的に、どうデプロイし、どうコマンドラインで動かすかを見ます。

公式が現在示している主なルートは vLLM です。DiffusionGemma は vLLM の OpenAI-compatible local server として起動でき、OpenAI Chat Completions に近いインターフェイスでリクエストできます。

事前確認

まず、自分の環境で DiffusionGemma を試す価値があるか確認します。

DiffusionGemma は 26B total MoE で、推論時には 3.8B パラメータがアクティブになります。小型モデルではありません。MoE、量子化、並列生成によって、ローカルデプロイのハードルを高性能コンシューマー GPU で試せる範囲まで下げています。

安定した長文執筆、知識 Q&A、本番 API が目的なら、標準 Gemma 4 の方がまだ安全です。DiffusionGemma は低遅延エディタ、コード infilling、構造化テキストの即時修正といった対話ツールの実験に向いています。

方法1：vLLMで直接起動する

公式開発者ガイドの中心的なコマンドは次の通りです。

1
2
3
4
5
6
7
8
9

vllm serve 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

このコマンドは Hugging Face から google/diffusiongemma-26B-A4B-it を取得し、ローカルの OpenAI-compatible server を起動します。通常、デフォルトでは http://localhost:8000 をリッスンします。

Hugging Face のログインが必要な環境では、先に実行します。

1

huggingface-cli login

vLLM が未インストールなら、まず Python 仮想環境を用意できます。

1
2
3
4

python -m venv .venv
source .venv/bin/activate
pip install -U pip
pip install -U vllm

実際に pip install -U vllm だけで動くかは、現在の vLLM リリースに DiffusionGemma サポートが含まれているかに依存します。DiffusionGemma は新しいアーキテクチャです。モデル構造が認識されない、パラメータが認識されない、attention backend がエラーになる場合は、まず vLLM の最新 release、Google Developer Guide、モデルカードを確認します。

方法2：DockerでvLLMを動かす

ローカルの Python 環境を汚したくない場合は、vLLM の Docker イメージを使えます。vLLM recipes では、次のような Docker 起動例が使われています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

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 \
    --generation-config vllm \
    --enable-chunked-prefill \
    --host 0.0.0.0 \
    --port 8000

この方式は環境がきれいで、サーバー、ワークステーション、一時的なテスト機に向いています。注意点は二つです。

• ホスト側に NVIDIA driver と NVIDIA Container Toolkit がインストール済みであること。
• イメージ内の vLLM が DiffusionGemma をサポートしていなければ、起動は失敗します。新しいイメージまたは対応ブランチが必要です。

ホストの Hugging Face キャッシュを再利用したい場合、-v ~/.cache/huggingface:/root/.cache/huggingface が便利です。毎回モデルを再ダウンロードせずに済みます。

curlでサービスをテストする

サービス起動後、まずモデル一覧を確認します。

1

curl http://localhost:8000/v1/models

返却結果に google/diffusiongemma-26B-A4B-it が見えれば、サービスは基本的に起動しています。

次に Chat Completions を試します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/diffusiongemma-26B-A4B-it",
    "messages": [
      {
        "role": "user",
        "content": "DiffusionGemma と普通の自己回帰 LLM の違いを三文で説明してください。"
      }
    ],
    "max_tokens": 256,
    "temperature": 0.7
  }'

OpenAI SDK に慣れている場合は、base_url をローカルサービスに向けます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

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": "Markdown 表を CSV に変換する Python 関数を書いてください。",
        }
    ],
    max_tokens=512,
)

print(response.choices[0].message.content)

パラメータの意味

公式コマンドには、個別に見ておきたいパラメータがいくつかあります。

--max-model-len 262144

最大コンテキスト長を設定します。DiffusionGemma / Gemma 4 系列は長いコンテキストをサポートしますが、毎回上限まで開くべきという意味ではありません。コンテキストが長いほど、VRAM とスケジューリングの負担は増えます。

ローカルで試すだけなら公式値のままでもよいですが、VRAM が厳しい場合は下げて、実際のタスクに影響があるか確認します。

--max-num-seqs 4

同時に処理するシーケンス数を制限します。DiffusionGemma は低同時実行のローカル対話に向きます。同時実行を大きくしても必ず速くなるわけではなく、VRAM 圧力が増える可能性があります。

ローカル単一ユーザーツールなら 1 から 4 の間で試せます。複数ユーザー向けサービスでは、きちんとベンチマークが必要です。

--gpu-memory-utilization 0.85

vLLM が GPU メモリの何割まで使うかを指定します。0.85 は比較的保守的な一般値です。

起動時に OOM する場合は、次を試します。

1

--gpu-memory-utilization 0.75

VRAM が十分ある場合は少し上げても構いませんが、最初から最大にしない方が安全です。システムと他プロセスの余裕を残します。

--attention-backend TRITON_ATTN

attention backend を指定します。公式コマンドは TRITON_ATTN を使っています。これは DiffusionGemma の特殊な attention / denoising 経路に関係します。

backend がサポートされない場合、原因は vLLM、CUDA、Triton、GPU アーキテクチャのバージョン不一致であることが多いです。モデルパラメータを適当に変える前に、ソフトウェアスタックを確認します。

--hf-overrides

公式コマンドのこの部分は重要です。

1

--hf-overrides '{"diffusion_sampler": "entropy_bound", "diffusion_entropy_bound": 0.1}'

Hugging Face config 内の diffusion sampler 設定を上書きします。entropy_bound は、DiffusionGemma の反復生成に合わせてデノイズ停止やサンプリング挙動を制御する戦略と考えられます。

普通の LLM では見かけないパラメータです。まず公式値で動かし、その後で実験するのが安全です。

--diffusion-config

公式コマンドでは次のようになっています。

1

--diffusion-config '{"canvas_length": 256}'

canvas_length は DiffusionGemma の 256-token canvas に対応します。モデルは 1 token ずつ線形生成するのではなく、ブロック内で並列デノイズします。この値はブロック拡散生成方式に直接関わります。

最初から不用意に変えない方がよいです。公式値で速度、品質、VRAM を確認してから、今後の vLLM 文書に沿って試します。

--enable-chunked-prefill

chunked prefill を有効にします。DiffusionGemma の長系列処理では prefill / denoising が連携するため、chunked prefill は長コンテキストでより安定したスケジューリングに役立ちます。

短い prompt のテストでは体感しにくいかもしれません。長文脈では意味が出ます。

より保守的なローカルテストコマンド

まず起動できるか確認したいだけなら、同時実行と VRAM 圧力を下げます。

1
2
3
4
5
6
7
8
9

vllm serve google/diffusiongemma-26B-A4B-it \
  --max-model-len 65536 \
  --max-num-seqs 1 \
  --gpu-memory-utilization 0.75 \
  --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

これは最適性能設定とは限りませんが、初回の切り分けには向いています。まずモデルを起動し、その後でコンテキスト長と同時実行を増やします。

試すべきデモ

DiffusionGemma は普通のチャット質問だけで試すべきではありません。本当に見るべきなのは「非線形生成」と「リアルタイム局所修正」です。

次のような prompt を試せます。

1
2
3
4

次の Python 関数の中間で欠けているロジックを補完してください。完全な関数だけを出力してください。

def markdown_table_to_csv(markdown: str) -> str:
    ...

1
2
3

次の JSON を修正して合法な JSON にしてください。元のフィールドの意味は保ってください。

{"name":"demo","items":[{"id":1,"tags":["a","b",],},]}

1
2
3
4

次の Markdown 表を 5 行に補完し、各行の列数を揃えてください。

| パラメータ | 役割 | 推奨 |
| --- | --- | --- |

1
2
3

あなたはエディタ内のインライン補完モデルです。次の文の角括弧内だけを書き換え、前後の文脈を自然につなげてください。

DiffusionGemma は [低遅延対話についての短い表現を書く] に適していますが、品質優先の長文生成には向きません。

これらのタスクは、「物語を書いて」よりも、双方向 attention、ブロック内自己修正、構造化出力能力をよく見せます。

よくある問題

起動時にモデル未対応と出る

まず vLLM バージョンを確認します。DiffusionGemma は新しいモデルなので、古い vLLM には実装がない可能性があります。

確認します。

1

vllm --version

その後、公式開発者ガイド、vLLM release note、DiffusionGemma モデルカードと照合します。

Hugging Face のダウンロードに失敗する

ネットワークとログイン状態を確認します。

1

huggingface-cli whoami

必要なら再ログインします。

1

huggingface-cli login

サーバーで動かす場合は、事前にモデルを取得するか、Hugging Face cache をコンテナにマウントするのがおすすめです。

OOM

次の順で負荷を下げます。

1

--max-num-seqs 1

1

--gpu-memory-utilization 0.75

1

--max-model-len 65536

それでも OOM する場合は、量子化重みを使っているか、vLLM が量子化形式を正しく読み込んでいるか、GPU がモデル要件を満たすかを確認します。

速度が思ったほど出ない

まず自分の場面が DiffusionGemma の得意領域か確認します。加速は主にローカル、低同時実行、専用 GPU、低〜中程度 batch に向きます。

高同時実行のクラウドサービスでは、自己回帰モデルが batch でハードウェアを使い切れるため、DiffusionGemma の利点は小さくなります。Apple Silicon のような統一メモリでも、同等の加速が見えないことがあります。

出力品質が Gemma 4 より低い

これは想定内です。Google は、DiffusionGemma が速度と並列レイアウト生成を優先するため、全体的な出力品質は標準 Gemma 4 より低いと明示しています。品質優先の本番用途では、標準 Gemma 4 を選ぶべきです。

最小検証手順

次の順で確認できます。

1. Hugging Face にログインする。

1

huggingface-cli login

2. vLLM サービスを起動する。

1
2
3
4
5
6
7
8
9

vllm serve google/diffusiongemma-26B-A4B-it \
  --max-model-len 65536 \
  --max-num-seqs 1 \
  --gpu-memory-utilization 0.75 \
  --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

3. モデル一覧を確認する。

1

curl http://localhost:8000/v1/models

4. 一度リクエストする。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/diffusiongemma-26B-A4B-it",
    "messages": [
      {
        "role": "user",
        "content": "Python 関数を補完してください。Markdown 表の文字列を入力し、CSV 文字列を出力します。"
      }
    ],
    "max_tokens": 512,
    "temperature": 0.4
  }'

5. 構造化修正やコード infilling を試す。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/diffusiongemma-26B-A4B-it",
    "messages": [
      {
        "role": "user",
        "content": "この JSON を修正し、合法な JSON だけを出力してください：{\"name\":\"demo\",\"items\":[{\"id\":1,\"tags\":[\"a\",\"b\",],},]}"
      }
    ],
    "max_tokens": 256,
    "temperature": 0.2
  }'

この五つが通れば、コンテキスト長、同時実行、GPU メモリ利用率を上げていきます。

DiffusionGemma の仕組みと適した用途

Google DeepMind が DiffusionGemma を公開しました。Gemma 系列の中でも実験色の強い新しい分岐です。従来の大規模言語モデルのように「一度に 1 token を予測する」自己回帰の道をそのまま進むのではなく、拡散モデルの考え方をテキスト生成に持ち込んでいます。まずノイズを含むテキストキャンバスを作り、複数回のデノイズを通じて段落全体を徐々に収束させます。

Google の位置づけは明確です。これは研究者と開発者が低遅延のローカル対話型テキスト生成ワークフローを探るための実験的オープンモデルであり、標準 Gemma 4 を全面的に置き換える本番品質モデルではありません。

まず要点

注目すべき点は二つあります。第一に、これは小型モデルではなく 26B MoE です。第二に、推論時にアクティブになるのは 3.8B パラメータだけで、生成のボトルネックをできるだけメモリ帯域から計算へ移そうとしています。

普通の LLM と何が違うのか

従来の自己回帰 LLM はタイプライターのように、左から右へ 1 token ずつ生成します。この方式は安定して成熟しており、高品質な長文出力にも向いています。ただしローカルで単一ユーザーが推論する場面では現実的な問題があります。GPU が十分に使われないことが多く、ボトルネックは重みの反復読み出しと token ごとのデコードになりがちです。

DiffusionGemma は別の考え方を取ります。最初に 256 token のランダムなプレースホルダーキャンバスを作り、その後で複数回の並列 refinement を行います。各ラウンドではキャンバス上の token が互いに見えます。モデルは前の文脈だけを見るのではなく、ブロック内で双方向 attention を使えます。

これにより、次の三つの結果が生まれます。

• 生成は厳密な左から右ではなく、ブロック全体が一緒に収束する。
• 生成中に前の位置の誤りを修正できる。
• コード infilling、インライン編集、形式の閉じ、数独のような非線形制約タスクにより自然に対応できる。

つまり DiffusionGemma は「同じ道でより大きなモデル」を追うのではなく、テキスト生成の別ルートを試しています。テキストを、繰り返し磨けるキャンバスとして扱うという発想です。

なぜ速くなる可能性があるのか

Google が繰り返し強調している要点は、DiffusionGemma がボトルネックを memory bandwidth から compute へ移そうとしていることです。

自己回帰モデルは 1 token を生成するたびにモデル重みへ何度もアクセスします。単一ユーザー、ローカル推論、低 batch の場面では、GPU の計算能力が十分に使われないことがあります。DiffusionGemma は一度に 256 token canvas を処理するため、GPU に大きな並列仕事を与え、tensor cores を動かしやすくします。

Google が示した数値は次の通りです。

• 単一の NVIDIA H100 で 1000 tokens/s 超。
• NVIDIA GeForce RTX 5090 で 700 tokens/s 超。
• 専用 GPU で最大約 4x のテキスト生成速度向上。

ただし、この速度には境界があります。Google も、DiffusionGemma の加速効果は主にローカル、低同時実行、単一アクセラレータ、低〜中程度 batch の推論に向くと説明しています。高 QPS のクラウドサービスでは、自己回帰モデルが大きな batch によってハードウェアを使い切れるため、DiffusionGemma の並列デコードの優位性は小さくなり、場合によってはサービングコストが上がることもあります。

ここは重要です。これはあらゆるデプロイの万能アクセラレータではなく、「ローカルのリアルタイム対話」に向けた新しい道筋に近いものです。

アーキテクチャはどう動くのか

開発者ガイドでは、より具体的な説明があります。DiffusionGemma の生成過程は二つの段階に分けられます。

1. Prefill / Incremental Prefill

   causal attention を使って prompt を読み取り、文脈を KV cache に書き込みます。長文の場合、モデルは各 256-token block が完了した後、その結果を KV cache にコミットし、次のブロックを処理します。

2. Denoising

   bidirectional attention を使って現在の canvas を反復的にデノイズします。現在ブロック内の query token は、キャンバス上の他の token を見られるだけでなく、すでに KV cache に書き込まれた過去の文脈も利用できます。

この設計は block autoregressive denoising と呼ばれます。順序性を完全に捨てるのではなく、長文ではブロック間の順序安定性を保ちながら、各ブロック内部を並列生成します。

この折衷は合理的です。完全並列では長文の一貫性が難しく、完全自己回帰では逐 token のボトルネックに戻ります。DiffusionGemma は「ブロック間は順序、ブロック内は拡散」を選んでいます。

向いている場面

DiffusionGemma が最も向いているのは普通のチャットではなく、低遅延、高速な書き換え、局所補完、全体制約が必要な対話的場面です。

典型的には次のような方向があります。

• インライン編集：ユーザーが一文を変更し、モデルが局所的な置換をすばやく補う。
• コード infilling：ファイルの先頭から末尾まで書くのではなく、途中の穴を埋める。
• Markdown / JSON / XML などの形式の閉じ：モデルが出力ブロック全体を同時に見られるため、括弧、タグ、リスト構造を修正しやすい。
• 非線形テキスト構造：グラフ、表、数独、アミノ酸配列、数学的グラフ構造など。
• ローカルのリアルタイムツール：入力中に更新が必要な開発者ツール、エディタプラグイン、デスクトップ AI アシスタント。

公式開発者ガイドには数独 fine-tuning の例もあります。ベースモデルは数独を解くために特別に訓練されておらず、成功率はほぼ 0% です。しかし簡単な JAX SFT recipe で微調整すると、数独タスクの正答率が 80% に上がり、推論ステップ数も減ります。この例が示したいのは「数独向けモデル」ということではなく、双方向デノイズが強い制約、多変数、全体整合性を必要とするタスクに向いているという点です。

向いていない場面

DiffusionGemma はまだ実験モデルであり、速度だけを見て判断するべきではありません。

Google は明確に、速度と並列レイアウト生成を優先しているため、全体的な出力品質は標準 Gemma 4 より低いと述べています。最高品質を求めるアプリケーションでは、標準 Gemma 4 のデプロイが推奨されます。

また、次の場面には必ずしも向きません。

• 高品質な長文執筆。
• 高同時実行のクラウド API サービス。
• 出力安定性と事実正確性が非常に重要な本番タスク。
• Apple Silicon の統一メモリアーキテクチャに主に依存するローカル推論。

最後の点も公式説明に由来します。DiffusionGemma の加速はアクセラレータ上の高い arithmetic intensity に依存します。Apple Silicon のような統一メモリアーキテクチャは推論時にメモリ帯域に制約されやすく、自己回帰モデルに対する同等の相対加速が見えない可能性があります。

デプロイとツールチェーン

DiffusionGemma は Hugging Face から重みを取得でき、Kaggle と Google Cloud Model Garden からもアクセスできます。公式開発者ガイドには vLLM のローカル OpenAI-compatible server の例があります。

1
2
3
4
5
6
7
8
9

vllm serve 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

公式が触れているエコシステムには次のものがあります。

• vLLM
• Hugging Face Transformers
• SGLang
• MLX
• Hackable Diffusion
• Unsloth
• NVIDIA NeMo
• NVIDIA NIM

さらに、llama.cpp 対応も近日中とされています。ローカルモデル利用者にとって重要なシグナルですが、実際に対応が入るまでは、動くツールチェーンを基準に確認する必要があります。

Gemma 4 との関係

DiffusionGemma は Gemma 4 の代替品ではありません。Gemma 4 ファミリー上の実験的分岐に近いものです。

次のように考えられます。

• 標準 Gemma 4：品質優先の本番出力に向く。
• DiffusionGemma：速度優先、低遅延、ローカル対話、非線形生成の探索に向く。

Gemma 4 backbone と Gemini Diffusion 研究の上に作られていますが、目的は単純に benchmark を上げることではありません。テキスト拡散が開発者ワークフローを変えられるかを検証することです。特に、自己回帰生成方式が苦手としてきたリアルタイムエディタ、コード中間補完、構造化コンテンツの即時修正などが対象になります。

注目する理由

DiffusionGemma が注目に値するのは、すぐに「最強テキストモデル」になるからではありません。テキスト生成の基本仮定を少し横にずらしているからです。

ここ数年、テキストモデルはほぼ自己回帰路線が前提でした。この路線は成熟していますが、出力を自然に線形過程にします。先に前半を書き、その後を書き、早い段階で書いた誤りは戻って修正しにくい。拡散式テキスト生成は別の可能性を出します。まず全体を組み、局所を繰り返し修正し、ブロック全体を一緒に明瞭にするという方法です。

これは開発者ツールに特に想像の余地があります。実際の編集は空白文書から下へ一直線に書くものではありません。挿入、削除、補完、形式修正、局所修正、中間の穴埋めが含まれます。DiffusionGemma の構造は、この「局所編集 + 全体制約」に近いものです。

まとめ

DiffusionGemma のデプロイで重要なのは、「チャットモデルの代替」を探すことではありません。vLLM で OpenAI-compatible サービスを起動し、インライン編集、コード穴埋め、構造化テキスト修復、低遅延出力を中心に実験することです。

初回デプロイでは保守的なパラメータをおすすめします。--max-num-seqs 1、--max-model-len 65536、--gpu-memory-utilization 0.75 から始めます。動いたら公式設定に戻し、速度、VRAM、出力品質を少しずつ確認します。

参考資料：

• DiffusionGemma - Google DeepMind
• DiffusionGemma: 4x faster text generation
• DiffusionGemma: The Developer Guide
• Gemma 4 Usage Guide - vLLM Recipes