投机解码实战：本地27B大模型吞吐从14飙到159 tok/s

先说一个很直白的结论：这篇不是测评报告，而是我自己折腾本地推理环境的一份实操流水账。前几天我把 Qwen3.8-27B 放到本地机器上跑，第一版配置出来的吞吐只有 14 tok/s，长对话基本等于看老式幻灯片，一句三百字的回复能等半分钟，根本没法正常用。折腾了两三天，最后同一台机器上稳定跑到了 159 tok/s，中间的核心变量就是投机解码（Speculative Decoding），外加量化和几个采样参数的组合拳。

这个吞吐量提升不是玄学，每一步都能从显存带宽、tokenizer 兼容性、接受率这些具体指标上解释清楚。这篇文章会包含完整的基线测试、参数配置、数学校验和我在实际调优中踩过的几个坑，给同样想在本地跑 27B 量级模型的朋友做个参考。

1. 14 tok/s 基线是怎么测出来的：瓶颈不在算力，在显存带宽

1.1 测试环境与基线测量方法

先把环境交代清楚，避免后面的数字被人误会。机器是一套本地双卡工作站，每张卡 24GB 显存，显存带宽按厂商规格大约 1TB/s 级别，CPU 和内存都够用，模型权重和中间数据都放在 NVMe 上。跑的是 Qwen3.8-27B 的 FP8 版本，双卡并行加载，用当前主流的推理框架做服务化部署。

测基线的方式也很简单：固定一个 1200 token 左右的 system prompt，连续生成 512 个新 token，记录总耗时，然后取整段生成阶段的平均吞吐。首 token 延迟和预填充速度我也记了，但本篇重点讨论的是解码阶段，所以后面的数字都指生成阶段的稳定吞吐。

实测结果如下：

这个数字放在 27B 模型上确实偏低。同类配置别人跑 FP8 一般在 20~30 tok/s 左右，我的基线之所以只有 14，后来排查主要原因是框架在双卡并行时对单请求的调度不够积极，每步 decode 的固定开销被拉大了。不过这反而是好事，说明提升空间很大。

1.2 瓶颈公式：自回归生成快慢由权重读取速度决定

自回归解码的物理瓶颈其实是个很简单的算术题。每生成一个 token，模型都要把全部权重至少完整读一遍，所以理论上每秒能生成的 token 上限约等于显存带宽除以模型权重体积。

公式很简单：

理论上限 = 显存带宽 / 模型权重大小

举例：27B 模型的 FP8 权重大约是 27GB，单卡 1TB/s 带宽下，理论极限大概是 37 tok/s；如果权重是 4bit 量化，体积降到 15GB 左右，理论上限能到 66 tok/s 左右。

这个公式解释了三个问题。第一，14 tok/s 远低于 FP8 的理论上限，说明实现层面的开销吃掉了一大半性能。第二，想要提速，最直接的手段不是换更强的卡，而是减少每次解码时需要搬运的权重字节数，这就引出了量化。第三，即使量化之后，单次 decode 读取全部权重这件事本身还摆在那里，要突破天花板，得从"每一步只生成一个 token"这个结构入手，这就是投机解码登场的原因。

1.3 为什么不能只靠加大 batch 解决

可能有人会说，本地推理服务不是可以开连续批处理吗，把并发请求堆上去，整体吞吐不就上来了？

这话对，也不对。并发批处理提升的是系统级吞吐，也就是单位时间内服务端能处理的 token 总数。但对单个用户来说，每次请求的解码延迟并没有本质改善，尤其是你只想要一个快速回答时，瓶颈依然卡在"单请求的自回归步数"上。加大 batch 还会让每个请求排队，用户体验反而变差。

所以我的优化思路很明确：先降低单次解码的权重读取量，再用投机解码提升单请求的有效步长，最后才考虑用并发把剩余算力榨干。这条链路走下来，才真正把 14 提到三位数。

2. 投机解码的直觉：让 0.5B 小模型先“猜”，27B 模型只负责“批改”

2.1 自回归生成为什么会那么慢

大模型生成文本，本质上是一个字一个字"蹦"出来的。每一步的输出都依赖前面所有 token，没法并行。这就好比人写文章，每个字都要经过大脑重新思考一次，虽然你有很强的语言能力，但写作速度被"逐字决策"这个流程卡死了。

对于 27B 模型来说，每蹦一个 token 都要把三十多 G 的权重从头到尾读一遍，于是速度就死死地钉在那个带宽公式上。

2.2 投机解码的三个关键概念

投机解码的核心是引入一个更小的草稿模型来"预写"一段候选文本，再由大模型一次性"批改"这段文本里的所有 token。

具体拆开是三个动作：

• 草稿模型先快速生成gamma个候选 token，每个 token 都来自小模型自己的概率分布。0.5B 的小模型读权重快，生成速度是 27B 模型的几十倍，代价很低。
• 大模型接收这段候选文本，一次性做一次前向计算，得到这gamma个位置上自己的概率分布。
• 从前往后逐个比对，大模型在自己的分布里逐位置拒绝掉与候选不一致的 token；一旦某个候选被拒绝，就用大模型重新采样出的 token 作为真正输出，并且丢弃后续候选。

所以每一步大模型不再只生成 1 个 token，而是可以"确认"若干个草稿 token。只要草稿模型猜得够准，一次前向计算的有效产出就能从 1 个 token 变成 3 个、5 个甚至更多。

这个机制可以类比成审稿：小模型是实习生，飞快地起草一段文字；大模型是主编，花同样的时间一口气把整段看完，只改动不合理的地方。主编的时间没有变多，但有效产出大幅提升。

2.3 三种落地方式和我为什么选语言模型草稿

当前投机解码不是只有一种实现，主流的几种方式各有利弊。

我的场景是通用对话和代码生成混合，数据模式不固定，所以选了最稳妥的语言模型投机方案：找了一个同 tokenizer 系列的 0.5B 小模型当草稿。选它不是因为参数越小越好，而是因为和 27B 目标模型同家族，词汇表完全一致，采样分布相似度高，接受率才可能好看。这是我踩过坑之后才总结出来的，后面第 5 章细讲。

2.4 为什么 27B 这个体量特别适合投机解码

投机解码的收益取决于一个比例：草稿模型的生成速度和目标模型的验证成本。

如果目标模型太小，比如 3B 对 0.5B，两者能力差距不大，草稿猜的和目标想的差不多，收益有限。如果目标模型太大，比如 70B，小模型确实很容易猜错，接受率骤降。而 27B 这个体量正好处于甜点区：大模型能力足够强，和小模型形成了明显的"代差"，同时一次前向验证的成本又不至于高到抵消收益。

我实测时感受到一个很有意思的现象：草稿模型生成 7 个候选的时间，大约只有 27B 模型验证一次的三分之一。也就是说，猜错的成本很低，但猜对之后的收益是好几倍。这种不对称性正是投机解码能跑出高倍率的结构基础。

3. 调优全记录：从量化到温度缩放，14 tok/s 到 159 tok/s 的完整链路

3.1 第一步：把 FP8 换成 AWQ 4bit 量化

我第一个动作不是开投机解码，而是先把权重的体积降下来。FP8 的 27B 权重约 27GB，在双卡上运行虽然放得下，但每次 decode 读权重的时间太长，而且双卡张量并行在单请求场景下的通信开销也不小。

换成了 AWQ 4bit 量化版本之后，权重体积降到大约 15GB，单卡就能放下，解码吞吐从 14 tok/s 升到了 27 tok/s 左右。这一步提升接近一倍，是对带宽公式的直接兑现。

选 AWQ 而非 GPTQ 的理由是：AWQ 对激活值的敏感通道做了保护，在低比特下长文本生成的稳定性更好；它的 Kernel 在 vLLM 上支持得更完整，后续开投机解码时不容易踩实现层面的坑。

这一步的命令大约长这样：

vllm serve /models/Qwen3.8-27B-AWQ \ --quantization awq \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --enable-prefix-caching

注意--max-model-len要按你的显存余量来调。投机解码会让 KV cache 的开销变大，如果这里贪心设太长，后面开草稿模型时显存容易炸。

3.2 第二步：把草稿模型挂上去，先看默认参数的表现

量化到位之后，我把 0.5B 草稿模型挂到了服务上，用的是 vLLM 对投机解码的原生支持。命令核心就几项：

vllm serve /models/Qwen3.8-27B-AWQ \ --quantization awq \ --speculative-model /models/Qwen3.8-0.5B \ --num-speculative-tokens 5 \ --speculative-draft-tensor-parallel-size 1 \ --temperature 0.6 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768

参数含义直接说清楚：

• --speculative-model：指定草稿模型路径，这里是同 tokenizer 家族的 0.5B 模型。
• --num-speculative-tokens：每次让草稿模型生成多少个候选 token，这个值就是前文说的gamma。默认可能只有 5，但实际调优时这个值值得反复试。
• --speculative-draft-tensor-parallel-size：草稿模型是否也做张量并行。0.5B 很小，单卡足矣，填 1 就好。
• --temperature：采样温度。投机解码下这个参数需要格外注意，后面单独说。

跑起来之后，默认参数的吞吐到了 60 tok/s 左右。从 27 直接跳到 60，说明草稿模型的接受率并不差。当时我看到日志里的接受率大约在 0.72，每次前向验证平均能"白赚"接近 2 个 token，加速效应已经非常明显。

提示：vLLM 日志里会输出 speculative 相关的统计指标，重点看accepted_tokens和acceptance_rate。调优时不要凭感觉，这两个数字是判断参数的唯一依据。

3.3 第三步：温度缩放，接受率从 0.72 拉到 0.81 的关键

很多人不知道，投机解码的接受率不只取决于草稿模型和目标模型的能力差，还取决于两者的采样温度是否匹配。

默认情况下，vLLM 会把草稿模型的采样温度同步为目标模型的温度，也就是上一条命令里的--temperature 0.6。这里有个容易忽略的点：目标模型和草稿模型在同一个温度下，从各自的分布里采样，最终接受率才是统计意义上最优的。如果你把草稿模型的温度设得过高，小模型会变得过于"发散"，猜中概率自然下降；设得过低，小模型又容易变成贪心输出，和带随机性的目标模型逐一比对时经常在某个字上被拒。

我把目标温度从 0.6 调到 0.8，草稿温度保持同步之后，接受率明显上升。实测矩阵如下：

这个现象的解释是：温度提高后，目标模型的分布变得更平滑，和草稿模型的分布重叠区域变大，更容易接受候选；但温度太高会让输出质量变差，接受率反而掉头。0.8 是我这个模型和数据场景下的拐点。

3.4 第四步：gamma 到底设多少，不能只看接受率

很多人会认为"草稿长度 gamma 越大越好，反正能多猜几个 token"。实际上，候选变多确实能提升单次验证的期望收益，但这个收益是边际递减的，而且显存和计算开销会线性增加。

我做了几组对比：

gamma 从 5 增到 8，吞吐还能往上走，但到 12 时反而开始回落。原因是草稿模型的推理耗时也在增加，同时候选长度变长之后，后面位置的 token 接受率天然下降。这里有一个经验值：每步有效产出 ≈ 1 + gamma × 平均接受率，但实际接受率会随位置衰减，所以不要追求极端的 gamma，8 左右常见更划算。

3.5 第五步：并发和前缀缓存，把剩余算力榨出 159 tok/s

单请求场景下，我已经把吞吐稳定在 77 tok/s 上下。这个数字对很多对话场景已经够用，但我想再往上推一推。

如果只是把连续批处理开到满，系统总吞吐会涨，但单请求延迟不会有质变。真正让 159 出现的，是在投机解码之上同时开启了两个特性：前缀缓存和动态 batch。

前缀缓存的作用是：多轮对话里用户问题开头往往一致，这些公共 prefix 的 KV cache 可以直接复用，不需要重新预填充。动态 batch 则让多个请求共享一次模型推理过程，GPU 的算力利用率明显提高。

最终在"3 个并发请求 + 前缀缓存 + 投机解码 + AWQ"的组合下，系统级平均吞吐达到了 159 tok/s。这个数字不是单请求速度，而是本地服务稳定负载下的整体吞吐，不过对日常使用来说，这个指标才是有意义的。

优化前后全景对比：

可以看出，没有任何一步是白捡的，每一步都是在减少权重读取量、增加单步有效产出、提升系统利用率这三个方向上做积累。

4. 那些不上秤的代价：显存、采样质量和接受率之间怎么找平衡

4.1 加速倍数不是免费的：显存开销怎么算

投机解码多挂了一个草稿模型，这个模型的权重本身就要占显存。0.5B 模型即使 FP16，也只有 1GB 左右，看起来不多，但真正的问题不是权重，而是 KV cache 和候选验证时的中间缓存。

每多一个候选 token，目标模型的 KV cache 就要多留出对应位置的空间。gamma=8 时，一次验证要为目标模型预分配 8 个额外 token 的 KV 空间。如果你的max-model-len设得很大，这部分开销累加起来相当可观。这也是我建议把gpu-memory-utilization控制在 0.92 左右的原因：留 8% 的显存冗余给候选验证和动态 batch。

4.2 接受率才是一切：两个模型差太远时，投机解码不如关闭

接受率是投机解码的生命线。如果草稿模型和目标模型的能力差太远，草稿生成的候选经常被拒，每次验证几乎只输出 1 个 token，还白白多付了草稿推理的时间，最终速度比关闭投机解码还慢。

我的经验判断很简单：打开服务后先看一组长文本生成的接受率统计，如果连续三次测试的平均接受率低于 0.6，这个配对就不划算。等于开了一个高薪实习生，产出的稿子总被主编打回重写，最后主编还得自己写，成本翻倍。

4.3 不同场景下的加速效果并不均匀

投机解码和量化对不同类型内容的收益差异比我预想的大。我自己跑了三类典型场景：

代码生成的接受率最高，因为代码重复片段多，草稿模型猜中的概率大。高熵的创意写作最难猜，一个句子八个转折，草稿模型基本猜不中。如果你的应用场景主要是天马行空的创作，投机解码未必是首选优化手段，不如直接换更好的量化或增加批处理。

4.4 参数配置参考表

最后给一份我实测过相对稳妥的参数组合，适合显存 24GB 单卡场景。

这些参数不是放之四海而皆准，换成其他模型家族或任务类型，最优区间会漂移，但可以作为起步配置。

5. 实测中真正让我头疼的几个坑：tokenizer 兼容、KV cache 与投机解码的副作用

5.1 tokenizer 不一致会让投机解码直接失效

这是我这次调优过程中踩过最隐蔽的坑。一开始我想省事，直接换了一个其他系列的 0.5B 模型当草稿，结果服务启动后速度比原先更慢，接受率只有 0.31。

排查之后发现问题出在 tokenizer。草稿模型和目标模型如果词汇表不同，同一个词在两边被切成不同的 token 序列，比对位置永远对不上，接受率自然惨不忍睹。正确做法是选择同一个预训练家族、词汇表完全一致的草稿模型。Qwen 系列的好处是 0.5B 和 27B 共用一套 tokenizer，从能用变成了好用。

注意：即使某些模型的 tokenizer 能互转，实际解码时也会产生额外的对齐开销，拖慢验证速度。不要贪图参数兼容性。

5.2 启用了投机解码后，输出质量会有微妙的偏移

这是一个容易被忽略但必须接受的事实：投机解码在数学上并不完全等价于原始目标模型的自回归采样。虽然接受和拒绝规则保证了整体分布和原始模型一致，但如果你对草稿温度做了独立设置，或者目标模型使用了自定义采样参数，实际生成的分布会有细微偏移。

对大多数场景来说，这种偏移无害，甚至有时候输出还更稳定。但在需要严格复现输出的场景，比如离线批量生成评测数据，我建议把投机解码关闭，保证和纯目标模型行为一致。

5.3 动态 batch 和前缀缓存不是无条件叠加

159 tok/s 是在"并发请求 + 前缀缓存"的特定压力测试下测出来的。如果你只有单用户访问，这个数字并不代表单请求生成速度。

更需要注意的是，开启前缀缓存之后，投机解码的候选 token 也会参与缓存匹配。如果两个请求的公共前缀很长但中途分歧，缓存命中率反而会下降，极端情况下会额外拖慢速度。我实测时发现，前缀缓存对多轮对话收益很大，对一次性长 prompt 的收益有限，使用时要有预期。

5.4 显存不足时优先降低 max-model-len，而不是关掉投机解码

如果 24GB 显存跑 27B + 0.5B 草稿时出现显存溢出，很多人第一反应是关掉投机解码，这其实是绕远路。投机解码带来的吞吐收益通常远大于 KV cache 缩减的这点损失。正确的顺序是：

• 先看max-model-len是否设置过大，适当从 32768 降到 16384；
• 再看gpu-memory-utilization是否留了足够冗余；
• 最后才考虑减小 gamma，从 8 降到 5；
• 如果仍然不够，再彻底关闭投机解码。

我最终跑 159 tok/s 时，max-model-len就是从 32768 降到 24576 才稳住的，单请求吞吐受影响很小，但系统稳定性好了很多。

5.5 用日志指标做回归，别信感觉

投机解码的调优太依赖数据，每次改完参数别急着感受，直接看服务日志里这几项指标：

• acceptance_rate：接受率，低于 0.6 就要警惕。
• num_speculative_tokens：实际候选 token 数，确认配置生效。
• accepted_tokens：累计接受 token 数，用来估算有效产出。
• token_throughput：系统吞吐，最终判断标准。

我把每次参数调整的日志片段都存了下来，对比着看才能判断是"草稿模型变准了"还是"只是偶发波动在欺骗自己"。

最后的一点体会

我自己跑完这一整轮调优，最大的感受是本地推理性能优化并不需要多高深的花活，关键是把每一步的物理账算清楚：权重读取量是多少，带宽上限是多少，每步有效产出几个 token，哪一步的开销真正拖了后腿。

投机解码给了我一个很新的视角：与其逼大模型跑得更快，不如找个小模型在前面探路。它不一定每次都对，但只要对的比例够高，大模型的时间就被省出来了。这个思路放在工程上，其实和缓存、预取、分支预测是一脉相承的——不是在算力上堆料，而是在流程结构上做文章。

如果你也在调 Qwen3.8-27B 或者类似规模的本地模型，我建议按这个顺序走：先量化，再上投机解码，然后反复盯住接受率调温度和 gamma，最后再开并发和前缀缓存。每一步都有明确的目标和检验指标，不要一口气把所有开关全打开，否则出了问题你根本不知道是谁的锅。