Gemma 4 与 DiffusionGemma：自回归、多 token 草拟和离散文本扩散

1. 证据边界：已经发布什么，仍缺什么

本页把三种速度来源分开：Gemma 4 的 MoE 通过少量 active experts 减少计算；MTP 通过草拟并验证多个 token 减少目标模型串行步数；DiffusionGemma 通过并行更新 token block 改变生成本身的依赖图。它们不可用一个“更快”概括。

2. Gemma 4 的 2026 发布序列：同一名字下实际增加了什么

Gemma 4 的架构、MTP、Unified 多模态和 QAT 资料并非同一天公开。复现实验应记录对应的 model revision、drafter 与量化产物，不能把不同日期的材料当作同一个固定快照。

3. 前置：自回归为何天然串行

普通 decoder-only LLM 把序列概率分解为条件概率乘积。训练时可以用 teacher forcing 并行计算所有位置，推理时第 t+1 个 token 必须等待第 t 个 token 被采样并写入 KV cache。

当 batch 很小，单步 decode 常受权重读取与 kernel launch 限制：每产出一个 token 都要流过大部分目标模型。MoE 降低每步激活计算，MTP 尝试让一次目标模型验证多个候选，文本扩散则允许多个位置在同一轮一起改变。

4. Gemma 4 家族：五种资源与模态取舍

26B-A4B 的 A4B 表示一次前向大约激活 4B 参数，但所有 26B 权重仍需加载或可访问。E2B/E4B 的 PLE 则是每个 decoder layer 持有自己的 embedding table，解释了 effective 参数与实际权重加载量不同。两者都不能只用标题里的“B”来估设备容量。

5. 共同骨架：hybrid local/global attention、统一 KV 与 PLE

Gemma 4 model card 描述的是 local sliding-window attention 与 global full attention 交替，最后一层固定为 global，而非全层都用 full attention。global layer 使用 unified K/V 与 p-RoPE；模型因此无需在每层支付同样的全局 KV 读取成本，但 global 层仍需要完整历史的高质量状态。

E2B/E4B 的 Per-Layer Embeddings（PLE）进一步说明参数命名不等于常规 weight table：每层拥有独立 embedding table，所以 2.3B/4.5B 的 effective parameter 数与包含 embedding 的实际加载量不同。部署显存表使用的是实际需要加载的权重，而不是一个抽象的“effective B”。

6. encoder-free multimodal：输入怎样进入同一主干

传统视觉语言模型常使用独立 vision encoder，把图像压成视觉 token 后再喂给语言模型。Gemma 4 12B 的 Unified encoder-free 路线更直接：把原始图像 patch 和音频 waveform 分块，通过轻量线性投影映射到主干所需的表示空间，与文本 token 共同进入统一 Transformer。

取消大型独立 encoder 可以减少组件和模态边界，但也把更多跨模态建模压力放进统一主干。部署时仍要运行图像切 patch、音频分块、归一化与投影算子；“encoder-free”不等于输入预处理为零。

7. Gemma 4 的注意力、MoE 与显存账本

dense 31B 每个 token 使用所有相关层权重；26B-A4B 由 router 为 token 选择少量 experts。MoE 层通常包含 router logits、top-k、dispatch、expert GEMM 和 combine。单卡可容纳时可本地完成；跨卡 expert parallel 时则需要 all-to-all，并面对热门 expert 的负载倾斜。

Gemma 4 的 128K/256K context 同样需要 KV cache。权重能装入 GPU 只完成第一步；要支持多会话，还需为 KV、activations、MTP 验证 batch 和运行时 workspace 预留 HBM。

8. 官方权重显存表应该怎样使用

Google 文档给出仅权重的加载估算，已经包含 20% loading overhead，但明确不包括 KV cache 和其他 runtime memory：

例如“Q4 26B-A4B 为 14.4 GB”不能推出 16 GB GPU 一定能跑 256K：模型加载后只余约 1.6 GB，而 KV、CUDA/Metal buffer、输入图像和临时 activation 都要占空间。应该先按真实 context 与并发测峰值，再决定 offload 或多卡切分。

9. QAT、PTQ 与文件后缀不是一回事

post-training quantization（PTQ）在训练完成后根据权重或校准数据做量化；quantization-aware training（QAT）在训练或微调阶段模拟低精度误差，让模型学习适应量化。相同“4-bit”标签下，量化粒度、scale、zero point、激活精度与 kernel 支持都可能不同。

Gemma 4 的 QAT 发布进一步公开 Q4_0 / mobile 路线：static activations、channel-wise quantization、针对 decode 的 2-bit 处理以及 embedding/KV compression。它们的共同目标是把误差处理放进训练阶段，而不是在导出时才发现某层无法低比特表达；但每个产物依旧要求相应 runtime kernel 支持。

Gemma 文档为不同量化产物使用明确后缀。部署时应匹配官方 checkpoint 的实际格式与引擎 kernel，而不是只按文件名中的位数估算速度。模型体积下降不保证算得更快：若硬件没有对应低精度 GEMM，runtime 可能先反量化，节省 HBM 却增加算子开销；KV compression 也必须单独做长上下文质量与峰值显存验证。

10. Gemma 4 的专用 MTP drafter 怎样工作

Gemma 4 各变体配有专用多 token prediction drafter。它是轻量四层 assistant，复用目标模型的 input embeddings，并读取目标模型最后一层 activations。E2B/E4B 还使用面向效率的 clustered vocabulary。

这仍是 speculative decoding：最终接受概率由目标 Gemma 4 决定，因此正确实现可保持目标分布。它与 DiffusionGemma 的根本差异是，MTP 只加速自回归目标模型；扩散模型自身就以多位置迭代更新为生成过程。

11. MTP 的算子、batch 与 MoE 限制

drafter 增加四层小模型的 GEMM 和 sampling，verification 把多个候选位置组成一个短 prefill。若一次接受多个 token，减少的目标模型串行 decode 步足以覆盖这些额外成本；若经常第一个 token 就拒绝，drafter 和验证反而增加延迟。

官方特别提醒：MoE 在 batch=1 时未必因为 active parameters 较少就明显加速，因为完整 expert 权重的加载/访问和路由开销仍在。MTP 也有类似硬件依赖：小 batch、memory-bound decode 通常更有空间；高 batch 已经把 GPU GEMM 利用率拉高后，额外 drafter 和验证 batch 的收益会变化。

12. DiffusionGemma：离散文本扩散到底是什么

连续图像扩散在噪声空间逐步去噪；离散文本扩散在 token 空间对被 mask、随机化或尚未确定的位置反复预测。DiffusionGemma 可以在一次 forward 中并行处理一块最多 256 个 token，再通过多轮更新逐渐锁定或修正这些位置。

双向 attention 让一个待填位置同时利用左右文，因此适合 inline editing、code infill 和 Sudoku 这类“答案中间也需要看右侧约束”的任务。自回归模型也能通过重排 prompt 或专门 infill objective 做这些任务，但其标准 left-to-right decode 依赖不同。

13. 为什么并行 256 token 不等于一步生成 256 个正确 token

一次 forward 可以为 256 个位置输出分布，但扩散生成通常要多轮 refinement。若生成 256 token 需要 S 个扩散步，串行临界路径约为 S 次大模型 forward，而不是 256 次；速度优势取决于 S、每轮保留比例、kernel 利用率和质量要求。

模型可以在后续轮次修改早先的低置信度 token，这就是官方所说的 self-correction 能力。但“能改”不等于一定改对；采样步数太少会伤质量，步数太多会吞掉速度优势。

14. DiffusionGemma 的模型与官方性能数字

官方同时明确：DiffusionGemma 的质量低于标准 Gemma 4。它的价值主张是本地/低到中等 batch 的高并行生成与可编辑性，而不是在每项质量指标上替代自回归 Gemma 4。

15. 一个代码补全例子：两种生成器怎样不同

已有代码：
def normalize(xs):
    <HOLE>
    return [x / total for x in xs]

自回归模型：把前缀、后缀按 infill 模板重排，随后从 hole 左端向右生成。
DiffusionGemma：把 hole 表示为一块待定 token；每轮所有位置都能看到
左侧函数签名和右侧 return，并可修改先前低置信度位置。

第一轮可能同时猜出 total、sum、异常处理等多个片段；后续轮次发现右侧使用 total 后，修正变量名和控制流。这个例子解释结构能力，不代表模型一定生成某段具体代码。可靠评测仍需编译、单元测试和相同延迟预算。

16. 服务层：什么时候扩散更合适，什么时候自回归更合适

Apple unified memory 也不保证复现独立 GPU 的同等加速，因为带宽、kernel、量化格式和调度不同。部署决策应以目标设备的端到端测量为准。

17. 部署：从单机验证到推理服务

DiffusionGemma 发布时提供 Hugging Face Transformers、vLLM、MLX 和 NVIDIA NVFP4 等生态路径，许可为 Apache 2.0。发布公告把 llama.cpp 支持写为“即将到来”，因此不能用这条发布时表述断言当前任意 llama.cpp 版本已经完整支持；应核对具体 release。

1. 选择确切模型与量化 checkpoint，记录 revision 和许可证。
2. Gemma 4 验证 chat template、multimodal preprocessing 与 MTP drafter 配对；不要混用不匹配的 assistant。
3. DiffusionGemma 固定 block size、扩散步数、置信度/重采样 schedule 与随机种子。
4. 记录权重常驻、峰值显存、TTFT、稳定首段延迟、tokens/s、能耗和质量。
5. 服务测试同时覆盖 batch=1、连续 batching 和实际并发；不要只跑一个理想的 256-token microbenchmark。
6. multimodal 请求额外测图像分辨率、音频长度、视频帧数和预处理时间。

18. 局限与尚未公开的部分

• DiffusionGemma 是实验性发布，官方明确质量低于标准 Gemma 4。
• “最高 4×”、H100 1,000+ tok/s、RTX 5090 700+ tok/s 都是条件性测量，不是跨环境保证。
• 离散扩散会多轮重算 token block，速度与质量由采样 schedule 共同决定。
• MoE 的 3.8B/4B active 降低计算，不等于只加载这些 active 权重。
• 官方权重显存表不含 KV 和 runtime；不能直接当成最低设备内存。
• encoder-free 仍有 patch/waveform 预处理与投影，视频支持按帧实现，不等于专用时空视频 encoder。
• 公开材料不足以独立复现完整预训练和 post-training 的数据、成本与所有超参数。

19. 最小复现与验证清单

1. 固定模型 revision、tokenizer、processor、推理引擎、kernel 和量化格式。
2. Gemma 4 分别关闭/开启 MTP，报告 acceptance length、TPOT、峰值显存和输出分布一致性。
3. DiffusionGemma 扫描扩散步数与 block size，绘制质量—延迟 Pareto 曲线，而非只选最快点。
4. 在相同硬件、相同 prompt、相同输出长度和相近质量下比较 AR 与 diffusion。
5. 分别测 batch=1、低并发和高并发；记录 prefill 与 generation，不把预处理时间藏掉。
6. multimodal 测试保留原图/音频参数，并检查 processor 是否发生静默 resize、截断或抽帧。
7. 代码任务使用编译和测试结果，编辑任务检查约束保持，不能只用主观可读性。

20. 一手来源