最近在调一个7B模型的推理服务首字延迟2秒、每秒只能吐十几个token4路并发一上来直接显存溢出。当时第一反应是显卡不行后来把推理优化方法系统过了一遍才发现真正的问题是对“推理到底慢在哪”这件事缺了一层底层认知。这篇把我在这个方向摸过的路、踩过的坑、真正见效的手段全部捋一遍从KV Cache到量化再到服务端调度每一节都会讲清楚它为什么有效、什么时候无效、以及我自己实测下来该怎么调。不管是刚接触推理加速的开发者还是准备上生产环境的工程师这篇文章应该都能帮你省掉不少弯路。1. 推理优化的本质一个“喂不饱”的计算单元很多人的第一反应是推理慢那就堆算力。但等你真把模型部署上去就会发现GPU的算力利用率低得离谱7B模型在单卡上经常连10%的利用率都跑不到。问题不在算力而在于整个生成过程的形态。1.1 自回归的串行宿命一次只产一个词LLM推理和训练有个本质区别训练时可以并行处理一批样本每个样本的整段序列都可以参与矩阵运算计算密度极高但推理是自回归的模型每生成一个token都要把历史上下文重新计算一遍然后才能预测下一个词。这意味着什么一个7B模型FP16权重是14GB你每生成一个token都要把这14GB全部读一遍。这就像你每次在纸上加一个词都必须把整本百科全书从头翻一遍。更麻烦的是这个过程没有任何并行余地——下一个token依赖前一个token顺序锁死了。在GPU上这叫做“带宽受限”而不是“算力受限”。算力是每秒能算多少次浮点运算带宽是每秒能从显存里搬多少数据。模型参数量决定了每次前向必须搬运的数据量而推理速度的上限不是算多快而是搬多快。1.2 带宽受限一个让人意外的基础计算我把这笔账算给你看。假设一块A100显卡的显存带宽约2TB/s跑7B模型时每token必须读取14GB权重那么光读取权重就需要约7毫秒。再算上KV Cache读写、激活值计算和中间数据搬运实际单步生成时间通常在15到25毫秒之间。也就是说单用户场景下7B模型的token生成速度天然就在50到70 token/s这个量级换更好的显卡确实能提升但并非“堆算力”就能解决的事。这也是为什么消费级显卡跑7B模型只有几十token/s因为带宽本身就摆在那里。理解了这一点推理优化的所有思路都可以归结为几个方向要么减少搬运的数据量量化、减少KV Cache要么减少搬运次数批处理、缓存复用要么让每一步生成更有“含金量”投机采样、并行解码。后面所有章节都在围绕这几个方向展开。2. KV Cache推理显存的第一大户也是优化第一站自回归推理中对于已经生成的历史token我们其实不需要从头重新计算它们所有的注意力分数只需要缓存每个token的Key和Value张量即可。这就是KV Cache。它避免了重复计算但代价是显存占用随序列长度线性增长。在实际部署中KV Cache往往是比模型权重更让人头疼的显存消耗来源。2.1 KV Cache到底吃了多少显存怎么算先给一个可以直接用的计算公式KV字节/token 2 × 层数 × KV头数 × head_dim × dtype字节数以Llama-2-7B为例32层、32个注意力头、head_dim128、FP16下2字节。代入得2 × 32 × 32 × 128 × 2 512KB/token一个token就是512KB。跑4096长度上下文单序列KV Cache就是2GB如果同时处理8路并发一次请求所有序列的KV Cache就是16GB。加上14GB的权重还没有算激活值和框架开销显存配额就已经捉襟见肘了。这也是为什么很多人在线上环境里一旦开长上下文很快就OOM——不是权重放不下而是KV Cache把剩余空间吃光了。所以KV Cache优化是所有推理优化的第一站因为它同时影响两个关键指标显存容量和online推理的延迟。2.2 我在实战中比较有效的KV Cache减负手段GQA分组查询注意力。这是模型架构层面的优化现在新发布的大模型几乎全员标配。GQA把多个查询头共享一组Key/Value头Llama-2-70B就是把32个KV头压缩到8个KV Cache直接缩小到原来的四分之一。如果你在选模型优先选带GQA的这个优势从第一行代码起就体现在显存上。PagedAttention与显存分页管理。这是vLLM的核心贡献。旧的推理框架为每个序列预留连续显存块长度一变就产生大量碎片和浪费。PagedAttention把KV Cache切成分页像操作系统的虚拟内存一样按需分配。效果是显存浪费减少了大半长上下文的请求也能挤进有限显存。实测中同样的显存vLLM能支撑的并发比HuggingFace原生实现多3到5倍。前缀复用与RadixAttention。如果线上请求大量共享相同前缀比如系统提示词、Agent工具的固定开头、多轮对话的历史记录把这部分KV Cache缓存起来直接复用可以省掉大量重复的prefill计算。SGLang的RadixAttention就是专门干这个的实测在多轮对话场景里能把整体延迟砍掉一半以上。KV Cache量化。把KV Cache从FP16压成FP8甚至4bit显存占用直接减半。这个方向有个粗糙但有效的经验K和V分开量化V的敏感度通常更高可以给V多留一点精度。不过这个尽量在项目后期再上因为它会引入额外的反量化开销部署复杂度也会明显上升。2.3 关于KV Cache参数配置的一些建议在vLLM这类引擎里max-model-len和gpu_memory_utilization是两个直接决定KV Cache上限的参数。我的习惯是先用公式估算模型权重占用的显存再把gpu_memory_utilization设置到0.85到0.9之间剩余空间几乎全留给KV Cache。不要一上来就把max-model-len拉满到64K甚至更长先看业务真实上下文长度给足余量就好——拉太长等于把等价并发砍半一个极端值可能直接毁掉整套服务的吞吐能力。3. 模型量化用精度换带宽收益与风险的账要算清量化是推理优化里话题度最高、收益也最直接的手段。权重从FP16压到INT8或者INT4等于每次前向搬运的数据量直接减半或减到四分之一。在带宽受限的decode阶段这是实打实的提速。3.1 为什么量化对推理那么有用回到第一节的账7B模型FP16权重14GBINT8权重7GBINT4权重3.5GB。假设在同一张卡上跑带宽占用分别约为原来的50%和25%。decode阶段理论上限就从50-70 token/s跳到100甚至160 token/s。实话说没有其他哪个优化手段能带来这么直接、这么“白捡”的加速。但量化的收益不是没有代价的。它压缩的是模型对参数的记忆精度表达力会受损。问题在于受损程度因模型大小而异70B以上模型因为参数量大、冗余度高通常W4A16量化后生成质量几乎不受影响但7B这种小模型本身表达空间就小再做4bit量化就可能明显变“笨”这需要谨慎评估。3.2 主流方案和选型尺子我实际用下来主流方案按精度和场景可以分为几类列个表方便你对照。方案精度显存收益速度收益适配场景我的实测感受W8A8权重8bit激活8bit较高50%明显服务端部署精度损失小但激活值量化引入的误差需要实测W4A16权重4bit激活16bit中高75%显著消费级显卡/边缘70B以上非常香小模型需谨慎AWQ中高60%-75%显著需要保留关键权重精度选通道加权保护对“0.1%重要参数”处理更精细GPTQ中60%-75%显著追求吞吐上限经典但重建误差略高新模型支持慢半拍FP8高50%明显NVIDIA Hopper以上TensorRT-LLM的FP8方案在H100上提速可观选型尺子就三句话第一70B以上模型大胆用W4A16第二40B以下模型先试W8A8或AWQ别急着上4bit第三如果目标是跑满NVIDIA新卡优先考虑FP8路线配合TensorRT-LLM收益最大。3.3 量化踩坑离群点、评估方式和引擎差异激活值离群点是FP8/INT8量化最容易翻车的地方。LLM的激活里经常有少数极大值直接按均匀分布缩放整个张量小数值的精度会塌掉。AWQ和SmoothQuant这类方案就是为了平滑离群点设计的实操中我发现AWQ在7B模型上的生成质量明显比GPTQ稳。评估量化效果时千万别只看perplexity。我踩过这个坑量化后的模型perplexity只掉了0.2看起来完全无事发生但一测真实业务prompt生成格式乱、重复率升高、关键信息丢。原因在于perplexity是平均指标对离群或罕见样本不敏感。正确做法是拿生产环境里最典型的那批prompt对着量化前后各跑100条人工抽查内容再跑自动化质量指标。不同引擎对量化格式的支持差异很大。vLLM对AWQ和GPTQ支持成熟llama.cpp对GGUF的4bit/5bit量化支持最好TensorRT-LLM对FP8尤其上心。所以量化方案选择不能脱离推理引擎单独定先定引擎再选量化格式否则会陷入“模型量好了引擎不支持”的窘境。4. 投机采样让大模型“少走路”的加速思路投机采样Speculative Decoding是我最近一年越来越常用的一招。它的思路反直觉用一个快速的小模型先生成n个候选token再让大模型一次性验证这些候选全部接受就“白赚”n步被拒绝的部分再回退重来。因为验证可以并行计算代价只相当于一次前向所以整体速度可以提升不少。4.1 草稿与验证的核心机制整个流程可以拆成三个步骤小模型草稿模型串行生成n个候选token这个模型通常只有大模型的十分之一大小跑得飞快。大模型对候选序列做一次并行前向用真实概率分布逐个token验证。被接受的token直接作为生成结果被拒绝的点回退重来。验证过程本身就是大模型的一次正常前向不会浪费。这里最怕的是草稿模型生成质量太差大模型验证时频繁拒绝。拒绝意味着草稿阶段白跑、验证阶段还得重算整体速度反而比直接让大模型生成还慢。所以接受率是这套机制的核心指标——草稿模型和大模型的“默契度”越高收益越大。4.2 关键参数和期望加速效果学术界给出的期望加速比有公式推算大致可以这样理解如果草稿长度是n接受率是p那么每步平均生成的token数约等于n × p / (1 - (1-p) × n的修正项)。太数学的推导这里不展开只给一个经验区间当接受率在0.6到0.8之间、草稿长度取4到5时单用户场景实测可以拿到2到2.5倍的decode加速。几个关键参数我调过之后的心得草稿长度draft length通常4到8比较合适。太短加速不明显太长被拒绝时浪费更大。7B配1B草稿我常用长度470B配7B草稿可以试5到6。接受率这是选草稿模型的核心依据。候选模型和你主模型同源最好因为token分布接近接受率才高。拿一个没有知识蒸馏关系的模型硬凑接受率经常连0.4都不到提速就变成降压了。温度与采样策略投机采样的接受率受温度影响温度越高、分布越散拒绝率越高。如果业务线的采样温度拉到1.0以上需要重新评估草稿模型是否还匹配。4.3 适用边界什么场景加速明显什么场景反而拖慢投机采样不是一上就生效。我实测下来的边界条件很清楚。加速明显单用户或低并发场景GPU远未饱和。比如一个人在本地用小模型跑对话目标模型卡在带宽上限草稿模型用空余算力换几步“白赚”效果显著。另外一个特殊场景是本地CPU/GPU混合部署草稿模型丢到CPU上跑利用异构算力加速比可以到2倍上下。加速不明显甚至变慢服务端高并发已经打满GPU的场景。如果目标模型本身已经连续批处理塞得满满当当你再塞一个草稿模型等于挤占了本来可以用来处理更多请求的算力。实测中在线服务开了投机采样总吞吐不升反降。这个场景的真正杀手锏是连续批处理和调度优化而不是投机采样。造token跟不上Medusa和EAGLE。这是投机采样的衍生方案思路是让主模型自己长出多个预测头来并行生成候选省去独立草稿模型的负担。Medusa在单卡上实测也能拿到1.5倍以上但实现复杂度高适合有专门优化团队的场景普通业务还不如用现成的草稿模型方案。5. 服务端吞吐的胜负手连续批处理与prefill/decode解耦如果你的目标是服务端高并发那么真正决定性的一环在这里。早期框架的批处理方式是静态的攒够一批请求才开始推理这一批全部结束后再处理下一批。这种“人工智障”式调度的浪费在于每个请求长度不一样先结束的要等后结束的新来的请求必须排队等当前批清空。GPU在大部分时间里都在等。5.1 连续批处理一个餐馆翻台式的改进vLLM提出的连续批处理Continuous Batching把批处理粒度从“整批请求”拆到“单个token步”。每生成一个token哪个序列结束就立刻腾出位置给队首的新请求GPU永远在处理活跃的序列。这就像餐馆不再等凑满一车人才发车而是哪桌客人吃完就立刻翻台翻台率直接决定流水。我的实测里同样的模型、同样的显存从静态批处理切到连续批处理吞吐可以提升到原来的3到5倍。这是服务端推理优化里最容易被低估的一环。很多人在本地跑通模型很兴奋但一上线并发就趴窝多数情况就是批处理机制没跟上。5.2 Prefill与Decode为什么必须分开调度这里要引入另一个关键概念。推理请求其实分两个阶段prefill阶段计算用户输入的整段prompt矩阵规模大、计算密集decode阶段逐个生成token每次读权重、带宽密集但算力需求小。这俩混在同一个批次里就像让短跑运动员和马拉松运动员跑同一场比赛谁也不舒服。最好的方案是prefill和decode分开调度业界叫PD分离。让一部分GPU资源专门处理prefill另一部分专攻decode中间通过队列衔接。这样做的好处是每个阶段都能针对自己的瓶颈做优化prefill的算力可以打满decode的带宽可以吃满互不拖累。vLLM里的chunked prefill也属于这类思路将大段prefill切块穿插在decode间隙中执行让GPU空闲时间进一步压缩。如果你要部署70B级别以上的模型且tokens/s要求很高PD分离基本是必经之路。5.3 实践中的调度参数建议调度层面的几个关键参数我给出一些相对通用的建议参数建议说明max_num_seqs8-16控制同时处理的最大序列数。太大单用户延迟飙升太小GPU喂不饱max_num_batched_tokens2048-4096单个batch内的token总量上限决定prefill块的大小gpu_memory_utilization0.85-0.9给KV Cache留足空间比例block_size16-32PagedAttention的分页大小实测大分页对长序列吞吐更友好这里有一个关键平衡点max_num_seqs设大系统吞吐上去了但每个请求排队等待的时间也会变长体现在用户体验上就是P99尾延迟恶化。业务对延迟敏感就设小一点对吞吐敏感就设大一点。没有固定答案只有贴着业务测试才能找到最优值。6. 推理引擎选型vLLM、TensorRT-LLM、SGLang、llama.cpp怎么挑同一个模型同样的卡用不同推理引擎跑出来的性能差距可以到30%以上这是我在多个项目里反复验证过的结论。引擎不只是“跑模型的工具”它决定了你能不能用上PagedAttention、连续批处理、PD分离这些优化手段。选错引擎后面再努力也是给地基不牢的房子添砖。6.1 四类主流引擎的定位和差异vLLM社区最活跃、生态最完整的通用引擎。PagedAttention和连续批处理是它的看家本领且与HuggingFace生态无缝衔接新模型发布后支持速度极快。适合绝大多数场景的快速部署。缺点是对特定NVIDIA新特性如FP8专用算子的支持没有TensorRT-LLM深。TensorRT-LLMNVIDIA官方出品性能上限最高的引擎尤其对FP8量化、Hopper/Blackwell架构新特性加持明显。同样的70B模型TensorRT-LLM可能比vLLM再快10%到30%。代价是引擎构建流程复杂模型需要先“编译”成TensorRT格式调试难度和版本兼容成本都高。适合对性能极致的生产环境。SGLang在RadixAttention前缀缓存和结构化输出方面优势突出。如果你业务里每轮请求都复用大量公共上下文——比如复杂Agent、RAG系统里的大段系统提示词——SGLang能把这些重复计算真正省掉这是其他引擎很难做到的。llama.cppGGUF格式和量化方案的“鼻祖级”实现CPU/GPU混合推理、离线单机部署、边缘设备场景的王者。单用户吞吐不算高但胜在零依赖、易部署、量化灵活现在大量本地AI应用里都能看到它的影子。6.2 我实测下来的数据感受我在A100-80G上分别用vLLM和TensorRT-LLM部署过Llama-2-7B。同条件下vLLM在256并发附近能达到千级tokens/s的系统吞吐TensorRT-LLM在此基础上还能再高出15%到25%。但TensorRT-LLM的模型构建时间和调试复杂度明显更高一个算子不兼容可能折腾一整天。对于大多数业务我的选择是先上vLLM快速跑通和压测确认收益后再评估是否值得迁移到TensorRT-LLM。llama.cpp我在RTX 4090上跑过Llama-3-8B的Q4_K_M量化版单用户吞吐能到100到180 token/s之间本地聊天体验非常顺。但如果要做在线服务llama.cpp的高并发能力偏弱硬撑的话不如直接用vLLM。选型我给个快速决策表场景推荐引擎原因快速上线、API服务、中高并发vLLM生态成熟优化全面最快跑通性能极致、NVIDIA新卡、FP8TensorRT-LLM单卡性能天花板原生叠满Agent/RAG大量公共前缀复用SGLangRadixAttention前缀缓存独一档本地离线部署、消费卡量化llama.cppGGUF生态丰富部署门槛最低6.3还有一个容易被忽略的选项是HuggingFace TGI。它在企业级功能如推理加速、对话模板兼容上做得不错但调度灵活性和吞吐优化不如vLLM激进。如果你的团队对HuggingFace生态特别熟TGI也是个稳的选择但如果是从零开始我还是建议直接考虑vLLM。7. 一次典型调优全流程从慢速服务到可上线状态这一节我把一次典型的调优流程完整走一遍所有优化顺序和收益都是我实际经历过的。目标是把一个“能跑但跑不动”的7B部署变成一个可上线的高吞吐服务。7.1 先定指标TTFT、TPOT、吞吐、P99优化如果没有度量就不叫优化只能叫碰运气。我用四个指标来评价推理服务指标全称定义对应瓶颈TTFTTime To First Token请求发出到收到第一个token的时间prefill阶段和排队时间TPOTTime Per Output Token平均生成每个token的耗时decode阶段带宽Throughput系统总输出吞吐每秒全系统生成的token数调度与批处理效率P99/P95尾延迟最慢的1%/5%请求的延迟极端并发与资源碎片很多项目只看平均TPOT结果上线以后被P99拖死——对在线聊天场景来说最慢的请求往往是用户直接感知“卡顿”的来源。所以调优的第一步不是改参数而是把压测脚本跑起来把这四个指标打出来。7.2 我的调优顺序和每一步的收益我这次调优走的是先基线、再逐层叠加的路线每一步都回到同一套压测脚本上跑分。第一步用HuggingFace原生实现跑一遍基线。结果很“感人”单用户TPOT约35ms4路并发时吞吐不到30 tokens/s显存已接近满。这一步的意义是给后续所有优化一个参照值。第二步切到vLLM开启连续批处理和PagedAttention。没有做任何量化单用户TPOT降到约18ms4路并发吞吐翻倍到120 tokens/s左右。这一步的收益几乎全来自批处理调度。第三步做W8A8量化。7B模型权重从14GB降到7GB显存压力骤减并发从4路提升到10路系统吞吐跳到350 token/s左右。单用户TPOT也有微幅下降。跑了一轮生成质量评估确认没问题才敢出这一步。第四步调调度参数。把max_num_seqs从默认16调到32max_num_batched_tokens调到4096同时观察P99。这一轮没有调模型纯粹在调排队策略吞吐从350提到了450 token/s以上P99没有明显劣化。第五步评估投机采样。在这个已经高并发的服务里加了草稿模型结果总吞吐反而掉了8%左右。原因就是我前面说的GPU已经饱和草稿模型反而抢占了目标模型的算力。这个测试价值很大——它帮我确认了当前架构的瓶颈在批处理而不是单步生成速度。整个流程跑完TPOT从35ms降到10ms左右系统吞吐从30 tokens/s提到400 tokens/s这一个多量级的提升没有更换任何硬件全是推理优化方法带来的。7.3 一些容易忽略的隐形坑压测过程中我踩了几个坑列出来基本是通用经验不要拿“你好”做压测。prompt越长prefill阶段占比越大TTFT虚高prompt太短KV Cache占用又失真。要用生产环境的真实prompt长度分布压测才有意义。采样参数会影响性能。beam search的KV Cache分支比greedy多几倍Top-K/Top-P对连续批处理的缓存复用也有影响。做性能对比时所有配置保持一致才有可比性。日志和metrics采样本身有开销。压测时开着全量请求日志我测出过5%到10%的吞吐损耗。生产环境要么抽样日志要么把日志写库放到异步线程。显存碎片比想象中的隐蔽。PagedAttention确实缓解了KV Cache碎片但长上下文和短上下文混跑仍然会造成显存浪费。监控面板里看到“显存没满但OOM”的情况多半就是碎片问题。8. 推理框架之外的性能因素与最后一点心得到这里核心优化方法基本都覆盖了。最后聊几个框架之外、却经常“一票否决”性能的因素以及我个人反复验证后的心得。第一你的输入长度分布可能比任何优化手段都重要。如果生产环境里大量请求都是几千token的RAG上下文而压测只用几十token的短prompt那么所有指标都是假的。任何调优都必须在真实负载画像下做。第二设备拓扑对多卡部署的影响常被忽视。NVLink真正让多卡协同跑起来PCIe 4.0/5.0跨卡通信在张量并行时是瓶颈。70B以上模型压测前先确认卡间带宽否则你可能会看到一个格局很大的TPOT。第三模型本身的长度外推能力也会影响推理优化。如果你的模型上下文只有4K就别硬撑20K请求KV Cache爆了任何调度优化都救不回来。回到开头那个案例7B模型的“慢”最终不是靠换卡解决的而是通过切引擎、量化、调调度这套组合拳把单位成本下的吞吐翻了十倍。推理优化是一门“把每一分带宽和每一分显存都花在刀刃上”的学问它没有某一条万能公式但永远有至少三步可以立刻动手重新审视批处理、评估量化收益、用真实负载重新压测。按这个顺序走大多数性能问题都能回到正轨。