1107 vs 303：谷歌这个开源模型，把大模型的“打字机”拆了

同一张 H100 显卡。同一个 26B 参数架构。303 那个还开启了多 token 预测加速。DiffusionGemma 跑出了 1107 token/s，是标准版 Gemma 4 的将近 4 倍。

我盯着这个数字看了很久。不是因为 1107 有多惊人——这个行业每周都有新纪录——而是因为 303 这个对比基线。谷歌没有拿它去碰 GPT-4o 或 Claude 4，而是直接对标自家 Gemma。这意味着什么？意味着它不是“更快一点点”，而是“换了一种生成方式”。

DiffusionGemma 不再一个 token 一个 token 往外蹦了。256 个 token，同时生成。

这个逻辑成立：自回归模型（GPT、Claude、DeepSeek 都用的范式）本质上是打字机。前一个 token 出来，才能算下一个。GPU 在大部分时间里处于“等结果”状态——算力利用率低，显存带宽浪费。本地跑模型时尤其明显，显卡有一半时间在空转。

换个角度看：DiffusionGemma 放弃了“逐字逐句”的因果约束，转而用扩散模型的方式同时生成一批 token。它不再是“下一个是什么”，而是“这一段应该长什么样”。区别在于，前者的瓶颈是串行等待，后者的瓶颈是并行拟合。

谷歌这次开源的是完全版：Apache 2.0 协议，权重、代码、训练脚本全给。没有“仅限研究”，没有“需申请访问”。对于本地部署玩家和边缘设备厂商来说，这可能是今年最值得关注的发布之一。

但问题从来不是“快不快”，而是“快的同时丢了多少东西”。

扩散模型在图像生成上已经证明了自己——Stable Diffusion、DALL·E 3、Midjourney 都是用扩散方式生成整张图像。但文本和图像有本质区别：图像的局部一致性容忍度高，像素块同时生成，人眼感知的是整体；文本的局部一致性要求高，“我今”后面如果同时生成“天”“吃”“饭”，这三个 token 之间必须严格互洽。否则会出现“我今天吃饭”和“我今吃天饭”的概率同时存在。

我的判断是：DiffusionGemma 在短文本、结构化输出、代码补全等场景可能表现优异；但在长文档、对话连贯性、逻辑推理等任务上，现在下结论为时尚早。256 个 token 同时生成，意味着模型必须在一个前馈步骤内同时解决 256 个预测任务，每个任务之间的依赖关系向量化压缩进一次计算。这需要极其高效的注意力机制和损失函数设计。

值得持续跟踪的是：谷歌论文中是否披露了与标准自回归模型在各类基准上的对比数据？——目前公开信息中这一点还比较模糊。如果 DiffusionGemma 在 MMLU、HumanEval、GSM8K 上的得分与 Gemma 4 持平，那这个模型的发布意义就不是“快 4 倍”，而是“快 4 倍的同时保持同等质量”。但如果质量有明显折损，它就更像是一个速度优先的特定场景优化方案。

另一个值得注意的细节：303 token/s 的基线版本开了多 token 预测加速。多 token 预测本身就是在标准自回归框架下的一种提速尝试——让模型一次预测多个未来 token，而不是一个。但即便是这个优化版本，也被 DiffusionGemma 甩下近 4 倍。这个数字说明的是：并行生成和因果生成之间的效率差距，靠修补和优化难以弥合。

对于本地部署者来说，1107 token/s 意味着什么？意味着在单卡 H100 上，你可以跑出接近 6000 token 的实时对话速度（按一次对话 5-6 个 token 输出计）。如果推广到消费级硬件——比如 RTX 4090——虽然绝对速度会大幅降低，但相对优势仍然可能保持 2-3 倍。对于需要低延迟响应的本地应用（代码补全、实时翻译、语音助手副脑），这可能是从“可用”到“好用”的临界点。

但我更关心的是另一个问题：扩散文本生成和自回归文本生成，到底在数学上存在怎样的根本差异？

自回归模型本质上是条件概率链：P(t1)P(t2|t1)…P(tn|t1…tn-1)。这是因果序列，信息流向是单向的。扩散模型在图像上用的是随机微分方程的逆过程——从高斯噪声逐步去噪到目标分布。谷歌这次的做法，应该是把文本 token 嵌入到一个连续空间中，然后在这个空间里做扩散，最后把去噪后的结果离散回 token。这从理论上看是可行的——文本的语义空间本身就有连续的流形结构——但挑战在于：离散 token 的“去噪”边界远比连续像素模糊。一个像素偏红 10% 和偏绿 10% 是连续变化；一个 token 从“吃”变成“喝”，语义边界是跳跃的。

这就是为什么我认为 DiffusionGemma 需要在论文中披露具体的失败案例分析。比如，在什么情况下它会产生语义上通顺但逻辑不连贯的连续 token？比如同时生成“他去了北京”和“他去了上海”的概率是否被有效压制？

谷歌这次的开源策略也值得对比。Meta 的 LLaMA 系列、Mistral、DeepSeek 等都在走“先闭源提质，再开源巩固生态”的路径。而谷歌这次是直接 Apache 2.0 开源，几乎没有限制。这和谷歌一贯的“大模型开源保守派”作风形成鲜明反差——之前 Gemma 系列虽然号称开源，但使用条款里包含了极其严苛的商业限制（月活用户超过 7 亿需单独申请）。这次 DiffusionGemma 的 Apache 2.0 是真正的“放出来”。

为什么突然这么大方？一个可能的猜测是：谷歌认为扩散文本生成这条路还处于早期，与其闭门造车，不如让整个社区一起试错、喂养数据、反馈问题。另一个则是：谷歌在自回归模型上已经落后 OpenAI 和 Anthropic 一个身位，所以在平行路线上做差异化卡位——就像当年 Android 用开源打 iOS 的闭环。

但风险同样存在：开源社区的力量能否在短期内解决扩散文本生成的固有缺陷？如果不能，那 DiffusionGemma 就会停留在“一个有趣的工程实验”层面；如果能，那它就是下一波本地模型热潮的催化剂。

这条路线还存在一个潜在的反直觉后果：更快的生成速度，未必带来更好的用户体验。

如果你是重度用户，你应该知道：很多时候模型的“慢”是有价值的。它让系统有机会做链式推理、搜索、反思、纠错。如果生成速度快了 4 倍，但缺乏有效的内置自纠机制，那它输出的错误也会以 4 倍的速度涌现。用户可能不会觉得“快真好”，而是觉得“快有什么用，错的概率也高了”。

更具体地说：在代码生成场景中，1300 token/s 但准确率 85% 的模型，和 400 token/s 但准确率 95% 的模型，哪个更有用？取决于场景。如果只是补全一行变量名或函数签名，前者更优；如果是生成一个复杂的排序算法核心逻辑，后者更容易一次通过编译。

我还没有看到 DiffusionGemma 在这些场景下的针对性评测。这在后续社区反哺中一定会被覆盖，但现在还是未知数。

谷歌在发布时强调了一点：DiffusionGemma 的训练和推理框架完全兼容现有的 Gemma 工具链。也就是说，如果你已经在用 Gemma 做微调、量化、部署，只需简单替换模型文件就能切换到 DiffusionGemma。这个设计很聪明——降低了采用成本，让社区可以快速验证效果。

从部署角度看，DiffusionGemma 的理论吞吐优势在批量推理和服务器端部署场景下会进一步放大。因为 256 个 token 同时生成，本质上等于在一个 batch 内并行处理多个预测任务。如果你的服务需要同时处理大量短请求（比如实时翻译、即时问答），这种方式可以显著降低延迟峰值。

但对于单个用户的流式交互，情况可能不同。自回归模型虽然慢，但输出是逐 token 流式出现的，用户感觉到的是“它在思考，然后逐步给出答案”。扩散模型一次性输出 256 个 token 块，用户可能会感知到“一段沉默，然后一段文字突然全部出现”。这种交互节奏的改变，在用户体验设计上需要重新适配——比如引入人工的流式模拟或渐进式显示。

我现在更关心的是：扩散文本生成的 scaling law 是怎样的？

自回归模型的性能随着模型参数和训练数据的增加而近乎确定性地提升。这是 LLaMA、GPT、Claude 等模型越做越大的根本驱动力。扩散模型在图像上也有类似经验——更大的模型、更多的去噪步骤，通常能产生更精细的图像。但文本扩散的 scaling 表现如何？如果 DiffusionGemma 在 2B、7B、26B 参数等不同规模下都保持了速度优势且质量稳定，那这个路径就值得系统性投入。如果只在特定规模下有效，那就更像一个工程 hack 而非理论突破。

谷歌目前只发布了 26B 版本。这个选择暗示了什么？26B 是中等偏大参数规模，既不算小模型（可以在消费级硬件上运行），也不算巨大模型（需要大规模集群推理）。选这个规模做首发，可能是为了平衡速度优势和硬件兼容性。后续如果出小模型版本（5B 或 8B），才能更清楚地看到参数规模和扩散生成效率之间的真实关系。

对比 Gemini 系列，Gemma 从来不是谷歌的旗舰模型。Gemma 是“为社区和开发者准备的开放模型”，Gemini 才是面向大客户和垂类应用的产品化模型。所以 DiffusionGemma 更像是一个“技术展示+生态试水”的组合——谷歌在表明：我们在文本生成范式的创新上没有落后，而且我们愿意开放给所有人验证。

但这篇分析如果想停在“谷歌牛逼”的层面，那就不符合我这个行业观察者的作风了。

真正的问题在于：DiffusionGemma 是否可能改变本地模型当前的格局？

当前本地部署的用户需求主要集中在这几个方向：一套代码补全的本地 Copilot、一个本地知识库问答系统、一个离线语音助手、一批特定任务的轻量级工具。这些场景对速度有要求，但对质量的容忍度也相对较高。DiffusionGemma 的高吞吐特征在这些场景下确实有吸引力——尤其是代码补全场景，生成速度快意味着开发者的工作流中断更少。

但还有另一个现实：现有本地模型的生态已经比较成熟。Llama.cpp、Ollama 等工具链支持几十种自回归模型，社区已经建立了大量微调脚本、量化方案和部署指南。DiffusionGemma 要切入这个生态，除了技术优势外，还需要工具链的快速适配。如果 ollama 或 llama.cpp 社区不能快速支持，那 DiffusionGemma 对于非技术用户来说就只是一个“跑在 H100 上的演示”。

谷歌显然意识到了这点。他们不仅开源了模型和权重，还一并发布了与 transformers 和 JAX 的兼容接口。这相当于给生态适配铺好了半条路。

但我这里需要做一个保守判断：即便 DiffusionGemma 在技术上有突破性，它的普及路径也不会是“替代”自回归模型，而是“补充”。 原因很简单：自回归模型的生态链太长，从训练框架到推理加速到应用层集成，每一个环节都有成熟的解决方案。扩散文本生成从原理上就和自回归不兼容，这意味着所有现有的推理优化技术（KV cache、speculative decoding、flash attention）在 DiffusionGemma 上要么不能直接用，要么需要重新设计等价物。这层迁移成本决定了 DiffusionGemma 短期内只可能在高吞吐需求明确且用户有技术能力的场景下率先落地。

更远一点说，如果 DiffusionGemma 证明了扩散文本生成可以在保持质量的前提下大幅提升速度，那整个行业的设计逻辑可能需要重新审视——不是“怎么让生成更快”，而是“生成更快之后，我们能用这多出来的算力带宽做什么”。

这个问题现在问还太早。