DiffusionGemma 把文本生成改成并行去噪：1000 token/s 之外更重要的生产边界

大语言模型长期像打字机：根据已有 token 预测下一个 token，再把新 token 放回上下文，重复直到结束。这个自回归过程天然串行，在单用户、本地 GPU 场景里，计算单元经常等着权重和 KV cache 从显存搬运。

DiffusionGemma 走了另一条路：不是从左到右逐词生成，而是一次放出一个带噪的文本块，让模型并行判断多个位置应该是什么，再经过若干轮迭代把整块文本修正出来。Google 公布的实验结果达到 H100 单卡 1000+ token/s、RTX 5090 700+ token/s，并以 Apache 2.0 开放模型。

这个数字足够抢眼，但它真正提出的问题是：当文本解码从串行变成并行，推理系统的瓶颈、产品形态和评测方式都会怎样变化？

自回归和文本扩散在算什么

自回归模型每一步计算一个条件概率：下一个 token 取决于之前所有 token。优点是训练和采样范式成熟，长文本质量稳定，流式输出自然；缺点是生成 N 个 token 至少要走 N 次串行解码。

文本扩散先初始化一组未知或噪声 token，然后反复去噪。每次前向可以同时更新一批位置，位置之间通过双向注意力互相参考。DiffusionGemma 每个 block 并行处理 256 个 token，因此代码填空、行内编辑、数独、分子或其他非线性序列可以同时利用左右两侧信息。

扩散不是“只做一次前向”。它仍需多轮去噪，只是每轮同时推进许多位置。最终速度取决于 block 大小、去噪步数、硬件利用率和质量目标。

为什么它在本地单用户场景更有吸引力

云端自回归服务可以用 continuous batching 把大量用户的不同 token 步骤拼在一起，提高 GPU 利用率。个人工作站上的单请求没有这种规模优势，GPU 很难被持续喂满。

文本扩散把同一个请求内部的多个 token 变成并行工作，使瓶颈从显存带宽更靠近计算吞吐。DiffusionGemma 是 26B 总参数的 MoE，每次只激活约 3.8B 参数；量化后可进入高端消费级显卡的显存范围。对于 IDE 行内改写、本地代码补全、实时草稿和交互式结构编辑，这种“单请求也能并行”的特性很重要。

但云服务是否同样获得四倍端到端收益，要看调度。扩散请求占用较大的并行计算块，可能挤压小请求；自回归服务已经高度优化的 batching、prefix cache 和 speculative decoding 也不会原地消失。

1000 token/s 不能代表用户体验

至少要同时看六个指标：

1. Time to first useful block：用户多久看到第一段可用结果。
2. Time to complete：完整答案何时稳定，不再大幅改写。
3. Revision churn：去噪过程中多少已显示内容会被替换。
4. Quality at latency：固定 100ms、500ms、2s 预算时质量是多少。
5. Effective throughput：通过格式、事实和任务验收的 token 有多少。
6. Energy per accepted output：每个可接受结果消耗多少能量与显存时间。

如果 700 token/s 生成的代码需要更多人工修复，它不一定比 200 token/s 的稳定模型更快。对于 Agent，最终指标仍应是每个已验证任务的时间和成本。

Block 生成会改变产品交互

传统聊天 UI 把逐字出现当成“模型正在思考”的反馈。扩散模型更适合展示块级草稿：先出现完整结构，再在局部位置变得更准确。

这对不同产品意味着不同设计：

• IDE：先生成整个函数骨架，再并行修正类型、变量和边界。
• 行内编辑：锁定不需要改变的文本，只对选区去噪。
• 结构化输出：先冻结 JSON schema，再修正字段值，避免整块漂移。
• 对话：按句子或段落提交稳定块，而不是把仍会变化的 token 全部展示。

UI 必须区分 provisional 和 committed 状态，否则模型每次修正都会让光标、语音播报和下游工具产生抖动。

Agent 工具调用需要“提交屏障”

普通文本可以边生成边改，工具参数不能。模型把文件路径从 A 修成 B 之前，如果系统已经执行删除或付款，后果不可逆。

因此扩散模型接工具时要设置提交屏障：

1. 去噪阶段只产生候选调用，不执行。
2. schema 完整、字段稳定后生成 committed call。
3. 确定性校验权限、类型、范围和幂等键。
4. 高风险调用进入人工审批。
5. 工具结果作为下一块的冻结上下文，不允许被模型改写。

这其实迫使 Agent runtime 更清楚地区分语言草稿和外部动作，是一件好事。

适合先试的任务和暂时不适合的任务

Google 也明确把 DiffusionGemma 定位为实验模型，并指出整体质量低于标准 Gemma 4。工程团队应把它放在路由系统里，处理速度敏感、可验证的任务，而不是为了吞吐数字替换所有模型。

一套公平的 A/B 评测

选择 50–100 个真实任务，把 DiffusionGemma 与同尺寸自回归模型在同一硬件、同一精度、同一最大质量预算下比较。除 token/s 外记录：

• 首个稳定块和完整结果延迟；
• 代码编译、单测、schema 和事实验证通过率；
• 每个通过样本的 GPU 秒数；
• 显存峰值和并发退化；
• 长度、block 边界和不同去噪步数的质量曲线；
• 用户接受率和编辑距离。

评测必须按任务类型分桶。把擅长填空的收益与长文质量平均在一起，会同时掩盖机会和风险。

并行生成真正改变的是硬件利用方式

DiffusionGemma 不是“下一 token 更快”，而是尝试把文本生成从串行依赖改造成可并行优化的问题。它可能让本地模型、行内编辑和非线性生成出现新的产品形态，也会迫使推理平台重新考虑调度、缓存、流式协议和工具提交。

最健康的判断是：这是值得进入实验队列的新执行引擎，不是已经证明可以替换自回归模型的终局。速度数字负责打开门，质量—延迟曲线和真实任务通过率才决定它能走多远。

参考资料

• Google：DiffusionGemma，4x faster text generation
• Google DeepMind：DiffusionGemma Model Page