文本 Diffusion 模型：离散去噪、掩码与序列生成

1. 先划边界：文本扩散到底扩散什么

图像扩散常在连续 latent 上逐步加高斯噪声；文本 token 是词表中的离散类别，不能直接给 token id 加一点高斯噪声并期待它仍有语言意义。离散扩散因此定义一个离散转移：把 token 替换成特殊 [MASK]，或按转移矩阵替换为其他词表状态。模型学习从受污染序列恢复干净序列。

当前大语言模型语境里的 dLLM 多指 masked diffusion language model：条件 prompt 保持可见，回答区域从掩码开始，多轮并行填充。它与 encoder-only 的 BERT 都会预测 mask，但目的不同：BERT 通常用于表示学习，dLLM 要定义完整的生成轨迹、终止规则与条件概率。

2. 前置：把序列生成看成条件分布恢复

设完整回答为 x0=(x1,...,xL)，条件 prompt 为 c。自回归模型把联合分布分解为从左到右的条件概率；扩散模型引入时间 t 和受污染序列 xt，学习在给定 c、xt、t 时恢复各位置的 x0。这里的“时间”是去噪步，不是文本位置。

两种分解都能表示条件语言分布，计算图却不同。AR 每步只新增一个位置，可以缓存全部历史 KV；dLLM 每步可能确认多个位置，但未确认位置仍在变化，注意力上下文也随之改变。评估加速时要同时计算网络前向次数、单次序列长度与缓存刷新范围，不能只数并行 token。

3. 前向过程：absorbing mask 怎样逐步毁掉一句话

最直观的 absorbing-mask 过程以随时间增加的概率把原 token 换成 [MASK]；一旦进入 mask，就不在前向过程中恢复。若时刻 t 的保留概率为 alpha(t)，每个位置独立保留原 token 的概率是 alpha(t)，变为 mask 的概率是 1-alpha(t)。

训练时无需真的运行很多步：采样一个 t，按该噪声率一次构造 xt 即可。不同论文会用不同时间参数化、权重和 transition matrix；D3PM 建立通用离散状态转移框架，MDLM 与 RADD 则把 absorbing-state 文本扩散的训练目标和采样进一步简化。理解具体模型时要看它预测 x0、反向 transition，还是某种比值/score，不能只看“用了 mask”。

4. 训练目标：不是普通 MLM loss 换个名字

一次训练样本通常包含条件 prompt、原答案、随机噪声时刻和被掩码答案。网络对全部位置输出词表 logits，但损失只在被污染位置上计算，并按噪声日程加权。最简化的直觉是“在各种 mask 比例下恢复完整答案”；严格目标来自扩散 ELBO 或等价的连续时间表达。

低噪声样本训练局部纠错，高噪声样本训练模型从近乎空白的画布建立全局内容。训练若只覆盖固定长度和固定 mask schedule，推理时贸然改用更大 block 或激进并行接受，质量通常会下降。2026 年的多项工作用伪轨迹蒸馏或专门的 block 解码训练，让训练轨迹更贴近高吞吐推理。

5. 反向生成：预测、选择、接受、再掩码

生成先创建长度为 L 的回答画布。每次前向，模型同时给所有 mask 位置产生词表分布；sampler 依据置信度、熵、预定日程或随机规则接受一部分 token，其余保持或重新变成 mask。重复直到没有 mask、达到步数上限或满足终止条件。

固定每步揭示相同数量最容易实现，却可能在简单 token 上浪费步骤、在难 token 上过早承诺。confidence-based decoding 让高置信位置先落定；entropy-bound sampler 以分布不确定性决定是否接受；remasking 允许纠错，但也会使 KV cache 更难复用。temperature、接受阈值、最大步数和画布长度共同决定质量与延迟。

6. 长度不是附属问题：固定画布、EOS 与 block

AR 遇到 EOS 就自然停止；masked dLLM 若从 256 个 mask 开始，必须解释“只需要 37 个 token”时其余位置是什么。早期方案常固定生成长度或把多余位置预测为 EOS/padding，容易浪费计算并影响长度分布。变量长度模型则显式预测长度、学习删除/插入、或让终止 token 与后续 padding 共同参与训练。

block-autoregressive 是实用折中：长回答被分成若干固定上限 canvas，canvas 之间从左到右推进，当前 canvas 内部并行扩散。这样已完成 block 可以形成稳定前缀 KV，当前 block 仍能双向修订。它没有完全消除串行依赖，但把串行单位从一个 token 放大成一块 token。

7. 与 AR 的真实成本比较：NFE 才是第一层答案

NFE 是 neural function evaluations，也就是完整模型前向次数。一次前向若平均确认 16 个 token，前向次数会明显减少；但每次重算 256-token block 的成本又远高于 AR 的单-token decode。只有平均接受数足够大、活动区足够小、稳定区域可缓存且 GPU 能吃满块级并行时，NFE 的下降才会转化为端到端加速。

8. 具体例子：256-token canvas 如何生成 73-token 答案

假设 prompt 已 prefill，回答 canvas 上限为 256。第 1 次前向看到 256 个 mask，sampler 接受约 18 个低熵 token；后续前向逐步确认结构词、数字和代码符号。若模型支持提前停止，它在第 73 位形成 EOS，并确认其后不需要输出；若不支持变量长度，则仍可能处理剩余 canvas。

如果每步平均确认 15 个 token，8 次 NFE 足以覆盖约 120 个位置；但接受数并不恒定，后期相互依赖的 token 可能成为长尾。预测服务延迟时，除了“8 steps”，还要统计每步活动 mask 数、熵分布、KV 刷新 token 数与实际 EOS 位置。

9. 2025 基线 LLaDA：它建立了什么，又缺了什么

LLaDA 是 8B masked diffusion language model，官方仓库称其预训练约 2.3T token。它证明了纯离散扩散在大规模预训练、指令跟随、数学和代码任务上的可行性，也是后续系统论文常用 baseline。训练时随机掩码答案 token，推理时从固定画布反复去噪。

但官方仓库也直接说明原始推理通常慢于同规模 AR：生成步数常接近回答长度，固定长度带来浪费，标准增量 KV cache 不能直接套用。它的历史意义是给出可扩展基线，不是证明文本扩散天然更快。2026 的重点已转向变量长度、GQA、block/canvas 结构、蒸馏采样和专门 serving。

10. 2026 iLLaDA：让基础模型先适配可用的推理形态

iLLaDA 仍为 8B 级，但针对原始 LLaDA 的训练和推理限制重新设计：使用 GQA 减少 KV 规模，支持变量长度，并把 confidence scoring 纳入生成。论文报告 12T 预训练 token，指令阶段使用 25B-token SFT 语料训练 12 epochs。

相对 LLaDA，论文报告 Base 在 BBH 提升 21.6 点、ARC-C 提升 14.9 点；Instruct 在 MATH 提升 14.5 点、HumanEval 提升 16.5 点。这些是论文设定下的相对结果，不代表在任意 sampler 或 serving 框架中自动复现。系统层面的意义在于：GQA 降低每个活动 token 的 KV，变量长度减少空 canvas，confidence 提供动态接受信号。

11. 2026 DiffusionGemma：AR 前缀加扩散画布

DiffusionGemma 于 2026-06-10 发布开放权重，建立在 Gemma 4 26B A4B 系列之上。官方模型卡给出 25.2B 总参数、3.8B active 参数、30 层；MoE 每层 128 个 experts，路由 8 个并带 1 个 shared expert。上下文上限 256K，单个扩散 canvas 为 256 token。

DiffusionGemma 没有反复双向重算整个 256K 上下文。它采用 block-autoregressive 结构：已完成前缀由 causal encoder/prefill 写入 KV cache，bidirectional denoiser 只反复更新当前 256-token canvas；长输出再开启下一块 canvas。成熟的长前缀缓存因此可以与块内并行去噪并存。

官方默认最多 48 steps，推荐 entropy-bound 0.1，temperature 从 0.8 降到 0.4，并支持 early stopping。官方材料报告 H100 FP8 超过 1100 tok/s，常见每次前向接受 15-20 token；量化部署约需 18GB。数字必须与 H100、FP8、官方 sampler 和 workload 一起引用，不能直接外推到其他 GPU 或长上下文。

12. DiffusionGemma 的多模态边界：媒体输入，文本输出

DiffusionGemma 可以接收图像和视频帧，并输出文本；它不是图像扩散生成器。模型卡给出视觉 token budget 70、140、280、560、1120，视频最多 60 秒并以 1 fps 采样。增加视觉 budget 会提高视觉细节和 prefill 成本，但不会改变当前文本 canvas 的 256-token 上限。

官方 AIME 2026 结果为 69.1，而 Gemma 4 对应结果为 88.3，说明高吞吐扩散解码并非无损替换。部署评估必须同时跑质量、长度和延迟；只报告 tok/s 会掩盖 sampler 更激进、思考更短或 benchmark 能力下降。

13. 底层算子：GEMM 相同，attention 形状不同

dLLM 仍由 embedding、QKV projection、attention、MoE/MLP、norm 和输出词表投影构成。DiffusionGemma 的 MoE 路径还包含 router top-k、expert GEMM、token permutation 与跨设备 all-to-all。变化集中在 attention mask 与活动 token：稳定前缀使用 causal prefill，当前 canvas 内需要双向交互；每一去噪步又对当前 canvas 产生全词表 logits。

词表 projection 在每步为大量位置输出 logits，可能成为显存带宽和临时张量大户。高效实现会只对活动位置算 logits、融合采样与 entropy 计算、压缩 bool mask，并把 token 接受结果留在 GPU 上，避免每步 CPU 往返。

14. KV cache：稳定前缀能存，变化画布只能近似存

标准 AR cache 成立是因为旧 token 的隐藏状态永远不变。dLLM 当前画布会从 mask 变为 token，也可能 remask，因此其他位置对它的 attention 结果随步数变化；无条件复用旧 KV 会产生近似误差。安全的第一层优化是缓存 causal prompt 和已完成 canvas，只重算活动 canvas。

更激进的方法会检测哪些位置或层的表示变化足够小，只刷新部分 KV；或把生成蒸馏成少量大 block，使缓存刷新次数减少。dLLM-Cache 是 2025 基础工作，报告最高 9.1×；2026 的 Dynamic-dLLM 等继续做自适应 cache/update。所有近似缓存都必须复测困惑度、任务准确率和长答案一致性，不能只看 speedup。

15. 中间层调度：请求不再每轮都前进一步

AR continuous batching 每轮通常为每个活跃请求生成一个 token；dLLM 每轮接受数不同，部分请求提前收敛，部分请求长期卡在高熵位置。若 batch 等待最慢请求，GPU 空洞增加；若每个 NFE 都重组 batch，调度和内存搬运又变重。调度单位应从“一个 decode token”改为“一个活动 canvas 的预算”。

Optimus 用 elastic chunk size 与 saturation-aware scheduling 适配动态并行度，论文报告最高比 AR 快 6.1×、比固定 block 快 4.3×。Sangam 把近似 cache 导致的重复 prefill/decode 纳入 deficit token-budget scheduler，并比较 colocated 与 hybrid 部署；其报告的平均延迟改善约为 8%-20% 或 9%-20%，取决于 workload 和部署模式。

16. 2026 serving 技术图谱：模型与 Runtime 要共同设计

这些最大值不能横向直接排名：baseline、模型、质量约束、输出长度、硬件与是否包含 prefill 各不相同。正确做法是在同一模型、同一 sampler 质量目标、同一 prompt/output 分布上报告 TTFT、time-to-first-accepted-block、inter-step time、E2E latency、tok/s 和任务分数。

17. 部署 DiffusionGemma：一张卡能启动，不等于生产完成

Google 开发指南给出 vLLM serving 配置，核心是 256-token canvas、entropy-bound sampler、chunked prefill 与适配 diffusion 的 generation config。下面保留关键参数作为可读基线；实际安装版本和参数应以官方当日文档为准：

vllm serve google/diffusiongemma-26B-A4B-it \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --gpu-memory-utilization 0.85 \
  --attention-backend TRITON_ATTN \
  --generation-config vllm \
  --hf-overrides '{"diffusion_sampler":"entropy_bound","diffusion_entropy_bound":0.1}' \
  --diffusion-config '{"canvas_length":256}' \
  --enable-chunked-prefill

生产前要补四组测试：不同 prompt 长度下的 prefix KV 峰值；不同输出长度下的 canvas 数和尾块浪费；不同 entropy/temperature/step cap 下的质量曲线；混合请求下的公平与取消。MoE 多卡部署还要测 expert parallel 的 all-to-all，不能把单卡量化结果当作多卡扩展结论。

18. 局限与失败模式：并行生成不会自动带来更好推理

高置信 token 可能在错误全局假设下过早锁定；remasking 能纠错，却增加 NFE 和 cache 失效。数学证明和代码有强顺序依赖，过大的并行接受可能破坏中间一致性。固定 canvas 会浪费短答案，过小 canvas 又恢复为大量串行 block。长上下文的 prompt KV 仍按上下文增长，扩散只改变输出侧。

闭源 Gemini Diffusion 官方页面报告特定评估中 1479 tok/s，且明确另有 0.84 秒 overhead；没有公开足够架构细节，不能把该数字解释成某个确定 sampler 或 KV 方案。任何没有质量约束、硬件、batch、输入输出长度和计时边界的 tok/s 都不是可部署证据。

19. 最小复现实验：先画质量-延迟曲线

1. 固定 100-500 条 prompt，按短答、长文、数学、代码分桶，保存期望最大长度与评分脚本。
2. 对 AR baseline 和 dLLM 使用相同 tokenizer、输入上限与硬件，记录 prefill、每次 NFE、接受 token 数、EOS 和峰值显存。
3. 扫描 step cap、temperature、entropy/confidence threshold、canvas length 与 cache 策略，输出质量-延迟 Pareto 曲线。
4. 加入并发，测 P50/P95/P99、取消请求、短请求被长 canvas 阻塞，以及 prefix KV 达到上限时的行为。
5. 用 profiler 验证时间究竟花在 expert GEMM、attention、vocab projection、采样 kernel、all-to-all 还是 CPU 调度。

只有当平均接受 token 数上升、NFE 降低、活动 canvas 受控，并且质量不越过目标下限时，扩散并行才转化成真实 serving 收益。

20. 一手来源