抛开diffusion概念理解扩散语言模型的生成与性能权衡

如果你暂时忘掉“扩散”这个词，扩散语言模型其实更容易理解。自回归模型一次生成一个文本 token。每个新 token 都是在前一个 token 生成完成后才产生。

掩码扩散模型的工作方式不同。它可以从许多未解析的位置开始，在同一轮处理中预测所有位置，然后只确定其中一部分预测结果。训练过程中，它会看到不同掩码量的序列，学习从两侧可见上下文还原出隐藏 token。生成过程中，这个过程会不断重复，直到序列完整。

在基于置信度的采样器中，模型会先保留置信度最高的预测，把不确定的位置继续留作掩码，放到下一轮处理。这给扩散带来了更高的并行度，但也产生了依赖问题。

假设同一轮处理解析了四个位置。所有四个预测都是基于序列的上一个版本做出的。在下一轮处理之前，它们无法把彼此作为新的可用上下文。如果这些选择之间依赖性很强，生成质量就会下降。这就是为什么去噪步骤和解码顺序很重要。

一次解析更多位置，需要的连续轮次就更少。一次解析更少位置，后续预测就能获得更多已完成的上下文，但推理需要更多计算量。我认为简单把它称为“更快的文本生成”忽略了一个更有意义的问题：输出中到底有多少内容可以真正并行处理？

@Cometml 在 30 个编码任务上用 Mercury 2 和 Claude Haiku 4.5 测试了这个问题，平均跑了 20 次。Mercury 的平均端到端时间约为 3.0 秒，Haiku 为 6.0 秒，但整体通过率分别为 84% 和 99.7%。在困难任务上，Mercury 通过率是 60%，Haiku 是 99%。

把 Mercury 的 reasoning_effort 提高到最高后，它的困难任务通过率提升到了 83%，但延迟也增加到了约 7.1 秒。Inception 没有记录这个设置在内部改了什么，所以我不认为它是直接对去噪步数的控制。

我不会用这些数据声称扩散比自回归生成快一倍。这是来自不同厂商的不同模型，计时还包含了网络和服务开销。结果中真正有价值的是权衡关系。如果输出的各部分之间依赖很弱，可以解析出部分输出，那就存在可以利用的并行性。如果未解析位置之间依赖性很强，那么更多的迭代处理就不再是额外开销，而是必要工作。

如果要为真实系统评估一个扩散语言模型，我会从这个问题出发：不问“扩散是不是更快？”，而是问工作负载实际能允许多少并行度。