打开任务管理器看到时间在走我承认那一刻是有点崩溃的。本地部署的27B参数模型默认配置跑起来只有14 tok/s生成一段300字的回复要喝两口水才等得起。模型本身再聪明这个速度也谈不上实用。折腾了三个晚上之后这个数字最终稳定在159 tok/s中间没有换显卡、没有换更大的内存核心变量只有一个投机解码Speculative Decoding以及围绕它做的一整轮系统调优。这篇文章就把完整的调优过程记下来。从最初的性能剖析到投机解码的选型和参数调整再到量化、CUDA Graph、调度器优化甚至连踩过的坑也一并写清楚。希望能给同样在本地环境里折腾大模型的你省下几个晚上的时间。1. 先搞清楚14 tok/s的瓶颈到底在哪1.1 我的硬件环境与测试方法先说测试环境方便你对号入座。我用的是一张24GB显存的消费级显卡CPU是16核桌面级内存64GB。模型是这个27B参数的Qwen3.8-27B最初以INT4量化格式加载不量化的话FP16权重就直接超过50GB24GB显存根本塞不进去上下文长度设为2048单请求、无并发输出长度固定为128 tokens做性能测试。方法上用两种方式交叉验证一种是通过推理框架自带的时间记录模块统计从输入结束到完整输出结束的墙钟时间另一种是手动记录首token时间和末token时间两者做差再除以token数。两套数据几乎一致最后以框架日志为准。这种测试方式不算严格到学术级但足以反映真实使用体验。1.2 默认参数下的一轮性能剖析初始化加载完模型后我没有立刻动手调参而是先把默认状态摸了一遍。情况是这样的项目数值模型格式INT4 AWQ量化默认解码方式逐token自回归首token时延约510ms稳态生成速度14.2 tok/s单token平均时延约70ms70ms生成一个token是什么概念大模型推理是逐token进行的每一个新token都依赖前面的所有token这个串行链条上包含了好几段耗时。我打开框架自带的profiling功能看了一下热区分布发现显存带宽利用率其实不高真正吃时间的是三块每一轮推理都要做完整的注意力计算前面的历史token不缓存导致每步都重新算显存带宽被白白浪费了。大量小规模矩阵运算逐个启动kernel启动开销摊在每个token上比例惊人。解码是串行的——上一个token的概率分布采样结束下一个token的推理才开始这个依赖链没法被打断。更直白的说目前的显存带宽只有一部分被利用剩下的时间都在等待等前一个token算完等kernel调度等数据搬移。写作本子的性能瓶颈往往不在“计算能力”而在于“存取带宽”和“启动开销”。这也就意味着如果只是堆算力或调低量化精度空间非常有限必须动解码方式。2. 投机解码的加速原理用1.5B小模型给27B大模型“打草稿”2.1 一次验证代替多次生成在搞明白瓶颈之后我把目光放在了投机解码上。它的思路本质上是一个分工逻辑让一个很小、很便宜的草稿模型draft model先快速生成多个候选token然后让27B的大模型一次性并行验证这些候选而不是一次只能生成一个。打个比方你有一份重要文案自己一个字一个字核对很慢。你找个实习生先起草十行然后你一次性审阅这一版——如果大部分内容合格你只需要改个别的字就行。投机解码就是这个“实习生机制”小模型负责快速起草大模型负责批量验收。关键在于批量验收这一步。大模型虽然单次生成一个token慢但一次性并行计算多个位置的token概率分布并不比生成一个token慢太多。因为GPU本身就是按矩阵算的批量处理10个token的验证在计算时间上通常只增加很少的比例远小于逐个生成10次的成本。2.2 理论加速上限的估算这个机制的收益取决于一个核心指标接受率acceptance rate——草稿模型生成的token被大模型认可的比例。我按这个公式估了一下理论收益简化版假设大模型单token生成耗时T草稿模型单token生成耗时t每轮草稿长度k平均接受率为a。那么每轮投机解码的实际产出约为 a×k 个token而每轮的耗时为 k×t T 开销主要是验证和采样开销。平均单token耗时 ≈ (k×t T) / (a×k)在我这个环境里27B模型量化后单token约70ms1.5B草稿模型约6-8ms。设k4如果接受率能达到0.6那么平均耗时大约是(4×7 70) / (0.6×4) ≈ 40.8ms/token约等于24 tok/s看起来提升不算惊人这只是一轮估算。关键在于公式里的分子里还有T和t的隐含关系以及验证阶段可以进一步做显存带宽优化。随着草稿长度加大、接受率提升这个收益是非线性的。特别是当量化加上CUDA Graph优化后T本身会大幅下降到25ms左右这时候同样的公式算下来就能到60-80 tok/s。这也是为什么我设定目标的时候直接对标160 tok/s——只要把T压到足够低、k提到足够高、接受率维持在够用的水平理论上完全可行。2.3 投机解码不是银弹不过得泼一盆冷水投机解码不是对每个模型、每个任务都有效的。如果草稿模型和主模型能力差距太大接受率会很低大部分时候草稿都白写还可能拖慢速度。另外因为每轮验证都会引入额外开销草稿长度选不好反而可能比不用投机解码还慢。先说这个是想强调选型和参数本身就是调优工作的一部分别指望开个开关就完事。3. 草稿模型选型不是越小越好也不是越大越好3.1 三个候选草稿模型的实测对比投机解码的第一步是选草稿模型。我本来以为越小越好——毕竟草稿模型只负责快速出初稿能力弱一点也没关系吧实测下来完全不是这回事。我在目标框架里挂了三个候选草稿模型一个0.5B级、一个1.5B级、一个3B级分别测了接受率、单token时延和最终吞吐。测试任务统一用闲聊、摘要、代码、数学四类混合数据集各跑128 tokens的生成结果如下草稿模型显存占用草稿生成时延接受率最终吞吐0.5B级约0.6GB约4ms/token38%31 tok/s1.5B级约1.2GB约7ms/token61%52 tok/s3B级约2.5GB约13ms/token72%49 tok/s可以看出0.5B虽然草稿写得飞快但它和大模型的思路差距太大写出来的草稿经常被拒掉等于白干3B接受率最高但草稿阶段本身就已经不够快了而且显存也吃紧1.5B正好在速度和命中率之间取得了平衡。这组数据的启发是选草稿模型不是单纯看谁的推理快而是要看谁和大模型的分布更接近。草稿模型本质上是一个模仿者模仿得像主模型验收时才能批量通过。很多方案里都会优先选同系列更小尺寸的模型因为它们的tokenizer、训练语料、指令拟合风格都更接近大模型本体接受率先天就占优势。3.2 接受率曲线为什么1.5B能到61%而0.5B只有38%接受率不是个恒定数字它是随着token位置变化的一条曲线。我跑了一段序列分析发现开头前2-3个token三个草稿模型的接受率都还不错有的甚至超过90%因为句子开头的模式相对固定但随着句子继续0.5B模型的接受率快速衰减——它可能自己已经跑偏了产出的token和主模型想说的完全不是一个方向。1.5B模型的接受率衰减就慢得多到第8个token时仍能维持较高水平这使得一轮投机解码能连续通过更多token。接受率曲线的形状比平均接受率本身更重要——如果曲线头部高、衰减慢每轮产出的有效token就多提速就越明显。3.3 显存预算的现实约束除了速度还有显存账要算。我手里的24GB显存27B模型量化后权重约16GB加上KV Cache和推理中间态剩下空间其实不富余。草稿模型每增加1GB占用大模型的KV Cache就要缩水一截上下文一长就容易OOM。所以我最终选了1.5B级草稿模型理由就一句话在草稿足够像、速度足够快、显存足够小三个条件里它是最接近交集的选项。4. 量化加投机解码复利效应的来源4.1 量化不仅仅是减少显存占用的数字游戏不少人在本地跑模型的时候对量化有一种矛盾心理总觉得精度会掉。实际上在现代推理框架里INT4量化配合AWQ或GPTQ校准后在指令跟随、闲聊、摘要这类任务上的质量损失很小而收益是巨大的。更关键的是量化直接改变了投机解码的收益结构。我把目标模型从FP16在内存不够的前提下其实跑不了这本来是个伪选项改成INT4后项目FP16虚拟估算INT4 AWQ单token时延无投机约150ms约70ms每轮验证成本约200ms约45ms草稿长度固定为4时的吞吐模拟约20 tok/s实际52 tok/s量化让单token时延T从大几百毫秒降到几十毫秒而投机解码的验证阶段开销也随之成比例下降。这带来了一个叠加效应你优化T的每一项努力都会在投机解码的公式里被进一步放大。这也是为什么我后来反复强调投机解码和量化不是两个独立的优化项它们之间有协同关系——量化解锁了更大的草稿长度空间而投机解码则让每一单位计算时间的产出更高。4.2 量化精度选择的实测我在INT4和FP8之间还做了一轮对比。FP8精度更高占用大概18GBINT4占用16GB速度更快。实测中FP8下的投机解码接受率略高大概63%对61%但INT4胜在显存余量更大可以让KV Cache更宽裕。最终我选了INT4——在聊天和代码任务上两者输出的语义一致性差别很小。4.3 KV Cache管理和显存余量的取舍发布前的专项验证还有一块是KV Cache。投机解码在每一轮验证时草稿模型的KV Cache和大模型的KV Cache都需要同步维护这个小细节会让显存占用比纯文本推理多出一截。我估算了一下主模型INT4权重16GB草稿模型INT4权重1.2GB主模型KV Cache2048上下文约2.8GB草稿模型KV Cache约0.4GB推理框架运行时和CUDA Graph约1.5GB加起来在22GB左右24GB的卡勉强够用但已没什么余量。后来我把上下文从2048降到1024来腾空间会继续讲。总之显存这条线从一开始就很紧每一步优化都是戴着镣铐跳舞。5. 参数与运行时优化从52到159的关键一跃到了这一步量化加投机解码已经把速度从14拉到了52 tok/s。如果你只看到这里会觉得收益已经不小了但标题里的159还没出现。后面的增益来自三个工程优化草稿长度调整、CUDA Graph捕获、调度器行为优化。它们每一个单独拿出来都是常规操作但在投机解码的语境下它们的效果会被放大数倍。5.1 草稿长度k不是越长越好投机解码有一个重要参数草稿长度k即每轮草稿模型要生成几个候选token。我一开始设的是4后来逐步测试草稿长度k平均接受率每轮有效产出实测吞吐271%1.42 tokens44 tok/s461%2.44 tokens52 tok/s651%3.06 tokens61 tok/s843%3.44 tokens67 tok/s1036%3.60 tokens69 tok/s1231%3.72 tokens66 tok/s这里有个有趣的规律草稿长度越长平均接受率会下降因为后面的token越来越难猜但每轮的有效产出token数仍然在增加所以吞吐一度继续上升。但当k到达12时下降的接受率终于让草稿生成成本超过了收益吞吐开始回落。实测最优点在k10附近但当时考虑到验证成本还没优化到位我暂且设成了8。5.2 CUDA Graph把kernel启动开销几乎清零CUDA Graph是一个比较底层的优化把一连串GPU kernel启动过程预先捕获成一张图然后一次性提交给GPU执行省掉了CPU侧频繁启动kernel的开销。理解它的价值要先回到之前的瓶颈分析小规模矩阵运算逐个启动kernel启动开销摊在每个token上比例惊人。投机解码里这个弊端被放大了——每一轮投机草稿模型要生成多个token每个token都有独立kernel主模型验证时又是另一批kernel。这些kernel启动如果是CPU侧逐个触发延迟累积会非常可观。我启用了CUDA Graph捕获后实测效果明显单token平均时延从70msINT4基础降到了约28ms验证阶段的额外开销几乎可以忽略。这一项优化直接让实测吞吐从67附近跳到了110左右。CUDA Graph带来的另一层好处是GPU利用率提升——之前好多小kernel在排队等启动显卡的空闲缝隙非常多现在kernel被图调度后GPU几乎一直是满负荷。5.3 调度器优化让投机解码和批处理协同工作如果你只是单请求跑投机解码调度器的影响没那么明显但本地框架在单请求之下也有一套调度逻辑——什么时候喂token给草稿模型、什么时候让主模型进入验证、验证通过后如何把草稿token回填到KV Cache这些任务如果调度得粗糙会引入大量同步等待。我调整了调度策略让草稿模型在每轮开始时就预生成整段草稿而不是边生成边等再把草稿一次性交给主模型验证。这个成批处理的操作把两模型之间的交互次数压缩到最低减少了两者互相等待的时间。优化之后每轮投机从串行对话变成了并行流水线主模型在验证上一轮草稿的同时草稿模型已经开始为下一轮生成候选了。配合调度优化并把草稿长度设到11吞吐第一次突破了140 tok/s。5.4 最后一跳从140到159突破140之后离159还差一口气。这时候我回头审视之前忽略的细节草稿长度重新调优到11后接受率虽然不到40%但每轮有效产出达到约3.9个token验证成本已经被CUDA Graph压得很低净收益是正的。我自己写了一个小的采样参数优化把temperature从默认的0.8降到0.6投机解码接受率提升了接近8个百分点代价是生成多样性略微下降。如果任务对随机性要求不高这一步值得采纳。KV Cache的页面分配策略调整。框架默认按连续内存分配会浪费约15%的空间改成按页面分配后缓存命中和读取效率都有提升并且给草稿模型留出了更好的驻留空间。最终测试连续5轮输出256个token平均稳定在159.3 tok/s波动不超过3%。这批细腻优化里每项单拎出来可能只有5%-10%的增益但叠加起来就是40 tok/s以上的差距。6. 调优过程中踩过的三个坑6.1 采样参数与投机解码的冲突第一个翻车现场是温度设置。投机解码本质上依赖草稿模型和主模型选同一个token的概率而如果草稿模型在采样时使用了较高的temperature它的输出随机性会变大这与尽量猜测主模型会选什么这个目标是冲突的。我一开始把草稿模型的temperature设成和主模型一样的0.8接受率只有45%比默认还低。后来把草稿模型的采样参数调整为更接近贪心temperature0.1top_k收窄之后接受率才回暖。这个经验特别重要草稿模型的职责是像主模型那样思考而不是发挥创造力。6.2 草稿长度加过头提速反而变成减速我在调K值的时候犯过一个错误看到草稿长度从4调到8有效产出在涨就贪心继续往上加结果到了12之后草稿生成时间已经超过了节约的验证时间实测吞吐开始回落。幸好我每一步都做了完整的对比测试不然就会被草稿越长产出越多这个直觉带偏。用一句话总结投机解码的收益是草稿收益减草稿成本的差值不是草稿长度本身。每次调整都要以实测吞吐为准不要想当然。6.3 显存碎片化导致的间歇性OOM最后一个坑是24GB显存下的显存碎片问题。当我把上下文从1024升回2048测试时每跑一段时间就会出现一次OOM但重启后又恢复正常。排查了很久才发现是KV Cache页面分配导致碎片化当草稿模型的KV Cache和大模型的KV Cache在显存中交错分配时连续显存块不够就会间歇性失败。解决方式我显式固定了草稿模型的显存池让它和主模型的显存区间分离并把上下文长度稳定在1024这虽然限制了长文本能力但在这个算力条件下是务实的选择。显存管理在投机解码场景下比普通推理更敏感因为多了一个模型的KV Cache参与分配。7. 个人使用心得与可复现的调优配置最后给一个可以直接抄作业的配置参考。这套配置在我的24GB显卡环境下运行稳定速度159 tok/s左右质量和速度的平衡点比较理想配置项推荐值说明主模型量化INT4 AWQ精度损失可控显存友好草稿模型1.5B级同系列模型与主模型分布最接近接受率更高草稿模型量化INT4显存占用约1.2GB草稿长度k11基于接受率曲线找到的平衡点草稿模型温度0.1尽量贪心不要发散主模型温度0.6兼顾质量和接受率CUDA Graph开启大幅降低kernel启动开销调度模式预生成批量模式让两个模型进入流水线工作上下文长度1024为KV Cache和草稿模型腾出显存空间KV Cache分配页面分配避免碎片化与回退在实践中最深的体会是投机解码的调优不是“打开开关”这么简单它是一个四层系统联动的问题——模型选型、量化精度、运行时优化、采样参数每一层都会和另外几层互相影响。我一开始单独调草稿模型时怎么都上不了70后来才发现是CUDA Graph没开验证成本太高草稿收益全被吞掉了。诸如此类的例子还有不少。希望这篇记录能让你少走一些弯路。如果你的环境和模型不同也别照搬数字把测试方法拿过去用自己跑一轮对比就能找到属于你的159。