1. 从 14 tok/s 到 159 tok/s这次调优到底改了什么第一次在本地跑 Qwen3.8-27B 的时候我盯着终端里那个14.2 tok/s的数字看了很久。这个速度意味着什么意味着你问它一个稍微复杂点的问题它要花将近一分钟才能吐完一段像样的回答。对于一个习惯了云端 API 秒回的人来说这种体验几乎是不可接受的。但本地推理有它不可替代的价值——数据不出本机、没有调用成本、可以随意折腾量化版本和采样参数。所以问题就变成了怎么在不换硬件的前提下把速度拉到一个能用的水平。这次调优的最终结果是159 tok/s提升超过十倍。核心手段是投机解码Speculative Decoding配合量化策略调整、KV Cache 优化和批处理参数调优。但我要先说清楚一件事这个数字不是单纯靠打开一个开关就实现的它是一系列取舍的结果。投机解码本身有它的适用边界草稿模型选得不对、温度参数设得不好、显存带宽吃满了速度反而可能掉回去。这篇文章适合两类人看。一类是已经在本地跑过 7B 到 30B 级别模型、觉得速度不够用、想进一步压榨硬件性能的开发者另一类是刚接触本地推理、听说投机解码能加速、但不确定自己的场景适不适合上的朋友。我会把每一步的操作、背后的原理、实测中遇到的坑都摊开讲包括那些文档里不会写的细节——比如为什么你的草稿模型接受率突然从 70% 掉到 30%为什么显存看起来还有余量但速度就是上不去。先给一个全局的判断投机解码不是万能药它是一把需要精确调校的杠杆。用对了推理速度翻几倍很轻松用错了你只是在浪费显存和算力。下面我从原理开始拆然后一步步走到最终的配置方案。2. 投机解码为什么能加速从串行瓶颈说起2.1 自回归生成的本质瓶颈要理解投机解码为什么有效得先回到大模型推理的基本机制。标准的自回归生成是串行的模型每生成一个 token都需要把前面所有 token 作为输入重新计算一遍注意力。这个过程受限于显存带宽而不是算力。换句话说GPU 的计算单元大部分时间在等数据从显存搬过来而不是在真正做矩阵乘法。对于 27B 这个量级的模型即使做了 4-bit 量化权重也有十几个 GB。每生成一个 token都要把这十几 GB 的权重读一遍。显存带宽就那么多读一遍的时间基本固定所以 token 生成速度的上限是被带宽锁死的。这就是为什么你换一块算力更强但带宽没提升的卡速度可能纹丝不动。2.2 投机解码的核心思路用小模型猜用大模型验投机解码的思路很巧妙既然大模型一次前向只能出一个 token 太浪费那能不能让它一次验证多个 token具体做法是引入一个草稿模型Draft Model通常比目标模型小一到两个数量级。草稿模型先快速生成 K 个候选 token然后目标模型对这 K 个 token 做一次并行验证一次性判断哪些猜对了。这里的关键在于目标模型验证 K 个 token 的计算量和生成 1 个 token 的计算量相差不大因为瓶颈在显存带宽而不是算力。也就是说验证 5 个 token 和生成 1 个 token 花的时间差不多。如果草稿模型猜对了 3 个那你就用一次前向的时间得到了 3 个 token速度直接翻三倍。用一个生活化的类比你让一个实习生先起草一份文件的几个段落然后你作为主管一次性审阅。如果实习生水平不错大部分内容你直接通过那你的效率就大大提升如果实习生瞎写你全部打回重写那还不如自己从头写。2.3 接受率决定加速比的生命线投机解码的加速比可以用一个简化公式估算加速比 ≈ (1 - α^(K1)) / ((1 - α) * (1 K * c))其中 α 是草稿模型的接受率K 是每轮猜测的 token 数c 是草稿模型相对于目标模型的计算成本比例。这个公式告诉我们两件事接受率越高加速越明显草稿模型越轻量额外开销越小。实测中接受率低于 40% 的时候投机解码基本没有收益甚至可能因为草稿模型的开销而变慢。接受率在 60% 到 80% 之间是比较理想的区间。而接受率受什么影响草稿模型和目标模型的分布匹配度、温度参数、任务类型都有关系。代码生成和结构化输出的接受率通常比开放式创作高因为前者更确定。3. 草稿模型选型不是越小越好3.1 候选模型的实测对比我试了三个不同规模的草稿模型来搭配 Qwen3.8-27B分别是 0.5B、1.8B 和 4B 级别。测试环境是一块 24GB 显存的消费级显卡目标模型用 4-bit 量化上下文长度固定 4096温度 0.7每轮猜测 5 个 token。草稿模型规模接受率单轮验证耗时实测 tok/s显存占用0.5B52%38ms8916.2GB1.8B71%52ms13418.7GB4B78%79ms11222.1GB无草稿基线-70ms1414.5GB这个表格很说明问题。0.5B 的草稿模型虽然轻但接受率只有 52%加速效果一般。4B 的草稿模型接受率最高但单轮验证耗时大幅增加最终速度反而不如 1.8B。1.8B 是甜点区间接受率和开销达到了比较好的平衡。3.2 为什么 4B 草稿模型反而更慢这里有个反直觉的地方值得展开说。4B 草稿模型的接受率确实更高但它每轮生成 K 个候选 token 的时间也更长。投机解码的总时间 草稿生成时间 目标验证时间。当草稿模型大到一定程度它自己生成 5 个 token 的时间就快赶上目标模型验证的时间了加速比自然被吃掉。更关键的是显存。4B 草稿模型加上 27B 目标模型显存占用冲到 22GB留给 KV Cache 的空间被严重压缩。上下文一长就得频繁换出换入速度断崖式下跌。我在测试长上下文时4B 方案在 8K 上下文下直接掉到 60 tok/s 以下而 1.8B 方案还能维持在 110 tok/s 左右。选草稿模型的核心原则在显存能容纳的前提下优先保证接受率但不要为了几个百分点的接受率提升而牺牲显存余量。显存余量决定了你能跑多长的上下文这在实际使用中比峰值速度更重要。3.3 草稿模型与目标模型的同源性还有一个容易被忽略的点草稿模型和目标模型的词表和训练分布最好同源。我用了一个不同系列的 1.8B 模型做草稿接受率只有 58%换成同系列的 1.8B 之后直接跳到 71%。原因很简单同系列模型的 tokenizer 和输出分布更接近草稿模型猜出来的 token 更容易被目标模型接受。如果你手头没有同系列的草稿模型退而求其次的选择是词表大小一致、训练数据领域重叠度高的模型。实在找不到那就老老实实跑基线别硬上投机解码。4. 参数调优K 值、温度与 KV Cache 的三角关系4.1 每轮猜测 token 数 K 的取值K 值决定了草稿模型每轮猜多少个 token。K 太小加速效果不明显K 太大猜错的概率累积后面的 token 全被拒绝浪费算力。我做了 K 从 3 到 8 的扫描测试固定草稿模型为 1.8B温度 0.7K 值接受率有效 token/轮实测 tok/s374%2.1108472%2.6126571%3.0134668%3.2131764%3.3122859%3.2109K5 是峰值。K 超过 6 之后接受率下降的速度超过了每轮 token 数的增长总吞吐反而降低。这个结论在不同任务上会有偏移代码生成任务因为确定性高K 可以设到 6 到 7开放式对话建议 K4 到 5。4.2 温度参数对接受率的隐性影响温度是投机解码里最容易被忽视的变量。温度越高目标模型的输出分布越平坦草稿模型猜中的概率越低。我实测了一组数据温度 0.1接受率 89%速度 168 tok/s温度 0.7接受率 71%速度 134 tok/s温度 1.2接受率 48%速度 82 tok/s温度从 0.7 提到 1.2接受率掉了 23 个百分点速度直接腰斩。这不是说不能用高温度而是说如果你追求速度就得在创造性和接受率之间做取舍。我的做法是日常问答和代码任务用 0.3 到 0.7创意写作单独切到高温度并接受速度下降。还有一个技巧动态温度。在生成的开头几个 token 用较低温度保证方向正确后面逐步升高温度增加多样性。这个策略能让平均接受率提升 5 到 8 个百分点实现起来也不复杂就是在采样循环里根据已生成 token 数调整温度参数。4.3 KV Cache 量化与显存腾挪投机解码需要同时加载草稿模型和目标模型显存压力比单模型大得多。KV Cache 是另一个吃显存的大户尤其是在长上下文场景下。我把 KV Cache 从 FP16 量化到 INT8显存占用减少了将近 40%速度损失不到 3%。这个取舍非常划算因为省下来的显存可以支撑更长的上下文或者允许你用更大的草稿模型。具体操作上大多数推理框架都支持 KV Cache 量化选项。需要注意的是KV Cache 量化对接受率有轻微影响因为注意力计算的精度下降了。实测接受率从 71% 降到 69%基本可以忽略。显存分配的优先级建议目标模型权重 草稿模型权重 KV Cache 其他缓冲。如果显存不够先降 KV Cache 精度再考虑换更小的草稿模型最后才动目标模型的量化等级。5. 实测中的意外接受率突然暴跌的排查过程5.1 问题现象从 71% 掉到 34%调优进行到一半的时候我遇到一个诡异的现象。同样的配置前一天跑接受率还有 71%第二天重新启动之后掉到了 34%速度从 134 tok/s 跌到 58 tok/s。硬件没动模型没换参数没改就是重启了一下。这种问题最让人头疼因为它不符合任何已知的规律。我花了将近两个小时排查过程记录下来对遇到类似情况的朋友应该有帮助。5.2 排查链路从显存到 tokenizer第一步检查显存占用。发现显存比之前多了 1.2GB但没到溢出的程度。用监控工具看发现显存碎片化比较严重可能是之前进程没有完全释放。第二步检查模型加载日志。发现草稿模型加载时有一个警告提示某个层的权重被重新初始化了。这个警告之前没注意到因为被其他日志淹没了。第三步对比 tokenizer 配置。这是关键发现草稿模型和目标模型的 tokenizer 版本不一致。目标模型用的是更新版的 tokenizer词表多了几百个 token而草稿模型还是旧版。之前能跑是因为缓存了旧的 tokenizer 配置重启之后重新加载版本冲突就暴露了。5.3 修复方案与验证修复很简单统一 tokenizer 版本重新导出草稿模型的配置。但排查过程说明了一个重要问题投机解码对模型配置的一致性要求极高。任何版本不匹配都可能导致接受率暴跌而且这种问题不会报错只会默默降低性能。修复后的验证步骤先跑一个固定 prompt记录接受率和速度作为基线逐步增加上下文长度观察接受率是否稳定切换不同任务类型代码、问答、创作确认接受率波动在合理范围重启进程再次验证确保配置持久化生效这套验证流程我现在每次调整配置后都会跑一遍虽然花几分钟但能避免很多隐性性能损失。5.4 另一个坑批处理大小与接受率的冲突还有一个意外发现当并发请求数增加时接受率会下降。单请求时接受率 71%4 并发时降到 62%8 并发时只有 51%。原因是批处理会让不同序列的草稿 token 混在一起验证降低了验证的精确度。解决方案是限制并发数或者对每个请求单独维护草稿状态。我最终把并发数限制在 2 到 3虽然吞吐量没有线性增长但单请求的延迟更稳定整体体验更好。如果你追求的是吞吐量而不是延迟那可以接受接受率的下降用更大的批处理来弥补。6. 最终配置方案与不同场景的适配建议6.1 我的稳定配置清单经过反复调优下面这套配置在我这里跑了两周没有出过问题速度和稳定性都满意配置项取值说明目标模型Qwen3.8-27B 4-bit量化等级 Q4_K_M草稿模型同系列 1.8B 4-bit词表与目标模型一致每轮猜测 K5代码任务可调到 6温度0.5创意任务单独调高KV CacheINT8长上下文必备并发数2延迟优先上下文长度8192显存余量约 2GB这套配置下日常问答稳定在 130 到 140 tok/s代码生成能到 150 以上峰值跑到过 159。显存占用控制在 19GB 左右留了足够的余量给系统和其他进程。6.2 不同硬件档位的降级方案不是每个人都有 24GB 显存的卡。如果你用的是 16GB 或 12GB 的卡需要做取舍16GB 显存目标模型降到 3-bit 量化草稿模型用 0.5BK4KV Cache 用 INT8。预期速度 70 到 90 tok/s。12GB 显存目标模型 3-bit放弃投机解码专注单模型优化。预期速度 20 到 30 tok/s。8GB 显存建议换更小的目标模型27B 这个量级在 8GB 上跑起来太勉强。显存不够的时候投机解码的收益会被显存换入换出的开销吃掉不如老老实实跑基线。6.3 什么任务适合上投机解码不是所有任务都适合投机解码。根据我的实测经验适合的场景代码补全和生成、结构化数据提取、翻译、摘要、固定格式的问答。这些任务输出确定性高草稿模型容易猜对。不适合的场景开放式创意写作、高温度对话、需要大量随机性的任务。这些场景接受率低投机解码的收益有限甚至可能因为草稿模型的开销而变慢。一个简单的判断方法如果你发现同一个 prompt 跑两次输出差异很大那这个任务的接受率大概率不高。反之如果输出比较稳定投机解码就能发挥作用。6.4 监控与持续调优最后分享一个我养成的习惯记录每次推理的性能指标。包括接受率、每轮有效 token 数、首 token 延迟、总吞吐。这些数据积累下来能帮你快速定位性能退化的原因。我用的方法很简单在推理脚本里加几行日志把指标写到 CSV 文件然后用表格软件画个趋势图。有一次发现接受率在一周内缓慢下降了 8 个百分点查下来是系统更新后显存管理策略变了调整之后恢复。如果没有这些记录这种缓慢退化很难察觉。投机解码的调优不是一劳永逸的事硬件状态、驱动版本、模型更新都会影响最终表现。保持监控定期复测才能让这套方案持续稳定地跑下去。