⚡ DiffusionGemma深度拆解：从逐字蹦到整块喷，LLM生成范式的结构性跃迁

> 模型发布：2026年6月10日，Google DeepMind，Apache 2.0 > > Hugging Face：google/diffusiongemma-26B-A4B-it

---

🔥 一句话总结

DiffusionGemma 不是「更快的自回归模型」，而是 彻底换了生成范式——从 GPT 的「逐字蹦」变成 Stable Diffusion 的「整块喷」。它用 256-token 画布 + 双向注意力 + 迭代去噪，在 H100 上跑出 1100+ token/s（4x 于同参数 AR 模型），代价是 benchmark 上比 Gemma 4 低 5-20 分。这不是简单的加速补丁，而是 把 LLM 从 memory-bound 变成 compute-bound 的结构性手术。

---

🎯 核心问题：为什么自回归 LLM 越跑越快，但「快」有个天花板？

自回归的物理瓶颈

所有 GPT、Claude、Gemma 都属于 自回归（Autoregressive, AR） 家族。它们的生成方式很简单：

Token 1 → Token 2 → Token 3 → ... → Token N
     ↑        ↑        ↑
   每个新token必须等前一个算完

这个「等」字，是性能杀手。

AR 模型的推理成本 = Prefill（处理 prompt）+ Decode（生成输出）。其中 decode 阶段是逐个串行的：

问题	原因	后果
Memory-bound	每个 token 的 KV cache 都要读/写，带宽成为瓶颈	GPU 算力闲置，内存带宽跑满
无法并行	第 N 个 token 依赖第 N-1 个	256 个 token 需要 256 次前向传递
注意力计算冗余	每次都要重新计算所有历史 token 的 attention	长上下文下 quadratic cost 爆炸

理论上，AR 模型的 decode 速度有个硬上限：受限于 GPU 内存带宽和串行依赖，无法通过简单优化突破。

扩散模型的图像生成启示

Stable Diffusion 告诉我们另一件事：从纯噪声开始，迭代去噪，一次生成整张图。这里的关键是「并行」——所有像素同时被优化，而不是逐个画出。

文本能否复制这个思路？这就是 DiffusionGemma 的核心问题：文本不是图像，token 之间有严格的时序和语法依赖，「并行生成」如何保证连贯性？

---

🧠 架构解剖：Encoder-Decoder + Block-Autoregressive Diffusion

DiffusionGemma 不是「把 Gemma 4 改成扩散模型」，而是基于 Gemma 4 的 MoE backbone，重新设计了生成头部。

整体架构

输入（Text/Image/Video）
    ↓
┌────────────────────────────────────────┐
│  Encoder（自回归编码器）                  │
│  - 处理 prompt，生成 KV cache            │
│  - 标准因果注意力                        │
│  - 26B MoE, 3.8B active                  │
└────────────────────────────────────────┘
    ↓ KV cache
┌────────────────────────────────────────┐
│  Decoder（扩散解码器）★                   │
│  - 双向注意力（非因果）                    │
│  - 256-token canvas                      │
│  - 迭代去噪：T steps                     │
│  - 每次 step 并行处理所有 256 个位置       │
└────────────────────────────────────────┘
    ↓
输出文本

关键设计决策

#### 1. Block-Autoregressive：块内并行，块间串行

DiffusionGemma 不是一次性生成整个 256K 上下文，而是每 256 个 token 为一个 canvas：

Prompt → [Canvas 1: 256 tokens] → [Canvas 2: 256 tokens] → ...
              ↑ 并行去噪 10-48 steps           ↑ 依赖 Canvas 1 的 KV cache

块内：256 个 token 通过 T 步迭代去噪同时生成（双向注意力）
块间：canvas 之间是串行的，当前 canvas 生成完后被编码器处理，加入 KV cache，下一个 canvas 在此基础上继续

这平衡了「并行度」和「长程一致性」：块内充分利用并行，块间保持自回归的稳定性。

#### 2. 双向注意力：BERT 的遗产

Decoder 使用双向注意力（非因果），这意味着每个位置可以看到 canvas 内所有其他位置——包括「未来」的 token。这是 DiffusionGemma 与 GPT 的核心区别：

特性	GPT（AR）	DiffusionGemma（扩散）
注意力方向	只能看左边	双向看整个 canvas
生成方式	逐个预测	整体去噪
推理速度	内存瓶颈	计算瓶颈
适合场景	通用对话	代码填充、结构化输出

双向注意力的代价是无法做 KV cache 增量复用——每个 canvas 都要重新计算所有位置的 KV，这是 DiffusionGemma 的架构性 trade-off。

#### 3. MoE 效率：128 专家，8 活跃

基于 Gemma 4 的 MoE backbone：

总参数 26B，活跃参数 3.8B
128 个 fine-grained expert + 1 个 shared expert
每个 token 路由到 top-8 个专家

这让模型在保持推理成本可控的同时，拥有接近 26B dense 模型的表达能力。3.8B 活跃参数意味着：

BF16：~52GB VRAM（需要 H100 或 RTX PRO 6000）
NVFP4（4-bit）：~18GB VRAM（RTX 4090 可跑）
INT8：~28GB VRAM（L40S 可跑）

#### 4. 统一状态扩散（Unified State Diffusion）vs 掩码扩散

DiffusionGemma 使用统一状态扩散（而非掩码扩散）：

掩码扩散（如 LLaDA）：token 要么已知要么被掩码，去噪过程是「逐步揭示」
统一状态扩散：所有 token 初始为纯噪声/随机状态，通过迭代双向优化，逐渐收敛到有效文本

这个设计更接近图像扩散的直觉：从一个「噪声画布」开始，每次迭代都改进所有位置，而不是简单地把 [MASK] 替换成真实 token。

---

📊 性能数据：速度 vs 质量的残酷 trade-off

速度表现

配置	Token/s	对比基准
H100 FP8, batch=1	1,100+	4x Gemma 4 AR
H100 FP8, batch=4	~2,800	15x Gemma 4 AR
RTX 5090, batch=1	700+	—
L40S INT8, batch=1, T=10	~480	~7x Gemma 4 AR
L40S INT8, batch=4, T=10	~1,400	—

关键洞察：DiffusionGemma 的优势在小 batch 低延迟场景最突出。当 batch size > 32 时，AR 模型通过 KV cache 复用会反超——因为 DiffusionGemma 的双向注意力无法做增量缓存。

质量表现（Benchmark）

Google 官方数据（DiffusionGemma vs Gemma 2.0 Flash-Lite）：

基准	DiffusionGemma	Gemma 2.0 Flash-Lite	Gap
Code LiveCodeBench	30.9%	28.5%	+2.4% ✅
Code BigCodeBench	45.4%	45.8%	-0.4%
Code HumanEval	89.6%	90.2%	-0.6%
Science GPQA Diamond	40.4%	56.5%	-16.1% ⚠️
Math AIME 2025	23.3%	20.0%	+3.3% ✅
Reasoning BIG-Bench Hard	15.0%	21.0%	-6.0% ⚠️
Multilingual Global MMLU	69.1%	79.0%	-9.9% ⚠️

结论：

代码任务：基本打平甚至略优（LiveCodeBench、AIME 数学）
科学推理：显著落后（GPQA -16.1%）
多语言/通用知识：差距明显（MMLU -9.9%）
Google 自己承认：在所有公开基准上，DiffusionGemma 低于标准 Gemma 4

为什么质量会掉？

1. 扩散过程的信息损失：每次迭代都有噪声，T 步去噪过程中累积误差 2. 双向注意力的「过度自由」：每个位置能看到所有位置，但长程依赖不如 AR 的链式传播稳定 3. Block 边界的拼接问题：256-token canvas 之间的过渡可能不如 AR 平滑 4. 训练目标不匹配：扩散训练优化的是「去噪」，而 benchmark 评估的是「最终文本质量」，两者不完全对齐

---

🔬 部署实测：Better Stack 的视频验证

视频作者做了两个实际测试：

测试1：个人财务仪表板（代码生成）

任务：构建一个功能完整的财务仪表板
结果：DiffusionGemma 生成了可工作的代码，但比 AR 模型有更多的「小错误」需要手动修复
速度体验：整块代码瞬间出现，而不是逐行「打字」——用户体验完全不同

测试2：街机风格游戏（复杂代码）

任务：构建一个功能完整的街机游戏
结果：核心逻辑正确，但边界处理、细节打磨不如 AR 模型
观察：扩散模型的「全局规划」能力似乎更适合架构级代码，但精细实现仍有差距

实测性能（H100 via RunPod）

场景	实测 Token/s	备注
短代码片段	~800-1000	接近理论值
长文档生成	~600-800	canvas 拼接 overhead
多轮对话	~400-600	每轮都要重新编码 context

---

💡 为什么 DiffusionGemma 值得重视

1. 范式转移：从 Memory-Bound 到 Compute-Bound

这是 DiffusionGemma 最深远的意义。AR 模型是内存带宽瓶颈——GPU 算力空闲，内存总线跑满。扩散模型是计算瓶颈——每个 step 都要做完整的 256-token 前向计算，算力被充分利用。

这个转变意味着：

未来 GPU 设计会更关注 FLOPS 而不是内存带宽
量化收益：AR 模型量化主要省内存，扩散模型量化省计算——收益更直接
推理成本模型：AR 的 cost ∝ 输出长度，扩散的 cost ∝ 输出长度 × 去噪步数

2. 代码填充的结构性优势

双向注意力让 DiffusionGemma 在「fill-in-the-middle」（FIM）任务上有天然优势：

# 给定前缀和后缀，填充中间
prefix = "def calculate_"
suffix = "return result"
# AR 模型只能从左到右，无法利用后缀信息
# DiffusionGemma 双向注意力，前后信息同时利用

Google 演示的 Sudoku 任务（从 0% 到 80% 准确率）正是利用了这个特性：约束条件从所有方向同时传播。

3. 开源生态的催化效应

Apache 2.0 + Hugging Face 开放权重意味着：

任何人可以 fine-tune 自己的领域适配版本
可以研究「为什么扩散模型在代码上不错但在推理上掉分」
可以探索混合架构：AR 做前缀，扩散做生成
llama.cpp 已经支持（需要专用分支），消费级 GPU 可跑

4. 本地 AI 的加速

DiffusionGemma 在 RTX 5090 上跑 700+ token/s，在 RTX 4090（NVFP4）上也可运行。这意味着消费级 GPU 上的本地 LLM 第一次达到「肉眼不可感知」的生成速度——对于本地 Agent、代码助手、隐私敏感场景，这是质变。

---

⚠️ 局限与开放问题

1. 质量-速度的帕累托前沿

当前 DiffusionGemma 在帕累托曲线上选择了「速度」端：

10 steps：快但质量差
20 steps：平衡点
48 steps：质量接近 AR 但速度优势缩小

是否存在一个「 sweet spot」让两者兼得？可能需要更大的模型或更好的训练策略。

2. 长文档连贯性

Block-autoregressive 的 canvas 边界是潜在问题。256 token 的 block 在学术论文、长篇小说等场景中可能产生「拼接感」。需要更长的 canvas（512/1024）或更平滑的过渡机制。

3. 实时对话的延迟

AR 模型的「逐字输出」给了用户「模型在思考」的心理反馈。DiffusionGemma 的「整块喷出」可能让用户感觉「等待时间更长」（虽然总时间更短）。UX 设计需要适配。

4. KV Cache 的增量复用

DiffusionGemma 的双向注意力无法做 vLLM 式的 prefix caching。这意味着多轮对话中每轮都要重新编码整个 context，长对话的效率可能不如 AR。

5. 训练数据截止

训练数据截止 2025 年 1 月，没有音频输入（Gemma 4 12B 支持），这是产品化差距。

---

📚 参考资源

DiffusionGemma Hugging Face：https://huggingface.co/google/diffusiongemma-26B-A4B-it
Gemini Diffusion（封闭版）：https://deepmind.google/models/gemini-diffusion/
vLLM 部署指南：https://recipes.vllm.ai/Google/diffusiongemma-26B-A4B-it
NVIDIA NIM 文档：https://docs.api.nvidia.com/nim/reference/diffusiongemma-26b-a4b-it
Awesome Agents 分析：https://awesomeagents.ai/models/diffusiongemma-26b/
Spheron 部署指南：https://www.spheron.network/blog/deploy-diffusiongemma-gpu-cloud/
ModelScope GGUF：https://modelscope.cn/models/unsloth/diffusiongemma-26B-A4B-it-GGUF
原视频：https://www.youtube.com/watch?v=Dxn3BcSgsMY

扩散语言模型时间线

时间	模型	规模	意义
2024	SEDD（Stanford）	学术	离散扩散理论基础
2025	LLaDA	8B	缩小与 AR 的 MMLU 差距到 ~5pt
2025	Mercury（Inception Labs）	商业	737-1109 tok/s on H100，代码聚焦
2025	Gemini Diffusion	封闭	Google 内部验证
2026.6	DiffusionGemma	26B MoE	首个开源大规模 DLM

---

#DiffusionGemma #GoogleDeepMind #扩散模型 #文本生成 #LLM推理加速 #Gemma4 #MoE #双向注意力 #代码生成 #本地AI #开源模型 #AI基础设施