推测性解码：实现 Whisper 推理速度提升两倍 [译]
内容提要
文章介绍用推测性解码加速Whisper语音转录：由快速助理模型自回归生成候选Token，主模型单次前向验证，保留一致前缀并修正首个错误，数学上保证输出与主模型一致。英语测试中，以Distil-Whisper为助理模型，73个样本的转录时间从73秒降至33秒，提速2.2倍，WER保持3.5%；荷兰语测试从117秒降至62秒，提速1.9倍，WER不变。助理模型宜比主模型快3倍以上，批处理不超过4时效果最佳。
延伸解读
速度与一致性的平衡
推测性解码通过助理模型快速生成候选Token，主模型单次前向验证，保留一致前缀并修正首个错误，数学上保证输出与主模型完全一致。这意味着提速不以牺牲准确率为代价，WER保持不变。对于需要高可靠性的转录场景，这种确定性尤为重要，可以无缝替换现有流程。
助理模型的选择与权衡
助理模型需与主模型共享词汇库，且速度至少为主模型的3倍，能准确预测70-80%的简单Token。Distil-Whisper因共享编码器且仅加载2层解码器，显存开销仅增加8%，是英语场景的理想选择。多语言场景可选Whisper tiny或微调模型，但需注意large-v3词汇量不同，不兼容旧版助理模型。
批处理大小的限制
推测性解码在批处理大小为1时提速最大，因为批内所有候选Token必须与验证Token完全一致才有效。实际测试表明，批处理不超过4时能有效提速，超过4则可能比仅用主模型更慢。因此，若需大批量处理，应调整批大小或评估是否启用推测性解码。
实际部署的考量
文章测试基于LibriSpeech英语和VoxPopuli荷兰语各73个样本，英语提速2.2倍，荷兰语提速1.9倍，WER均不变。但助理模型加载会增加少量显存，且需确保tokenizer一致。对于资源受限环境，需权衡显存与速度收益。此外，推测性解码也适用于语音翻译任务，只需调整任务参数。
Q&A
推测性解码是怎么让 Whisper 推理变快的？
推测性解码使用一个快速的助理模型自回归生成多个候选 Token，然后主模型通过一次前向传递验证这些 Token。保留与主模型预测一致的前缀，并在第一个不匹配处用主模型的正确 Token 替换，丢弃后续候选。这样大部分 Token 由快速助理模型生成，主模型只做验证，从而加速推理，同时数学上保证输出与主模型完全一致。
用推测性解码加速 Whisper 后，转录准确率会下降吗？
不会。推测性解码在数学上保证输出与单独使用主模型时完全一致。在英语测试中，WER 保持 3.5% 不变；在荷兰语测试中，WER 保持 12.8% 不变。因此可以无缝替代现有 Whisper 流程，不损失准确性。
英语和荷兰语的实测提速效果分别是多少？
英语测试使用 LibriSpeech 的 73 个样本，转录时间从 73 秒降至 33 秒，提速 2.2 倍，WER 保持 3.5%。荷兰语测试使用 VoxPopuli 的 73 个样本，时间从 117 秒降至 62 秒，提速 1.9 倍，WER 保持 12.8%。
选择助理模型时有哪些要求？
助理模型必须与主模型共用相同的词汇库（即相同的 Tokenizer）。例如，多语言主模型需搭配多语言助理模型（如 tiny），英语主模型需搭配英语助理模型（如 tiny.en）。Whisper large-v3 因扩大了词汇量，与之前版本不兼容。此外，助理模型的速度至少应是主模型的 3 倍，并能准确预测 70-80% 的简单 Token。
批处理大小对推测性解码的速度有什么影响？
批处理大小为 1 时速度提升最大。在批量推测性解码中，整个批处理的所有候选 Token 必须与验证 Token 完全一致才有效，任一位置不一致都会导致后续候选被丢弃。实际测试表明，批处理大小不超过 4 时能有效提速，超过 4 时推理速度反而比仅用主模型慢。
如何在 Hugging Face Transformers 中使用推测性解码？
在 Transformers 中，推测性解码通过“辅助生成”策略实现。调用 model.generate 时传入 assistant_model 参数即可，例如 outputs = model.generate(**inputs, assistant_model=assistant_model)。也可以通过 pipeline API，在 generate_kwargs 中指定 assistant_model。助理模型可以用 AutoModelForCausalLM 加载（如 Distil-Whisper 仅需加载解码器），显存仅增加约 8%。
