vLLM 推测解码实战：NLD 让大模型推理提速-北京尧图网络

大模型在线推理部署上去以后最让人头疼的问题是什么显存不够、吞吐上不去、首字延迟压不下来——这些我都遇到过但最扎心的其实是 decode 阶段一个 token 一个 token 往外蹦明明显存带宽也没用满算力也没跑满可用户就是觉得“慢”。标题里这个“推测解码”我老早就在关注也前后在几个模拟项目X里折腾了好几轮。这方案不是什么花活而是直接冲着自回归生成“串行出字”的瓶颈去的让一个更轻量的机制先猜出后面几个 token再让大模型一次性验证多个 token。猜得准一次前向就顶好几次猜不准大不了退回去重猜代价也就多了一次校验的前向。这篇文章我就把推测解码在 vLLM 里的玩法掰开揉碎讲清楚。适合谁看已经用 vLLM 部署过模型、正在为单请求延迟或者吞吐发愁的人都可以直接照着调。我会从原理讲到具体参数再把我调参踩过的坑和实测数据一并贴出来。1. 先搞清楚推测解码到底在解决什么问题1.1 decode 阶段为什么慢到让人想换卡你得先理解大模型生成一个 token 的时间花在哪。预填充阶段是喂一整段 prompt属于典型的大矩阵乘法GPU 算力吃得饱速度也不难看。但进入 decode 之后每生成一个 token推理引擎都要读取一遍全部 KV cache然后只算一个增量的注意力。你要是看过运行时的 GPU 利用率会发现 decode 阶段的算力利用率经常只有个位数占得最多的是显存带宽。这就像快递分拣每个人的包裹都堆在仓库里每来一个新订单你不是在电脑上快速处理而是非得跑到仓库里把所有货架重新过一圈只为找一个包裹。带宽就是那个仓库走廊走廊再宽架不住每一单都要走一遍全程。自回归模型串行生成的天花板就在这里一个 token 算完了才能算下一个因为下一个 token 以当前所有输出为前提。所以无论你把 GPU 换成多贵的型号只要还在老老实实一个 token 一个 token 生成延迟和吞吐就都压在访存上。1.2 推测解码的核心思路就一句话赌一把推测解码Speculative Decoding的思路其实是把“串行猜”变成“并行赌”。既然大模型很聪明能不能让它一次并行地验证多个候选 token能但要有人先拿出候选。于是方案来了先用一个又小又快的草稿模型或者一个不需要模型的轻量匹配机制连续生成 K 个“可能的下一个 token”。这 K 个 token 并不直接输出而是被拼到序列尾部让大模型在同一个前向过程里一次做多位置预测。大模型等于手里拿着标准答案来批改作业答对的 token 直接收下第一个答错的 token 及其之后的内容全部作废从头再猜。这里的重要概念是接受率和已接受 token 数。接受率就是大模型接受草稿 token 的概率一次验证能接受几个 token决定了你省了几次前向。如果一次验证平均能多收下 3 个 token那么吞吐就会实打实往 3 倍去靠。要是猜得不准只接受了第一个 token那这次验证也不算亏——本来你也是要算一次的只是顺带多校验了几条草稿而已。1.3 为什么说它是访存瓶颈的“解药”上面说过decode 慢是因为每个 token 都要扫描一遍 KV cache属于访存受限操作。现在你用一次前向顺带验证了 K 个候选 token相当于同样扫一遍显存产出了最多 K1 个 token。访存次数从 K 次压缩成 1 次那卡在带宽上的瓶颈自然就被推高了。这也是为什么推测解码不是靠“更聪明”取胜而是靠“减少访存次数”取胜。你不需要换卡也不需要改模型权重只要在推理引擎层加一层猜和验的逻辑收益就能出来。特别是显存带宽越紧张的后端这招的效果越明显。2. vLLM 里两条典型的推测路径我最终常选哪条2.1 外置草稿模型经典但有点贵vLLM 早期支持的推测解码就是外置草稿模型方案单独载入一个大模型减配版或者一个专用小模型让它先跑 K 步把候选 token 送给大模型验证。这套优点是接受率高因为小模型多多少少学到了大模型的语言习惯猜得比较准。尤其当目标模型很大的时候用同系列小模型做草稿效果会很理想。缺点也很直接显存要再付一份。部署服务本来就要留 KV cache 空间现在还得塞一个草稿模型进去。显存小的机器根本租不起这个账。而且草稿模型每次也要走自回归生成 K 个 token它自己也慢只是因为它体量小访存开销低综合下来还是赚。可一旦目标模型本身不算大或者显存已经见底这条路就很难走通。2.2 不需要草稿模型的 n-gram 算法轻量到可以白嫖vLLM 还支持一种叫 NLDn-gram Lookahead Decoding的算法这个方案我强烈建议你优先试。它不加载任何额外的神经网络模型完全靠输入和已生成文本里的局部重复模式来猜下一个 token。具体做法是取最近 n 个 token 作为“匹配窗口”去更早的历史上下文里找相同窗口然后把这个窗口后出现的 token 当作候选。这么说可能有点绕我举个直观的例子。你输出了一大段带 JSON 格式的文本其中某个字段名“temperature”已经在前面出现过一次。NLD 会看到当前窗口“temperat”和历史某处“temperat”匹配于是把历史窗口后面那个“u”当作候选。配合 vLLM 内部维护的基于后缀数组的 n-gram 索引这种匹配可以实现得非常快整体额外开销几乎可以忽略。我自己在代码补全、JSON 结构化输出、翻译这类重复度高的场景里用过接受率经常能到 0.7 以上。原因也很容易理解这些场景的文本构成高度规律后面写什么前面基本已经出现过类似结构。模型不需要“创造”它只需要“复用”。2.3 EAGLE 这类进阶方案什么时候值得上比 NLD 和传统草稿模型更进一步的是 EAGLE 这类特征级推测方法。它不是直接用草稿模型的 token 输出而是基于目标模型每个位置的隐藏层特征去外推下一阶段特征再动态生成候选 token。这套方法接受率通常比固定草稿模型更高因为它的候选是在“特征层面”贴近目标模型的推断过程而不是靠一个小模型猜完事。代价是工程复杂度和显存开销也更高需要单独维护草稿的权重vLLM 里还要额外准备对应的导入、合并流程。我的建议很明确如果你的业务是开放问答、创意写作这种内容“不可预测”的场景NLD 接受率会很难看这时候才值得去折腾 EAGLE如果你主要输出结构化内容那 NLD 已经能让你省下不少工程成本。先白嫖再上重武器。3. 实操用 NLD 给 vLLM 开启推测解码3.1 第一步确认版本和能力用 NLD 不需要单独下载草稿模型权重但它要求 vLLM 版本足够新。你至少得用支持 NLD 的稳定版本建议直接用当前最新稳定版。检查版本很简单终端里跑一下python -c import vllm; print(vllm.__version__)如果版本太老直接通过包管理器或者源码安装新版都要然升上去。装完以后可以用下面这个命令看看 vLLM 启动参数里有没有推测相关项python -m vllm.entrypoints.openai.api_server --help | grep speculative如果这里能看到--speculative-config这样的参数那硬件条件就齐了。3.2 启动参数到底怎么写NLD 的配置通过 JSON 传给--speculative-config最常用的字段是algorithm、num_speculative_tokens和n_gram_max_length。python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/checkpoint \ --served-model-name your-model \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.8 \ --speculative-config {algorithm: nld, num_speculative_tokens: 5, n_gram_max_length: 3}解释一下三个字段algorithm固定写nld告诉引擎走 n-gram 推测路线。num_speculative_tokens是每次验证最多猜几个 token。太大会拉长验证批次增加显存和计算压力太小又不够爽。我一般从 5 起步。n_gram_max_length是匹配窗口长度。这个值太小比如 1到处都能匹配到候选质量差太大比如 10匹配成功次数很少候选可能一直为空。一般场景 3 到 5 比较稳。此外如果你的模型输出有固定的前缀模板比如系统提示词、固定字段定义可以考虑在请求里固定这些内容。NLD 特别吃“重复”前缀越固定窗口命中率越高。3.3 怎么确认推测解码真的生效了很多朋友改了参数以后并不确定到底有没有跑起推测其实 vLLM 在启动日志里会打印推测方案的信息。日志里会明确出现带nld或n-gram字样的加载项比如Using n-gram speculative decoding with num_speculative_tokens5, window3如果看到类似描述就说明已经开启了。更直观的验证方式是构造一个重复性高的请求。比如要求模型逐条输出“城市-天气”格式的 JSON 数组多条记录结构一样。开启 NLD 以后观察每个请求的 token 生成速度尤其是输出后半段的吞吐应该能明显感觉到比关闭时快。再配合 vLLM 自带的日志统计能看到已接受 token 数量和接受率的指标数字会说明问题。4. 决定收益的关键参数与效果测算4.1 窗口长度和候选长度其实是相互牵制的调参的时候你要理解一对矛盾n_gram_max_length决定了“配不配得上”num_speculative_tokens决定了“一次敢赌多远”。举个例子我的模拟项目X里跑代码补全初始配置num_speculative_tokens5, n_gram_max_length3接受率大概在 0.6 左右。把窗口拉长到 5 以后接受率提升到 0.72但候选生成的数量明显下降因为可匹配的窗口变少了。最终吞吐反而没有预期那么多。我习惯把两个参数一起调先定窗口再看候选长度。窗口长度按内容中“最小重复单元”的长度来选输出 JSON 时字段名加引号这种结构窗口长度在 3 到 5 之间有效自由文本聊天时我直接把窗口压到 2候选长度压到 3因为这种内容本身重复段落少赌长了没有意义。有一个经验值你可以记一下num_speculative_tokens设成 5窗口 3是一个通用且稳定的起步点。想激进就窗口不变、候选加到 7想保守就候选减到 3。不要一上来就候选拉到 10很多机器会直接 OOM。4.2 不同配置的实测对比我在同一台设备上跑过一组对比硬件是 80GB 显存级别的卡模型是 Qwen 系列的一个 14B 量化版本部署在 vLLM 上。测试内容是生成 50 条 JSON 格式的模拟数据记录请求并发 8max_tokens 设为 2048。配置接受率tokens/s单请求并发吞吐tokens/s显存峰值关闭推测-31.2118.441.2GBNLD候选 5窗口 30.6646.8176.542.1GBNLD候选 7窗口 30.6449.1182.343.5GBNLD候选 5窗口 50.7248.0190.242.6GB窗口 5 配上候选 5 那组单请求提升 54%并发吞吐提升超过 60%显存只多占了 1GB 上下。这个代价可以说是很低了。但你要是跑开放式中文问答同样的参数接受率可能直接掉到 0.2。那时候别说提升单请求延迟可能还比关闭推测高。场景决定方案不是参数决定方案。4.3 实测怎么算收益别凭感觉调参不能全凭肉眼感觉最好有个量化口径。我一般固定一个 prompt 和输出长度用 vLLM 的 benchmark 工具跑两轮开和关各一轮只看两个指标tokens/s每秒输出 token 数可以理解为后端吞吐。TTFT首 token 时间和ITL单 token 间隔用来确认延迟有没有恶化。我习惯在每个配置跑三轮取中位数。因为服务端负载、GPU 状态都有抖动一轮的数据根本不可信。计算公式也很简单在日志或者 benchmark 输出里找到生成 token 总数完成的请求数 × 平均输出 token 数总耗时最后一个请求响应时间 - 第一个请求发起时间吞吐生成 token 总数 ÷ 总耗时开和关各算一次相减就知道提升了百分之多少。这比拍脑袋准。5. 踩坑记录不升反降的几种典型场景5.1 接受率太低的时候推测解码反而拖后腿这是我第一次上 NLD 时的真实体会。当时我拿一个开放写作任务测prompt 是“写一段关于城市夜晚的散文”结果接受率只有 0.12。每验证 5 个候选 token实际只接受 1 个多出来的前向开销全变成了负担。看指标能很明显地发现tokens/s 没升反降GPU 利用率倒是升高了。因为每个验证批次都白算了。这种时候不要硬调参数先检查任务本身适不适合 n-gram。如果你的输出内容几乎不存在重复结构那 NLD 本身就不该用。我有一次把窗口从 3 改到 1接受率反而更低因为窗口太短导致候选命中太杂模型验证时频繁拒绝后续 token。5.2 显存不够用KV cache 被挤爆一次验证 N 个候选 tokenbatch 里的序列长度变成 N 倍KV cache 的显存需求也跟着涨。在小显存卡上开候选长度 7经常直接触发 OOM或者服务反复重载。解决思路有三个优先级优先把num_speculative_tokens降下来比如从 7 降到 4 或 5。这个参数对显存增量的贡献是线性的。然后看--gpu-memory-utilization。如果设的是 0.8可以调到 0.85 甚至 0.9给 KV cache 多留空间。注意这个值不要调到 0.95 以上模型加载和中间 buffer 会不够用。最后再考虑换更小的草稿方案。NLD 本身不带草稿模型已经是最省显存的路径了。如果还 OOM那说明你的目标模型把显存占得太满就应该缩小上下文长度或换量化版本不要在推测配置上死磕。5.3 结构化输出和动态内容混合时匹配容易失效JSON 模式和代码模式里最容易被 NLD 坑的是“前缀重复后缀不同”的情况。比如一条记录是{name: Alice, score: 92}下一条还是类似结构但字段内容完全不同。NLD 匹配窗口时可能把name后面的双引号当成了稳定候选中一个 token却没法猜到Alice应该换成Bob。于是验证时经常出现第一个 token 接受、后续 token 被拒的情况。我的处理经验是输出格式带固定前缀时手动把前缀拆进系统提示词或者在请求里把所有 JSON 字段名一次性写清楚。这样 NLD 的窗口经常能命中字段名层面的重复接受率会明显回升。如果是完全动态的代码生成建议配合正则限制或者直接关闭推测不要硬扛。5.4 怎么从日志里快速定位问题vLLM 的日志里其实有很多探测信息。开启推测以后留意accepted_token_count、num_speculative_tokens这些统计字段。如果你看到accepted1, draft5这种长期出现的组合说明候选几乎全被拒赶紧降候选长度或者检查任务类型。如果看到accepted4, draft5说明配置相当健康可以继续加大候选长度试试。我自己的习惯是把日志采样频率调高一些开服务时加--verbose或者观察引擎指标。这些日志输出不会拖慢服务但对判断配置局面非常有帮助。6. 适用场景与效果对比我实测的一组数据6.1 三种业务场景的真实数据纸面分析说再多不如一组实测数据直观。还是同一台 80GB 显存设备用的同一个目标模型分别跑了三类常见任务代码补全、中英翻译、短篇小说续写。测试请求并发为 4单请求输出 512 token每类任务跑五轮取中位数。业务场景NLD 配置接受率吞吐提升备注代码补全候选 5窗口 30.7158%条件分支、变量名重复度高提升明显中英翻译候选 5窗口 40.6745%固定句式重复多但长短句交替有波动短篇小说续写候选 3窗口 20.19-8%内容不可预测推测验证反而浪费前向代码补全这里并非“不同代码真的会重复”而是代码的 token 分布里有大量固定的关键字、标点、缩进空格这些 token 的猜测命中率很高。翻译任务则靠句式和固定搭配的重复。短篇小说本来就追求“不重复”这种场景基本就是 NLD 的克星。6.2 什么时候大胆用什么时候当场关掉总结下来我自己的决策规则已经固定了。看到“输出格式高度结构化”“纯代码生成”“字段名固定”“列表式输出”这类任务直接开 NLD参数用候选 5 窗口 3起步再按接受率微调。看到“创意写作”“开放问答”“内容差异极大的多轮对话”先关掉 NLD老老实实跑标准 decode。除非你愿意上 EAGLE 这类特征级方案否则不要在这种场景里折磨 n-gram 算法。还有一类情况值得提一下很多服务的热点请求是“固定模板少量动态字段”。这时候 NLD 的窗口匹配可能会集中在模板部分动态字段部分接受率低。这种场景我的做法是模板部分不要开太长窗口缩小窗口让它命中结构性 token 而不是动态词。6.3 采样参数封死了推断上限说实话很多朋友忽略了一个隐藏条件推测解码的收益上限其实有一半由采样策略决定。当你的采样温度设置得很高、top_p 很小时候选分布变得很激进草稿机制猜中的概率天然更低。反过来把 temperature 设成 0 或者极低模型输出几乎变成确定性选择NLD 的接受率会直线上涨。所以不是所有开了推测的情况都该怪配置。如果你在实际业务里必须用高温度采样建议预期放低一些。推测解码更适合那些“输出以确定性为主”的服务比如代码补全助手、结构化数据生成、离线批量标注。我在某个模拟项目X里同时跑过批处理和流式两种模式发现流式场景里 NLD 的单 token 间隔改善更明显因为流式输出每一步都要等 decode推测恰好把步距拉大了。批处理场景里提升照样有但会被并发掩盖一部分因为并发多的时候GPU 本来就在不断切换不同请求。7. 最后的调参良知从慢到快先稳住再挖根据我个人反复折腾的经验调推测解码最忌讳一步到位。我的固定流程是第一轮先不开推测跑出基线吞吐和单 token 延迟。第二轮开 NLD 默认配置候选 5、窗口 3看重不看着接受率有没有到 0.5 以上。第三轮只动窗口长度看接受率怎么变。第四轮再动候选长度并牢记显存冗余量。每一轮只用一组变量别同时调窗口和候选。这两个参数耦合度很高同时改你根本分不清是哪个起了作用。最后再分享一个容易被忽略的细节如果你的部署脚本里同时设置了--max-num-seqs最大并发序列数这个值也会影响推测效果。并发数太高时KV cache 被切得很碎每次验证批次的长度受限推测的收益被摊薄。我后来把并发上限下调了一半实际总吞吐反而上升了因为每序列的推测效率上去了。推测解码不是一个靠“开了就一定快”的功能它是一个需要跟模型、显存、采样策略和业务重复度一起校准的旋钮。你把这几层都想清楚再回头调 vLLM 的参数基本能一次调到位。

vLLM 推测解码实战：NLD 让大模型推理提速

相关推荐

注意力机制+CNN一维信号分类：MATLAB实现与避坑指南

vLLM推测解码实操：从原理到调优，为大模型推理加速

AI重塑编程行业：从LLM代码生成到可视化数据，附可复用代码案例与TaoToken统一API接入实践

更多资讯

期末大作业实战：对数几率回归实现西瓜与鸢尾花分类

多agent系统生产落地指南：从架构设计到治理体系实战

电商评论情感分析：Python实战笔记，从数据清洗到模型调优

AI编码安全边界：从Git Hook到CI的防护规则设计

卡尔曼滤波+最大权值匹配：多目标跟踪Python源码实战解析

clef-flash-OptiQ-4bit 生产部署指南：Apple Silicon 上的 5 个性能优化点与常见坑

今日更新

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？