推测解码的额外开销
推测解码的思路是用一个小模型（草稿模型）先连续猜若干个 token，再由主模型一次性验证，猜对的直接采纳。它要同时驻留两套权重和两套缓存：草稿模型自己的权重、以及为它维护的缓存，两者都随并发增长。因此显存预算要把它当成主模型之外的一笔独立小账，而不是塞进主模型的余量里。
基本信息
| 额外组成 | 草稿模型权重、草稿缓存、额外的调度与验证开销 |
|---|---|
| 关键指标 | 接受率，即被主模型采纳的草稿 token 比例 |
| 收益条件 | 接受率高且草稿模型足够小，才能净赚速度 |
| 显存形态 | 随并发线性增长，高并发下不可忽略 |
| 启用方式 | 推理引擎的推测解码参数，草稿模型单独指定 |
典型使用场景
- 降低单 token 延迟：交互式对话对逐步输出的速度敏感，接受率高时可明显改善体感
- 同系列小模型做草稿：与主模型同源的小模型输出风格接近，接受率通常更高
- 批量生成任务：长文本输出场景收益被放大，但要确认显存余量足够
- 低并发高端卡：显存宽裕时用额外开销换速度，属于划算的取舍
- 对比验证：先小流量测接受率，再决定是否全量开启
预算与实测
预算与实测
# 预算拆法
# 总预算 = 主模型（权重 + 缓存 + 工作区）+ 草稿模型（权重 + 草稿缓存）
nvidia-smi --query-gpu=memory.used --format=csv -l 5 # 步骤一：记录主模型基线水位
# 步骤二：挂上草稿模型后重新采样，对比显存增量
# 步骤三：小流量压测，记录接受率与单 token 延迟
# 结论：收益为负或水位顶格时，换更小的草稿模型或关闭该功能收益判断
| 条件 | 收益 | 风险 |
|---|---|---|
| 草稿模型很小且接受率高 | 单 token 延迟明显下降 | 显存增量小，可接受 |
| 草稿模型偏大 | 速度提升有限 | 权重与缓存双重占用，可能拖慢主模型 |
| 接受率低 | 接近无收益 | 白付显存与调度开销 |
| 高并发场景 | 吞吐可能不升反降 | 缓存占用挤压主力并发，显存水位顶格 |
| 显存本就紧张 | 不适用 | 主模型缓存被挤压，长上下文请求失败 |
接受率是判断收益的唯一可靠依据：不同模型组合、不同任务的接受率差别很大，必须用真实流量测，不能照搬别人的配置。
草稿模型通常与主模型同系列效果更好：分词器一致时验证过程更顺畅，分词方式差异过大会让接受率显著下降。