不要再紧盯着 OpenAI 与 Anthropic 两家公司的新模型竞赛了！
就在最近，谷歌低调完成了一项重要突破：
将用于图像生成的扩散模型，巧妙迁移到文本生成领域，实现了高达 4 倍的速度提升。
这款新模型名为 DiffusionGemma，它彻底摒弃了传统自回归模型“逐 Token 生成”的串行模式，转而采用类似“整版印刷”的并行机制——首先铺设一张包含 256 个 Token 的“画布”，然后从随机噪声出发，经过多轮去噪步骤，使整段文字同时浮现出来。
凭借这一创新架构，DiffusionGemma 在生成速度上交出了惊艳的成绩：在单块 H100 上达到每秒 1000 个以上 Token，在消费级 RTX 5090 上达到每秒 700 个以上 Token，比同等规格的自回归模型快了约 4 倍。更值得关注的是，这个拥有 26B 参数的 MoE（混合专家）模型，推理时仅激活 3.8B 参数，量化后只需 18GB 显存即可运行。换句话说，一张 RTX 4090 显卡就能在本地流畅部署。
目前 DiffusionGemma 已采用允许商用的 Apache 2.0 开源协议，权重文件可直接从 Hugging Face 平台下载。
说到这里，大家应该已经意识到：DiffusionGemma 最显著的标签就是“快”。究竟有多快？我们用实际数据说话。
在同一块 H100 上（fp8 精度，batch size=1），DiffusionGemma 实现了每秒 1000+ Token 的输出速度，而采用标准自回归架构的 Gemma 4 26B A4B，即使加上 MTP 加速，也仅有每秒 300+ Token——两者之间的速度差距接近 4 倍。
要理解 DiffusionGemma 为何如此之快，得先弄清楚当前主流大模型为什么“慢”。如今的大语言模型，无论是 GPT、Claude 还是 Gemini，底层都基于自回归架构——就像一台老式打字机，从左到右，一个字接一个字地敲出来。每生成一个新 Token，都需要重新加载一次包含数十亿参数的模型权重。在云端服务器上，这并非大问题，因为服务器可以同时处理上千个用户请求，将硬件利用率压满。但在本地运行模型时，场景则完全不同——仅有你一人使用，GPU 的大量算力实际上处于空闲状态，只能等待一个 Token 一个 Token 地缓慢输出。工程师常将此称为“内存带宽瓶颈”（memory-bandwidth bound）。
为解决这一瓶颈，DiffusionGemma 将目光投向了扩散模型。回想一下，扩散模型在生成图像时，是不是直接对整张图片的所有像素同时进行去噪？没错，它的工作方式就是一次性处理一整块 Token，天然具备并行性。这意味着 GPU 可以一次性接收大量并行计算任务，Tensor Core 火力全开，不再因等待而闲置。计算瓶颈从“内存搬运不及”转变为“算力是否充足”，而算力恰恰是 GPU 最充裕的资源。
具体到 DiffusionGemma，其原理与 Stable Diffusion 类似，只是去噪后得到的不是图像，而是文本。
第一步：铺开一张包含 256 个随机占位符的 Token 画布。
第二步：通过多轮迭代去噪，高置信度的 Token 优先锁定，再将其作为上下文线索逐步修正剩余部分。
第三步：整段文本收敛为最终的稳定输出。
用谷歌自己的比喻来说，这相当于从单线程的打字机，升级成了整版印刷的印刷机。看看 Hugging Face 制作的 DiffusionGemma 文本到 3D SVG 演示，可以直观感受逐步生成的过程——模型并非从第一行代码写到最后一行的写法，而是整段 SVG 代码同时浮现、同时修正，最终收敛成一把完整的 3D 宝剑。
除了速度，DiffusionGemma 还有一个值得关注的特性：双向注意力。 传统自回归模型只能向前看，在生成第 N+1 个 Token 时，只能参考第 1 到第 N 个 Token，无法预知尚未写出的未来内容。而 DiffusionGemma 的 256 个 Token 同时生成，每个 Token 都能观察到画布上所有其他 Token，前后文同时可见。这赋予了一个自回归模型难以实现的能力——实时自我纠错。 模型边生成边评估整段文本的一致性，发现不合理之处立即修正，无需等待全部写完再回头修改。
谷歌为此举了一个直观的例子：数独。
数独的核心挑战在于“后面的数字会影响前面的数字”，自回归模型由于只能单向观察，处理起来极为困难。但微调后的 DiffusionGemma 在数独任务上的成功率从 0% 直接跃升至 80%。 因此，如果未来涉及代码补全、行内编辑、复杂 Markdown 格式化等需要“前后文同时协调”的场景，扩散模型无疑具备结构性优势。
然而，这并不意味着扩散模型毫无短板。其在图像生成领域早已被验证的最大局限——速度与质量的权衡——同样适用于文本。去噪步数越少，速度越快，但生成质量越低；去噪步数越多，质量越好，但速度优势也随之缩小。在质量方面，与相同参数量的 Gemma 4 26B A4B 相比，DiffusionGemma 在多项基准测试中确实存在差距。谷歌也很坦诚：生产环境推荐使用标准 Gemma 4，而 DiffusionGemma 主要面向对速度敏感的本地交互场景。
所以，或许正如谷歌 CEO 皮查伊所言，DiffusionGemma 目前更像一匹“赛马”——首先把速度提起来。 它目前只是谷歌对下一代模型形态的一次探索性实验：如果不再执着于一个 Token 一个 Token 地串行生成，而是让模型充分利用现代 GPU 的并行计算能力，那么大模型的速度上限究竟还能被推高多少？
而且说实话，谷歌并非第一个尝试验证这条路线的人。早在今年 2 月，初创公司 Inception Labs 就发布了扩散文本模型 Mercury 2，号称比 Claude、Gemini 快 5 到 10 倍，成为业内第一个真正投入生产的扩散语言模型。谷歌自己在去年 I/O 大会上也曾展示过 Gemini Diffusion 实验，当时采样速度达到每秒 1479 Token，但随后沉寂了整整一年，外界一度猜测该方案“走不通”。直到现在，DiffusionGemma 卷土重来，并且英伟达从 RTX 到 H100 全线为其提供支持——从 RTX 4090 到 H100 再到 DGX Spark 全覆盖，vLLM、MLX、Unsloth、NeMo 全部适配，llama.cpp 也在路上。
只能说，嘴上说着“实验性”，行动却很诚实。谷歌这次为 DiffusionGemma 配备的资源和生态支持，显然不只是为了展示一个技术 Demo。从模型到推理框架，再到硬件生态，DiffusionGemma 已经获得了足够多的支撑。至于它最终能否挑战自回归模型的主流地位，目前还没有定论。但至少，谷歌已经将这条路真正开源了。