1. 先搞清楚推理性能调优到底在调什么做AI模型部署的同学应该都有同感模型训练完了只是第一步真正让人头疼的是后面那句“上线跑一下”。训练时你关心loss降没降、收敛快不快可一旦进入推理阶段画风就全变了——延迟、吞吐、显存占用、首token耗时、并发能力每一个指标都有可能成为压垮线上服务的最后一根稻草。我见过不少团队把大量精力花在训练调参上结果模型一到推理阶段就各种翻车GPU利用率上不去、请求一多就超时、显存莫名其妙OOM。回头复盘问题往往出在“不知道推理性能的瓶颈到底在哪”这件事上。所以这篇文章想认真聊一聊AI模型推理性能调优与部署建议把我在实际项目中踩过的坑、验证过的方法、以及一些可以直接抄作业的配置方案分享出来。先给这篇文章定个位如果你正准备把训练好的模型部署成线上服务或者已经在部署但性能不理想这篇文章值得你从头看到尾。内容覆盖推理性能指标拆解、常见瓶颈定位、模型优化手段、部署架构选择、运行时参数配置、实测调优过程以及高频故障的排查思路。我会尽量用实际场景说话而不是堆理论。注意文中的所有测试数据和配置参数都来自我本人在某公司内部搭建的模拟项目X中的实操记录硬件环境为单卡和双卡两种方案结论在同类GPU上具备一定的参考价值但不同架构、不同驱动版本下结果会有差异建议以实测为准。2. 推理性能的核心指标与瓶颈拆解2.1 别只看单次延迟这些指标同样重要很多刚接触部署的同学习惯拿“单次推理耗时”来衡量模型快不快但真实线上场景里单次推理耗时只是表象。举个很简单的例子一个接口单次推理只要10ms但只能同时处理1个请求另一个接口单次推理要30ms却能同时处理32个请求。在业务并发较高的时候后者的整体吞吐反而是前者的好几倍用户体验也好得多。推理性能调优时我一般会同时盯住下面几个核心指标延迟Latency从请求发出到拿到完整响应的时间细分下来还包括首token时间TTFT和每token生成时间TPOT。在线业务对延迟特别敏感比如对话类场景首token超过3秒用户基本就会觉得“卡了”。吞吐量Throughput单位时间内能处理的请求数或token数。离线批处理场景更看重吞吐比如批量文档解析、离线生成。GPU利用率这块很多人会忽略。GPU利用率低往往意味着算子没有充分利用硬件或者数据加载/预处理成了瓶颈。显存占用模型权重、KV Cache、中间激活值、CUDA context加起来分分钟能把显存吃满。并发能力服务在同一时刻能支撑的请求连接数直接决定你能扛多大的业务流量。表格整理一下方便对照场景选指标指标适用场景主要瓶颈来源延迟含TTFT/TPOT在线对话、实时交互模型规模、解码方式、算子效率吞吐量离线批处理、数据生产batch size、并发数、显存带宽GPU利用率所有场景数据加载、CPU预处理、算子调度显存占用所有场景模型权重、KV Cache、中间激活并发能力高并发API服务框架线程模型、显存容量、显存管理策略2.2 推理瓶颈往往不在模型本身我做过的几个调优案例里印象最深刻的一个是模型本身算力占用不大但接口整体延迟高得离谱。排查到最后发现问题出在输入数据的预处理环节——每来一个请求服务端都要做一次图像解码、缩放、归一化而这一步跑在CPU上且是串行执行的。GPU在那闲着等数据CPU成了瓶颈整个链路就被拖慢了。这个案例很有代表性。推理性能调优的第一步永远是先定位瓶颈而不是盲目上优化手段。一般来说瓶颈可能出现在以下几个位置数据预处理/后处理CPU密集操作、编解码耗时、数据格式转换经常被忽视。CPU与GPU之间的数据传输小批量请求频繁拷贝数据PCIe传输耗时占比会非常高。模型计算本身算子实现低效、内存访问模式不佳、图优化未开启。推理框架与调度线程数配置不当、显存分配策略不合理、动态shape引起的重编译。服务端网络与IO请求排队、连接池耗尽、序列化/反序列化开销。定位瓶颈有一个很朴素但有效的方法先把模型单独拿出来做一条龙压测逐步拆解每一段的耗时占比。比如你用profile工具看一遍时间线如果发现GPU kernel执行只占了20%时间其余都在数据搬运和CPU处理那砸再多GPU算力也白搭。2.3 用哪个指标判断优化效果调优过程中一定要先定好基准。我推荐的做法是固定同一份测试数据集包含不同长度的输入固定batch size和并发数跑足够多轮取p50/p99延迟同时记录吞吐量。调优前后对比这些数据而不是看单次运气好的结果。我自己做调优时第一件事是在服务里埋好日志记录每次请求的预处理耗时、排队耗时、GPU kernel耗时、后处理耗时。后面所有的优化动作都能用数据说话哪段耗时长就去优化哪段避免凭感觉调参。3. 模型层面的优化从权重到算子的瘦身术3.1 模型量化性价比最高的第一刀模型量化是推理性能调优里回报率最高的手段之一。原理很简单训练时模型权重通常用FP32或FP16存储推理时其实没必要保持这么高的精度把权重从FP32压到FP16能直接减半显存占用从FP16压到INT8还能再减一半。代价是部分任务精度会有轻微下降。实际项目中大模型的KV Cache同样会消耗大量显存。KV Cache量化比如从FP16压到INT8甚至INT4可以显著提升并发能力因为同样的显存可以塞下更多请求的KV缓存。以我在模拟项目X里的一个7B模型为例权重从FP16切到INT8后单卡能处理的并发数从16提升到了28显存占用降低了约45%。量化落地时有两点值得特别注意不是所有算子都适合INT8量化。像LayerNorm、Softmax这类对精度敏感的算子通常保持高精度量化主要集中在矩阵乘法和Embedding层。量化后的模型一定要做精度验证。用一小部分测试集对比量化前后输出差异超过可接受阈值就需要回退部分层或者改用混合精度方案。表不同量化精度对显存和速度的影响7B模型实测精度方案显存占用相对吞吐提升精度损失FP32100%基准1x无FP16/BF16约50%1.6x可忽略INT8约25%2.1x低需验证INT4约12.5%2.8x中需谨慎3.2 剪枝、蒸馏与模型结构精简量化解决了存储和计算强度的问题但很多场景下还需要在结构上做减法这就是模型剪枝和蒸馏的用武之地。模型剪枝的做法是去掉神经网络中对最终输出贡献较小的权重连接或甚至整个通道。当前很多开源模型本身就存在参数冗余剪掉一部分权重后精度下降有限但计算量会明显减少。实际操作中结构化剪枝比非结构化剪枝更适合推理加速因为非结构化剪枝产生的稀疏矩阵在GPU上不太好发挥除非硬件专门支持稀疏计算。模型蒸馏则是用一个大的教师模型去指导一个小学生模型学习让小学生模型在参数量小很多的情况下尽量逼近教师模型的输出。蒸馏后的模型精度可能略低但推理成本下降得非常明显。我见过一个团队把BERT-base蒸馏成三层的小模型在线问答场景延迟从80ms降到了20ms效果还能接受。选择哪种手段要看业务容忍度毫秒级延迟敏感场景优先上蒸馏和小规模模型别硬扛大模型。离线高吞吐场景可以用量化大批次的方案不用太在意单次延迟。精度要求极高场景尽量保留高精度权重只在KV Cache和激活值上做温和量化。3.3 算子融合与计算图优化模型推理时计算图里有很多细碎的算子频繁在GPU上启动内核kernel。每个kernel启动都有固定开销虽然单次只有几十微秒但模型里有几百上千个算子累积起来非常可观。算子融合就是把相邻的几个算子合并成一个减少kernel启动次数同时减少中间结果的读写。最经典的融合案例是把“矩阵乘法偏置激活函数”融合成一个算子。比如Transformer里的Attention计算把QKV映射、缩放、Softmax、输出映射等步骤尽量融合能省掉不少中间显存读写。PyTorch的torch.compile、TensorRT的图优化、ONNX Runtime的graph optimization都在做类似的事。我用torch.compile试过一个12层的Transformer模型在A100上推理延迟直接降了18%且无需改任何业务代码。但要注意torch.compile首次运行会有较长的编译时间服务上线时需要预热的机制否则第一个请求会特别慢。4. 推理引擎与服务架构的选型逻辑4.1 主流推理引擎横向对比选推理引擎是部署中绕不开的决策点。我用过的方案包括PyTorch原生、ONNX Runtime、TensorRT、以及专门的大模型推理框架如vLLM、TGI、SGLang。各有各的优劣势不存在万能选择。引擎优势劣势适用场景PyTorch原生上手快、兼容好、生态全性能一般、显存占用高原型验证、快速迭代ONNX Runtime跨平台、优化好、部署轻部分算子转换有坑通用模型上云、端侧部署TensorRTGPU上性能极致构建时间长、硬件绑定生产环境、固定shape场景vLLM/TGI大模型专用、吞吐极高依赖特定GPU架构对话、生成、大规模并发我比较推荐的生产路径是先用PyTorch做功能和正确性验证再导出ONNX或直接用TensorRT做性能优化。如果模型真的很小或者对上线速度要求极快PyTorch torch.compile也能撑一段时间但后续扩容时大概率还得换引擎。4.2 单机多卡部署时的切分策略模型大到单卡放不下就得考虑多卡部署。常见的有张量并行、流水线并行和数据并行三者解决的问题完全不同。张量并行把一层里的矩阵运算切分到多张卡适合单层计算量极大、显存放不下的场景。缺点是卡间通信频繁对NVLink带宽要求很高。流水线并行把模型按层切分成多段每张卡负责若干层数据按顺序流过各卡。适合层数很深的模型但会出现流水线气泡利用率不一定理想。数据并行每张卡都放完整模型各自处理不同batch的数据最后同步梯度或结果。推理时基本不涉及梯度同步所以扩展性很好。实际部署中这些策略往往组合使用。大模型推理通常先用张量并行解决单卡放不下的问题再用数据并行提升整体吞吐。通信开销是必须重点关注的如果卡间通信瓶颈严重多卡跑的收益可能还不如单卡。我做过一个对比7B模型在单卡上能跑但并发很低切成两卡张量并行后单次延迟反而增加了约10%因为通信开销抵消了算力收益。但对于更大规模的模型比如70B级不多卡部署根本跑不起来通信开销属于必须付出的代价。4.3 动态batch与Continuous Batching传统的静态batching是等一批请求凑够数量再统一推理缺点是等待时间不可控而且batch里长短不一的序列会互相拖累——都得按照最长序列来算浪费严重。大模型推理框架普遍引入了Continuous Batching连续批处理本质是不再要求一个batch内的请求同进同出。某个请求生成完一个token就退出新请求随时可以插入GPU始终在处理有效计算。这个机制对吞吐的提升非常明显。以vLLM为例在同等资源下相同并发压测中吞吐往往是Naive PyTorch实现的数倍。部署时如果想用上Continuous Batching就别自己造轮子了直接选vLLM或TGI这类成熟框架内部已经实现了显存管理和调度逻辑比手写高效得多。5. 运行时参数调优与关键配置5.1 显存管理与缓存策略显存是推理性能最大的物理约束之一。做大模型推理时显存主要消耗在三块模型权重、KV Cache、临时激活值。模型权重基本固定临时激活值随batch和序列长度波动KV Cache则是优化空间最大的部分。几个实用的显存优化思路尽量复用显存框架层面做好内存池避免每次请求都重新分配。vLLM就是通过PagedAttention把KV Cache分块管理大幅减少了碎片和浪费。调整KV Cache策略将KV Cache从FP16降到INT8或INT4或者限制最大序列长度能直接提升并发承载量。开启显存不够时的自动换出部分框架支持把不活跃的请求KV Cache换到CPU内存但换入换出会增加延迟适合吞吐优先的离线场景。用小batch多迭代如果显存紧张与其一次塞大batch导致OOM不如拆分几个小batch控制在显存安全线以内。5.2 线程、并发与批大小设置服务端的线程数和并发设置也是性能调优的关键。PyTorch的CPU线程数默认可能吃满所有核心但在GPU推理场景下CPU线程太多反而会带来上下文切换开销。建议按以下思路设置torch.set_num_threads如果预处理在CPU上执行可以预留一部分CPU核给数据加载剩下的给计算线程。模型服务的max_batch_size不宜盲目设大。batch增大能提升吞吐但延迟会同步上升需要找到吞吐与延迟的平衡点。我一般压测时会从1、2、4、8、16逐级往上试观察p99延迟曲线何时开始拐弯。并发请求数压测时并发太低可能喂不饱GPU太高又可能导致排队加剧。可以用压测工具逐步加压监控GPU利用率和响应时间找到拐点。有一个容易踩的坑动态shape会导致推理框架在运行时不断重新编译或layout变换性能严重劣化。我的做法是能固定shape就固定不能固定就限制为几个离散档位如长度128/256/512/1024框架内做padding到档位长度。虽然会浪费一点算力但换来的稳定性非常值。5.3 预热、模型编译与大模型特有参数部署服务上线的第一分钟往往性能很差。原因是模型首次推理时需要加载权重、建立cuDNN/tensorRT的benchmark、编译计算图。生产环境一定要做预热具体做法是服务启动后用几条具有代表性的数据跑几轮推理把编译和缓存预热到位再开始对外提供流量。大模型推理框架里几个关键参数值得重点调gpu_memory_utilization控制在0.85-0.9之间比较稳妥太低浪费显存太高容易OOM遇到碎片化严重时还需要降一点。max_num_seqs / max_num_batched_tokens决定并发上限需要根据业务峰值设置。设太大会导致显存瞬间爆掉太小则浪费算力。enable_prefix_caching开启后相同的请求前缀比如系统提示词的KV Cache可以复用多轮对话场景收益明显。streaming输出对话场景优先使用流式输出用户感知到的首token延迟会大幅降低。6. 一次完整的推理性能调优案例记录6.1 压测准备与基线数据我在模拟项目X中部署过一个规模中等的对话模型单卡初始配置用的是PyTorch原生服务FP16权重动态batch关闭最大并发16。压测用的是一组平均输入长度512token、输出长度128token的请求共500条。基线数据如下指标数值平均首token延迟820ms平均总延迟6.4s吞吐量2.8 req/sGPU峰值利用率47%显存峰值占用15.2GB看到这个数据第一个直觉就是GPU利用率太低了只有47%说明大量时间在等待数据或者算子没吃满。接下来开始逐项优化。6.2 逐步优化过程与效果第一刀先换推理引擎。我把服务从PyTorch原生换成了vLLM启用Continuous Batching和PagedAttention。仅仅这一步吞吐就从2.8 req/s提升到了5.6 req/s翻了一倍。GPU利用率也升到了72%。原因是动态batch和显存管理带来的收益非常直观。第二刀模型量化。把权重从FP16量化到INT8KV Cache保持FP16。量化后模型吞吐进一步从5.6提升到7.1 req/s显存峰值降到了约11.8GB。513条测试数据里输出质量对比差异基本看不出来。第三刀优化服务端参数。把max_num_seqs从16调高到32gpu_memory_utilization设为0.88同时开启prefix caching。吞吐提升到8.3 req/sp99总延迟稳在7.8s以内。这个时候GPU利用率已经达到86%显存还有约1.5GB余量。第四刀把输入长度限制为128的倍数并关闭动态shape。这个操作对单次推理延迟的降低有一定帮助首token延迟从平均441ms降到了382ms。最终优化后数据指标优化前优化后平均首token延迟820ms382ms平均总延迟6.4s4.1s吞吐量2.8 req/s8.3 req/sGPU峰值利用率47%86%显存峰值占用15.2GB11.8GB整体吞吐提升了接近3倍延迟下降了36%。整个过程没有改一行模型代码完全通过引擎选型、量化、参数调优实现。这也再次验证了那个观点很多性能问题压根不是模型本身的问题而是部署方案没选对、配置没调好。6.3 多场景下的部署建议汇总根据不同的业务场景我建议的部署策略也不同整理成一个速查表场景推荐方案关键配置在线对话/交互vLLM/TGI INT8量化开启streaming、prefix caching大规模离线生产TensorRT 固定shape大batch、高吞吐优先端侧/边缘部署ONNX Runtime 量化压缩体积、CPU多线程优化高精度要求场景FP16/BF16 TensorRT不激进量化只做图优化小模型快速上线PyTorch torch.compile预热、限制并发、避免动态shape需要注意任何时候都不建议直接上线不经过压测的服务。即使方案看起来合理也必须在小流量下压一遍确认真实数据而不是纸面推算。7. 常见问题与排查技巧实录7.1 GPU利用率低总感觉性能没榨干现象GPU利用率只有30%-50%延迟却不低。优先排查以下环节数据加载和预处理是不是在CPU上串行执行如果是试试异步数据加载、多进程预处理或者把预处理算子放到GPU上。请求batch是不是太小小batch喂不饱GPU吞吐自然上不去。是不是存在动态shape导致的recompile观察第一次请求后有没有周期性卡顿有的话就固定shape。是不是CPU线程数设置不合理导致线程切换开销过大。排查工具上我惯用nvidia-smi看实时利用率配合Nsight Systems看完整时间线能非常清楚地看到每个环节的耗时占比。如果没有这类工具也可以用简单的计时埋点把预处理、传输、推理、后处理每一段时间打印出来。7.2 显存OOM与溢出问题显存OOM是部署中最常见的故障之一。OOM不一定代表显存总量不够更多时候是分配策略或者某个突发峰值导致。排查思路先分清是权重放不下还是运行时峰值超了。如果是权重放不下直接量化权重或者换多卡部署。如果是运行期峰值超了调整batch大小、限制max_num_seqs、降低gpu_memory_utilization、缩小或量化KV Cache。还有一种情况是显存碎片化服务跑了一段时间后OOM但重启就好。这是因为不断分配和释放不同大小的显存块碎片越来越多。vLLM这类框架的PagedAttention能大幅缓解碎片问题用PyTorch原生的话可以考虑显存池或定期重启服务的土办法不优雅但管用。7.3 首token延迟高但整体吞吐正常如果首token延迟特别高多半卡在prefill阶段也就是处理输入Prompt阶段。大模型解码分两段prefill把整段输入一次性算完generate阶段才逐token生成。输入越长prefill耗时越高。优化手段包括让模型支持并行prefill某些框架默认支持。缩短输入的无效内容从业务层做输入裁剪。用chunked prefill机制把超长输入拆成小块逐步计算避免一次性算完导致延迟尖刺。开启prefix caching多轮对话和共用system prompt时效果明显。调低并发减少排队等待时间。7.4 并发高时延迟快速劣化并发一高延迟就起飞通常有两个原因一是请求排队时间过长二是显存不够导致KV Cache被换出。应对方法优先保证p99延迟在容忍范围内适当通过限流控制并发数量。开连续批处理避免静态batch带来的等待效应。增加服务实例利用水平扩展分散压力。如果单机已经是极限就需要考虑多卡或分布式部署了。8. 最后的实操心得分享几个我在多次上线部署中学到的经验不算什么高深理论但真的能救命第一性能调优一定要以监控数据为驱动。不要看感觉不要凭经验猜。每个优化动作前后都要有明确的指标对比这样出了问题才能快速回滚也不会白忙一场。第二不要把所有鸡蛋放在一个篮子里。推理引擎、量化方案、服务架构这些组件尽量做成可切换的。我见过一些团队把TensorRT优化后的模型写死进代码里后来模型迭代了TensorRT重新构建要花好几个小时上线节奏被拖得很惨。合理做法是把优化链路自动化模型一变构建流程自动跑一遍产物自动验证。第三注意压测数据的代表性。很多人拿固定长度的输入做压测看起来数据很漂亮一上真实业务就被长短不一的输入打回原形。建议压测数据的长度分布尽量贴近线上真实请求否则调出来的参数很容易在真实场景翻车。第四小步快跑一次只改一个变量。同时换引擎、开量化、改并发配置如果性能有波动根本分不清是哪一步引起的。我习惯一次只调整一项跑一轮压测记录数据然后再动下一项。调优过程会慢一些但每步结论都很扎实。推理性能调优是一个系统工程从模型结构化简、量化、算子融合到推理引擎选型、服务架构设计、运行时参数配置每一环都有文章可做。这篇文章算是我近期实操的一份沉淀也希望能帮你少走一些弯路。如果你手头正好有模型要部署不妨先从基线测试开始一步步来。 AI模型推理性能调优与部署关键实践：从指标到实战
1. 先搞清楚推理性能调优到底在调什么做AI模型部署的同学应该都有同感模型训练完了只是第一步真正让人头疼的是后面那句“上线跑一下”。训练时你关心loss降没降、收敛快不快可一旦进入推理阶段画风就全变了——延迟、吞吐、显存占用、首token耗时、并发能力每一个指标都有可能成为压垮线上服务的最后一根稻草。我见过不少团队把大量精力花在训练调参上结果模型一到推理阶段就各种翻车GPU利用率上不去、请求一多就超时、显存莫名其妙OOM。回头复盘问题往往出在“不知道推理性能的瓶颈到底在哪”这件事上。所以这篇文章想认真聊一聊AI模型推理性能调优与部署建议把我在实际项目中踩过的坑、验证过的方法、以及一些可以直接抄作业的配置方案分享出来。先给这篇文章定个位如果你正准备把训练好的模型部署成线上服务或者已经在部署但性能不理想这篇文章值得你从头看到尾。内容覆盖推理性能指标拆解、常见瓶颈定位、模型优化手段、部署架构选择、运行时参数配置、实测调优过程以及高频故障的排查思路。我会尽量用实际场景说话而不是堆理论。注意文中的所有测试数据和配置参数都来自我本人在某公司内部搭建的模拟项目X中的实操记录硬件环境为单卡和双卡两种方案结论在同类GPU上具备一定的参考价值但不同架构、不同驱动版本下结果会有差异建议以实测为准。2. 推理性能的核心指标与瓶颈拆解2.1 别只看单次延迟这些指标同样重要很多刚接触部署的同学习惯拿“单次推理耗时”来衡量模型快不快但真实线上场景里单次推理耗时只是表象。举个很简单的例子一个接口单次推理只要10ms但只能同时处理1个请求另一个接口单次推理要30ms却能同时处理32个请求。在业务并发较高的时候后者的整体吞吐反而是前者的好几倍用户体验也好得多。推理性能调优时我一般会同时盯住下面几个核心指标延迟Latency从请求发出到拿到完整响应的时间细分下来还包括首token时间TTFT和每token生成时间TPOT。在线业务对延迟特别敏感比如对话类场景首token超过3秒用户基本就会觉得“卡了”。吞吐量Throughput单位时间内能处理的请求数或token数。离线批处理场景更看重吞吐比如批量文档解析、离线生成。GPU利用率这块很多人会忽略。GPU利用率低往往意味着算子没有充分利用硬件或者数据加载/预处理成了瓶颈。显存占用模型权重、KV Cache、中间激活值、CUDA context加起来分分钟能把显存吃满。并发能力服务在同一时刻能支撑的请求连接数直接决定你能扛多大的业务流量。表格整理一下方便对照场景选指标指标适用场景主要瓶颈来源延迟含TTFT/TPOT在线对话、实时交互模型规模、解码方式、算子效率吞吐量离线批处理、数据生产batch size、并发数、显存带宽GPU利用率所有场景数据加载、CPU预处理、算子调度显存占用所有场景模型权重、KV Cache、中间激活并发能力高并发API服务框架线程模型、显存容量、显存管理策略2.2 推理瓶颈往往不在模型本身我做过的几个调优案例里印象最深刻的一个是模型本身算力占用不大但接口整体延迟高得离谱。排查到最后发现问题出在输入数据的预处理环节——每来一个请求服务端都要做一次图像解码、缩放、归一化而这一步跑在CPU上且是串行执行的。GPU在那闲着等数据CPU成了瓶颈整个链路就被拖慢了。这个案例很有代表性。推理性能调优的第一步永远是先定位瓶颈而不是盲目上优化手段。一般来说瓶颈可能出现在以下几个位置数据预处理/后处理CPU密集操作、编解码耗时、数据格式转换经常被忽视。CPU与GPU之间的数据传输小批量请求频繁拷贝数据PCIe传输耗时占比会非常高。模型计算本身算子实现低效、内存访问模式不佳、图优化未开启。推理框架与调度线程数配置不当、显存分配策略不合理、动态shape引起的重编译。服务端网络与IO请求排队、连接池耗尽、序列化/反序列化开销。定位瓶颈有一个很朴素但有效的方法先把模型单独拿出来做一条龙压测逐步拆解每一段的耗时占比。比如你用profile工具看一遍时间线如果发现GPU kernel执行只占了20%时间其余都在数据搬运和CPU处理那砸再多GPU算力也白搭。2.3 用哪个指标判断优化效果调优过程中一定要先定好基准。我推荐的做法是固定同一份测试数据集包含不同长度的输入固定batch size和并发数跑足够多轮取p50/p99延迟同时记录吞吐量。调优前后对比这些数据而不是看单次运气好的结果。我自己做调优时第一件事是在服务里埋好日志记录每次请求的预处理耗时、排队耗时、GPU kernel耗时、后处理耗时。后面所有的优化动作都能用数据说话哪段耗时长就去优化哪段避免凭感觉调参。3. 模型层面的优化从权重到算子的瘦身术3.1 模型量化性价比最高的第一刀模型量化是推理性能调优里回报率最高的手段之一。原理很简单训练时模型权重通常用FP32或FP16存储推理时其实没必要保持这么高的精度把权重从FP32压到FP16能直接减半显存占用从FP16压到INT8还能再减一半。代价是部分任务精度会有轻微下降。实际项目中大模型的KV Cache同样会消耗大量显存。KV Cache量化比如从FP16压到INT8甚至INT4可以显著提升并发能力因为同样的显存可以塞下更多请求的KV缓存。以我在模拟项目X里的一个7B模型为例权重从FP16切到INT8后单卡能处理的并发数从16提升到了28显存占用降低了约45%。量化落地时有两点值得特别注意不是所有算子都适合INT8量化。像LayerNorm、Softmax这类对精度敏感的算子通常保持高精度量化主要集中在矩阵乘法和Embedding层。量化后的模型一定要做精度验证。用一小部分测试集对比量化前后输出差异超过可接受阈值就需要回退部分层或者改用混合精度方案。表不同量化精度对显存和速度的影响7B模型实测精度方案显存占用相对吞吐提升精度损失FP32100%基准1x无FP16/BF16约50%1.6x可忽略INT8约25%2.1x低需验证INT4约12.5%2.8x中需谨慎3.2 剪枝、蒸馏与模型结构精简量化解决了存储和计算强度的问题但很多场景下还需要在结构上做减法这就是模型剪枝和蒸馏的用武之地。模型剪枝的做法是去掉神经网络中对最终输出贡献较小的权重连接或甚至整个通道。当前很多开源模型本身就存在参数冗余剪掉一部分权重后精度下降有限但计算量会明显减少。实际操作中结构化剪枝比非结构化剪枝更适合推理加速因为非结构化剪枝产生的稀疏矩阵在GPU上不太好发挥除非硬件专门支持稀疏计算。模型蒸馏则是用一个大的教师模型去指导一个小学生模型学习让小学生模型在参数量小很多的情况下尽量逼近教师模型的输出。蒸馏后的模型精度可能略低但推理成本下降得非常明显。我见过一个团队把BERT-base蒸馏成三层的小模型在线问答场景延迟从80ms降到了20ms效果还能接受。选择哪种手段要看业务容忍度毫秒级延迟敏感场景优先上蒸馏和小规模模型别硬扛大模型。离线高吞吐场景可以用量化大批次的方案不用太在意单次延迟。精度要求极高场景尽量保留高精度权重只在KV Cache和激活值上做温和量化。3.3 算子融合与计算图优化模型推理时计算图里有很多细碎的算子频繁在GPU上启动内核kernel。每个kernel启动都有固定开销虽然单次只有几十微秒但模型里有几百上千个算子累积起来非常可观。算子融合就是把相邻的几个算子合并成一个减少kernel启动次数同时减少中间结果的读写。最经典的融合案例是把“矩阵乘法偏置激活函数”融合成一个算子。比如Transformer里的Attention计算把QKV映射、缩放、Softmax、输出映射等步骤尽量融合能省掉不少中间显存读写。PyTorch的torch.compile、TensorRT的图优化、ONNX Runtime的graph optimization都在做类似的事。我用torch.compile试过一个12层的Transformer模型在A100上推理延迟直接降了18%且无需改任何业务代码。但要注意torch.compile首次运行会有较长的编译时间服务上线时需要预热的机制否则第一个请求会特别慢。4. 推理引擎与服务架构的选型逻辑4.1 主流推理引擎横向对比选推理引擎是部署中绕不开的决策点。我用过的方案包括PyTorch原生、ONNX Runtime、TensorRT、以及专门的大模型推理框架如vLLM、TGI、SGLang。各有各的优劣势不存在万能选择。引擎优势劣势适用场景PyTorch原生上手快、兼容好、生态全性能一般、显存占用高原型验证、快速迭代ONNX Runtime跨平台、优化好、部署轻部分算子转换有坑通用模型上云、端侧部署TensorRTGPU上性能极致构建时间长、硬件绑定生产环境、固定shape场景vLLM/TGI大模型专用、吞吐极高依赖特定GPU架构对话、生成、大规模并发我比较推荐的生产路径是先用PyTorch做功能和正确性验证再导出ONNX或直接用TensorRT做性能优化。如果模型真的很小或者对上线速度要求极快PyTorch torch.compile也能撑一段时间但后续扩容时大概率还得换引擎。4.2 单机多卡部署时的切分策略模型大到单卡放不下就得考虑多卡部署。常见的有张量并行、流水线并行和数据并行三者解决的问题完全不同。张量并行把一层里的矩阵运算切分到多张卡适合单层计算量极大、显存放不下的场景。缺点是卡间通信频繁对NVLink带宽要求很高。流水线并行把模型按层切分成多段每张卡负责若干层数据按顺序流过各卡。适合层数很深的模型但会出现流水线气泡利用率不一定理想。数据并行每张卡都放完整模型各自处理不同batch的数据最后同步梯度或结果。推理时基本不涉及梯度同步所以扩展性很好。实际部署中这些策略往往组合使用。大模型推理通常先用张量并行解决单卡放不下的问题再用数据并行提升整体吞吐。通信开销是必须重点关注的如果卡间通信瓶颈严重多卡跑的收益可能还不如单卡。我做过一个对比7B模型在单卡上能跑但并发很低切成两卡张量并行后单次延迟反而增加了约10%因为通信开销抵消了算力收益。但对于更大规模的模型比如70B级不多卡部署根本跑不起来通信开销属于必须付出的代价。4.3 动态batch与Continuous Batching传统的静态batching是等一批请求凑够数量再统一推理缺点是等待时间不可控而且batch里长短不一的序列会互相拖累——都得按照最长序列来算浪费严重。大模型推理框架普遍引入了Continuous Batching连续批处理本质是不再要求一个batch内的请求同进同出。某个请求生成完一个token就退出新请求随时可以插入GPU始终在处理有效计算。这个机制对吞吐的提升非常明显。以vLLM为例在同等资源下相同并发压测中吞吐往往是Naive PyTorch实现的数倍。部署时如果想用上Continuous Batching就别自己造轮子了直接选vLLM或TGI这类成熟框架内部已经实现了显存管理和调度逻辑比手写高效得多。5. 运行时参数调优与关键配置5.1 显存管理与缓存策略显存是推理性能最大的物理约束之一。做大模型推理时显存主要消耗在三块模型权重、KV Cache、临时激活值。模型权重基本固定临时激活值随batch和序列长度波动KV Cache则是优化空间最大的部分。几个实用的显存优化思路尽量复用显存框架层面做好内存池避免每次请求都重新分配。vLLM就是通过PagedAttention把KV Cache分块管理大幅减少了碎片和浪费。调整KV Cache策略将KV Cache从FP16降到INT8或INT4或者限制最大序列长度能直接提升并发承载量。开启显存不够时的自动换出部分框架支持把不活跃的请求KV Cache换到CPU内存但换入换出会增加延迟适合吞吐优先的离线场景。用小batch多迭代如果显存紧张与其一次塞大batch导致OOM不如拆分几个小batch控制在显存安全线以内。5.2 线程、并发与批大小设置服务端的线程数和并发设置也是性能调优的关键。PyTorch的CPU线程数默认可能吃满所有核心但在GPU推理场景下CPU线程太多反而会带来上下文切换开销。建议按以下思路设置torch.set_num_threads如果预处理在CPU上执行可以预留一部分CPU核给数据加载剩下的给计算线程。模型服务的max_batch_size不宜盲目设大。batch增大能提升吞吐但延迟会同步上升需要找到吞吐与延迟的平衡点。我一般压测时会从1、2、4、8、16逐级往上试观察p99延迟曲线何时开始拐弯。并发请求数压测时并发太低可能喂不饱GPU太高又可能导致排队加剧。可以用压测工具逐步加压监控GPU利用率和响应时间找到拐点。有一个容易踩的坑动态shape会导致推理框架在运行时不断重新编译或layout变换性能严重劣化。我的做法是能固定shape就固定不能固定就限制为几个离散档位如长度128/256/512/1024框架内做padding到档位长度。虽然会浪费一点算力但换来的稳定性非常值。5.3 预热、模型编译与大模型特有参数部署服务上线的第一分钟往往性能很差。原因是模型首次推理时需要加载权重、建立cuDNN/tensorRT的benchmark、编译计算图。生产环境一定要做预热具体做法是服务启动后用几条具有代表性的数据跑几轮推理把编译和缓存预热到位再开始对外提供流量。大模型推理框架里几个关键参数值得重点调gpu_memory_utilization控制在0.85-0.9之间比较稳妥太低浪费显存太高容易OOM遇到碎片化严重时还需要降一点。max_num_seqs / max_num_batched_tokens决定并发上限需要根据业务峰值设置。设太大会导致显存瞬间爆掉太小则浪费算力。enable_prefix_caching开启后相同的请求前缀比如系统提示词的KV Cache可以复用多轮对话场景收益明显。streaming输出对话场景优先使用流式输出用户感知到的首token延迟会大幅降低。6. 一次完整的推理性能调优案例记录6.1 压测准备与基线数据我在模拟项目X中部署过一个规模中等的对话模型单卡初始配置用的是PyTorch原生服务FP16权重动态batch关闭最大并发16。压测用的是一组平均输入长度512token、输出长度128token的请求共500条。基线数据如下指标数值平均首token延迟820ms平均总延迟6.4s吞吐量2.8 req/sGPU峰值利用率47%显存峰值占用15.2GB看到这个数据第一个直觉就是GPU利用率太低了只有47%说明大量时间在等待数据或者算子没吃满。接下来开始逐项优化。6.2 逐步优化过程与效果第一刀先换推理引擎。我把服务从PyTorch原生换成了vLLM启用Continuous Batching和PagedAttention。仅仅这一步吞吐就从2.8 req/s提升到了5.6 req/s翻了一倍。GPU利用率也升到了72%。原因是动态batch和显存管理带来的收益非常直观。第二刀模型量化。把权重从FP16量化到INT8KV Cache保持FP16。量化后模型吞吐进一步从5.6提升到7.1 req/s显存峰值降到了约11.8GB。513条测试数据里输出质量对比差异基本看不出来。第三刀优化服务端参数。把max_num_seqs从16调高到32gpu_memory_utilization设为0.88同时开启prefix caching。吞吐提升到8.3 req/sp99总延迟稳在7.8s以内。这个时候GPU利用率已经达到86%显存还有约1.5GB余量。第四刀把输入长度限制为128的倍数并关闭动态shape。这个操作对单次推理延迟的降低有一定帮助首token延迟从平均441ms降到了382ms。最终优化后数据指标优化前优化后平均首token延迟820ms382ms平均总延迟6.4s4.1s吞吐量2.8 req/s8.3 req/sGPU峰值利用率47%86%显存峰值占用15.2GB11.8GB整体吞吐提升了接近3倍延迟下降了36%。整个过程没有改一行模型代码完全通过引擎选型、量化、参数调优实现。这也再次验证了那个观点很多性能问题压根不是模型本身的问题而是部署方案没选对、配置没调好。6.3 多场景下的部署建议汇总根据不同的业务场景我建议的部署策略也不同整理成一个速查表场景推荐方案关键配置在线对话/交互vLLM/TGI INT8量化开启streaming、prefix caching大规模离线生产TensorRT 固定shape大batch、高吞吐优先端侧/边缘部署ONNX Runtime 量化压缩体积、CPU多线程优化高精度要求场景FP16/BF16 TensorRT不激进量化只做图优化小模型快速上线PyTorch torch.compile预热、限制并发、避免动态shape需要注意任何时候都不建议直接上线不经过压测的服务。即使方案看起来合理也必须在小流量下压一遍确认真实数据而不是纸面推算。7. 常见问题与排查技巧实录7.1 GPU利用率低总感觉性能没榨干现象GPU利用率只有30%-50%延迟却不低。优先排查以下环节数据加载和预处理是不是在CPU上串行执行如果是试试异步数据加载、多进程预处理或者把预处理算子放到GPU上。请求batch是不是太小小batch喂不饱GPU吞吐自然上不去。是不是存在动态shape导致的recompile观察第一次请求后有没有周期性卡顿有的话就固定shape。是不是CPU线程数设置不合理导致线程切换开销过大。排查工具上我惯用nvidia-smi看实时利用率配合Nsight Systems看完整时间线能非常清楚地看到每个环节的耗时占比。如果没有这类工具也可以用简单的计时埋点把预处理、传输、推理、后处理每一段时间打印出来。7.2 显存OOM与溢出问题显存OOM是部署中最常见的故障之一。OOM不一定代表显存总量不够更多时候是分配策略或者某个突发峰值导致。排查思路先分清是权重放不下还是运行时峰值超了。如果是权重放不下直接量化权重或者换多卡部署。如果是运行期峰值超了调整batch大小、限制max_num_seqs、降低gpu_memory_utilization、缩小或量化KV Cache。还有一种情况是显存碎片化服务跑了一段时间后OOM但重启就好。这是因为不断分配和释放不同大小的显存块碎片越来越多。vLLM这类框架的PagedAttention能大幅缓解碎片问题用PyTorch原生的话可以考虑显存池或定期重启服务的土办法不优雅但管用。7.3 首token延迟高但整体吞吐正常如果首token延迟特别高多半卡在prefill阶段也就是处理输入Prompt阶段。大模型解码分两段prefill把整段输入一次性算完generate阶段才逐token生成。输入越长prefill耗时越高。优化手段包括让模型支持并行prefill某些框架默认支持。缩短输入的无效内容从业务层做输入裁剪。用chunked prefill机制把超长输入拆成小块逐步计算避免一次性算完导致延迟尖刺。开启prefix caching多轮对话和共用system prompt时效果明显。调低并发减少排队等待时间。7.4 并发高时延迟快速劣化并发一高延迟就起飞通常有两个原因一是请求排队时间过长二是显存不够导致KV Cache被换出。应对方法优先保证p99延迟在容忍范围内适当通过限流控制并发数量。开连续批处理避免静态batch带来的等待效应。增加服务实例利用水平扩展分散压力。如果单机已经是极限就需要考虑多卡或分布式部署了。8. 最后的实操心得分享几个我在多次上线部署中学到的经验不算什么高深理论但真的能救命第一性能调优一定要以监控数据为驱动。不要看感觉不要凭经验猜。每个优化动作前后都要有明确的指标对比这样出了问题才能快速回滚也不会白忙一场。第二不要把所有鸡蛋放在一个篮子里。推理引擎、量化方案、服务架构这些组件尽量做成可切换的。我见过一些团队把TensorRT优化后的模型写死进代码里后来模型迭代了TensorRT重新构建要花好几个小时上线节奏被拖得很惨。合理做法是把优化链路自动化模型一变构建流程自动跑一遍产物自动验证。第三注意压测数据的代表性。很多人拿固定长度的输入做压测看起来数据很漂亮一上真实业务就被长短不一的输入打回原形。建议压测数据的长度分布尽量贴近线上真实请求否则调出来的参数很容易在真实场景翻车。第四小步快跑一次只改一个变量。同时换引擎、开量化、改并发配置如果性能有波动根本分不清是哪一步引起的。我习惯一次只调整一项跑一轮压测记录数据然后再动下一项。调优过程会慢一些但每步结论都很扎实。推理性能调优是一个系统工程从模型结构化简、量化、算子融合到推理引擎选型、服务架构设计、运行时参数配置每一环都有文章可做。这篇文章算是我近期实操的一份沉淀也希望能帮你少走一些弯路。如果你手头正好有模型要部署不妨先从基线测试开始一步步来。