最近在帮一个推荐项目做推理调优模型不大单卡也能跑但线上P99延迟就是压不下来。排了两天发现瓶颈根本不在算力——准确说是推理阶段大量时间都花在“搬参数”上了GPU核心多数时候都在等数据。这个现象在AI模型推理性能优化里非常典型只盯着显卡算力是远远不够的访存带宽、调度开销、显存复用、框架本身的损耗每一层都可能成为瓶颈。这篇文章我把“AI模型推理性能瓶颈与优化策略”整个拆开来讲从瓶颈定性、模型侧优化、系统侧调度到一套可以直接照做的实战流程和排查方法全部是基于我自己反复调模型踩坑之后的沉淀。适合正在做模型部署、服务化推理、延迟优化或者准备上大模型的工程师参考。文中不会堆一堆看不懂的概念每个点都会说清楚“为什么这么做”和“我实际做下来是什么效果”。1. 先搞清楚推理瓶颈不是“算力不够”那么简单1.1 训练和推理两者的性能目标完全不同很多人习惯拿训练阶段的经验来推理阶段用这是第一道坎。训练时一个batch塞几十上百条样本流水线跑满追求的是整体吞吐显卡利用率高、算力吃满就是好事。但推理不一样尤其是线上服务用户发一个请求从进入系统到返回结果这个端到端时间才是核心指标。同一个GPU训练时能把矩阵乘算得飞起推理时却很可能因为batch太小而让算力大量闲置。训练可以忍受250ms的单步迭代因为那是为了收敛精度推理端超过200ms用户就开始感知到卡顿。训练可以动态调整batch大小来提升效率推理却被响应时间死死约束着。所以推理优化的目标函数从来不是“显卡利用率最高”而是“在延迟约束下的吞吐最大化”。我之前踩过的坑就是拿训练时GPU利用率90%来推断推理也能跑满结果上到线上发现利用率不到20%延迟还飘得厉害。后来才反应过来训练是饱和作业推理是稀疏请求两者工作负载模型根本不一样。1.2 计算密集型与访存密集型先给瓶颈定性定位推理瓶颈的第一步不是翻代码而是判断这个模型在GPU上跑的时候到底是“算不过来”还是“等数据等太久”。我用一个生活化的例子说明把GPU核心想象成厨师把参数和中间特征想象成食材。如果厨师切菜、炒菜本身很慢那是计算瓶颈如果厨师动作很快但食材要从很远的仓库一趟趟拉过来大部分时间都在等食材那就是访存瓶颈。大多数DNN推理场景都属于后者。以一个大模型为例假设有10亿参数FP16存储下就是2GB。每个请求进来模型要把这2GB参数从显存里读一遍参与计算而GPU的显存带宽是固定的比如某型号显卡是2TB/s光读一次参数就要1ms左右。如果模型结构复杂、小算子多参数反复读写访存耗时就会成倍放大算力反而吃不饱。判断方法很简单跑一遍profiling看算子的耗时占比。如果卷积、矩阵乘这些“大算子”本身耗时长是计算密集如果耗时都花在数据搬运、小的elementwise操作上就是访存密集。这两类问题的优化方向完全不同——前者要削减计算量后者要减少参数访存次数。搞反了就是白忙活。1.3 为什么GPU利用率高不代表性能好很多优化报告喜欢拿“GPU利用率95%”说事但对推理而言这个数字有强烈的误导性。我见过一个模型GPU利用率看着不低但是端到端延迟里有一大半耗在框架侧Python解释器调用、动态图调度、小的kernel反复启动这些开销根本不体现在GPU利用率上。打个比方GPU利用率衡量的是“炒菜时火有多旺”但用户感知的是“从点菜到上菜”的全部时间。厨房里火再旺如果每个菜都要重新点火、重新找锅铲上菜速度依然很慢。这也是为什么同样一个模型放在PyTorch动态图里跑和转成推理引擎跑延迟能差2到3倍——前者每个算子都走一遍解释、调度、分发的流程后者把这些流程全部省掉算子之间还做了融合。所以看指标不能只看GPU利用率还要关注端到端延迟、单请求的GPU时间占比、kernel启动次数、CPU与GPU之间的数据传输量。后续章节我会详细说怎么用profiling去把这几个指标量化出来。2. 模型侧的三板斧量化、剪枝、蒸馏2.1 量化从FP16到INT8访存量直接砍半量化是目前性价比最高的推理加速手段没有之一。原理特别简单把模型参数和中间激活从FP16每个数占2字节变成INT8每个数占1字节。同样是读一遍参数访存量直接少一半如果计算用的是INT8矩阵乘很多显卡上还能吃到Tensor Core的加速计算侧也提速。但量化不是无脑转换。我最开始做量化的时候直接把一个训练好的模型从FP16切到INT8结果显示精度掉了2个百分点业务方直接不接受。后来调了几轮才搞清楚问题在于校准数据的选择——校准要拿覆盖真实分布的验证集去统计激活值的范围然后确定缩放系数。如果校准集太偏、太少算出来的范围就不准量化误差会被放大。实操上我建议先做per-channel的权重量化再做per-tensor的激活量化两层分开处理风险更可控。如果某些敏感层量化后掉点明显就用混合精度关键层保持FP16非关键层INT8。不要追求“全模型INT8”的一刀切实际部署时混合精度往往才是最稳的方案。2.2 剪枝优先做结构化剪枝别一上来就做稀疏剪枝的思路是把模型里“不太重要”的参数删掉。关键问题是“怎么删”。非结构化剪枝是把权重矩阵里接近0的元素置零产生一个稀疏矩阵理论上计算量大幅减少但GPU对稀疏矩阵的加速很有限还得依赖特殊的稀疏kernel和推理库搞不好收益没吃到多少工程复杂度倒是上去了。我做过的项目里真正落地的是结构化剪枝直接剪掉整个channel、整个attention头。比如Transformer模型里某些head学到的模式重复度很高去掉一两个对精度影响很小但矩阵维度变小后计算量和访存量都实打实降低了。还有一种更简单的做法是减少隐藏层维度配合蒸馏一起做效果比单独剪枝好得多。剪枝的坑在于“剪完要不要微调”。如果不微调精度基本都会掉微调几轮能拉回来一部分。线上资源充裕的话我一般会做“剪枝 - 知识蒸馏 - 量化”三件套推理速度能提升好几倍精度损失控制在可接受范围。2.3 蒸馏小模型接替大模型的稳妥路知识蒸馏说白了就是训练一个小模型去模仿大模型的输出。大模型当老师小模型当学生学生不仅要学正确答案还要学老师的“软性判断”和“概率分布”。有一个容易忽略的点蒸馏对小模型收益最大的往往不是精度而是鲁棒性。我做过一个实验直接训练的小模型在某类长尾样本上表现不稳定但用蒸馏出来的小模型同样的参数规模长尾样本的稳定性好了不少。原因可能是大模型的soft label携带了类别之间的相似性信息这类信息在one-hot标签里是不存在的。蒸馏在实际部署中的定位通常是“前菜”——先把模型变小变轻后面再上量化和算子融合。反过来顺序就麻烦了先把模型量化了再去蒸馏噪声太大学生模型很难学。这个顺序我建议记住先蒸馏再剪枝最后量化。2.4 算子融合消掉看不见的CPU调度开销算子融合我不太愿意把它归到“模型侧”因为它不改变模型结构而是改变执行方式。但它带来的加速非常直观。深度学习模型本质是一张计算图每个节点是一个算子。如果不做融合PyTorch会按顺序逐个执行GPU计算完一个算子把结果写回显存然后再启动下一个kernel中间还有CPU的调度和框架的检查开销。一次推理下来几十个算子的调度损耗累加起来非常可观。算子融合的思路是把多个连续的小算子合并成一个kernel。比如LayerNorm包含多个elementwise操作完全可以合成一个算子来处理省去中间结果的反复读写再比如多头注意力里的QKV三个线性变换原本是三个GEMM可以拼成一个大的GEMM一次算完。我见过一个模型只做了QKV融合和LayerNorm融合延迟就降了20%到30%这个收益几乎不需要调参就能拿到。这类优化通常由推理引擎来自动完成比如ONNX Runtime的图优化、TensorRT的层融合。所以如果你还在用原生的PyTorch做线上推理第一步不是去改模型结构而是先过一遍推理引擎的融合优化通常能白捡一大截性能。3. 系统侧的调度优化把每一毫秒都抢回来3.1 动态批处理延迟和吞吐怎么平衡线上推理系统和单次推理有一个本质区别请求是动态到达的。如果每个请求单独占用GPU跑一遍模型GPU利用率自然低得可怜。动态批处理Dynamic Batching就是把一小段时间窗口内到达的多个请求攒起来拼成一个batch一次性计算然后再拆开返回结果。这里面有一个关键参数攒批等待时间。等太长吞吐上去了但延迟超预期等太短batch太小加速不明显。我一般把它设成模型单次推理时长的10%到20%举个例子模型单跑一次要20ms等待窗口设3-4ms既不显著影响P99又能让吞吐量成倍增长。另外注意动态批处理要求模型本身支持任意batch shape输入。如果你的模型里写了固定batch的reshape那就得提前改掉。还要对“长请求”做兜底——等太久还没凑够批就先把手头的批次发出去保证延迟上限可控。3.2 连续批处理解锁高吞吐的关键动态批处理对普通DNN推理已经很有效但对自回归生成类模型来说还不够。自回归模型的推理分为prefill预填充处理用户输入的整个序列和decode逐token生成两个阶段每个请求的生成长度不一样。传统的静态批处理会一直等待整个batch所有序列生成完才释放显存和计算资源短的序列生成完也只能干等着GPU算力浪费严重。连续批处理Continuous Batching把这个逻辑改成了“迭代级调度”每完成一个request的生成就把这个位置立即让给一个新的request。相当于排队打饭从“一整批人打完再放下一批”变成了“谁打完谁走、下一人立刻补上”。这个优化对LLM服务的吞吐提升非常显著实测在同等延迟约束下吞吐量可以提升2到3倍。当前主流的大模型推理框架基本都内置了连续批处理。如果你自己写调度逻辑核心是要把请求拆成迭代单位并在每个迭代结束后检查有无完成的请求。因为这个逻辑比较绕我建议尽量别重复造轮子直接用开源框架的能力把精力放在业务适配和瓶颈排查上。3.3 KV Cache与显存复用大模型推理的命门大模型推理和普通DNN有一个很大的不同自回归生成过程会把历史token的Key和Value缓存在显存里避免每次生成都重复计算前面的注意力。这就是KV Cache。模型越大、支持的上下文越长KV Cache占用的显存就越夸张。KV Cache带来的第一个难题是显存碎片化。不同请求的长度不一样如果每个请求都按最大长度预分配缓存显存会被白白浪费一大块。现在业界比较成熟的做法是PagedAttention这种“按页分配”的思路类似操作系统的分页机制显存按小块分配需要多少用多少不够再分配新页大幅降低显存浪费也能容纳更多并发请求。实际优化KV Cache的方向有三个一是显存预留策略给KV Cache划出独立池子并做监控二是量化KV Cache把缓存从FP16压到INT8能省一半显存对精度影响通常很小三是缓存复用同一个用户的多轮对话直接复用历史缓存避免重复计算。这三招组合下来单机并发能力能翻一番。3.4 推理引擎怎么选几个主流的真实对比做推理优化绕不开推理引擎我直接给结论没有一个引擎是万能的关键是按场景来选。如果你的模型上线后用TensorRT通常能拿到最好的GPU性能和算子融合效果代价是转换过程偶尔会踩坑有些算子不支持需要改写如果模型需要跨平台、跨硬件部署ONNX Runtime更省心兼容性好图优化也很成熟如果做大规模语言模型服务化主流的方案是vLLM内置PagedAttention和连续批处理吞吐表现在社区里验证较充分。我自己最常用的组合是先用ONNX Runtime做一次优化验证确认加速比和精度没问题再切到TensorRT做最终打磨。这样能快速发现模型里有没有“对加速不友好”的算子。如果某个算子转换失败先尝试替换成等价实现实在不行就在图里保留FP16精度。引擎选型本身也是优化流程的一环选对了事半功倍选错了可能卡上半个月。4. 实战一套完整的瓶颈定位与优化落地流程4.1 第一步用Profiling拍清楚时间花在哪优化不能靠猜。前面我一直在强调profiling这里说具体怎么操作。以GPU推理为例最直接的是用nsys和ncu这两个工具nsys看整体时间线能直观看到CPU和GPU的活动时间、kernel的启动频率、数据传输的时间占比ncu看每个kernel的详细指标包括显存带宽利用率和计算吞吐。如果你用PyTorch的话也可以先用自带的profiler把算子级别的耗时排名拉出来快速定位耗时大户。我自己的标准动作是这样先看端到端延迟的分布再单独测“GPU计算时间”和“前后处理时间”两个相减就能知道框架调度和数据搬运到底吃掉了多少毫秒。如果数据搬运占30%以上优先优化预处理和结果回传如果GPU kernel之间有大段空白重点看算子融合和引擎优化。这个阶段最重要的一件事是“记录基线”。优化前后的延迟分布、吞吐、显存占用、GPU利用率都要留档不只是为了汇报更是为了每次改动后能快速对比出收益和回退。4.2 第二步定位瓶颈优先级不要眉毛胡子一把抓拿到profiling结果后我习惯把问题归成三类并按照收益从高到低排序第一优先级框架调度和数据搬运开销。这类问题改善空间大、改动成本低往往通过切换推理引擎或算子融合就能一下子提速很多。第二优先级访存密集型算子。需要从模型结构下手量化、剪枝都能显著减少访存量。第三优先级计算密集型算子。说明模型本身的计算量确实大考虑蒸馏换成小模型或者升级硬件。这个优先级顺序很重要。如果一上来就做量化但实际瓶颈其实在CPU预处理上那量化带来的收益会全部被预处理延迟吃掉线上延迟几乎没变化。我见过不少团队在优化时先选了“看着高级”的方案结果收益甚微问题就是优先级排错了。我的建议是花最多精力在最耗时的环节上其他环节只要没有明显异常就先放着。优化是一个“投入产出比”的游戏不在关键路径上烧时间。4.3 第三步一个推荐模型从200ms到45ms的优化记录下面是我最近帮忙调的一个推荐模型案例脱敏处理后用来说明整套流程怎么落地。初始状态模型本身不大大概几亿参数线上P99延迟200msGPU利用率不足20%平均QPS已经撑不住业务增长。第一步profiling发现端到端200ms里CPU特征预处理占60ms模型GPU推理占90ms结果后处理占20ms剩余30ms花在Python框架调度和数据拷贝上。这个结构说明GPU根本没吃饱瓶颈在CPU侧和框架侧。于是调整方案先把特征预处理从Python重构成C算子并在GPU上直接计算部分特征预处理从60ms降到15ms接着把模型从PyTorch动态图换成ONNX Runtime走图优化再切到TensorRT做算子融合GPU推理从90ms降到40ms最后叠加INT8量化和动态batching吞吐翻了3倍延迟又压缩了5ms。最终该服务的P99从200ms降到45ms左右GPU利用率提升到60%以上。这个案例里没有用到任何“魔法”级的技术核心就是按瓶颈优先级一步步来。4.4 验收标准上线前看哪些指标才不会翻车优化做完了怎么判断能不能上线我建议至少看这五个指标延迟分布P50、P95、P99、吞吐量QPS/TPS、GPU利用率、显存峰值、稳定性相邻时段性能抖动。重点说延迟分布千万别只看平均延迟。有些优化操作会把少数请求的延迟拖得特别高平均数据看起来还行但线上瓶颈往往在P99。我习惯把P99作为硬指标P95做参考P50做趋势判断。另外显存峰值必须留存档出现过优化后延迟低了但显存快爆了的情况上线几分钟就OOM非常危险。稳定性方面建议在压测环境用真实流量回放跑一小时以上看延迟曲线是否平坦。只跑几分钟的验收基本没用冷启动、缓存预热、显存碎片的累积效应都会在持续运行后暴露出来。5. 常见问题与排查技巧实录5.1 问题速查表高延迟、低吞吐、显存OOM我把实际优化中遇到过的高频问题整理成一张速查表遇到对应现象可以直接对照排查现象可能原因排查方法与解决方向GPU利用率高但延迟高批处理设置过大队列排队时间过长调整动态批处理等待窗口和batch上限GPU利用率低但延迟高瓶颈在CPU预处理或数据搬运profiling看CPU-GPU时间占比优化预处理首次请求特别慢CUDA上下文初始化、显存预分配增加预热机制服务启动时跑一次假请求吞吐量上不去请求过于碎片化batch凑不满打开动态批处理评估连续批处理显存OOM并发请求多KV Cache膨胀开启分页显存管理做KV Cache量化量化后精度大幅下降校准集不够代表性扩大校准集覆盖敏感层退回FP16延迟波动剧烈显存碎片累积或并发争抢定期重启或做显存整理预留缓冲这张表说起来挺简单但每一条背后我都踩过坑。比如“首次请求慢”这个问题一度把我折腾了好几天压测都美滋滋一上生产就被用户反馈首个请求超时后来才发现是服务启动后没有做推理预热第一个请求被迫承担了昂贵的初始化开销。5.2 几个容易翻车的细节有两个细节我特别想提。第一个是优化流程里的“复测陷阱”只要模型代码、引擎版本、GPU驱动任一变化都要重新跑性能基线。曾经为了一个小特性升级了推理引擎版本结果某些算子的kernel选择变了P99直接飙升由于没有留存旧版本的基线数据排查了两天才定位到。这个教训直接促使我养成了“每次改动完立刻记录基线”的习惯。第二个细节是并发参数的设置不能靠拍脑袋。并发数、队列长度、超时时间三者强耦合并发设太高会让显存吃紧设太低则让算力闲置。我的经验是先用理论值估算显存余量除以单请求显存占用得到并发上限再往下调20%到30%留出安全缓冲。线上值用A/B测试慢慢逼近最优而不是一次到位。最后分享一个我自己常用的排障小技巧在优化版本上线前故意把老版本和新版本放到同一个压测环境里跑同一条流量观察两者的延迟曲线差异。如果新版本在某个流量峰值下延迟飙高说明它的弹性不如老版本这时候宁可选择延迟略高但更稳定的方案。推理优化是一场长跑稳定性永远排在极致性能前面。说实话做推理性能优化最忌讳的就是“一把梭”。看到别人的经验贴说量化能提速多少、换引擎能提速多少就以为自己也能拿同样的收益——其实每个系统的瓶颈分布都不一样。我自己的体会是把profiling做扎实把瓶颈优先级排清楚再按部就班地动手优化方案最终都会收敛到那条最合适的路径上。中间可能踩坑但有基线数据在手回退和调整都不慌。