DiffusionGemma：4 倍加速背后的取舍 (2026)

扩散语言模型在文本生成上一直有个尴尬点：理论上它不必一个词一个词往前吐，适合并行；但一旦放到大模型尺度，质量、训练方式和推理工程都会变得难处理。Google DeepMind 这次发布的 DiffusionGemma，重点不是把扩散模型吹成新的通用替代品，而是给一个更窄的场景交答案：低并发、本地、交互式文本生成，能不能把专用 GPU 真正喂饱。官方给出的答案是，26B MoE 总参数、推理时激活 3.8B 参数、每次并行生成 256 个 token，在部分专用 GPU 上达到最高 4 倍文本生成加速。1

先看结论：它不是 Gemma 4 的质量替代品

DiffusionGemma 是一个实验性开放模型，许可证是 Apache 2.0。它基于 Gemma 4 系列的能力基础和 Gemini Diffusion 研究，目标是探索文本扩散在速度敏感任务里的价值。官方也把边界说得很直：如果应用追求最高输出质量，标准的自回归 Gemma 4 仍然是推荐选择；DiffusionGemma 优先服务的是内联编辑、快速迭代、非线性文本结构生成这类交互场景。1

这句话很关键。它把 DiffusionGemma 从「新一代通用大模型」的位置上拿下来，放回一个更具体的问题里：当用户只发起一两个本地请求时，传统自回归模型的逐 token 解码会让显卡等下一步，算力利用率不高。扩散式文本生成把一段文本当成一个块来修，给 GPU 一次塞进更大的计算量，速度收益才有机会出现。

核心机制：从左到右打字，变成整段草稿反复修

多数语言模型像打字机：先预测第 1 个 token，再基于它预测第 2 个，按顺序一路往右。云端服务可以靠大量用户请求做 batch，把服务器利用率拉上来；单用户本地推理时，batch 很小，瓶颈常常落在显存带宽和等待下一步上。1

DiffusionGemma 换了一种生成方式。它先铺开一块随机占位 token 画布，然后多轮迭代：每轮锁定更可信的 token，把它们作为上下文，再修剩下的部分。因为一次 forward pass 可以并行处理 256 个 token，块里的 token 能互相看见，不再只有左边上下文。官方把这种双向注意力用于解释内联编辑、代码补全、氨基酸序列和数学图结构等非线性任务的潜在优势。1

这里的「自我修正」也要按工程语境理解。它不是模型突然有了额外的推理能力，而是生成过程中能看到整段候选文本，因而可以在同一块里修闭合 Markdown、补全代码片段、调整前后依赖。对需要边写边改的应用，这比严格从左往右输出更自然。

速度数字很亮，但适用条件也很窄

官方给出的硬指标集中在本地或低并发专用 GPU 场景：单张 NVIDIA H100 上 1000+ token/s，GeForce RTX 5090 上 700+ token/s；在量化后，它作为 26B 总参数 MoE 模型，可以落进高端消费级独显的 18GB VRAM 限制内。1

维度	官方说法	读者该怎么判断
推理速度	专用 GPU 上最高 4 倍文本生成加速；H100 1000+ token/s，RTX 5090 700+ token/s。1	适合先拿低 batch、本地交互任务实测，不要直接外推到高并发云服务。
模型规模	26B 总参数 MoE，推理时激活 3.8B 参数。1	它不是小模型，但通过稀疏激活降低单次推理负担。
显存门槛	量化后可放进 18GB VRAM 的高端消费级独显。1	对桌面工作站友好，对普通笔记本仍不算低门槛。
质量取舍	官方建议最高质量场景继续用标准 Gemma 4。1	不应只看 token/s，最终要把任务成功率、编辑成本和输出稳定性一起测。

速度收益还有一个容易被忽略的脚注：它依赖加速器的高算术强度。Google DeepMind 特别提醒，Apple Silicon 这类统一内存架构的计算与内存带宽比例不同，未必能相对自回归 Gemma 4 获得同样加速。1

这意味着 DiffusionGemma 更像是「桌面专用 GPU 工作流」的实验模型，而不是所有本地设备都能立刻吃到红利。对开发者来说，第一步不是问它是不是比 Gemma 4 快，而是确认自己的硬件、batch 大小和任务形态是否落在它的甜区里。

真正值得试的任务：不是普通聊天，而是需要来回改的文本

自回归模型最擅长的是顺序生成。用户问一句，模型接一句，输出从左到右推进。DiffusionGemma 的卖点在于它能同时看一整块文本，所以更适合「局部需要互相约束」的任务。

官方举了一个很直观的例子：Unsloth 把 DiffusionGemma 微调到解数独。数独的每个格子都受同行、同列、同宫的未来位置影响，这类任务对只能看左侧上下文的生成方式不友好；双向注意力让模型更容易在整张网格里协调约束。1

把这个例子翻译到开发场景，最可能受益的不是客服问答，也不是长篇报告一口气生成，而是这些任务：

在 IDE 里补一段代码，同时考虑函数前后结构。
修改 Markdown 或结构化文档，要求标签、列表、引用块成对闭合。
做代码 infilling，缺口两边都有上下文。
生成序列、图结构或表格时，需要让后面的约束反过来影响前面的内容。

如果你的任务只是「给我写一段普通说明」，扩散式生成的优势可能只剩速度，而且还要付出质量折扣。若任务本身有强约束、强交互、强局部修订，DiffusionGemma 才更值得拿出来试。

工具链已经铺开，但它仍是实验品

发布页列出的接入方式不少：模型权重在 Hugging Face，开发者可以用 MLX、vLLM、Hugging Face Transformers 等工具服务模型；Google 还提到 Hackable Diffusion、Unsloth、NVIDIA NeMo，以及即将到来的 llama.cpp 支持。NVIDIA 侧的优化覆盖 GeForce RTX 5090 和 4090、Hopper / Blackwell、DGX Spark、DGX Station、RTX PRO，并提到 NVFP4 这类 4-bit 浮点内核可提升计算吞吐。1

这套生态信号说明，Google DeepMind 不是只放一个论文式 demo，而是希望开发者真的把它接进本地推理栈。但官方同时保留了「experimental」标签，这个词在这里不能忽略。对生产系统来说，扩散文本模型至少还要回答几个问题：

输出质量在真实任务里比 Gemma 4 低多少，低在哪里。
多轮迭代的延迟曲线是否稳定，是否会出现某些 prompt 明显不收敛。
并行块大小、采样策略、量化方式会怎样影响可控性。
高并发部署时，速度优势是否会被成本和吞吐抵消。

官方已经点出其中一个答案：在高 QPS 云服务里，自回归模型可以靠 batch 把算力打满，因此 DiffusionGemma 的并行解码收益会递减，甚至可能带来更高服务成本。它最强的优势区间，是单加速器上的低到中等 batch。1

对开发者的判断标准

DiffusionGemma 最有价值的地方，是把「本地 LLM 太慢」这个问题拆细了。慢不只是模型小不小、显卡强不强，还取决于解码方式有没有让硬件干满活。对单用户交互场景，逐 token 生成确实可能浪费专用 GPU；扩散式文本生成提供了一条不同的路。

但这条路不是无条件更好。它用质量换速度，用局部块生成换顺序稳定性，用专用硬件吞吐换设备普适性。真正的评估应该放在你的任务上：内联编辑是否少等几秒，代码补全是否更完整，结构化文本是否少出闭合错误，用户是否愿意接受输出质量的下降。

如果这些指标成立，DiffusionGemma 可能会成为一类本地交互应用的新选项；如果不成立，它更像一篇值得跟进的研究信号。Google DeepMind 已经把模型、许可证和工具链入口摆出来，下一步要看的不是发布页里的最高 token/s，而是开发者把它放进真实工作流后，能不能少等、少改、少返工。

References

1DiffusionGemma: 4x faster text generation

DiffusionGemma：4 倍加速背后的取舍