推理降延迟：投机解码与蒸馏怎么选

dev.to · AI#推理优化#模型蒸馏

Editor brief · 编辑速览

投机解码让小模型起草、大模型验证，收益取决于草稿接受率；蒸馏则用小模型替代大模型，需要权衡质量损失。文章解释两种方案在延迟、计算成本和输出质量上的不同取舍。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

给 AI 聊天应用提速，可以让小模型先写、大模型验收，也可以直接换成模仿大模型的小模型。原文讨论的就是推测解码和蒸馏：前者争取减少等待，后者减少模型开销，两者付出的代价并不相同。

作者最有价值的提醒是：别只看生成速度，还要看机器忙不忙、质量在哪些请求上下降，以及后续谁负责重新训练。对接入 AI 的前端和全栈团队来说，这比单看一张性能榜更接近实际选型。

推测解码（Speculative Decoding）让一个小模型提前生成若干候选 token，再由大模型通过一次前向计算验证。候选通过得越多，一次大模型计算就越能产出多个 token，平均等待时间也越短。

它没有把大模型压缩掉，而是增加了一位「打草稿的人」。

作者用接受率说明这笔账：如果草稿有 90% 被接受，验证的收益可能很可观；如果降到 50%，草稿生成和验证都花了资源，提速却可能很少。这两个数字是解释机制的示例，原文没有提供对应的模型、硬件和测试过程，不能当成通用分界线。

作者认为，草稿模型与大模型使用相同 tokenizer、接触相近训练语料和任务领域时，更容易得到较高接受率。遇到偏离训练分布的请求，草稿就可能频繁被拒。

推测解码保留质量的前提，是验证与采样算法能够严格保持目标模型的输出分布。

这里的「无损」指输出概率分布相同，不是每次运行都生成完全相同的文字。也不能把随意实现的「小模型生成、大模型审核」都算作无损推测解码。

蒸馏（Distillation）让较小的学生模型学习较大教师模型的输出。上线后真正处理请求的是学生，因此参数量、内存需求和单 token 推理成本都有机会下降，不依赖机器有没有闲余算力。

代价是，你已经换了一个模型。

学生可能很好地完成训练覆盖的任务，却在少见输入上退步。作者强调，平均基准分数只下降几分，不代表实际体验只下降一点：损失可能集中在少量复杂、异常或训练未覆盖的请求上。这就是「长尾质量」，也就是那些不常见、却不能随便答错的情况。

另一笔账发生在更新时。学生学到的是教师某个阶段的行为；教师更新后，学生不会自动获得新能力。要继续跟进，需要重新蒸馏，而不是修改配置。

如果教师每月更新，团队承担的就是持续训练流水线，需要明确负责人、评测和发布流程。单次推理账单变小，并不等于整个项目的维护成本同比例变小。

作者把硬件利用率放在选型中心：利用率为 30% 时，推测解码增加的浮点运算可能利用原本闲置的资源；达到 85% 时，草稿模型就可能与正常业务争抢算力，抬高有效服务成本。

因此，有算力余量、又要求保持大模型质量的场景，更适合先评估推测解码。机器持续高负载、成本约束更强的场景，则更有理由考虑蒸馏。

两者还能叠加：先蒸馏出较小的服务模型，再让更小的草稿模型为它做推测解码。此时，质量变化来自蒸馏，额外提速取决于草稿接受率。推测解码不会恢复蒸馏已经损失的能力。

评测也要拆开看。首 token 时间（TTFT）决定用户多久看到第一点内容；token 间延迟决定内容开始输出后是否顺畅。推测解码可能改善后者，却因为多了前置草稿步骤而拖慢前者。

作者还要求在生产流量上测接受率，按明确评分规则检查长尾质量，并把重训频率算进成本。只测一组熟悉题目，容易同时高估草稿效果和学生能力。

我认同作者把「减少等待」和「减少模型工作量」分开讨论。对团队来说，保留原模型与替换原模型，确实是两种不同的质量责任。

但原文更像工程经验框架，缺少可复核的对照实验。它没有交代草稿长度、并发规模、硬件配置，也没有给出蒸馏前后的具体质量结果，因而不足以证明组合方案「通常最优」。

开头的数字也要留个问号：作者称用户大约能容忍 200 毫秒的 token 间隔，又称单加速器上的 70B 模型每个 token 耗时约 40 毫秒，状态差时约 100 毫秒。后两者都低于前述阈值，仅凭这些数字还推不出明显的体验缺口，仍需考察排队和实际输出波动。

「闲置算力免费」同样说得过满。已有容量也有能耗和运维成本，30% 与 85% 更不是普适阈值。对调用托管 API 的团队，能否使用这些优化，还取决于服务商开放了哪些能力。

至于「先做可逆优化」，我赞成把它当作优先级原则。但缓存、预计算也有维护成本，蒸馏也能通过切回原模型回退。真正的区别，是回退后还能否保住原先争取到的成本和容量收益。