谷歌最新26B大模型，打字机变印刷机，推理速度1000+Token，4090可跑

大家好，我是 Ai 学习的老章

谷歌昨天又放了个大招——DiffusionGemma，第一个被 vLLM 原生支持的扩散式大语言模型（dLLM），推理速度直接干到 1000+ Token/s，就问你快不快吧

简介

DiffusionGemma 是谷歌 DeepMind 基于 Gemma 4 架构打造的 26B 参数大模型，但它和我们熟悉的 ChatGPT、Qwen、DeepSeek 这些模型有个本质区别——它不是一个 token 一个 token 往外蹦的，它是一整块一整块"喷"出来的

传统自回归模型（AR）就像打字员，一个字一个字从左到右敲；DiffusionGemma 更像印刷机，一次盖上去就是 256 个 token，然后反复打磨直到清晰为止

下面这张图很直观地展示了两者的区别：

自回归 vs 扩散式生成对比

自回归 vs 扩散式生成对比

核心参数一览：

这里要划重点：25.2B 总参数，但实际激活只有 3.8B，典型的 MoE 架构，意味着推理时显存占用远比你想象的低

为什么这么快

下面这张图一眼看清 DiffusionGemma 为什么快：

DiffusionGemma vs AR 速度对比

DiffusionGemma vs AR 速度对比

核心原理其实不复杂：

传统 AR 模型每次推理只能产出 1 个 token，受限于显存带宽（每生成一个 token 就要读一遍整个 KV Cache），在小 batch 场景下大量算力是闲置的

DiffusionGemma 换了个思路——每次生成 256 个 token，通过多轮去噪迭代（通常 10-20 步就能收敛），把闲置算力利用起来换取更低的延迟。这个 trade-off 在低并发场景下特别香

扩散采样循环示意

扩散采样循环示意

简单说就是：

1. 先随机初始化 256 个 token 的"画布"
2. 模型反复擦写这 256 个位置，每轮锁定最有信心的那些
3. 当画布稳定不再变化时，一次性输出这 256 个 token
4. 然后开始下一个 256 token 的画布

模型还支持 Thinking 模式（和 Gemma 4 一样），可以先思考再回答，适合数学推理和复杂编程任务

性能实测

这是 vLLM 官方在 batch size = 1 场景下的实测数据，FP8 量化版：

H100/H200 性能对比

H100/H200 性能对比

从 vLLM Recipes 的更详细测试来看（单 H100，并发=1）：

注意那个 首 Token 延迟（TTFT）489ms——因为模型要先去噪完一整个 256 token 的画布才能吐出第一个字。这是扩散模型的固有 tradeoff，但换来的是后续生成速度起飞

我看有网友2张3090显卡跑起来，可以达到450Token/s

Image

量化版推荐

RedHat AI 团队用 llm-compressor 制作了两个量化版本，精度损失几乎可以忽略：

FP8 动态量化版（推荐！）：

NVFP4 量化版（更省显存）：

两个量化版的精度恢复率都在 97% 以上，GPQA 和 GSM8K 甚至出现了"越量化越准"的情况（统计波动，不用太在意），非常值得使用

我的建议：

• 有 H100/H200（80GB 显存）→ 直接上 FP8 版，速度快精度高
• 显存紧张想榨到极致 → 选 NVFP4 版，显存占用更低

如果使用llama cpp启动，我看有测试，单4090也能轻松跑

./build/bin/llama-diffusion-cli \ -m /path/to/diffusiongemma-26B-A4B-it-Q4_K_M.gguf \ -ngl 99 -cnv -n 2048 --diffusion-visual

本地部署

DiffusionGemma 目前需要通过 vLLM 的 Gemma Docker 镜像部署：

# 拉取镜像
docker pull vllm/vllm-openai:gemma

单卡部署（H100/H200）：

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 \
        --host 0.0.0.0 --port 8000

部署量化版（FP8）：

VLLM_USE_V2_MODEL_RUNNER=1
vllm serve RedHatAI/diffusiongemma-26B-A4B-it-FP8-dynamic \
    --trust-remote-code \
    --attention-backend TRITON_ATTN \
    --max-num-seqs 4 \
    --hf-overrides '{"diffusion_sampler": "entropy_bound", "diffusion_entropy_bound": 0.1}' \
    --default-chat-template-kwargs '{"enable_thinking": true}'

几个关键参数说明：

• --max-num-seqs 4：扩散模型的状态缓冲区很大（canvas × vocab_size），并发数不能太高，否则会 OOM
• --gpu-memory-utilization 0.85：给去噪过程预留显存
• --attention-backend TRITON_ATTN：目前量化版需要用 Triton 注意力后端

使用

部署完之后，用法和普通 OpenAI API 完全一样，零切换成本：

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写一个快速排序"}],
    max_tokens=512,
    temperature=0.7,
)
print(response.choices[0].message.content)

开启 Thinking 模式（推理更强）：

response = client.chat.completions.create(
    model="google/diffusiongemma-26B-A4B-it",
    messages=[{"role": "user", "content": "求 x^3 * ln(x) 的导数"}],
    max_tokens=32768,
    extra_body={"chat_template_kwargs": {"enable_thinking": True}},
)

优缺点分析

优点：

• 推理速度炸裂，单请求 1000+ tok/s，是 AR 模型的 5-6 倍
• MoE 架构，激活参数只有 3.8B，单卡可跑
• 量化版精度几乎无损，FP8 和 NVFP4 都有
• 支持多模态（文本+图片+视频输入）
• 支持 Thinking 模式，复杂推理有保障
• Apache 2.0 开源，商用无忧
• 部署后兼容 OpenAI API，无缝切换

局限：

• 首 Token 延迟高（~489ms vs AR 的 53ms），不适合对 TTFT 敏感的流式聊天场景
• 并发数受限（max_seqs ≤ 4），高并发服务不太合适
• 目前只有 vLLM 支持（需要专用 Docker 镜像），生态还在建设中
• 基准分数整体比同架构的 Gemma 4 低一些（AIME 69.1% vs 88.3%），用速度换了一些精度

总结

DiffusionGemma 是一个很有意思的模型——谷歌用扩散式生成这条完全不同的路径，硬生生把大模型推理速度拉到了 1000+ tok/s 的级别。虽然精度上还没追平同参数的 Gemma 4，但在低并发、对延迟敏感的场景（比如个人助手、本地推理、实时对话），这个速度优势太明显了

如果你有一张 H100 或 H200，我强烈建议试试 FP8 量化版——精度几乎无损，速度直接拉满。这可能是目前 26B 级别开源模型里，单请求推理最快的存在了