从 14 tok/s 到 159 tok/s，这组数字不是换卡换出来的，也不是量化压出来的，而是同一台机器、同一个 27B 模型、同一份测试集上，通过投机解码调优得到的实测变化。最初看到这个结果我也很意外，毕竟自回归解码一直被显存带宽卡着，常规思路是换硬件或者降精度。可当我把草稿模型选型、采样对齐、投机长度这三件事逐个调顺之后，单卡吞吐确实是能翻着跟头往上涨的。这篇记录不打算复述文档，而是按我实际操作的顺序来写：先定位瓶颈在哪，再解释投机解码凭什么能提速，然后把每一步参数变化对应的速度变化写清楚，最后留下一份能直接照着排查的问题清单。适合正在本地跑大模型、对速度不满、又不想动模型权重的人参考。
1. 项目概述与需求解构
1.1 拆开标题，先看这场调优的对象
我手里这个模型，总参数量是 27B，但每个 token 推理时只激活约 3.8B 参数，属于典型的稀疏 MoE（混合专家）结构。这类模型的特点是：单卡能装下，但自回归生成时，权重读取仍然是全量进行，显存带宽消耗很大，而实际计算量又很小。带宽瓶颈在这种情况下会被放大得非常明显。
14 tok/s 的基线就是这么来的。模型加载完之后，单请求、连续生成 512 个 token，不做任何投机解码，平均每秒只能吐 14 个 token。对跑长文本任务的人来讲，这个速度不是不能跑，但基本谈不上“好用”。生成 500 个字要三十多秒，流式输出时能明显看到字符是一个一个蹦出来的，用户等待焦虑直接拉满。
这次调优的核心目标，不是追求一个漂亮的分数，而是让本地推理从“偶尔试一下”变成“日常能依赖”。判断标准也很简单：端到端生成速度能不能进入百 tok/s 区间，显存占用能不能继续控制在单卡范围内。
1.2 要解决的三个真实痛点
第一个痛点是单次生成耗时过长。我做本地批量改写和代码生成测试时，很多任务单次输出在 800 到 1000 个 token，按 14 tok/s 算，一条任务要一分多钟，连续跑二三十条基本没法下班。
第二个痛点是长上下文场景下的可用性。上下文一长，prefill 阶段也要占用时间，如果生成速度还低，整个任务耗时会被拉到一个难以接受的程度。
第三个痛点是调优方向太多，容易走弯路。量化、剪枝、换推理引擎、换显卡，每个方向看起来都能提速，但代价和风险不同。我最后选择投机解码，是因为它不改权重、不损失推理质量，只是改变生成方式。
1.3 为什么最终选了投机解码
在不动硬件的前提下，常见提速路径有四条：
- 量化：把权重从 BF16 压到 INT8 或 INT4，减少读取的数据量。但量化会引入精度损失，而且在权重刚好装进显存的前提下，继续压低精度对生成质量的伤害不一定值得。
- 剪枝或蒸馏：需要重新训练或微调，时间成本太高，不适合只想解决本地推理速度的人。
- 换推理引擎：有些引擎的算子优化确实更好，但提升幅度通常有限，很难带来数量级变化。
- 投机解码：用一个小模型先快速“打草稿”，再用大模型一次性验证多个候选 token。
我最终选了投机解码。它和量化和引擎优化都不冲突，甚至可以叠加。它解决的是自回归生成过程中“每生成一个 token 就要完整读一遍权重”的结构性浪费，这是换引擎和加 batch 都很难完全绕开的瓶颈。
| 方案 | 是否改权重 | 质量损失 | 实施成本 | 预期收益 |
|---|---|---|---|---|
| 量化 | 是 | 有 | 低 | 1.3~2 倍 |
| 剪枝/蒸馏 | 是 | 可能 | 高 | 1.5~3 倍 |
| 换推理引擎 | 否 | 无 | 低 | 10%~50% |
| 投机解码 | 否 | 无 | 中 | 视接受率而定 |
2. 投机解码原理以及为什么能换来十倍涨幅
2.1 自回归解码的瓶颈出在带宽上
先解释一个很多人忽略的事实：大模型生成 token 时，每一步都要从显存里把模型权重完整读一遍。对 27B 模型来说，这个读取动作花掉的时间，远大于真正做矩阵乘法的时间。GPU 在大部分时间里不是在“算”，而是在“等数据从显存搬到计算单元”。
我习惯用一个流水线例子来理解：一个工人每次只搬一个零件，大量时间花在往返仓库的路上，真正上手组装的时间很少。自回归解码就是这样，模型每走一步都要重新“过一遍仓库”，但只产出一个 token。
MoE 模型更夸张。因为激活参数少，单步计算量很低；但模型文件还是 27B 的量级，权重读取量并不会因为“只激活 3.8B”而变小。所以 MoE 在低并发自回归场景下，显存带宽瓶颈比传统 dense 模型更突出，14 tok/s 这种数字也就很常见了。
2.2 投机解码：小模型打草稿，大模型做审稿
投机解码的思路可以概括成八个字：小模型猜，大模型审。
详细流程是这样的：
- 草稿模型先自回归生成 K 个候选 token。这个模型很小，比如 0.5B，速度很快。
- 大模型把这 K 个候选 token 对应的位置一次性做前向计算，得到每一个位置的预测分布。
- 从第一个 token 开始逐个比对。如果草稿 token 落在大模型的采样范围内，就接受，继续看下一个；一旦遇到不被接受的 token，就停下来。
- 在第一个拒绝位置，用大模型自己的分布重新采样一个 token，替换草稿结果。
- 把这一段“连续被接受的草稿 token 加上替换 token”合起来作为本次输出，然后继续下一轮。
伪代码是这样的：
draft_tokens = draft_model.generate(gamma) target_logits = target_model.score(draft_tokens) accepted = 0 for i in range(gamma): if accept_probability(draft_tokens[i], target_logits[i]): accepted += 1 else: draft_tokens[i] = sample_from(target_logits[i]) break output.extend(draft_tokens[:accepted + 1])核心收益在于：大模型原本需要 K 次前向才能生成 K 个 token，现在只需要一次前向，就能完成验证。当然这不是白来的，草稿模型也要自回归生成 K 个 token，所以草稿模型必须足够快，否则省下来的时间会被草稿阶段重新吃掉。
2.3 三个决定收益的关键数值
投机解码的收益不只看模型，还受三个数值共同影响。
第一个是投机长度 gamma。也就是每次让草稿模型往前多想几个 token。gamma 越大，单次验证的收益上限越高。但草稿生成的序列越长，后面就越容易跑偏，接受率会衰减，无效计算变多。
第二个是接受率 p。也就是一个草稿 token 被大模型接受的概率。p 取决于草稿模型与大模型输出分布的匹配程度。
第三个是平均接受长度。这是最直接的观测指标。gamma=5 时，如果平均只能接受 1.2 个 token，那等于每次大模型前向只产出 2 个 token 左右，收益有限；如果能稳定接受 3 个以上，大模型前向次数就能降到原来的三分之一以下，速度提升会非常明显。
用简化公式估算：当草稿 token 独立且接受概率为 p 时，平均接受长度约为：
p * (1 - p^gamma) / (1 - p)p=0.7、gamma=5 时，平均接受长度大约 1.94；p=0.8、gamma=8 时，大约 3.33。这个公式能帮我们在调参前判断一个配置值不值得试，而不是盲目把 gamma 调大。
2.4 为什么能冲到 159 tok/s
159 tok/s 看起来像是从 14 翻了 11 倍，但拆开看并不玄学。这里有三个条件叠加：
草稿模型足够快。0.5B 级别的模型生成 8 个候选 token，耗时才几十毫秒，远小于目标模型一次前向的耗时。
接受率足够高。采样对齐之后，平均接受长度能到 5 以上，意味着目标模型每做一次前向，平均能产出接近 6 个 token。
MoE 模型放大了验证收益。大模型验证多个候选 token 时，权重的读取基本还是一次，增加的只是计算量，而 MoE 的激活参数很小，所以一次验证多个位置的计算开销比 dense 模型低很多。
所以 14 到 159 不是某个参数单独拉出来的效果，而是“小模型快、大模型验证便宜、接受率高”三者叠加的结果。
3. 实测过程与关键调优步骤
3.1 基线和测试口径先定好
调优之前，我先把测试口径固定下来。测试集包含代码生成、文本摘要、问答三类任务，一共 30 条，全部本地构造。每轮测试固定生成 512 token，温度 0.6，top_k 20，单用户、无并发，计时从生成第一个 token 开始，到生成结束。
基线结果：不开投机解码时，平均生成速度 14.2 tok/s。这个数字很稳定，连续跑三次差异不超过 0.3。
这个固定口径很重要。如果任务只生成几十个 token，prefill 阶段对整体耗时影响很大，投机解码的收益会被稀释。长时间生成测试才能看出稳定吞吐。
3.2 第一次开启投机解码：只到 58 tok/s
第一次配置，我选了一个 0.5B 的草稿模型。选它的原因很简单：同词表、体积小、单卡加载后显存占用不到 2GB。
命令大概长这样：
infer_engine --model target-27b \ --draft draft-0.5b \ --speculative-length 5 \ --temperature 0.6 \ --top-k 20跑完之后，平均速度是 58 tok/s，比基线好不少，但离目标还远。然后我去看引擎日志里的“average accepted tokens”，发现只有 1.8。也就是说草稿模型确实能猜中一部分，但过半候选被大模型拒绝了，收益被白白浪费。
3.3 采样对齐：从 58 到 120 的关键一步
投机解码里最容易被忽视的问题，是草稿模型和目标模型的采样参数不一致。
我当时的目标模型用的是 temperature=0.6 加 top_k=20。但草稿模型可能还在用默认的 temperature=0.0，也就是每次只选最高概率 token。这种情况下，草稿模型走的是贪婪路径，目标模型却按随机分布验证，两边思路完全不一样，接受率自然低。
我把草稿模型的 temperature、top_k 全部改成和目标模型一致，同时把随机种子固定到同一组，重新跑了一遍。平均接受长度从 1.8 跳到了 3.1，生成速度直接拉到 121 tok/s。
这是整轮调优里收益最大的一次改动，但它不换模型、不做量化，只是改了配置。很多投机解码跑不出效果的项目，问题往往出在这一步，而不是草稿模型能力不行。
3.4 投机长度和缓存优化：冲刺 159 tok/s
采样对齐之后，我开始调 gamma。从 5 加到 6、7、8，吞吐一直在小幅上升；加到 9 的时候开始回落。原因是草稿模型生成较长序列时，后面的 token 接受率衰减明显，验证收益盖不过草稿模型的额外开销。
最后我停在 gamma=8，又做了两个小改动：
第一个是打开前缀缓存。同一个用户的多轮对话里，前面已经算过的系统提示词和上下文不用每次都重新 prefill，能省下不少重复计算。
第二个是把草稿模型的 KV cache 预留长度改成和生成长度一致。如果不改，草稿模型在长生成过程中会反复扩展缓存，带来额外的显存申请和重算开销。
最终配置是：0.5B 草稿模型、gamma=8、采样参数对齐、温度 0.6、开前缀缓存。稳定跑出来的结果是 159.3 tok/s，目标模型平均单次前向产出约 5.9 个 token，显存占用从 16.2GB 升到 18.4GB。
| 调优阶段 | 主要改动 | 平均接受长度 | 实测 tok/s |
|---|---|---|---|
| 基线 | 无投机解码 | 无 | 14 |
| 阶段一 | 开启默认 gamma=5 | 1.8 | 58 |
| 阶段二 | 草稿与目标采样对齐 | 3.1 | 121 |
| 阶段三 | gamma=8 + 前缀缓存 | 5.3 | 159 |
3.5 为什么最后没有继续加大 gamma
投机长度并不是越大越好。从公式就能看出来，接受率 p 固定时，平均接受长度会随着 gamma 增大而趋近于某个极限。比如 p=0.8 时，gamma 从 4 加到 8，平均接受长度从约 2.36 涨到 3.33；而 gamma 继续加到 16，也只能涨到 3.99 左右。
换句话说，投机长度加得越往后，每一单位新增候选带来的收益越低，但草稿模型的耗时和显存压力是线性增长的。继续加大 gamma 只是在为越来越小的收益买单。
所以判断最优 gamma 不能靠拍脑袋，要看同一组实测数据里“平均接受长度”和“草稿耗时”的变化趋势。当草稿耗时增速开始超过接受长度增速，就该把 gamma 往回缩一点。
4. 常见问题与排查技巧实录
4.1 开启投机解码后反而更慢
这是我被问得最多的情况。明明开了投机解码，速度反而比不开还低。通常有以下几种原因：
草稿模型太大。如果草稿模型生成 K 个候选 token 的耗时，已经超过目标模型验证节省下来的时间，那整个流程就是负收益。
采样参数不一致。草稿模型和目标模型一个 greedy、一个随机，接受率会掉到非常难看的水平，目标模型前向次数省不下来。
显存接近上限。草稿模型叠加之后，如果显存开始溢出，模型权重会在显存和内存之间反复换入换出，性能直接断崖下跌。
排查顺序建议是：先看日志里草稿模型的单步耗时，再看平均接受长度，最后看显存剩余。不要一上来就怀疑 gamma 不够大。
4.2 接受率上不去的三个常见原因
如果打开日志发现平均接受长度只有 1.1 或 1.2，问题集中在三处：
- 词表不一致。草稿模型和主模型如果不是同一个分词体系，候选 token 天然就很难被接受。最稳妥的办法是选同系列、同词表的小模型。
- 采样参数不一致。temperature、top_k、top_p 任何一个不一样，都会让草稿和目标模型的输出分布产生错位。
- 草稿模型能力太弱。小模型确实快，但如果训练领域和主模型差异太大，猜中率会极低。这种情况不是调参能解决的，需要换一个稍大、但训练任务更接近的草稿模型。
4.3 投机解码与量化、并发怎么搭配
投机解码和量化是可以叠加的。目标模型量化后，权重读取量变小，投机解码依然能继续省前向次数。但草稿模型我建议保持原精度，因为草稿模型本身很小，量化省下的显存微不足道，却可能降低接受率，得不偿失。
并发场景要特别注意。当 batch size 变大时，目标模型一次前向本来就在处理多个请求，前向次数利用率已经比较高，投机解码带来的额外收益会被摊薄。所以如果场景是多人同时用，优先调并发和缓存复用；如果场景是单路流式对话，投机解码的收益最大。
4.4 我的几条避坑经验
调参时一定要同时记录三组数字：目标模型前向次数、草稿模型前向次数、平均接受长度。只看最终 tok/s，你不知道是哪一环节在拖后腿。
测试长度不要设太短。生成 50 个 token 的任务，prefill 时间占比很大，投机解码的优势很难体现。建议至少生成 512 token 再算平均速度。
对比实验不要只用同一个随机种子。固定种子会让结果高度可复现，但也容易掩盖随机波动。我习惯用三组不同种子各跑一遍，取平均值。
草稿模型的选择要综合看词表、参数量和训练域。有时候 0.1B 的草稿模型比 0.5B 的好用，因为它足够快，即使接受率稍低，整体时间账也算得过来。
最后说一点个人体会。从 14 到 159，最值钱的不是最后的数字，而是过程中建立起来的三个习惯：先定位瓶颈再动手、用接受率和前向次数量化每一步收益、调参时始终保留一份可复现的基线。投机解码确实像是一次“白捡”的加速，但它依赖的草稿模型和采样对齐也需要花时间调。如果你正被单卡推理速度卡住，先别急着换卡或者削精度，花一个下午把投机解码跑通，大概率能省下这笔换硬件的钱。
