大模型推理这件事真正做过线上部署的人都知道训练只是前半场推理才是那个天天要面对的成本黑洞。一个70B级别的模型如果老老实实用FP16跑光权重就要吃掉140GB显存单卡根本放不下多卡并行之后吞吐还是上不去延迟也压不下来。这时候摆在面前的其实就三条路把数值精度降下来量化、让一次前向多吐几个token投机采样、把计算密集和访存密集的阶段拆开部署PD分离。这三样东西不是互斥的选项而是可以叠加的组合拳但每一块都有自己的坑配错了不但不加速反而更慢。我自己从最早用INT8跑BERT那会儿开始到后来折腾LLaMA、Qwen系列的量化部署再到最近在PD分离架构上踩了不少坑中间交的学费不算少。这篇就把这三块技术从原理到实操完整捋一遍重点讲清楚每项技术到底在解决什么问题、参数怎么选、什么场景下会翻车。不管你是刚接触推理优化的新手还是已经在做线上服务的老手应该都能从里面找到能直接抄作业的东西。1. 量化把权重和激活从FP16压到INT8/INT4到底省了什么1.1 量化省的不只是显存更是显存带宽很多人一提量化第一反应是省显存这个理解对但只对了一半。大模型推理在decode阶段是典型的memory-bound场景——每生成一个token都要把整个模型的权重从显存里读一遍。以70B模型为例FP16下每生成一个token要读140GB的数据而A100的显存带宽大概是2TB/s理论极限也就每秒14个token左右。这时候算力其实是闲置的瓶颈全在带宽上。把权重压到INT8数据量直接减半带宽压力也减半理论吞吐就能翻倍。压到INT4理论上能到4倍。这就是为什么量化在decode阶段效果特别明显而在prefill阶段计算密集提升就没那么大——prefill阶段瓶颈在算力不在带宽。所以量化的核心收益可以拆成三块显存占用下降权重从2字节/参数降到1字节INT8或0.5字节INT470B模型从140GB降到70GB甚至35GB单卡能装下的模型规模直接上一个台阶。显存带宽压力下降decode阶段吞吐提升的主要来源通常INT8能带来1.5到1.9倍的实际加速INT4能到2到3倍。算力利用率提升INT8的矩阵乘在支持Tensor Core INT8的卡上比如A100、H100理论算力是FP16的2倍但实际能不能吃满要看kernel实现。1.2 权重量化、激活量化、KV Cache量化是三件不同的事新手最容易混淆的就是把量化当成一个整体。实际上在大模型推理里量化至少分三个层面每个层面的难度和收益都不一样。权重量化Weight-only Quantization是最简单也最常用的。只把模型权重压成INT8或INT4激活值还是FP16计算的时候把权重反量化回FP16再做矩阵乘。这种方式实现简单精度损失小主要收益是省显存和带宽。GPTQ、AWQ、GGUF这些方案都属于这一类。激活量化Activation Quantization就麻烦多了。激活值的分布是动态的不同输入、不同层之间差异很大而且经常有离群值outlier。直接量化激活会导致精度大幅下降。SmoothQuant的思路是通过数学等价变换把激活的量化难度转移到权重上让两者都好量化。只有权重和激活都量化成INT8才能真正用上INT8的Tensor Core拿到算力上的收益。KV Cache量化是长上下文场景的救命稻草。上下文越长KV Cache占的显存越多有时候甚至超过模型权重本身。把KV Cache从FP16压到INT8显存直接减半能支持的并发数和上下文长度都上去了。但KV Cache的量化对精度影响比较敏感尤其是attention的softmax之后需要仔细调。量化层面典型方案主要收益精度风险实现难度权重量化GPTQ、AWQ、GGUF省显存、省带宽低低激活量化SmoothQuant用上INT8算力中高高KV Cache量化FP8 KV、INT8 KV省显存、支持长上下文中中1.3 GPTQ和AWQ怎么选一个看校准集一个看激活分布GPTQ和AWQ是目前最主流的两种权重量化方案很多人纠结选哪个。我的经验是看你的场景。GPTQ是基于二阶信息Hessian矩阵的逐层量化方法它通过最小化量化误差来逐列确定量化参数。优点是压缩率高INT4下精度保持得不错生态成熟各种模型都有现成的量化版本。缺点是量化过程比较慢而且对校准集比较敏感——校准集选得不好某些层的精度会掉得厉害。AWQActivation-aware Weight Quantization的核心洞察是不是所有权重都同等重要应该根据激活值的分布来保护那些重要的权重通道。它通过观察激活的幅度找出对输出影响大的权重通道对这些通道保留更高的精度。优点是精度通常比GPTQ好一点尤其是小模型上量化速度快。缺点是生态相对GPTQ没那么全。实操建议7B以下的小模型优先AWQ精度优势明显。13B到70B的中大模型两者差距不大看哪个有现成的量化权重。需要极致压缩INT3甚至INT2GPTQ的变体方案更多。校准集不管用哪个校准集一定要覆盖你的实际业务场景。用通用语料校准的模型在你的垂直领域上可能掉点严重。提示量化后的模型一定要在你的真实业务数据上做评测不要只看 perplexity。PPL掉了0.1不代表业务效果没问题有时候PPL几乎不变但某些特定任务的效果会崩。1.4 INT4量化的显存账怎么算拿Qwen系列27B模型举例算一笔实际的账。FP16下权重是27B × 2字节 54GB加上KV Cache和激活单卡80GB的A100勉强能跑但并发很低。INT4量化后权重降到27B × 0.5字节 ≈ 13.5GB加上KV Cache假设8K上下文、batch size 16大概再占10到15GB总共不到30GB一张A100就能跑得很舒服并发还能往上提。但这里有个坑INT4的group size分组大小会影响显存和精度。group size越小量化越精细精度越好但需要存储的scale和zero point越多显存占用越大。常见的group size是128如果降到64精度会好一点但显存多占一些升到256显存省了但精度可能掉。这个参数需要根据你的精度要求来权衡。另外要注意INT4量化后反量化回FP16做计算这个反量化本身有开销。如果kernel实现不好省下来的带宽可能被反量化的计算吃掉。所以选推理框架的时候要看它的INT4 kernel是不是经过优化的比如vLLM、TensorRT-LLM这些都有专门的fused kernel。2. 投机采样用一个小模型给大模型打草稿2.1 投机采样的本质是拿算力换带宽投机采样Speculative Decoding这个思路第一次看会觉得有点反直觉明明大模型已经够慢了还要再跑一个小模型不是更慢吗关键在于decode阶段是memory-bound的。大模型每生成一个token都要把全部权重读一遍但实际做的计算量很小。也就是说算力大量闲置。投机采样就是利用这些闲置的算力先用一个小模型draft model快速生成K个候选token然后让大模型一次性验证这K个token。验证的时候大模型只需要做一次前向并行处理K个位置就能判断哪些token是对的。如果小模型猜得准大模型一次前向就能确认多个token相当于把读一遍权重只生成一个token变成了读一遍权重生成多个token带宽利用率大幅提升。这就是为什么投机采样能加速——它把memory-bound的decode变成了更接近compute-bound的批量验证。加速比的理论上限是K1K个draft token加1个bonus token但实际取决于小模型的接受率acceptance rate。接受率高加速比就高接受率低大模型要频繁拒绝反而浪费算力。2.2 draft model的选择不是越小越好选draft model是投机采样最关键的一步。很多人以为draft model越小越快越好其实不是。核心指标是接受率而接受率和draft model与target model的相似度强相关。常见的搭配策略同系列小模型比如target是Qwen-72Bdraft用Qwen-1.8B或Qwen-7B。同系列模型的tokenizer和训练数据分布接近接受率通常比较高。蒸馏模型专门为某个大模型蒸馏出来的小模型接受率往往比通用小模型高。EAGLE/Medusa这类方法不走独立小模型的路线而是在大模型上挂几个额外的预测头直接预测后续token。EAGLE用特征层面的自回归Medusa用多个解码头并行预测。它们的接受率通常比独立draft model高但需要额外的训练。我的实测经验Qwen-72B配Qwen-7B做draft在通用对话场景下接受率大概在0.7到0.8加速比能到2倍左右。如果换成Qwen-1.8B接受率掉到0.5左右加速比反而只有1.5倍——因为小模型虽然快但猜得不准大模型验证时拒绝太多。draft model接受率通用对话实测加速比备注同系列7B0.7-0.8约2.0x推荐同系列1.8B0.5-0.6约1.5x小但不够准EAGLE头0.8-0.9约2.5x需额外训练通用小模型0.4-0.6约1.3x不推荐2.3 K值怎么定不是越大越好投机采样里的K是每次draft生成的候选token数量。K越大理论上一次验证能确认的token越多但接受率会随着位置往后递减——第一个token接受率最高越往后越低。K1时基本没有加速效果因为验证的开销和收益抵消了。K4到8是比较常见的甜点区。K太大比如16后面的token接受率很低大模型验证时大部分被拒绝浪费算力。实际调K的时候建议动态调整根据当前的接受率来定。如果最近几次接受率都很高可以适当增大K如果接受率低就减小K。vLLM和TensorRT-LLM都支持这种动态投机采样。注意投机采样在batch size较大时收益会下降。因为大batch下decode本身就不是纯memory-bound了算力已经被利用起来投机采样能榨取的额外算力就少了。所以投机采样最适合低并发、低延迟的场景比如单用户对话。2.4 投机采样的精度是严格无损的这点必须强调投机采样的输出分布和原始大模型是数学等价的。验证阶段的接受-拒绝机制保证了最终采样的token服从大模型的原始分布。所以投机采样不会损失精度这是它相比量化的一大优势。但有个前提验证逻辑必须正确实现。有些实现为了图快用了简化的验证策略就会破坏等价性。自己实现的时候要特别注意拒绝采样那一步的随机数生成和概率比较必须严格按论文来。3. PD分离把prefill和decode拆到不同的机器上3.1 prefill和decode的瓶颈完全不同要理解PD分离Prefill-Decode Disaggregation先得搞清楚prefill和decode这两个阶段的差异。Prefill阶段处理的是用户输入的整个prompt所有token并行计算是典型的compute-bound场景。这个阶段算力吃满显存带宽反而没那么紧张。耗时和prompt长度成正比。Decode阶段是逐token生成每次只处理一个token是典型的memory-bound场景。算力闲置带宽吃满。耗时和生成的token数成正比。问题来了如果把这两个阶段放在同一张卡上跑它们会互相干扰。一个长prompt的prefill请求进来会把decode的延迟拉高因为prefill占用了算力反过来大量decode请求在跑prefill的吞吐也会受影响。这就是所谓的prefill-decode干扰。PD分离的思路很直接把prefill和decode拆到不同的机器或不同的GPU组上各自用最适合的资源配置。prefill机器用高算力的卡decode机器用大显存的卡互不干扰。3.2 PD分离的架构长什么样一个典型的PD分离架构包含这几个部分Prefill集群专门处理新进来的请求做完整的prefill计算生成KV Cache。Decode集群接收prefill传来的KV Cache逐token生成。KV Cache传输通道prefill算完的KV Cache要传给decode节点这是PD分离的核心难点。调度器决定请求怎么分配什么时候触发KV Cache传输。KV Cache的传输是最大的挑战。一个70B模型、8K上下文的请求KV Cache大概有几个GB。这么大的数据要在节点间传输网络带宽成了瓶颈。所以PD分离通常需要高速互联比如NVLink、InfiniBand普通以太网可能传输时间比省下来的还多。传输方式有两种逐层传输prefill算完一层就传一层decode可以尽早开始。降低首token延迟但实现复杂。整体传输prefill全部算完再传。实现简单但首token延迟高。3.3 什么场景下PD分离才划算PD分离不是万能的它的收益高度依赖场景。适合的场景长prompt 短输出比如RAG、文档问答prefill占大头分离后prefill集群可以专门优化。高并发、混合负载有大量长短不一的请求分离后可以分别调度避免互相干扰。SLA要求严格需要稳定控制首token延迟和每token延迟分离后两者可以独立调优。不适合的场景短prompt 长输出prefill占比小分离的收益有限还要承担KV Cache传输开销。低并发资源本来就闲着分离反而增加复杂度。网络带宽不足KV Cache传输成为瓶颈得不偿失。我自己的经验是PD分离在大规模、高并发的线上服务里收益最明显小规模部署反而可能因为传输开销而变慢。上线前一定要做A/B测试对比分离前后的端到端延迟和吞吐。3.4 PD分离和量化的组合PD分离和量化可以叠加而且组合起来效果不错。prefill阶段是compute-bound适合用量化来提升算力利用率INT8的Tensor Core算力是FP16的两倍decode阶段是memory-bound适合用量化来降低带宽压力。但要注意prefill和decode用的量化方案可以不同。prefill可以用激进的INT8甚至FP8因为compute-bound场景对精度没那么敏感decode用保守一点的权重量化保证生成质量。这种混合精度的配置在PD分离架构下很容易实现因为两个阶段本来就跑在不同的机器上。KV Cache的量化在PD分离下更要仔细考虑因为KV Cache要跨节点传输。量化后的KV Cache传输量更小传输更快但decode端反量化有开销。这个权衡需要根据网络带宽和算力来定。4. 三项技术的组合实战与踩坑记录4.1 组合顺序先量化再投机最后PD分离如果你打算把这三项技术都用上建议的落地顺序是先做量化这是收益最直接、风险最低的一步。先把模型压到INT8或INT4把显存和带宽问题解决掉。再加投机采样在量化后的模型上加draft model进一步榨取decode阶段的性能。注意draft model也要量化否则它自己就成了瓶颈。最后上PD分离这是架构层面的改动复杂度最高放在最后做。前面两步已经把单机性能优化到位了PD分离解决的是集群层面的调度问题。这个顺序的好处是每一步都能独立验证收益出问题也容易定位。如果一上来就三个一起上性能不达标你都不知道是哪个环节的问题。4.2 踩坑一量化后投机采样的接受率暴跌这是我踩过最坑的一个。单独用INT4量化的模型精度没问题单独用投机采样加速比2倍。但两个一起用接受率从0.75掉到0.4加速比还不如不用投机采样。原因在于draft model和target model的量化误差不一致。draft model量化后输出的token分布和量化后的target model的分布对不齐导致验证时频繁拒绝。解决办法是让draft model和target model用相同的量化方案和校准集保证两者的分布尽量对齐。如果还不行draft model可以保持FP16不量化虽然它慢一点但接受率能回来。4.3 踩坑二PD分离的KV Cache传输把网络打满第一次做PD分离的时候没算清楚KV Cache的传输量。8K上下文、batch size 32的请求KV Cache加起来几十GB千兆网根本传不动首token延迟反而比不分离还高。后来换成了高速互联并且做了几件事KV Cache量化传输前压成INT8传输量减半。逐层传输prefill算完一层传一层decode尽早开始掩盖传输延迟。请求分批大batch拆成小batch传输避免单次传输量过大。调整之后首token延迟降下来了吞吐也上去了。这个坑的教训是PD分离之前一定要算清楚KV Cache的传输量网络带宽是硬约束。4.4 踩坑三动态K值的投机采样在混合负载下抖动投机采样的K值动态调整在负载稳定的时候效果很好。但线上流量是波动的K值频繁调整会导致延迟抖动。有时候K刚调大流量模式就变了接受率下降反而拖慢。解决办法是给K值调整加滞回区间hysteresis接受率高到一定程度才增大K低到一定程度才减小K中间区间保持不变。这样避免了频繁调整。另外可以按请求类型分组不同类型的请求用不同的K值策略。4.5 一个实际的配置参考最后给一个我自己在用的配置供参考。硬件是8卡A100 80GB模型是Qwen-72B服务的是通用对话场景平均prompt 500 token平均输出200 token。配置项设置说明权重量化AWQ INT4, group size 128精度和显存的平衡点KV CacheINT8长上下文场景必需投机采样同系列7B draft, K5接受率约0.75PD分离prefill 3卡, decode 5卡按负载比例分配KV传输逐层传输 INT8降低首token延迟这套配置下相比FP16基线吞吐提升了大概3.5倍首token延迟降低了40%。当然这只是个参考具体配置要根据你的模型、硬件和业务场景来调。量化、投机采样、PD分离这三项技术本质上都是在解决大模型推理的成本和延迟问题但切入点不同量化解决的是每个参数占多少资源投机采样解决的是每次前向能产出多少tokenPD分离解决的是不同阶段怎么用不同的资源。理解了这个底层逻辑具体参数怎么调、方案怎么选就有了判断的依据。真正上线的时候别指望一套配置打天下多测、多调、多对比才是正道。