1. 推理优化到底在优化什么先搞清楚瓶颈再动手做了这么久大模型应用和推理部署我越来越觉得一件事很多人一提“推理优化”就想到量化、剪枝、蒸馏这些名词但真正落到生产环境里往往连瓶颈在哪都没找准就急着上各种花活。结果模型是变小了速度反而更慢显存倒是省了一点吞吐却惨不忍睹。推理优化不是堆技巧是系统工程。先说清楚“推理”在这里指什么。你在训练阶段做的那些前向传播、反向传播、梯度更新那是训练推理目标是让模型学会知识。而部署阶段的推理是用训练好的权重对真实请求做一次前向计算产出结果。这个阶段的核心矛盾是模型太大、计算太重、显存太贵、用户等不起。推理优化要解决的就是在这个矛盾里找到性价比最高的平衡点。打个比方训练像是建一座图书馆推理像是每天接待几千个读者来查书。图书馆已经建好了你不能把承重墙拆了也不能把所有书都扔掉你要做的是让读者更快找到书、更流畅地翻阅、更高效地利用每一寸空间。推理优化的本质就是在不破坏模型能力的前提下让“查书”这件事更快、更省、更稳。推理优化有两个核心指标几乎所有优化手段都是围绕它们展开的。第一个是延迟Latency也就是一个请求从发出去到拿到第一个token要多久这直接决定用户体验。聊天机器人、自动驾驶、实时翻译全是延迟敏感场景。第二个是吞吐Throughput,也就是单位时间内能处理多少个请求。OpenAI的API、电商客服机器人、批量处理任务这些场景更关心吞吐。延迟和吞吐经常打架你把单请求延迟压得很低往往是以牺牲并发为代价的你把吞吐拉满单请求可能要排队等更久。优化之前先想清楚我的业务到底是延迟敏感还是吞吐敏感还有一个隐藏指标显存占用。大模型部署最痛的往往不是算力不够而是显存装不下。一个7B的FP16模型光权重就要14GB再加上KV Cache、激活值、临时缓冲区一张24GB的卡可能连模型都塞不进去更别提服务请求了。所以推理优化里有一大类工作本质上就是“省显存”。把这三个指标放在一起看推理优化的全貌就出来了。下面我从设计思路上先理一理整体的优化框架再逐个拆核心手段。2. 推理优化整体设计思路五层漏斗模型我实际部署过不少模型从几百M的小模型到几十B的大模型都碰过。踩过的坑多了之后我总结了一套自己的推理优化思路叫“五层漏斗”。意思是每次做优化从上往下走每一层解决一类问题上一层的优化效果不够了再往下一层走。第一层算法层优化。这一层改的是“模型本身怎么做推理”包括模型结构设计、注意力机制的近似、推理步数的缩减。典型手段是蒸馏、稀疏化另外这些年很火的投机采样也属于这一层。这一层的优化上限最高但代价也最大因为往往动模型结构需要重新训练或者微调工程成本高而且有精度损失风险。第二层图优化层。这一层不改模型权重只改计算图的执行方式。典型手段是算子融合Kernel Fusion比如把Attention里的多个小操作融合成一个kernel。你写模型的时候用的是PyTorch一层层API调用很清晰但实际执行的时候一个个小kernel来回启动开销很大。图优化就是把多个小kernel合并成大kernel减少启动开销和中间结果读写。这一层是编译器和推理框架帮我们做掉的一般不需要自己手动干预。第三层运行时优化层。这一层是推理框架在做的事比如连续批处理Continuous Batching、动态显存分配、KV Cache管理。vLLM、TensorRT-LLM、SGLang这些框架的核心竞争力就在这一层。同样的模型你用原生PyTorch跑和用vLLM跑吞吐能差好几倍主要就是这个层的差距。第四层硬件适配层。这一层是让模型更贴合底层硬件典型手段是量化。GPU对低精度计算的支持远好于高精度INT8、FP8的计算单元吞吐率比FP16高很多而且显存占用减半。这一层优化空间大落地上手快是目前最常用的优化手段后面我会详细展开。第五层服务调度层。这一层属于系统架构层面包括模型并行、多卡部署、请求调度、弹性伸缩。比如一个大模型单卡放不下就用张量并行切到多卡比如高并发场景把推理服务放在K8s里做自动扩缩容。这一层优化属于运维范畴但对整体QPS的提升非常明显。这个五层漏斗每层都有各自的工具和手段实际项目里不需要每层都做而是根据瓶颈对症下药。我见过有些团队一上来就搞量化结果瓶颈根本不在显存和算力而是框架的批处理没开浪费了好几天。所以做推理优化第一件事永远是先量化瓶颈再选优化手段。3. 核心优化手段逐一拆解量化、KV Cache与投机采样3.1 量化把模型从FP16瘦身到INT8的取舍之道量化是目前生产环境里用得最广、见效最快的推理优化手段。业界常说的“INT8量化”“FP8量化”“AWQ”“GPTQ”都属于这个范畴。核心原理很简单模型的权重和激活值本来用FP16或FP32存储和计算我们把它降到INT8甚至INT4用更少的比特位去近似原来的数值。少用一半甚至四分之三的比特带来的收益是直接的显存占用减半计算吞吐翻倍因为硬件对低精度计算的并行度更高。但量化不是白赚的它有两个代价。第一个代价是精度损失。你把数值从16位降到8位精度肯定有损关键是怎么让损失不伤害模型能力。第二个代价是校准成本——不是随便把FP16转成INT8就行要算scale和zero point这个计算过程叫校准Calibration。业界有两种主流量化方式PTQ训练后量化和QAT量化感知训练。PTQ是在模型训练完之后做量化不动训练过程速度快但精度偶尔会掉QAT是在训练过程中就模拟量化误差让模型学会适应低精度表示精度保留更好但成本高。以最常用的PTQ为例流程是这样的先准备一批有代表性的校准数据统计数据集的数值分布范围为每一层权重计算合适的缩放因子对激活值也做类似处理最后把高精度权重映射到低精度范围再评测模型精度是否达标。实践中我非常推荐先用GPTQ或者AWQ这类结构化量化方法跑一版因为它们对层做了特殊处理稳定性比朴素PTQ好很多。精度损失怎么评估我在实际项目中给过一个经验值7B到13B的模型INT8量化通常能把精度损失控制在1%以内如果任务不是特别敏感比如文本分类、常规对话基本感觉不到差异INT4量化损失会大一些尤其对数学推理、代码生成这类任务可能会看到明显降智。所以如果你的任务对输出质量要求极高又不缺显存那没必要冒险量化反过来如果一张卡放不下量化就是性价比最高的选择。3.2 KV Cache大模型推理的显存大头与优化核心聊到大模型推理优化绕不开KV Cache这个概念。我第一次看显存监控的时候也吓一跳——模型权重占了几GBKV Cache居然能占掉和权重同量级的显存甚至更多。KV Cache到底是什么简单说Transformer在做自回归生成的时候每生成一个新token都要把前面所有token的Key和Value向量重新计算一遍。如果不缓存那每生成一个token都是O(n²)的计算量根本跑不动。所以推理框架会在显存里开辟一块区域把历史token的K和V矩阵存下来后面生成新token时直接查询这就是KV Cache。KV Cache的显存占用公式可以这样估2 × 层数 × 头数 × 头维度 × 序列长度 × 批次大小 × 字节数。以7B模型为例通常有32层假设每层KV维度是128序列长度2048批次大小16FP16存储光KV Cache就是2×32×128×2048×16×2字节大约537MB。看起来还好但如果序列长度到8192批次大小到64直接飙到8GB以上。这也是为什么长上下文场景里显存会爆掉。针对KV Cache的优化业界已经做了大量工作。最出名的是vLLM的PagedAttention思路借鉴操作系统的虚拟内存分页管理。传统实现里KV Cache要预先分配一整块连续显存即使请求很短也按最大序列长度预留空间浪费严重。PagedAttention把KV Cache切成固定大小的块按需分配不连续也没关系用块表来索引类似操作系统的页表。这个改进大幅提升了显存利用率也是vLLM吞吐领先的关键原因之一。除了分页管理还有几个实用方向。一是KV Cache量化把KV Cache也量化到INT8显存占用直接减半。二是前缀复用Prefix Caching如果多个请求有相同的前缀比如多轮对话的前几轮可以复用已计算的KV Cache节省大量重复计算。三是滑动窗口Sliding Window对超长文本场景只保留最近N个token的KV旧的可以丢弃显存占用变成恒定值。具体用哪种方案取决于你的业务场景多轮对话适合前缀复用流式长文本适合滑动窗口高并发短请求适合PagedAttention。3.3 投机采样用一个小模型加速大模型的神奇思路投机采样是我近年来觉得最“妙”的推理优化手段。它的思路非常反直觉既然大模型每次生成token都那么慢那我能不能先让一个小模型快速生成一串候选token再用大模型一次验证如果小模型猜得准大模型一次性验证多个token速度翻好几倍如果猜错了就回退到当前正确位置重新来损失很少。这背后有一个很重要的事实大模型的解码瓶颈在于串行逐token生成而不是单次前向计算慢。每次前向计算其实能算出整个词表的概率分布但我们只取一个token其他几百个token的概率都浪费了。投机采样就是把这个浪费利用起来——用小模型提前“预演”几个token大模型一次前向就能同时验证所有预演token的对错。实际跑下来投机采样在和人对话这类场景里效果特别好因为对话文本有大量常见搭配小模型猜中的概率很高加速比能做到2-3倍。合理配置的流程是先加载一个小模型比如大模型1/10规模的模型把小模型和大模型放在同一个推理环境里配置草稿模型路径、建议采样token数一般5-8个比较合适然后测试延迟和吞吐需要反复调试草稿长度这个参数太长反而降低收益太短又不够吃满前向能力。但投机采样不是所有场景都适用。如果任务是代码生成、数学推导这类高度依赖精确逻辑的内容草稿模型的猜测准确率很低加速效果大打折扣。此外投机采样会额外占用显存去加载草稿模型显存紧张的环境里要考虑清楚值不值。我的判断标准很简单如果业务场景是开放对话、内容生成这类高确定性文本值得上投机采样如果是代码、数学、搜索这类低确定性任务不如把精力放在量化和批处理上。4. 从算力到服务推理框架选型与关键参数调优前面的优化手段更多是“算法层面”的但要真正落地离不开一套成熟的推理框架。市面上主流的大模型推理框架我基本都用过这里分享一下我的选型思路和调优经验。vLLM是目前社区最活跃的框架PagedAttention的提出者吞吐表现优秀API设计也贴近生产环境。SGLang在vLLM的基础上做了更激进的前缀复用和调度优化在长上下文和多轮对话场景表现突出。TensorRT-LLM是NVIDIA官方出品的对自家GPU适配最深量化支持也最全面但灵活性和社区生态稍弱。Hugging Face TGIText Generation Inference适合快速部署内置了流式输出、量化支持但极端高并发下不如前两者。选型我有个建议如果团队对PyTorch生态依赖很强优先vLLM或SGLang因为它们对Hugging Face模型兼容性最好接入成本最低如果对延迟和吞吐有极致要求且团队有能力做深度优化可以花时间啃TensorRT-LLM如果只是快速验证、做一些内部工具TGI就够了别在这上面浪费太多工程时间。框架定下来之后参数调优才是真正见功夫的地方。我以vLLM为例几个最关键的启动参数--tensor-parallel-size张量并行度决定模型切分到几张卡上。假设你有4张24GB的卡跑一个7B模型单卡就能放下设1即可跑70B模型至少需要4卡并行。--max-model-len最大序列长度这个值直接影响KV Cache分配上限。不是设得越大越好太长会让显存预留过多短请求场景反而浪费。我习惯按业务真实需求估算平均请求长度最大输出长度乘1.5的安全系数。--gpu-memory-utilizationGPU显存利用率上限默认是0.9。这个参数很有意思它控制的是KV Cache能占用多少显存。设得太低能并发处理的请求数少吞吐上不去设得太高一旦模型权重和激活值有额外开销容易OOM。经验值是从0.85开始试观察显存监控慢慢往上加。--max-num-seqs单批次最多序列数这直接决定batch的大小。batch越大吞吐越高但KV Cache和计算压力也越大。需要配合显存余量来调。我自己调过的一个项目初始配置是max-model-len8192、gpu-memory-utilization0.9QPS只有15单个请求平均延迟3秒。排查后发现max-model-len设得过大导致KV Cache预留过多实际跑到的序列长度很少超过2000。把max-model-len降到4096之后KV Cache省出来的显存撑大了max-num-seqsQPS直接翻到55延迟还降了一半。这就是为什么我一直强调先根据真实业务量确认最大序列长度再谈其他参数。还有一个容易被忽略的参数是--trust-remote-code。现在很多模型用自定义代码实现的模型结构vLLM默认不信任远程代码不加这个参数启动就会报错。这个不算优化但部署时经常因为这个卡住顺手提一下。框架调优的过程不是一个晚上能完成的我的经验是分三步走先跑通再调优先用默认参数把服务跑起来确认功能正常再压测找瓶颈用并发请求工具压测看是显存先爆还是算力先满最后针对性调整参数。流程走完吞吐翻一倍以上是常有的事。5. 实战调优流程从压测到参数选定的一次完整记录说太多理论容易飘我拿一次真实的小型实战来演示调优过程。假设你有一个8B模型要部署在单张24GB的卡上目标支持20路并发对话单次输出128个token能让用户基本感觉不到明显卡顿。第一步是准备压测工具。我自己常用的是wrk和locust这类通用压测工具但在LLM推理场景里更推荐专门针对大模型推理的压测方案比如用Python脚本配合OpenAI格式的API模拟并发请求统计首token延迟、平均延迟、QPS三个核心指标。脚本里两个关键参数并发数concurrent_requests和总请求数total_requests先跑50个并发、200个请求拿到基线数据。第二步是确定序列长度和显存预算。8B模型FP16权重约16GB24GB卡还剩8GB给KV Cache和激活值。假设平均请求prompt是512 token期望输出128 token那单个请求的KV Cache占用大概是2×32×(模型H维度)×(512128)×2字节。8B模型的H维度通常是4096这部分算下来约1.6GB左右。8GB可用显存理论上能支撑5个左右的并发请求。这显然不够20路并发但压测下来确实发现显存就是瓶颈那KV Cache压缩或量化就是第一优先级。第三步启动量化。我用AWQ把权重量化到INT4权重从16GB降到4GB多省出近12GB显存。KV Cache也顺手量化到INT8单请求占用减半现在理论上可以支撑十几路并发。压测结果QPS从5跳到14延迟也从4秒降到2.4秒。但此时发现新的瓶颈GPU算力在INT4计算下的利用率已经接近90%单请求首token延迟还有500多毫秒不够理想。第四步上投机采样。我配了一个200M的草稿模型采样长度设为6首token延迟降到300毫秒以内平均延迟降了约40%。为什么有效因为对话场景的常见句式多草稿模型猜得准大模型一次验证就能产出多个token。这个配置下QPS也到了30左右远超目标20路的要求。第五步做稳定性验证。跑了一段时间之后发现偶发OOM原因是有些请求的prompt远超512 token超出KV Cache预留空间。后来加上了系统的过载保护策略对超长请求做截断处理OOM再没出现过。这只是个小案例但它很典型地展示了优化的顺序逻辑先看显存够不够不够就量化再看计算利用率高不高高就上投机采样或图优化最后用压测数据说话而不是拍脑袋定参数。6. 常见问题与排查记录那些坑我已经替你踩过了推理优化落地过程中最花时间的往往不是优化本身而是排查各种诡异的问题。我整理了几类最典型的高频问题每一个都是我实际遇到并解决过的。第一类用了vLLM之后输出结果和原生PyTorch不一样。这种情况十有八九和采样参数有关。vLLM为了性能默认用了自己精简过的采样器实现如果代码里有自定义的temperature、top_p逻辑可能出现细微差异。解决方案是检查输出确认是不是真的不可接受绝大多数场景微小的概率差异不影响使用。如果任务对随机性要求极高可以关掉vLLM的高效采样模式代价是吞吐下降。第二类量化之后模型“降智”明显。我遇到过用GPTQ量化13B模型数学能力断崖式下跌。原因是校准数据集选得太偏全是聊天数据导致数学相关的权重分布没被充分覆盖。解决方法是换校准集从目标任务里抽一批真实数据重新校准精度立刻回来了。校准集的质量比数量重要得多一般512条有代表性的数据绰绰有余。第三类并发一高延迟剧烈抖动。这个问题多半出在请求调度上而不是模型计算。连续批处理机制下一个慢请求会阻塞同一批次里的其他请求。解决方案是给不同请求设置超时和优先级或者把长请求和短请求分流到不同实例。另外检查一下max-num-seqs是不是设得过大batch太大虽然吞吐高但单个请求会等更久。第四类显存看着还有剩余但新的请求还是报OOM。这是因为显存碎片化。即使是PagedAttention长期运行后也会出现碎片。vLLM的做法是后台定期做KV Cache的整理和压缩但如果你用的是老版本框架可能没有这个能力。建议升级到新版框架或者定期重启服务清理碎片。第五类第一版推理服务延迟很低但跑了一周之后越来越慢。这个通常不是推理本身的问题而是日志、干扰、未及时释放的连接等“脏服务”问题比如请求日志越堆越多磁盘IO拖慢了模型权重读取。检查一下运行环境把老进程清掉重启一次通常能恢复。这不是推理框架的问题是运维层面的积累。我把这些经验写成一个简单的排查顺序先确认环境没问题CPU、内存、GPU、磁盘IO再看框架日志有没有异常报错然后逐层排查输入输出长度、采样参数、模型文件完整性最后才怀疑框架或硬件的极限。按这个顺序走大部分问题半小时内能定位。7. 推理优化方向怎么选一张决策清单让你不再纠结每次聊完推理优化总会有人问这么多手段到底该先做哪个我给的建议是不要凭喜好用一张决策清单来判断。先问自己四个问题第一业务核心指标是延迟、吞吐还是成本第二当前瓶颈是显存、算力、还是IO第三模型的精度容错空间有多大第四团队有多少工程时间投入如果你的回答是业务重吞吐显存是瓶颈容错较高那先上量化没错。如果你的回答是业务重延迟算力已经打满且场景是开放对话那投机采样是性价比最高的选择。如果你的回答是业务重延迟prompt前缀重复度高比如Agent系统每次都要塞一大堆系统提示词前缀缓存的收益远大于其他手段。如果你的回答是单卡放不下模型集群资源又充裕那先做模型并行再说别的。这个决策思路的好处是砍掉了一堆无用功。我见过团队花了两周做模型蒸馏结果发现瓶颈在批处理没开白忙活。推理优化的核心原则就是用数据定位瓶颈用方法对症下药用压测验证效果。最后分享一个我个人的小经验每次做推理优化都先录一份性能基线指标包括单请求平均延迟、P99延迟、QPS、显存峰值、GPU利用率。做完任何优化都和基线对比再确认是否值得。这套方法不一定最先进但保证你每一步都有据可依不会在复杂的优化迷宫里迷失方向。推理优化这条路没有终点模型在变大场景在变多部署条件在变化但只要掌握了“找瓶颈、选方案、做验证”这套方法论什么样的新问题来了都不慌。