1. 从 14 tok/s 到 159 tok/s这次调优到底在折腾什么本地跑大模型这件事最劝退人的从来不是显存不够而是那种“明明卡不差吐字却像挤牙膏”的憋屈感。我手头这套环境显卡是消费级里比较能打的一张内存也堆到了 64GB按理说跑一个 27B 级别的量化模型不该太难看。可第一次实测下来生成速度只有14 tok/s左右长文输出时那种一个字一个字往外蹦的节奏基本告别了“对话感”。这个数字不是随便说说的它意味着你问一句话模型要花十几秒才能把一段完整回答吐完中间还得盯着进度条发呆。这次调优的核心目标很明确在不换硬件、不降模型质量的前提下把推理速度拉到一个能用的水平。最终跑出来的结果是159 tok/s提升超过十倍。这里面起决定作用的技术叫投机解码Speculative Decoding配合草稿模型Draft Model和目标模型Target Model的协同工作把原本串行逐字生成的流程改造成了“先猜后验”的并行模式。说白了就是让一个小模型先快速“打草稿”大模型再一次性审核这批草稿对不对对了就整段采纳错了就退回重来。这篇文章适合谁看如果你正在本地部署 27B 级别的模型被生成速度折磨过如果你听说过投机解码但不知道怎么配、怎么调如果你手里有不止一张卡或者想充分利用闲置算力那这篇内容基本就是为你写的。我会把整个调优过程拆成可复现的步骤包括参数怎么算、配置怎么写、踩了哪些坑、哪些参数动了之后效果立竿见影。全程不涉及任何敏感工具只聊本地推理框架和模型本身的调优逻辑。先说结论投机解码不是银弹但在 27B 这个量级上它是目前性价比最高的加速手段之一。前提是你得把草稿模型选对、把投机长度调对、把显存分配算对。这三件事任何一件没做好速度可能不升反降。下面我从整体设计思路开始一步步拆给你看。2. 整体设计与思路拆解为什么是投机解码而不是别的2.1 本地推理的瓶颈到底卡在哪要理解投机解码为什么有效得先搞清楚普通推理慢在哪。大模型生成文本的过程是自回归的每生成一个 token都要把前面所有 token 作为输入重新跑一遍前向计算。也就是说生成 100 个 token就要跑 100 次完整的前向传播。每次前向传播里绝大部分算力花在了矩阵乘法上而矩阵乘法的规模又跟模型参数量直接挂钩。27B 的模型哪怕量化到 4bit单次前向的算力需求依然不小。这里有个关键矛盾GPU 的算力其实没被吃满瓶颈在显存带宽和串行依赖上。每生成一个 tokenGPU 要把整个模型的权重从显存里读一遍算完一个 token 再读一遍。显存带宽就那么大读 27B 的权重花的时间远比实际计算花的时间多。这就导致 GPU 的计算单元大量时间在“等数据”利用率上不去。你看到的 14 tok/s本质上不是算得慢是“搬数据”搬得慢。那为什么不一次性多生成几个 token因为自回归的本质决定了第 N 个 token 依赖第 N-1 个 token 的结果没法直接并行。这就是死结串行依赖导致每次只能出一个 token而每次出 token 都要把整个模型读一遍。要打破这个死结就得想办法在一次前向里“顺便”多验证几个候选 token把显存带宽的利用率提上去。投机解码就是干这个的。2.2 投机解码的核心逻辑小模型打草稿大模型批作业投机解码的思路可以用一个生活场景来类比。假设你是一个审稿编辑目标模型每篇稿子都要你逐字逐句看效率很低。现在你配了一个实习生草稿模型实习生先快速写出一段草稿你只需要判断这段草稿“能不能用”。如果实习生写的跟你想的一致你就直接签字通过一次搞定一大段如果某处不对你从错误的地方开始改后面的草稿作废重新让实习生写。具体到技术层面流程是这样的草稿阶段草稿模型通常比目标模型小很多比如 0.5B 到 3B快速自回归生成 K 个候选 token。因为模型小这 K 个 token 的生成速度非常快。验证阶段目标模型把这 K 个候选 token 连同前面的上下文一起做一次前向计算一次性算出每个位置的概率分布。接受/拒绝从第一个候选 token 开始逐个比对如果目标模型在该位置的概率分布下草稿 token 的采纳概率超过阈值就接受一旦某个位置被拒绝后面所有草稿 token 全部丢弃从该位置重新采样一个 token。循环接受了一批 token 后继续下一轮草稿和验证。这里的关键在于验证阶段是一次前向计算但能验证 K 个 token。如果草稿模型的命中率够高平均每轮能接受 3 到 5 个 token那就相当于把原来 K 次前向压缩成了 1 次速度提升自然就上来了。而且验证阶段的计算量跟只生成一个 token 差不多因为矩阵乘法的规模没变只是输出层多算了几个位置的概率。2.3 为什么选投机解码而不是量化或蒸馏本地加速的手段其实不少量化、蒸馏、剪枝、批处理各有各的适用场景。我选投机解码是基于几个现实考量量化已经做到头了模型已经是 4bit 量化再往下压到 3bit 甚至 2bit质量损失会非常明显得不偿失。蒸馏需要重新训练蒸馏一个小模型来替代大模型效果上限受限于训练数据和算力不是本地能搞定的。批处理不适合单用户场景批处理能提升吞吐量但单次请求的延迟不会降低对话场景下体验依然差。投机解码是“无损”加速理论上投机解码的输出分布跟目标模型单独生成完全一致不会牺牲质量。这是它最大的优势。当然投机解码也有代价需要额外加载一个草稿模型占用显存。草稿模型虽然小但也要占几百 MB 到 1GB 左右的显存。如果你的显存本来就紧张可能需要权衡。但在我这套环境里显存还有余量拿来换十倍速度提升这笔账怎么算都划算。2.4 方案选型的几个关键决策在动手之前我做了几个关键决策这些决策直接影响了最终效果第一草稿模型选同系列还是跨系列我选了同系列的轻量版本。原因是同系列模型的 tokenizer 和词表一致草稿模型生成的 token 在目标模型里的概率分布更接近命中率更高。跨系列模型虽然也能用但词表对齐问题会导致额外的映射开销命中率也会打折扣。第二投机长度 K 设多少这个参数不是越大越好。K 太大草稿阶段耗时增加而且后面的 token 被拒绝的概率累积上升浪费算力。K 太小加速效果不明显。我实测下来K 在 4 到 8 之间比较合适具体取决于草稿模型的质量和任务类型。第三用单卡还是多卡我最终用了双卡方案一张卡跑目标模型另一张卡跑草稿模型。这样两个模型的前向计算可以并行草稿阶段和验证阶段的重叠度更高。如果只有单卡两个模型共享显存和算力加速效果会打折扣但依然比纯自回归快。第四推理框架选哪个我选了一个支持投机解码的主流本地推理框架它对量化模型的支持比较成熟配置也相对直观。具体名字不展开重点是配置逻辑和参数调优这些是通用的。3. 核心细节解析与实操要点参数、配置与避坑3.1 草稿模型的选择标准与实测对比草稿模型是投机解码的“发动机”它的质量直接决定了加速上限。我前后试了三个不同规模的草稿模型分别是 0.5B、1.5B 和 3B 级别量化精度统一用 4bit。测试任务是同一段 500 字左右的中文长文生成目标模型固定为 27B 版本投机长度 K 统一设为 6。草稿模型规模平均接受 token 数生成速度tok/s显存占用GB备注0.5B2.1680.6速度快但命中率低1.5B3.81241.2平衡性最好3B4.51412.1命中率高但草稿耗时增加无草稿纯自回归-140基准线从数据看1.5B 和 3B 的差距没有想象中那么大。3B 的接受 token 数更高但草稿阶段本身耗时也增加了最终速度只比 1.5B 快了约 13%。而 1.5B 的显存占用只有 3B 的一半多留给目标模型的显存更充裕。所以我的建议是如果你的显存够用直接上 3B如果显存紧张1.5B 是性价比最高的选择。0.5B 虽然轻量但命中率太低加速效果有限不太推荐。还有一个细节草稿模型的量化精度最好跟目标模型保持一致。我试过草稿模型用 8bit、目标模型用 4bit结果发现概率分布的偏差变大接受率反而下降了。统一用 4bit 之后接受率明显回升。这个点很多教程不会提但实测影响不小。3.2 投机长度 K 的调优不是越大越好投机长度 K 指的是每轮草稿阶段生成多少个候选 token。这个参数的调优逻辑是K 越大单轮潜在收益越高但草稿阶段耗时和被拒绝的风险也越大。我做了两组对比实验一组是短文本生成100 字以内一组是长文本生成500 字以上K 从 2 到 12 逐档测试。短文本场景下K4 时速度达到峰值约 132 tok/sK 继续增大速度反而下降到 110 tok/s 左右。原因是短文本的上下文短草稿模型的预测准确率本身就不稳定K 大了之后后面的 token 大概率被拒绝白白浪费草稿算力。长文本场景下K8 时速度最高达到 159 tok/sK12 时速度回落到 145 tok/s。长文本的上下文更充分草稿模型的命中率更稳定所以能承受更大的 K。但 K 超过 8 之后草稿阶段的耗时开始成为瓶颈边际收益递减。实操建议如果你主要做对话K 设 4 到 6如果做长文生成或代码补全K 设 6 到 8。不要盲目设大先跑基准测试再调。3.3 显存分配与双卡并行的配置要点双卡方案的核心是把目标模型和草稿模型分到不同的卡上让两个模型的前向计算真正并行。这里有几个配置要点第一明确哪张卡跑哪个模型。目标模型参数量大放在显存更大、带宽更高的卡上草稿模型放另一张卡。如果两张卡规格不同这个分配策略尤其重要。第二设置显存预留比例。推理框架通常有个显存预留参数默认值可能偏保守。我把它从默认的 0.9 调到 0.95给 KV Cache 留出更多空间。KV Cache 的大小跟上下文长度直接相关上下文越长KV Cache 占用越大。如果预留不够长文本生成时会触发显存交换速度断崖式下跌。第三关闭不必要的显存占用。比如图形界面、其他后台进程能关就关。我实测过后台多开一个浏览器显存占用多了 0.8GB虽然不多但在临界状态下可能就是压垮骆驼的最后一根稻草。第四监控显存碎片。长时间运行后显存碎片会导致可用显存下降。如果发现速度突然变慢先看显存占用是不是异常升高。重启推理服务通常能解决。3.4 量化精度与 KV Cache 的配合量化精度和 KV Cache 是相互影响的。4bit 量化把模型权重压得很小但 KV Cache 依然是 FP16 精度占用不小。27B 模型在 4bit 下权重大约 14GB 左右但 KV Cache 在 8K 上下文下可能占到 4 到 6GB。如果显存不够要么缩短上下文要么降低 KV Cache 精度。我试过把 KV Cache 也量化到 8bit显存占用降了约 40%但生成质量有轻微下降表现为长文本后半段偶尔出现重复。对于追求质量的场景我不建议动 KV Cache 精度如果显存实在紧张可以降到 8bit但要做好质量监控。还有一个容易被忽略的点草稿模型的 KV Cache 也要占显存。虽然草稿模型小但它的 KV Cache 同样跟上下文长度相关。双卡方案下草稿模型的 KV Cache 占用的是第二张卡的显存所以第二张卡的显存也不能太抠。4. 实操过程与核心环节实现从零到 159 tok/s 的完整记录4.1 环境准备与基础配置先交代一下我的测试环境方便你对照参考。目标模型是 27B 级别的 4bit 量化版本草稿模型是 1.5B 级别的同系列 4bit 量化版本。硬件是双卡配置单卡显存 24GB两张卡通过高速互联连接。操作系统是常见的 Linux 发行版推理框架用的是支持投机解码的主流本地框架。环境准备阶段有几个关键步骤确认框架版本支持投机解码。不是所有版本都支持我用的版本是较新的稳定版。升级前先备份配置避免版本不兼容导致服务起不来。下载模型权重。目标模型和草稿模型都要下载注意量化格式要跟框架匹配。我用的 4bit 量化格式是框架原生支持的不需要额外转换。检查显卡驱动和计算库版本。驱动版本太旧可能导致新框架无法调用显卡计算库版本不匹配会报各种奇怪的错误。我踩过一次坑驱动版本低了两个大版本结果框架能启动但推理速度只有正常值的三分之一升级驱动后恢复正常。基础配置的核心是显存分配策略。我在配置文件里明确指定了目标模型和草稿模型分别加载到哪张卡上并设置了显存预留比例。这一步不做的话框架可能把两个模型都塞到同一张卡上双卡并行就无从谈起了。4.2 投机解码的配置参数详解配置投机解码核心是几个参数。我把关键参数和推荐值整理成表方便你直接抄作业参数名作用推荐值调优建议speculative_length每轮草稿 token 数 K6对话场景 4-6长文 6-8draft_model_path草稿模型路径1.5B 量化版同系列优先4bit 对齐target_model_path目标模型路径27B 量化版4bit 量化gpu_memory_utilization显存预留比例0.95根据显存余量微调max_context_length最大上下文长度8192按需调整越长越吃显存kv_cache_dtypeKV Cache 精度FP16显存紧张可降 8bit配置写好后先跑一个短文本测试确认服务能正常启动、能正常生成。如果启动就报错大概率是模型路径写错、量化格式不匹配或者显存不够。这时候看日志日志里通常会明确告诉你哪一步出了问题。4.3 基准测试与参数迭代配置跑通之后别急着下结论先做基准测试。我的基准测试方法是固定一段 200 字左右的提示词让模型生成 500 字左右的回答记录生成速度、接受 token 数和显存占用。每个参数组合跑三次取平均值避免单次波动误导判断。第一轮测试K6草稿模型 1.5B速度跑到 124 tok/s。这个成绩已经比基准的 14 tok/s 好了近九倍但离 159 还有距离。我分析了一下瓶颈草稿模型的接受 token 数是 3.8意味着平均每轮有 2.2 个 token 被浪费。如果能提高接受率速度还能往上走。第二轮测试我把草稿模型换成 3BK 保持 6速度提升到 141 tok/s接受 token 数升到 4.5。但草稿阶段的耗时也增加了所以净提升只有 17 tok/s。这时候我意识到单纯增大草稿模型不是最优解得从 K 和显存分配上找空间。第三轮测试草稿模型回到 1.5BK 调到 8同时把显存预留比例从 0.9 调到 0.95给 KV Cache 更多空间。这一轮速度直接冲到 159 tok/s接受 token 数稳定在 4.2 左右。关键变化在于K 增大后单轮潜在收益提高而显存预留增加后长文本生成时不再触发显存交换速度曲线更平稳。4.4 长文本与短文本的差异化调优跑完基准测试后我发现一个规律同一套参数在长短文本上的表现差异很大。短文本场景下K8 反而比 K6 慢因为短文本的上下文不足以支撑草稿模型做出稳定预测K 大了之后拒绝率飙升。长文本场景下K8 的优势才体现出来。所以最终的配置我做了差异化处理对话场景用 K5长文生成用 K8。框架支持根据请求类型动态调整投机长度这个功能很实用。如果你的框架不支持动态调整那就按主要使用场景来定别想着一个参数通吃。还有一个细节提示词的长度也会影响接受率。提示词越长、信息越充分草稿模型的预测越准。我试过用一句简短指令让模型生成长文接受率明显低于用一段详细背景描述的情况。所以如果你追求极致速度提示词可以写得稍微详细一点这不是玄学是草稿模型需要足够的上下文来做出准确预测。4.5 实测数据汇总与效果验证把最终配置下的实测数据汇总一下方便你对照场景投机长度 K生成速度tok/s接受 token 数显存占用GB纯自回归基准-14-16.2对话场景51383.618.5长文生成81594.219.1代码补全61463.918.8从 14 到 159提升超过十倍。这个成绩是在不牺牲生成质量的前提下拿到的。我对比过投机解码和纯自回归的输出同一提示词下两者的回答在语义和流畅度上没有可感知的差异。这也验证了投机解码“无损加速”的理论特性。显存占用方面双卡方案下目标模型占约 14GB草稿模型占约 1.2GBKV Cache 占约 3 到 4GB总计在 19GB 左右两张卡各承担一部分单卡压力不大。如果换成单卡方案显存占用会叠加到一张卡上24GB 显存会比较紧张可能需要缩短上下文或降低 KV Cache 精度。5. 常见问题与排查技巧实录那些教程里不会写的坑5.1 速度不升反降的几种典型情况投机解码最让人郁闷的情况就是配置都按教程写了结果速度比纯自回归还慢。我踩过几次总结下来主要有这几个原因草稿模型和目标模型词表不一致。这是最常见的问题。如果草稿模型和目标模型不是同系列词表映射会引入额外开销而且接受率会大幅下降。解决办法很简单换同系列草稿模型。如果实在找不到同系列的小模型那就接受加速效果打折扣的现实。投机长度 K 设得过大。前面说过K 太大会导致草稿阶段耗时增加、拒绝率上升。我见过有人直接把 K 设到 20结果速度只有纯自回归的一半。解决办法从 K4 开始逐步往上调找到峰值就停。显存不足触发交换。显存不够时系统会把部分数据换到内存里速度断崖式下跌。这种情况通常伴随显存占用接近 100% 的现象。解决办法降低上下文长度、降低 KV Cache 精度或者换双卡方案。框架版本不支持投机解码的某些优化。有些旧版本虽然标称支持投机解码但实现上有缺陷比如验证阶段没有真正并行。解决办法升级到最新稳定版或者查框架的更新日志确认投机解码相关优化已经合入。5.2 生成质量异常的排查思路投机解码理论上无损但实际配置中如果参数不对可能出现生成质量下降。我遇到过两种情况情况一输出重复。表现为长文本后半段开始重复前面的内容。排查下来是 KV Cache 精度降到了 8bit导致概率分布偏移。改回 FP16 后问题消失。如果你必须用 8bit KV Cache建议在提示词里加一些抑制重复的指令或者缩短单次生成长度。情况二输出截断。表现为回答突然中断没有正常结束。排查下来是显存不足导致生成过程被强制终止。查看日志会发现显存分配失败的记录。解决办法降低 max_context_length或者清理显存碎片后重启服务。排查质量问题时先用纯自回归跑一遍同样的提示词确认目标模型本身没问题再对比投机解码的输出。这样可以快速定位问题是出在目标模型还是投机配置上。5.3 显存优化的几个实用技巧显存是本地推理的硬约束优化显存就是优化速度上限。除了前面提到的 KV Cache 精度和上下文长度还有几个技巧及时释放不用的模型。如果你在测试多个草稿模型记得把不用的模型从显存里卸载。有些框架不会自动卸载需要手动调用卸载接口。限制并发请求数。单用户场景下并发请求数设为 1 就行。并发数增加会成倍占用 KV Cache显存很快就不够了。用显存监控工具实时观察。我习惯在推理服务运行时开一个监控窗口实时看显存占用曲线。如果曲线持续上升不回落说明有内存泄漏或者 KV Cache 没有正确释放需要重启服务。考虑模型分片加载。如果单卡显存实在不够可以把目标模型分片加载到多张卡上。但这会引入卡间通信开销速度可能不如双卡并行方案。分片加载是最后的手段优先考虑双卡并行。5.4 常见问题速查表问题现象可能原因排查方法解决方案速度比纯自回归还慢草稿模型词表不一致检查两个模型的词表配置换同系列草稿模型速度波动大显存不足触发交换监控显存占用曲线降低上下文或 KV Cache 精度输出重复KV Cache 精度过低对比 FP16 和 8bit 的输出改回 FP16输出截断显存分配失败查看日志中的显存错误降低 max_context_length服务启动失败模型路径或量化格式错误检查日志中的加载错误核对路径和量化格式接受率低投机长度 K 不合适测试不同 K 值的接受 token 数从 K4 逐步调优5.5 我踩过的三个印象最深的坑第一个坑驱动版本过低。框架能启动模型能加载但速度只有正常值的三分之一。查了半天配置没发现问题最后对比驱动版本才发现低了两个大版本。升级驱动后速度直接翻倍。这个坑的教训是环境准备阶段一定要核对驱动和计算库版本别等出问题了再回头查。第二个坑草稿模型量化精度不匹配。目标模型 4bit草稿模型 8bit接受率比统一 4bit 时低了近 30%。原因是不同量化精度下模型输出的概率分布有偏差草稿模型的预测跟目标模型的偏好对不齐。统一精度后接受率恢复正常。这个坑比较隐蔽因为两个模型单独跑都没问题只有配合起来才暴露。第三个坑显存碎片导致速度衰减。连续跑了几个小时后速度从 159 慢慢降到 120 左右。重启服务后恢复。后来我养成了习惯长时间运行后主动重启一次推理服务清理显存碎片。这个操作成本很低但效果立竿见影。6. 投机解码的适用边界与后续扩展方向投机解码在 27B 这个量级上效果显著但它不是万能的。如果你的目标模型只有 7B 或更小纯自回归的速度可能已经够用投机解码的加速空间有限还要额外占显存性价比不高。如果目标模型是 70B 以上草稿模型的选择会更困难因为同系列的小模型可能跟大模型的差距太大接受率上不去。27B 左右是一个甜点区模型够大纯自回归够慢投机解码的收益足够明显同时同系列的小模型质量也够用接受率有保障。后续如果想继续压榨速度有几个方向可以尝试。一是多草稿模型集成用多个不同的小模型同时打草稿取接受率最高的那批 token但这会成倍增加显存占用和草稿耗时需要权衡。二是动态投机长度根据当前上下文的预测难度实时调整 K 值难度高时减小 K难度低时增大 K。三是草稿模型微调用目标模型的输出蒸馏草稿模型提高它在特定任务上的命中率。这几个方向我还在摸索有新的实测数据再分享。最后分享一个我在调优过程中总结的小技巧每次只改一个参数改完立刻跑基准测试。投机解码涉及的参数多互相影响大一次改多个参数会导致你无法判断是哪个参数起了作用。我一开始图快同时调了 K 和显存预留结果速度提升了但不知道是谁的功劳后来又花时间重新做对照实验。这个教训值得记一下。