标题里带“VLLM”很多人第一反应是vLLM又出新功能了其实这里说的推测解码Speculative Decoding不是vLLM独有的社区里很多推理框架都在做但vLLM因为用户基数大、迭代快把这套技术从论文搬到了生产环境。我自己第一次看到“推测解码”这四个字的时候也懵了一下直觉上“推测”这词不像工程术语倒像算命。但真跑通之后才发现这玩意儿一点都不玄学它解决的就是大模型推理“一个字一个字往外蹦”这个天然瓶颈。如果你正在做大模型推理服务或者你只是想知道怎么让手里的模型跑得更快、GPU利用率更高这篇文章就是给你写的。我会从原理讲到配置再讲到我实际踩过的坑尽量让完全没接触过的人也能看懂。1. 推测解码到底在解决什么问题为什么能加速1.1 LLM推理慢的根源要理解推测解码先得搞明白大模型为什么慢。别看现在各家模型动不动几百亿参数但生成一个token的过程本质上还是“一步一步来”你输入一句话模型输出第一个词然后把这个词拼回去再预测下一个词。每一步都要求把整个模型前向推理一遍而这一步只能串行进行没法并行。这就好比你去银行柜台办事一次只能处理一个顾客无论柜台后面有多少员工在闲着轮到你的窗口始终是那个节奏。GPU确实很强但在自回归生成场景下每一步只有一个token的依赖关系计算单元大部分时间都在“等上一步的结果”。显存带宽和计算能力没法充分拉满利用率可能只有一小半。此外大模型的显存占用也高参数动辄几十G推理时要把权重全部加载到显存里。每一步计算都要读取全部权重这导致很多情况下瓶颈其实是显存带宽而不是算力。于是人们就琢磨能不能一次性多猜几个词再让大模型一次性验证这样同样一次前向传播却能产出多个token相当于把串行循环改成“批量循环”。1.2 推测解码的核心思想让小模型先猜大模型负责验证推测解码的思路很直白你不是慢吗那我先拿一个速度快、参数量小的小模型去“打草稿”一口气生成K个连续token。然后拿着这K个token拼到原始输入后面一起丢给大模型做一次前向计算。大模型会同时给出这K个位置各自的预测分布然后我们逐个检查小模型猜的token到底“对上”了大模型的判断没有。如果小模型猜测的某个token恰好就是大模型在这个位置概率最高的token或者满足某个接受条件那我们直接采用如果对不上就从这个位置回退用大模型自己的预测结果重新生成。这个过程叫“验证”。一次验证能接受几个token这次前向计算就算“赚到”了几个token的生成量。乍一听有点绕但打个比方就清楚了小模型是“实习生”写了一份初稿大模型是“主编”拿着初稿快速过一遍。如果实习生写得靠谱主编只需要批个“同”就能一次通过好几句写得不靠谱的地方主编自己动笔改。重点在于主编审稿是一整段审而不是一句话一句话逼着秘书念。1.3 为什么这能大幅加速一次验证批量生产这里的关键在于大模型一次前向传播不仅能算出一个token的概率分布而是能同时算出输入序列里所有位置的下一个token分布。你给它输入“今天天气真”它能预测出“好”但如果你把“今天天气真好啊”整句喂进去它能同时算出“好”后面的“啊”应该是什么。也就是说大模型一次前向计算可以验证多个位置的预测结果而不必真的把每个新token重新拼回去再算一次。所以推测解码的加速来自于用多次小模型的前向传播换一次大模型的前向传播。小模型前向传播便宜大模型前向传播贵。如果小模型猜得准大模型一次验证能接受四五个token那等于把四次大模型串行计算合并成了一次速度自然直线上升。但要注意推测解码不是改变生成质量它只是一个“无损加速”策略。如果小模型瞎猜大模型全部打回那不仅没有加速反而白白多算了小模型的生成时间。所以草稿模型的质量直接决定这个方案能不能真正提升吞吐量。2. 两个关键角色草稿模型与目标模型2.1 草稿模型的选择标准和常见候选草稿模型Draft Model是推测解码里的“实习生”。它必须满足几个条件第一生成速度要足够快一般参数要比目标模型小很多第二生成风格和知识分布要尽量贴近目标模型否则猜出来的东西老是被拒绝加速比会很难看第三词表要一致这是硬性要求后面我会详细说为什么。在vLLM社区里常见的搭配组合包括目标模型用某个7B甚至70B的模型草稿模型则选用同系列的小版本比如1B或3B。为什么强调同系列因为同系列模型通常共享tokenizer和词表而且训练数据的分布和模型行为方式高度相似草稿被接受的概率会明显高一些。跨系列搭配不是完全不行但很容易出现词表不一致的问题需要进行映射处理操作起来麻烦加速效果也未必好。比较合适的草稿模型大小通常选择目标模型的1/10到1/5。比如7B的目标模型配0.5B到1B的草稿模型比较常见70B的目标模型配7B左右的草稿模型。这里没有绝对公式因为跟显存带宽、batch大小、任务类型都相关但基本逻辑是草稿模型太大会显著增加额外延迟让“小成本换大收益”的账算不过来草稿模型太小则预测能力太弱老是被拒绝同样不划算。2.2 目标模型与草稿模型之间的配合逻辑目标模型就是我们真正要部署的服务模型它决定了最终输出质量。在推测解码流程里目标模型的主要工作不是逐个生成而是“批量验证”。它接收的新输入是原始上下文加上草稿模型预测出来的K个token。例如原始输入是“请写一句关于春天的诗”当前已经生成到“春风又绿”草稿模型快速预测了后面5个token分别为“江”“南”“岸”“明”“月”。那么目标模型前向计算时直接处理整个序列“……春风又绿江南岸明月”并计算出每个位置上的概率分布。接下来进入“接受/拒绝”判断从第一个预测token开始检查草稿预测的“江”是否在目标模型的top概率列表中。如果是则接受然后继续检查“南”直到遇到第一个不被接受的token后续的草稿token全部丢弃改为从当前断点开始使用目标模型的预测token重新生成。整个过程可以看成一个贪心匹配但为了保持原始采样的随机性实际实现里通常会用“基于概率的随机接受”方式也就是即便草稿token不是最高概率只要它落在目标模型的采样概率范围内仍有一定机会被接受。这才能保证推测解码后的采样分布和原始目标模型单独推理的分布一致。2.3 接受率如何决定加速效果接受率Accept Rate是推测解码里最核心的指标。它指的是草稿模型预测的K个token中能被目标模型接受的比例。如果接受率接近1那几乎是草稿模型生成一次目标模型验证一次就能直接吐出K个token加速显著如果接受率很低比如10%那每次验证只通过了零点几个token额外还多花了草稿模型生成的时间反而更慢。从概率上说接受率越大最优的推测长度K也越大。打个比方如果你草稿质量高哪怕一次猜20个token也有很大概率全被接受那大模型一次前向就顶20次效率很恐怖如果草稿质量差猜2个就错一个那K再大也没用因为断点往往出现在前几个位置后面的token全是白算。实际操作中我们一般先跑一个小批量测试统计不同K值下的平均接受token数然后选一个让期望收益最大的K。vLLM里对应参数一般是num_speculative_tokens默认值可能是4到5但这个值并非越大越好。我用下来感觉K4到6在多数场景下收益最佳过大时会增加显存和计算的无谓消耗过小则掩盖不了大模型单步推理的延迟。3. vLLM社区中的推测解码配置实战3.1 vLLM中推测解码的基本参数如果你用的是vLLM打开文档会发现它已经把推测解码集成了不需要自己实现复杂的验证逻辑。我们只需要指定草稿模型再控制几个关键参数就能跑起来。最基本的一组启动参数大致如下--model目标模型路径也就是你要部署的主力模型。--speculative-model草稿模型路径可以是本地路径也可以是模型仓库里的名称。--num-speculative-tokens草稿模型一次生成“猜几个词”一般设置在1到10之间推荐先试4或5。--speculative-draft-tensor-parallel-size草稿模型使用的张量并行大小。因为草稿模型一般比较小有时候不需要和主模型一样的并行度。--speculative-max-model-len草稿模型最大序列长度通常建议不小于目标模型的长度否则长的上下文下可能截断。除了这些vLLM还有一些内部参数控制草稿模型的内存管理、接受策略等但普通使用场景我们只需要关心上面这几个。这里必须提醒一下如果你用的是较早版本的vLLM参数名可能略微不同。有的版本用--draft_model有的版本统一改成--speculative_model。最好先查一下对应版本的接口文档免得辛辛苦苦配了半天加载时报“unknown argument”。3.2 一个可参考的启动命令与模型选择为了直观我给你一个可参考的启动示例。假设目标模型是某个开源7B模型草稿模型是同系列的1B模型且两块卡的显存都比较宽裕你可以这样启动python -m vllm.entrypoints.openai.api_server \ --model /models/llama-7b-hf \ --speculative-model /models/llama-1b-hf \ --num-speculative-tokens 5 \ --tensor-parallel-size 1 \ --speculative-draft-tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 4096如果你目标模型用的是70B规模那就得考虑张量并行。比如目标模型用4卡草稿模型用1卡就好命令里可以加上--tensor-parallel-size 4 \ --speculative-draft-tensor-parallel-size 1 \这样草稿模型只占一张卡目标模型占用四张卡。需要注意的是草稿模型与目标模型的数据通信需要走GPU间高速通道如果两张卡之间的带宽不够可能会出现“通信时间超过计算时间”的情况加速效果会被明显削弱。关于模型选择我自己的实测经验是优先选和目标模型同系列的小版本千万别拍脑袋找一个不同tokenizer的模型。同一个系列意味着两者词表完全一致预测的语义风格也比较接近省掉很多麻烦。实在找不到同系列就选一个词表兼容的小模型然后自己写一个词表映射。但那样实现的难度和维护成本都不小非必要不建议尝试。3.3 采样参数对推测解码的影响推测解码有一个隐藏的“坑”采样参数不一致会导致接受率大幅波动甚至直接破坏无损加速的保证。原理很简单vLLM的推测解码在验证时会使用目标模型当前的采样配置来决定是否接受草稿token。比如你设定了温度0.8top_p0.9那么目标模型计算出的概率分布经过采样后草稿token可能以某个概率被接受。但如果你的采样配置和草稿模型训练时的分布差异太大比如把温度调得特别高草稿模型原本很有把握的token在高温采样下变得不突出接受率就会变低。更麻烦的是如果你在推理时使用top_k或top_p这些截断采样目标模型可能把一些低概率token直接排除在外草稿模型却不知道这回事于是大量草稿token被拒绝。我建议尽量让草稿模型和目标模型使用相同的采样参数或者至少在推理时不要用过高的温度。vLLM社区里也有人专门尝试在不同温度下测试接受率结论是温度在1.0附近时表现比较稳定当温度超过1.5以后加速比会明显下降。如果你确实需要高温生成的创意场景那推测解码的收益就要重新评估了不要指望它还能保持1.8倍以上的加速。4. 实测效果怎么评估加速比从哪里来4.1 评测指标TTFT与ITL/TG聊到加速就不能不先定义“快”的标准。大模型推理服务常见的性能指标有两个TTFTTime To First Token首token延迟和ITLInter-Token Latency单词间隔延迟也常被称为TPOT/TGToken Generation time。其中TTFT主要受预填充阶段影响由于推测解码在处理用户输入时并没有多token可猜测所以对TTFT的改善十分有限。它真正强的地方在于降低ITL也就是连续生成token的间隔时间。举个例子目标模型每秒只能生成30个token加上推测解码后每秒能达到60到70个token。那么对用户体验而言同样的对话里每个字蹦出来的速度明显变快流畅感提升显著。但如果你的业务非常在意首回复时间那么推测解码并不能带来质的改变这时候更应该考虑优化预填充、KV Cache命中率甚至换用更激进的前缀缓存方案。4.2 不同场景下的加速比实测我在日常测试中主要跑了代码生成、通用对话、结构化输出三种场景。结果差异挺明显。代码生成场景下草稿模型对“括号配对、分号结尾、模板化代码”这类规律性很强的文本预测特别准接受率常常能到0.7以上实测加速比在1.8到2.5倍之间。通用对话场景的预测难度稍高因为对话内容更自由接受率通常在0.5到0.6加速比掉到1.5倍左右。结构化输出比如强制输出JSON、约束输出格式反而很有意思如果模型本身接受了结构化指令训练草稿模型面对固定格式时预测非常稳定接受率甚至比代码生成还高。需要注意的是这些数字都是我在单卡、低并发场景下测出来的。如果服务端并发很高多个请求会合成一个batch处理推测解码的收益会变得更复杂。因为batch变大会让目标模型单次前向的代价变高但如果草稿模型的batch也同样变大那么它生成K个token的总代价也会成比例上升加速比的结论不能简单照搬。4.3 影响加速比的隐藏因素还有一个容易被忽略的因素显存带宽。推测解码虽然能减少目标模型的前向次数但并没有减少总计算量反而增加了草稿模型的计算。当两者的权重同时从显存搬到计算核心时对显存带宽的要求更高。如果你的GPU是那种“算力强但带宽相对有限”的型号加速比也许会比理论上限低很多。另外输入序列长度也会影响收益。因为草稿模型生成的是“未来K个token”它自己也需要把之前的整个上下文都过一遍。上下文越长草稿模型每一步生成的时间也越长即便目标模型验证很快整体的额外开销也在增加。所以短文本场景里的加速收益会比长文本场景更明显。我在实践中的一个经验是开启推测解码后不要只看“每秒生成token数”这一个指标最好同时观察GPU利用率、显存占用量和平均接受率。vLLM的日志里通常会有一些统计信息或者你可以在工作台里查看GPU监控。如果你发现GPU利用率和之前差不多但显存占用多了几GB那大概率是草稿模型带来的开销超过了收益应该考虑换更小的草稿模型或减少K值。5. 实操中踩过的坑与排查技巧5.1 草稿模型与目标模型的词表不匹配导致崩溃这个坑可能是所有做推测解码的新手都会遇到的。词表不匹配一般有两种表现一种是启动时直接报错提示vocabulary size mismatch另一种是启动不报错但推理时生成的token是乱的甚至偶尔崩掉。出现这种情况往往是因为草稿模型和目标模型的tokenizer不是同一个体系。比如目标模型用的是BPE词表草稿模型用的是SentencePiece词表即使两个模型的词表大小恰好一致排序也可能完全不同。你让草稿模型输出一个“token id42”目标模型可能把它理解为“token id42对应的另一个词”那整个验证过程就没有意义了。解决方案很简单换同系列模型或者确认两个模型都使用相同的tokenizer文件。在vLLM的GitHub和社区讨论里官方对这个问题也给了明确说明就是为了让用户避免这种不匹配。所以选草稿模型之前先检查一下两个模型的tokenizer_config.json是否一致最稳的做法就是直接用同一个tokenizer目录下的模型。5.2 温度参数与推测解码的冲突我之前遇到一个很有意思的问题服务端设定的温度是默认的1.0跑推测解码一切正常。后来产品经理要求把温度调到1.2以增强创造力然后线上就出现“生成速度变慢”的反馈。一开始还以为是并发问题后来发现是温度变化连累了接受率。原因前面已经分析过温度升高会改变目标模型的采样分布让高概率token的概率被摊平草稿模型原本“有把握”的token不再那么被认可。这个问题在社区里讨论过很多次示例模型不同、采样参数不同接受率都会有波动。我的建议是如果你的业务场景依赖高温采样先别上推测解码或者只把K值调到2或3。如果你必须既高温又高加速那就需要重新训练一个在高温采样下依然预测精准的草稿模型这个工程成本就比较大了。5.3 显存不足时怎么折中推测解码需要额外加载一个草稿模型这会平白多出几百MB到几GB的显存开销。如果你手头的GPU卡显存刚刚好能装下目标模型再塞一个草稿模型就会OOM。这时候有几个折中方案。第一使用更小的草稿模型比如0.5B级别显存占用能控制在1GB以内。第二减少num_speculative_tokens因为每个推测token都需要在草稿模型内缓存KVK值减小能降低缓存开销。第三如果vLLM支持将草稿模型放到CPU上或者使用独立的更小卡可以把草稿模型和大模型分开部署但这需要硬件拓扑支持不能随便给一个通用方案。还有一种思路不用单独的草稿模型而是用目标模型自身的前几层或者一个提前退出分支来做草稿。这种“自草稿”方案在学术圈讨论得不少但vLLM社区目前主要还是支持独立草稿模型自草稿更多以研究形式存在。如果显存太紧可以考虑等社区后续支持。5.4 常见问题速查表整理一张速查表方便你出了问题快速排查。现象可能原因处置建议启动时报vocabulary mismatch草稿模型与目标模型词表不一致更换同系列模型或统一tokenizer推理速度比不开推测解码还慢草稿模型太大或K值太大接受率低换更小草稿模型减小K值观察接受率生成内容质量异常、乱码温度等采样参数不一致统一采样参数重开服务开启后显存不足额外加载草稿模型及KV缓存减小草稿模型大小降低K值或分离部署收益只在长序列场景明显短序列表征不明显不一定要开推测解码考虑其他优化6. 推测解码的下一步从单卡到多卡从固定到动态6.1 草稿模型与目标模型分离部署如果你已经跑通了单机单卡或单机多卡的基础推测解码接下来值得关注的是草稿模型和目标模型分离部署。因为在实际生产环境里目标模型往往是7B或70B的主管模型草稿模型只是辅助两个模型挤在同一张卡上会互相抢显存、抢带宽。分离部署的好处很明显草稿模型可以放在一张廉价的推理卡上目标模型独占高性能卡两者通过高速网络通信。但这也带来了通信延迟。如果草稿模型生成100个token耗时5毫秒结果传到目标模型那边用了5毫秒那收益就被吃掉了大半。所以分离部署的前提是拥有足够快的卡间通信通道。在vLLM社区里已经有针对多卡模式下草稿模型并行策略的优化讨论比如让草稿模型也使用张量并行只不过并行度远低于目标模型。这种配置适合大规模部署场景如果你只是自己本地玩一玩暂时没必要搞这么复杂。6.2 动态草稿模型与并行解码方案固定一个草稿模型从头用到尾并不是所有场景下的最优解。因为用户输入的模式随时在变化例如先让模型写代码然后又聊情感话题单个草稿模型很难一直都在高水平上猜测。业内已经在尝试动态草稿模型也就是根据当前对话的“语境”在多个草稿模型中切换或者动态调整K值。这一点在vLLM的Roadmap里也有提及但功能尚不稳定需要社区的持续迭代。另一个方向是“并行解码”思路比如一次让草稿模型生成多个候选序列目标模型并行验证从中选出最佳接受结果。这种方式在小模型上尝试过可以把接受率低的问题通过多候选来对冲。代价是生成多个候选序列本身就有开销需要更精细的调度策略。如果你对这些方向感兴趣可以去读几篇相关的论文比如关于推测采样、并行块验证的早期工作。vLLM的实现本身也吸收了不少论文里的思想但工程上做了很多适配比如如何在异步调度中处理草稿模型的生成。6.3 你可以在哪里找到参考实现vLLM的官方仓库和文档里推测解码的说明已经比较完整了。社区里也有不少已经合并的PR和issue讨论里面有不少用户实测数据、模型搭配经验和参数调整心得。如果你想更深入地看实现细节可以搜索一下vLLM源码中关于spec_decode的目录仔细读一读它的worker和metrics逻辑能学到很多工程细节。但读源码时有个小小的提醒不要被里面各种抽象类绕晕。你只需要抓住一条主线草稿模型如何生成token序列目标模型如何做批量验证以及两者的KV Cache如何管理。理解了这三个环节你基本就掌握了推测解码的工程脉络。我个人在实际操作中的体会是推测解码不是一个“开了就能起飞”的银弹它对模型搭配、采样参数、场景类型都很敏感。但只要耐心调一遍尤其是把草稿模型选对、K值调合适它带来的提速体验真的是立竿见影的。有一次我部署一个代码生成服务只是把K值从4调到6接受率就明显上升首屏的token吞吐直接提升了接近一倍当时挺感慨原来优化并不总是复杂的新架构有时关键就在对系统瓶颈的判断上。最后再分享一个小技巧如果你在调参时拿不准最优的K值可以先跑一段固定输入然后用日志里的接受率统计来“反向”找最优值。接受率高就尝试加大K接受率低就减小K直到单位时间内生成token数达到峰值。这个方法虽然笨但比盲目相信默认参数可靠得多。推测解码在社区里已经不算新概念了但真正能把它用好、调优、部署到生产中的人往往也就是多做了这一步细致的测量和迭代。 
长河君 · 2026/10/21 21:32:32 · 阅读 1.2k vLLM推测解码实战：草稿模型让大模型推理提速
标题里带“VLLM”很多人第一反应是vLLM又出新功能了其实这里说的推测解码Speculative Decoding不是vLLM独有的社区里很多推理框架都在做但vLLM因为用户基数大、迭代快把这套技术从论文搬到了生产环境。我自己第一次看到“推测解码”这四个字的时候也懵了一下直觉上“推测”这词不像工程术语倒像算命。但真跑通之后才发现这玩意儿一点都不玄学它解决的就是大模型推理“一个字一个字往外蹦”这个天然瓶颈。如果你正在做大模型推理服务或者你只是想知道怎么让手里的模型跑得更快、GPU利用率更高这篇文章就是给你写的。我会从原理讲到配置再讲到我实际踩过的坑尽量让完全没接触过的人也能看懂。1. 推测解码到底在解决什么问题为什么能加速1.1 LLM推理慢的根源要理解推测解码先得搞明白大模型为什么慢。别看现在各家模型动不动几百亿参数但生成一个token的过程本质上还是“一步一步来”你输入一句话模型输出第一个词然后把这个词拼回去再预测下一个词。每一步都要求把整个模型前向推理一遍而这一步只能串行进行没法并行。这就好比你去银行柜台办事一次只能处理一个顾客无论柜台后面有多少员工在闲着轮到你的窗口始终是那个节奏。GPU确实很强但在自回归生成场景下每一步只有一个token的依赖关系计算单元大部分时间都在“等上一步的结果”。显存带宽和计算能力没法充分拉满利用率可能只有一小半。此外大模型的显存占用也高参数动辄几十G推理时要把权重全部加载到显存里。每一步计算都要读取全部权重这导致很多情况下瓶颈其实是显存带宽而不是算力。于是人们就琢磨能不能一次性多猜几个词再让大模型一次性验证这样同样一次前向传播却能产出多个token相当于把串行循环改成“批量循环”。1.2 推测解码的核心思想让小模型先猜大模型负责验证推测解码的思路很直白你不是慢吗那我先拿一个速度快、参数量小的小模型去“打草稿”一口气生成K个连续token。然后拿着这K个token拼到原始输入后面一起丢给大模型做一次前向计算。大模型会同时给出这K个位置各自的预测分布然后我们逐个检查小模型猜的token到底“对上”了大模型的判断没有。如果小模型猜测的某个token恰好就是大模型在这个位置概率最高的token或者满足某个接受条件那我们直接采用如果对不上就从这个位置回退用大模型自己的预测结果重新生成。这个过程叫“验证”。一次验证能接受几个token这次前向计算就算“赚到”了几个token的生成量。乍一听有点绕但打个比方就清楚了小模型是“实习生”写了一份初稿大模型是“主编”拿着初稿快速过一遍。如果实习生写得靠谱主编只需要批个“同”就能一次通过好几句写得不靠谱的地方主编自己动笔改。重点在于主编审稿是一整段审而不是一句话一句话逼着秘书念。1.3 为什么这能大幅加速一次验证批量生产这里的关键在于大模型一次前向传播不仅能算出一个token的概率分布而是能同时算出输入序列里所有位置的下一个token分布。你给它输入“今天天气真”它能预测出“好”但如果你把“今天天气真好啊”整句喂进去它能同时算出“好”后面的“啊”应该是什么。也就是说大模型一次前向计算可以验证多个位置的预测结果而不必真的把每个新token重新拼回去再算一次。所以推测解码的加速来自于用多次小模型的前向传播换一次大模型的前向传播。小模型前向传播便宜大模型前向传播贵。如果小模型猜得准大模型一次验证能接受四五个token那等于把四次大模型串行计算合并成了一次速度自然直线上升。但要注意推测解码不是改变生成质量它只是一个“无损加速”策略。如果小模型瞎猜大模型全部打回那不仅没有加速反而白白多算了小模型的生成时间。所以草稿模型的质量直接决定这个方案能不能真正提升吞吐量。2. 两个关键角色草稿模型与目标模型2.1 草稿模型的选择标准和常见候选草稿模型Draft Model是推测解码里的“实习生”。它必须满足几个条件第一生成速度要足够快一般参数要比目标模型小很多第二生成风格和知识分布要尽量贴近目标模型否则猜出来的东西老是被拒绝加速比会很难看第三词表要一致这是硬性要求后面我会详细说为什么。在vLLM社区里常见的搭配组合包括目标模型用某个7B甚至70B的模型草稿模型则选用同系列的小版本比如1B或3B。为什么强调同系列因为同系列模型通常共享tokenizer和词表而且训练数据的分布和模型行为方式高度相似草稿被接受的概率会明显高一些。跨系列搭配不是完全不行但很容易出现词表不一致的问题需要进行映射处理操作起来麻烦加速效果也未必好。比较合适的草稿模型大小通常选择目标模型的1/10到1/5。比如7B的目标模型配0.5B到1B的草稿模型比较常见70B的目标模型配7B左右的草稿模型。这里没有绝对公式因为跟显存带宽、batch大小、任务类型都相关但基本逻辑是草稿模型太大会显著增加额外延迟让“小成本换大收益”的账算不过来草稿模型太小则预测能力太弱老是被拒绝同样不划算。2.2 目标模型与草稿模型之间的配合逻辑目标模型就是我们真正要部署的服务模型它决定了最终输出质量。在推测解码流程里目标模型的主要工作不是逐个生成而是“批量验证”。它接收的新输入是原始上下文加上草稿模型预测出来的K个token。例如原始输入是“请写一句关于春天的诗”当前已经生成到“春风又绿”草稿模型快速预测了后面5个token分别为“江”“南”“岸”“明”“月”。那么目标模型前向计算时直接处理整个序列“……春风又绿江南岸明月”并计算出每个位置上的概率分布。接下来进入“接受/拒绝”判断从第一个预测token开始检查草稿预测的“江”是否在目标模型的top概率列表中。如果是则接受然后继续检查“南”直到遇到第一个不被接受的token后续的草稿token全部丢弃改为从当前断点开始使用目标模型的预测token重新生成。整个过程可以看成一个贪心匹配但为了保持原始采样的随机性实际实现里通常会用“基于概率的随机接受”方式也就是即便草稿token不是最高概率只要它落在目标模型的采样概率范围内仍有一定机会被接受。这才能保证推测解码后的采样分布和原始目标模型单独推理的分布一致。2.3 接受率如何决定加速效果接受率Accept Rate是推测解码里最核心的指标。它指的是草稿模型预测的K个token中能被目标模型接受的比例。如果接受率接近1那几乎是草稿模型生成一次目标模型验证一次就能直接吐出K个token加速显著如果接受率很低比如10%那每次验证只通过了零点几个token额外还多花了草稿模型生成的时间反而更慢。从概率上说接受率越大最优的推测长度K也越大。打个比方如果你草稿质量高哪怕一次猜20个token也有很大概率全被接受那大模型一次前向就顶20次效率很恐怖如果草稿质量差猜2个就错一个那K再大也没用因为断点往往出现在前几个位置后面的token全是白算。实际操作中我们一般先跑一个小批量测试统计不同K值下的平均接受token数然后选一个让期望收益最大的K。vLLM里对应参数一般是num_speculative_tokens默认值可能是4到5但这个值并非越大越好。我用下来感觉K4到6在多数场景下收益最佳过大时会增加显存和计算的无谓消耗过小则掩盖不了大模型单步推理的延迟。3. vLLM社区中的推测解码配置实战3.1 vLLM中推测解码的基本参数如果你用的是vLLM打开文档会发现它已经把推测解码集成了不需要自己实现复杂的验证逻辑。我们只需要指定草稿模型再控制几个关键参数就能跑起来。最基本的一组启动参数大致如下--model目标模型路径也就是你要部署的主力模型。--speculative-model草稿模型路径可以是本地路径也可以是模型仓库里的名称。--num-speculative-tokens草稿模型一次生成“猜几个词”一般设置在1到10之间推荐先试4或5。--speculative-draft-tensor-parallel-size草稿模型使用的张量并行大小。因为草稿模型一般比较小有时候不需要和主模型一样的并行度。--speculative-max-model-len草稿模型最大序列长度通常建议不小于目标模型的长度否则长的上下文下可能截断。除了这些vLLM还有一些内部参数控制草稿模型的内存管理、接受策略等但普通使用场景我们只需要关心上面这几个。这里必须提醒一下如果你用的是较早版本的vLLM参数名可能略微不同。有的版本用--draft_model有的版本统一改成--speculative_model。最好先查一下对应版本的接口文档免得辛辛苦苦配了半天加载时报“unknown argument”。3.2 一个可参考的启动命令与模型选择为了直观我给你一个可参考的启动示例。假设目标模型是某个开源7B模型草稿模型是同系列的1B模型且两块卡的显存都比较宽裕你可以这样启动python -m vllm.entrypoints.openai.api_server \ --model /models/llama-7b-hf \ --speculative-model /models/llama-1b-hf \ --num-speculative-tokens 5 \ --tensor-parallel-size 1 \ --speculative-draft-tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 4096如果你目标模型用的是70B规模那就得考虑张量并行。比如目标模型用4卡草稿模型用1卡就好命令里可以加上--tensor-parallel-size 4 \ --speculative-draft-tensor-parallel-size 1 \这样草稿模型只占一张卡目标模型占用四张卡。需要注意的是草稿模型与目标模型的数据通信需要走GPU间高速通道如果两张卡之间的带宽不够可能会出现“通信时间超过计算时间”的情况加速效果会被明显削弱。关于模型选择我自己的实测经验是优先选和目标模型同系列的小版本千万别拍脑袋找一个不同tokenizer的模型。同一个系列意味着两者词表完全一致预测的语义风格也比较接近省掉很多麻烦。实在找不到同系列就选一个词表兼容的小模型然后自己写一个词表映射。但那样实现的难度和维护成本都不小非必要不建议尝试。3.3 采样参数对推测解码的影响推测解码有一个隐藏的“坑”采样参数不一致会导致接受率大幅波动甚至直接破坏无损加速的保证。原理很简单vLLM的推测解码在验证时会使用目标模型当前的采样配置来决定是否接受草稿token。比如你设定了温度0.8top_p0.9那么目标模型计算出的概率分布经过采样后草稿token可能以某个概率被接受。但如果你的采样配置和草稿模型训练时的分布差异太大比如把温度调得特别高草稿模型原本很有把握的token在高温采样下变得不突出接受率就会变低。更麻烦的是如果你在推理时使用top_k或top_p这些截断采样目标模型可能把一些低概率token直接排除在外草稿模型却不知道这回事于是大量草稿token被拒绝。我建议尽量让草稿模型和目标模型使用相同的采样参数或者至少在推理时不要用过高的温度。vLLM社区里也有人专门尝试在不同温度下测试接受率结论是温度在1.0附近时表现比较稳定当温度超过1.5以后加速比会明显下降。如果你确实需要高温生成的创意场景那推测解码的收益就要重新评估了不要指望它还能保持1.8倍以上的加速。4. 实测效果怎么评估加速比从哪里来4.1 评测指标TTFT与ITL/TG聊到加速就不能不先定义“快”的标准。大模型推理服务常见的性能指标有两个TTFTTime To First Token首token延迟和ITLInter-Token Latency单词间隔延迟也常被称为TPOT/TGToken Generation time。其中TTFT主要受预填充阶段影响由于推测解码在处理用户输入时并没有多token可猜测所以对TTFT的改善十分有限。它真正强的地方在于降低ITL也就是连续生成token的间隔时间。举个例子目标模型每秒只能生成30个token加上推测解码后每秒能达到60到70个token。那么对用户体验而言同样的对话里每个字蹦出来的速度明显变快流畅感提升显著。但如果你的业务非常在意首回复时间那么推测解码并不能带来质的改变这时候更应该考虑优化预填充、KV Cache命中率甚至换用更激进的前缀缓存方案。4.2 不同场景下的加速比实测我在日常测试中主要跑了代码生成、通用对话、结构化输出三种场景。结果差异挺明显。代码生成场景下草稿模型对“括号配对、分号结尾、模板化代码”这类规律性很强的文本预测特别准接受率常常能到0.7以上实测加速比在1.8到2.5倍之间。通用对话场景的预测难度稍高因为对话内容更自由接受率通常在0.5到0.6加速比掉到1.5倍左右。结构化输出比如强制输出JSON、约束输出格式反而很有意思如果模型本身接受了结构化指令训练草稿模型面对固定格式时预测非常稳定接受率甚至比代码生成还高。需要注意的是这些数字都是我在单卡、低并发场景下测出来的。如果服务端并发很高多个请求会合成一个batch处理推测解码的收益会变得更复杂。因为batch变大会让目标模型单次前向的代价变高但如果草稿模型的batch也同样变大那么它生成K个token的总代价也会成比例上升加速比的结论不能简单照搬。4.3 影响加速比的隐藏因素还有一个容易被忽略的因素显存带宽。推测解码虽然能减少目标模型的前向次数但并没有减少总计算量反而增加了草稿模型的计算。当两者的权重同时从显存搬到计算核心时对显存带宽的要求更高。如果你的GPU是那种“算力强但带宽相对有限”的型号加速比也许会比理论上限低很多。另外输入序列长度也会影响收益。因为草稿模型生成的是“未来K个token”它自己也需要把之前的整个上下文都过一遍。上下文越长草稿模型每一步生成的时间也越长即便目标模型验证很快整体的额外开销也在增加。所以短文本场景里的加速收益会比长文本场景更明显。我在实践中的一个经验是开启推测解码后不要只看“每秒生成token数”这一个指标最好同时观察GPU利用率、显存占用量和平均接受率。vLLM的日志里通常会有一些统计信息或者你可以在工作台里查看GPU监控。如果你发现GPU利用率和之前差不多但显存占用多了几GB那大概率是草稿模型带来的开销超过了收益应该考虑换更小的草稿模型或减少K值。5. 实操中踩过的坑与排查技巧5.1 草稿模型与目标模型的词表不匹配导致崩溃这个坑可能是所有做推测解码的新手都会遇到的。词表不匹配一般有两种表现一种是启动时直接报错提示vocabulary size mismatch另一种是启动不报错但推理时生成的token是乱的甚至偶尔崩掉。出现这种情况往往是因为草稿模型和目标模型的tokenizer不是同一个体系。比如目标模型用的是BPE词表草稿模型用的是SentencePiece词表即使两个模型的词表大小恰好一致排序也可能完全不同。你让草稿模型输出一个“token id42”目标模型可能把它理解为“token id42对应的另一个词”那整个验证过程就没有意义了。解决方案很简单换同系列模型或者确认两个模型都使用相同的tokenizer文件。在vLLM的GitHub和社区讨论里官方对这个问题也给了明确说明就是为了让用户避免这种不匹配。所以选草稿模型之前先检查一下两个模型的tokenizer_config.json是否一致最稳的做法就是直接用同一个tokenizer目录下的模型。5.2 温度参数与推测解码的冲突我之前遇到一个很有意思的问题服务端设定的温度是默认的1.0跑推测解码一切正常。后来产品经理要求把温度调到1.2以增强创造力然后线上就出现“生成速度变慢”的反馈。一开始还以为是并发问题后来发现是温度变化连累了接受率。原因前面已经分析过温度升高会改变目标模型的采样分布让高概率token的概率被摊平草稿模型原本“有把握”的token不再那么被认可。这个问题在社区里讨论过很多次示例模型不同、采样参数不同接受率都会有波动。我的建议是如果你的业务场景依赖高温采样先别上推测解码或者只把K值调到2或3。如果你必须既高温又高加速那就需要重新训练一个在高温采样下依然预测精准的草稿模型这个工程成本就比较大了。5.3 显存不足时怎么折中推测解码需要额外加载一个草稿模型这会平白多出几百MB到几GB的显存开销。如果你手头的GPU卡显存刚刚好能装下目标模型再塞一个草稿模型就会OOM。这时候有几个折中方案。第一使用更小的草稿模型比如0.5B级别显存占用能控制在1GB以内。第二减少num_speculative_tokens因为每个推测token都需要在草稿模型内缓存KVK值减小能降低缓存开销。第三如果vLLM支持将草稿模型放到CPU上或者使用独立的更小卡可以把草稿模型和大模型分开部署但这需要硬件拓扑支持不能随便给一个通用方案。还有一种思路不用单独的草稿模型而是用目标模型自身的前几层或者一个提前退出分支来做草稿。这种“自草稿”方案在学术圈讨论得不少但vLLM社区目前主要还是支持独立草稿模型自草稿更多以研究形式存在。如果显存太紧可以考虑等社区后续支持。5.4 常见问题速查表整理一张速查表方便你出了问题快速排查。现象可能原因处置建议启动时报vocabulary mismatch草稿模型与目标模型词表不一致更换同系列模型或统一tokenizer推理速度比不开推测解码还慢草稿模型太大或K值太大接受率低换更小草稿模型减小K值观察接受率生成内容质量异常、乱码温度等采样参数不一致统一采样参数重开服务开启后显存不足额外加载草稿模型及KV缓存减小草稿模型大小降低K值或分离部署收益只在长序列场景明显短序列表征不明显不一定要开推测解码考虑其他优化6. 推测解码的下一步从单卡到多卡从固定到动态6.1 草稿模型与目标模型分离部署如果你已经跑通了单机单卡或单机多卡的基础推测解码接下来值得关注的是草稿模型和目标模型分离部署。因为在实际生产环境里目标模型往往是7B或70B的主管模型草稿模型只是辅助两个模型挤在同一张卡上会互相抢显存、抢带宽。分离部署的好处很明显草稿模型可以放在一张廉价的推理卡上目标模型独占高性能卡两者通过高速网络通信。但这也带来了通信延迟。如果草稿模型生成100个token耗时5毫秒结果传到目标模型那边用了5毫秒那收益就被吃掉了大半。所以分离部署的前提是拥有足够快的卡间通信通道。在vLLM社区里已经有针对多卡模式下草稿模型并行策略的优化讨论比如让草稿模型也使用张量并行只不过并行度远低于目标模型。这种配置适合大规模部署场景如果你只是自己本地玩一玩暂时没必要搞这么复杂。6.2 动态草稿模型与并行解码方案固定一个草稿模型从头用到尾并不是所有场景下的最优解。因为用户输入的模式随时在变化例如先让模型写代码然后又聊情感话题单个草稿模型很难一直都在高水平上猜测。业内已经在尝试动态草稿模型也就是根据当前对话的“语境”在多个草稿模型中切换或者动态调整K值。这一点在vLLM的Roadmap里也有提及但功能尚不稳定需要社区的持续迭代。另一个方向是“并行解码”思路比如一次让草稿模型生成多个候选序列目标模型并行验证从中选出最佳接受结果。这种方式在小模型上尝试过可以把接受率低的问题通过多候选来对冲。代价是生成多个候选序列本身就有开销需要更精细的调度策略。如果你对这些方向感兴趣可以去读几篇相关的论文比如关于推测采样、并行块验证的早期工作。vLLM的实现本身也吸收了不少论文里的思想但工程上做了很多适配比如如何在异步调度中处理草稿模型的生成。6.3 你可以在哪里找到参考实现vLLM的官方仓库和文档里推测解码的说明已经比较完整了。社区里也有不少已经合并的PR和issue讨论里面有不少用户实测数据、模型搭配经验和参数调整心得。如果你想更深入地看实现细节可以搜索一下vLLM源码中关于spec_decode的目录仔细读一读它的worker和metrics逻辑能学到很多工程细节。但读源码时有个小小的提醒不要被里面各种抽象类绕晕。你只需要抓住一条主线草稿模型如何生成token序列目标模型如何做批量验证以及两者的KV Cache如何管理。理解了这三个环节你基本就掌握了推测解码的工程脉络。我个人在实际操作中的体会是推测解码不是一个“开了就能起飞”的银弹它对模型搭配、采样参数、场景类型都很敏感。但只要耐心调一遍尤其是把草稿模型选对、K值调合适它带来的提速体验真的是立竿见影的。有一次我部署一个代码生成服务只是把K值从4调到6接受率就明显上升首屏的token吞吐直接提升了接近一倍当时挺感慨原来优化并不总是复杂的新架构有时关键就在对系统瓶颈的判断上。最后再分享一个小技巧如果你在调参时拿不准最优的K值可以先跑一段固定输入然后用日志里的接受率统计来“反向”找最优值。接受率高就尝试加大K接受率低就减小K直到单位时间内生成token数达到峰值。这个方法虽然笨但比盲目相信默认参数可靠得多。推测解码在社区里已经不算新概念了但真正能把它用好、调优、部署到生产中的人往往也就是多做了这一步细致的测量和迭代。