DiffusionGemma 在一组公开测试中比自回归母模型快 7.1 倍。它在 AIME 2026 上也低了 15.1 分，并在约 32 个并发请求时失去总吞吐优势，详细延迟表还排除了 prefill。模型确实很快，应用能否变快取决于真正的瓶颈在哪里。
证据核验时间：2026 年 8 月 18 日。DiffusionGemma 属于实验性开放模型，本文保留每组数据的硬件与服务条件。
阅读时间：约 8 分钟 · 全文约 2800 字
核心结论
- 技术报告的 7.1 倍来自 H100、FP8、batch 1、4096 输入 Token、1024 输出 Token：DiffusionGemma 为 1456 TPS，Gemma 4 AR 为 204 TPS。
- 对比采用 multi-token prediction 的 AR 基线，优势缩小到 4.8 倍。Google 发布页写最高 4 倍，vLLM 在自己的配置中测得相对普通 AR 约 5 至 6 倍、相对 MTP AR 约 2.6 至 3 倍。
- 速度包含能力代价。AIME 2026 thinking 模式下，DiffusionGemma 得分 69.1，Gemma 4 AR 为 84.2，MTP AR 为 88.3。
- 扩散解码最适合低并发、单用户、输出较长且结构约束强的任务。并发增加后，AR batching 会逐渐占优。
- 任务与流量差异较大时，应把两类解码放在同一工作负载路由后面，按可验收结果选路，而非按峰值 TPS 选模型。
7.1 倍测量了什么
DiffusionGemma 从 Gemma 4 26B A4B 初始化。它不按顺序提交每个 Token，而是在 256 Token 的 canvas 上用双向注意力反复去噪。一个 canvas 通常只需远少于 256 次 forward 即可收敛。
技术报告在七个基准上平均得到 19.74 tokens per forward。在 H100、FP8、单请求、4096 Token 输入与 1024 Token 输出条件下：
| 解码器 | 输出速度 | 相对普通 AR |
|---|---|---|
| Gemma 4 AR | 204 TPS | 1.0 倍 |
| Gemma 4 AR + MTP | 303 TPS | 1.5 倍 |
| DiffusionGemma TD | 1456 TPS | 7.1 倍 |
这是同一配置下的解码对比，不能直接等同于所有应用的端到端加速。
Google 发布文章采用更克制的最高 4 倍。vLLM 的 batch 1 测试在单张 H200 上达到 1288 generation TPS，相对普通 AR 约 6 倍，相对 MTP 约 3 倍；H100 上为 1008 TPS，约为 5 倍和 2.6 倍。
硬件、kernel、量化、测试提示、adaptive denoising 和基线不同，倍数自然不同。它们共同描述一个条件区间，而非互相冲突。
为什么 batch 1 特别快
普通 AR 在单用户解码时经常受内存带宽限制。每生成一个新 Token，都要重新搬运模型权重，计算单元却没有充分利用。batching 的价值是一次为很多用户分别生成下一个 Token，用并发填满计算能力。
DiffusionGemma 把这部分空闲计算交给同一个用户。它在一个 canvas 中并行处理多个位置，用更重的一次 forward 换取更少的 forward 总数，瓶颈从反复搬运权重转向并行计算。
前提是硬件上仍有空闲计算。并发请求增加后，AR 同样可以通过 batching 使用这些计算资源。Google 文档因此明确把目标场景限定为消费端、低并发、本地使用。
瓶颈会随负载迁移。
质量账单写在报告里
技术报告同时比较了文本扩散模式、原始 AR 与 MTP AR。thinking 模式结果如下：
| 基准 | DiffusionGemma TD | Gemma 4 AR | Gemma 4 AR + MTP |
|---|---|---|---|
| AIME 2026 | 69.1 | 84.2 | 88.3 |
| GPQA Diamond | 73.2 | 79.8 | 82.3 |
| LiveCodeBench-v6 | 69.1 | 71.4 | 77.1 |
| HumanEval | 94.5 | 98.2 | 98.8 |
差距随任务变化。困难数学上的损失很大，部分结构化编码任务差距较小。DiffusionGemma 在多个推理基准上生成的总 Token 也更少。简洁输出进一步提高速度，同时限制了长推理轨迹带来的质量收益。
作者给出四个原因：模型从 AR 权重热启动，并未从头按扩散目标预训练；扩散适配的 SFT 阶段相对较短；RL 直接面向超低延迟；继承的架构可能并非扩散范式的最优解。已知问题还包括偶发 Token 重复，以及多模态任务中 thought tag 不完整。
这是一条 Pareto 曲线。增加 denoising steps 可以换取精度，adaptive stopping 可以针对简单任务提前结束。部署配置本身就是模型的一部分。
TPS 不是任务完成时间
报告的详细延迟表排除了 prefill。长上下文、检索、工具调用和验证都可能比输出解码更慢。此时，即使生成速度提高 7 倍，用户感知变化仍可能很小。
扩散还改变了首 Token 的含义。AR 生成一个 Token 后即可流式输出；block diffusion 需要先把 canvas 去噪到可以提交的状态。完整答案更快，与第一个稳定输出更晚可以同时成立，具体结果取决于 streamer 与接受策略。
Agent 工作流真正有用的指标是可验收结果耗时：
可验收延迟 = 检索 + prefill + 生成 + 工具等待 + 验证 + 重试
更快的解码器如果产生更多失败答案，验证和重试足以吃掉 TPS 收益。这与审计分词器性能瓶颈采用同一原则：测量限制完整闭环的环节。
并发反转
技术报告比较了并发提高后的单用户与总吞吐。低 batch 下 DiffusionGemma 占优，约到 32 个并发请求时，AR 开始取得总吞吐优势。
32 并非永久常数。报告明确说明，当前 DiffusionGemma 的 kernel 选择与 sampling 尚未针对 batch 大于 1 优化，后续实现可能移动交叉点。更稳定的是方向：
- 低并发留下空闲计算，扩散可以把它用于单个请求。
- 高并发让 AR 通过大量独立序列填满计算资源。
- 长提示会提高 prefill 与 attention 占比。
- 更大的 canvas 与更多 denoising steps 会提高计算和内存压力。
云服务需要测试真实流量分布，而非单个 batch。
四类工作负载怎样选
交互式本地生成
单用户占用一张卡、需要较长完整答案、重视完成延迟时，DiffusionGemma 很有吸引力。本地编码助手、结构化抽取和离线文档转换符合其目标场景。
高 QPS 云端聊天
大量请求可以持续 batching 时，AR 是更稳妥的默认项。需要在真实到达分布下测量 p50、p95、每秒完成请求数和每个可验收答案成本。
困难推理
答案质量高于延迟时，使用 AR 或更强推理模型。AIME 的差距无法用 TPS 抵消。混合系统可以让扩散生成草案或处理强约束部分，再把不确定和高风险任务路由给 AR。
结构化转换
输出位置大部分由输入决定时，扩散具备结构优势。报告中的 JSON 抽取用两步收敛，局部 Python 修复用三步收敛。这类任务比开放式长推理更匹配其机制。
一套能经受模型更新的部署矩阵
冻结代表性任务集，比较完整系统，至少记录：
| 维度 | 最小测量项 |
|---|---|
| 质量 | 任务通过率、schema 合法率、事实或测试准确率 |
| 延迟 | 首个有用输出时间、可验收结果时间 |
| 流量 | 真实到达率与并发下的 p50、p95 |
| 效率 | GPU 小时、每个可验收结果成本 |
| 稳定性 | 重复、格式错误、超时、重试率 |
| 配置 | 硬件、精度、引擎版本、canvas、步数、停止规则 |
然后建立显式路由：
- 低并发、强约束、延迟敏感任务走扩散。
- 困难推理、高风险决策和质量敏感代码走 AR。
- 高 QPS 流量选择实测 batching 下的胜者。
- 每次模型、kernel 或流量变化后重新测量边界。
回退规则应由任务风险和当前瓶颈决定，而非由模型标签决定。
常见问题
DiffusionGemma 真的快 7 倍吗？
在技术报告的 H100、batch 1 条件下，它比普通 Gemma 4 AR 快 7.1 倍。相对 MTP AR 为 4.8 倍，其他官方实现测得不同倍数。
为什么 Google 发布页写 4 倍？
发布页采用更宽泛、更保守的口径。硬件、精度、服务引擎、提示、adaptive steps 和基线都会改变结果。
DiffusionGemma 的推理质量更低吗？
公开 AIME 2026 对比中是：69.1 对 84.2。部分编码和结构化任务差距较小，因此质量需要按真实任务测量。
扩散解码一定延迟更低吗？
不会。batch 1 生成时间显著降低，prefill、首个稳定输出、工具调用、验证、重试和并发仍可能主导端到端延迟。
什么时候应该回退到自回归？
困难推理、高风险准确性、高并发 batching 占优，或 AR 的每个可验收结果成本更低时，应走自回归路径。