高并发下吞吐量为何会崩溃？
最大的生产风险在于，块扩散草稿模型会一次性生成长令牌序列，但如果不加区分地验证这些块，可能会将关键的批处理容量浪费在很可能被拒绝的令牌上。DSpark [1] 在一个实时服务系统（DeepSeek-V4）中证明了这一点：当验证长度未针对每个请求进行调整时，在严格的交互性约束下，吞吐量会严重下降。通过基于前缀存活概率和引擎特定的吞吐量特征动态调整验证长度，DSpark 在匹配的吞吐量水平下将单用户生成速度提升了 60–85%，并实现了此前无法达到的性能层级。这表明，在生产环境中，失败模式不仅仅是原始速度问题，而是草稿质量与批处理调度之间的交互作用。
草稿质量如何随块长度和采样温度而衰减？
块式扩散草稿模型会并行预测多个未来词元，但由于它们基于逐位置边际分布进行采样，而非完全条件化的序列，因此往往无法捕捉目标模型偏好的生成轨迹。当解码是随机（非贪婪）时，这一问题尤为突出，正如DBLast [3]所示：随着目标采样分布的熵增加，被接受的草稿长度会下降。在高熵场景下，独立的块式采样变得脆弱，而DBLast的依赖式块草稿模型（使用低秩潜在混合）在提升接受长度方面始终优于独立采样。类似地，DSpark [1]指出，并行草稿模型因缺乏词元间依赖而面临接受率快速衰减的问题，这正是他们添加轻量级顺序模块以建模块内依赖的原因。要点是：如果你的生产工作负载使用温度大于0的采样，你需要一个能建模依赖关系的草稿模型，而不仅仅是并行预测器。
为什么固定块大小在生产环境中是一种失效模式？
大多数分块扩散方法使用固定的推理块大小，但BlockPilot [5]表明，最优块大小因样本而异，且对性能至关重要。他们发现，最优块大小集中在训练块大小附近，但差异仍然足够大，以至于一刀切的方法并非最优。BlockPilot根据预填充表示预测最优块大小，在Qwen3-4B上、温度T=1时实现了5.92的接受长度和4.20倍的加速。这是一个明确的信号，表明生产系统必须按请求调整块大小，而不仅仅是按工作负载调整。同样的主题也出现在Bastion [2]中，它根据硬件约束动态构建查询相关的草稿树，以及D^2SD [4]中，后者利用置信度分数选择最可能的拒绝边界并重新锚定替代延续。所有这些方法都指向同一个结论：静态配置在生产中是一种负担。
关于这些资料来源
此回答基于5项研究（均为预印本）——发表于2026年，其中5项为2024年或之后——从8项通过质量筛选的研究中选出最具相关性的，这些研究源自从超过5亿篇论文数据库中检索到的33篇文献。
本文引用的文献
DSpark：基于置信度调度的半自回归生成投机解码方法
DSpark在DeepSeek-V4服务中的部署表明，对长块进行不加区分的验证会浪费批处理容量并降低吞吐量；其基于置信度调度的验证在吞吐量不变的情况下，将每位用户的生成速度提升了60%至85%。
Bastion：基于树结构块扩散草拟的预算感知投机解码
Bastion采用预算感知的树状扩散草稿机制，结合接受代理模型和在线延迟估计器，相较于自回归解码实现了最高6.61倍的加速，并比最先进的块扩散基线方法性能提升39%。
DBLAST：面向随机投机解码的依赖块草拟方法
DBLast表明，独立块采样在目标采样熵增加时会降低接受长度；而其采用面向接受度训练的依赖块草稿模型则能提升接受长度，尤其是在高熵解码场景下效果更为显著。
D^2SD：利用双重扩散草稿模型加速推测解码
D^2SD采用双扩散草稿框架，结合置信度引导的前缀树与级联注意力机制，在底层扩散方法及强自回归基线模型的基础上均实现了性能提升。
BlockPilot：基于扩散的推测解码的实例自适应策略学习
BlockPilot表明，最优块大小在不同样本间存在差异，并可从预填充表示中预测该大小，在Qwen3-4B上、T=1条件下实现了5.92的接受长度和4.20倍的加速。