从 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 取决于草稿模型与大模型输出分布的匹配程度。第三个是平均接受长度。这是最直接的观测指标。gamma5 时如果平均只能接受 1.2 个 token那等于每次大模型前向只产出 2 个 token 左右收益有限如果能稳定接受 3 个以上大模型前向次数就能降到原来的三分之一以下速度提升会非常明显。用简化公式估算当草稿 token 独立且接受概率为 p 时平均接受长度约为p * (1 - p^gamma) / (1 - p)p0.7、gamma5 时平均接受长度大约 1.94p0.8、gamma8 时大约 3.33。这个公式能帮我们在调参前判断一个配置值不值得试而不是盲目把 gamma 调大。2.4 为什么能冲到 159 tok/s159 tok/s 看起来像是从 14 翻了 11 倍但拆开看并不玄学。这里有三个条件叠加草稿模型足够快。0.5B 级别的模型生成 8 个候选 token耗时才几十毫秒远小于目标模型一次前向的耗时。接受率足够高。采样对齐之后平均接受长度能到 5 以上意味着目标模型每做一次前向平均能产出接近 6 个 token。MoE 模型放大了验证收益。大模型验证多个候选 token 时权重的读取基本还是一次增加的只是计算量而 MoE 的激活参数很小所以一次验证多个位置的计算开销比 dense 模型低很多。所以 14 到 159 不是某个参数单独拉出来的效果而是“小模型快、大模型验证便宜、接受率高”三者叠加的结果。3. 实测过程与关键调优步骤3.1 基线和测试口径先定好调优之前我先把测试口径固定下来。测试集包含代码生成、文本摘要、问答三类任务一共 30 条全部本地构造。每轮测试固定生成 512 token温度 0.6top_k 20单用户、无并发计时从生成第一个 token 开始到生成结束。基线结果不开投机解码时平均生成速度 14.2 tok/s。这个数字很稳定连续跑三次差异不超过 0.3。这个固定口径很重要。如果任务只生成几十个 tokenprefill 阶段对整体耗时影响很大投机解码的收益会被稀释。长时间生成测试才能看出稳定吞吐。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 的关键一步投机解码里最容易被忽视的问题是草稿模型和目标模型的采样参数不一致。我当时的目标模型用的是 temperature0.6 加 top_k20。但草稿模型可能还在用默认的 temperature0.0也就是每次只选最高概率 token。这种情况下草稿模型走的是贪婪路径目标模型却按随机分布验证两边思路完全不一样接受率自然低。我把草稿模型的 temperature、top_k 全部改成和目标模型一致同时把随机种子固定到同一组重新跑了一遍。平均接受长度从 1.8 跳到了 3.1生成速度直接拉到 121 tok/s。这是整轮调优里收益最大的一次改动但它不换模型、不做量化只是改了配置。很多投机解码跑不出效果的项目问题往往出在这一步而不是草稿模型能力不行。3.4 投机长度和缓存优化冲刺 159 tok/s采样对齐之后我开始调 gamma。从 5 加到 6、7、8吞吐一直在小幅上升加到 9 的时候开始回落。原因是草稿模型生成较长序列时后面的 token 接受率衰减明显验证收益盖不过草稿模型的额外开销。最后我停在 gamma8又做了两个小改动第一个是打开前缀缓存。同一个用户的多轮对话里前面已经算过的系统提示词和上下文不用每次都重新 prefill能省下不少重复计算。第二个是把草稿模型的 KV cache 预留长度改成和生成长度一致。如果不改草稿模型在长生成过程中会反复扩展缓存带来额外的显存申请和重算开销。最终配置是0.5B 草稿模型、gamma8、采样参数对齐、温度 0.6、开前缀缓存。稳定跑出来的结果是 159.3 tok/s目标模型平均单次前向产出约 5.9 个 token显存占用从 16.2GB 升到 18.4GB。调优阶段主要改动平均接受长度实测 tok/s基线无投机解码无14阶段一开启默认 gamma51.858阶段二草稿与目标采样对齐3.1121阶段三gamma8 前缀缓存5.31593.5 为什么最后没有继续加大 gamma投机长度并不是越大越好。从公式就能看出来接受率 p 固定时平均接受长度会随着 gamma 增大而趋近于某个极限。比如 p0.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最值钱的不是最后的数字而是过程中建立起来的三个习惯先定位瓶颈再动手、用接受率和前向次数量化每一步收益、调参时始终保留一份可复现的基线。投机解码确实像是一次“白捡”的加速但它依赖的草稿模型和采样对齐也需要花时间调。如果你正被单卡推理速度卡住先别急着换卡或者削精度花一个下午把投机解码跑通大概率能省下这笔换硬件的钱。