昇腾上开了投机解码反而更慢：先别查 NPU 利用率，查接受率

在昇腾 A2 上给一个 Qwen 系模型启用投机解码，预期是 Decode 阶段吞吐提升，实际压测结果却是开了比不开还慢。第一反应是 NPU 利用率或显存带宽出了问题，但 npu-smi 显示利用率正常，显存水位也没有异常。折腾了大半天才定位到根因：草稿模型和目标模型的分布偏移导致接受率回退，投机解码退化成了“每步只确认 1 个 token”的纯开销。

一、 先理解投机解码的收益来源

投机解码的加速逻辑很直接：草稿模型每步生成 γ 个候选 token，目标模型一次性验证这 γ+1 个位置，接受其中连续匹配的前缀。每被接受一个 token，就省掉一次目标模型的前向。接受率是草稿分布和目标分布重合度的直接反映，一旦两者偏移，草稿阶段的计算就成了纯负担。

所以看到“开了投机反而慢”，正确的排查顺序是：先看接受率，再查硬件。接受率不是 vLLM 默认打印的指标，需要在日志或运行时 metrics 里看 spec_decode_draft_acceptance_rate，或者用 Grafana 面板计算 accepted_tokens / draft_tokens 的比值。如果接受率掉到接近 1（每步只确认 1 个 token），问题就在分布偏移上，硬件因素可以先排除。

二、 昇腾上特有的版本敏感点

我们这个场景的根因是 vLLM-Ascend 版本中的已知修复尚未合入。特定模型（如 GLM 系列）在旧版本下启用投机解码时，草稿模型和目标模型在 reasoning-effort 档位、MoE 路由的 SwiGLU 数值边界上存在系统性偏差，导致草稿产出的候选 token 大面积被拒绝。这类回归不会报错，只在接受率指标上暴露，很容易被误判为硬件或配置问题。

处理方式很直接：确认 vLLM-Ascend 版本是否包含对应模型的投机解码修复。升级后接受率回到正常区间，投机解码的加速才真正兑现。

三、 批量大小对投机收益的“翻转效应”

另一个容易被忽略的变量是 batch size。投机解码在 batch size 较小时收益最明显：此时 GPU/NPU 处于访存受限状态，算力有富余，额外的草稿计算几乎是“免费”的。但 batch size 增大后，草稿 token 开始和真实 token 争夺同一份算力，每个被拒绝的 token 都是实打实的计算浪费。在 batch 256 的场景下，投机解码的吞吐收益可能完全消失甚至反转。

这意味着线上服务的 batch 分布决定了投机解码是否值得开。如果服务以低并发、低延迟为主，投机解码的收益稳定；如果以高并发吞吐为主，需要先做接受率和 batch 的联合测试，而不是看到“支持投机解码”就默认打开。

四、 自适应验证：不是所有请求都值得投机

vLLM 和部分昇腾适配版本提供了 Adaptive Verification 能力：不是每一步都验证完整的 γ 个草稿 token，而是根据每个位置的存活概率动态决定验证多少。高置信度的请求保留完整草稿块，低置信度的请求在几个 token 后就截断，把算力留给更值得验证的位置。在混合负载下（部分请求结构化程度高、接受率高，部分请求开放生成、接受率低），这个机制能显著降低投机解码对 P99 延迟的负面影响。

五、 总结

昇腾上投机解码的排查链路：先看接受率（而非 NPU 利用率）→ 确认 vLLM-Ascend 版本是否包含对应模型的验收修复 → 测试 batch size 对收益的翻转点 → 混合负载场景考虑自适应验证。投机解码不是“开了就快”的开关，接受率低于阈值时，它是一笔纯亏损的买卖。