为什么部署投机采样后推理速度反而掉到了 0.86x？

最近在尝试优化大模型推理性能时，我被投机采样（Speculative Decoding）给坑了。很多技术文档和论文里把这套方案描述成能显著降低端到端延迟的“神药”，但在实际部署 Qwen2.5-3B（主模型）和 Qwen2.5-0.5B（草稿模型）的组合时，我发现实测的 Token/s 不仅没有提升，反而出现了 0.86x 这种离谱的“负加速”。

起初我以为是硬件环境的锅。比如在 Mac 的 MPS 后端上，每次调用模型都会产生一定的固定调度开销，小模型虽然参数量少，但调度时间在总耗时中的占比极高。在这种情况下，即便模型规模相差 6 倍，实际速度提升可能只有 2.8 倍，导致投机采样的收益被硬件开销给抵消了。但为了搞清楚本质原因，我尝试通过 FLOPs 理论计算来排除硬件干扰，结果发现这其实是一个纯粹的数学概率博弈问题。

投机采样的核心逻辑是利用一个轻量级的草稿模型（Draft Model）先行预测几个 Token，再由主模型一次性并行验证。如果主模型接受了这些 Token，速度就起飞了；如果拒绝了，则需要回滚并重新生成。这里存在一个核心矛盾：成本比（c）与接受率（$\alpha$）的博弈。

我实测发现，当使用 0.5B 模型作为草稿模型时，接受率大约在 30%-40% 左右。在这个区间内，即便假设硬件调度开销为 0，理论加速比其实连 1.0x 都不到。为了提升接受率，我尝试将草稿模型升级到 1.5B，本以为这样能通过提高 $\alpha$ 来救场，结果却陷入了另一个死循环：成本比 $c$ 变成了 0.5。这意味着草稿模型变得更重了，此时它需要达到 70% 以上的接受率才能勉强打平单模型推理的速度。

在实际运行 1.5B 草稿模型时，虽然偶尔能刷出 1.37x 的加速峰值，但绝大多数时间性能依然在 0.4x 到 0.7x 之间徘徊。这证明了投机采样的效果极度依赖于草稿模型对主模型概率分布的拟合程度。如果草稿模型猜不准，频繁的“拒绝-回滚”机制不仅浪费了计算资源，反而成了性能累赘。

对于准备实操部署的朋友，我建议在写代码之前先用这个理论加速比公式预估一下：

E[speedup] = (1 - α^(γ+1)) / ((1 - α)(γ·c + 1))

其中 $\alpha$ 代表接受率，$\gamma$ 是猜测长度，$c$ 是模型成本比（草稿模型耗时/主模型耗时）。

通过这个公式可以发现，投机采样绝非万能药。如果草稿模型太弱，导致 $\alpha$ 过低，或者草稿模型太强，导致 $c$ 过高，这套工作流纯属浪费电。建议在部署前先跑一遍这个计算，如果预估结果低于 1.2，建议直接放弃投机采样，回归到单模型推理，这样性能反而更稳。