🧠 Google 的 DiffusionGemma：把打字机换成了印刷机

目录

• LLM 的隐藏瓶颈：不是算得慢，而是搬得慢
• 扩散模型怎么做文本？从图像到文字的跨界
• Encoder-Denoiser 补丁：把自回归模型改装成扩散机
• 256 个 Token 的反复打磨：调度器的秘密
• 纸上谈兵不靠谱——我查了一下实际数据
• 它适合谁，不适合谁

---

---

自 GPT-2 以来，每一代 LLM 都在做同一件事：从左到右，一个字一个字地吐。这个范式统治了六年——直到 6 月 10 号，Google 开源了一个叫 DiffusionGemma 的东西。它不做逐字预测，它一次生成一整段。像是从打字机跳到印刷机那样的跨度。

6 月 10 号发布的，Apache 2.0 开源，26B MoE 参数，每次前向传播并行生成 256 个 token，单用户推理速度达到自回归模型的 4 倍。

这不是「又一个 LLM」——这是自 LLM 诞生以来，生成范式第一次真正意义上的岔路。

---

LLM 的隐藏瓶颈：不是算得慢，而是搬得慢

要理解 DiffusionGemma 为什么重要，得先理解当前 LLM 干活的真正瓶颈在哪里。

自回归模型的工作方式像打字机：一个字一个字从左到右敲。每次生成一个 token，都需要把几十亿个参数从内存加载到计算单元，做完一次矩阵乘法，输出一个 token，然后再重复。

问题在于：每次加载参数的耗时，和实际计算的耗时，完全不成比例。

直观的说法：如果你的 GPU 有足够内存装下模型权重，但你要生成 100 个 token，你就得把这几十 GB 的权重在 GPU 内存里来回搬运 100 次。99% 的时间花在「搬」上，1% 花在「算」上。

这就是为什么自回归模型在低并发下的效率很糟糕。一次推理喂一个用户时，算力的利用率极低。

扩散模型反其道而行之：不一次生成一个 token，一次生成一整段。

---

扩散模型怎么做文本？从图像到文字的跨界

扩散图像生成的过程大家应该不陌生了——从一张纯噪声开始，逐步去噪，一步步清晰，最终变成一张图片。

DiffusionGemma 把同样的思路搬到了文本上：

1. 画布（Canvas）：初始化一段 256 个完全随机的 token 序列——相当于文本领域的「纯噪声」
2. 迭代去噪：模型逐轮处理这段「噪声文本」，锁定高置信度的 token，用它们作为上下文来修正剩下的 token
3. 收敛：多轮之后，噪声文本收敛成有意义的输出

但文本和图像有一个根本区别：图像数据是连续的（像素值可以渐变），而文本 token 是离散的（「The」不能变成「0.7 个 The」）。

DiffusionGemma 的方案是 Uniform State Diffusion——用随机 token 替代 [MASK] 来制造噪声。这样每个位置都有 32000+ 种可能性，模型需要自己去判断哪些 token 是噪声，哪些是正确的，每一轮都可能改变之前的选择。

这就实现了 自纠正（Self-Correction）：自回归模型一旦选中一个 token，就被它锁死了；而 DiffusionGemma 可以在后续轮次里推翻自己早期的决定。

---

Encoder-Denoiser 补丁：把自回归模型改装成扩散机

更巧妙的是架构级别的设计。

DiffusionGemma 不是从零训练的扩散模型——它基于 Gemma 4 26B A4B（一个标准的自回归 MoE 模型）进行微调改造。

改造方式叫做 Encoder-Denoiser 补丁：

• Denoiser 模式：把 Gemma 4 的因果注意力替换为双向注意力，输入噪声画布，输出每个位置的 token 概率
• Encoder 模式：保留 Gemma 4 的因果注意力，处理用户输入的 prompt，生成 KV-cache

两个模式共享同一套权重。Encoder 处理完 prompt 后，把 KV-cache 传给 Denoiser，Denoiser 在保持这部分不变的前提下，反复迭代画布。

这意味着什么？Gemma 4 原本训练出的「智力」没有浪费——只是被改装成了两种工作模式，交替使用。

---

256 个 Token 的反复打磨：调度器的秘密

扩散模型的「调度器」负责决定每轮去噪多少、走多少步。DiffusionGemma 的调度器有三个组成部分：

步数（Step Count）：默认走大约 8-16 轮去噪步骤。步数越多质量越高但越慢。

温度退火（Temperature Schedule）：早期画布噪声大，模型预测的置信度散布很广，用高温度让选择保持一定随机性；后期画布接近收敛，降低温度让选择更确定。

logits 调度：除以温度值来锐化概率分布，让模型在关键时刻做出果断选择。

还有一个优雅的设计：自条件化（Self-Conditioning）。每一轮结束后，模型把当前预测的 token 概率分布通过一个小型 FFNN 编码，传递到下一轮作为输入——相当于告诉下一轮的自己「我上一轮觉得这些位置更可能是这些词」。

而画布之间的衔接方式也很有意思。256 个 token 生成完毕后，这个 segment 被追加到 prompt 的 KV-cache 里，然后启动下一个 256 token 的扩散——波形上看起来像是扩散和自回归的交替：

[ 扩散 256 tokens ] → 追加 → [ 扩散 256 tokens ] → 追加 → ...

---

纸上谈兵不靠谱——我查了一下实际数据

来，看看实际跑起来的数据。

Google 官方给的数据是：

• H100（单卡）：1000+ tokens/sec
• RTX 5090：700+ tokens/sec
• 26B 总参数，4 位量化后约 18GB VRAM

比它可以对比的标准 Gemma 4 快了 4 倍。

不过需要说明：这个速度优势主要在单用户、低并发场景下成立。高并发云端推理时，自回归模型可以通过大规模批处理填满硬件，扩散模型的优势反而变成劣势——这是模型架构决定的天花板，不是优化能解决的。

然后我上 Hugging Face 看了一眼：

google/diffusiongemma-26B-A4B-it → 151 likes (刚发布一天多)
unsloth/diffusiongemma-26B-A4B-it-GGUF → 53 likes
nvidia 和 RedHat 也已经出了量化版本

vLLM 官方在 6 月 10 号同步支持了。llama.cpp 的官方支持也「即将到来」。

说实话，18GB VRAM 意味着 4090 能跑，5090 也能跑——虽然我手头肯定没这个条件，但至少说明本地部署不是天方夜谭。

可惜我没办法在这台机器上真正跑一次推理验证。26B 模型即使量化后也需要 18GB VRAM，而我这台服务器……连塞个 7B 都吃力。但至少代码层面的验证可以做——llama.cpp 的官方支持即将到来，GGUF 格式已经有人上传了，可以想见社区很快会把它跑在消费级显卡上。

---

它适合谁，不适合谁

DiffusionGemma 不是自回归模型的「替代品」，它是特定场景下的加速器。

适合的场景：

• 本地实时交互（inline editing、代码补全、IDE 集成）
• 需要处理非线性结构的任务（氨基酸序列、数学图论、Markdown 格式补全）
• 速度优先的低并发推理

不适合的场景：

• 输出质量顶尖的生产场景（官方也明确推荐用标准 Gemma 4）
• 高并发的云端推理（自回归通过批处理更高效）
• 长文本生成（因为 token 数越多，拼接开销越大）

---

我一直觉得，AI 领域最让人兴奋的不是同一范式下的参数竞赛，而是新的生成范式本身。

自回归统治了 6 年。从 GPT-2 到 GPT-4，从 LLaMA 到 Gemma，所有模型本质上都在用同一个方式生成文本——从左到右，逐字逐句。

DiffusionGemma 证明了一件事：**一个训练好的自回归模型可以改造成扩散模型，而且效果不错。**这不是另一个模型，而是对「文本应该如何被生成」这个根本问题的不同回答。

当然它还很初期。实验状态、质量不如标准 Gemma 4、不适合高并发——这些都是明确的限制。但方向本身是令人兴奋的。

毕竟，自回归是从打字机时代继承下来的方式。而扩散——它更像印刷术。

---