每次我在社区帮人排查大模型推理速度问题时都会遇到一个相同场景显卡明明在跑显存也没爆但生成速度就是上不去一个千字回答要等上一两分钟。任务管理器里看GPU利用率只有百分之二三十算力根本没吃满。问题出在哪大概率是踩了推理加速的老三样没做全——量化、投机采样和PD分离。这篇文章就是围绕这三项技术来写的它们分别解决什么瓶颈、底层原理是什么、怎么在本地部署环境中落地、组合起来能达到什么效果。适合两类读者一类是刚把大模型跑起来、想进一步压榨硬件性能的人另一类是准备上手vLLM这类推理引擎、想系统理解关键参数含义的开发者。我会结合自己在nano-vllm和vLLM上实际调参的经验把每一步的操作逻辑讲清楚。1. 大模型推理到底慢在哪里先搞清两个截然不同的瓶颈很多人对推理慢的理解停留在模型太大、显卡不够好于是第一反应就是换更大显存的卡。这个方向没错但比较浪费钱。因为大模型推理的慢往往不是算力不够而是显存带宽不够、数据搬运不过来。这个认知不纠正后面做量化也好、做PD分离也好你都理解不了为什么能提速。1.1 计算密集型与访存密集型一张显卡的两副面孔深度学习任务大致分两类。一类是卷积神经网络跑图像分类、目标检测特征是每张输入图片的计算量很大芯片上的CUDA核心大多时间在真正做乘加运算这叫计算密集型compute-bound。另一类是推荐系统里的Embedding查询、大模型的token生成特征是单个token的计算量不大但每一步都要把模型全部权重从显存里搬到计算单元里跑一遍这叫访存密集型memory-bound。大模型推理在预填充阶段偏计算密集因为要一次性处理整段提示词矩阵乘法量大但在逐token生成阶段每个token只做一次前向传播计算量小到可怜瓶颈彻底变成显存带宽。这也是为什么你会发现生成模式下GPU利用率叠不高功耗也上不去但速度就是快不起来——核心都是被显存读取带宽卡住了。1.2 一张表看清decoder阶段的带宽消耗我们以27B参数模型为例假设用float16精度加载权重。27B个参数每个参数占2字节总权重就是54GB。每生成一个token推理引擎要把这54GB权重从显存搬到计算单元至少一遍。目前主流数据中心的显卡比如H100显存带宽大概是3.35TB/s消费级显卡比如RTX 4090带宽大约1TB/s。那么单次搬运耗时就是54GB除以带宽。硬件显存带宽约搬运27B权重耗时/次RTX 40901.0 TB/s约54毫秒H1003.35 TB/s约16毫秒A100 80G2.0 TB/s约27毫秒也就是说在最理想的情况下4090每生成一个token至少要54毫秒换算过来每秒最多生成18个token左右。这还不算计算、调度、KV Cache读写等其他开销。所以当有人吹某框架在消费卡上跑27B模型能到50 tokens/s你首先该怀疑权重精度是不是已经降过或者用了投机采样等技巧在缩短实际生成路径。理解了这条主线后面三个加速技术就很好串起来量化是把要搬运的权重瘦身投机采样是减少大模型实际生成token的次数PD分离则是把两种不同特性的阶段拆开、避免互相干扰。三者从不同部位下手但终极目标都是缓解搬运权和生成等待这个核心矛盾。1.3 为什么batch越大越划算但显存总是不够用既然每生成一个token都要读一遍全部权重那如果一次来一批请求呢权重只需要读一遍却可以同时服务于多个请求的多个token计算相当于搬运成本被分摊了。这也是推理引擎里continuous batching的核心思想。但batch增大意味着显存里的KV Cache也在涨。每个请求的每层、每个注意力头都要缓存K和V向量上下文越长占用越大。于是你陷入一个矛盾想要吞吐需要大的batch想要大的batch需要多的显存可显存里有54GB已经被权重占走了。这就是量化最直接的动机之一——把权重占的那一块压缩下来给KV Cache腾地方让batch可以开更大。2. 量化落地把参数精度压到合理区间显存和速度一起改善量化是这三项技术里最容易上手、收益最直接的一个。本质上就是让模型参数用更少比特来表示常见路线有INT8、INT4、FP8、NF4等等。你不需要掌握底层的位运算细节但一定要知道量化到底动了什么、精度影响在哪里、实际部署时选哪种格式。2.1 量化为什么既省显存又提速三个环节同步减压第一是缩小权重的物理体积。27B模型FP16要54GB压到INT4大约13.5GB省了四分之三。这一下子解决两件事原本放不下的卡能放下了原本放得下的卡KV Cache可用空间变大batch能开更大吞吐随之提升。第二是降低带宽压力。上面那张表的搬运耗时间和权重体积成正比INT4权重只需搬运原本四分之一的数据量单token延迟的理论下限直接缩短到原来的四分之一左右。注意我这里说的是下限——实际上因为反量化计算、额外开销等因素实际提速没那么夸张但趋势是明确的。第三是部分硬件有低精度加速单元。像H100对FP8有专门的Tensor Core加速INT8在多数显卡上吞吐也比FP16高。也就是说量化之后不光搬运快计算本身也有可能更快。但这条要看硬件消费级显卡上4bit推理主要吃的是带宽红利而不是Tensor Core红利。2.2 主流量化路线横向对比别迷信哪个最好量化方案太多我按部署方式给一个实用对照。你可以把它当成选型清单方案精度是否需要重训适用场景特点PTQ训练后量化INT8否追求稳妥的通用场景用校准集统计激活范围速度快精度损失通常可控GPTQINT4/INT3否单卡部署大模型按层做二阶近似误差补偿27B模型压到13GB左右AWQINT4否对敏感通道更加在意的场景不直接量化所有权重按通道重要性做缩放保护GGUF2~8bit可调否llama.cpp / Ollama 等本地工具链格式封装好量化层级细适合Consumer级硬件MLX 4-bit4bit否Apple Silicon 设备配合MLX框架在Mac上跑Qwen这类模型很快FP88bit否H100等数据中心卡精度接近FP16但硬件必须支持NF4QLoRA4bit是微调时用微调场景正态分布适配的4bit编码通常配合LoRA实际项目里我没有只认一个方案的执念。在vLLM上跑Qwen系模型我习惯优先试AWQ或GPTQ本地PC上跑GGUFMacBook上直接用MLX 4-bit。同一种模型在这些方案下的速度差异不大真正影响体验的往往是显存余量和上下文支持长度。2.3 实操演示本地27B模型的4bit部署链路搜到热搜里有人在问qwen3.8-27b mlx 4-bit推理和k100ai单卡推理qwen3.8:27b推理速度我正好把本地跑27B模型的完整思路走一遍。以一台48GB显存的工作站为例跑Qwen3.8-27B的4bit版本第一步从HuggingFace下载对应量化权重。如果想跑AWQ版本用Qwen/Qwen2.5-27B-Instruct-AWQ这类仓库如果想跑GGUF用Qwen/Qwen2.5-27B-Instruct-GGUF选q4_K_M这个分片。下载命令用huggingface-cli或者git clone都行注意大文件要开LFS。第二步启动vllm serve Qwen/Qwen2.5-27B-Instruct-AWQ。关键参数是--quantization awq引擎会按AWQ格式加载显存占用大约在14~16GB权重加少量KV Cache。如果你想跑更高吞吐可以再加--max-num-seqs 32、--gpu-memory-utilization 0.9。第三步简单测速。用OpenAI兼容接口写几行Python脚本发请求关注completion_tokens和耗时。我的经验值是在48GB卡上跑AWQ版27B模型单并发大概35~45 tokens/s10并发时吞吐能到200 tokens/s。如果在4090这种24GB卡上权重占14~16GB后KV Cache空间会比较紧建议把--max-model-len限制在4096或8192。如果在Mac上直接用MLX脚本加载mlx-community/Qwen2.5-27B-Instruct-4bit。这块我没法给你统一命令因为MLX的代码通常是一段Python脚本核心就是from mlx_lm import load, generate然后指定模型路径。速度上M2 Ultra的Mac Studio跑27B 4bit大约在20~30 tokens/s比同类Windows机器上的CPU推理快很多。2.4 量化白拿的代价精度损失怎么评估任何量化都有精度损失只是多少的问题。我的经验是INT8几乎无损AWQ和GPTQ的INT4在日常对话场景基本无感但遇到数学推理、代码生成这类需要精确逻辑的任务偶发错误会变多。怎么验证精度两条路。第一条是跑任务集算指标比如代码用HumanEval、数学用GSM8K对比量化前后的pass1。第二条更直观拿同一个问题反复问量化前后的模型看回答稳定性。我在实践中发现哲学性、开放性问题对量化不敏感但写一段二分查找代码这种明确任务4bit模型偶尔会把边界条件写错。如果你做量化不是为了部署而是为了微调注意不要自己乱改权重精度。QLoRA那套NF4格式是配合LoRA适配器用的需要专门的库和流程。直接对普通INT4权重做微调梯度更新很容易把量化误差放大。提示买卡之前先算账。27B模型4bit约需14GB显存再留出上下文和KV Cache的空间你至少要有20GB可用显存才跑得舒服。别只看参数说14GB能跑就直接下单同容量显卡。3. 投机采样用小草稿模型开路让大模型只做裁判量化解决的是读权重的带宽问题投机采样则是从另一个角度提速——减少大模型真正执行的生成步数。这个思路刚接触会觉得反直觉本来一次推理就够麻烦了为什么还要额外跑一个小模型但理解了它的权衡后你会发现它特别适合单机单卡或者和量化叠加使用。3.1 原理拆解猜得快验得稳兑现率决定收益投机采样speculative decoding的框架是选一个小得多的草稿模型draft model比如几十亿参数的模型或者同一个大模型的蒸馏小版。草稿模型先连续生成K个候选token。大模型target model把这K个token拼在一起一次性做前向计算逐个校验。如果某个token的概率低于草稿模型预估的接受阈值就从这里截断用大模型自己采样出的token替换然后循环。关键点在第三步大模型原本要串行生成K个token每次都得等前一个完成投机采样下它只需做一次前向计算就能同时校验K个候选。算力没怎么多花但生成的墙钟时间被压下去了。加速比的上限大约等于草稿模型的接受率乘以草稿长度。如果平均接受率是0.7草稿长度是5那么理想加速比约3.5倍。实际会打折扣因为每次校验到第几个token被拒绝决定了这轮实际生效了几个token。如果第一个就被拒那这次投机就是负收益。我见过很多人在这个环节翻车原因是草稿模型选得太小、或者和被验证的模型领域差异太大导致接受率掉到0.2以下。这时候投机采样不仅没有提速反而因为多跑一个小模型白耗算力。经验参数草稿模型和主模型的规模比我觉得在1:5到1:20之间比较靠谱同源蒸馏模型效果最好。3.2 实操配置在vLLM里跑通投机采样在vLLM中启用投机采样非常直接只需要指定草稿模型。以Qwen系列为例主模型用27B的AWQ版本草稿模型可以用同系列的0.5B或1.5B版本。vllm serve Qwen/Qwen2.5-27B-Instruct-AWQ \ --quantization awq \ --speculative-config draft_modelQwen/Qwen2.5-1.5B-Instruct \ --num-speculative-tokens 5 \ --max-model-len 8192这里--num-speculative-tokens就是K值我建议从5开始调不要一上来就开8或10。K值越大单轮可校验的候选越多但如果草稿模型质量不行拒绝发生在后半段前面的计算全白费。执行后观察日志里的accepted_length和rejected_length。vLLM会打印这部分统计核心看平均接受token数。当平均接受数大于3时投机采样的收益就比较体面了如果小于2我建议把K调小或者换更强的草稿模型。我在单卡上跑过一组对照27B AWQ模型K5草稿1.5B实测从36 tokens/s提升到58 tokens/s左右提升约60%。注意一点投机采样对batch的收益不如对单请求延时那么明显。高并发时continuous batching本身已经让GPU很忙小模型穿插反而会挤占算力所以这个技术最适用的场景是低并发下的首token延迟和单用户交互体验。3.3 遭遇翻车后的排查思路接受率上不去的三个原因如果投机采样跑下来反而更慢按下面的顺序排查第一草稿模型是否与被验证模型同源、同微调方向。跨系列组合基本不用试比如用Mistral小模型给Qwen大模型打草稿成功率会低到没法看。第二--num-speculative-tokens是否太大。K越大后面几个token的接受率通常断崖下跌因为草稿模型越往后猜越容易偏离。不是一个K值吃遍所有场景需要跑一小段benchmark找拐点。第三温度参数。温度越高采样随机性越强草稿模型猜中大模型理想分布的概率越低。对话场景如果用temperature1.0投机采样的收益就会大幅缩水。实用做法是保持在0.3~0.7之间这也是大多数对话任务常用的区间。4. PD分离把预填充和生成拆开调度别让两种活抢一张卡量化省了显存带宽投机采样减了生成步数PD分离则是从系统调度层面做文章。这项技术在vLLM 0.6.x之后逐渐成为热点核心就是把Prefill阶段和Decode阶段部署到不同的进程甚至不同的显卡上。4.1 Prefill与Decode的资源需求完全不同一个完整请求在大模型推理中分两段。Prefill阶段也称预填充处理用户输入的prompt把它变成第一个输出tokenDecode阶段逐token生成后续内容。Prefill的特点是计算密集一次处理大量输入token矩阵乘法规模大算力需求高但对延迟相对没有那么敏感。Decode的特点是访存密集每个token的计算量小但需要频繁读取权重和KV Cache对延迟极敏感用户每多等一秒都很明显。传统架构两者在一张卡上交替执行先来的请求做Prefill后来的请求排队做完Prefill的请求进入Decode又要抢占算力。结果就是长prompt请求的Prefill会把正在Decode的短请求卡住造成尾延迟飙升。这跟餐厅里一个厨师既要处理大订单备菜又要给每桌客人上菜一样忙起来两头乱。4.2 PD分离怎么运作一个调度理论加上一套分布式分工PD分离的思路是把这两类任务放到不同实例上。Prefill实例专门处理输入、生成KV CacheDecode实例接收Prefill传过来的KV Cache继续生成token。彼此独立调度互不抢资源。这张图听起来复杂但实际抽象起来就四步请求进入Prefill节点推进到首个tokenKV Cache传输给Decode节点Decode节点连续生成token生成完毕释放资源。对上层API来说客户端只看到一次请求和一次流式返回底层拆成了两段流水线。vLLM里启用PD分离有典型配置思路vllm serve Qwen/Qwen2.5-27B-Instruct-AWQ \ --enable-pd-separation \ --pd-workload prefill \ --port 8000另一台机器或另一张卡上起Decode实例用--pd-workload decode再把Prefill实例的地址传给它。更细的调度还可以配置--pd-pool、KV Cache传输策略等等。我在实际调测中感受到的一个核心区别是启用PD分离后请求的P99延迟变得很平稳不再有某次请求突然多等好几秒的毛刺。原因就是长prompt的Prefill不再挤占活跃Decode的算力。4.3 什么场景才值得上PD分离不是所有架构都需要它PD分离并不是默认更优它引入了KV Cache传输和分布式一致性的额外开销。我给它画个适用边界单卡部署或者两卡以内的场景PD分离收益很小甚至会因为多进程通信拖慢速度。中低并发场景也暂时用不上continuous batching已经能把调度维持得不错。真正值得上的场景是百级并发以上、长prompt占比高、P99延迟敏感的生产服务。比如企业内部接入多个知识库助手用户粘贴大段文档提问此时Prefill平均几百上千token每隔几个请求做一次大块矩阵计算很容易干扰Decode。另外要提的是PD分离经常会和量化叠加使用Prefill实例卡显存较大跑FP8版本Decode实例卡显存相对充裕跑INT4版本带宽压力也更小。这样既保证了Prefill的精度又压低了Decode的访存成本算力分配也更干净。提示如果你只有一张卡别硬上PD分离。把精力放在量化和投机采样上收益会明显得多。PD分离是为多卡集群里的调度问题准备的手术刀不是人人都需要。5. 三套加速方案如何组合选型逻辑与效果预期很多人把量化、投机采样、PD分离当成三个独立选项实际上它们解决的瓶颈不同、可以互相叠加。我用一张图把它们在整条推理链路里的位置理出来你就知道怎么组合了。5.1 组合的底层逻辑先压带宽、再减步数、再调调度量化解决的是单token生成时的权重读取成本属于所有场景的基本盘。投机采样解决的是串行生成步数的墙钟时间属于交互延迟优化器。PD分离解决的是多请求混合调度时的资源争抢属于高并发生产环境的稳定器。所以我会这样组合第一档单卡本地部署。量化必做投机采样视模型对选择而定PD分离直接跳过。这是最基本的加速组合先把权重压缩再用投机采样优化单用户延迟。第二档小规模多卡服务。量化继续做PD分离如果并发不高可以不急着上但vLLM的KV Cache复用、prefix caching一定要开加上投机采样提升响应速度。第三档生产级大并发集群。三件套全上Prefill和Decode节点分别量化到不同精度前者跑FP8保精度后者跑INT4提吞吐Decode节点内部再说有没有必要配投机采样KV Cache传输走高速通道。5.2 单卡组合实践27B模型的顶配配置我拿24GB显卡单机跑27B模型举个例子这是社区里提问最多的配置。显存只有24GB放FP16的27B模型要54GB放不下AWQ 4bit约14~16GB能放但KV Cache空间只剩不到8GB所以--max-model-len不能开太大建议8192以内。在此基础上叠加投机采样用1.5B草稿模型K5。我跑出来的典型数据是单并发从35 tokens/s提升到约55 tokens/sP95延迟从4秒压缩到2.5秒左右。这个效果在没有量化的情况下是做不到的因为FP16权重直接把显存占满连投机采样的小模型都塞不进去。如果你用GGUF加llama.cpp那套组合思路类似选q4_K_M量化再开启--speculative近似的功能llama.cpp 2024年底后的版本支持draft模型同样能压延迟。5.3 高并发生产环境PD分离与量化如何分配合适的卡假设你有一个中等规模的推理服务4张40GB显卡。我建议这么分Prefill节点1张卡跑FP8或者AWQ量化版本主要吃算力KV Cache要求不高。Decode节点2张卡跑INT4量化主要吃带宽batch开大。剩下1张卡看情况做弹性扩展如果prompt特别长加给Prefill如果生成特别长加给Decode。这样的分配比四张卡全部混跑要容易调优得多。Prefill不会突然被Decode的长尾请求堵住Decode也不会因为某次大批量Prefill导致GPU利用率跳水。注意KV Cache的传输问题。PD分离之后Prefill节点生成的KV Cache要送到Decode节点如果走普通网络延迟会吃掉一部分收益。实际部署里尽量保证两个节点在同一台机器内通过NVLink通信或者至少是在低延迟内网中。PCIe和万兆网也能跑但P99延迟会明显上涨。5.4 配置选型对照表按你的场景抄作业我把不同场景的推荐配置整理成一张表方便你直接参考场景量化精度投机采样PD分离关键配置本地单卡跑7B以下INT4/GGUF q4不建议不启用优先保显存余量本地单卡跑27BAWQ/INT4强烈推荐不启用max-model-len 控制双卡中等并发AWQ/INT4推荐视情况batch控制是关键四卡以上高并发Prefill FP8 Decode INT4推荐启用KV Cache传输通道要快Mac本地部署MLX 4bit视模型而定不启用注意Apple统一内存上限6. 跑完一轮实操我总结的几条教训文章最后不写总结性套话只把自己踩过的坑拿出来说说。第一点是别迷信单一指标。量化之后显存看着变小了但kv cache的余量、并发上去之后的吞吐、长prompt下的P99延迟都要看。我曾经只看单token延迟觉得挺快实际压测一跑batch一开直接崩了。第二点是草稿模型的引入不是零成本。它占用显存、占用调度资源、还会增加首token延迟的感知复杂度。如果你跑的是7B以下的小模型投机采样的收益非常可疑——主模型本来就不慢草稿模型的额外开销反而可能拖后腿。我建议10B以上模型再考虑这个技术。第三点是PD分离的调试成本比想象中高。它不是加个参数就完事你需要感知KV Cache传输耗时、Prefill和Decode实例的负载比例、甚至网络拓扑。刚开始跑的时候我遇到过Prefill节点利用率只有30%Decode节点却在排队的情况最后靠调整分配比例和并发上限才平衡。第四点是如果手头资源有限优先做量化。这项技术一次投入、长期受益后续无论上投机采样还是PD分离都以它为基础。我给新手的学习路径是先把自己模型的量化版本跑熟然后上一个同源的草稿模型做投机采样最后再碰PD分离。这三步走完你对大模型推理的优化认知基本就立住了。另外提一句网上经常能看到各种推理加速神器的夸张宣传实际自己上手跑一遍大部分收益都来自我们上面说的朴素原理省显存、减带宽、少走串行路径。理解了原理再去调参数你就不会轻易被那些花哨名词忽悠。最后分享一个小技巧每次调整推理参数后记得用固定的prompt、固定的输入长度、固定的并发数做前后对比把数据记下来。我习惯把每次实验的tokens/s、TTFT、P99延迟记在表格里慢慢就能摸出自己硬件条件下最优的配置组合。大模型推理加速是一个靠实验迭代的过程没有哪一套配置能通吃所有环境数据在手调优不愁。