Google DeepMind 6 月 10 日发布 DiffusionGemma，最容易被记住的数字是：单张 NVIDIA H100 上超过 1000 tokens/s，RTX 5090 上超过 700 tokens/s，最高 4 倍推理提速。

但这个数字不能单独看。DiffusionGemma 不是 Gemma 4 的加速版，也不是把所有文本生成任务都变快 4 倍。它真正有意思的地方，是把文本生成从逐 token 排队，改成一块一块并行生成。

它改了什么：从逐 token 到 256 token 并行生成

传统自回归大语言模型像排队写字。前一个 token 出来，后一个 token 才能继续算。这种方式稳定、成熟，但在本地单卡、低 batch 场景里，GPU 经常吃不满。

DiffusionGemma 换了路线。它用文本扩散方式，一次并行生成 256 个 token 的文本块，再通过多轮迭代修正。简单说，不是一个字一个字往前推，而是先铺出一片，再反复改。

模型规格也给得比较明确：26B MoE，总参数 26B，推理时激活 3.8B 参数。许可是 Apache 2.0，对本地应用和商业试验都更友好。

维度标准自回归模型DiffusionGemma我的判断
生成方式从左到右逐 token 输出256 token 文本块并行扩散生成改的是解码路径，不是单纯堆参数
模型形态视具体模型而定26B MoE，激活 3.8B对高端消费级 GPU 更有想象力
开放许可视模型而定Apache 2.0方便开发者做本地集成和产品试验
官方速度锚点依赖 batch、硬件和推理栈H100 1000+ tokens/s，RTX 5090 700+ tokens/s最高 4 倍不是全场景承诺
质量定位Gemma 4 仍偏生产主力整体低于标准 Gemma 4不能拿来直接替换高质量输出链路

这个变化对代码补全、内联编辑、填空、Markdown 结构补齐更有意义。因为这些任务经常不是单纯往后续写，而是前后互相约束。

比如补一段代码，后面的括号、变量名、缩进，都会反过来影响前面的选择。纯从左到右当然能做，但未必最省力。DiffusionGemma 的路线，至少是在试另一把刀。

它快在哪里：本地、低并发、强交互

DiffusionGemma 的速度优势，有前提。

官方给出的条件集中在单加速器、低到中 batch、本地或低并发推理。它还依赖专用 GPU、量化和优化推理栈。DeepMind 提到可通过 MLX、vLLM、Hugging Face Transformers 使用，并与 NVIDIA 在 GeForce RTX 5090、4090、Hopper、Blackwell 以及 NVFP4 内核上做了优化。

这句话翻译成产品语言，就是：它更适合一个用户盯着屏幕等结果的场景。

做 IDE 插件、桌面写作工具、本地代码助手的人，可以把 DiffusionGemma 放进候选池。动作也很具体：不要先替换主模型，而是挑 2-3 个高频交互点压测，比如代码补全、局部改写、结构化填空。

这里的收益不是少花一半云账单，而是少等几百毫秒。对强交互工具来说，这几百毫秒很值钱。用户不会管模型架构，只会感觉光标后面的补全是跟手，还是慢半拍。

云服务商的算盘不一样。

高 QPS 场景下，自回归模型可以把大量请求合批，把硬件利用率拉起来。DiffusionGemma 的并行解码在这种架构里，优势会变小。考虑到它还有迭代修正过程，成本也可能不降反升。

所以这不是云端大规模推理的省钱答案。更准确地说，它解决的是单人单卡、低到中并发下的速度问题。

它不能替代什么：质量和生产稳定性

DeepMind 没有把话说满。高质量生产输出，官方仍建议使用标准 Gemma 4。

这点比 4 倍提速更重要。文本扩散在图像生成里已经很成熟，但语言不是图像。语言任务要同时处理事实一致性、长程推理、指令遵循和风格稳定。任何一项掉线，开发者都要用微调、重排序或后处理补账。

对技术决策者来说，比较现实的路线是分层使用。

场景更适合的选择原因
高质量问答、复杂推理、正式文案生成Gemma 4输出质量和稳定性更重要
本地代码补全、内联编辑、快速草稿DiffusionGemma 可试延迟更敏感，质量容错更高
高 QPS 云服务先观望或小流量测试合批后速度优势可能被稀释
端侧或单卡工具值得压测更贴近官方优势区间

开发团队现在不该做大迁移。更稳的动作是三件事。

一是测真实延迟，不只看 tokens/s。交互产品更在意首屏响应、局部补全等待时间、用户是否感到卡顿。

二是测质量损失。尤其是量化后，在 RTX 4090、5090 这类消费卡上的表现，不能只看跑得快，还要看补全是否能用。

三是看本地生态支持。MLX、vLLM、Hugging Face Transformers 已经是入口，但 llama.cpp 等生态如果跟进不足，很多本地开发者的接入成本还会偏高。

我更在意的不是最高 4 倍这个数字，而是它把一个老问题摆到台面上：文本生成不一定只能逐 token 排队。只是新路归新路，兵贵神速，也怕失准。

DiffusionGemma 适合拿来抢交互速度，不适合拿来赌最终质量。开头那个 4 倍数字，应该被放回它该在的位置：本地、低并发、专用 GPU、特定推理栈下的速度上限。