vLLM · Production-Grade Serving

Run DiffusionGemma on vLLM

vLLM is the most popular production LLM server. DiffusionGemma works with vLLM's custom model loading — here's the exact config to get it serving.

vLLM works today (no PR wait). llama.cpp #24423 still in draft — Ollama and LM Studio waiting. Ecosystem status →

Current vLLM Support Status

vLLM has supported DiffusionGemma since day 0. Google collaborated with the vLLM team before launch, making vLLM the only production-ready serving path for DiffusionGemma today. No custom forks, no PR branches, no workarounds — just pip install vllm and --trust-remote-code.

vLLM loads models directly from HuggingFace format (safetensors), bypassing GGUF entirely. This is the recommended path for production deployments — multi-GPU, continuous batching, and OpenAI-compatible API out of the box.

Install vLLM with DiffusionGemma Support

Prerequisites

# Python 3.10+ required
python --version

# NVIDIA GPU with CUDA 12.x
nvidia-smi

# Install vLLM
pip install vllm

Start Serving — Single GPU

vllm serve google/diffusiongemma-26B-A4B-it \
  --trust-remote-code \
  --gpu-memory-utilization 0.92 \
  --max-model-len 65536 \
  --max-num-seqs 8 \
  --host 0.0.0.0 \
  --port 8000

Multi-GPU — Tensor Parallelism (shipped June 26, 2026)

TP=2 lets two 16GB GPUs (2×5060 Ti, 2×4080) run the full 26B model. TP=4 is for data center setups. vLLM #46177 fixed the vocab-parallel embedding mismatch — update to vLLM nightly (≥0.8.0.dev) for TP support.

TP=2 — 2 GPUs

vllm serve google/diffusiongemma-26B-A4B-it \
  --trust-remote-code \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 65536 \
  --max-num-seqs 8

TP=4 — 4 GPUs

vllm serve google/diffusiongemma-26B-A4B-it \
  --trust-remote-code \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.88 \
  --max-model-len 65536 \
  --max-num-seqs 16

NVFP4 on Blackwell (RTX 5090)

vllm serve nvidia/diffusiongemma-26B-A4B-IT-NVFP4 \
  --trust-remote-code \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 65536

NVFP4 is Google's custom 4-bit floating point format. Best quality-to-memory ratio. Requires NVIDIA Blackwell (RTX 5090, B100, B200). Emulated on Ampere/Ada with ~10% overhead.

TP Troubleshooting

"matmul reduction-dim mismatch" — you're on a vLLM version before #46177 merged. Upgrade: pip install --upgrade vllm --pre (nightly).

OOM with TP=2 on 2×16GB — lower --gpu-memory-utilization to 0.80 and reduce --max-num-seqs to 4. The 26B model at Q4 needs ~16GB total across GPUs, but KV cache adds per-request overhead.

Pipeline parallel (PP) is not supported yet — only tensor parallel works for DiffusionGemma. The sampler output type doesn't match PP broadcast expectations.

Key Configuration Flags

--trust-remote-code (required)

DiffusionGemma uses a custom model architecture not yet in HuggingFace Transformers mainline. Without this flag, vLLM refuses to load the model. This is safe for Google's official repo — it's the same flag every DiffusionGemma setup needs.

--gpu-memory-utilization 0.92

Leave 8% headroom for CUDA context and KV cache overhead. Pushing to 0.95+ risks OOM on long context windows. For the 26B model at Q4, expect ~16GB VRAM usage on a single GPU.

--max-num-seqs 8

Cap concurrent requests. DiffusionGemma's block-level generation means each sequence holds 256 tokens in memory simultaneously — higher concurrency hits VRAM harder than autoregressive models.

--max-model-len 65536

DiffusionGemma's native context window. You can go lower if you don't need long contexts — it saves KV cache memory.

Call the API

OpenAI-compatible endpoint

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/diffusiongemma-26B-A4B-it",
    "messages": [{"role": "user", "content": "Explain diffusion language models"}],
    "max_tokens": 256,
    "temperature": 0.7
  }'

Python client

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")

response = client.chat.completions.create(
    model="google/diffusiongemma-26B-A4B-it",
    messages=[{"role": "user", "content": "Explain diffusion language models"}],
    max_tokens=256,
    temperature=0.7,
)
print(response.choices[0].message.content)

Troubleshooting

"trust_remote_code" not recognized

You're on an older vLLM version. Upgrade: pip install --upgrade vllm. vLLM 0.6.0+ required for DiffusionGemma support.

OOM on startup

Lower --gpu-memory-utilization to 0.85 or reduce --max-model-len to 32768. If you're using a 16GB GPU (RTX 4060 Ti, 3070 Ti), consider Q4_0 GGUF via llama.cpp instead — vLLM works best on 24GB+ cards.

"Model architecture not supported"

Double-check --trust-remote-code is present. If the error persists, you may need to use the HuggingFace model ID exactly: google/diffusiongemma-26B-A4B-it.

Got it serving. Now keep it running.

This tutorial covers the PR branch workaround. The Production Guide covers production deployment: Docker Compose, GPU tuning, 20+ error fixes, multi-user serving — 8 chapters. $39 $29, lifetime updates.

Get the Production Manual — $29 →

Last updated: July 1, 2026