DiffusionGemma不再逐词写答案

DiffusionGemma 技术报告补上了关键细节

谷歌近期发布 DiffusionGemma 技术报告，系统解释了这款 26B 混合专家模型为何能把文本生成速度提高到传统自回归模型的最高 4 倍。 截至 2026 年 8 月 20 日，报告已经以 arXiv:2608.00146 公开，距离模型在 6 月 10 日首次亮相约两个月。

DiffusionGemma 不是 Gemma 4 的常规升级，而是谷歌对另一条文本生成路线的公开实验。它没有继续沿用“预测下一个 token”的标准范式，而是一次处理整块文本，通过多轮迭代把不完整或不确定的内容逐步修正为最终答案。

扩散式语言模型是通过并行初始化一组文本位置，再经过多轮去噪或修订得到完整序列的语言模型。 这个思路与图像扩散模型“从噪声逐渐还原图片”相似，但文本是离散 token，不像像素那样能够直接连续加噪，因此模型需要额外设计离散状态、遮盖策略、采样顺序和停止条件。

它真正改变的是推理的瓶颈

DiffusionGemma 的核心价值不是减少计算量，而是把推理负载从显存带宽瓶颈转向并行计算。 这一区别决定了它为什么在独立 GPU、单用户和低并发场景下特别快，也决定了它未必适合所有线上服务。

自回归语言模型是按照从左到右的顺序，每次根据已有上下文预测一个新 token 的模型。生成一段 256-token 的内容时，自回归模型原则上要执行 256 个串行解码步骤；后一个 token 必须等待前一个 token 出现，GPU 很难在单条请求中把大量计算单元同时用满。

DiffusionGemma 则会一次性起草整个 256-token 文本块，并在后续步骤中并行评估和修改多个位置。它仍然需要多轮前向计算，并不是“一步吐出整段答案”，但每一轮可以同时处理大量 token，因此更容易利用 GPU、TPU 或 NPU 的矩阵计算能力。

并行生成不等于零延迟，而是用更少的串行步骤换取更大的单步计算负载。 如果一段文本经过数十轮修订才能完成，那么它的总浮点计算量未必低于自回归模型；它只是把原先分散在数百次小解码中的任务，重组为更适合现代加速器的批量计算。

这种变化可以用“打字机”和“印刷机”来理解。自回归模型像打字机，每次敲出一个字符；DiffusionGemma 更像先排好整页版面，再不断校对和换字。后者特别适合表格、代码片段、固定模板和行内改写，因为模型能够同时看到待生成区域的左右结构，而不是只能看已经写出的左侧内容。

单张 H100 超过每秒 1000 token，但数字不能脱离条件

谷歌公布的峰值结果显示，DiffusionGemma 在单张 NVIDIA H100 GPU 上可以达到每秒超过 1000 token，最高生成速度约为同级自回归方案的 4 倍。 部分公开材料给出的采样速度达到每秒 1479 token，初始开销约为 0.84 秒，但这些数字对应特定硬件、精度、输出长度和采样配置，不能直接套用到消费级显卡。

速度指标至少需要拆成三个部分来看：首个可用结果延迟、稳定输出吞吐量，以及完成整段文本所需的总时间。扩散模型可能快速给出一版粗略草稿，但用户是否能立即阅读，取决于界面是否展示中间状态；如果必须等全部修订完成，体验上的首字延迟就不一定优于流式输出的自回归模型。

“每秒 token 数”对扩散模型也不是完全公平的统一尺度。 自回归模型生成的 token 通常一旦展示就不会回头修改，而扩散模型可能在同一位置反复更新；如果把中间迭代也计入计算，却只按最终 token 统计，吞吐量体现的是完成速度，而不是模型每秒实际处理了多少 token 状态。

| 模型或路线 | 参数与架构 | 生成方式 | 公开速度信息 | 授权或开放程度 | 更适合的场景 | 主要限制 | |---|---:|---|---|---|---|---| | DiffusionGemma | 26B MoE | 以 256-token 文本块并行生成并迭代修订 | 单张 H100 超过 1000 token/s，最高约 4 倍提速 | Apache 2.0 开放权重 | 本地交互、行内编辑、快速草拟、结构化布局 | 质量仍偏实验性，速度依赖硬件和采样设置 | | Gemma 4 自回归模型 | Gemma 4 系列架构 | 从左到右逐 token 解码 | 未以同一配置给出统一绝对值 | 开放模型 | 高质量通用生成、成熟生产部署 | 单请求解码更受显存带宽约束 | | Gemini Diffusion | 扩散式文本生成研究路线 | 并行生成与多轮修订 | 官方强调低延迟，缺少完全可复现的开放权重对照 | 闭源产品与研究能力 | 实时交互、快速响应 | 外部开发者难以复现实验和深度定制 | | 常规云端自回归 LLM | 多种稠密或 MoE 架构 | 逐 token 解码，可进行动态批处理 | 高并发下可通过批处理提高总吞吐量 | 视产品而定 | 高 QPS 在线服务 | 单用户本地运行时硬件利用率较低 |

26B MoE 不等于每个 token 都跑 260 亿参数

混合专家模型是通过路由器为不同 token 选择部分专家网络参与计算的稀疏模型。 DiffusionGemma 的 26B 描述指向模型的总体参数规模，但不能简单理解为每一轮、每一个 token 都激活全部 260 亿参数。

MoE 的意义在于把模型容量和单次计算成本部分解耦。模型可以保存更多专家参数，不同类型的输入由不同专家处理，同时避免每次推理都遍历全部权重；代价是路由、专家调度和显存驻留变得更复杂。

26B 也不代表它能轻松塞进所有个人电脑。 仅按理论权重容量估算，26B 参数使用 16 位存储约需 52GB，8 位约需 26GB，4 位约需 13GB，这还没有计入缓存、激活值、路由和运行时开销。MoE 能减少实际计算量，却不会自动让未激活的权重从显存中消失，除非运行时采用分层加载或 CPU/GPU 卸载。

DiffusionGemma 原生强调对 NVIDIA NVFP4 的支持。NVFP4 是面向 Blackwell GPU 的 4 位浮点格式，其目标是在降低权重与计算开销的同时尽量保留精度；但这种优势依赖新一代硬件和对应软件栈，不能等同于任意显卡上的通用 INT4 量化。

扩散头让模型能“回头改”，但不会自动获得全局推理能力

扩散式输出头是负责把并行文本状态逐步转化为最终 token 序列的模型组件。 它与 Gemma 4 主干共同工作，让模型能够判断整块文本中哪些位置已经稳定、哪些位置仍需要继续替换。

这种机制天然适合“中间填空”任务。比如修改一句代码、补齐表格的某一列，或者在已知开头和结尾的条件下重写中间段落，自回归模型通常需要重建生成顺序；扩散模型则可以固定已知部分，只更新不确定区域。

能够同时查看整个文本块不等于一定具备更强的全局逻辑一致性。 模型确实可以在后续迭代中修正括号不闭合、格式错位和前后措辞冲突，但复杂数学证明、长链科学推理和事实准确性仍然取决于训练数据、模型容量与推理方法，而不是仅由解码架构决定。

公开信息显示，DiffusionGemma 在数学和代码类任务上具有竞争力，但在 GPQA Diamond、BIG-Bench Extra Hard 等高难度科学与综合推理测试上仍有明显改进空间。谷歌也没有把它定位成 Gemma 4 自回归模型的全面替代品，而是明确保留“实验性模型”的标签。

最适合它的不是聊天机器人，而是编辑器里的即时操作

DiffusionGemma 当前最有说服力的落地场景是本地、低并发、需要反复修改短文本块的交互式应用。 在这些任务中，用户更在意一次操作能否在一秒左右完成，而不是服务端每块 GPU 可以同时承载多少会话。

比较现实的使用方式包括：

• 在代码编辑器中并行补全一个函数，而不是逐行等待输出；
• 对已有段落执行局部改写，并锁定不需要变化的上下文；
• 生成 JSON、表格、SVG 或固定版式文本，让模型多轮修复结构；
• 在离线工作站上快速生成多个草稿，再由更强的自回归模型复核；
• 为游戏角色、设计工具和创作软件提供低延迟的本地文本反馈。

高并发云服务反而不一定能获得同等幅度的收益。 自回归模型虽然单条请求是串行的，但云服务可以把成百上千个用户的解码步骤组合成动态批次，让 GPU 始终保持高利用率；扩散模型每条请求的单步计算更重，还可能面对不同请求修订轮数不一致的问题。

这意味着“单卡 4 倍提速”不能直接换算为“线上服务成本下降 75%”。真实成本还取决于批处理效率、显存占用、提示词长度、固定块长带来的空白计算、采样轮数，以及模型为了达到相同质量是否需要额外验证或重写。

这是一条值得押注的支线，还不是主路

DiffusionGemma 证明了文本扩散已经从论文概念进入可下载、可部署、可测量的开放模型阶段。 Apache 2.0 许可证降低了研究和商业试验门槛，开发者可以围绕采样器、量化、缓存、条件填充和硬件内核进行优化，而不必只根据闭源产品的演示判断效果。

它的局限同样清楚。固定 256-token 块更适合短文本和局部操作，面对数千 token 的长答案时，如何保持跨块一致性仍是难题；多轮修订也使调试变得更复杂，传统的温度、top-p 和逐 token 概率分析不能原样照搬。

DiffusionGemma 最重要的行业意义，是把语言模型竞争从“谁的每个 token 更聪明”扩展到“谁能以更适合硬件的方式生成整段内容”。 自回归路线在模型质量、工具调用、长上下文和服务基础设施上仍然占据主导地位，但扩散路线可能先在 AI PC、专业工作站、编辑器和端侧代理中找到位置。

短期看，开发者不应因为 4 倍峰值速度就把现有生成链路全部改成文本扩散；更合理的做法是把它当作专用引擎，用于短块生成、局部修订和低延迟草拟，再让成熟模型承担复杂推理和最终校验。

长期看，如果扩散式语言模型能够同时解决质量、可控采样和跨块一致性问题，它可能改变用户对 AI 输出的基本认知：答案不再像聊天窗口那样逐字出现，而是先形成完整草稿，再在眼前迅速自我修正。DiffusionGemma 还没有完成这次替代，但它已经让这条路线从“有趣的研究”变成了值得实际测试的工程选项。

参考来源

• DiffusionGemma 相关模型与权重检索：Hugging Face 上的模型权重、社区实现及部署资料入口。
• 谷歌开源 4 倍提速的实验性扩散语言模型 DiffusionGemma：中文社区对模型架构、速度优势与本地推理场景的整理。

注：核心技术信息来自 2026 年 8 月公开的《DiffusionGemma Technical Report》（arXiv:2608.00146）以及谷歌此前发布的模型说明；按照本站来源链接规范，文末未列出非指定域名链接。