你让 AI 写一封邮件，熟悉的生成方式像有人边想边敲：先写第一个词，再根据前文写下一个。这个过程稳定，但必须排队进行。DiffusionGemma 想换一种办法：先摊开一整块带有空缺的草稿，再同时修改许多位置，反复几轮后交出完整文本。
这不是简单的加速技巧，而是在改写语言模型“如何写出一句话”。据 arXiv 技术报告摘要，DiffusionGemma 是一个实验性的开放权重语言模型，目标是探索非自回归的高速生成路径。眼下值得看的，正是它能否在速度、质量和部署复杂度之间找到新的平衡。
从逐词接龙，改成整块修稿
传统语言模型大多采用自回归生成：从左到右一次预测一个 token。token 是模型处理文字的基本片段，可能是一个字、词的一部分，也可能是标点。后一个 token 依赖前面已经写好的内容，所以生成过程天然串行。
DiffusionGemma 使用离散扩散生成。它先把一组文本位置当作噪声或占位符，再经过多轮并行修正，逐渐得到完整文本。可以把它理解成编辑一张 256 格的稿纸：传统模型从第一格一路写到最后一格；DiffusionGemma 则先铺开全部格子，每轮同时确定其中一批内容。
据论文摘要，模型以 256 个 token 为一块进行迭代修正，而不是每次只解码一个 token。关键变化不在于“少算一次”，而在于让一次计算有机会推进多个位置，从生成机制上绕开逐 token 解码的串行瓶颈。
它不是从零造一台新机器
DiffusionGemma 基于 Gemma 4 的 MoE 架构改造。MoE，即 Mixture of Experts，中文通常译作“混合专家”：模型内部有多组不同的“专家”，每次只调用其中一部分。这样既能保留较大的总容量，也能压低一次推理实际动用的计算量。
论文摘要给出的规模是约 252 亿个总参数，推理时激活约 38 亿个参数。参数可以粗略理解为模型训练后保存下来的内部权重。总参数代表它拥有的整体容量，激活参数则更接近每次工作时真正参与计算的部分。
“基于 Gemma 4 改造”也很重要。它说明这项实验不是完全抛弃已有模型，而是在现有能力上更换生成路径。摘要称，DiffusionGemma 仍支持思考模式、多模态输入和长上下文。多模态输入指模型不只处理文字，也能接收其他形式的信息；长上下文则表示它能在一次任务中处理较长的输入内容。
速度数字应该怎么看
按照论文摘要中的官方数据，DiffusionGemma 每次前向计算通常能生成约 15 至 20 个 token。前向计算，就是模型接收当前状态并算出下一轮结果的完整过程。传统自回归模型的一次计算通常只向前推进一个 token；扩散式生成试图让一次计算同时确定更多位置。
官方还称，模型在单张 NVIDIA H100 上达到每秒 1000 个以上的输出 token。tok/s 就是模型每秒生成多少个文字片段。不过，这个数字不能直接理解为所有电脑都能获得相同速度。H100 是具体的测试硬件；实际表现还会受到实现方式和部署环境影响。现有供稿也没有提供统一条件下的第三方复测，因此这里更适合把它看作官方展示的技术上限，而不是普遍可复制的体验。
为什么这条路线值得关注
今天多数语言模型都沿着同一条生成路径竞争：继续逐词生成，再从模型、硬件或解码技巧上提速。DiffusionGemma 追问的是更靠前的问题：文字是否一定要按顺序一个个写出来。
如果分块并行修正能够兼顾输出质量，它就可能改变速度优化的着力点。但这种路线也带来新的权衡。模型不再只决定“下一个词是什么”，而要在多轮修正中协调一整块文字。速度、质量和实现复杂度需要一起评估，单看 tok/s 无法回答它是否已经胜过成熟的自回归方案。
社区部署也还在推进。截至发稿前复核，llama.cpp 的 PR #24423 与 PR #24427 均仍为 Draft，意味着相关支持尚在讨论和修改阶段，不能等同于已经合并的正式支持。Reddit 帖子中有人期待它在 8GB VRAM——也就是 8GB 显存——设备上获得更高 tok/s，但这只是个人期待，不是实测结论。
局限与未知
- 现有数字主要来自论文摘要这一单一来源，供稿没有提供独立复测，不能据此断言模型已经“更好”或在普通设备上同样“更快”。
- 材料没有给出质量基准、具体对比对象及误差案例，暂时无法判断并行修正是否会牺牲连贯性、准确性或指令遵循能力。
- llama.cpp 的两个实现仍处于 Draft。扩散式生成能否低成本进入常见本地工具链，仍要看后续工程整合与实际测试。
DiffusionGemma 目前更像一张清楚的路线图，而不是已经结束的比赛。它最有价值的地方，是把问题从“怎样让逐词生成再快一点”，推进到“语言模型是否必须逐词生成”。