并行草稿为什么不容易训练：一篇推测解码预印本的思路

推测解码能不能加速，取决于草稿提议的内容有多少能被目标模型接受。一篇10月27日公开的预印本提出MDraft：它不改推理阶段的草稿模型结构，而是在训练时让多个候选草稿共同提供校验反馈。

先把流程拆开看：较小的草稿模型一次提议一段token，目标模型并行校验这段提议。通过的前缀可以保留，不通过的位置按校验规则处理；如果一次能确认多个token，就有机会减少目标模型的调用次数。

论文关注的是“一步并行草稿”里的一处不匹配。草稿模型在同一次前向计算中预测多个位置，不知道同一段里前面实际采样出了哪个词；目标模型给某个位置打分时，却会看到前面的候选词。因此，同一个位置遇到不同前缀时，目标模型可能偏好不同的后续词。只分别拟合这些反馈，可能把某个前缀下合理的候选词压得过低。

MDraft的做法是在同一个上下文下采样多段草稿，分别让目标模型评分，再把不同草稿在同一位置的完整词表概率做聚合，与各自的评分混合后用于训练。额外的候选评估发生在训练阶段；论文比较时保持草稿架构、块长度和推理算法不变，替换的是训练后的草稿模型权重。

主实验用Qwen3-4B作校验模型，比较了数学、代码和对话共六项基准。在温度0.6下，MDraft的六项平均接受长度为6.321，论文中同温度最强的对照为6.168。这个指标按论文定义包含每次校验中接受的草稿token，以及一个额外的修正或奖励token；数字不是“准确率”，也不是每秒生成速度。温度为0时，MDraft的平均值虽略高，但并非每项基准都排第一。

作者没有单独报告实际吞吐提升：更长的接受长度是否换成更快的生成，还取决于草稿计算、目标模型校验、批量大小和硬件等开销。额外训练成本也需要结合任务规模考虑。这是一篇预印本的特定实验结果，不代表现有服务已经采用该方法，也不是对所有模型或工作负载的速度承诺。