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 可以探索的范围。

如果你只想稳定写长文、做知识问答或上线生产接口，标准 Gemma 4 仍然更稳。DiffusionGemma 更适合试低延迟编辑器、代码中间补全、结构化文本即时修正这类交互工具。

方式一：直接用 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 和模型卡里的最新说明。

方式二：用 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": "写一个 Python 函数，把 Markdown 表格转换成 CSV。",
        }
    ],
    max_tokens=512,
)

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

参数怎么理解

官方命令里有几个参数值得单独看。

--max-model-len 262144

设置最大上下文长度。DiffusionGemma / Gemma 4 系列支持很长的上下文，但这不代表每次都应该开到极限。上下文越长，显存和调度压力越大。

如果只是本地试跑，可以先保留官方值；如果显存吃紧，可以考虑降低它，再看实际任务是否受影响。

--max-num-seqs 4

限制同时处理的序列数量。DiffusionGemma 更适合低并发、本地交互；把并发开太大，不一定更快，反而可能增加显存压力。

本地单用户工具可以从 1 到 4 之间试。多人服务才需要更认真地压测。

--gpu-memory-utilization 0.85

告诉 vLLM 最多使用多少比例 GPU 显存。0.85 是一个比较常见的保守值。

如果启动 OOM，可以尝试降到：

1

--gpu-memory-utilization 0.75

如果显存很充足，也可以略微调高，但不要一开始就拉满，给系统和其他进程留一点余量。

--attention-backend TRITON_ATTN

指定 attention backend。官方命令使用 TRITON_ATTN，这和 DiffusionGemma 的特殊 attention / denoising 路径有关。

如果遇到 backend 不支持，多半是 vLLM、CUDA、Triton、显卡架构之间版本不匹配，先不要乱改模型参数，优先检查软件栈。

--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。模型不是一个 token 一个 token 线性生成，而是在一个块内并行去噪。这个值直接关系到它的块扩散生成方式。

不建议一开始随意改。先用官方值确认速度、质量和显存，再根据 vLLM 后续文档测试。

--enable-chunked-prefill

启用分块 prefill。DiffusionGemma 的长序列处理会在 prefill / denoising 之间配合工作，chunked prefill 可以帮助长上下文场景更稳地调度。

如果你只做短 prompt 测试，体感可能不明显；如果处理长上下文，它更有意义。

一个更保守的本地测试命令

如果你只是想先确认能不能启动，可以把并发和显存压力降一点：

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

这个命令不一定是最优性能配置，但更适合第一次排障。先让模型起来，再逐步增加上下文长度和并发。

适合拿来做什么 demo

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 适合 [这里写一个关于低延迟交互的短语]，但不适合质量优先的长文生产。

这些任务比“讲个故事”更能体现它的双向注意力、块内自修正和结构化输出能力。

常见问题

启动时报模型不支持

优先检查 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 是否正确加载量化格式，以及显卡是否满足模型要求。

速度没有想象中快

先确认你的场景是不是 DiffusionGemma 的优势区间。它的加速主要面向本地、低并发、专用 GPU、低到中等 batch。

如果是在高并发云端服务，自回归模型可以通过 batch 把硬件吃满，DiffusionGemma 的优势会变小。Apple Silicon 这类统一内存架构也未必能看到同等加速。

输出质量不如 Gemma 4

这是预期内的。官方明确说，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
  }'

如果这五步能跑通，再去调高上下文长度、并发和显存利用率。

DiffusionGemma 的文本扩散原理与适用场景

Google DeepMind 发布了 DiffusionGemma，这是 Gemma 系列里一个很有实验味道的新分支。它不是继续沿着传统自回归大模型“一次预测一个 token”的路线往前推，而是把扩散模型的思路引入文本生成：先生成一块带噪声的文本画布，再通过多轮去噪把整段内容逐步收敛出来。

官方给它的定位很明确：这是一个实验性开放模型，适合研究和开发者探索低延迟、本地交互式文本生成工作流，不是用来全面替代标准 Gemma 4 的生产质量模型。

先看关键信息

这里最值得注意的是两点：第一，它不是小模型，而是一个 26B MoE；第二，它推理时只激活 3.8B 参数，并且把生成瓶颈从显存带宽尽量转向算力。

它和普通 LLM 最大区别是什么

传统自回归 LLM 像打字机：从左到右，一个 token 接一个 token 地生成。这个方式稳定、成熟，也适合高质量长文本输出，但本地单用户推理时会遇到一个现实问题：GPU 很多时候没有被充分喂饱，瓶颈常常在反复读取权重和逐 token 解码。

DiffusionGemma 换了一个思路。它先创建一个 256 token 的随机占位画布，然后多轮并行 refinement。每一轮里，画布上的 token 可以互相看见，模型不是只看前文，而是能在一个块内做双向注意力。

这带来三个直接结果：

• 生成不是严格从左到右，而是整块文本一起收敛。
• 模型可以在生成过程中修正前面位置的错误。
• 对代码填空、行内编辑、格式闭合、数独这类非线性约束任务更自然。

换句话说，DiffusionGemma 不是在追求“同样路线上的更大模型”，而是在测试另一种文本生成路径：把文本当成一块可以反复打磨的画布。

为什么它可能更快

官方反复强调的关键点是：DiffusionGemma 试图把瓶颈从 memory bandwidth 转向 compute。

自回归模型每生成一个 token 都要反复访问模型权重。对于单用户、本地推理、低 batch 的场景，GPU 算力不一定能被充分利用。DiffusionGemma 一次处理 256 token canvas，给 GPU 更大块的并行工作，让 tensor cores 更容易跑起来。

官方给出的数据是：

• 单张 NVIDIA H100 上可超过 1000 tokens/s。
• NVIDIA GeForce RTX 5090 上可超过 700 tokens/s。
• 在专用 GPU 上文本生成速度最高约 4x。

不过这个速度结论有边界。官方也提醒，DiffusionGemma 的加速优势主要适合本地、低并发、单加速卡、低到中等 batch 的推理场景。如果是高 QPS 云端服务，自回归模型可以通过大批量请求把算力吃满，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 仍然是实验模型，不能只看速度。

官方说得很直白：因为它优先考虑速度和并行布局生成，整体输出质量低于标准 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。跑通之后，再回到官方配置，逐步测试速度、显存和输出质量。

参考资料：

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