1. 为什么非要在本地跑27B从“一句话等半天”说起拿到 Qwen3.8-27B 的权重时我第一反应是“终于有个能在消费级显卡上跑的大模型了”。结果部署完兴冲冲地敲了个问题进去屏幕上的光标闪了快十秒才开始一个字符一个字符地往外吐。盯着那个每秒十几个 token 的速率我一度怀疑自己是不是把模型下错了档位。14 tok/s 是什么概念一句话大约 30 个字加上标点和停顿差不多 50 个 token。也就是说我输入一句完整的问题要等接近 4 秒才能看到第一个词开始出现再花 3 秒才能把一句话读完。聊天还好稍微长一点的代码生成等三十秒是常态。到了 64K 上下文的长文档总结那体验基本是灾难级别——我泡好咖啡回来它还在吭哧吭哧地写中间段落。后来我把目标锁定在投机解码上花了两个晚上把草稿模型、草稿长度、采样对齐这些参数一个个抠过去同一台机器、同一个主模型速度直接从 14 tok/s 拉到 159 tok/s。注意这不是换了显卡也不是换了框架就是调整推理策略和参数组合的结果。这篇文章我把整个调优过程、中间踩过的坑、每一步为什么这么做全部写出来给同样在本地跑 27B 模型的同行一条可以照抄的路径。为什么要折腾本地而不是直接用云端的 API两条原因。第一输入输出里全是带业务性质的代码和文档丢到远程接口总有顾虑本地跑数据不出机器这一点对我很重要。第二持续调用收费模型跑实验一个月累计下来的费用足够给显卡还分期了。所以本地推理是我绕不开的路而速度就是这条路最大的拦路虎。适合读这篇东西的人有两类一类是手里有 24GB 左右显存的卡正在被 27B 级别模型的生成速度折磨另一类是听说过投机解码但不太清楚它到底能带来多少收益想看看真实数据再决定要不要花时间折腾。我保证不堆理论名词所有结论都有实测数据支撑。2. 投机解码不是魔法是“小模型打草稿大模型来把关”很多人一听“投机解码”四个字第一反应是“这不就是个近似加速吗牺牲质量换速度”。实际恰恰相反它不改变最终输出分布质量损失几乎可以忽略。它的核心思路简单到一句话就能说清用一个很小的模型快速写一版草稿然后用 27B 的大模型一次前向同时校验一大串草稿能用的留下不能用的当场改掉。2.1 一次前向计算原来可以做这么多事常规解码是串行的模型生成第 1 个 token然后拿这个 token 作为输入生成第 2 个每一步都要跑一次完整的 27B 前向计算。你拿到的每一个字背后都是一次全模型计算。这个流程逻辑上没错但效率上极其浪费——每一步只有最后一个位置的输出被用到前面那些位置的计算全部作废。投机解码的聪明之处在于让计算变成“批量验收”。小模型先生成 k 个候选 token比如 16 个。大模型拿到这串候选把它们和之前的上下文拼起来一次性跑前向一次性给 16 个位置上每个位置的预测结果。然后逐一比对草稿的第 1 个 token 和大模型预测的第 1 个位置是否一致如果一致继续看第 2 个如果不一致说明草稿在这里写错了立刻停下来用大模型自己预测的 token 替换。小模型一次前向的成本可能只有大模型的 2%大模型跑一次前向却能“批发”出十几个合法 token。这就是投机解码能把速度推高数倍的根本逻辑。2.2 接受率整个投机解码的胜负手投机解码加速效果的命门是一个叫“接受率”的指标。它表示草稿模型生成的 token 被大模型认可的比例。如果草稿 16 个 token大模型全部接受那么一次前向直接产出 17 个 token实际生成速度可以达到无投机模式的好几倍。如果草稿质量很差大模型只接受了 3 个就被打回那么虽然也省了几次前向但草稿模型的耗时反而成了负担。我实测下来接受率和两个东西强相关草稿模型和目标模型的“默契程度”以及采样参数的偏离程度。默契程度取决于模型代数是否接近、训练分布是否相似这个在选草稿模型时要重点看。采样参数则完全可控——草稿采样和大模型采样如果各用一套温度和 top-p那么草稿写的方向和正主想要的方向不一致接受率会断崖式下跌。所以数据上的最优做法不是把草稿模型调得“更聪明”而是让它的采样风格和主模型尽量一致。可能有读者会问如果草稿全错岂不是要退回普通解码是的。这也是为什么投机解码不是所有场景都适用长文本和代码生成的收益差异很大。我后面会在第 5 节单独讲什么时候它反而会让速度变慢。2.3 硬件底座投机解码吃带宽不吃算力关于投机解码有个反直觉的结论它之所以能加速不是减少了大模型的计算量而是把“串行计算”变成了“并行计算”让显存带宽的利用率大幅提高。大模型一次前向计算 17 个位置的 logits和计算 1 个位置相比计算量确实增加了不少但内存带宽的消耗几乎是一样的——权重只需要从显存读一遍位置上的差异主要体现在矩阵形状上。所以投机解码最受益的硬件是显存带宽充裕的消费级显卡。算力弱一点没关系只要带宽够批量验证 17 个位置就能摊薄权重读取的成本。反过来如果你的显卡本身算力很强但显存带宽一般投机解码的收益会相对小一些因为计算瓶颈会先碰到天花板。3. 初始 14 tok/s 的真实瓶颈量化档位、内存搬运与带宽浪费进入调优之前我先交代一下当时的环境单卡 24GB 显存CPU 是主流多核内存 64GB。软件栈用的是一个支持投机解码的主流推理服务框架配合前端接入。这个配置在社区用户里很常见没有什么特殊之处。3.1 第一版部署Q8 量化加 CPU offload 的自我感动第一次部署 Qwen3.8-27B我图省事直接用了 Q8 量化。Q8 下 27B 权重大约 27GB比 24GB 显存多了 3GB。当时我想得很简单多出来的部分塞进 CPU 内存用的时候再搬过去反正 KV cache 一开始也不大。结果就是那 14 tok/s。后来分析才明白这 14 tok/s 里有 70% 的时间花在等数据从内存搬到显存。大模型解码每一步都要把当前需要的权重从内存往显存搬Q8 量化之后每次前向要搬运 27GB 的权重数据。PCIe 的带宽相比显存带宽完全不是一个量级每生成一个 token就有 3GB 以上的数据在背后疯狂排队。这不是生成慢是搬运慢。这里有个经验教训本地跑 27B 级别模型量化档位的选择第一优先级不是“质量多高”而是“能不能完全塞进显存”。塞不进显存的一切方案速度都没法看。如果你的显卡显存刚好比模型权重小一点宁可把量化档位从 Q8 降到 INT4也不要图那一点质量损失去搞 CPU offload。3.2 基线测试怎么测才靠谱很多人测推理速度犯一个错误打开聊天界面随便问一句然后看输出 token 数除以时间得出一个“速度”。这个数字波动极大因为首次生成阶段提示词处理需要时间中间又受到上下文长度影响。我这次所有对比数据都是在一个标准测试任务上测的固定 512 token 的英文技术文档作为前缀然后让它续写 100 个 token每轮测 3 次取中位数。这样测出来的数字才代表“稳态生成速度”而不是首 token 延迟或者某个瞬间峰值。同时我强烈建议在每次改完参数后清空缓存再测一轮。因为投机解码命中后 KV cache 的复用情况会显著影响速度如果上一次测试留下来的 KV cache 还在下一轮会虚高不少。我所有数据都是在冷启动条件下跑的尽管如此我还是会在后面标注“短上下文峰值”和“长上下文稳态”两个状态因为两者的差异真的很大。3.3 瓶颈定性这 14 tok/s 到底浪费在哪把 14 tok/s 拆开来看三块成本内存搬运占大头模型本身的计算占一部分解码器的串行等待占了一部分。内存搬运的问题通过换 INT4 全显存部署解决这能把速度拉到 25 tok/s。但 25 tok/s 依然不让人满意——聊天勉强能接受代码补全仍然有明显的滞后感。剩下的瓶颈在于“串行”。即使模型完全驻留显存一次生成一个 token27B 的权重每次都要完整过一遍。单卡 24GB 的消费级显卡计算 27B 一次前向大约需要 20ms 左右换算下来最高也就 50 tok/s 上下。想再往上走靠优化算子已经没多少空间了必须换思路这就是我投入研究投机解码的原因。4. 从 14 到 159 的调优过程每个参数都是挤牙膏挤出来的4.1 第一步先让模型彻底住进显存我把 Q8 换成了 INT4 量化。27B 模型权重大约 16GB加上 KV cache 和计算缓存24GB 显存虽然紧但能放开手脚。这一步操作完之后速度从 14 tok/s 直接跳到 25 tok/s。注意这还没开投机解码纯粹是解决了内存搬运问题。这个阶段还顺手做了个优化把提示词处理阶段放到单独的 GPU 流上和生成阶段分开。这样首 token 延迟降了不少虽然对稳态 tok/s 影响不大但体感上“从点击发送到屏幕上开始出字”的等待时间明显缩短了。对于聊天场景首 token 延迟比稳态速度更能决定主观体验。4.2 草稿模型怎么选太小不行更大更不行投机解码的第一步是选草稿模型。我第一反应是“越小越好”因为草稿模型生成速度快开销低。于是先跑了一个 0.5B 的参数模型结果接受率只有三成速度大约 40 tok/s提升有限。后来试了 1.5B 级别的同系列小模型接受率一下子拉到接近七成速度冲击到 90 往上。而 3B 的草稿模型接受率确实更高了但草稿生成本身的时间上去了整体速度反而回落。这里我画了张实际对比表草稿模型接受率实测生成速度tok/s短上下文峰值0.5B约 30%421.5B约 68%1073B约 75%96结论很清楚草稿模型选型的核心原则是“接受率增幅要超过草稿生成时间增幅”。一个 1.5B 的草稿模型在 24GB 显存上是这套配置的甜点位。另外要特别注意草稿模型的词表必须和主模型一致否则候选 token 的 id 对不上投机解码直接失效。这个我在第 5 节会详细说。4.3 草稿长度8、16、24、32 到底差多少草稿长度draft length指小模型一次生成多少个候选 token。参数太小大模型一次前向的批量优势发挥不出来参数太大草稿尾部 token 被拒绝的概率越来越高那些“白写”的部分全是浪费。我实测了 4 档草稿长度平均每轮接受 token 数生成速度tok/s8约 5.48416约 10.810724约 14.210132约 16.59564约 18.188这里面最值得琢磨的是为什么长度 16 到 24 收益反而下降了。因为草稿生成 24 个 token 需要 3 次小模型前向框架一般按固定块长度生成大模型验证一次总耗时比 16 的更久。而尾部草稿 token 的接受率在第 8 个 token 之后就快速衰减——让一个小模型一口气“编”24 个连贯 token后面几个基本是放飞自我。所以 16 是最平衡的选择。4.4 采样对齐让草稿和正式模型想得一样这是整个调优过程里最容易被忽视、但影响最大的一项。我第一次开投机解码的时候用的默认采样参数草稿模型走贪心解码主模型走带温度的随机采样。结果是草稿倾向于给出概率最高的那一个 token主模型却在抽签两边经常对不上。接受率看着不错实际速度却只有 50 多。后来我把草稿模型和目标模型的采样参数设置成完全一致同样使用温度 0.6同样的 top-p 0.9。这个改动让接受率从大约 45% 直接爬到接近 70%。原理很好理解如果主模型是随机抽签的草稿模型也必须是同一套抽签规则这样它的“运气”才能和正主同步。两者采样分布重叠越高投机解码的成功率越大。代码注释里写着“草稿模型用 argmax 更稳定”这种话千万别信那是针对旧版采样逻辑的遗留经验在采样对齐这一项上一致性才是第一性原理。4.5 最后的峰值冲刺计算图优化、批处理与流并发到这一步速度已经稳定在 107 tok/s 附近离 159 还有一段距离。剩下这部分提升主要靠三件小事一是把验证 batch 的大小调成“草稿长度 1”也就是一次验证 17 个位置。有些框架默认会拆成好几个小 batch 分批验证虽然逻辑一致但前向次数变多了带宽就浪费了。调成单 batch 后单次前向能完全吃到显存带宽的峰值。二是打开计算图融合。这会让框架把 attention、残差连接、层归一化这些小算子合并成更大的算子减少 kernel 启动次数。听起来很底层但实际收益非常可观直接贡献了大约 20% 的速度提升。三是用双流并发草稿模型和主模型跑在不同计算流上。草稿模型生成候选 token 的同时上一轮的验证结果可以并行做 KV cache 更新而不是等草稿全部生成完再启动大模型。这种流水线重叠让每一轮迭代的间隔时间缩短了将近 15%。4.6 完整调优对照表阶段配置说明生成速度tok/s初始状态Q8 量化 CPU offload14显存全驻留INT4 量化全部载入 GPU25投机解码默认参数0.5B 草稿长度 8采样分离42草稿模型升级换 1.5B 草稿长度 1690采样对齐草稿与主模型统一温度、top-p107计算图与流水线优化单 batch 验证 算子融合 双流并发1595. 投机解码的翻车现场那些让我越调越慢的配置调优不是一路顺利的中间至少有三四回改完参数之后速度反而比之前更低了。这些翻车经验比成功数据更有价值。5.1 开箱即用的默认参数为什么反而更慢第一次启动投机解码我满怀期待地等一个速度暴涨结果只看到 32 tok/s居然比不开投机还慢。查了半天才发现框架的默认草稿长度是 32默认草稿模型是一个非常小的 0.1B 模型接受率大约只有 15%。也就是说小模型在绝大多数时候是在瞎写大模型复验一遍发现前后矛盾几乎每个候选 token 都被拒绝白白多跑了一次草稿生成。最后我又要等草稿生成完又要等大模型否定它整个过程双重浪费时间。这个翻车告诉我一件事投机解码的默认参数是给“服务器显卡”设计的默认长度和草稿模型选型都偏保守。在消费级显卡上必须手动调参数不吃透这个功能不如不开。5.2 Tokenizer 不一致导致的哑火有一次我把草稿模型换成一个口碑很好的第三方小模型结构小巧、速度极快心想这次指定能起飞。结果打开之后傻眼了速度只有 18 tok/s比第一版还慢。去看日志发现主模型和草稿模型的 token 对应关系错位严重第 3 个草稿 token 已经和第 2 个主模型 token 对不上了等于验证永远在后面几步失败。原因很简单两个模型的词表不一样虽然“看起来”都能处理中文和英文但是同一个词在不同词表里的 id 完全不同。投机解码本质上是在做 token id 级别的比对词表不一致比对就失去意义。从那以后我选草稿模型只有一个标准和主模型出自同一系列、词表完全一致。这个条件比追求草稿模型本身的聪明程度重要得多。5.3 闪崩显存东拼西凑的代价把草稿模型升级到 3B 那个阶段显存已经非常极限主模型 INT4 占 16GB草稿模型 INT8 占 3GBKV cache 一路涨到 4GB 以上剩余空间所剩无几。然后我在一次长上下文测试中直接遇到了显存溢出进程崩了。后来我采用了两层防护第一给 KV cache 设置上限长上下文时主动溢出到 CPU 内存而不是让显存直接爆掉第二草稿模型不动辄上 3B1.5B 级别的草稿在 24GB 显存上是更稳妥的选择。显存这东西永远是动态的你能给模型留多点冗余推理就多一分稳定。5.4 长文本场景为什么速度会腰斩把 159 tok/s 当成日常速度是不诚实的。我测了一下 8K 上下文的代码仓库续写任务同样的参数组合速度掉到 68 tok/s 左右比峰值腰斩还多。原因有两个第一长上下文的 KV cache 占用了大量显存带宽每次前向除了读取权重还要读取越来越长的 KV cache带宽被分摊了第二草稿模型在长上下文中要关注的信息太多了前面写了一个关键变量名后面可能就忘了接受率从 68% 掉到 45% 左右。这两个因素叠加速度自然往下走。所以 159 是短上下文的峰值65 到 100 才是日常长文本的真实体感。这不是坏事——至少我做的事情从“不能忍”变成了“很流畅”。6. 调优之后的日子这个速度到底能拿来干什么159 tok/s 是什么概念普通人的阅读速度大约每分钟 300 到 400 个汉字也就是每秒 5 到 7 个汉字。一个 159 tok/s 的模型按英文 token 算相当于每秒输出 110 到 140 个英文字符明显快于人眼阅读中文场景因为 token 密度更高大概等效于每秒 80 到 100 个汉字已经追平甚至超过了一个人快速扫读的速度。这带来一个质变生成不再需要等待而是变成了“你还没读完它已经写完了”。我用它做代码补全的时候光标几乎跟在输入后面实时出结果那种跟手的感觉和云端的 10 tok/s 完全是两个维度的体验。代码续写、单元测试生成、文档整理、格式转换这一类“机械生成”任务159 tok/s 意味着效率瓶颈从模型速度转移到了我的阅读速度。聊天场景反而体会不出这种提升因为人的阅读速度决定了对话节奏30 tok/s 和 159 tok/s 在“一句话已经很长”的场景里感官差距没那么大。所以我个人的建议是如果你的核心场景是通关对话、闲聊、头脑风暴那花大力气调投机解码的优先级不高如果你的核心场景是代码补全、批处理、长文本润色那这个调优投入绝对值回票价。我的最终配置给它一个交代主模型 INT4 量化1.5B 同词表草稿模型草稿长度 16采样参数统一温度 0.6、top-p 0.9单 batch 验证计算图融合打开双流并发。日常短文本峰值 159 tok/s8K 长上下文稳定在 70 左右。整个过程没有换任何硬件没有降模型质量只是在推理策略上做了一次系统性的抠参数。如果你也在同样的配置上跑 27B 级别的模型我建议你先别急着换卡把投机解码的参数照着这份调优路径走一遍。它不保证每个场景都翻十倍但大概率能让你从“用不下去”变成“用得挺顺手”。我最后悔的只有一件事没有早点把采样对齐这个参数搞清楚白白多等了一个礼拜的龟速输出。