投机解码调优实战：本地大模型推理从14 tok/s飙升到159 tok/s

本地跑大模型，我最烦的就是输出像挤牙膏。前段时间把 Qwen3.8-27B 拉到本地，默认配置下速度只有 14 tok/s，生成一段几百字的回答能等半分钟，根本没法当工具用。后来花了一个晚上做投机解码调优，把同一块显卡上的单流推理速度干到了 159 tok/s。这篇文章不聊跑分软件的虚头，直接记录我实际调了什么、每个参数为什么这么调、以及中间踩过的坑。适合正在本地折腾大模型推理，或者做 Agent 应用觉得响应太慢的人。

1. 先把项目目标讲清楚：不是跑通，是跑快

1.1 这次调优的对象和硬件环境

我本地跑的是 Qwen3.8-27B，一个 27B 参数级别的对话模型。部署环境是一台普通工作站：单机单卡，24GB 显存的中高端显卡，外加 32GB 内存。这个配置卡得很微妙：模型如果用 fp16 全量加载，光权重就接近 54GB，单卡根本放不下。所以我一开始用 4bit 量化加载，权重压到 13GB 左右，剩下一点显存给 KV cache 和运行时占用。默认配置下跑起来只有 14 tok/s，基本上属于“能出声但没法用”的状态。

很多人在本地部署时只看“模型能不能加载进显存”，忽略了真正影响体验的是生成速度。14 tok/s 意味着一个 300 字的中文回答（大概 450 个 token）需要 32 秒才能吐完。这个延迟放在交互式对话里，用户早就失去耐心了。放在 Agent 链路上更致命，因为一个任务可能要连续调用模型三四次，32 秒乘以多轮调用，整个流程直接卡到无法接受。所以这次项目的目标很明确：不是把模型跑通，而是把它跑到“可用”的水平。

1.2 tok/s 这个指标为什么是本地推理的分水岭

token 每秒（tok/s）是衡量文本生成速度最直接的指标。不同场景对速度的要求差别很大。我自己的体感是：低于 20 tok/s，互动感基本为零，更像在等一个慢任务；达到 50 tok/s，对话才有一点实时感，能连续追问；超过 100 tok/s，日常使用已经非常跟手。

159 tok/s 是什么概念？一个 300 字的中文回答大约 450 个 token，在 159 tok/s 下只需要 2.8 秒左右。对比原来的 14 tok/s，同样一段输出从 32 秒缩短到 2.8 秒，这个差距对实际体验是质变。尤其是做流式输出时，用户看到第一个字的时间也会大幅提前，因为这些优化让每次前向计算都能产出更多 token，而不是等一个 token 才走一次模型。

还有一个容易被忽略的点：tok/s 并不是一个固定值，它会受到并发数、上下文长度、量化方式、采样温度等因素影响。所以调优时一定要固定测量条件，否则数据对比没有意义。我这次统一用单请求、输出长度控制在 128 token 左右、连续跑 20 次取平均，确保每一步对比是在同一把尺子下进行的。

2. 14 tok/s 的瓶颈到底在哪

2.1 自回归生成的基础逻辑

大模型生成文本的底层机制是自回归。所谓自回归，就是模型一次只能预测一个 token，预测完这个 token 之后，把它拼到输入序列末尾，再预测下一个 token。这个过程串行进行，每一步都依赖前一步的结果，没法并行。

这个特性决定了推理速度和显存带宽强相关。你可以把模型想象成一本巨型词典，每生成一个词，都要把整本词典从头到尾翻一遍，从中找出当前上下文下最可能的下一个词。翻词典这个动作是大模型的前向计算，它必须读取全部权重，无论当前输入多短。也就是说，生成一个 100 token 的回答，模型要完整“翻词典”100 次。自回归结构决定了串行次数等于输出长度，这就是速度的硬天花板之一。

2.2 显存带宽才是主要约束

很多人以为大模型推理慢是因为 GPU 算力不够，实际上很多场景卡在显存带宽而不是浮点算力。每生成一个 token，模型都要把全部权重从显存搬到计算单元，这个搬运过程非常耗时。

用数字来感受一下：27B 模型在 4bit 量化后约 13GB，每次前向计算至少要把 13GB 权重读一遍。主流消费级显卡的显存带宽如果按 1TB/s 估，理论上读出 13GB 需要约 13ms，对应上限也就 76 tok/s。但这只是理想带宽，实际还有激活值搬运、KV cache 读取、kernel 启动开销、内存碎片等因素，所以默认配置跑出 14 tok/s 一点也不奇怪，说明优化空间非常大。

这里有一个重要结论：只要能减少“翻词典”的次数，就能直接提升生成速度。量化能把单次前向的权重体积降下来，但治标不治本；投机解码则是让一次翻词典能拿到多个 token，相当于从根上改变了串行次数。

2.3 量化只是降本，不解决串行问题

我在调优初期先试了几个常规手段。4bit 量化本来就是为了能加载模型，继续压到 3bit 或 2bit 虽然显存占用降低，但速度提升有限，而且质量损失明显。图模式编译带来的收益也不大，因为瓶颈在权重搬运而不是 kernel 计算。接着我试了增大批处理（batch size），把多个请求打包在一起可以摊薄权重搬运成本，吞吐量确实上去了，但单个请求的延迟还是没改善。

这一步让我意识到：如果还是要一个 token 一个 token 地生成，再怎么优化权重读取，都很难突破几倍的天花板。我需要的是改变生成模式本身，而不是在自回归串行链路上修修补补。这时候才把目光转向投机解码。

3. 从默认配置到 159 tok/s：完整调优步骤

3.1 第一步：换用支持投机解码的推理服务

原来的本地推理脚本是模型仓库自带的，功能简单，不支持投机解码。我没自己造轮子，而是换了一个开源推理服务框架，用 Docker 起了一个本地服务。选择这个框架的唯一标准是它把投机解码做成了开箱即用的配置项，不用自己改 CUDA kernel。

先贴一份我当时用的服务端配置概要，注意引擎名字我已经做了脱敏处理，关键是参数结构：

{ "engine": "local-inference-server", "model": "/models/qwen3.8-27b", "draft_model": "/models/qwen3.8-1b-draft", "quantization": "4bit", "speculative_decoding": { "enabled": true, "num_speculative_tokens": 5, "temperature": 0.3 } }

启动之后先不要急着测速度，而是确认模型正常加载、日志里出现“speculative decoding enabled”这类输出。我第一版配置直接套默认值，草稿长度 5，温度保持原来的 0.7，结果只从 14 tok/s 到了 41 tok/s，提升有但不够亮眼。这为后面的参数调整埋下了伏笔。

3.2 第二步：选一个合适的草稿模型

投机解码的核心是一个小模型先“打草稿”，大模型再做校验。这个小模型叫草稿模型（draft model）。它不需要很强，但必须满足两个硬性条件：词表和目标模型完全一致；参数量足够小，生成候选 token 的速度足够快。

我一开始用的是一套 0.5B 级小模型，速度很快，但接受率很低，经常被大模型拒绝，导致大量候选 token 变成无效计算。后来换成一个 1B 级别的小模型，词表和 Qwen3.8-27B 完全对齐，接受率明显提升。这里有一个反直觉的结论：草稿模型不是越小越好。太小了猜不准，校验时被连续拒绝，浪费目标模型的前向机会；稍微大一点，接受率提升带来的收益可以覆盖草稿模型多出来的耗时。

选草稿模型时还要注意它是否在相似的语料上训练过。如果目标模型擅长代码，草稿模型却只学过通用文本，那么遇到代码类请求时，草稿模型的预测命中率会大幅下降。我建议根据你的实际使用场景多备几个候选草稿模型，逐个测接受率，而不是只盯着参数大小。

3.3 第三步：核心参数逐项调优

投机解码有三个关键参数：草稿长度、温度、采样参数一致性。逐个说。

草稿长度（num_speculative_tokens）控制小模型一次生成多少个候选 token，目标模型一次前向最多可以校验 N+1 个 token。N 越大，理论加速上限越高，但小模型生成候选串的时间和目标模型的显存开销也会增加。我从 N=5 开始，逐步试到 8，最终停在 7。N=8 时接受率开始下滑，实际吞吐不升反降。

温度对投机解码的影响经常被忽略。投机解码的本质是用草稿模型的概率分布去匹配目标模型的采样分布。如果目标模型使用较高的 temperature，采样时随机性大，草稿模型很难猜中；如果改成较低的 temperature，预测更接近 greedy，接受率会明显上升。我将 temperature 从 0.7 降到 0.3，接受率从 55% 升到 75%，这是一个非常显著的变化。

还有一个容易被忽略的点：开投机解码后，草稿模型和目标模型的采样参数必须完全一致。top_p、top_k、temperature 任何一个不匹配，都会导致候选 token 的接受逻辑错乱。最典型的错误是只设了主模型的 temperature，忘了把草稿模型的采样参数同步过去，结果输出质量波动很大。

下面是我实测过程中记录的几组关键数据：

这里要说明一下：159 tok/s 不是单独一个开关能做到的，而是投机解码配合了量化、图模式、连续批处理和 KV cache 复用一起达到的结果。但投机解码是让速度发生质变的核心杠杆，没有它，其他优化堆上去也很难突破 50。

3.4 第四步：验证输出一致性

调优不能只看速度，还要确认输出质量没有劣化。我在每一步参数调整后，用同样一组 20 个 prompt 跑一遍，对比开启投机解码前后的输出。在 greedy 解码下，投机解码理论上应该与自回归完全一致；在采样模式下，允许有小幅差异，但不能出现乱码、重复和逻辑断裂。

如果你发现输出质量明显变差，优先检查三件事：草稿模型的词表是否和目标模型完全一致；草稿模型和目标模型的采样参数是否一致；草稿长度是否过大导致接受率太低。大多数不一致问题都出在前两个原因，而不是投机解码算法本身。

4. 投机解码的原理：为什么一次前向能吐多个 token

4.1 期望收益的数学计算

投机解码的加速逻辑其实可以用一个简单的数学模型解释。假设草稿模型单个 token 的接受率是 p，投机长度是 K，那么目标模型每做一次前向，能够一次性确定下来的 token 数量期望是：

E = (1 - p^(K+1)) / (1 - p)

这个公式的意思是：最多可以验证 K+1 个 token，但中途可能遇到第一个被拒绝的 token 就停下来。如果 p=0.75，K=5，代入计算：E = (1 - 0.75^6) / 0.25 ≈ (1 - 0.178) / 0.25 ≈ 3.29。也就是说，目标模型每做一次前向，平均能确定 3.29 个 token，相比自回归每次前向只确定 1 个 token，理论加速约 3.3 倍。

如果把 p 提高到 0.8，K 还是 5，期望值变成 (1 - 0.8^6) / 0.2 ≈ (1 - 0.262) / 0.2 ≈ 3.69，加速提升到 3.7 倍。如果再把 K 加到 7，p=0.75，E = (1 - 0.75^8) / 0.25 ≈ 3.9 倍。这就是为什么接受率和草稿长度是投机解码的两个主要杠杆。

4.2 为什么不能无限加大草稿长度

从公式看，K 越大，期望 E 的极限越接近 1/(1-p)，似乎可以一直提升。但实际中 K 不可能无限增大，原因有三点。第一，草稿模型生成 K 个候选 token 本身需要时间，K 越大，草稿阶段耗时线性增长。第二，目标模型一次验证 K+1 个 token，显存占用和计算量也随之增加，尤其是 KV cache 的开销。第三，随着验证序列变长，后面位置的 token 接受率会逐渐下降，因为草稿模型只能基于早期生成的候选继续扩展，误差会累积。

我在测试中就发现，K 从 5 调到 8 时，接受率从 75% 掉到 61%，虽然理论上限更高，但实际吞吐反而下降了。最终停在 K=7，是在当前硬件和草稿模型组合下的甜点区。换一个更强的草稿模型，甜点区可能会后移。

4.3 从 14 到 159 不全是投机解码的功劳

这里需要说句公道话：159/14 大约是 11 倍，已经超出了投机解码单独能达到的理论上限。所以实际调优中，必然是投机解码和基础优化叠加的结果。我自己的调优路径是先通过量化和图优化把基础速度从 14 提到 30 左右，再开启投机解码跳到 80+，最后用连续批处理和 KV cache 复用逼近 159。投机解码是最大的跳变来源，但其他优化是把地板抬高的必要条件。

这也提醒大家：如果你想复现类似的提速，不要只改投机解码的开关，还要把你推理服务里已有的优化项全部打开，比如连续批处理、前缀缓存、算子融合。这些优化和投机解码是互补关系，而不是替代关系。

5. 常见问题与排查速查表

5.1 开了投机解码反而变慢

这是最常遇到的问题。我排查时的第一反应是看日志里的“接受率”和“草稿耗时”。如果接受率低于 50%，说明草稿模型猜不中，目标模型很多前向等于白做。如果草稿耗时接近目标模型单次前向耗时，说明草稿模型太大或 K 太大。

解决办法很简单：换更小但词表一致的草稿模型，或者降低 K。我遇到过一种情况：同一个草稿模型在不同温度下接受率差异巨大。温度 0.2 时接受率接近 80%，温度 0.8 时直接掉到 35%。如果你必须用高温度做创意生成，投机解码的收益会大幅缩水，这时不如关掉投机解码。

5.2 输出结果变差或出现乱码

投机解码本身不应该改变模型的知识能力和表达水平，如果输出质量明显劣化，先查词表对齐。草稿模型和目标模型的 tokenizer 必须完全一致，否则候选 token 的 id 对不上，像拿着另一套字典做校对，肯定全部错位。

另一个原因是采样参数不一致。我见过有人设置主模型 temperature=0.7，但草稿模型使用默认参数 0.0，两个分布完全不同，造成大量拒绝和乱码。正确做法是把草稿模型的采样参数和主模型完全同步。还有一个容易忽略的点：如果你使用 top_p 采样，草稿模型的 top_p 也要保持一致。

5.3 显存不足

投机解码会额外加载一个草稿模型，还要为目标模型的批量验证分配更大的临时显存。如果原本就快爆显存，开投机解码可能直接 OOM。我的做法是先把草稿模型做 8bit 量化，显存占用降低一半以上，接受率下降不多。如果还紧张，就把 K 调小一点，并关闭连续批处理来降低峰值显存。

另外推荐开启 KV cache 复用。这个功能可以在多轮对话和并行请求中共享重复前缀的 KV cache，减少显存浪费。开了之后，我从 112 到 159 的调优过程中没有因为显存不足掉过链子。

5.4 接受率上不去

接受率是投机解码的核心健康指标。日志里如果长期低于 60%，那说明草稿模型和你的实际数据分布不匹配。我遇到过一种典型场景：Qwen3.8-27B 在代码问答上很强，但我选的草稿模型是通用文本模型，代码场景接受率只有 40%。后来换了一个在代码数据上微调过的小模型，接受率直接跳到 80%。

还有一个不常被提到的点：模型量化程度过高也会降低接受率。目标模型和草稿模型的概率分布差异会随着量化程度增大，所以如果接受率一直低，可以尝试把草稿模型保持 fp16，只量化主模型，或者反过来。两者都用极低比特量化时，接受率通常不会太好看。

6. 最后再分享几个实操心得

6.1 先白盒确认，再谈调参

调投机解码最忌讳盲调。我建议你把推理服务的日志级别调低，开启每轮请求的统计信息，至少看清接受率、草稿模型耗时、目标模型验证耗时这三项。没有这些数据，你根本不知道瓶颈是在草稿生成、验证阶段还是采样参数。我大部分问题都是通过日志定位到的，而不是靠猜。

6.2 不要盲目追求极端数字

159 tok/s 是有测试条件的：单请求、输出长度限制、低温度、开启动态优化。如果你换成复杂指令、长上下文、高并发或者高 temperature，速度会明显回落。我建议根据自己的真实场景固定一个 benchmark，比如“1000 token 上下文，输出 200 token，并发 1”，在这个条件下做对比调优，得到的数据才有参考价值。

6.3 给后续扩展留个口子

这次调优只是第一步。如果你想让速度再往上走，可以考虑两个方向：一是训练一个与业务场景高度匹配的专用草稿模型，接受率可能提升到 80% 以上；二是把草稿模型和主模型拆分到两张显卡上，让草稿生成和主体验证流水线并行，草稿耗时就能被藏起来。这两种方案我还没有完整落地，但原理上是确定可行的。

我的整体体会是，本地推理速度优化里，投机解码是性价比最高的杠杆之一，但绝不是只改一个参数就完事。先把采样参数和草稿模型调对，再逐步加大草稿长度，最后配合基础优化，才能在稳定性和速度之间找到平衡。希望这份记录能让你少走几个弯路。