第24章：推测解码与低延迟优化

1. 项目背景

某代码助手的vLLM服务上线后，开发者反馈最集中的问题是"补全太慢"——在IDE中输入一行代码，期望100ms内看到补全建议，但实际TPOT（每Token生成时间）约45ms，一行10个Token的代码补全需要450ms。虽然比一般的闲聊快了，但与IDE对"实时感"的要求（<200ms端到端）还有差距。

技术团队分析了延迟构成：每次Token生成都需要完整的Transformer forward（80层 × 注意力计算 × FFN）。在batch较小的情况下，GPU利用率不足40%——大部分时间在等待显存读取而非计算。要降低延迟，必须减少每个Token的forward次数——但这是自回归生成的本质，如何打破？

团队发现了推测解码（Speculative Decoding）：用一个轻量级的"草稿模型"（Draft Model）快速猜测未来几个Token，然后由主模型一次性验证这些猜测。如果草稿模型猜对了，可以一次验证通过多个Token，吞吐翻倍；猜错了也不影响正确性——只是浪费了草稿模型的计算。

痛点：自回归生成的"一次一个Token"是延迟的根本瓶颈。推测解码通过"猜测+验证"的投机策略，在低batch、低延迟场景下可获得1.5-2.5倍加速。但接受率（草稿猜对的概率）直接决定了实际收益——接受率70%意味着约30%的草稿计算被浪费。

2. 项目设计

（场景：代码团队周会。开发组长展示了一组"延迟漏斗"数据——代码补全的P50=450ms, P95=1200ms。）

小胖