大模型 API 为什么突然变快：推测解码不是偷偷换小模型

大模型 API 为什么突然变快：推测解码不是偷偷换小模型

大模型 API 的速度变化经常被用户理解成“供应商把请求降级给小模型”。9 月 2 日 NVIDIA 发布的推测解码指南展示了另一种可能：目标模型保持不变，额外增加一个轻量草稿机制，一次提出多个后续 Token，再由目标模型并行验证。目标模型按顺序接受候选，遇到第一个不匹配便从该处继续生成；在严格验证条件下，保留下来的输出与目标模型按标准方式逐 Token 解码一致。

普通自回归解码每轮只产生一个 Token，GPU 需要反复加载权重并启动计算。推测解码用更多并行计算换取更少的串行轮次。草稿长度 D 表示一次提出多少候选，接受长度 AL 表示目标模型在一次验证中最终产出多少 Token。AL 越高通常越有利，但草稿本身也消耗时间和显存；候选猜得差或批量已经很大时，推测解码甚至可能拖慢服务。

草稿模型不是备用模型

备用路由发生在主模型不可用、超时或超预算时，请求会改由另一模型完成，输出分布也随之变化。推测解码中的小模型没有最终决定权，它只提供候选，目标模型仍负责验证。两者在产品承诺、日志与评测中应分开记录。服务商如果切换了最终模型，应披露实际 model code；若只是启用推测解码，可以把它视为推理引擎优化。

草稿机制也不只有“小模型带大模型”。NVIDIA 比较了外部草稿模型、EAGLE-3、MTP、DFlash、DSpark 以及 suffix/n-gram 等方案。外部草稿容易理解，却要维护另一套权重和 KV Cache；附着在目标模型上的预测头能利用隐藏状态；n-gram 不训练模型，只复用已经出现的文本模式，适合代码、模板和其他重复度较高的工作负载。选择哪种方案，要同时看接受长度、草稿开销、训练成本和部署复杂度。

新指南还提醒，最佳草稿长度会随批量、注意力结构和上下文变化。低并发、强调交互延迟的接口有更多闲置计算可用于验证；高并发服务本已接近计算上限，额外候选未必划算。对长上下文 Agent，注意力和 KV Cache 压力又会改变瓶颈。一个在聊天数据上提速的配置，放到代码补全或摘要任务上可能完全不同。

API 用户应测首字延迟和完整任务

调用第三方大模型 API 时，用户通常看不到服务端是否启用推测解码，但可以观察它的结果。评测至少分开记录首字延迟、输出 Token 间隔、P50/P95 完成时间和错误率；短回答与长回答、流式与非流式、单并发与高并发要分别测试。仅用一条提示跑三次，无法区分推理优化、网络抖动和排队变化。

自托管团队还应使用真实提示计算接受率。NVIDIA 推荐用覆盖代码、摘要和不同输入长度的 SPEED-Bench 衡量 AL，并用推理框架测草稿开销。模型微调后，输出分布与隐藏状态可能变化，原有草稿器的接受率会下降，升级目标 checkpoint 时必须重新跑基线。为了追求峰值而放松验证条件，则需要额外评估质量偏移，不能再宣称输出完全不变。

模型网关可在业务侧补齐可见性：固定目标模型与版本，记录请求时间、首字延迟、输出长度、重试和实际路由，让团队判断性能变化来自模型、供应商还是网络。可通过 [AnyAIS 模型列表](/models) 选择候选模型，并按 [API 文档](/docs) 在同一套真实任务上比较延迟与完成率。速度提升只有转化为更稳定的任务结果，才值得进入生产。

来源：[NVIDIA：Co-Designing AI Models Using Speculative Decoding](https://developer.nvidia.com/blog/co-designing-ai-models-using-speculative-decoding-for-faster-llm-inference/)