DiffusionGemma: 首个在 vLLM 中获得原生支持的 Diffusion LLM

vLLM 已集成 DiffusionGemma，这是一个基于 Gemma4 骨干网络构建的 26B 参数离散扩散语言模型。此次集成标志着 vLLM 首次原生支持扩散语言模型 (dLLM)，实现了从顺序 Token 生成向迭代式块细化的转变，从而显著降低了低 Batch Size 下的延迟。

DiffusionGemma 架构与解码

DiffusionGemma 取代了标准的自回归解码（即从左到右逐个生成 Token），转而采用一种迭代对长度为 256 个 Token 的固定画布进行去噪的过程。这种方法通过增加计算量来缓解内存带宽压力，允许模型在多个去噪步骤中并行细化多个 Token。

双模式运行

DiffusionGemma 使用同一套权重在两种不同的模式下运行：

• Encoder Mode (编码器模式): 采用因果注意力 (causal attention) 来预填充 Prompt，并将完成的块“提交”到 KV cache 中。
• Decoder Mode (解码器模式): 采用双向注意力 (bidirectional attention)，允许画布中的每个位置都能关注到其他所有位置，从而实现同步细化。

由于编码器模式使用标准的因果注意力，vLLM 的自动前缀缓存 (automatic prefix caching) 保持兼容，无需修改即可工作。

采样循环与熵界去噪

生成过程以 256 个 Token 为一个块进行。在 Prompt 预填充后，画布会用随机 Token 进行初始化。随后模型进入去噪循环，在每个位置采样候选 Token。

为了确定保留哪些 Token，DiffusionGemma 使用了熵界 (entropy-bound) 规则：它按置信度从高到低的顺序接受 Token，直到累积熵超过预设预算。一旦画布收敛（定义为 argmax 预测在连续几步内保持稳定，且每个 Token 的平均熵低于阈值，或达到步数限制），Token 就会通过一次编码器传递进行提交，然后为下一个块重复此过程。

用于稳定性的自我调节 (Self-Conditioning)

为了加速收敛并提高稳定性，模型使用了自我调节 (self-conditioning)。在去噪步骤之间，模型会基于其前一次预测的完整 Softmax 分布进行调节。该分布被转换为 Token Embedding 的概率加权平均值，并通过一个门控 MLP 添加到画布 Embedding 中，为模型提供其先前信念的记忆。

vLLM 实现细节

集成 DiffusionGemma 需要支持非自回归解码模式。vLLM 通过利用多个架构抽象实现了这一点：

投机解码数据路径

vLLM 复用了其现有的投机解码 (speculative decoding) 路径，将当前画布视为一组草稿 Token (draft tokens)，这些 Token 要么被完全拒绝，要么被完全接受。这使得团队能够以极小的改动维持核心调度器和模型运行器。

ModelState 接口

为了避免分叉 (forking) 模型运行器，vLLM 利用了 ModelState 抽象。它提供了钩子 (hooks)，允许 DiffusionGemma 在不改变通用运行器的情况下定义自定义行为：

钩子	在 DiffusionGemma 中的用途
prepare_inputs()	处理画布 Embedding 和自我调节的应用。
prepare_attn()	根据每个请求在因果注意力 (encoder) 和双向注意力 (denoise) 之间切换。
custom_sampler()	安装 DiffusionSampler 以取代默认采样器。
add_request() / remove_request()	管理每个请求的扩散状态生命周期 (画布、概率)。

动态单序列因果注意力

由于单个 Batch 可能包含处于不同阶段（预填充、去噪、提交）的请求，vLLM 实现了动态单序列因果注意力 (dynamic per-sequence causal attention)。这使得注意力掩码 (attention mask) 能够适应每个请求的具体因果需求。该功能在 Triton Attention (TRITON_ATTN) 和 FlashAttention 4 (FLASH_ATTN) 后端中均得到支持。

对称滑动窗口注意力

对于使用滑动窗口注意力的层，DiffusionGemma 在去噪阶段需要对称窗口。而因果请求使用单侧窗口（关注之前的 $W$ 个 Token），双向请求则关注两侧各 $W$ 个 Token，总窗口大小为 $2W + 1$。

性能与量化

吞吐量结果

DiffusionGemma 的架构实现了极低的推理延迟。在单 GPU 上以 Batch Size 1 进行的基准测试显示，其吞吐量较自回归基准有显著提升：

• H200 (FP8): 每秒生成 1,288 个 Token（约为标准自回归基准的 ~6 倍，约为多 Token 预测的 ~3 倍）。
• H100 (FP8): 每秒生成 1,008 个 Token（约为标准自回归基准的 ~5 倍，约为多 Token 预测的 ~2.6 倍）。

量化检查点

使用 LLM Compressor 创建了模型的量化版本，并以 compressed-tensors 格式提供。支持的格式包括：

• FP8: 具有全动态激活值的量化权重。
• NVFP4: 权重和激活值均量化为 NVFP4 格式。