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

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

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

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

事前確認

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

項目	推奨
モデル	`google/diffusiongemma-26B-A4B-it`
GPU	NVIDIA のディスクリート GPU を優先
VRAM	公式は、量子化後に高性能コンシューマー向け GPU の 18GB VRAM 範囲に収まると説明
推奨場面	ローカル、低同時実行、低遅延、対話型生成
非推奨場面	高 QPS のクラウドサービス、品質優先の長文生成
サービングフレームワーク	`vLLM`
API 形態	OpenAI-compatible local server

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 を選ぶべきです。

最小検証手順

次の順で確認できます。

Hugging Face にログインする。

1

huggingface-cli login

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

モデル一覧を確認する。

1

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

一度リクエストする。

 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
  }'

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

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

参考資料：