量化、投机采样和PD分离这三板斧几乎覆盖了当前大模型推理优化从算法到工程的几个最关键层面。这篇文章我结合自己实际部署和调优的经验把这三个方向的核心原理、落地方法和踩过的坑一次说清楚希望能帮到正准备系统性学习推理加速的朋友。1. 整体设计思路推理慢的瓶颈到底在哪在做任何加速优化之前得先想明白一个问题大模型推理的时间到底花在哪里了不了解瓶颈就上手优化大概率是瞎忙。我刚开始接触这方向时也走过弯路对着网上的奇技淫巧一顿操作结果收益甚微。后来才意识到推理加速这件事必须按“内存带宽、计算效率、资源利用率”这三个维度去拆解。1.1 从一次请求的完整旅程看延迟构成一次普通的大模型请求从用户输入到最后吐出一个字一个字的回复内部其实经历了两个物理性质完全不同的阶段。第一个阶段叫Prefill预填充也就是把用户输入的整段Prompt一次性喂给模型并行计算所有输入token的注意力结果生成对应的KV Cache。这个阶段的特点是计算密集compute-boundGPU的算力利用率往往能跑到80%以上瓶颈在GPU矩阵乘法的吞吐能力。一个512字的PromptPrefill通常只需要几十毫秒到几百毫秒。第二个阶段叫Decode解码也就是模型一个一个地自回归生成输出token。每生成一个token就要把之前所有token的KV Cache从头到尾读一遍同时只计算当前这一个token的注意力。这个阶段的特点是访存密集memory-boundGPU的算力利用率往往惨不忍睹可能只有10%到20%大部分时间都花在从HBM高带宽显存往计算单元搬运数据上。我给一个直观的数字一张A100 80GB的卡在跑7B模型解码时实测生成速度大约只有30到50 token/s瓶颈几乎全在显存带宽。理解这两个阶段的本质区别你就能明白为什么业界会提出PD分离这种架构——既然Prefill和Decode的瓶颈物理资源不同就让不同的机器干不同的活而不是让一台机器同时被两种瓶颈拖累。这也是为什么很多人说推理优化第一步不是上工具而是先建立对性能模型的理解。1.2 三个技术方向分别解决什么问题量化、投机采样、PD分离恰好分别对应了我在开头说的三个维度。量化解决的是“搬运太多数据”的问题。模型参数和KV Cache都保存在显存里每次解码都要反复读。如果能把参数从FP1616位浮点数2字节压到INT44位整数0.5字节理论上来讲需要搬运的数据量直接降为原来的四分之一解码速度的上限就能大幅提升。同时更小的显存占用意味着同一张卡能塞下更大的模型或更大的并发。投机采样解决的是“串行生成太慢”的问题。想象一下每次只生成一个token8000亿参数的大模型就得从头到尾跑一次前向计算这实在太浪费了。投机采样的思路是先用一个又小又快的小模型一次性草拟出未来5到10个token然后让大模型一次性验证这整批token对不对。如果验证通过了一半那一大步就把“生成半个token”的工作量省下来了。相当于用一份计算成本换取了多步生成结果吞吐量自然就上去了。PD分离解决的是“资源配置不合理”的问题。前面提到Prefill吃算力、Decode吃带宽如果有一台服务器同时承接两类请求就会出现资源抢占高并发的Prefill请求会把算力占满导致Decode阶段的token生成速度骤降。PD分离的做法是把Prefill和Decode部署到不同的GPU上通过高速网络在两者之间传递KV Cache让每类硬件的特性都物尽其用。算力强的卡专心做Prefill带宽大的卡专心做Decode各干各的活整体吞吐能提升一到两倍。顺带解释一下搜索热词里一直出现“量化交易”的原因。在金融领域量化的意思是“用数学模型代替人来做交易决策”核心是数字建模和策略回测。而在AI推理语境下量化Quantization指的就是“降低模型参数的数值精度用更少的比特去近似原来的浮点数”。这个词在不同语境下含义完全不同这篇文章里说的全都是后者别混淆了。2. 量化加速原理、主流方案与实操参数量化是大模型推理加速里门槛最低、见效最快的一个方向也是很多人在生产环境做的第一项优化。但它的细节非常多同样是INT8有的方案掉点严重有的方案几乎无损差一步可能就差很多。2.1 量化的本质用更少的位数表达参数要理解量化先理解大模型参数的存法。FP16半精度浮点数用16个比特表示一个数其中1位符号、5位指数、10位尾数。这个范围对于神经网络里的权重参数来说是绰绰有余的因为训练好的模型权重通常分布在很窄的区间内比如 [-1.96, 1.96]。量化的核心操作就是映射。假设我们要把一个浮点数范围 [-a, a] 映射到整数范围 [-127, 127]只需要用一个缩放因子scale把浮点数除以scale再四舍五入取整就得到了对应的INT8整数。反量化的时候用整数乘以scale就能恢复一个近似的浮点值。这里面丢掉的信息就是取整时的那些小数尾巴。INT8量化后模型体积直接减半4字节变1字节推理时GPU显存带宽压力也减半decode吞吐理论上能翻倍。而INT4量化更激进把每个参数压缩到4个比特体积再减半。不过INT4因为精度太低业界普遍会配合分组量化Group-wise Quantization来用不是把整个权重张量用一个scale而是每128个元素共享一组scale和zero point这样量化误差受局部数值分布的影响就小得多。GPTQ和AWQ这两个主流方案的核心思想都是为了让4比特量化后的误差降到可接受的范围。2.2 GPTQ、AWQ、GGUF怎么选现在的量化方案主要是分两派训练后量化PTQ和量化感知训练QAT。大模型因为重新训练代价太高基本都是走PTQ路线。GPTQGenerative Pre-trained Transformer Quantization是目前最经典的训练后量化方法。它的思路是用二阶近似Hessian矩阵来逐层补偿量化误差量化完一列权重后会顺手把误差“推销”到后面未量化的列上让整体误差更小。GPTQ主要针对GPU部署vLLM等推理框架原生支持。AWQActivation-aware Weight Quantization的思路和GPTQ完全不同。它观察到权重的重要性并不平均少数对激活值影响极大的关键通道需要保留高精度。AWQ通过分析激活值的分布找出一小部分对模型输出影响最大的通道在量化时专门给它们更高的精度占比。实测下来AWQ在同等压缩率下尤其是在小模型7B级别上的表现往往比GPTQ略好但推理框架的支持成熟度略逊一些主要靠TensorRT-LLM和部分定制内核来跑。GGUF则是另一条赛道它主要面向CPU和苹果M系列芯片配合llama.cpp使用。GGUF在算法精度上不一定比GPTQ强但它胜在封装形式灵活支持2到8比特的多种量化档位且能快速做跨平台的CPU推理。如果你主要在消费级显卡或CPU上跑模型GGUF是首选如果生产环境用A100/H100跑服务那还是GPTQ和AWQ更主流。那么实际该选哪个我的经验是看三件事部署框架、模型权重是否容易获取、以及容忍的内存占用。生产场景优先无脑选你推理框架官方文档里最亲的那个方案vLLM推GPTQ和AWQTensorRT-LLM推FP8和INT4不要自己瞎配不熟的框架否则内核不匹配性能反而更差。2.3 量化落地实操从量化到部署的完整步骤我以vLLM框架搭配GPTQ为例给出一个可以直接复制的实操流程。第一步选基座模型。尽量选原生FP16即原始精度的模型权重不要选别人已经量化过的版本反复量化误差会累积。第二步量化。可以用AutoGPTQ库直接加载FP16模型并量化保存成GPTQ格式权重也可以去HuggingFace下载别人量化好的现成权重。量化时主要调两个参数bits4或8和group_size128。刚开始建议用8比特跑一遍验证流程无误再上4比特因为4比特的精度恢复对参数更敏感。第三步部署到vLLM。一个典型的启动命令是python -m vllm.entrypoints.openai.api_server \ --model /path/to/quantized_model \ --quantization gptq \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1这里的gpu-memory-utilization设为0.9意味着允许vLLM使用90%的显存剩下10%留给CUDA上下文和KV Cache碎片。如果设为0.95甚至更高大概率会OOM别贪心。第四步做精度回测。这是最多人忽略的步骤。跑量化模型之前先把原版FP16模型在同一批测试集上的输出记录下来作为基线然后对比量化模型的输出差异。建议用困惑度Perplexity和几个代表性下游任务常识问答、代码生成、数学推理作为评估维度。如果ppl暴涨超过0.5或者下游任务掉点超过3%就该考虑换量化粒度或改用AWQ。2.4 KV Cache量化不可忽视的显存救星很多人只量化模型权重但KV Cache才是推理时显存的大头。一个7B模型FP16权重占约14GB而一个长度为4096、batch为16的请求序列其KV Cache可能额外吃下好几GB甚至几十GB显存。高并发的服务里KV Cache往往比权重更占地方。KV Cache量化的原理是把缓存里存储的Key和Value张量从FP16压缩到INT8有的方案甚至压缩到FP8。由于KV Cache的量化误差只影响当前这次请求的注意力计算不像权重量化那样影响全局所以可以用更小的组大小甚至per-token动态量化来降低误差。vLLM在新版本里已经内置了KV Cache的FP8量化开关设置环境变量VLLM_KV_CACHE_DTYPEFP8即可。实测在8比特下模型精度几乎无损而显存占用能下降约15%到25%。如果你用的是H100H100支持FP8的硬件加速这个开关基本就是免费送的。如果是A100FP8虽然能在软件层模拟但收益就不如H100那么明显了。实操起来有个经验先把模型权重量化做完再评估显存余量最后决定要不要再压KV Cache。两个一起上可能造成误差叠加有些任务会突然掉点。稳妥的做法是先单独开KV Cache量化跑一遍回测再决定是否保留。3. 投机采样让小模型先把话说完投机采样是我在生产环境里实测提升最明显、但同时也是坑最多的一项技术。它的基本思想听起来有些反直觉让一个更小更弱的草稿模型先写句子再让大模型去校对。但为什么这样反而更快3.1 为什么“先猜再校验”反而更快要理解投机采样的加速比得回到大模型自回归生成的根本矛盾每生成一个token都必须做一整轮前向计算但这个前向计算里计算每个token的开销是不变的你不能因为“下一个token更容易预测”就跳过计算。投机采样利用的正是“有些token很容易预测”这个特点。比如你让模型接着写“床前明月光疑是地上”几乎任何模型都能比较准确地猜出“霜”。既然如此为什么不让一个成本低廉的草稿模型一次性连猜10个token然后让大模型用一次前向计算同时验证这10个token的置信度如果其中6个token的概率都高于采样阈值那就相当于用“跑一次大模型”的成本换来了6个token的产出解码阶段的有效速度直接翻了好几倍。学术界管这个方法叫“推测解码”Speculative Decoding它有两类主流的实现路径一类是让同体系的更大模型配合一个小模型使用针对于当前任务微调得到的草稿模型另一类是让同一个模型复用自己浅层的输出作为草稿例如EAGLE方法可以理解为不需要外部小模型而是用模型自己在前几层的计算先给出粗预测。3.2 草稿模型的选型和加速比预估投机采样的加速效果很大程度上取决于草稿模型的质量和速度。草稿模型和目标模型之间的“能力gap”不能太大草稿模型太笨导致猜中的比例太低大模型频繁拒绝这时候投机采样反而会降低吞吐因为验证失败后你还得重新采样白白多跑一次计算。我的工程经验是草稿模型和目标模型的参数量比值控制在1/30到1/10之间。比如7B目标模型用0.5B到1B的草稿模型13B目标模型用1B到3B的草稿模型。草稿模型生成token的延迟必须远小于目标模型生成一个token的延迟否则加速比就趋近于1。理论加速比的估算方法很简单假设草稿模型一次性能猜中n个token中的k个那么总耗时约为“草稿模型的n次前向时间 大模型的1次前向时间”而“被接受的k个token”是有效产出。所以有效加速比约等于k除以n乘以草稿模型与大模型的单token耗时比再加1。实操跑下来典型的加速比数据是当接受率在50%到60%时1B草稿配合7B目标模型总体解码速度能提升约1.8到2.5倍。这里注意一个反直觉的点草稿长度不是越长越好。草稿太长虽然理论上给了更多“命中”的机会但大模型验证阶段的计算成本线性增长而接受率却随着位置越靠后衰减越快。实测草稿长度取4到8个token收益最大取16以上收益就开始暴跌了。3.3 投机采样的工程实现与配置细节如果你用vLLM投机采样已经内置了支持。关键配置参数有三个--speculative-config指定草稿模型、--num-speculative-tokens草稿长度、--speculative-max-model-len草稿模型的序列长度限制。一个典型启动命令是python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3.1-8B-Instruct \ --speculative-config {model: meta-llama/Llama-3.1-8B-Instruct-Tiny} \ --num-speculative-tokens 5 \ --max-model-len 8192注意这里的关键坑草稿模型和目标模型必须使用同一个词表否则token id对不上投机采样直接失效。Llama系列的Tiny版本和原版就是同一个词表所以可以配。但如果你自己找一个词表不同的0.5B模型去配验证阶段会全部拒绝性能不升反降。还有温度参数的问题。投机采样在贪心解码temperature接近0时效果最佳因为这时候草稿模型的预测和大模型的argmax结果一致性最高。如果温度调高到0.8甚至1.0输出的随机性增大草稿模型的命中率会显著下降加速效果大打折扣。所以如果你的业务必须高温度采样投机采样的收益就不是那么理想了。3.4 投机采样的常见陷阱投机采样最大的一个隐形陷阱是显存翻倍。草稿模型虽然小但依然需要额外占一部分显存。我在A100上跑13B模型时加上一个2B草稿模型显存占用直接多了约4GB。如果你的GPU本来就很紧张投机采样根本没有施展空间可以先考虑量化。第二个陷阱是过高的草稿模型质量。草稿模型如果训练得过于接近目标模型它每token的延迟会变大。设想极端情况草稿模型和目标模型一样大你等于每次都跑了两遍大模型哪怕接受率100%有效吞吐也只有原来的一半。所以草稿模型的核心指标不是“准不准”而是“单位时间的有效命中数”。第三个坑是序列级别的投机采样可能导致生成长度的抖动。因为被接受的token数量不稳定每次迭代产出的token数不一样服务的逐token延迟会出现肉眼可见的波动。对延迟敏感型业务比如流式对话这种抖动可能影响用户体验。解决办法是在服务端做输出缓冲攒够一定数量的token再一起返回给用户。4. PD分离把算力和带宽各归其位PD分离是最近两年大模型推理架构里最热的方向这名字听起来很高大上但本质思想非常朴素让懂算力的去算让懂带宽的去读各司其职。但落地起来远比想象的复杂。4.1 为什么需要把两阶段拆开前面已经解释过Prefill阶段是计算密集Decode阶段是访存密集。传统部署方式是将两者放在同一张GPU上问题在于这两种请求会互相干扰。举个例子某台GPU正同时在处理8个并发请求的decode阶段每个请求都在大量读取KV Cache此时来了一个包含长文档的新请求需要做巨大的Prefill计算。这个Prefill计算会把GPU的算力占满导致正在进行的decode阶段全部变慢。等Prefill算完decode恢复又需要时间。也就是说一个长提示词请求的到达可能会让所有正在流式输出的请求集体卡顿几十毫秒。这在交互型业务里是非常糟糕的体验。PD分离的思路是把Prefill请求分流到专门的计算型GPU上P实例把Decode请求分流到专门的带宽型GPU上D实例。两边互不干扰各跑各的极致。P实例处理完Prefill后将计算好的KV Cache通过高速网络传输给对应的D实例D实例拿到KV Cache后继续后续的decode过程。4.2 PD分离的工程实现架构PD分离的落地通常需要一个前缀树路由组件和一个传输通道。一次完整流程大致是这样第一步用户请求到达网关层网关根据请求长度和系统负载判断该请求是否值得拆成PD分离。短请求比如几十个token拆分反而增加网络传输开销不划算。一般建议请求context长度超过某一阈值如512才走PD分离路径。第二步P实例接收请求后执行Prefill生成Prompt对应的KV Cache。这个KV Cache的量有多大呢一个7B模型每个token的KV Cache大约为0.25MB如果请求的context长2048KV Cache就要约512MB。如果同时并发100个这样的请求P实例需要传输的KV Cache总量是50GB这只能靠GPU间的高速互联如NVLink、RoCE网络来搞定普通万兆以太网根本传不动。第三步KV Cache通过传输层送到D实例D实例把接收到的KV Cache直接塞进自己的KV Cache池中然后继续该请求的decode循环。实际工程里P和D是一对多还是一比一映射取决于流量模型。我的经验是P实例的数量大约是D实例的1/4到1/5因为Prefill阶段的总计算量虽然大但单次耗时短而decode阶段则是持续不断地占着设备。如果流量中线上的长上下文请求占比很高甚至可以做到1:1甚至1:2。4.3 配合其他技术的组合拳PD分离不是银弹它解决的是资源划分问题但很多基础优化依然要做。我手上一个真实项目的完整体系是模型权重用INT8量化这一层把显存占用和带宽需求降下来让D实例能支持更大的batch量化后单层模型的decode吞吐提升了大约1.7倍。随后接入PD分离把Prefill的算力需求剥离出去后D实例因为不再被Prefill打断decode吞吐又提升了约1.4倍。最后在D实例上加投机采样配合一个草稿模型decode吞吐再翻了一倍左右。三层叠完同一个GPU集群的有效吞吐比我最初只做量化的方案高出大约5倍。但这里要强调的是组合拳中各层之间存在相互影响不是无脑全开就好。比如PD分离后D实例的显存富余了这给投机采样的草稿模型留出了空间。但如果已经在D实例上堆了极高并发KV Cache已经快占满显存再塞一个草稿模型就可能导致OOM。4.4 PD分离的调度与资源规划细节PD分离要想在真实生产环境跑出收益调度层必须做好三件事。一是请求分类策略。长短请求要分开长请求上PD路径短请求直接在D实例本地做Prefill和Decode避免网络传输浪费。我在系统里用了一个简单的规则如果请求的context长度超过512且系统压力较大就走PD路径否则直接在D实例处理。这套规则可以从根上避免大多数无谓的KV Cache搬运。二是KV Cache的传输优化。传输KV Cache看起来只是搬数据但实际上传输会造成GPU空闲等待如果不想方法P实例给D实例发数据时自己的计算单元是闲置的这就很不划算。业界通用的做法是提前切分把KV Cache切成一个个小块边计算边发送边接收边解码流水线式运作。用CUDA Graph和异步传输可以做到传输几乎“隐藏”在计算背后。三是故障处理。多了一个传输环节就多了一类故障点。网络抖动、D实例接收KV Cache失败、P实例崩溃都需要设计恢复机制。我的建议是KV Cache传输走RDMA尽量避开CPU内存拷贝同时在网关层做请求超时重试这样就算某个D实例挂了请求也能重新调度到其他实例不至于用户侧断流。PD分离的落地工作量是我做的三件事里最大的但如果你的业务有大量长上下文交互请求这笔投入非常值得。它不从底层加速每个token的计算而是从资源调度层面避开了互相拖累本质上是靠“买更多机器但不让机器空转”来提效。5. 常见问题与排查技巧实录做推理优化最怕的不是不会原理而是出了性能问题不知道去哪排查。这一节我把三个方向实际操作中踩过的坑和排查心得整理成一个速查表方便你遇到问题直接对照。现象可能原因排查思路解决方案量化后显存确实降了但生成速度没提升权重量化但KV Cache没量化带宽瓶颈仍在KV Cache用nsight compute看访存指标确认是不是cache读取占据主要耗时开启KV Cache量化观察是否有进一步加速量化后小样本对话正常但长文本任务突然乱码量化误差在长上下文下累积尤其是INT4大group size用困惑度对比长文本前后PPL变化降低group size到64或改用AWQ投机采样上线后吞吐反而下降草稿模型质量太差接受率过低开启投机采样的日志监控接受率低于30%基本无收益换更大或同词表的草稿模型或减少草稿长度投机采样加速比和论文差距巨大运行在较高采样温度下草稿模型命中率大幅下降检查采样温度参数测试temperature0时的加速比业务允许时降低温度或放弃投机采样PD分离后P实例空闲率极高请求太少或都太短不满足拆分条件查看P/D实例的GPU利用率分布调整拆分阈值让更多请求走上PD路径PD分离后网络传输成了瓶颈KV Cache传输未走RDMA走TCP/IP拷贝开销过大观测网络传输耗时检查是否经过CPU切换到RDMA如IB或RoCE启用GPU Direct多机部署PD后模型吞吐没变延迟反而变高只在单机内部做了PD跨机传输的开销吞掉了收益分析延迟成分对比传输耗时和计算耗时优先采用同一节点内的P/D实例组跨机时升级网络量化投机采样同时开启后精度崩了两种近似手段叠加误差被放大分别单独回测精度再叠加测试二选一或减一个的激进程度排查性能问题时我还有一个习惯每次只改一个变量改完跑一组基准测试记录数据再动下一个。不要一上来就同时开量化、投机采样、PD分离出了问题根本定位不到。比如先量化跑通在量化的基础上加投机采样再在两者基础上做PD分离这样每个变量对最终性能的贡献量都一清二楚。另外所有优化最好都在一个独立的评测集上做对照实验至少准备200条覆盖短长上下文的请求看平均延迟、TPOT单个token生成时间和吞吐量。不要用一两个测试用例就下结论推理性能受请求长度和并发度影响极大样本量不足的评测结论没有参考意义。6. 从框架层面看vLLM如何串联这三个加速技术如果你是用vLLM作为一个完整的推理服务框架来用好消息是现在这个框架本身已经可以把量化、投机采样、PD分离这三件事以配置文件的形式统一搞定坏消息是很多人并不清楚这些配置项之间怎么配合。我这里的实践记录大概率可以直接拿到你的生产环境参考。vLLM的启动方式以LLM类的构造参数为准。模型权重上你可以传已经量化好的GPTQ、AWQ、FP8等格式的权重地址框架会自动识别精度并做对应的内核分发。KV Cache量化通过kv_cache_dtype参数控制设置成fp8_e5m2就能启用。投机采样通过SpeculativeConfig配置可以指定草稿模型名称和草稿长度。而PD分离vLLM从较高版本开始支持支持--enforce-eager配合多实例部署或者在调度中做前缀缓存和分离处理。一个基本的生产级配置大概长这样from vllm import LLM, SamplingParams from vllm.config import KVCacheConfig llm LLM( modelyour-model-awq-int4, quantizationAWQ, kv_cache_dtypefp8_e5m2, speculative_configSpeculativeConfig( draft_modelyour-draft-model, num_speculative_tokens5, ), max_model_len16384, gpu_memory_utilization0.85, enforce_eagerFalse, disable_log_statsFalse, ) sampling_params SamplingParams(temperature0.2, top_p0.8, max_tokens1024) outputs llm.generate([你好请介绍一下你自己], sampling_paramssampling_params)如果用的是OpenAI兼容的服务模式把上述参数直接写进命令行或启动脚本里即可。这里要特别强调两点。第一vLLM的PD分离在部分版本里并不是完全透明、开箱即用的它更多依赖你启动多个实例通过外部网关做请求路由。换句话说PD分离是架构层面的事比量化模型参数层面和投机采样解码策略层面要“更外一层”。框架只是给你提供了底层传输的工具具体的路由策略还是得自己写。第二这几个加速技术叠加时框架的调度器会成为下一个瓶颈。如果显存和算力同时上升调度器的锁竞争就可能拖垮整体效率。我碰到的真实案例是加上投机采样后vLLM的单实例高并发并发数大于32时调度吞吐反而下降。解决办法是调整max_num_seqs参数或者在vLLM外部做请求排队不要一股脑把所有请求塞进引擎。工具层面总结一句话vLLM是一个很好的“乐高底座”量化是替换了底座里的零件投机采样是加了一个辅助轮PD分离是重新排列了底座的使用方式。三者可以独立使用也可以叠加使用但叠加时一定要仔细去测调度和吞吐。7. 实操经验与学习路径建议最后分享一些我踩过多次坑之后沉淀下来的经验以及如果你现在刚起步应该按什么顺序来学。学习路径上我的建议是先量化再投机采样最后做PD分离。量化的学习曲线最短半天到一天就能跑通一个量化模型的部署它教会你如何看显存、看带宽、做精度回测。投机采样稍微复杂一点但它能让你深刻理解“计算换带宽”这个核心trade-off。PD分离再往前一步涉及多机、网络和调度是所有内容里工程复杂度最高的放最后学最合理。三个方向学完后建议自己搭一个统一评测脚本里面至少包含单流式请求的延迟表现比如给定一个固定2048 token的输入统计首token延迟和生成速度。高并发吞吐表现比如用wrk或自写脚本压100路并发看整体吞吐。显存使用和波动情况关注峰值显存和KV Cache增长率。这三组数据能让你直观看到每个优化动作带来的真实收益也能让你判断优化是否引入了不稳定因素。实操上给大家三条最紧要的原则都是血泪教训。第一量化模型的精度回测绝对不能省。我在一个7B模型上做过一次偷懒没回测就直接上线结果代码生成任务开始出现一段段重复输出。回测之后发现量化组只在数学推理任务上掉了5个点代码任务直接崩了。不同任务的敏感性不同你无法凭空判断哪种量化配置能过哪种任务只有实测数据能说话。第二投机采样的接受率是你最该关注的核心指标。别只盯着最终的吞吐数字。如果接受率低于30%说明草稿模型选得不好调再久也没用。应当先看草稿模型在目标任务的分布上是否跟目标模型有足够重叠再谈配置调参。第三PD分离不要一开始就上多机。先在单机多卡里做P实例和D实例的逻辑隔离验证收益和传输耗时。我之前一上来就搞了两台8卡机器结果网络传输成了瓶颈优化收益被吃掉大半后来退回单机内PD才真正看到收益。跨机PD只在单机物理资源不够时才是必要的别给自己添乱。老实说大模型推理加速这个方向论文和框架的迭代速度都非常快今天的最优方案可能下周就被新架构替代。但量化、投机采样、PD分离这三个方向背后的底层思考方式是稳定的要么少搬运要么搬一次用多次要么把不同的资源分给擅长它的活。理解了这三种思路哪怕以后来了新的加速方法你也能很快抓住它的本质知道它适合用在哪、不适合用在哪。