1. 投机采样到底在解决什么问题大模型推理优化这个系列第一篇我们聊了KV Cache和PagedAttention核心思路是“别重复算已经算过的东西”。但有个问题KV Cache解决不了自回归解码的串行性。每生成一个token都要把整个模型跑一遍哪怕模型只有7B参数生成100个token就要跑100次前向。这个过程中GPU的算力利用率其实很低——大部分时间花在把权重从显存搬到计算单元上真正做矩阵乘的时间占比很小。业内管这个叫memory-bound。投机采样Speculative Sampling就是冲着这个瓶颈来的。它的核心思想特别像我们平时干活让一个手快但水平一般的人先打草稿让一个水平高但手慢的专家来审核。草稿打得对就批量采纳打错了就纠正一下继续。这样专家的审核工作量没增加多少但整体产出速度上去了。具体到大模型推理场景用一个小的草稿模型Draft Model快速生成K个候选token然后让目标模型Target Model一次性对这K个token做并行验证。因为验证是并行的一次前向就能确认多个token是否正确相当于把原本串行的K次前向压缩成了1次大前向加K次小前向。只要草稿模型的生成速度足够快、接受率足够高端到端的加速比就很可观。我第一次在生产环境里跑投机采样是给一个13B的模型做加速。当时用的草稿模型是1.5B的同系列模型K设成4实测下来在A100上拿到了2.3倍的吞吐提升。但这里面坑不少后面会细说。注意投机采样不改变目标模型的输出分布。也就是说它不会让模型变“笨”最终生成的token序列在数学上等价于直接用目标模型采样。这一点是它比量化、剪枝等压缩方法更让人放心的地方。2. 核心原理拆解从草稿到验证的完整链路2.1 草稿模型怎么选、怎么跑草稿模型的选择直接决定了加速效果。理想情况下草稿模型要满足三个条件足够小推理速度快、和目标模型同分布接受率高、架构兼容方便部署。常见的选法有几种。第一种是同系列的小模型比如目标模型是Llama-2-13B草稿模型用Llama-2-1.5B或者TinyLlama-1.1B。这种组合的好处是tokenizer一致、训练数据分布接近接受率通常能到70%以上。第二种是用目标模型自己蒸馏出来的小模型接受率会更高但需要额外的训练成本。第三种是EAGLE这类方法它不用独立的草稿模型而是在目标模型的隐藏层上挂一个轻量级的自回归头来预测下一个token的特征相当于“自己给自己打草稿”。草稿模型生成K个token的过程是纯自回归的但因为模型小单步延迟很低。这里有个经验值K一般取3到8之间。K太小验证的并行优势发挥不出来K太大草稿阶段本身耗时增加而且后面的token接受率会指数衰减。我实测下来K5是个比较稳的默认值具体还要看草稿模型和目标模型的速度比。2.2 验证阶段的并行打分机制验证阶段是投机采样的精髓。目标模型拿到草稿模型生成的K个token后不是简单地逐个确认“对不对”而是并行计算每个位置上的概率分布然后跟草稿模型的分布做比较。具体来说对于第i个草稿token目标模型会算出在该位置上的概率p_target草稿模型之前算的是p_draft。接受这个token的概率是min(1, p_target/p_draft)。如果拒绝就从调整后的分布(p_target - p_draft)的正部分重新采样一个token。这套机制保证了最终输出的分布严格等于目标模型的分布数学上叫“拒绝采样”的变体。实际实现的时候验证是一次前向完成的。把原始prompt加上K个草稿token一起喂给目标模型拿到K1个位置的概率分布多出来的那个是最后一个草稿token之后的位置。然后从第一个草稿token开始逐个判断接受还是拒绝一旦某个位置被拒绝后面的草稿token全部丢弃并从该位置重新采样一个token然后继续下一轮。2.3 接受率为什么是关键指标接受率Acceptance Rate是投机采样最重要的监控指标。它定义为被目标模型接受的草稿token数量除以总草稿token数量。接受率越高平均每次验证能确认的token越多加速比越大。加速比的理论上限可以用一个简化公式估算假设草稿模型单步耗时是目标模型的1/r接受率为α草稿长度为K那么加速比大约是(1-α^(K1))/((1-α)(1/r K·α))。这个公式不用记但结论要清楚当α低于50%的时候投机采样基本没什么收益甚至可能负优化。所以草稿模型和目标模型的分布匹配度比什么都重要。我踩过的一个坑是拿一个中文能力很强的目标模型配了一个主要在英文语料上训练的草稿模型。结果英文任务接受率75%中文任务直接掉到30%以下整体吞吐还不如不加投机采样。后来换了一个同系列的中文增强小模型接受率回到65%以上加速效果才稳定下来。3. 实操部署从零搭一套投机采样推理服务3.1 环境准备与模型选择先说一下我的测试环境Ubuntu 22.04单卡A100 80GCUDA 12.1PyTorch 2.2。推理框架用的是vLLM 0.4.2它原生支持投机采样配置起来最省事。如果你用的是HuggingFace Transformers也可以手动实现但性能调优空间更大后面会提。模型选择上我选了一组比较有代表性的搭配角色模型参数量说明目标模型Qwen2.5-7B-Instruct7B主力模型FP16精度草稿模型Qwen2.5-0.5B-Instruct0.5B同系列小模型tokenizer一致备选草稿TinyLlama-1.1B1.1B跨系列测试用选Qwen2.5系列是因为它的tokenizer在中文上表现好而且0.5B和7B之间的分布差距相对可控。TinyLlama作为对照组用来验证“同系列”这个条件到底有多重要。安装vLLM的命令很简单pip install vllm0.4.2如果你要用最新版注意API可能有变化。vLLM的投机采样配置在SamplingParams里通过speculative_model参数指定草稿模型路径num_speculative_tokens指定K值。3.2 启动脚本与关键参数配置下面是我实际用的启动脚本基于vLLM的离线推理接口from vllm import LLM, SamplingParams llm LLM( modelQwen/Qwen2.5-7B-Instruct, speculative_modelQwen/Qwen2.5-0.5B-Instruct, num_speculative_tokens5, tensor_parallel_size1, dtypefloat16, gpu_memory_utilization0.9, max_model_len4096, ) sampling_params SamplingParams( temperature0.7, top_p0.9, max_tokens512, ) prompts [ 用通俗的语言解释一下什么是投机采样控制在200字以内。, 写一个Python函数实现快速排序并加上详细注释。, ] outputs llm.generate(prompts, sampling_params) for output in outputs: print(output.outputs[0].text)几个关键参数的解释num_speculative_tokens5草稿长度K。我试过3、5、8、10在Qwen2.5-7B0.5B这个组合下K5的端到端吞吐最高。K8的时候草稿阶段耗时明显增加虽然单轮接受token数多了但总吞吐反而下降。gpu_memory_utilization0.9显存利用率。投机采样会同时加载两个模型显存占用比单模型高。7B0.5B的FP16权重加起来大概15G左右加上KV Cache80G卡完全够用。如果是24G卡建议把目标模型换成4B级别或者用量化版本。temperature0.7温度参数会影响接受率。温度越高采样随机性越大草稿模型和目标模型的分布差异越容易被放大接受率会下降。实测temperature从0.1调到1.0接受率大概会掉15到20个百分点。3.3 实测数据与加速比计算跑完上面的脚本我用time命令和vLLM自带的吞吐统计做了对比测试。测试集是50条中文指令平均输出长度300 token左右。结果如下配置吞吐(tokens/s)平均接受率加速比目标模型单独跑42.3-1.0xQwen2.5-0.5B草稿(K3)78.572%1.86xQwen2.5-0.5B草稿(K5)97.268%2.30xQwen2.5-0.5B草稿(K8)89.661%2.12xTinyLlama-1.1B草稿(K5)63.441%1.50x几个观察第一同系列草稿模型的优势非常明显TinyLlama虽然参数量更大但接受率只有41%加速比远不如0.5B的Qwen。第二K5确实是个甜点值K8的时候草稿阶段的开销吃掉了并行验证的收益。第三接受率68%的情况下拿到2.3倍加速这个数字在生产环境里已经很有价值了。实操心得如果你的显存比较紧张可以考虑用GPTQ或AWQ量化后的草稿模型4bit的0.5B模型显存占用不到1G速度还更快。但量化会引入额外的分布偏移接受率可能会掉几个点需要实测权衡。4. 进阶玩法EAGLE与草稿树4.1 EAGLE的核心改进思路EAGLEExtrapolation Algorithm for Greater Language-model Efficiency是投机采样的一个重要变体。它的核心洞察是与其用一个独立的小模型打草稿不如让目标模型自己“预测自己的未来”。具体做法是在目标模型的最后一层隐藏状态上接一个轻量级的自回归头通常是一层Transformer或者MLP。这个头在训练阶段学习预测下一个token的隐藏特征推理阶段就用它来生成草稿token。因为草稿特征直接来自目标模型的内部表示分布匹配度天然就高接受率通常能到80%以上。EAGLE的另一个改进是草稿树Draft Tree。普通投机采样是一条线性的草稿序列EAGLE则允许草稿阶段生成一棵树状结构每个节点有多个分支。验证阶段用目标模型对整棵树做并行打分然后选出一条最优路径。这样相当于在同样的验证开销下探索了更多的候选序列进一步提升了接受率。4.2 草稿树的实现要点草稿树的构建需要控制分支因子和深度。分支太多验证时的计算量会指数增长分支太少又退化成线性草稿。实践中常用的配置是每层2到3个分支深度4到6层。验证阶段的关键是注意力掩码的设计。树状结构意味着不同分支之间的token不能互相看到需要构造一个块对角形式的attention mask。这个在vLLM和TensorRT-LLM里都有现成的实现但如果你自己手写推理代码这块很容易出错。我建议直接用支持EAGLE的推理框架别自己造轮子。EAGLE的部署成本比普通投机采样高一些因为需要额外训练那个自回归头。但好消息是EAGLE的官方仓库提供了在Llama、Qwen等主流模型上的预训练头可以直接拿来用。我试过Qwen2.5-7B的EAGLE头接受率稳定在82%左右加速比能到2.8倍比普通投机采样又高了一截。4.3 不同方案的选型建议方案接受率加速比部署复杂度适用场景普通投机采样(同系列)65-75%2.0-2.5x低快速上线资源充足普通投机采样(跨系列)35-50%1.2-1.6x低不推荐除非没有同系列小模型EAGLE78-85%2.5-3.0x中追求极致性能有训练资源草稿树EAGLE82-88%2.8-3.5x高离线推理延迟不敏感选型的时候别只看加速比。普通投机采样最大的优势是零训练成本找一个小模型配上就能跑。EAGLE虽然效果好但需要额外的训练和调参而且推理框架的支持程度参差不齐。我的建议是先用普通投机采样快速验证收益如果接受率能到65%以上再考虑上EAGLE。5. 常见问题与排查技巧实录5.1 接受率突然暴跌怎么查接受率暴跌是最常见的问题通常有以下几个原因第一草稿模型和目标模型的tokenizer不一致。这个坑很隐蔽因为两个模型都能正常跑但token的切分方式不同会导致分布完全对不上。排查方法很简单拿同一段文本分别用两个tokenizer编码看token序列是否一致。如果不一致接受率必然崩。第二温度参数设置过高。前面提过高温会放大分布差异。如果你发现接受率随着temperature升高而快速下降这是正常现象。解决办法是在高温场景下适当降低K值或者换一个分布更接近的草稿模型。第三输入领域偏移。草稿模型在训练时没见过的领域接受率会明显下降。比如代码生成任务上如果草稿模型主要用自然语料训练接受率可能只有40%左右。这时候要么换一个代码能力强的草稿模型要么在目标领域上对草稿模型做轻量微调。5.2 显存不够用的降级方案投机采样同时加载两个模型显存占用比单模型高不少。如果显存吃紧可以按以下顺序降级量化草稿模型用GPTQ或AWQ把草稿模型压到4bit显存占用降到原来的1/4速度还更快。接受率可能掉3到5个点但整体收益仍然为正。减小K值K从5降到3草稿阶段的KV Cache占用减少但加速比也会下降。换更小的草稿模型0.5B换0.3B甚至0.1B但接受率可能掉得厉害需要实测。目标模型量化这是最后的手段因为量化目标模型会影响输出质量而投机采样本身是不影响质量的。注意不要为了省显存把草稿模型放到CPU上跑。草稿模型的价值就在于速度快放到CPU上单步延迟可能比目标模型在GPU上还高完全失去意义。5.3 批量推理时的特殊考量单条请求的投机采样和批量推理下的行为不太一样。批量推理时不同请求的接受率不同导致每个请求实际生成的token数不一样。这会给调度带来麻烦有的请求一轮验证接受了5个token有的只接受了1个如果按固定batch size调度会出现“短请求等长请求”的情况。vLLM的处理方式是动态调整每个请求的草稿长度。接受率高的请求多给一些草稿token接受率低的少给一些。这个策略在连续批处理Continuous Batching下效果很好但需要框架层面的支持。如果你自己实现推理服务建议至少记录每个请求的滑动平均接受率用来动态调整K值。另外批量推理时草稿模型的batch size会变大单步延迟增加这会影响加速比。实测batch size从1增加到16草稿模型单步延迟大概增加2到3倍但目标模型的并行验证延迟增加得更多。所以大batch下投机采样的相对收益反而更明显因为目标模型的计算密度上去了memory-bound的问题缓解了但串行解码的瓶颈还在。5.4 常见问题速查表现象可能原因排查方法解决方向接受率低于40%tokenizer不一致对比两个模型的token序列换同系列草稿模型接受率随温度升高骤降分布差异放大固定温度对比测试降低K值或换模型加速比低于1.5x草稿模型太慢测草稿模型单步延迟换更小或量化草稿模型显存OOM双模型加载看nvidia-smi显存占用量化草稿或减小K输出质量下降验证逻辑有bug对比纯目标模型输出检查拒绝采样实现批量推理吞吐不升反降调度策略问题看各请求接受率分布启用动态K调整最后分享一个我调试时常用的小技巧先关掉投机采样跑一遍基线记录纯目标模型的输出。然后开投机采样跑同样的prompt逐token对比输出。如果发现输出分布有明显偏差大概率是验证阶段的拒绝采样实现有问题。正常情况下投机采样的输出应该和纯目标模型在统计上不可区分个别样本有差异是正常的但如果系统性偏向某些token就要查代码了。这个系列后面还会聊连续批处理和PagedAttention的配合优化以及怎么在多卡环境下做投机采样的张量并行。投机采样本身不复杂但跟其他优化技术组合起来调优空间还是很大的。