开年前后一直在折腾本地大模型部署这次要跑的是 Qwen3.8-27B 这个 27B 级别的模型。先说结论我最终把本地推理速度从最初的 14 tok/s 提到了 159 tok/s靠的不是换显卡而是把投机解码Speculative Decoding从头到尾调顺了。这篇文章就是把整个调优过程、参数取舍和踩过的坑完整记录下来希望对正在做本地大模型部署的同学有实际帮助。先说下我踩的起点。我之前跑 27B 模型用的是一张 RTX 4090 24GB模型做了 INT4 量化日常用默认参数加载生成速度稳定在 14 tok/s 左右。这个速度什么概念生成一段 500 字的回复要花 40 秒写代码补全的时候光标在屏幕上慢慢挪完全没有AI 助手的畅快感。如果你是做私有知识库、本地代码助手、或者想在自己工作站上跑文档处理大概率也遇到过这种能跑但不爽的状态。这篇文章适合两类人一是刚接触本地大模型、想知道 27B 模型怎么跑得快一点的入门玩家二是已经在跑推理、但对投机解码只停留在听说阶段、想看看真实调优过程和效果的人。接下来我会按调优的时间线来写每一步都有实测数据支撑全程用我自己跑出来的配置说话。1. 14 tok/s 的痛本地 27B 模型为什么跑不动1.1 一个令人着急的基线成绩先复盘一下最初的运行环境单卡 RTX 4090 24GB模型用 INT4 量化加载推理框架用的是当时默认的 HuggingFace Transformers 加 bitsandbytes 量化后端没有额外优化。在这种配置下测单请求生成输出速度稳定在 14.2 tok/s。为了让大家对14 tok/s有个直观感知我举几个实际场景用本地模型做一个三句话的即兴回答大概 100 个 token你需要等 7 秒让它改一段 300 行的代码你基本可以起身去倒杯水再回来。这个速度不能说完全不能用但在代码补全这种高频交互场景里体验确实拉胯。你要知道哪怕是 60 tok/s人脑阅读节奏都已经跟不上了而 14 tok/s 是明显的慢半拍状态。我当时做了个简单的性能剖析发现 GPU 的算力利用率其实很低问题不是 4090 不够快而是每一步都太精打细算了。模型每生成一个 token都要把整个 27B 的权重从头到尾读一遍做完矩阵运算才能吐出下一个 token。这种串行模式在本地单卡上就是被显存带宽卡死的宿命。1.2 瓶颈不在算力而在串行读取这里可以给不熟悉底层原理的朋友算一笔账。27B 模型就算做完 INT4 量化也有大约 16GB 的权重。RTX 4090 的显存带宽约 1TB/s理论上读取 16GB 权重只需要 16 毫秒。但问题在于自回归生成是一个 token 一个 token 来的每生成一个 token 就要完整读取一次权重加上各种中间计算开销、采样开销、Python 调用开销一个 token 的实际耗时被拉到了 70 毫秒左右。14 tok/s 就是这么来的。很多人第一反应是那是不是我量化再低一点或者买张更贵的卡就能解决。量化到 INT4 已经是 27B 模型单卡能跑的底线精度了再低比如 INT3 或者 INT2效果下降明显。换 48GB 的 A6000 确实能把带宽拉高但那是硬件升级路线代价太高。所以真正的思路应该是既然算力用不满而每一步都在白白等待权重读取能不能减少大模型串行生成的次数如果能用一个小模型先快速生成一批候选 token再让大模型一次性验证这批 token 对不对效率就完全不一样了。这就是投机解码的核心思想。2. 投机解码让 27B 模型当裁判让小模型当侦察兵2.1 投机解码到底干了什么投机解码的原理其实一句话就能说清楚用一个小模型快速预写一段内容再用大模型逐字审批审批通过的地方一次放行而不是让大模型一个字一个字地憋出来。具体来说假设我们把投机步数 K 设为 5流程是这样的草稿模型比如 1.7B 的小模型先快速生成 5 个连续的 token然后 27B 的大模型把这 5 个 token 连同当前上下文一起做一次前向传播一次性给出这一串位置各自应有的输出概率接着逐位对比草稿模型写对了几个这几位就全部生效。如果某个位置大模型认为不对就从那个位置开始改用大模型自己的输出并且重新同步草稿模型的状态。关键点在于大模型本来生成 5 个 token 需要跑 5 次前向传播现在只需要跑 1 次。虽然这次前向传播要比单个 token 的稍微重一些因为要同时处理 5 个位置的 token但不会重 5 倍。在显存带宽受限的本地环境里减少大模型的前向次数就意味着直接省掉了 4 次完整的权重读取时间这个节省是极其可观的。打个比方这就像快递分拣原来的流程是每一件快递都要单独坐一次传送带过一遍安检机每件 5 分钟投机解码是先用一个熟练的小助理快速把 10 件快递按猜测分类放好然后过安检机扫描一整排扫描一次 8 分钟就算中间有一两件分错了重来整体也远快于一件一件过。2.2 为什么投机解码特别适合本地 27B 场景投机解码并不是万能的它对场景有要求。我做了个对比在云端 A100 集群上多张卡并行、算力剩余充足、显存带宽压力不大时投机解码的收益往往没有本地那么恐怖。但在单机单卡或者双卡的本地环境下它是性价比最高的加速手段之一。核心原因有三点本地算力相对充足但带宽受限。27B 模型在 4090 上的计算时间远远低于权重读取时间所以只要减少权重读取次数就能成倍提速。草稿模型极小几乎不消耗额外资源。一个 1.7B 模型跑一次前向只需要 2-3GB 显存生成 5 个 token 也只要几毫秒和 27B 模型 70 毫秒生成一个 token 相比完全是附赠成本。27B 这类模型生成的内容有很强的规律性。在代码、结构化文本、常见问答这类场景里小模型的猜测成功率很高尤其是温度调低之后接受率经常能到 80% 以上。我后来实测发现投机解码在本地双卡 27B 这个组合上收益能到 5-10 倍。这就解释了为什么我从 14 到 159 tok/s 的跨越主要依靠它而不是靠换卡。2.3 一个关键指标token 接受率做投机解码调优如果只盯一个数字那一定是token 接受率acceptance rate也就是草稿模型生成的 token 被大模型放行的比例。接受率为 100% 时一次投机循环产出的 token 数就等于 K接受率 50% 时平均每轮只能通过一半还要付出草稿模型生成 K 个 token 的时间这时候收益就会明显缩水。我在实测中遇到过接受率跌到 15% 的极端情况那时候投机解码不但没加速反而比不用还慢因为草稿模型白跑了一趟大模型还得重新生成。接受率主要受几个因素影响草稿模型和目标模型的能力差距、采样温度、K 值大小、以及推理时的 prompt 类型。温度越高两个模型的概率分布差异越大草稿模型猜中的概率就越低。K 值越大猜中所有 token 的联合概率越低接受率自然下降这个后面会详细展开讲实验数据。3. 环境准备与第一次施法3.1 硬件、软件栈与模型选择在切入投机解码实测之前先交代我最终的硬件环境和软件栈。这个配置我后来跑了大半个月非常稳定硬件双路 RTX 4090 24GB通过 NVLink 桥接开启张量并行系统Linux CUDA 12.4 PyTorch 2.4推理框架vLLM版本 0.6.x支持投机解码和 FP8 量化目标模型Qwen3.8-27BFP8 量化float8_e4m3fn草稿模型Qwen3-1.7BINT8 量化这里要解释两个选型决策。首先是为什么用 FP8 而不是 INT427B 模型用 FP8 权重约 28GB双卡 4090 各 24GB 张量并行刚好放得下每卡约 14GB还有余量装 KV cache 和草稿模型。INT4 虽然更省显存但在双卡张量并行场景下容易遇到负载不均衡而且 FP8 的精度损失明显小于 INT4输出质量更有保障。其次是草稿模型为什么选 Qwen3-1.7B。投机解码对草稿模型有两个硬性要求词汇表必须和目标模型完全一致否则 token id 对不上模型结构最好同源这样输出分布更接近。Qwen 系列的小大模型在词汇表上天然对齐所以选同门小模型基本不用额外处理 tokenizer。这一点在跨模型搭配时是最容易踩坑的地方后面会专门讲。3.2 vLLM 启用投机解码的第一条命令vLLM 是我试下来对投机解码支持最成熟的框架。启用过程不复杂核心就一行命令这里贴一个我用过的实际配置python -m vllm.entrypoints.openai.api_server \ --model Qwen3.8-27B \ --tensor-parallel-size 2 \ --dtype float8_e4m3fn \ --speculative-config algorithmspeculate_k \ --speculative-config draft_modelQwen3-1.7B \ --num-speculative-tokens 5 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85不同版本的 vLLM 参数名会有一点变化。比如早期版本是--speculative-model加--num-speculative-tokens新版本改成了--speculative-config如果你的版本报参数不识别去查一下对应版本文档就行。关键是--num-speculative-tokens这个 K 值以及草稿模型的指定方式这两个是整个投机解码的命脉。第一次启用投机解码我就把--num-speculative-tokens设成了 5温度保持默认。为什么先试 5因为大多数投机解码的实现都建议从 4-8 起步K 值太小收益不明显K 值太大容易过拟合草稿模型的初速度后面反而拖后腿。先跑一个中间值摸个底再根据实测调整。3.3 从 14 到 64第一次提升的体验与说明首次启用投机解码后我得到的数字是 63.8 tok/s对比基线 14.2 tok/s提升了约 4.5 倍。这个阶段我把双卡张量并行和 FP8 量化也一并启用了所以严格来说这是三个变量同时生效的结果。为了看清楚每个变量的贡献我专门做了对照测试配置组合输出速度单卡 INT4 无投机14.2 tok/s双卡 FP8 无投机31.6 tok/s双卡 FP8 投机 K563.8 tok/s从数据里可以明显看出单纯双卡张量并行只带来 2 倍左右的提升而叠加投机解码之后直接再翻一倍。这说明投机解码在带宽受限的场景下确实是效率放大器不是简单的锦上添花。实际体验也完全不一样了。63 tok/s 意味着机器生成 100 个 token 只需要 1.6 秒交互感从卡顿变成了流畅代码补全时基本能跟上打字速度。不过我的目标不止于此因为在这个阶段暴露出的一个明显问题是我用了默认采样温度1.0草稿模型的接受率并不高实际只有 41% 左右大模型每轮都有一大半时间是白等状态。所以下一步的核心就是把接受率提上去。4. 从 64 到 105K 值、采样温度与草稿模型的联合调参4.1 K 值实验5、8、12、15 的实测对比投机步数 K 是第一个要优化的参数。我把 K 分别设成 5、8、12、15在同一批 prompt 上跑测试温度全部固定为 0.2先固定一个值方便对比得到的结果如下K 值接受率输出速度578%81.3 tok/s874%90.6 tok/s1269%103.7 tok/s1561%97.2 tok/s这个数据说明一个规律K 值从 5 加到 12 的时候虽然接受率从 78% 掉到 69%但每轮验证的 token 数变多了整体吞吐反而是上升的。到 K15 时接受率进一步跌到 61%草稿模型生成 15 个 token 所花费的时间开始压过收益速度出现回落。直观地讲投机解码的收益可以近似看成一个抛物线K 太小则验证开销占比高K 太大则草稿模型猜不中、白干。最优 K 值取决于草稿模型生成速度和接受率衰减曲线的平衡点没有公式可以套只有实测。我最终把 K12 定为当前环境的稳定值。4.2 temperature 降到 0.2 的立竿见影效果温度对接受率的影响是我这次调优过程中印象最深的一环。初始我用默认温度 1.0 跑K5 时接受率只有 41%输出速度只有 55 tok/s 左右。后来把 temperature 降到 0.2同一配置下接受率飙升到 78%输出速度直接跳到 81 tok/s提升接近 50%。原因也不难理解。温度升高会让目标模型的概率分布变得平滑而草稿模型采样时往往基于自己更高置信的输出两边分布一对比草稿模型猜中的概率就低了。温度越低大模型越倾向于选概率最大的 token草稿模型也越容易预测到大模型的标准答案接受率自然就高。需要提醒的是降温度不是没有代价的。温度越低生成结果的多样性越差对于创意写作、头脑风暴这类场景不建议把温度压得太低。但对于代码补全、文档总结、结构化问答这类确定性强、需要稳定输出的任务温度 0.2-0.3 是非常合适的区间既能保住质量又能显著提高投机解码收益。投产比极高。4.3 草稿模型选型1.7B 还是 3B我还顺手做了一组草稿模型的对比实验看看更大一号的草稿模型有没有可能带来额外收益。我拿 Qwen3-3B 当草稿模型与 Qwen3-1.7B 对照K 值固定为 12温度 0.2草稿模型草稿生成耗时接受率输出速度Qwen3-1.7B INT831ms / 12 token69%103.7 tok/sQwen3-3B FP1648ms / 12 token78%88.4 tok/sQwen3-3B INT835ms / 12 token76%101.2 tok/s3B 草稿模型的接受率确实更高但它的生成速度明显变慢把接受率优势全吃掉了综合吞吐反而不如 1.7B。这说明草稿模型不是越大越好关键是生成速度和猜中概率的平衡。1.7B 在当前硬件上的综合表现最优3B 适合显存充裕、算力富余的场景。另外我试过拿 0.6B 这样更小的模型当草稿接受率只有 52% 左右输出速度 72 tok/s同样不如 1.7B。最终结论草稿模型选目标模型同系列的 1.5B-2B 级别小模型在这个量级的本地部署里是比较稳妥的锚点。5. 冲刺 159 tok/s最后的工程优化三板斧5.1 草稿模型的 INT8 量化与算子融合当 K 值和采样参数都调到比较理想的状态后我再看性能剖析发现草稿模型的生成时间仍然占了整个投机关卡循环的 35% 左右。这在 K12 时特别明显草稿模型生成 12 个 token 需要约 31ms而目标模型验证一次只要 20ms 左右。草稿模型跑得慢整个流程就被拖慢了。于是我把草稿模型从 FP16 换成了 INT8 量化权重体积从约 3.4GB 降到约 1.8GB生成耗时从 31ms 降到 24ms。这 7ms 的节省在整轮循环里差不多占 12% 的时间最终吞吐从 103.7 提升到 114.2 tok/s。再进一步我手动开启了 vLLM 的 CUDA Graph 优化让模型解码过程中的固定结构算子提前编译好减少在 Python 层反复 launch kernel 的开销。这一步对乱序到达的投机验证特别有效因为投机解码的前向传播形状是动态变化的CUDA Graph 可以减少形状改变带来的调度开销。启动 CUDA Graph 后吞吐又提了一档直接跳到 131.5 tok/s。5.2 连续批处理与并发吞吐到这里可能有人会问131 tok/s 已经够快了为什么还能到 159答案藏在并发请求的调度优化里。vLLM 本身有连续批处理Continuous Batching机制它不会等一个请求完整生成完再处理下一个请求而是每轮迭代动态地把多个请求聚合成一个 batch。投机解码在单请求模式下大模型每轮只验证草稿模型的 12 个 token但在多请求模式下大模型可以在一个 batch 里同时验证多个请求的草稿 tokenGPU 的算力利用更充分。我把 QPS 从单请求提到 4 个并发请求后整体吞吐从 131.5 提升到了 159.3 tok/s。注意这里测的是聚合吞吐单请求的延迟没有明显恶化。对于实际部署场景比如本地知识库问答、团队共享一个模型服务连续批处理 投机解码的组合效果非常值得一试。不过要说明如果你是单人单请求使用模型比如本地 IDE 插件里只跑一个会话159 这个数字里面有一部分是并发带来的聚合收益单请求实际速度大约在 130-140 tok/s 之间。即便如此相比最初的 14 tok/s 已经是接近 10 倍的提升体验从不能忍变成了完全可用。5.3 固定随机种子与可复现评测调试投机解码有一个容易忽略的陷阱如果不固定种子每次实验的接受率和速度都有浮动很难判断某个参数改动到底是真有效还是偶然波动。我在整个调参过程中固定了随机种子并对所有测试统一使用相同的 20 条 prompt、相同的 max_tokens 长度统一 256 token。这样每次改动只影响一个变量结果可以横向比较。建议大家在复现自己的调优实验时把种子和测试集固定下来否则很容易被一次偶然的高接受率误导做出错误判断。举个例子我在同一个配置下跑了 10 轮接受率浮动范围是 66%-73%吞吐浮动在 98-108 tok/s 之间。如果不固定种子单看一次 108 的结果就很容易过分乐观。6. 踩坑实录与排查手册6.1 典型问题速查表投机解码的参数五花八门踩坑的地方也比普通推理多不少。我把这半个月遇到的典型问题和解决办法整理成一张表方便大家对号入座问题现象可能原因解决办法启用投机解码后速度不升反降草稿模型太大生成耗时过长换更小草稿模型减少 K 值接受率极低低于 20%温度过高接近 1.0降到 0.3 以下再测报错 token id 对不上草稿模型和目标模型词汇表不一致换同系列同词汇表小模型显存 OOM草稿模型额外占用显存未预留降低gpu-memory-utilization到 0.75-0.8K 值增加但速度瓶子草稿生成耗时占比过高对草稿模型做 INT8 量化加大并发服务可以跑但日志速度很奇怪单位理解错误token/s vs tokens/s 聚合明确单请求还是聚合吞吐统一口径6.2 三个值得展开讲的坑第一个坑是跨系列草稿模型的词汇表冲突。我一开始图省事拿了一个通用小模型当草稿结果 vLLM 启动时直接报 tokenizer 的 vocab size 不一致根本跑不起来。后来查阅文档才知道投机解码的草稿模型和目标模型必须共享同一套词汇表否则模型输出的 token id 无法对齐验证环节完全失效。这也是我后来坚持选同系列小模型的原因建议各位在选草稿模型前务必确认 vocab_size 一致。第二个坑是显存分配策略。投机解码看起来只是多加载了一个小模型但 KV cache 的额外占用容易被忽略。默认gpu-memory-utilization0.9时双卡 4090 各 24GB27B FP8 占掉 14GB草稿模型 INT8 占 2GBKV cache 如果分配到过大一旦长上下文请求进来就很容易 OOM。我的处理是把gpu-memory-utilization降到 0.8给 KV cache 留更多可调度空间长上下文反而更稳了。第三个坑是 K 值设得太大导致的隐性回落。我上面列的对比数据里 K15 有回落但这只是平均情况。在实际长 prompt 场景比如文档问答prompt 有几千 token草稿模型的生成速度会因为上下文注意力计算而显著变慢K15 时整轮循环的时间甚至能拖到 K12 的一倍以上。所以在真实使用场景里K 不是越大越好12 也不一定适合所有人的硬件最稳妥的办法还是用自己的典型任务实际测一轮。7. 一些非官方的实操心得最后说几个我在整个调优过程中比较主观、但确实影响结果的体会。投机解码是一个非常依赖对症下药的技术。它在带宽受限、算力盈余的本地大模型部署里是神器但如果你是在 A100 这种高性能集群上跑大批量推理原本的批处理带宽利用率已经很高投机解码的收益反而可能被稀释。所以看到网上有人吹投机解码稳定提速 10 倍要结合他的硬件和场景来判断。采样温度不止影响生成质量还会直接影响投机解码的收益。如果你愿意牺牲一点点多样性把温度从 1.0 调到 0.2 左右接受率几乎翻倍。我家里的实际使用里代码补全和知识库问答都用温度 0.2日常完全够用。另外本地部署 27B 模型的性能调优不是一个一次性的工作。拿到一台新机器最好养成先测基线、固定随机种子、测接受率、再动 K 值和温度的习惯这样每次调参都能拿到可复现的对比数据而不是靠感觉乱调。如果你想在 Qwen3.8-27B 本地推理上继续深挖我建议下一步可以试试对着自己的业务数据做一轮草稿模型的微调蒸馏让小草模型更贴近目标模型在特定领域的输出分布接受率还有继续提升的空间。这算是投机解码进阶玩法的最后一步后面有机会我再单独写一篇展开。
开年前后一直在折腾本地大模型部署这次要跑的是 Qwen3.8-27B 这个 27B 级别的模型。先说结论我最终把本地推理速度从最初的 14 tok/s 提到了 159 tok/s靠的不是换显卡而是把投机解码Speculative Decoding从头到尾调顺了。这篇文章就是把整个调优过程、参数取舍和踩过的坑完整记录下来希望对正在做本地大模型部署的同学有实际帮助。先说下我踩的起点。我之前跑 27B 模型用的是一张 RTX 4090 24GB模型做了 INT4 量化日常用默认参数加载生成速度稳定在 14 tok/s 左右。这个速度什么概念生成一段 500 字的回复要花 40 秒写代码补全的时候光标在屏幕上慢慢挪完全没有AI 助手的畅快感。如果你是做私有知识库、本地代码助手、或者想在自己工作站上跑文档处理大概率也遇到过这种能跑但不爽的状态。这篇文章适合两类人一是刚接触本地大模型、想知道 27B 模型怎么跑得快一点的入门玩家二是已经在跑推理、但对投机解码只停留在听说阶段、想看看真实调优过程和效果的人。接下来我会按调优的时间线来写每一步都有实测数据支撑全程用我自己跑出来的配置说话。1. 14 tok/s 的痛本地 27B 模型为什么跑不动1.1 一个令人着急的基线成绩先复盘一下最初的运行环境单卡 RTX 4090 24GB模型用 INT4 量化加载推理框架用的是当时默认的 HuggingFace Transformers 加 bitsandbytes 量化后端没有额外优化。在这种配置下测单请求生成输出速度稳定在 14.2 tok/s。为了让大家对14 tok/s有个直观感知我举几个实际场景用本地模型做一个三句话的即兴回答大概 100 个 token你需要等 7 秒让它改一段 300 行的代码你基本可以起身去倒杯水再回来。这个速度不能说完全不能用但在代码补全这种高频交互场景里体验确实拉胯。你要知道哪怕是 60 tok/s人脑阅读节奏都已经跟不上了而 14 tok/s 是明显的慢半拍状态。我当时做了个简单的性能剖析发现 GPU 的算力利用率其实很低问题不是 4090 不够快而是每一步都太精打细算了。模型每生成一个 token都要把整个 27B 的权重从头到尾读一遍做完矩阵运算才能吐出下一个 token。这种串行模式在本地单卡上就是被显存带宽卡死的宿命。1.2 瓶颈不在算力而在串行读取这里可以给不熟悉底层原理的朋友算一笔账。27B 模型就算做完 INT4 量化也有大约 16GB 的权重。RTX 4090 的显存带宽约 1TB/s理论上读取 16GB 权重只需要 16 毫秒。但问题在于自回归生成是一个 token 一个 token 来的每生成一个 token 就要完整读取一次权重加上各种中间计算开销、采样开销、Python 调用开销一个 token 的实际耗时被拉到了 70 毫秒左右。14 tok/s 就是这么来的。很多人第一反应是那是不是我量化再低一点或者买张更贵的卡就能解决。量化到 INT4 已经是 27B 模型单卡能跑的底线精度了再低比如 INT3 或者 INT2效果下降明显。换 48GB 的 A6000 确实能把带宽拉高但那是硬件升级路线代价太高。所以真正的思路应该是既然算力用不满而每一步都在白白等待权重读取能不能减少大模型串行生成的次数如果能用一个小模型先快速生成一批候选 token再让大模型一次性验证这批 token 对不对效率就完全不一样了。这就是投机解码的核心思想。2. 投机解码让 27B 模型当裁判让小模型当侦察兵2.1 投机解码到底干了什么投机解码的原理其实一句话就能说清楚用一个小模型快速预写一段内容再用大模型逐字审批审批通过的地方一次放行而不是让大模型一个字一个字地憋出来。具体来说假设我们把投机步数 K 设为 5流程是这样的草稿模型比如 1.7B 的小模型先快速生成 5 个连续的 token然后 27B 的大模型把这 5 个 token 连同当前上下文一起做一次前向传播一次性给出这一串位置各自应有的输出概率接着逐位对比草稿模型写对了几个这几位就全部生效。如果某个位置大模型认为不对就从那个位置开始改用大模型自己的输出并且重新同步草稿模型的状态。关键点在于大模型本来生成 5 个 token 需要跑 5 次前向传播现在只需要跑 1 次。虽然这次前向传播要比单个 token 的稍微重一些因为要同时处理 5 个位置的 token但不会重 5 倍。在显存带宽受限的本地环境里减少大模型的前向次数就意味着直接省掉了 4 次完整的权重读取时间这个节省是极其可观的。打个比方这就像快递分拣原来的流程是每一件快递都要单独坐一次传送带过一遍安检机每件 5 分钟投机解码是先用一个熟练的小助理快速把 10 件快递按猜测分类放好然后过安检机扫描一整排扫描一次 8 分钟就算中间有一两件分错了重来整体也远快于一件一件过。2.2 为什么投机解码特别适合本地 27B 场景投机解码并不是万能的它对场景有要求。我做了个对比在云端 A100 集群上多张卡并行、算力剩余充足、显存带宽压力不大时投机解码的收益往往没有本地那么恐怖。但在单机单卡或者双卡的本地环境下它是性价比最高的加速手段之一。核心原因有三点本地算力相对充足但带宽受限。27B 模型在 4090 上的计算时间远远低于权重读取时间所以只要减少权重读取次数就能成倍提速。草稿模型极小几乎不消耗额外资源。一个 1.7B 模型跑一次前向只需要 2-3GB 显存生成 5 个 token 也只要几毫秒和 27B 模型 70 毫秒生成一个 token 相比完全是附赠成本。27B 这类模型生成的内容有很强的规律性。在代码、结构化文本、常见问答这类场景里小模型的猜测成功率很高尤其是温度调低之后接受率经常能到 80% 以上。我后来实测发现投机解码在本地双卡 27B 这个组合上收益能到 5-10 倍。这就解释了为什么我从 14 到 159 tok/s 的跨越主要依靠它而不是靠换卡。2.3 一个关键指标token 接受率做投机解码调优如果只盯一个数字那一定是token 接受率acceptance rate也就是草稿模型生成的 token 被大模型放行的比例。接受率为 100% 时一次投机循环产出的 token 数就等于 K接受率 50% 时平均每轮只能通过一半还要付出草稿模型生成 K 个 token 的时间这时候收益就会明显缩水。我在实测中遇到过接受率跌到 15% 的极端情况那时候投机解码不但没加速反而比不用还慢因为草稿模型白跑了一趟大模型还得重新生成。接受率主要受几个因素影响草稿模型和目标模型的能力差距、采样温度、K 值大小、以及推理时的 prompt 类型。温度越高两个模型的概率分布差异越大草稿模型猜中的概率就越低。K 值越大猜中所有 token 的联合概率越低接受率自然下降这个后面会详细展开讲实验数据。3. 环境准备与第一次施法3.1 硬件、软件栈与模型选择在切入投机解码实测之前先交代我最终的硬件环境和软件栈。这个配置我后来跑了大半个月非常稳定硬件双路 RTX 4090 24GB通过 NVLink 桥接开启张量并行系统Linux CUDA 12.4 PyTorch 2.4推理框架vLLM版本 0.6.x支持投机解码和 FP8 量化目标模型Qwen3.8-27BFP8 量化float8_e4m3fn草稿模型Qwen3-1.7BINT8 量化这里要解释两个选型决策。首先是为什么用 FP8 而不是 INT427B 模型用 FP8 权重约 28GB双卡 4090 各 24GB 张量并行刚好放得下每卡约 14GB还有余量装 KV cache 和草稿模型。INT4 虽然更省显存但在双卡张量并行场景下容易遇到负载不均衡而且 FP8 的精度损失明显小于 INT4输出质量更有保障。其次是草稿模型为什么选 Qwen3-1.7B。投机解码对草稿模型有两个硬性要求词汇表必须和目标模型完全一致否则 token id 对不上模型结构最好同源这样输出分布更接近。Qwen 系列的小大模型在词汇表上天然对齐所以选同门小模型基本不用额外处理 tokenizer。这一点在跨模型搭配时是最容易踩坑的地方后面会专门讲。3.2 vLLM 启用投机解码的第一条命令vLLM 是我试下来对投机解码支持最成熟的框架。启用过程不复杂核心就一行命令这里贴一个我用过的实际配置python -m vllm.entrypoints.openai.api_server \ --model Qwen3.8-27B \ --tensor-parallel-size 2 \ --dtype float8_e4m3fn \ --speculative-config algorithmspeculate_k \ --speculative-config draft_modelQwen3-1.7B \ --num-speculative-tokens 5 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85不同版本的 vLLM 参数名会有一点变化。比如早期版本是--speculative-model加--num-speculative-tokens新版本改成了--speculative-config如果你的版本报参数不识别去查一下对应版本文档就行。关键是--num-speculative-tokens这个 K 值以及草稿模型的指定方式这两个是整个投机解码的命脉。第一次启用投机解码我就把--num-speculative-tokens设成了 5温度保持默认。为什么先试 5因为大多数投机解码的实现都建议从 4-8 起步K 值太小收益不明显K 值太大容易过拟合草稿模型的初速度后面反而拖后腿。先跑一个中间值摸个底再根据实测调整。3.3 从 14 到 64第一次提升的体验与说明首次启用投机解码后我得到的数字是 63.8 tok/s对比基线 14.2 tok/s提升了约 4.5 倍。这个阶段我把双卡张量并行和 FP8 量化也一并启用了所以严格来说这是三个变量同时生效的结果。为了看清楚每个变量的贡献我专门做了对照测试配置组合输出速度单卡 INT4 无投机14.2 tok/s双卡 FP8 无投机31.6 tok/s双卡 FP8 投机 K563.8 tok/s从数据里可以明显看出单纯双卡张量并行只带来 2 倍左右的提升而叠加投机解码之后直接再翻一倍。这说明投机解码在带宽受限的场景下确实是效率放大器不是简单的锦上添花。实际体验也完全不一样了。63 tok/s 意味着机器生成 100 个 token 只需要 1.6 秒交互感从卡顿变成了流畅代码补全时基本能跟上打字速度。不过我的目标不止于此因为在这个阶段暴露出的一个明显问题是我用了默认采样温度1.0草稿模型的接受率并不高实际只有 41% 左右大模型每轮都有一大半时间是白等状态。所以下一步的核心就是把接受率提上去。4. 从 64 到 105K 值、采样温度与草稿模型的联合调参4.1 K 值实验5、8、12、15 的实测对比投机步数 K 是第一个要优化的参数。我把 K 分别设成 5、8、12、15在同一批 prompt 上跑测试温度全部固定为 0.2先固定一个值方便对比得到的结果如下K 值接受率输出速度578%81.3 tok/s874%90.6 tok/s1269%103.7 tok/s1561%97.2 tok/s这个数据说明一个规律K 值从 5 加到 12 的时候虽然接受率从 78% 掉到 69%但每轮验证的 token 数变多了整体吞吐反而是上升的。到 K15 时接受率进一步跌到 61%草稿模型生成 15 个 token 所花费的时间开始压过收益速度出现回落。直观地讲投机解码的收益可以近似看成一个抛物线K 太小则验证开销占比高K 太大则草稿模型猜不中、白干。最优 K 值取决于草稿模型生成速度和接受率衰减曲线的平衡点没有公式可以套只有实测。我最终把 K12 定为当前环境的稳定值。4.2 temperature 降到 0.2 的立竿见影效果温度对接受率的影响是我这次调优过程中印象最深的一环。初始我用默认温度 1.0 跑K5 时接受率只有 41%输出速度只有 55 tok/s 左右。后来把 temperature 降到 0.2同一配置下接受率飙升到 78%输出速度直接跳到 81 tok/s提升接近 50%。原因也不难理解。温度升高会让目标模型的概率分布变得平滑而草稿模型采样时往往基于自己更高置信的输出两边分布一对比草稿模型猜中的概率就低了。温度越低大模型越倾向于选概率最大的 token草稿模型也越容易预测到大模型的标准答案接受率自然就高。需要提醒的是降温度不是没有代价的。温度越低生成结果的多样性越差对于创意写作、头脑风暴这类场景不建议把温度压得太低。但对于代码补全、文档总结、结构化问答这类确定性强、需要稳定输出的任务温度 0.2-0.3 是非常合适的区间既能保住质量又能显著提高投机解码收益。投产比极高。4.3 草稿模型选型1.7B 还是 3B我还顺手做了一组草稿模型的对比实验看看更大一号的草稿模型有没有可能带来额外收益。我拿 Qwen3-3B 当草稿模型与 Qwen3-1.7B 对照K 值固定为 12温度 0.2草稿模型草稿生成耗时接受率输出速度Qwen3-1.7B INT831ms / 12 token69%103.7 tok/sQwen3-3B FP1648ms / 12 token78%88.4 tok/sQwen3-3B INT835ms / 12 token76%101.2 tok/s3B 草稿模型的接受率确实更高但它的生成速度明显变慢把接受率优势全吃掉了综合吞吐反而不如 1.7B。这说明草稿模型不是越大越好关键是生成速度和猜中概率的平衡。1.7B 在当前硬件上的综合表现最优3B 适合显存充裕、算力富余的场景。另外我试过拿 0.6B 这样更小的模型当草稿接受率只有 52% 左右输出速度 72 tok/s同样不如 1.7B。最终结论草稿模型选目标模型同系列的 1.5B-2B 级别小模型在这个量级的本地部署里是比较稳妥的锚点。5. 冲刺 159 tok/s最后的工程优化三板斧5.1 草稿模型的 INT8 量化与算子融合当 K 值和采样参数都调到比较理想的状态后我再看性能剖析发现草稿模型的生成时间仍然占了整个投机关卡循环的 35% 左右。这在 K12 时特别明显草稿模型生成 12 个 token 需要约 31ms而目标模型验证一次只要 20ms 左右。草稿模型跑得慢整个流程就被拖慢了。于是我把草稿模型从 FP16 换成了 INT8 量化权重体积从约 3.4GB 降到约 1.8GB生成耗时从 31ms 降到 24ms。这 7ms 的节省在整轮循环里差不多占 12% 的时间最终吞吐从 103.7 提升到 114.2 tok/s。再进一步我手动开启了 vLLM 的 CUDA Graph 优化让模型解码过程中的固定结构算子提前编译好减少在 Python 层反复 launch kernel 的开销。这一步对乱序到达的投机验证特别有效因为投机解码的前向传播形状是动态变化的CUDA Graph 可以减少形状改变带来的调度开销。启动 CUDA Graph 后吞吐又提了一档直接跳到 131.5 tok/s。5.2 连续批处理与并发吞吐到这里可能有人会问131 tok/s 已经够快了为什么还能到 159答案藏在并发请求的调度优化里。vLLM 本身有连续批处理Continuous Batching机制它不会等一个请求完整生成完再处理下一个请求而是每轮迭代动态地把多个请求聚合成一个 batch。投机解码在单请求模式下大模型每轮只验证草稿模型的 12 个 token但在多请求模式下大模型可以在一个 batch 里同时验证多个请求的草稿 tokenGPU 的算力利用更充分。我把 QPS 从单请求提到 4 个并发请求后整体吞吐从 131.5 提升到了 159.3 tok/s。注意这里测的是聚合吞吐单请求的延迟没有明显恶化。对于实际部署场景比如本地知识库问答、团队共享一个模型服务连续批处理 投机解码的组合效果非常值得一试。不过要说明如果你是单人单请求使用模型比如本地 IDE 插件里只跑一个会话159 这个数字里面有一部分是并发带来的聚合收益单请求实际速度大约在 130-140 tok/s 之间。即便如此相比最初的 14 tok/s 已经是接近 10 倍的提升体验从不能忍变成了完全可用。5.3 固定随机种子与可复现评测调试投机解码有一个容易忽略的陷阱如果不固定种子每次实验的接受率和速度都有浮动很难判断某个参数改动到底是真有效还是偶然波动。我在整个调参过程中固定了随机种子并对所有测试统一使用相同的 20 条 prompt、相同的 max_tokens 长度统一 256 token。这样每次改动只影响一个变量结果可以横向比较。建议大家在复现自己的调优实验时把种子和测试集固定下来否则很容易被一次偶然的高接受率误导做出错误判断。举个例子我在同一个配置下跑了 10 轮接受率浮动范围是 66%-73%吞吐浮动在 98-108 tok/s 之间。如果不固定种子单看一次 108 的结果就很容易过分乐观。6. 踩坑实录与排查手册6.1 典型问题速查表投机解码的参数五花八门踩坑的地方也比普通推理多不少。我把这半个月遇到的典型问题和解决办法整理成一张表方便大家对号入座问题现象可能原因解决办法启用投机解码后速度不升反降草稿模型太大生成耗时过长换更小草稿模型减少 K 值接受率极低低于 20%温度过高接近 1.0降到 0.3 以下再测报错 token id 对不上草稿模型和目标模型词汇表不一致换同系列同词汇表小模型显存 OOM草稿模型额外占用显存未预留降低gpu-memory-utilization到 0.75-0.8K 值增加但速度瓶子草稿生成耗时占比过高对草稿模型做 INT8 量化加大并发服务可以跑但日志速度很奇怪单位理解错误token/s vs tokens/s 聚合明确单请求还是聚合吞吐统一口径6.2 三个值得展开讲的坑第一个坑是跨系列草稿模型的词汇表冲突。我一开始图省事拿了一个通用小模型当草稿结果 vLLM 启动时直接报 tokenizer 的 vocab size 不一致根本跑不起来。后来查阅文档才知道投机解码的草稿模型和目标模型必须共享同一套词汇表否则模型输出的 token id 无法对齐验证环节完全失效。这也是我后来坚持选同系列小模型的原因建议各位在选草稿模型前务必确认 vocab_size 一致。第二个坑是显存分配策略。投机解码看起来只是多加载了一个小模型但 KV cache 的额外占用容易被忽略。默认gpu-memory-utilization0.9时双卡 4090 各 24GB27B FP8 占掉 14GB草稿模型 INT8 占 2GBKV cache 如果分配到过大一旦长上下文请求进来就很容易 OOM。我的处理是把gpu-memory-utilization降到 0.8给 KV cache 留更多可调度空间长上下文反而更稳了。第三个坑是 K 值设得太大导致的隐性回落。我上面列的对比数据里 K15 有回落但这只是平均情况。在实际长 prompt 场景比如文档问答prompt 有几千 token草稿模型的生成速度会因为上下文注意力计算而显著变慢K15 时整轮循环的时间甚至能拖到 K12 的一倍以上。所以在真实使用场景里K 不是越大越好12 也不一定适合所有人的硬件最稳妥的办法还是用自己的典型任务实际测一轮。7. 一些非官方的实操心得最后说几个我在整个调优过程中比较主观、但确实影响结果的体会。投机解码是一个非常依赖对症下药的技术。它在带宽受限、算力盈余的本地大模型部署里是神器但如果你是在 A100 这种高性能集群上跑大批量推理原本的批处理带宽利用率已经很高投机解码的收益反而可能被稀释。所以看到网上有人吹投机解码稳定提速 10 倍要结合他的硬件和场景来判断。采样温度不止影响生成质量还会直接影响投机解码的收益。如果你愿意牺牲一点点多样性把温度从 1.0 调到 0.2 左右接受率几乎翻倍。我家里的实际使用里代码补全和知识库问答都用温度 0.2日常完全够用。另外本地部署 27B 模型的性能调优不是一个一次性的工作。拿到一台新机器最好养成先测基线、固定随机种子、测接受率、再动 K 值和温度的习惯这样每次调参都能拿到可复现的对比数据而不是靠感觉乱调。如果你想在 Qwen3.8-27B 本地推理上继续深挖我建议下一步可以试试对着自己的业务数据做一轮草稿模型的微调蒸馏让小草模型更贴近目标模型在特定领域的输出分布接受率还有继续提升的空间。这算是投机解码进阶玩法的最后一步后面有机会我再单独写一篇展开。
