Google 发布 DiffusionGemma：当语言模型不再只能从左到右写

Google 近期发布了开源模型 DiffusionGemma，并同步公开了DiffusionGemma 技术报告。它直接从完成全部后训练的 Gemma 4 26B-A4B 权重出发，通过离散多项式扩散算法，把原本逐个词单向提交的自回归生成过程，改写为在 256 个 token 大小的画布内通过多轮双向注意力迭代去噪的并行生成机制。

与此前闭源部署或参数与训练细节未完全公开的工业探索相比，Google 这次在发布Google 模型卡的同时，直接在Hugging Face 开放权重页面开源了完整的模型参数，并在架构中保留了可切回经典自回归模式的 AR fallback 接口，让工程团队可以直接在主流推理引擎上部署和测试离散文本扩散。

在官方公布的数据中，三个数字构成了鲜明的张力：在单张 NVIDIA H100 显卡上，模型单请求解码速度达到每秒 1,456 个 token；追加训练 token 预算少于原 Gemma 4 总训练预算的 10%；但在 AIME 2026 数学推理测试中，得分从原模型的 88.3 分回落到 69.1 分。作为一名跟踪语言模型推理演进的工程师，我最初看到发布时最容易关注千级别的解码速度，但在核对这组测试条件与消融数据后，更核心的问题浮现出来：这种通过改变生成顺序换取推理加速的架构尝试，在底层执行动作中改变了什么，又在模型能力上支付了怎样的代价。

前缀一旦写下就成了历史，但在局部画布里还能反复修改

普通自回归语言模型依据条件概率 $p(x_i | x_{<i})$ 生成文本，从左到右逐个预测下一个 token。每一步前向计算都建立在已有前缀的基础之上。以多位数乘法 23 × 47 = 1081 为例，如果将四个数字视作四个生成位置，自回归模型在第一步输出 1 之后，该位置便立即固化为后续计算必须接受的历史前缀。如果模型在第一步输出错误数值，在当前同一条生成轨迹中，后续计算无法返回第一位直接修改，只能在后续文本中承认失误或由外部系统重试。

文本扩散改变了这一生成过程。它在开始时先铺出若干未定稿的候选位置，随后在多轮前向计算中让整块文本同时演进。在第一轮计算中，第二位可能暂为 1，呈现 1181 的临时状态；在下一轮前向计算中，模型借助双向注意力机制同时参考前后相邻位置的信息，根据上下文约束将第二位修正为 0。随着去噪推进，高置信度位置先行锁定，低置信度位置持续调整，直至整段文本达到稳定。

DiffusionGemma 将这种双向迭代约束在固定的局部窗口内。模型每次处理包含 256 个 token 的 canvas 区域。在当前 canvas 内，模型通过多轮前向反复调整所有候选 token。当前 canvas 完成去噪并定稿后，模型将它完整写入 KV cache，作为后续生成步骤中只读的前缀上下文。模型处理新 canvas 块时，无法回写已定稿的历史块：

prompt / 已提交块 1 / 已提交块 2 / 正在修改块 3
           只读             只读          块内可改

在实际生成中，关于 DiffusionGemma token 提交动态的研究记录了 686 个测试提示词，发现模型并非在最后一步将 canvas 内的 256 个位置一次性定稿，而是随任务和文本粒度呈现分批锁定的动态过程。这种机制打破了自回归每个 token 必须即时提交的限制，同时保留了块级别向前推进的因果结构。单次前向能够同时推进多个位置，但模型只能修改当前 256 个 token 范围内的内容。

文本没法直接加高斯噪声，但现成的语言模型可以换一种生成方式

扩散模型在图像领域早已成熟，但迁移至自然语言处理经历了数年探索。图像像素与潜在空间特征处于连续数值空间，数值受到微小扰动或叠加高斯噪声后依然属于连续流形，神经网络能够通过连续得分函数学习逐步去噪。文本 token ID 则是离散类别索引，为特定 token ID 加上连续数值在词表中没有定义，相邻索引之间也缺乏连续的语义关联。文本无法直接叠加高斯噪声，必须专门构造离散空间的加噪与去噪规则。

离散加噪的数学形式化在 2021 年有了关键进展。D3PM 论文提出了结构化状态转移矩阵与吸收态机制，解决了 token 在离散空间中如何逐步加噪与去噪的转移概率建模问题。另一条探索路线是将 token 映射到连续词向量空间施加高斯扩散，2022 年的 Diffusion-LM 论文展示了连续轨迹在可控生成与局部填空上的灵活性，但连续向量向离散 token 映射时产生的舍入误差会导致文本质量受损，且其 200 步去噪采样在端到端耗时上达到自回归基准的 7 倍。

随后，离散扩散逐步向自回归的建模质量靠拢。2023 年发表的 SEDD 论文在 LM1B 数据集与 GPT-2-small 规模实验中，相对此前离散扩散基线将困惑度降低了 50% 至 75%，将困惑度差距缩小到距离同配置下从头训练的自回归基准约 1 个 PPL 以内。

到了大模型阶段，从头训练的算力开销促使研究转向复用成熟权重。LLaDA 论文使用 2.3T token 从头训练了 8B 规模的离散扩散模型，验证了在大规模数据下离散扩散同样可以涌现上下文学习与指令遵循能力，但也展示了从零预训练大模型的庞大开销。为此，DiffuLLaMA 论文探索了直接转换路线，将预训练好的 GPT-2 与 LLaMA2（127M 至 7B 参数）检查点转换为扩散模型，在 7B 模型上使用约 60B 至 65B token 完成适应，低于该研究设定的 200B token 上限，证明扩散模型无需从零重新学习通用语言分布。

工程部署与推理延迟随之成为新的焦点。Mercury Coder 技术报告展示了面向代码场景的低延迟扩散模型，在 Artificial Analysis 采用约 1K 输入搭配 1K 输出的专用代码提示词测试中，单张 H100 测得 1,109 与 737 output tok/s 的解码输出，但其模型参数量、初始化来源与具体训练配方未作披露。Gemini Diffusion 官方页面公布了每秒 1,479 个 token 的采样速度（不计 0.84 秒固定开销），在未披露硬件型号与上下文长度的前提下，其测试显示在 GPQA（40.4 对 56.5）和 Global MMLU（69.1 对 79.0）等基准上相较 Gemini 2.0 Flash-Lite 仍存在明显差距。在此之后，Dream 论文与 LLaDA 2.0 论文在模型转换、MoE 架构、分块扩散以及 KV cache 整合上继续推进。

DiffusionGemma 延续了此前的文本扩散与权重转换路线。它的技术增量，是把成熟模型资产复用、少步数采样器蒸馏、自回归回退、开放权重以及主流推理引擎支持整合进同一个可以直接分发的工程工件。模型以完成全部后训练的 Gemma 4 26B-A4B 权重作为初始化起点。该基座拥有 25.2B 总参数，每个 token 激活约 3.8B 参数，出发点本身已具备指令遵循、长思考、多模态理解与工具调用能力。

在加噪方式上，模型采用多项式离散扩散，按照噪声水平以一定概率将 token 替换为词表中均匀采样的随机 token。训练过程分为两个阶段：模型先在去噪适应训练中学习如何从随机 token 污染的 256-token canvas 块中重建干净文本。经过这一步后，模型使用较多采样步数能生成正常文本，但把采样压缩至极少步数会造成质量崩溃。接着，采样器蒸馏与强化学习（SD·RL）将任务奖励最大化与采样步数压缩整合进统一目标，由高步数 teacher 模型提供轨迹引导，训练 student 模型使用更少的前向计算轮次快速逼近定稿文本。在 SD·RL 训练后，模型在整条输出轨迹上平均单次网络前向传播能够产出约 19.74 个有效 token（TPF）。这是一个摊销平均值，并不意味着模型在每一次前向中固定写入 19.74 个 token。

根据DiffusionGemma 技术报告披露的信息，上述两个阶段追加训练所消耗的 token 总量，少于起始 Gemma 4 模型总训练 token 预算的 10%。这个比例描述的是训练 token 预算，并不等同于整体算力成本只有原模型的 10%。报告并未公开追加训练消耗的绝对 token 数量、FLOPs、GPU 机时或完整的转换配方。

每秒 1456 个 token 的测试条件，以及真实请求下的延迟表现

官方公布的 1,456 output tok/s 解码速度对应着一套精确的硬件与负载测试条件。

根据DiffusionGemma 技术报告的记录，该数据测定于单张 NVIDIA H100 GPU、FP8 精度、单并发请求（batch size 为 1）、4096 输入 token 搭配 1024 输出 token 的场景下，并且统计区间仅包含 decode 解码阶段，排除了 prefill 耗时。在该配置下，单次扩散前向平均硬件耗时为 13.56 毫秒，结合平均 19.74 的 TPF 产出率，得出每秒 1,456 个输出 token。在相同的硬件与请求配置下，标准 Gemma 4 自回归模型解码速度为 204 tok/s，开启多 token 预测（MTP）加速后为 303 tok/s。

这一加速效果来自于对 GPU 访存特性的改变。在单请求低并发场景下，自回归模型由于每次前向计算仅生成 1 个 token，计算密度较低，执行时间大量消耗在将模型权重与 KV cache 从显存读入计算核心的带宽开销上。DiffusionGemma 每次前向同时处理 256 个候选 token，减少了串行前向的总轮次，从而大幅缩减了在低并发下单请求对模型权重与 KV cache 的重复读取次数。

在引擎适配方面，vLLM 官方博客文章公布了与 Google 及 NVIDIA 联合开展的测试结果：在 batch size 1 的 FP8 环境下，单张 H100 测得 1,008 generation tok/s，H200 测得 1,288 generation tok/s。这是多方联合针对性优化的工程实现结果，不宜表述为第三方团队完全独立的盲复现基准。

在实际服务中，纯解码阶段的峰值 TPS 并不等同于用户感知的端到端响应延迟。vLLM SPEED-Bench recipe 在单张 NVIDIA H100、BF16 精度、单并发、max_tokens=256 且使用推荐熵界采样器的标准评测套件下，提供了更为全面的性能对照：

这组数据反映了吞吐量在实际交互链路中的转化特征。每请求 generation TPS 从 205 提升至 1282（约 6.2 倍），但由于 DiffusionGemma 在该测试集上生成的平均文本长度短于自回归模型，整体总 output TPS 从 199 提升至 375（约 1.9 倍）。平均端到端耗时从 2.87 秒缩短至 0.88 秒，带来了约 3.3 倍的实际加速。

同时，平均首 token 响应时间（TTFT）从自回归模型的 53 毫秒上升至扩散模型的 489 毫秒。自回归模型在完成 prefill 后只需执行单次轻量前向即可吐出首个 token，而扩散模型必须在首个 256-token canvas 上完成多轮前向去噪迭代并达到定稿阈值后，才能向外流式输出文本。

随着并发请求增加，Google 报告的并发实验显示，在约 32 个并发请求的测试配置下，自回归模式的总吞吐量开始反超扩散模式。高并发 continuous batching 聚合多个请求，逐渐填满显存带宽与计算单元，也把自回归的单步访存开销摊到多个请求上。扩散模式依靠减少单请求访存轮次获得的边际收益随之减弱。这个交叉点只属于报告中的测试配置，并非固定的系统常数。

速度提上去之后，复杂推理为什么会掉分，切回自回归又能找回多少

在生成吞吐量大幅拉升的同时，DiffusionGemma 在复杂推理任务上的表现出现了明显下滑。Google 模型卡中的测试对比记录了 DiffusionGemma 扩散思考模式与原始 Gemma 4 在 AR+MTP 思考模式下的基准成绩：

在数学竞赛测试 AIME 2026 上，扩散思考模式得分从 88.3 分下滑至 69.1 分，落差达 19.2 分；在检验多轮工具调用与智能体规划能力的 Tau2 测试中，得分从 68.2 分下降至 56.2 分；在长上下文多针检索任务 MRCR 128K 上，得分从 44.1 分下降至 32.0 分。

与这一质量落差相对照的，是模型保留的 AR fallback 机制。当工程人员将 DiffusionGemma 训练完成的最终权重重新加载回原版 Gemma 4 的经典自回归执行流程中，并在自回归模式下展开思考过程时，其各项推理指标出现了大幅回升：AIME 得分从 69.1 分恢复至 84.2 分（对比原始模型的 88.3 分），GPQA 得分从 73.2 分恢复至 79.8 分（对比原始模型的 82.3 分），BigBench Extra Hard 得分从 47.6 分恢复至 59.1 分（对比原始模型的 64.8 分）。此时，模型的解码速度也相应回落至自回归基线的约 204 tok/s。

AR fallback 的测试结果提供了重要的归因线索。指标的明显回升表明两阶段追加训练并未彻底破坏存储在模型权重底层的知识表征，提示运行时的扩散生成模式承担了部分质量损失。

但这一回升并不等同于无损转换。首先，切回自回归模式后，各项指标距离原版 Gemma 4 依然存在 3 到 6 个百分点的性能缺口；其次，由于技术报告缺乏单独强化学习、单独蒸馏以及联合因子设计的完整对照消融实验，无法在定量层面干净地区分质量差距究竟有多少来自于追加训练的数据预算限制，有多少来自于蒸馏压缩采样步数对输出多样性的影响，又有多少来自于 SD·RL 训练导致的更短平均输出长度。

高 TPF 生成与深度逻辑推理之间可能存在串行依赖深度的机制权衡。在自回归生成中，每输出一个推理 token，模型就执行一次严格基于全部既有前缀的有向条件计算 $p(x_i | x_{<i})$。复杂的数学推导和代码逻辑具有高度的串行因果依赖，后续推导步骤必须建立在前面步骤成立的基础之上。

在文本扩散模式下，单次前向计算虽然能够并行更新约 20 个 token 的内容，但这 20 个 token 是在同一个前向步内通过双向注意力协同调整的，属于同层并行更新，在机制推断上无法等价于连续执行 20 步串行状态转移所具备的因果计算深度。SD·RL 训练过程也反映了这一倾向：当任务奖励进入平台期后，继续训练主要在压低模型的预测熵并缩短输出文本长度，最终 checkpoint 的平均输出长度接近 SFT checkpoint 的一半，作者也承认这放弃了长链条推理可能带来的部分能力收益。

生成顺序不再只有一种，不同负载下的取舍依然分明

结合执行机制、吞吐条件与推理能力的综合表现，文本扩散在工程实践中的定位逐渐清晰。它并非在所有维度上全面替代自回归，而是为特定任务特征提供了一个可以在运行时进行针对性配置的性能档位。

低并发、长输出是优先测试扩散模式的一类负载，因为 decode 提速有更多空间抵消较高的首 token 延迟。但现有 SPEED-Bench 结果来自特定测试集与请求形状，不能直接外推到所有长文本任务。局部文本编辑与中间填空是另一个优先实验方向：256-token canvas 内的双向注意力可以同时参考待编辑区域前后的上下文，也允许后续候选影响前序位置。不过 DiffusionGemma 自身缺乏散文修订与跨 block 编辑的独立 benchmark，canvas 写入 KV cache 后也无法跨块回写，实际编辑收益仍需结合具体工作流验证。

较高并发下，成熟的 continuous batching 已能提高硬件利用率与总吞吐，扩散模式减少单请求访存的收益随之缩小。延迟敏感的短工具调用与请求路由通常只输出几十个 token，系统耗时主要由 prefill 与首 token 延迟主导，扩散模式较高的首 token 延迟反而可能增加响应时间。强约束结构化输出也仍偏向成熟的自回归栈：自回归引擎可以在逐 token 生成过程中应用文法或 JSON Schema 状态机，而离散扩散单步更新多个位置，现有语法状态机难以直接施加同样的逐 token 约束。根据vLLM 仓库的结构化输出讨论，当前扩散解码主要依赖全局生成后的校验与重试。

评估这一技术路线的后续演进，关键在于接下来出现的一系列实测证据。我们需要观察在控制相同任务准确率与输出长度的前提下，扩散模型在更广泛的任务集上是否依然能够维持端到端响应耗时的实际优势；也需要观察在代码局部重构与文本编辑场景中，原生双向画布去噪能否在编辑质量上系统性超越成熟自回归模型搭配外部编辑循环的方案；而在模型层面上，未来的采样器蒸馏算法或新型混合架构能否在保持高 TPF 并行输出的同时，有效弥合串行因果推理深度的差距。

在这些问题获得进一步数据验证之前，从左到右单向提交的自回归范式依然是复杂逻辑推理与通用生产服务的默认选择。DiffusionGemma 带来的变化，是让生成顺序从固定的模型假设，变成一个可以根据任务特征单独测试的运行选项。