投机解码实战：本地运行27B大模型从14到159 tok/s的调优之路

1. 先看结果：从 14 tok/s 到 159 tok/s 的调优路径

把 Qwen3.8-27B 这个量级的模型放在本地跑，很多人第一反应是“显存够不够”，实际上更折磨人的是速度。默认参数加载完模型，随便写了句提示词，看着每秒 14 个 token 的输出，我都怀疑人生了：这哪里是对话，明明是老式电报机。折腾完投机解码、采样参数、线程调度和锁内存之后，同一台机器上测出了 159 tok/s 的峰值，长文生成稳定在 100~120 tok/s。前后差了 10 倍，值得把完整过程捋一遍。

这篇分享写给两类人：一类是想在本地把 27B 级别模型跑流畅的玩家，另一类是已经跑起来但速度不理想、想搞清楚投机解码到底怎么用的朋友。我会把原理、参数、实测数据、踩坑记录全部摊开，你照着调一遍，大概率也能翻几倍。

先说结论，避免你被标题误导：159 tok/s 是短提示词、固定 seed、连续多轮测速后取到的最佳值，不是所有场景都能复现的日常速度。真正让我满意的，是投机解码打开之后生成的节奏确实肉眼可见地变快了，这才是值得关注的地方。

1.1 测试环境与基线成绩

为了避免“一步到位”的错觉，先把测试环境写清楚。我用的是一台桌面级机器，处理器 16 核，内存 64GB，显卡是 24GB 显存的型号，操作系统是比较常见的 Linux 发行版。模型文件是 Qwen3.8-27B 的 GGUF 量化版，精度 Q4_K_M，推理运行时用的社区开源方案 llama.cpp。

先说基线：默认参数启动，模型全部卸载到 GPU，不做任何优化，实测生成速度 14.2 tok/s。这个数字是什么概念？读一条 500 字的回复要等 35 秒，普通人根本接受不了。此时显存占用 22GB 左右，GPU 利用率一直不低，但输出就是慢。

我一开始以为是量化格式的问题，于是把 Q4_K_M 换成更高精度的 Q8_0 试了试，速度反而掉到了 8 tok/s。这给了我一个明确信号：瓶颈不在精度，而在整个推理的执行方式，靠换量化文件解决不了问题。

1.2 第一个瓶颈：串行生成是原罪

大模型生成 token 的方式是逐字输出，当前 token 没算完，下一个 token 不可能开始。这个串行过程里，单个 token 的等待时间等于“读取权重 + 计算 attention + 采样”的耗时。27B 模型的权重总量就摆在那里，哪怕量化到 Q4_K_M，每次都要从显存走一遍完整的数据，内存带宽直接卡死速度上不去。

这不是单张显卡的问题，而是架构层面的限制。当模型权重无法全部塞进更快的片上缓存时，瓶颈就转移到了显存带宽上。Q4_K_M 量化已经把权重压到了 16GB 左右，继续压位宽能提一点速度，但会牺牲生成质量，不是正路。

真正突破串行瓶颈的思路，是让大模型一次“看”多个 token，而不是每次只处理一个。投机解码就是干这个事的，它把这些本应串行等待的 token 玩出了并行验证的花样。下一节把原理讲透，这是整个调优的核心。

2. 投机解码到底在干嘛

投机解码（Speculative Decoding）不是新概念，但对很多刚开始玩本地大模型的人来说，还是有点抽象。我用一个场景说明白：假设你是主编，一个实习生负责起草稿子。你以前是实习生写完一句话你才批一句，现在你手里有 8 句还没看过的草稿，但你只需要扫一眼就能同时判断这 8 句行不行，行的留下，不行的当场改。于是审批速度就提上来了。

对应到推理过程：实习生就是草稿模型，一个体积小、速度快的小模型；主编就是目标模型，也就是 27B 模型。小模型先快速自回归生成 8 个候选 token，大模型拿到这 8 个 token 之后，用一次前向计算同时验证它们的目标概率分布。验证通过的 token 直接采纳，没通过的在第一个出错位置停下来，用大模型自身的输出替换掉后续全部候选。

关键点在于：大模型验证多个 token 的计算量，和验证单个 token 相比增加得不多，因为权重读取、关键计算部分在 batch 维度上合并了。这才是投机解码省时间的根本原因。

2.1 实习生写稿、主编审稿：一次并行验证多个候选

假设草稿模型生成了一批候选 token，长度设为 N。目标模型把 N 个 token 组成一个 batch 做一次前向推理，得到每个位置的预测分布。对比原则很简单：草稿模型预测的 token 是否落在目标模型的 top-1 里，连续一致就连续接受，一旦不一致就回到错误位置，从目标分布中重新采样。

这里有一个容易忽略的细节：草稿模型的生成过程依然是串行的，只不过它非常小，生成 8 个 token 的时间可能比大模型生成 2 个 token 还短。也就是说，草稿模型的“快”是前提，目标模型的“并行验证”才是加速的主力。两者配合起来，才实现了“一步生成多个 token”的效果。

一个完整投机解码周期的开销是“草稿模型生成 N 个 token + 目标模型一次前向 + 可能的重新生成”。如果能接受全部 N 个 token，那么这一个周期就相当于生成了 N 个 token，对比原来一次前向只能生成 1 个 token，加速比直接诱惑到心中窃喜。

2.2 接受率：决定加速比的核心指标

投机解码不是无条件加速，它有一个核心指标叫接受率，指的是草稿模型生成的 token 中，被目标模型验证通过的比例。接受率越高，加速越明显；接受率低到一定程度，投机解码会比直接推理更慢，因为被拒绝后重新采样，白白浪费了之前的计算。

影响接受率的因素有三个：草稿模型与目标模型的知识分布是否接近、采样参数是否一致、投机长度设置是否合理。如果草稿模型和目标模型来自同一个基座系列，接受率通常不错；如果硬塞一个完全不搭边的小模型，基本就是浪费电。

我做了个小测试对比：用同系列 3B 模型做草稿，接受率大概四成；换成同系列 1.1B，接受率反而能到六成以上。原因不难理解，小模型更“顺从”，预测倾向更接近大模型的概率分布。但草稿太小也会带来另一个问题——它生成候选的速度虽快，可候选质量不够高，整个周期的净收益需要综合权衡。

2.3 不是所有模型都适合投机解码

投机解码并不是放到任何模型上都能产生神效。如果你跑的是 3B、7B 这种小模型，目标模型本身就快，草稿模型的那点速度优势根本弥补不了目标模型额外计算 batch token 的开销，甚至可能拖慢整体速度。真正适合投机解码的是“大模型 + 大权重访问开销”的场景，比如 27B、32B、70B 这档。

另外，显存带宽也很关键。如果显卡的显存带宽有限，目标模型一次处理多个 token 的开销比处理单个 token 高出不少，那投机解码的收益会被明显压缩。这也是为什么同样一套配置，在新旧两代显卡上跑出的加速比差别很大。后面实测部分我会给出具体数字，你就能直观感受到这个差异。

3. 环境搭建与草稿模型选型

理解了原理，下一步是动手。这一节讲工具选型、草稿模型怎么挑、启动参数怎么配。

3.1 推理工具选型：llama.cpp 为本地场景而生

本地单机跑 27B 量化模型，我优先推荐社区开源推理运行时 llama.cpp。它的优势在于：对 GGUF 量化支持成熟、显存管理灵活、CPU/GPU 混合加载稳定、投机解码功能持续在更新。相比之下，vLLM 更适合多卡服务器和并发服务场景，在显存充足的前提下性能更强，但它对显存的需求更苛刻，配置复杂度也高，单机本地体验它的性价比不高。

我这套环境的最终配置就是围绕 llama.cpp 展开的，直接编译带 GPU 加速的版本，后续所有参数调整都基于同一套二进制文件。如果你用的是预编译包，记得确认版本足够新，因为投机解码功能在旧版上的行为差异很大，稍有不慎就白折腾。

3.2 草稿模型怎么挑：词表一致是底线

投机解码对草稿模型最硬性的要求是词表一致。目标模型和草稿模型必须用同一个分词器，否则 token 的编号对不上，验证过程根本无从谈起。最省心的做法是选择与目标模型同系列的较小尺寸版本，它们共享词表和 tokenizer，接受率有天然优势。

我的选择路径是这样：先锁定两个候选，一个 3B，一个 1.1B，都是同系列版本。3B 模型的草稿质量高，但生成速度慢；1.1B 模型生成快，但预测分布更粗糙。实际测下来，1.1B 在当前硬件上的综合收益反而更好，原因在于“草稿速度 × 接受率”的综合乘积更高。这个结论不一定适用于你的环境，但可以作为排查思路参考。

草稿模型的量化格式也需要注意。我测试过 FP16 和 Q8_0，两者对接受率的影响不大，但 Q8_0 更省显存。如果你的显存已经快被目标模型吃满，草稿模型尽量选择低精度版本会稳妥一些。可能你会问，能不能让草稿模型跑在 CPU 上？可以，但跨设备传输延迟会抵消掉不少收益，不是首选。

3.3 启动命令与参数全解读

我最终落地的启动配置大概长这样，参数含义我会逐个拆解：

llama-cli \ -m models/qwen3.8-27b-q4_k_m.gguf \ -md models/qwen-draft-1.1b.gguf \ -t 8 \ -ngl 99 \ --temp 0 \ --top-k 40 \ --top-p 0.9 \ --min-p 0.1 \ --mlock \ --draft 8 \ -p "用一句话解释什么是缓存"

这里面的关键参数：

• -m：目标模型路径，27B 的 Q4_K_M 量化文件。
• -md：草稿模型路径，1.1B 的 Q8_0 量化文件。
• -t 8：线程数。我试过 4、8、16，最终 8 最稳。线程数开太多会带来调度开销，反而拖慢速度。
• -ngl 99：把模型层全部卸载到 GPU。这里 99 是个“全量卸载”的常用写法，不是真的只有 99 层。
• --temp 0：采样温度设为 0，也就是贪心解码。这是我试了多个温度后发现的“小窍门”，后面会单独讲。
• --draft 8：投机长度，也就是草稿模型一次生成的候选 token 数量。我最终固定在 8。
• --mlock：锁内存，把模型权重锁定在物理内存中，避免系统把它换到交换空间，对速度稳定性有帮助。
• --top-k 40、--top-p 0.9、--min-p 0.1：采样参数。需要特别注意的是，这些参数必须和目标模型、草稿模型保持一致，否则接受率会掉得很厉害。

有一个参数细节值得单独说：投机长度不是越大越好。理论上草稿生成 16 个候选，目标模型一次验证 16 个，看着很爽，但实际运行中，候选超过一定数量后，后续 token 的接受率会断崖式下降。因为草稿模型预测越往后越不靠谱，一旦中途被拒，后面的候选全部作废，这 16 个 token 的前向计算成本就全部沉没了。我实测下来，8 是当前环境下的甜点位，4 偏保守，12 和 16 的性能都不升反降。

4. 完整调优过程：从 14 到 159 的每一步

前面铺垫了那么多，这一节进入重头戏：从 14.2 tok/s 到 159 tok/s，我到底走了哪几步。这不是一次性就跳上去的，而是分阶段验证、逐步叠加优化项的结果。

4.1 阶段一：默认设置，只有 14

第一次启动时，我没有做任何调优，线程数直接拉满 16，没有锁内存，温度用的默认值 0.8，投机解码没开。测速结果 14.2 tok/s，确认了开头的判断。这个结果是后续所有对比的基线。

我一度怀疑是显存容量不够导致部分层被塞到内存里，但检查了 GPU 占用和模型层分布，确认 24GB 显存能完整装下 22GB 的目标模型。瓶颈确实在串行推理的显存带宽上。

4.2 阶段二：把该优化的基础项过一遍

这个阶段没有魔法，就是把系统层面的因素先清理干净：线程数从 16 降到 8，加上--mlock防止内存交换，采样参数统一设置，输出长度限制在合理范围。测速小幅提升到 16.8 tok/s，说明基础优化能带来约 18% 的改善，但距离质变还很远。

这个阶段也让我意识到，本地跑模型的速度问题不是由单一因素决定的，显存带宽、内存访问策略、线程调度、采样逻辑都会贡献微小影响。把它们都理顺之后，再去做推理方式的改造，才能看到真正的收益。

4.3 阶段三：投机解码一开，直接翻倍

在保持阶段二配置的基础上，加载 1.1B 草稿模型，--draft 8，其余参数不变。测速结果让我确定方向没走错：速度直接跳到 68 tok/s。从 16.8 到 68，单纯投机解码带来的增益就有四倍，这是本次调优中贡献最大的一步。

这时候我在终端里看输出，已经能明显感受到“批量吐字”的效果了。原来一个字一个字蹦，现在是一段一段蹦，体感差异非常强烈。68 tok/s 已经达到了可用标准，一个 500 字的回复只需要 8 秒左右。

不过，这个速度还不算稳定，波动幅度在 55~75 之间。我猜测是采样参数不一致导致的接受率抖动，于是进入下一轮调整。

4.4 阶段四：投机长度、采样参数、草稿模型大小的组合实验

这一阶段我做了三个维度的对照实验。

第一个维度是投机长度。我把--draft分别设为 4、8、12、16 进行测速，结果如下：

第二个维度是采样一致性。我把目标模型和草稿模型的采样参数统一之后，接受率明显上升，速度从 68 tok/s 提升到 82 tok/s。最意外的是把温度从 0.8 改成 0 之后，速度又跳了一截。原因是温度不为零时，草稿模型和目标模型的采样随机性都会增加，两者概率分布的一致性会变差；温度为零的贪心模式，更容易让草稿模型的 top-1 恰好就是目标模型的 top-1。

第三个维度是草稿模型大小。我把草稿模型从 1.1B 换成 3B，接受率提升到七成左右，但草稿生成速度慢了太多，最终整体速度反而掉到 51 tok/s。再把草稿模型换成 0.6B，草稿速度极快，但接受率只有三成，综合结果也只有 43 tok/s。1.1B 是当前环境下的最优解。

三个维度交叉验证后，我把速度稳定在了 82~95 区间。

4.5 最终配置与实测数据汇总

最后一轮，我做了三件事：把上下文窗口从 8K 降到 4K，降低内存占用和寻址开销；固定 seed 让测速过程更加稳定；调整电源管理策略，避免处理器在生成过程中自动降频。做完之后，短提示词、限制输出长度的场景下，测到了 159 tok/s 的峰值。

这不是日常状态。长文生成、复杂对话、较长上下文的场景下，速度稳定在 100~120 tok/s 是更真实的数据。为了让你看得更清晰，我把整个调优路径汇总成了一个表：

需要提醒的是，这组的数字是基于我这套硬件得到的，换个显卡或换套内存平台，比例会不同，但调优方向和相对收益是可以复用的。

5. 常见问题与排查心得

投机解码调优过程中，我遇到过的坑比预想的多，这里挑几个有代表性的问题分享出来，帮你省掉重复排查的时间。

5.1 开启投机解码后反而变慢

这是最多人踩的坑。如果你是 7B 以下的小模型，投机解码几乎一定不会带来收益，甚至可能变慢。原因在于目标模型本身生成一个 token 的成本已经很低，草稿模型的生成和验证开销反而占了大头。这种情况下，直接关掉--draft选项，回归串行推理就好了。

如果目标模型是 27B 以上，开启后反而变慢，优先检查草稿模型是不是和目标任务差距太大。比如说你拿一个通用小模型做草稿，目标模型是一个专攻代码的模型，接受率会低得可怕，草稿生成的全是“起笔就被否掉的废稿”。换同系列的草稿模型，这个问题基本能解决。

5.2 草稿模型加载失败与词表不匹配

加载草稿模型时提示词表不匹配，是最让人烦躁的错误。原因很简单：草稿模型和目标模型用的不是同一套分词器。不同系列的模型，即便 token 数量一样，内部映射规则也可能完全不同，强行加载必然失败。

解决办法只有一个：换词表一致的草稿模型。这就是为什么我前面强调优先选择同系列小模型，词表共享，开箱即用。如果你手里的模型是不同系列的，又实在找不到配套草稿，那这条路就别走了，直接优化硬件或者换更小的目标模型是更务实的选择。

还有一个容易忽略的情况：草稿模型偶尔能加载，但输出明显异常，比如一段话里疯狂重复某个 token。这种也是词表不匹配的隐性表现，不要怀疑采样参数，先换草稿。

5.3 显存不足时的取舍策略

当显存不足以同时容纳目标模型和草稿模型时，有几个方案可以权衡。第一，目标模型降低一档量化，比如从 Q4_K_M 降到 Q3_K_M，代价是生成质量会有可感知的下降。第二，草稿模型换成更低精度或更小的版本，牺牲部分接受率换显存空间。第三，把上下文窗口缩短，释放 KV cache 占用的显存，通常能腾出 1~2GB 的空间。

我个人倾向于优先压缩上下文长度，而不是动量化位宽，因为长上下文的收益在日常使用中不高，但模型质量的损失是实实在在的。

5.4 测速姿势不对，结果全是噪声

很多人反馈“为什么别人的 159，我的只有 70”，这里很大一部分原因是测速方法不统一。正确的测速姿势应该是这样：固定提示词、固定生成长度、固定 seed，同一个配置至少测三次取平均值。同时把首 token 延迟时间和后续生成速度分开统计，因为首 token 受上下文预填充影响很大，不能和稳定生成阶段混在一起算。

我自己的做法是写一段固定的测试提示词，限制输出 512 个 token，用相同的 seed 跑三遍，取中间值作为该配置的参考速度。只有用统一口径比较，调优方向才可信。千万不要看到某一次瞬时高点就当成最终成绩，那是自欺欺人，很容易误导后面的判断。

最后说一个我自己摸索出来的经验：投机解码就像换了个引擎，但引擎再好，车身这边漏风、那边抖动也是白搭。先把系统层面的干扰清干净，再上投机解码，这个顺序一定不能反。否则你开满特效去测一个本身就带病的状态，结果只会被一个离谱的低分误导，白白错过真正可能带来质变的技术。