推测解码怎么加速
用一个更小的草稿模型（或 n-gram 一类方法）先预测若干候选 token，主模型一次前向就能校验并接受其中一部分：接受率高时每步产出多个 token，单 token 时间明显下降。它适合显存还有余量、又对延迟敏感的场景。
基本信息
| 核心思路 | 草稿模型先猜，主模型一次校验 |
|---|---|
| 关键指标 | 接受率 |
| 收益条件 | 接受率高、草稿开销低 |
| 资源代价 | 额外显存与算力 |
| 适用场景 | 显存有余、延迟敏感 |
典型使用场景
- 交互问答的首字之后生成速度不够
- 延迟敏感但对总吞吐要求不高的服务
- 显存有富余、希望压低单请求耗时
- 结构化字段等接受率天然较高的输出任务
- 对生成速度有硬指标、又不想换更大算力的场景
配置示意
配置示意
vllm serve <主模型路径> --speculative-model <草稿模型路径> --num-speculative-tokens 5
# 参数形态随版本变化，以版本文档为准
# 上线前用真实流量测接受率，再决定是否常开与开几个候选四个量要一起看
| 指标 | 含义 | 关注点 |
|---|---|---|
| 接受率 | 被接受的候选比例 | 越高收益越大 |
| 草稿开销 | 草稿模型耗时 | 过大就吃掉收益 |
| 显存占用 | 草稿模型与缓存 | 需要额外预留 |
| 吞吐变化 | 单位时间产出 | 与延迟可能反向 |
收益取决于接受率与草稿成本：上线前用真实流量测接受率，再决定是否常开、开几个候选，不要按论文里的最好情况估。
草稿模型与主模型的分词表要一致：不一致时接受率会很低，表现为几乎没有加速，排查时优先核对这一点。
接受率与输出内容强相关：摘要、改写这类偏确定的任务通常比自由创作更容易命中，按业务类型分别验证。