DiffusionGemma：Google 把扩散模型带进文本生成

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

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

先看关键信息

项目	DiffusionGemma
发布时间	2026-06-10
模型性质	实验性开放模型
基础	Gemma 4 backbone + Gemini Diffusion research
架构	26B total Mixture of Experts，推理时激活 3.8B 参数
生成方式	文本扩散，按 256-token canvas 并行去噪
许可证	Apache 2.0
速度目标	在专用 GPU 上最高约 4x 文本生成速度提升
典型硬件	量化后可在高端消费级独立 GPU 的 18GB VRAM 范围内部署
获取方式	Hugging Face、Kaggle、Google Cloud Model Garden

这里最值得注意的是两点：第一，它不是小模型，而是一个 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 的生成过程可以分成两种阶段：

Prefill / Incremental Prefill

使用 causal attention 读取 prompt，并把上下文写入 KV cache。对于长文本，模型会在每个 256-token block 完成后，把结果提交进 KV cache，再处理下一块。
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 是一个实验性开放模型，核心看点是用文本扩散和块内并行去噪替代传统逐 token 生成。它在专用 GPU、本地低并发、实时交互场景下可能带来明显速度优势，也更适合行内编辑、代码补全、结构化文本和多变量约束任务。

但它不是 Gemma 4 的生产质量替代品。现阶段更适合研究、工具原型和开发者实验。真正选型时，可以把它放在“低延迟交互模型”这一栏，而不是“通用最强大模型”这一栏。

参考资料：