量化、投机采样、PD分离这三个词最近在大模型推理圈子里出现的频率越来越高。不管你是做模型部署、推理服务优化还是单纯想把显存占用降下来、把响应速度提上去这三项技术基本是绕不开的进阶功课。这篇内容我结合自己的调优经验和社区里的一些实践把原理和实操一起拆开讲尽量让刚接触这块的人也能有个清晰抓手。1. 内容整体设计与思路拆解1.1 为什么推理加速会成为大模型落地的核心瓶颈模型训练好之后真正决定用户体验的是推理侧的延迟和吞吐。大模型在生成场景里每个Token都需要经过一次完整的前向计算模型参数量动辄几十亿上百亿显存带宽和算力消耗都非常可观。更麻烦的是生成过程是逐Token串行的前面没算完后面没法开始所以推理耗时直接和序列长度、并发请求数挂在一起。训练侧可以堆卡、可以等但推理侧面对的是真实用户延迟超过一两秒就会明显影响体验。因此如何在不显著降低生成质量的前提下把推理延迟压下去、把吞吐提上来就成了工程落地最核心的命题。我个人的理解是推理优化本质上是在算力、显存、带宽、延迟之间做权衡。量化主要解决显存和带宽瓶颈投机采样解决串行生成带来的算力空转问题PD分离则是从架构层面解决并发混杂场景下的资源争抢问题。三条路方向不同但最终目标一致让模型跑得更快、更省、更稳。这三项技术虽然看着是独立的方向实际组合起来效果才会最大化。我建议学习路径按照“先量化再投机采样最后PD分离”的顺序走量化是基础先把资源的账算明白投机采样是策略层解决单请求的生成效率PD分离是架构层解决整体系统的调度和利用率问题。1.2 从资源、延迟、吞吐三个维度理解加速的本质加速这件事首先要搞清楚你到底在优化什么指标。不同业务场景关注的指标完全不一样在线对话类产品最看重首Token延迟和单Token延迟用户希望越快看到反馈越好。离线批量处理场景比如数据标注、知识库批量生成更看重吞吐量希望单位时间内跑完的样本越多越好。混合场景比如既有实时交互又有批量任务就需要调度层面的精细化管理单纯压延迟或单纯冲吞吐都不够。量化主要解决的是“资源不够”的问题。模型参数量太大显存放不下或者带宽不够导致计算单元饿肚子这样即使算力再强也发挥不出来。把权重从FP16压到INT4或者INT8显存占用直接砍半甚至砍到四分之一加载和计算的数据量同步下降延迟和吞吐都会受益。投机采样解决的是“算力空转”的问题。自回归生成的每一步都得等上一步的结果GPU在等待期间并没有真正满负荷工作。投机采样让一个更小更快的草稿模型先猜几个Token主模型一次性验证多个Token等于把串行的等待变成了并行的验证吞吐提升非常明显。PD分离解决的是“资源争抢”的问题。不同请求的输入长度和输出长度差异很大混在一起跑的时候有的请求还在啃长输入前缀有的已经在快速吐Token互相干扰导致GPU利用率忽高忽低。把预填充和解码拆到不同的实例或进程上各自用各自合适的资源整体效率和稳定性都会好很多。1.3 明确优化边界什么场景该用哪种方案不是所有场景都需要把三种技术全上。项目动工前先算一笔账避免过度优化带来不必要的复杂度。如果你的显卡显存比较紧张模型本身能跑起来但很勉强应该优先做量化。比如一张24G的卡想跑70B模型不量化基本没戏INT4量化之后勉强能塞进去虽然速度不一定快但至少能跑。如果你的显存充足但生成速度感觉明显低于理论算力瓶颈大概率在自回归的串行依赖上这时候投机采样收益最大。草稿模型选得好加速比能到2到3倍而付出的额外显存成本很小。如果你服务的是高并发线上业务请求长短参差不齐表现为GPU利用率上不去、延迟波动大那PD分离是更根本的解法。把不同计算特征的请求分到不同节点资源利用率和响应稳定性都会有明显改善。这三条路不是互斥关系实际生产里通常是量化打底然后按业务特征决定加不加投机采样、要不要拆分PD。2. 核心细节解析与实操要点2.1 模型量化原理、主流路线与参数选择量化本质上是把连续的浮点数值映射到有限的离散整数空间。大模型推理里最常见的是把FP16的权重转成INT8或者INT4。为什么有效因为推理时的计算瓶颈往往不在算力FLOPS上而在显存带宽上。每个Token都要把全部权重从显存搬到计算单元数据量越大等待时间越长算力再强也只能干等。量化把每个权重从2字节变成1字节或0.5字节带宽压力直接减半甚至减75%计算效率自然就上来了。实操里常见的量化方案分两大类。一类是训练后量化PTQ模型训完直接转不需要额外训练数据或只拿少量校准数据跑一下实现简单、部署快是目前的主流。另一类是量化感知训练QAT在训练阶段就把量化误差纳入考虑精度保留更好但要重训或微调模型成本高普通业务场景很少用。PTQ里比较有代表性的方案社区公认的主要是GPTQ和AWQ。两者都能把模型压到INT4精度损失在可接受范围内。GPTQ基于近似二阶优化做逐层量化对激活值分布比较敏感校准数据集选好了效果很稳。AWQ的思路是分析各通道的激活值重要性按重要程度分配不同的量化缩放系数不需要重训校准成本更低在指令微调模型上表现经常比GPTQ略好。选择上我个人的建议是有充裕的校准数据和时间用GPTQ追求部署简单和泛化性AWQ更顺手。量化参数选择有两个关键点。一是量化位宽INT8和INT4各有各的适用场景INT8精度损失几乎可以忽略速度提升有限INT4显存节省明显但某些任务上质量回退会比较明显尤其代码生成和数学推理类任务。二是分组大小也叫group size。group size越小量化粒度越细精度保留越好但存储开销和反量化计算成本也会上升。128是平衡点64精度更好256更省显存。关于量化有一条容易纠结的K位要和各位强调一下量化精度的损失在长文本生成和高难度任务上会被放大如果你的业务对输出质量要求很高建议先做INT8观测效果满意了再跳INT4别一上来就追求极端的显存节省。2.2 KV Cache量化显存优化的隐藏大头很多人做量化只盯着权重忽略了KV Cache。大模型推理过程中每生成一个Token都要把历史Token的Key和Value缓存下来供后续计算用。序列越长并发越多KV Cache占用的显存就越大。实际生产里长上下文场景下KV Cache消耗的显存常常超过权重本身成为GPU显存的第一大头。KV Cache量化就是把缓存里的Key和Value也压到INT8或者更低。因为KV Cache在生成过程中被反复读取压缩后能显著缓解显存压力从而支持更长的上下文和更大的并发批次。现在主流的推理框架比如vLLM、TensorRT-LLM都已经原生支持KV Cache量化打开开关就行不需要额外改造模型。实操里KV Cache量化要考虑两个点一是量化位宽选择INT8基本是无损的INT4显存更省但偶尔会有质量波动二是量化策略有的是按Token动态量化有的是离线统计好缩放系数具体看框架实现。我实测下来的感觉是KV Cache量化INT8的综合收益非常高基本零成本换显存强烈建议默认开启。INT4则建议在同一条数据上做A/B评测后再决定要不要上。2.3 显存计算与配置推演做量化之前先学会算显存账。以13B模型为例FP16权重占13乘2约26GB显存INT8降到13GBINT4只需要约6.5GB。但这个只是权重的占用推理运行时还得叠加KV Cache和激活值开销以及推理框架本身的预留显存。一个粗略的估算公式可以参考[ 总显存 \approx 模型权重显存 KV Cache显存 激活值显存 预留缓冲 ]KV Cache的预计公式大致是KV显存 2Key和Value × 层数 × 隐藏维度 × 最大序列长度 × 并发数 × 每个元素字节数。这串数值实际算下来会相当惊人。举个例子13B模型通常有40层、隐藏维度5120如果最大支持4096长度、同时处理8个请求在FP16下KV Cache就占2乘40乘5120乘4096乘8乘2再除以1024的三次方算下来大约40GB比模型权重本身还大得多。这也是为什么长上下文场景显存总是不够用的根本原因。量化之后权重和KV Cache同步下降显存压力大幅缓解。这就是为什么宽量化和高并发、长上下文本质上是绑定关系——不量化KV Cache就把显存吃光了根本谈不上高并发。2.4 投机采样的原理与草稿模型选择投机采样的逻辑用一个比方解释最清楚你在看一篇文章准备翻译旁边有个实习生帮你先把草稿写出来你只需要扫一眼对的地方直接过错的地方改掉就行。实习生写得越快、越准你的整体效率就越高。大模型推理里的实习生就是草稿模型负责快速猜测接下来的几个Token主模型原本需要一步步等现在一次性验证多个Token得等的时间大大缩短。理论上如果草稿模型输出的每一段都和主模型一致那投机采样能直接把生成速度提升接近草稿模型与被验证次数的倍数关系。实际场景中草稿模型的准确率通常不是100%主模型验证后总有一部分被拒绝需要主模型自己重新生成因此实际加速收益会有折扣。草稿模型质量越高拒绝率越低收益越接近理论上限。草稿模型怎么选直接影响投机采样的效果。规模化使用后我个人的观察是同一个模型的量化小版本比如13B主模型配6B量化版草稿容易形成风格一致的效果拒绝率低整体效果最稳。原生小模型比如6B或7B模型直接拿来做草稿需要额外加载一组权重显存成本由项目预算决定。基于N-gram的检索式草稿不做神经网络推断完全靠历史文本里的统计规律猜Token在重复性较高的代码生成和模板化内容上效果意外地好。选择草稿模型的核心指标是拒绝率和草稿速度的平衡。草稿模型太弱猜的Token大部分被拒等于多跑了一次无效的前向草稿模型太强又失去了“快”的意义草稿的成本可能抵消验证的收益。一般建议拿一小批业务数据进行实测让草稿模型与主模型的Top-1一致率在一个可控范围内。关于投机采样的几个参数也顺带提一下草稿长度这个参数控制草稿模型单次最多生成几个候选Token推荐值通常在4到8之间太小乘数效应不明显太大浪费算力温度参数需要同步调整温度越高输出越随机草稿模型的命中率会显著下降建议应用投机采样时把采样温度控制在合理区间内能显著减少被拒数量修正策略则建议采用保守的验证截断策略碰到拒绝点时立即回退而不是用复杂策略更激进地赌后续内容。2.5 PD分离为什么要把预填充和解码拆开PD分离指的是Prefill和Decode分离。一个请求进入推理系统后前面处理输入前缀的阶段叫预填充阶段计算密集、访存相对少适合一次性大批量打满算力后面逐个生成Token的阶段叫解码阶段每步计算量小但访存需求高适合把多个请求拼在一起提高吞吐。传统架构里这两个阶段混在同一块GPU上执行很容易出现资源冲突。想象一个场景GPU正在处理一个长文档的预填充算力吃满、显存带宽需求很小此时其他用户的解码请求还在排队等算力等预填充结束了好不容易轮到解码又来一个长输入请求抢占资源。结果就是两个阶段相互拖累GPU利用率波动剧烈延迟的表现也不稳定。PD分离把这个混跑模式改成拼跑模式预填充请求统一送到专用的预填充实例上处理解码阶段则交给专门负责解码的实例。两者之间通过缓存和通信机制协作长输入请求不再拖慢在线解码大量并发请求的吞吐稳定性也能得到保障。PD分离的优势在实际部署中体现在几个层面预填充实例可以把算力拉满处理大序列的耗时显著缩短解码实例集中处理短Token级计算批量调度的效率更高长请求和短请求各自走各自的通道延迟的稳定性明显变好。代价是需要额外的机器和网络通信开销架构复杂度也上了一个台阶通常适合并发量较高、延迟要求严格的线上业务场景。2.6 PD分离工程细节缓存复用与调度策略PD分离的实现难点不在算法而在工程协调。关键有三块第一块是KV Cache的传递。预填充阶段算出来的KV Cache要传给解码实例直接走网络传输的话数据量非常大延迟和带宽都扛不住。现在主流的做法是共享显存或者用本地高速缓存让两个阶段的KV Cache放在都能访问的地方避免重复计算和搬运。第二块是调度策略。预填充实例跑得快解码实例跑得慢两者之间天然存在速度差。如果调度不做控制预填充实例会不断产出任务塞给解码实例导致解码队列积压延迟反而恶化。常见的做法是做带速率控制的调度预填充实例只负责产出KV Cache解码实例按自身的吞吐节奏消费队列长度保持在合理水位。第三块是数据一致性。两端可能存在不同批次的请求交错需要额外的跟踪和同步机制来保证请求与生成结果的对应关系准确。这部分虽然看起来不起眼但排查起来比较费劲建议项目一开始就把请求ID治理做好。PD分离的拆分配置也会直接影响效果。常见的模式包括按层切分、按请求类型切分和按时间窗口弹性切分。按层切分是指将模型的不同Transformer层分到不同实例上先训的所有层算完再交给后续层继续算适合追求极致吞吐的离线场景按请求类型切分更通用在线实时类请求走一体式通道批量长任务走PD分离通道弹性切分则根据业务流量自动调整资源配比适合流量波动的业务。个人实践中按请求类型分和弹性切分是两条最值得优先尝试的路线。3. 实操过程与核心环节实现3.1 量化实操全流程与踩坑记录以当前比较主流的推理框架跑量化模型为例实操流程大致分这么几步。第一步选基座模型和量化工具。如果追求部署简单推荐直接从模型库找已经量化好的版本社区生态基本成熟很多知名模型都有现成的INT8、INT4版本可下载。如果需要自己量化推荐的工具路径是AWQ或GPTQ仓库做量化再用推理框架加载推理这套组合的通用性最强。第二步准备校准数据。校准数据集不是随意的需要贴近模型的实际使用场景。比如做一个代码生成服务就找一批代码片段做校准做客服问答就找一批真实对话语料。数据集规模不用很大几百条到上千条就够但要保证覆盖常见输入分布。第三步执行量化。以AWQ为例在命令行里指定模型路径、校准数据集路径、量化位宽和分组大小跑完会自动产出量化后的模型权重。实测大概几十分钟到几小时不等取决于模型大小和硬件条件。第四步加载量化模型并验证。加载到推理框架后直接跑一批测试请求观察两件事生成内容的质量是否达标显存占用是否符合预期。这里特别提醒一个容易踩的坑校准数据的风格如果和真实业务数据差距很大量化后模型在真实场景里的表现会明显变差。比如你用通用文本做了校准上线时却发现很多代码生成请求这时候量化误差会被放大输出质量和速度都会受影响。务必让校准数据的分布贴近线上真实请求。顺便提醒一个测试时的常见错觉本地单卡测试和线上多卡并发量化的显存收益一样但延迟收益的体现方式不同。单卡测试主要看单个请求变快多少多卡并发则要看同等显存下能塞进多少并发请求、吞吐量提升多少。如果只看单卡延迟INT8和INT4的差距可能不大但在线场景在乎的往往是同一块卡能扛住的并发量。3.2 投机采样参数调配实例投机采样的部署关键是把几个核心参数调到位。这里给一个我用过的参考配置主模型13B草稿模型建议选一个同源体系的6B量化版本。草稿长度建议从4开始测先用默认采样温度观察拒绝率和加速比接着按0.1步进调整温度并观察变化最后逐项对比不同参数组合下的整体生成耗时、每Token延迟和首Token延迟。实操中发现一个有意思的规律草稿长度翻倍并不等于加速翻倍因为草稿模型生成多个Token时前几个Token的准确率高越往后越容易跑偏。草稿长度从4调到8加速收益可能只有10%到20%但草稿模型自身多花了将近一倍的算力在做无效生成。比较合理的做法是拿一小批业务数据实测画出草稿长度与加速比的曲线找到收益开始平缓的拐点。投机采样和量化有很好的协同效应。量化主模型之后显存占用下降了多出来的空间正好能放一个草稿模型而且两者本身的部署成本都不高。量化后再上投机采样等于在带宽优化和等待优化两个维度同时发力综合加速效果经常能突破单一手段的极限。3.3 PD分离的部署形态与链路观察PD分离的部署和推理框架的支持程度关系很大。当前主流的推理框架都已经有PD分离的雏形或成熟方案业界也有一些独立网关组件在做预填充和解码的路由。实操中PD分离的链路要观察的指标和传统一体式架构略有不同网关耗时指标反映了请求路由的效率预填充耗时指标反映了大输入请求的处理速度解码耗时和排队长度指标则反映了解码实例的繁忙程度。各段指标分开看才能准确定位瓶颈出在哪一环。部署PD分离最常见的入门路径是先用两台机器跑通小规模链路观察各段耗时和队列情况再逐步调整实例配比。需要留意的是一体式架构搬到分离架构后网关会成为一个潜在的单点瓶颈如果请求量很大网关自身的转发能力要做压测。一个比较实用的观察经验是如果在监控里看到解码队列长时间积压说明预填充生产能力大于解码消费能力这时候先别急着加解码实例先看解码实例的调度是不是有问题反过来如果预填充耗时很长说明预填充实例的算力不足再加解码实例也解决不了源头问题。这类问题在分离架构里很容易定位因为各段指标分得比较清楚。3.4 多技术组合优化的推荐配比三种技术单独跑完一轮之后组合使用才是生产环境的真正考卷。我整理了一套自己实践中比较顺手的配置流程优先开量化打底权重和KV Cache双INT8起步先把显存占用的压力和带宽压力降下来。紧接着根据显存余量和业务需求决定要不要把权重再降到INT4。然后评估是否适合投机采样判断依据主要是业务的生成延迟是否还有明显优化空间以及显存里放不放得下草稿模型。最后看并发量和延迟要求决定要不要拆PD分离。同样的硬件条件下三项全开比只开量化大约有2到3倍的端到端收益代价是系统复杂度明显上升定位问题的门槛也会变高。所以我的建议是量化必须做投机采样按需做PD分离在流量和稳定性要求都具备条件时再做。4. 常见问题与排查技巧实录4.1 量化精度损失严重怎么定位是哪个环节出的问题一旦发现量化后的模型输出质量明显下降先别急着换量化方法按照这个顺序排查。先确认是不是校准数据的问题。校准数据的分布如果和业务分布脱节误差会被放大这是最常见的原因。解决办法是换一批更贴近真实业务的数据重新校准通常就能把精度拉回不少。然后检查分组大小的设置。256的组大小比128更激进精度损失也会更大如果你的业务对质量要求高改回128或64试试。再看是不是INT4本身不适合这个任务。代码、数学这类对Token精度极其敏感的任务建议先用INT8压一遍看效果再决定是否继续压。如果是KV Cache量化引入的质量问题可以尝试只对权重量化、KV Cache保持原精度或把KV Cache量化位宽调高一档通过组合测试排查出具体是哪一块压坏了。4.2 投机采样加速不明显甚至变慢大概率出在这几个地方真正动手调投机采样后会发现收益不及预期是常态反而不加速甚至变慢的情况也不少见。优先检查草稿模型的输出分布和主模型差多远一致性太差的话验证时大部分草稿Token都会被拒绝等于白白多跑了一轮前向计算。这时候提高草稿模型质量比继续调参划算。再看草稿长度是不是设得太大。超过一定阈值之后后面的Token基本是乱猜拉了整体加速的后腿。实际调试时建议从小值开始逐步往上加找到收益拐点。最后也要关注采样温度。温度偏高会导致输出随机性变大草稿命中率会明显下降投机采样的适用前提是生成过程具有较好的确定性。如果以上三个方向都排查过还没改善直接关掉投机采样回到量化和调度上的优化不必一开始就硬上所有技术。4.3 PD分离上线后延迟反而变高了先查通信和调度PD分离不是银弹拆不好确实会出现延迟不降反升的情况。最常见的坑是预填充实例到解码实例之间的KV Cache通信开销太大尤其是跨机跨节点部署时传输时间可能直接吃掉拆分带来的收益。先用任意形式把KV Cache传递的耗时测清楚再决定要不要调整部署拓扑。第二个常见问题是调度策略配置不当。预填充实例一直在生产任务解码实例消费不过来队列越堆越长。这时候把调制策略改成分批拉取或者带缓冲池的消费模式让解码侧按自己的吞吐节奏消耗通常能缓解积压问题。第三个问题是慢请求被漏掉了。PD分离后更要关注长尾请求的调度建议给网关加超时和优先级机制避免个别慢请求把后面一串请求都堵死。4.4 常见问题速查表问题现象优先排查方向建议解法量化后质量明显下滑校准数据与业务分布不一致换贴近业务的校准集重跑校准同一位宽下显存不降反升KV Cache未量化开销占大头打开KV Cache INT8量化投机采样加速比远低于预期草稿模型和主模型差异过大换同源小模型或调低草稿长度投机采样偶发性变慢采样温度过高、拒绝率升高调低温度限制草稿长度PD分离后整体延迟变高KV Cache跨机传输开销过大改成共享显存或本地高速缓存PD分离后解码队列积压调度策略不匹配增加消费侧批量拉取机制线上偶发超时网关或调度单点瓶颈引入请求优先级和超时降级机制5. 综合优化效果复盘5.1 一个端到端的优化案例记录拿一个实际场景来串一遍。一个13B对话模型在单张24G卡上部署上下文长度4096并发8个请求原始FP16权重加KV Cache的情况下显存已经非常吃紧生成速度也不理想。第一步开量化权重和KV Cache都压到INT8显存占用大幅下降单Token延迟明显变快质量基本没损失。第二步尝试投机采样挂一个6B同源量化小模型做草稿模型草稿长度调到6采样温度调低到0.5附近拒绝率控制在合理范围内单请求生成延迟又进一步缩短。第三步看整体负载情况8个并发下GPU利用率已经比较稳定暂时没有继续拆PD分离的必要留给后续流量增长时再考虑。这套组合下来从原始FP16到量化加投机采样单请求生成延迟大约降了60%左右显存占用降了接近一半同时还有余量可以继续加并发。实际效果因模型和业务略有不同但这个量级的收益在类似组合下是正常水平。5.2 不同硬件配置下的调整策略硬件的差异对优化策略的选择影响非常大。在单卡玩家的小显存环境里量化和KV Cache优化是必做的投机采样则要看显存余量再决定因为草稿模型也要占显存。在多卡环境下如果追求单请求最低延迟量化和投机采样为主PD分离作用不大如果目标是高并发线上服务PD分离的价值会凸显出来配合量化能压出非常可观的吞吐提升。具体到笔者自己的实践体会最难的不是把某一项技术跑通而是判断当前场景到底该在哪个维度上用力。显存不够就做量化延迟卡脖子就试投机采样并发一高就上PD分离。这个判断过程是需要反复拿数据说话的不是拍脑袋能定的。在真实项目里我踩过几次坑之后最大的感受是别迷信单一技术的加速倍数也别一开始就把三个技术全堆上。先量化打底再按业务特征逐步叠加每一步都用线上数据验证收益。这个流程虽然看起来慢但最终得到的系统性能和稳定性都明显更扎实。另外和模型效果负相关的那些量化激进策略比如极端位宽和过小的分组大小建议用完整的评测集把关之后再进生产环境。