DiffusionGemma 发布：Google 开源 4 倍速文本扩散模型，本地推理新范式
2026 年 6 月 10 日，Google 在官方博客上发布了 DiffusionGemma——一款实验性的开源文本扩散模型，采用 Apache 2.0 许可证。与传统的自回归 LLM 逐个 token 生成不同，DiffusionGemma 通过并行生成整块文本的方式，在专用 GPU 上实现了最高 4 倍的推理加速。这一发布在 Hacker News 上获得 320+ points 和 87 条讨论，开发者社区反响热烈。
核心信息速览
| 特性 | 参数 |
|---|---|
| 模型架构 | 26B MoE（Mixture of Experts） |
| 激活参数 | 3.8B（每次推理仅激活 15%） |
| 加速倍数 | 最高 4x（对比同规模自回归模型） |
| 推理速度 | H100: 1000+ tok/s，RTX 5090: 700+ tok/s |
| 显存需求 | 量化后约 18GB（适配高端消费级 GPU） |
| 生成粒度 | 256 token 并行生成 |
| 许可证 | Apache 2.0 |
| 权重下载 | Hugging Face |
| 状态 | 实验性（experimental） |
技术原理：从「打字机」到「印刷机」
理解 DiffusionGemma 最直观的方式，是用 Google 博客中的经典类比：
传统自回归模型像一台打字机——逐个 token 从左到右输出。在云端，多用户请求批处理可以压满硬件利用率。但在本地单用户场景下，GPU 大部分时间处于等待状态（memory-bandwidth bound）。
DiffusionGemma 像一台印刷机——一次性「起草」整段 256 个 token，然后通过多轮迭代逐步精修，最终输出高质量文本。
具体工作流程分为三个阶段：
- 初始化：模型从一个「随机占位符 token 画布」开始（256 token 的噪声向量）
- 多轮迭代精修：每轮前向传播中，模型同时观察全部 256 个 token，锁定已确定的 token，用它们作为上下文线索修正不确定的部分
- 收敛：经过若干轮迭代，随机噪声收敛为连贯、高质量的文本输出
关键创新在于双向注意力（bidirectional attention）——每个 token 在生成过程中可以看到它前后的所有其他 token，这与自回归模型「只看左边」的单向注意力形成本质区别。这让 DiffusionGemma 在代码补全、内联编辑、Sudoku 求解等非结构化任务上表现优异。
速度优势从何而来？
传统 LLM 的推理瓶颈在于访存带宽（memory bandwidth）——每次前向传播需要把全部权重从 HBM 加载到计算单元，却只生成一个 token。在单用户本地推理时，计算单元大部分时间处于饥饿状态。
DiffusionGemma 将瓶颈从访存转移到了计算（compute-bound）——每轮前向传播同时生成 256 个 token，让 GPU 的计算单元被充分压满。在低并发（1-4 用户）的本地部署场景下，这一优势最为显著。
⚠️ 在高 QPS 云端部署中，自回归模型可以通过大批量请求（large batch size）压满计算单元，DiffusionGemma 的并行解码优势会递减，甚至可能产生更高的服务成本。
与 Gemma 4 的对比：速度 vs 质量
DiffusionGemma 建立在 Gemma 4 系列的「每参数智能比」之上，但两者面向不同场景：
| 维度 | Gemma 4（自回归） | DiffusionGemma（扩散） |
|---|---|---|
| 输出质量 | ★★★★★ 生产级标准 | ★★★☆☆ 实验级 |
| 生成速度 | 1x（基准） | 最高 4x |
| 适用场景 | 问答、写作、推理 | 内联编辑、代码补全、实时交互 |
| 硬件适配 | 所有 GPU | 专用 GPU（计算密集型加速） |
| Apple Silicon | 正常发挥 | 加速效果有限（访存瓶颈） |
硬件适配与部署
DiffusionGemma 的加速依赖 GPU 的计算密度（arithmetic intensity）。NVIDIA 已发布针对 Hopper（H100）和 Blackwell 架构的 NVFP4（4-bit 浮点）内核，支持 RTX 5090 和 RTX 4090 等消费级 GPU 的量化推理。
关键硬件适配信息：
- NVIDIA H100：1000+ tok/s，全精度推理
- NVIDIA RTX 5090：700+ tok/s，量化后约 18GB 显存
- NVIDIA DGX Spark / DGX Station：本地桌面部署原生支持
- Apple Silicon（M 系列）：加速效果有限——由于统一内存架构是访存瓶颈型而非计算瓶颈型，可能无法复现 GPU 上的加速比
模型权重已上传至 Hugging Face，开发者可以下载并在自有硬件上运行。官方 llama.cpp 支持即将到来，届时通过 GGUF 格式即可在更广泛的硬件上运行。
微调与定制
DiffusionGemma 通过微调可以显著提升特定任务的表现。Google 博客中展示了一个有趣的示例：微调 DiffusionGemma 解 Sudoku——数独的每个格子依赖上下左右多个方向的约束，自回归模型从左到右的单向生成方式天然不适合这种多重依赖场景，而 DiffusionGemma 的双向注意力可以在一次前向传播中观察所有格子之间的关系。
官方推荐使用以下工具进行微调：
- EasyLM（Google 自研的模块化 JAX 工具箱）
- Hugging Face 的微调流水线
社区反响与真实体验
HN 评论区中，一位开发者分享了自己使用 Mercury（另一个扩散模型）的实际体验：
“出乎意料地，我最喜欢的模型是 Mercury，不是因为它更’聪明’，而是因为它快得离谱。它更像结对编程的体验，而不是 SOTA Agent 那种’提示→等待’的模式。老实说，这更有趣，也找回了一些 AI 之前的编程乐趣。”
也有开发者指出扩散模型的真正机会可能在边缘设备：
“LLM decoder 在低负载时计算单元处于饥饿状态，因为需要反复搬运 GB 级的权重。在边缘设备上，你的加速器在逐 token 生成时大量时间在等待。DiffusionGemma 的并行解码恰恰解决了这个问题。”
局限性说明
作为实验性模型，DiffusionGemma 有明确的局限性：
- 输出质量低于 Gemma 4——追求速度的取舍，不适用于高质量生产场景
- 高并发场景无优势——在云端大批量推理中，自回归模型的批处理效率更高
- Apple Silicon 加速有限——统一内存架构的访存瓶颈限制了扩散模型的加速潜力
- 尚在实验阶段——官方不建议直接用于生产环境
总结与展望
DiffusionGemma 代表了文本生成架构的一个重要探索方向。它不是替代自回归模型，而是为速度优先的本地交互场景提供了一个全新的工具选择。
对于 AI 开发者而言，这意味着：
- 实时编码助手：代码内联补全和即时生成的体验将大幅提升
- 本地 Agent 应用：在消费级 GPU 上运行速度更快的本地推理模型
- 非结构化任务：如代码 infill、markdown 格式修复、JSON 生成等可利用双向注意力优势
正如 HN 评论中所说：“这可能是未来的雏形——虽然今天的模型还不够好，但方向本身很重要。” 对于关注本地 AI 推理效率的开发者，DiffusionGemma 是一个值得立即上手的实验项目。