大模型推理这件事真正落到生产环境里最扎心的往往不是模型效果而是成本和延迟。一个70B级别的模型FP16精度下光权重就要占140GB显存单卡根本放不下多卡并行又要考虑通信开销就算勉强跑起来生成一个token要等几百毫秒用户早就关掉页面了。我最早接触推理加速是在一个对话类项目上当时线上用的是FP16全精度部署QPS一上去GPU就打满老板天天盯着账单问为什么这么贵。后来一路摸爬滚打把量化、投机采样、PD分离这几套东西挨个试了一遍才算把成本压到能接受的范围。这篇文章就把我踩过的坑和验证过的方案完整梳理出来从量化怎么选、投机采样怎么调、PD分离怎么拆到三者怎么组合尽量讲透。适合已经跑通过基础推理、想进一步压成本降延迟的工程师也适合刚接触这块、想建立整体认知的读者。1. 量化把权重从FP16压到INT4到底省了什么1.1 量化的本质是精度换空间但换法有讲究量化的核心逻辑很朴素神经网络权重和激活值原本用16位浮点数存储但实际推理时并不需要这么高的精度用8位甚至4位整数表示显存占用直接砍到原来的1/2到1/4。听起来简单但真正动手就会发现量化不是简单地把浮点数截断成整数中间涉及缩放因子scale和零点zero point的设计不同方案对精度的影响差异巨大。以最基础的对称量化为例假设一组权重范围是[-2.5, 3.1]要映射到INT8的[-127, 127]区间。缩放因子就是max(abs(权重))/127这里取3.1/127≈0.0244。每个权重除以这个缩放因子再四舍五入就得到量化后的整数值。反量化时乘以缩放因子还原。问题在于如果权重分布不均匀比如大部分值集中在[-0.5, 0.5]只有极少数离群值到了3.1那缩放因子会被离群值拉大导致大部分权重被压缩到很小的整数范围内精度损失严重。这就是为什么per-channel量化比per-tensor量化效果好——每个通道单独算缩放因子离群值只影响自己所在的通道。实际选型时我一般会看几个维度显存节省比例、精度损失、推理速度提升、以及部署复杂度。下面这张表是我实测过几种主流方案在7B模型上的对比硬件是单张A100 80Gbatch size设为8量化方案权重精度显存占用相对FP16速度困惑度上升部署难度FP1616bit14GB1.0x基准低INT8 (bitsandbytes)8bit7.5GB1.3x0.05低GPTQ INT44bit4.2GB2.1x0.15中AWQ INT44bit4.0GB2.4x0.08中GGUF Q4_K_M4bit4.3GB1.8x0.12低从表里能看出来AWQ在精度和速度上综合表现最好但它的量化过程需要校准数据集部署时也要对应的推理内核支持。GPTQ生态更成熟几乎主流推理框架都支持但速度略逊。GGUF适合本地部署场景CPUGPU混合推理很方便但纯GPU吞吐不如前两者。1.2 校准数据集的选择比量化算法本身更容易被忽略很多人做量化时把注意力全放在算法上随便拿几百条数据跑校准就完事结果量化后模型在某些任务上崩得厉害。我踩过最惨的一次是拿通用新闻语料校准一个代码模型量化后代码补全的准确率掉了将近20个百分点。后来才明白校准数据的分布必须和实际推理场景匹配。校准的本质是用少量样本估计权重和激活的分布范围如果校准样本里全是短文本那模型在处理长文本时的激活范围就会被低估量化后溢出严重。我的经验是校准集至少覆盖三类样本短输入短输出、长输入短输出、长输入长输出每类200到500条总量控制在1000条左右就够了。如果模型有特定领域倾向比如医疗、法律、代码校准集里这类样本要占一半以上。还有一个细节是校准时的序列长度。很多框架默认用512或1024但如果实际推理时序列能到4096校准长度也得跟上。我一般会把校准长度设成实际最大长度的80%左右比如最大4096就用3276这样既覆盖了大部分场景又不至于因为太长导致校准太慢。1.3 量化后的精度验证不能只看困惑度困惑度perplexity是最常用的量化评估指标但它有个致命问题困惑度对量化误差不敏感。我见过量化后困惑度只涨了0.1但实际生成时重复、胡言乱语的情况明显增多。所以除了困惑度还得看下游任务的实际表现。我的验证流程一般分三步。第一步跑标准基准比如MMLU、GSM8K、HumanEval看量化前后分数变化一般掉2个点以内可以接受。第二步跑业务相关的测试集这一步最关键因为标准基准和实际场景往往有差距。第三步做人工抽检随机抽100条生成结果让标注同学盲评看有没有明显的质量下降。三步都过了才敢上线。另外提醒一点量化对不同的层影响不一样。注意力层的QKV投影对量化比较敏感FFN层相对鲁棒。如果发现量化后效果掉太多可以试试混合精度量化——敏感层保持FP16其他层用INT4。GPTQ和AWQ都支持这种配置代价是显存节省会打折扣但精度能拉回来不少。2. 投机采样用一个小模型给大模型提速2.1 投机采样的核心思想是猜对了就赚猜错了不亏大模型推理慢的根本原因是自回归生成——每生成一个token都要跑一次完整的前向计算而前向计算的时间主要花在加载权重上计算量本身并不大。这就导致GPU的计算单元大量空闲瓶颈在显存带宽。投机采样Speculative Decoding的思路是用一个小的草稿模型draft model快速生成多个候选token然后让大模型一次性验证这些token是否正确。如果草稿模型猜对了大模型一次前向就能确认多个token相当于把多次串行计算变成了一次并行验证。这里的关键在于草稿模型要足够小足够快同时预测准确率要够高。如果草稿模型太差大模型频繁拒绝候选token那加速效果就没了甚至因为多了草稿模型的开销反而更慢。我实测下来草稿模型和大模型的能力差距不能太大一般草稿模型参数量是大模型的1/10到1/5比较合适。比如70B模型配7B草稿模型13B模型配1.5B草稿模型。投机采样的加速比有个理论公式假设草稿模型生成γ个token接受率为α那期望加速比大约是(1-α^(γ1))/((1-α)(γ*c1))其中c是草稿模型和大模型单次前向的时间比。这个公式告诉我们γ不是越大越好。γ太大时后面的token接受率会指数下降而且草稿模型生成更多token也要花时间。实践中γ取4到8比较合适具体要看任务类型。2.2 草稿模型的选型与训练草稿模型不一定非要自己训练但自己训练的草稿模型效果通常更好。我试过三种方案各有适用场景。第一种是直接用同系列的小模型比如用Llama-3-8B给Llama-3-70B做草稿。这种方案最省事tokenizer一致输出分布也比较接近接受率一般在60%到75%之间。缺点是草稿模型本身也不小推理时要额外占显存70B8B的组合在单张80G卡上跑INT4勉强够FP16就放不下了。第二种是蒸馏一个更小的草稿模型。用大模型的输出作为软标签训练一个1B到3B的小模型。这种方案草稿模型更小更快但训练成本高而且接受率通常比同系列小模型低一些大概50%到65%。好处是显存占用小可以和大模型同卡部署。第三种是用EAGLE这类专门设计的投机采样方法。EAGLE不单独训练草稿模型而是在大模型的隐藏层特征上接一个轻量级预测头直接预测下一个token的特征。这种方案接受率最高我实测能到80%以上但实现复杂度也最高需要改模型结构部署时也要对应的推理框架支持。选型时我会考虑几个因素如果显存充裕、追求快速上线选同系列小模型如果显存紧张、愿意投入训练选蒸馏方案如果追求极致加速、团队有推理框架改造能力选EAGLE。2.3 投机采样的调参经验投机采样有几个关键参数需要调草稿长度γ、接受阈值、以及是否启用动态γ。γ的调整我一般从4开始试逐步加到8看加速比的变化。如果加到8之后加速比反而下降说明接受率掉得太快就停在6或7。接受阈值这个参数很多人不知道。标准投机采样是严格验证草稿token必须和大模型采样结果完全一致才接受。但实际中可以做松弛比如大模型对草稿token的概率超过某个阈值就接受这样能提高接受率代价是生成质量可能有微小下降。我一般把阈值设在0.8到0.9之间再低就不敢用了。动态γ是个很实用的技巧。在生成初期上下文短草稿模型预测准确率高可以用大一点的γ生成到后面上下文长了草稿模型准确率下降就自动调小γ。vLLM和TensorRT-LLM都支持这种动态调整开启后加速比能再提升10%到15%。还有一个坑是batch size对投机采样的影响。投机采样在batch size1时加速效果最好因为此时GPU计算单元空闲最多。batch size增大后GPU利用率上去了投机采样的收益就变小了。我实测batch size8时投机采样的加速比从2.5x掉到1.4x左右。所以投机采样更适合低并发、低延迟的场景比如个人助手、代码补全不太适合高并发的批量推理。3. PD分离把预填充和解码拆到不同机器上3.1 预填充和解码的计算特征完全不同大模型推理分两个阶段预填充prefill和解码decode。预填充是把整个输入序列一次性送进模型计算所有位置的注意力输出第一个token。这个阶段是计算密集型的矩阵乘法规模大GPU计算单元利用率高。解码是逐个生成后续token每次只处理一个新token但要和之前所有token做注意力计算。这个阶段是显存带宽密集型的计算量小但访存量大GPU计算单元大量空闲。这两个阶段的特征差异导致它们对硬件的要求不同。预填充适合算力强的卡解码适合显存带宽大的卡。如果混在一起跑就会出现资源错配——预填充时显存带宽浪费解码时算力浪费。PD分离Prefill-Decode Disaggregation就是把这两个阶段拆到不同的机器或不同的GPU上各自用最适合的资源配置。PD分离的架构一般是这样一组机器专门做预填充叫P节点另一组专门做解码叫D节点。请求进来先到P节点做预填充生成第一个token和KV Cache然后把KV Cache传给D节点D节点接着做解码。KV Cache的传输是PD分离的关键开销70B模型在4096序列长度下KV Cache大约2GB左右通过高速网络传输需要几十毫秒。如果传输开销太大PD分离的收益就被吃掉了。3.2 PD分离的收益与代价PD分离最大的收益是资源利用率提升。我做过一个对比实验同样的硬件配置混布方案和PD分离方案在相同SLA下的吞吐差距能到1.8倍。原因是混布时预填充和解码互相干扰预填充的长请求会阻塞解码的短请求导致尾延迟飙升。PD分离后预填充和解码各自独立调度互不影响。但PD分离也有代价。首先是KV Cache传输开销这个前面说了。其次是架构复杂度上升需要额外的调度层来协调P节点和D节点还要处理节点故障、负载均衡等问题。第三是显存浪费P节点做完预填充后KV Cache就传走了本地不保留但P节点本身也需要显存来加载模型权重。所以PD分离更适合大规模部署小规模部署反而可能因为复杂度上升导致整体效率下降。我一般建议日请求量在百万级别以上、且对尾延迟有要求的场景考虑PD分离。如果请求量不大或者对延迟不敏感混布方案更简单可靠。3.3 PD分离的调度策略PD分离的调度比混布复杂得多核心要解决三个问题请求怎么分配到P节点、KV Cache怎么传输、D节点怎么调度解码。请求分配我试过两种策略。一种是轮询简单但效果一般因为不同请求的预填充计算量差异很大长请求和短请求混在一起会导致P节点负载不均。另一种是按输入长度分桶短请求走一组P节点长请求走另一组这样每组P节点的负载比较均衡。分桶的阈值我一般设在1024和4096小于1024算短1024到4096算中大于4096算长。KV Cache传输有两种方式。一种是通过网络直接传P节点算完直接把KV Cache发给D节点。这种方式延迟低但要求网络带宽足够而且P节点和D节点要能直连。另一种是通过共享存储中转P节点写到共享存储D节点从共享存储读。这种方式解耦了P和D但多了一次读写延迟更高。我一般优先用直传只有在网络条件不允许时才用共享存储。D节点的调度关键是batch管理。解码阶段每个请求每步只生成一个token如果batch太小GPU利用率低batch太大显存又不够。我一般会把D节点的batch控制在32到64之间同时用连续批处理continuous batching来动态调整——新请求随时加入完成的请求随时退出保持batch始终处于满载状态。4. 三者组合量化打底、投机采样提效、PD分离扩吞吐4.1 组合顺序有讲究量化、投机采样、PD分离这三项技术不是互斥的可以组合使用但组合顺序会影响最终效果。我的经验是量化打底投机采样提效PD分离扩吞吐。量化是基础先把模型压到能接受的显存范围内这是后面所有优化的前提。如果模型本身都放不下谈别的没意义。量化做完后单卡能放下模型了再考虑投机采样。投机采样需要额外的草稿模型量化后显存有富余才能加。最后是PD分离这是在单机优化到极限后通过分布式架构进一步提升吞吐的手段。组合时要注意几个冲突点。第一量化后的模型和草稿模型的精度要匹配。如果大模型用了INT4量化草稿模型也用INT4那草稿模型的预测准确率会下降接受率降低。我一般让草稿模型保持FP16或INT8保证预测质量。第二PD分离后KV Cache传输的是量化后的KV还是FP16的KV如果KV也量化了传输量能减半但解码精度会受影响。我一般KV Cache保持FP16只量化权重这样精度损失可控。第三投机采样在PD分离架构下草稿模型放在P节点还是D节点我一般放在D节点因为解码阶段是投机采样的主战场草稿模型和主模型同节点部署通信开销最小。4.2 一个实际部署案例的参数配置拿一个13B模型的对话服务举例日请求量200万平均输入长度800平均输出长度200P99延迟要求2秒以内。我最终的配置是这样的量化方案用AWQ INT4权重显存从26GB降到7GB单张A100 40G能放下主模型加草稿模型。草稿模型用1.5B的同系列模型FP16精度显存占用3GB。投机采样γ设为6接受率实测68%加速比约2.2x。PD分离用4台P节点加8台D节点P节点用A100 40GD节点用A100 80G。P节点只做预填充batch size开到16D节点做解码加投机采样batch size控制在48。这套配置下单D节点的解码吞吐约1200 token/s8台D节点总吞吐约9600 token/s满足200万日请求量绰绰有余。P99延迟实测1.4秒其中预填充占300毫秒KV Cache传输占80毫秒解码占1秒左右。整体成本比FP16混布方案降低了约60%。4.3 监控与调优的持续过程这套系统上线后不是一劳永逸的需要持续监控和调优。我重点盯几个指标接受率、KV Cache传输延迟、P节点和D节点的负载均衡、以及端到端延迟的P99和P999。接受率下降通常意味着草稿模型和主模型的分布漂移了可能是主模型更新了版本或者请求分布变了。这时候要重新校准草稿模型或者调整γ。KV Cache传输延迟上升一般是网络拥塞需要检查P节点和D节点之间的网络带宽利用率。负载不均衡则要调整请求分配策略或者动态扩缩容。我一般每周做一次全链路压测模拟真实请求分布看各项指标是否达标。每月做一次参数调优根据最近的请求特征重新调整γ、batch size、分桶阈值等参数。这套流程跑下来系统能一直保持在比较优的状态。5. 几个容易踩的坑和我的应对方式5.1 量化后模型输出重复的问题量化后模型最容易出现的问题是输出重复比如连续生成相同的句子或者陷入循环。这个问题在INT4量化下尤其明显因为量化误差累积到后面会导致概率分布偏移模型对某些token的概率估计出错反复选中同一个token。我试过几种缓解方式。第一种是调整采样参数把temperature稍微调高或者加一点重复惩罚repetition penalty一般设1.05到1.1就能明显改善。第二种是在量化时保留lm_head层为FP16因为输出层的量化误差对最终概率影响最大。第三种是用混合精度量化把注意力层的QKV投影也保留FP16。这三种方式可以叠加使用我一般先调采样参数不行再动量化配置。5.2 投机采样在长上下文下的失效投机采样在短上下文下效果很好但上下文一长接受率就断崖式下降。原因是草稿模型在长上下文下预测能力变差而且长上下文下主模型和草稿模型的注意力分布差异更大。我实测在4096上下文下接受率从短上下文的70%掉到40%左右加速比从2.2x掉到1.3x。应对方式有两种。一种是动态调整γ上下文越长γ越小4096以上直接关掉投机采样。另一种是用更好的草稿模型比如EAGLE方案在长上下文下接受率能保持在60%以上。我一般用动态γ实现简单效果也够用。5.3 PD分离的KV Cache传输瓶颈PD分离最怕的就是KV Cache传输成为瓶颈。我遇到过一次P节点和D节点之间的网络带宽被其他服务占满KV Cache传输延迟从80毫秒飙到500毫秒端到端延迟直接翻倍。后来做了网络隔离给PD分离的流量单独划了带宽问题才解决。除了网络隔离还可以做KV Cache压缩。比如只传注意力层的KVFFN层的中间激活不传或者对KV做量化INT8量化后传输量减半精度损失很小。我一般先做网络隔离如果还不够再上KV量化。5.4 组合方案下的故障排查三项技术组合后出问题时排查链路很长。我的经验是分层排查先看量化层确认模型输出是否正常可以临时切回FP16对比再看投机采样层关掉投机采样看延迟变化判断是否是草稿模型的问题最后看PD分离层检查P节点和D节点的日志看KV Cache传输是否正常。每层都要有独立的监控指标和开关方便快速定位和回滚。我一般会在配置里保留所有开关出问题时能一键切换回最简方案先恢复服务再慢慢排查。6. 关于工具链和框架选择的个人建议6.1 推理框架的选型目前主流的推理框架有vLLM、TensorRT-LLM、SGLang、以及HuggingFace TGI。我三个都用过各有优劣。vLLM上手最快PagedAttention和连续批处理都是内置的量化支持也全AWQ、GPTQ、FP8都有。缺点是PD分离支持相对弱一些需要自己改调度层。TensorRT-LLM性能最好尤其是INT4量化下的推理速度但编译流程复杂模型转换要花不少时间适合模型固定、追求极致性能的场景。SGLang在投机采样和结构化输出上做得最好EAGLE支持也最完善但生态相对小一些。TGI适合快速验证生产环境用得少。我的建议是如果团队推理经验不多先用vLLM跑通它的文档和社区最友好。如果追求极致性能且模型不常换上TensorRT-LLM。如果投机采样是核心需求选SGLang。6.2 量化工具的选择量化工具我主要用AutoAWQ、AutoGPTQ、llama.cpp的量化工具、以及NVIDIA的TensorRT Model Optimizer。AutoAWQ和AutoGPTQ适合GPU部署llama.cpp适合CPUGPU混合部署TensorRT Model Optimizer适合配合TensorRT-LLM使用。选量化工具时要注意几点第一确认推理框架支持该量化格式比如vLLM支持AWQ和GPTQ但GGUF只支持llama.cpp。第二确认量化工具支持你的模型结构有些新模型结构出来得晚量化工具还没适配。第三确认量化后的模型能正确加载我遇到过量化工具和推理框架版本不匹配导致加载失败的情况一般锁版本能解决。6.3 监控和压测工具监控我一般用Prometheus加Grafana重点监控GPU利用率、显存占用、请求延迟分布、以及各阶段的耗时拆解。压测用Locust或wrk模拟真实请求分布重点看P99和P999延迟。压测时要注意请求分布的模拟。很多压测工具默认用固定长度的请求但真实场景下输入输出长度都是变化的。我一般会从线上日志里采样真实的请求长度分布用这个分布来生成压测请求这样压测结果才有参考价值。7. 一些零散但重要的经验7.1 量化不是越激进越好我见过有人为了省显存把模型量化到INT2甚至INT1结果模型完全不能用。量化的收益是边际递减的INT8到INT4显存减半但INT4到INT2显存只再减半精度损失却成倍增加。我一般建议INT4是底线再低就不划算了。如果显存实在不够宁可换更小的模型也不要过度量化大模型。7.2 投机采样的草稿模型要定期更新草稿模型和主模型的分布会随着时间漂移。如果主模型做了微调或者请求分布变了草稿模型的接受率会下降。我一般每季度重新训练或校准一次草稿模型保证接受率维持在合理水平。7.3 PD分离的节点比例要动态调整P节点和D节点的比例不是固定的。如果请求的输入长度增加P节点的负载会上升需要增加P节点如果输出长度增加D节点的负载上升需要增加D节点。我一般会根据最近一周的请求特征每周调整一次节点比例。7.4 别忘了推理之外的优化量化、投机采样、PD分离都是推理层面的优化但端到端延迟还包括网络传输、排队、后处理等环节。我遇到过推理本身很快但排队等了很久的情况。所以优化时要看全链路别只盯着推理引擎。排队优化可以用优先级队列把短请求优先处理网络优化可以用长连接、压缩传输后处理优化可以异步化不阻塞主流程。7.5 测试环境要和线上一致量化、投机采样、PD分离这些技术对硬件和网络都很敏感测试环境的配置要和线上尽量一致。我踩过测试环境用A100、线上用H100的坑量化后的性能表现完全不同测试通过的配置上线后效果差很多。后来规定测试环境必须和线上同型号硬件网络拓扑也要一致问题才少了。这套东西我前后折腾了大半年从最开始FP16硬扛到后来量化加投机采样再到PD分离每一步都是被成本和延迟逼出来的。现在回头看最关键的其实不是某项技术本身而是理解每项技术的适用边界知道什么场景该用什么方案。量化解决显存问题投机采样解决单请求延迟问题PD分离解决吞吐问题三者各司其职组合起来才能把成本和体验都做到可接受的范围。如果你也在做类似的优化建议先从量化入手这是投入产出比最高的一步跑通之后再逐步加投机采样和PD分离别一上来就全上复杂度太高容易翻车。