GPU利用率上不去这件事我是真头疼过。一排A100在那儿跑着nvidia-smi一看利用率不到20%算力没吃满钱却照花不误。别说什么性能优化连老板那关都过不去。这两年我前后调过不少推理项目从CV模型到LLM服务都碰过踩坑踩到怀疑人生也沉淀了不少可复用的经验。这篇就把我在实际项目中验证过的GPU推理利用率优化策略完整捋一遍从瓶颈定位、模型优化、引擎选型到服务端调度、数据管线掰开揉碎讲清楚适合做推理部署、在线服务优化的算法工程师和SRE同学参考。1. 为什么GPU利用率上不去先看清瓶颈在哪1.1 指标定义你看到的“利用率”可能骗了你很多人一上来就盯nvidia-smi里的GPU-Util看到数字低就断定GPU没吃满。这个指标其实有个大坑GPU-Util表示的是采样周期内SM上有活动的时间占比它只反映“忙不忙”不反映“忙得有没有效率”。我遇到过一种典型场景GPU利用率的数字能到80%以上但吞吐量就是上不去。用Nsight Systems抓一下才发现SM确实在工作但跑的是大量的非张量核心指令或者频繁地在等待内存返回真正执行Matrix Multiply/Conv这类重计算的占比很低。换句话说SM是“瞎忙”Tensor Core压根没醒。所以我们不能只看GPU-Util这一个数要结合云监控或DCGM里的SM Active、SM Occupancy、Tensor Active、Memory Throttle这些细粒度指标一起判断。如果你只想快速判断最实用的一个组合是GPU-Util高但Tensor Active低基本可以断定算子实现有问题或者模型推理引擎没用上Tensor CoreGPU-Util低但Memory Util高大概率在等数据。1.2 推理工作负载的特征为什么跟训练不一样推理和训练的优化方向根本不一样这个不认识清楚后面全是白调。训练阶段追求的是吞吐最大化数据流水线可以无限叠buffer多卡并行随便堆因为训练对个别step的延迟不敏感。但推理不一样推理是典型的延迟敏感任务尤其在线的场景单个请求从进去到出来必须在几十毫秒内完成。更麻烦的是推理场景下模型的batch通常很小。在线服务里一个请求就是一个batch1GPU卡的优势要在数据并行度和矩阵块足够大的时候才能发挥出来。batch1时往往算力还没铺开数据搬运和算子启动的开销反而占了主导。我用一个生活化的类比来解释训练像是在大型工厂里批量生产同一种零件流水线拉满机器永远在转效率最高。推理则像一家餐厅现场点单每桌点的菜不一样后厨必须快速出一桌菜这时候哪怕灶台很多切配、洗锅、摆盘的时间也会拖慢出菜速度。GPU推理利用率低归根结底就是两个问题一是单次计算任务太“小”太“碎”不足以填满GPU的并行流水线二是数据准备和调度的时间超过了计算本身的时间。下面每一节都是围绕这两个问题展开。2. 模型级优化从源头减少计算量2.1 精度量化与压缩FP32到INT8/INT4的加速逻辑模型量化是提高GPU利用率性价比最高的一招因为它同时解决了两个问题计算变快了、显存占用和带宽开销变低了。推理引擎里INT8在Tensor Core上的理论算力通常是FP32的4倍以上。拿常见的BERT系列模型举例我试过把FP32直接转成INT8推理吞吐提升大约3倍显存占用下降约60%到70%而精度损失在绝大多数NLU任务上只有不到1个百分点。这个收益是肉眼可见的。常用量化方案有后训练量化PTQ和量化感知训练QAT。线上推理项目我的建议是优先PTQ因为它不需要重新训练模型几分钟就能完成。具体做法是收集一批有代表性的校准数据跑一遍推理让模型统计每一层的激活值范围然后选择校准策略比如entropy、percentile、mse把浮点权重和激活值映射到INT8范围。实操里有几个点要格外注意校准集要有代表性不要只挑文本短的样本要看线上真实的输入分布。有个同学用纯均匀分布的校准集上线后长尾样本精度掉得惨不忍睹。校准的batch不要太小尽量让每一层看到足够多的激活值统计样本。敏感层比如最后的分类层、attention的softmax之后如果INT8量化掉点严重可以做混合精度只保留这些层为FP16。在具体工具链上TensorRT的INT8校准器已经封装好了ONNX Runtime的onnxruntime quantization工具也支持static和dynamic量化。如果你用的是PyTorch模型可以直接用torch.ao.quantization做PTQ然后导出INT8模型。我个人偏好先在ONNX Runtime上做静态QDQ量化再交给TensorRT跑这样可控性好很多。2.2 算子融合与图优化减少Kernel启动开销GPU推理里有一个容易被忽视的隐形开销Kernel启动。每一个算子在GPU上执行之前CPU都要下发一条Launch命令这个命令本身的耗时虽然只有微秒级但如果一个模型里有几百个算子串行启动一遍就是几毫秒。而且很多小算子本身计算只要几微秒启动开销反而占了主要成本。打个比方Kernel启动就像派人去仓库取东西如果每个小零件都单独跑一趟大部分时间都浪费在路上算子融合则是把几个相邻的小零件装进同一辆车一次运回来。常见的融合包括ConvBNReLU融合成一个算子、LayerNorm里所有元素操作融合、Multi-Head Attention里QKV三个线性层合并成一次大矩阵乘、残差连接与激活融合等。TensorRT在做推理优化时就是干这个事它会扫描整张计算图自动做层融合ONNX Runtime的graph optimization也自带基础融合。如果你想确认图优化有没有生效打开Neural Network Inference的profiler看看优化的前后Kernel个数和单步耗时。我做过一个纯Transformer结构的中型模型原始PyTorch直接推理大概要启动700多个Kernel经过TensorRT图优化后降到不到200个端到端延迟降了接近40%。这种开销在短文本、小模型上特别明显在长序列大模型上会被掩盖掉一部分但也值得处理。3. 推理引擎与运行时选择别在错误的引擎上浪费GPU3.1 引擎选型对比原生框架、TensorRT、ONNX Runtime、vLLM很多人习惯直接用PyTorch的torch.inference_mode()上线追求方便。但原生框架默认不做算子融合、不做图优化GPU利用率和专门的推理引擎差一大截。我在推理服务化的项目里基本都是走ONNX Runtime或者TensorRT路线只有在快速验证模型效果时才用PyTorch直接跑。下面这张表是我在多个项目里总结的常见推理引擎适配经验引擎优势劣势推荐场景PyTorch原生灵活、上手快Kernel开销大、显存占用高原型验证、动态图调试ONNX Runtime跨平台、静态图优化、支持多种加速器复杂模型图优化效果弱于TensorRT通用部署、CPU/GPU兼顾TensorRT极致延迟、算子融合强、INT8优化成熟转换周期长、对动态shape支持有限高吞吐、低延迟的在线GPU服务vLLM专为LLM设计、PagedAttention省显存、连续批处理只适配GPT类结构LLM在线推理服务选引擎不能盲目跟风一定要先看模型结构、动态性要求、部署环境。我踩过一个坑某个CV模型用了大量的自定义算子在TensorRT里无法直接支持不得不手写插件。如果当初先用ONNX Runtime验证一遍可能根本不需要这么麻烦。所以我现在的选型逻辑是模型结构规整、以线性层和标准卷积为主优先TensorRT算子比较特殊、频繁升级、需要快速部署优先ONNX Runtime。3.2 关键运行时参数的调优要领引擎选好了参数不调、环境不配GPU利用率一样上不去。这里有三个参数是我每次必调的。第一是batch_size相关配置。TensorRT在构建engine时要指定max_batch_size这个值不能拍脑袋定。如果线上请求稀疏配一个很大的max_batch_size也不会自动提升利用率反而多占显存。最关键的是配套的优化策略比如TensorRT的OptimalBatchSize和动态Profile要根据实际流量配置。第二是工作线程数和CPU绑核。每个推理请求的前处理、后处理、数据拷贝都在CPU上跑如果线程反复切换、跨NUMA访问CPU侧变成瓶颈后GPU就一直等着。我习惯把推理进程绑定到物理核留出独立核给数据预处理和框架调度减少上下文切换损耗。第三是显存分配策略。TensorRT默认在创建engine上下文时就会把工作显存预分配好这一步在初始化阶段要做掉不要把显存分配留到每次推理请求中。PyTorch侧也要注意torch.cuda.empty_cache()别看名字是“清缓存”它在推理服务里可能引发后续分配的抖动不是优化手段。4. 服务端批处理与调度策略把GPU塞满的艺术4.1 动态Batching从“单个请求”到“攒批处理”前面提到了推理是点单制但点单制不代表不能拼桌。动态Batching的思路是把一小段时间窗口内到达的多个请求合并成一个batch再一次性送进GPU计算。这种做法能显著提高GPU利用率和整体吞吐代价是增加了部分请求的等待延迟。举例来说假设模型单卡处理batch1的延迟是10ms处理batch8的延迟是25ms。如果不做动态批处理8个请求串行处理要80ms如果攒成一个batch只需要25ms左右理想情况下整体吞吐直接翻了3倍多。虽然最前面那个请求多等了15ms的攒批时间但只要总延迟还在SLA内这个交换非常划算。设计动态Batching服务时有几个关键参数max_batch_size最大合并数、max_wait_time最大凑批等待时间。这两个参数就是延迟和吞吐之间的天平。max_batch_size设得太大容易让单批的计算时间过长后面的请求等太久max_wait_time设得太大则请求体验明显变差。我建议用小流量压测来确定参数不要靠感觉。先固定max_batch_size从0到max_wait_time扫描画出吞吐和P95延迟的曲线挑一个P95延迟还在可接受范围的最高吞吐点。另外有个很容易被忽略的细节动态批处理不是简单把请求堆在一个列表里跑一次模型就行它要求模型的输入维度是定长的或者能通过padding对齐还要求batch维度支持动态变化。很多PyTorch模型对动态batch支持不友好总是报错我建议在做服务封装时就把模型输入显式声明为shape不固定的并提前写好padding和mask的逻辑。4.2 请求并发与多流用足GPU的并行能力GPU一次可以并行执行多个CUDA流不同流之间互不阻塞。如果一个推理服务只在一个流上串行提交Kernel那么就算模型内可以并行的地方再多也只能排队执行整个GPU的并行能力被丢了大半。我见过一个项目GPU利用率只有20%但并发请求量已经很大排查发现服务端把所有推理都放在同一个CUDA流上执行成了天然瓶颈。改造方式很简单为每个请求或每批请求分配独立的CUDA流保证不同请求的Kernel可以重叠执行。PyTorch侧可以用torch.cuda.Stream来管理但更推荐在像Triton这样的推理服务框架里直接配instance数和并发数框架会帮你调度多流并发。如果再往上走还可以用多进程/多实例的方式每个进程独立加载模型副本各自处理一批请求整卡利用率更容易被顶上去。这种方式对显存比较大的卡比较友好显存小的卡要注意模型副本的显存开销。还有一个调度层面的技巧在线和离线任务混部。如果单纯放在线推理其它时间GPU大多是闲置的可以错峰混入离线批量任务把“碎片化”利用率拉满。比如夜间低峰期跑离线提特征任务把一整天的GPU平均利用率水平拉高一大截。5. 数据加载与I/O优化CPU侧的瓶颈同样要命5.1 数据管线拆解请求从网络到GPU的完整路径我排查GPU利用率低问题时经常发现GPU本身没问题问题出在数据根本送不到GPU手上。推理数据的完整路径大致是请求到达 → CPU解析、预处理tokenize、裁剪、resize、归一化→ 内存拷贝到显存 → GPU计算 → 结果拷回内存 → 后处理返回。这条链路里任何一环慢了GPU都会因为“没活干”而空闲等待。我实测过一个BERT服务的CPU预处理如果从20ms涨到40msGPU利用率可能直接从45%掉到20%不到。因为GPU通常几毫秒就把计算做完了剩下的时间全在等CPU准备下一批数据。怎么判断瓶颈在CPU侧很简单把预处理逻辑临时屏蔽掉直接喂假数据跑压测。如果GPU利用率立刻飙升说明预处理链路就是瓶颈如果还是很低再往GPU侧查。这个方法虽然粗糙但在实际排查里非常高效。5.2 实用优化手段缓存、并行加载、异步传输CPU侧优化我认为有三个最有效的手段数据缓存、多进程预处理、异步数据拷贝。数据缓存方面如果线上有大量的重复文本重复请求第一次做预处理时就把tokenize结果或图像tensor缓存下来后续请求直接命中缓存省掉重复计算。这个收益在短文本场景特别明显tokenize本身看着轻量但大数据量下累积起来也很可观。多进程预处理方面Python的GIL是单进程下预处理无法并行的大坑。把预处理拆到独立的进程池里用队列把处理好的结果发给推理主进程实测可以提升预处理吞吐3倍以上GPU不再因为等着CPU预处理而干等。异步传输方面传统流程是CPU准备完数据后马上复制到显存这个复制是同步的拷贝期间GPU和CPU有一方会等待。优化方式是让CPU预先准备下一批数据当前批在GPU上计算的同时把下一批数据通过异步拷贝接口提前搬到显存实现CPU预处理、PCIe传输、GPU计算三者的流水线重叠。在PyTorch里可以用tensor.pin_memory()配合non_blockingTrue实现锁页内存的异步拷贝。我给一个基本配置示例假设你用的是Triton Inference Server数据加载时不需要自己写流水线框架原生支持dynamic_batching和max_queue_delay你要做的就是设计好输入输出格式。如果自研服务可以按“生产者-消费者”模式构建预处理进程是生产者排队队列是有界队列推理进程是消费者严格限制队列积压深度防止CPU预处理过快导致内存膨胀或过慢导致GPU饥饿。6. 监控与瓶颈定位实战如何量化GPU的真实状态6.1 观测体系搭建从利用率指标到端到端延迟优化GPU利用率的前提是能量化它否则就是凭感觉瞎调。我在项目里搭的监控体系分三层第一层是机器侧指标DCGM提供的GPU Utilization、SM Active、Tensor Active、Memory Utilization、GPU Memory Used、PCIe RX/TX。这一层告诉你GPU忙不忙、显存吃多少、数据传输是否饱和。第二层是服务侧指标QPS、P50/P95/P99延迟、请求排队长度、批处理成功率。这一层告诉你用户的真实感受和调度质量。第三层是Profiler单次抓取Nsight Systems和NVIDIA Nsight Compute用于定位具体是哪个算子耗时、哪个环节空闲。有人会问为什么GPU Utilization都不看了还装这些因为只靠一个GPU-Util没法还原完整因果链。我举一个真实排查过的虚拟案例某服务GPU-Util稳定在30%QPS却已经不低了加机器也没用。用Nsight一抓发现模型里有几个元素级算子在频繁启动噪音太大把那些算子融合后GPU-Util直接跳到65%QPS也涨了40%。监控里还有一个经常被忽略的关键指标叫ATTActive Tensor Time它反映Tensor Core实际工作的时间占比。在推理优化时我建议把它作为比GPU-Util更核心的追踪指标ATT一旦能稳定在50%以上基本可以说明GPU在被高效使用。6.2 一个完整的优化案例复盘从18%到72%我拿一个纯虚构但非常典型的项目来做复盘。某公司有个在线推理服务跑的是一个10亿参数左右的文本分类模型业务高峰期QPS要求200部署了4张A100但机器监控显示GPU利用率平均只有18%老板很不满意。他们的推理服务直接用PyTorch加载FP16模型没有批处理CPU预处理也是单进程同步。第一步我给服务换了推理引擎从PyTorch切到TensorRT开启FP16同时把模型转成静态batch8的engine。这一步跑完GPU-Util从18%升到了35%。第二步在服务端加了动态Batchingmax_batch_size8、max_wait_time15ms明显感觉到利用率提升峰值到了50%左右但还有波动。第三步用Nsight抓了一遍发现预处理进程在队列里大量积压处理不过来。我把预处理改成多进程并加了预处理结果缓存GPU-Util稳定在63%。第四步把模型进一步做INT8量化但保留敏感层为FP16。量化后单batch延迟继续下降吞吐提升明显Tensor Active占比升到了55%以上整卡GPU-Util稳定在72%QPS从200撑到了将近800。这个案例里每一步看起来动作不大但组合起来效果惊人。核心思路就是先把模型做小做快再把请求聚合起来喂给GPU最后保证CPU侧不断供。四个环节缺一个利用率都会上不去。6.3 常见问题与避坑速查表实践过程中我整理了下面这份避坑速查表是按内存里的教训一条条攒出来的每次优化前我都会过一遍现象原因排查方式解决方案GPU-Util低但显存占用高模型过多或显存碎片化对比已加载模型与显存用量减少常驻模型数量开启显存复用GPU-Util高但QPS不涨SM做无用功重计算占比少Nsight检查Tensor Active和算子耗时图优化、算子融合、换推理引擎GPU-Util忽高忽低动态Batching参数不合理或CPU预处理抖动对齐流量与批处理统计调整max_wait_time优化CPU管线加并发后利用率不涨CUDA流或锁竞争瓶颈查看并行Kernel重叠情况为请求分配独立流改用多实例显存OOM偶发动态shape带来显存预分配波动观察峰值显存曲线固定profile范围显存池化预分配小batch请求延迟合格但吞吐上不去没用动态批处理压测对比各batch延迟开启动态Batching并压测调参INT8精度下降明显校准集偏差或敏感层被量化按分位数对比精度换校准策略敏感层保留FP16我个人在实际操作中的体会是GPU利用率优化不是一锤子买卖而是一个持续逼近的过程。每次改动后都要用监控数据验证并且改动要小步快跑不要一次性把所有优化全堆上去否则出了问题根本定位不到是哪一步引入的。另外务必在项目初期就把监控和profiling体系搭好不要等到利用率崩了再回来补成本会高出好几倍。如果现在你的GPU利用率也卡在低位建议先别急着买新卡按这套思路从模型、引擎、批处理、数据管线、监控五个维度逐项排查大概率能省下一大笔算力成本。