跨国深谈← 返回←让小模型先猜，大模型来批：推理加速值不值？

让小模型先猜，大模型来批：推理加速值不值？

关联

人物 Sheila

公司 Akamai

概念 投机解码 · 草稿模型 · 接受率 · KVCache · 推理 · GPU · vLLM

大语言模型回答问题分两步：先读你的输入，建一份“工作记忆”（叫 KVCache），这一步只做一次；然后开始逐字写答案。

因为每个词都依赖前一个词，生成只能一个一个来。

如果你用的是 Llama 70B 这样的大模型，一次回答可能要跑上百次前向计算，又贵又慢。

speculative decoding 的思路是：别让大模型亲自写每个词。让一个小模型先“猜”几个词，大模型一次性验证。猜对了就白赚，猜错了大模型重算。

输出结果不变——大模型仍然把着准确性的关，只是活儿变少了 。

小模型怎么选？

通常每个周期让小模型猜 3 到 5 个词，大模型批量审批，被拒的词由它重新计算 。选草稿模型有几条经验法则：

一是要小，一般比目标模型小 10 到 50 倍；

二是必须用同一套分词器，最好来自同一个模型家族，否则你得在两套分词器之间手动转换 ；

剩下的就是权衡成本和准确率。

Sheila 的演示环境只有一块 Blackwell GPU，还要同时跑基线和投机解码两套服务，所以模型要选得足够小：

基线模型权重约 16GB，草稿模型只有 2.5GB，剩下的空间留给两边的缓存 。

它不是免费的

代价很直接：你要同时托管两个模型，显存要多分一份给草稿模型，两边的 KVCache 也都要额外空间 。

所以判断标准很简单——你的 GPU 有没有闲着的算力？

如果是高并发场景，GPU 本来就忙不过来，开投机解码反而添乱；如果余量充足，才值得考虑 。

什么任务有效？看“接受率”

核心指标是接受率：草稿模型生成的词里，被大模型认可的比例 。这个比例高低，取决于任务类型。

高度结构化的任务最受益——写代码、生成 JSON、写 SQL。这类任务的下一个词几乎是确定的，小模型猜得准。

Sheila 的现场演示里，结构化输出任务开了投机解码后快了 1.6 倍，接受率很高，每秒生成的词数也明显提升 。

反过来，创意型任务——写诗、头脑风暴——温度设得高，下一个词的可能性本来就多，小模型猜不中，接受率很低，加速效果就差 。

长上下文任务也要小心

投机解码只加速“写答案”那一步，不加速“读输入”那一步 。

如果你的应用要喂给模型大量上下文——比如检索增强生成、分析长文档——而真正要生成的答案很短，模型大部分时间都花在建缓存上，投机解码帮不了什么忙。

所以要问自己几个问题：你的应用是结构化输出吗？显存够吗？是创意场景吗？并发高不高？

批量小、显存有余的结构化任务，是最理想的候选 。

想上手的话

Sheila 用的是 vLLM 这个推理服务引擎，文档写得不错。这是最简单的一种投机解码实现，还有 Ngram、Medusa、Eagle 等更进阶的架构 。

网上相关内容不多，她推荐了 General Compute 的博客和 Google 等发表的研究论文；Akamai 的 GitHub（Akamai developers）上有完整的复现教程 。

本集带走

• 大模型回答慢在逐词生成；让小模型先猜几个词、大模型批量验证，可以在不损失准确性的前提下加速。
• 代价是要多托管一个模型、多占显存——GPU 已经很忙的高并发场景不适合开。
• 接受率是关键指标：写代码、JSON、SQL 这类结构化任务接受率高；写诗、头脑风暴这类创意任务接受率低。
• 演示中结构化任务提速 1.6 倍。
• 投机解码只加速生成阶段，读长上下文（如检索增强生成）占大头的任务收益有限；上手推荐 vLLM。

高并发情况下，你的 GPU 可能已经在忙于处理所有请求了，这时实现投机解码就没有意义；但如果你有多余的 GPU 空间，就值得考虑。
High concurrency, your GPUs are probably already busy trying to run all the requests, so it wouldn’t make sense to implement speculative decoding, but if you have extra GPU space, it’s worth considering.
—— Sheila · [03:10]