谷歌开源26B文本扩散MoE模型皮查伊称速度如赛马

今天一早，谷歌又发新模型了！

Gemmna 家族迎来了新成员——DiffusionGemma。这是一个专注于文本扩散的实验性开源模型，在文本生成任务上，速度表现极为突出。

根据最新信息，DiffusionGemma 基于 Apache 2.0 许可证发布，是一个总参数规模达 26B 的混合专家模型（MoE）。

它并没有沿用典型自回归大语言模型那种按顺序、逐 token 生成的模式，而是可以选择一次性生成整块文本。如此一来，在 GPU 上，文本生成速度最高可以提升到 4 倍。

DiffusionGemma 建立在 Gemma 4 家族业界领先的“每参数智能水平”之上，同时也吸收了 Gemini Diffusion 的前沿研究成果。它引入了一种全新的扩散式输出头，目标非常明确：尽可能提高生成速度。

需要说明的是，对于追求高质量生产级输出的场景，自回归版本的 Gemma 4 依然是首选。而 DiffusionGemma 更适合那些对速度要求极高、强调本地交互体验的研究人员和开发者，例如行内编辑、快速迭代，以及生成非线性文本结构等场景。

谷歌 CEO 皮查伊对它的评价是：“DiffusionGemma 是一款开放的实验性模型，它把我们的文本扩散研究带到了 Gemma 4 上。速度像赛马一样快——通过一次性生成整块文本，而不是逐 token 预测，推理速度最高可以提升到 4 倍。”

为开发者创造新的价值

对于实时交互式 AI 应用的开发者来说，本地推理最让人头疼的问题之一就是延迟。DiffusionGemma 正是冲着这个痛点而来，当然，也做出了一些取舍。

首先，推理速度非常快。

DiffusionGemma 将解码瓶颈从内存带宽转向了计算本身。因此在专用 GPU 上，token 输出速度最高可以提升至 4 倍。在单张 NVIDIA H100 上，它可以达到每秒 1000+ tokens；在 NVIDIA GeForce RTX 5090 上，也能达到每秒 700+ tokens。

其次是硬件门槛相对友好。

DiffusionGemma 是一个总规模为 26B 的 MoE 模型，但推理时只激活 3.8B 参数。经过量化后，它可以比较轻松地运行在 18GB 显存以内的高端消费级独立显卡上。

第三，它支持双向注意力。

每次前向计算可以并行生成 256 个 token，并且每个 token 都能看到其他 token。这让它在一些非线性场景中更有优势，比如行内编辑、代码补全、氨基酸序列生成，或者数学图结构。

第四，它具备一定的自我修正能力。

模型会通过多轮迭代，不断优化自己的输出。因为它可以一次性查看整个文本块，所以能实时发现并修正错误。

不过，DiffusionGemma 目前仍然是一个实验性模型。由于它更重视速度和并行布局生成，整体输出质量会低于标准版的 Gemma 4。如果应用场景对质量要求最高，那么标准版 Gemma 4 依然是最稳妥的选择。

当然，开发者也可以通过微调，让 DiffusionGemma 在特定任务上表现得更好。

下面这个例子中，Unsloth 对 DiffusionGemma 进行了微调，让它学会了如何解数独。数独对自回归模型并不友好，因为每个 token 往往都依赖后面的 token；而 DiffusionGemma 的双向注意力机制，反而让这类任务变得更容易。

经过微调后，DiffusionGemma 正在解数独。

为什么要用扩散模型生成文本？

过去几年，AI 研究社区一直在探索基于扩散的文本生成方法，但要把它应用到大模型上并不容易。

DiffusionGemma 的突破点在于，它改变了模型使用硬件的方式。

传统语言模型更像一台打字机：从左到右，一个 token 接一个 token 地生成。在云端，这种方式很高效，服务器可以同时批处理成千上万个用户请求，让硬件资源被充分利用。

但在本地运行、只有单个用户请求时，这种逐词生成的方式反而会让你的独立 GPU 或 TPU 处于低利用率状态。它大部分时间都在等待下一个“按键”。

DiffusionGemma 则把这个问题反了过来。它不是按顺序一个词一个词地预测，而是一次性起草整个 256-token 文本块。这样一来，处理器每次都能拿到更大块的计算任务，硬件利用率也更高。

换句话说，它把模型推理从一台顺序敲字的打字机，升级成了一台可以同时印出整块文本的高速印刷机。

Hugging Face 制作的 DiffusionGemma text-to-3D SVG 演示，展示了逐步生成过程。

这也意味着，DiffusionGemma 的速度优势主要面向本地推理和低并发推理场景。在高 QPS 的云端服务中，自回归模型本身就可以通过批处理充分吃满算力，因此 DiffusionGemma 的并行解码优势会被削弱，甚至可能带来更高的服务成本。

它的吞吐优势，主要体现在单个翻跟斗上的低到中等 batch size 场景。