Google 的 DiffusionGemma 并行生成文本
The Decoder··作者 Jonathan Kemper
关键信息
DiffusionGemma 总参数量为 260 亿，但由于采用混合专家架构，每一步只激活 38 亿参数。Google 表示，量化后模型可在高端消费级 GPU 上以 18 GB 显存运行，但它也承认输出质量弱于传统自回归模型。
资讯摘要
Google 发布了 DiffusionGemma，这是一个基于 Gemma 4 家族的实验性开源权重文本模型。与传统语言模型逐个生成 token 不同，DiffusionGemma 会先从 256 个随机占位 token 开始，再经过多轮迭代逐步修正，直到形成可读文本。这个思路借鉴了图像生成中的扩散模型，即把噪声不断去除并转化为有结构的结果。Google 介绍称，该模型总参数量为 260 亿，但由于采用混合专家架构，每一步只激活 38 亿参数。Google 还表示，量化版本可以在高端消费级 GPU 上以 18 GB 显存运行。Nvidia 参与了优化工作，并称该模型在单用户模式下、使用独立 GPU 时，推理速度可比传统自回归模型快最多 4 倍。
Nvidia 给出的数据包括：在 H100 上单请求约 1000 tokens/秒，在 DGX Spark 上约 150 tokens/秒，在 DGX Station 上最高约 800 tokens/秒，在 GeForce RTX 5090 上则超过 700 tokens/秒。Google 认为，这种加速来自更好的 GPU 利用率，因为模型一次并行处理最多 256 个 token，不再像许多自回归模型那样受限于内存带宽。Google 也指出，在 Apple Silicon 这类共享内存系统上，这种优势可能会变小；而在云端多请求服务场景中，优势甚至可能消失并带来更高成本。代价是生成质量不如传统模型，因此 Google 仍建议在最看重输出质量时使用普通的 Gemma 4 模型。公司将 DiffusionGemma 定位为面向研究人员和开发者的工具，尤其适合插入现有段落、补全代码空缺，或处理氨基酸序列、数学图结构以及类似数独的任务。
资讯正文
谷歌的新开源模型 DiffusionGemma 不再逐词生成文本，而是从噪声中生成文本
重点
- 谷歌发布了 DiffusionGemma，这是一款实验性的语言模型，采用基于扩散的方法生成文本，一次生成 256 个 token 的块，而不是逐词生成。
- 通过并行处理 token，该模型更充分地利用了图形处理器，在单用户模式、专用 GPU 上运行时，速度最高可比传统模型快四倍。
- 虽然生成文本的质量低于传统模型，但这种方法尤其适合非线性任务，例如事后插入文本或填补程序代码中的空缺。
谷歌发布了一款带开放权重的实验性模型，它通过扩散而不是逐词生成文本。在单块 GPU 上运行时，它在单用户模式下的速度最高可比经典语言模型快四倍。优化工作由 Nvidia 完成。
大多数语言模型都是一个 token 接着一个 token 地生成，每个新 token 都基于前一个 token。DiffusionGemma 采用了不同的方法。它从一块 256 个随机占位 token 开始，并通过多轮迭代逐步修正，直到形成可读文本。这一思路来自图像 AI，扩散模型正是这样把噪声转化为清晰图像的。
该模型总参数量为 260 亿，但每一步只激活 38 亿参数。这要归功于混合专家架构，其中多个专门的子网络并列存在，并根据输入只激活合适的部分。谷歌表示，在量化到更低精度后，这个模型可以装入高端消费级 GPU 上的 18 GB VRAM。它基于 Gemma 4 家族，并借用了谷歌此前 Gemini Diffusion 研究中的扩散流程。
更好的 GPU 利用率解释了速度提升
Nvidia 表示，速度优势归根结底来自硬件利用方式。对于自回归模型，单用户推理通常会受内存带宽限制。GPU 的计算单元大部分时间都处于空闲状态，只是在等待内存中的数据。工程师把这称为 memory-bound。DiffusionGemma 通过并行处理最多 256 个 token 绕开了这个问题，把瓶颈转向了原始计算能力本身。结果就是 GPU 确实能持续忙碌起来。
Nvidia 报告称，在处理单个请求时，H100 上的吞吐量约为每秒 1,000 个 token；在 DGX Spark 桌面系统上为每秒 150 个 token；在 DGX Station 上最高可达每秒 800 个 token。在 GeForce RTX 5090 上，谷歌声称其速度超过每秒 700 个 token。在本地单用户模式下，该模型在专用 GPU 上运行的速度大约是同类自回归模型的四倍。
谷歌将这一效果与专用加速器联系在一起。在 Apple Silicon 这类共享内存架构上，由于推理过程本身往往也受内存带宽限制，与自回归模型相比的差距可能会更小。
在具有大量并行请求的云端服务中，这种优势会反转。谷歌表示，在这种场景下，自回归模型本就已经能让硬件保持忙碌，因此 DiffusionGemma 实际上可能会推高成本。
速度是以质量为代价的，但也打开了新的应用场景
DiffusionGemma 以输出质量换取速度。Google 仍然建议在最看重质量的场景中使用常规的 Gemma 4 模型，并将 DiffusionGemma 定位为面向研究人员和开发者、用于尝试本地快速工作流的工具。
Google 认为，DiffusionGemma 真正擅长的是那些不是从左到右进行的任务。由于该模型会一次性考虑整个文本块，因此在生成过程中，每个 token 都可以引用其他所有 token，包括稍后才出现的 token。传统语言模型只能回看前文。
这使它适用于向现有段落中插入文本、填补代码空缺，或处理氨基酸序列和数学图等结构化数据。作为一个例子，Google 指向了一个由 Unsloth 微调的版本，DiffusionGemma 在其中解决了数独。自回归模型很难完成这类任务，因为每个填入项都依赖于后面的填入项。
从第一天起就具备广泛工具支持的开源权重
该模型权重已在 Hugging Face 上以 Apache 2.0 许可证发布。DiffusionGemma 可直接与常见推理库配合使用，例如 Hugging Face Transformers、vLLM（支持 Red Hat 集成）、以及 MLX。至于微调，Google 推荐其自己的 JAX 工具包 Hackable Diffusion，以及 Unsloth 和 Nvidia NeMo Framework。对 llama.cpp 的支持也在计划之中。
Nvidia 已针对 RTX 5090 和 4090 对该模型进行量化，并为 Hopper 和 Blackwell 服务器架构进行了优化，其中包括面向本地桌面部署的 DGX Spark 和 DGX Station。它也可通过 Gemini Enterprise Agent Platform Model Garden 和 Nvidia NIM 获得。
Google 还发布了 DiffusionGemma 开发者指南，Maarten Grootendorst 也制作了一份可视化指南，解释该模型的工作原理。
Gemini Diffusion 奠定了基础
Google DeepMind 早已通过 Gemini Diffusion 展示过一个基于文本的扩散模型的早期实验性演示。当时，DeepMind 声称其速度达到每秒 1,479 个 token。在基准测试中，Gemini Diffusion 的表现大致与 Gemini 2.0 Flash-Lite 持平。
初创公司 Inception 也在推进同样的并行扩散方法。其 Mercury 2 于 2026 年初发布，该公司称其为首个基于扩散的推理模型。
来源与参考
收录于 2026-06-11