1. 从能跑到跑得稳AI系统性能工程到底在解决什么很多人第一次接触AI系统性能工程是从一个很具体的场景开始的模型在开发机上跑得好好的一上生产环境就各种问题——推理延迟忽高忽低、GPU利用率上不去、并发一上来就OOM、批处理吞吐量远低于预期。这时候大家才意识到把模型训练出来只是第一步让它在真实业务负载下稳定高效地运行是另一套完全不同的功夫。AI系统性能工程的核心说白了就是回答三个问题资源花在哪了、瓶颈卡在哪了、怎么用最小的代价把瓶颈挪开。它跟传统后端性能优化最大的区别在于AI系统的负载特征非常特殊——计算密集、显存敏感、请求长度方差极大、批处理策略直接影响吞吐和延迟的平衡点。你不能简单套用加机器加缓存那套思路很多时候加机器反而让问题更复杂。这篇内容适合三类人看一是刚把模型部署上线、发现性能不达标的算法工程师二是负责AI平台稳定性、天天被延迟告警追着跑的后端或运维同学三是想系统理解AI系统性能分析方法论的技术负责人。我会尽量用实际排查思路和可复现的操作来讲而不是堆概念。需要先建立一个认知AI系统性能工程不是调参玄学它有一套相对清晰的观测—假设—验证—收敛的闭环。你观测到什么指标异常提出什么假设用什么手段验证最后怎么确认优化生效这个链路走通了性能问题就不再是碰运气。2. 先把观测做对AI系统性能指标的采集与解读2.1 为什么大多数人的性能观测一开始就是错的我见过太多团队的性能监控面板上面只有CPU使用率、内存占用、QPS这几条曲线。对传统Web服务来说这够了但对AI系统来说这些指标几乎无法定位问题。原因很简单AI推理的瓶颈通常在GPU上而GPU的利用率、显存占用、SM占用率、显存带宽这些关键指标传统监控根本不采集。更隐蔽的一个坑是指标采样粒度。AI推理的延迟可能是几十毫秒级别如果你用15秒或1分钟的平均值去看所有毛刺都被抹平了你看到的是一条平稳的曲线但用户实际感受到的是间歇性的卡顿。我建议延迟类指标至少用P50、P95、P99三个分位数同时看采样窗口压到秒级甚至更细。还有一个常见误区是把GPU利用率高当成好事。GPU利用率100%不代表系统健康它可能意味着请求在排队、显存快爆了、或者你在做大量无效计算。利用率要结合吞吐量和延迟一起看才有意义。2.2 一套可落地的指标分层采集方案我把AI系统的性能指标分成四层从下到上依次是硬件层、运行时层、服务层、业务层。每层的关注点不同采集工具也不同。层级关键指标常用采集手段关注重点硬件层GPU利用率、显存占用、显存带宽、温度、功耗厂商提供的设备查询工具、系统级监控是否存在硬件瓶颈或降频运行时层算子耗时、CUDA内核执行时间、显存分配次数框架自带的profiler、运行时追踪计算图哪里最耗时服务层请求延迟分位数、吞吐量、队列长度、批大小分布服务框架指标、自定义埋点调度和批处理是否合理业务层端到端响应时间、成功率、超时率业务监控、链路追踪用户实际体验硬件层的采集最直接的方式是用设备厂商提供的查询接口定期拉取。比如在推理服务里每隔一秒记录一次显存占用和利用率落到时序数据库里。这里有个实操细节采集本身不能成为性能负担查询频率太高会干扰被测系统我一般控制在1秒一次压测时甚至放宽到2秒。运行时层的profiling要谨慎使用。框架自带的profiler开启后开销可能达到20%以上绝对不能在生产环境长期开着。正确做法是在预发环境复现问题用profiler抓一段短时间的trace定位到具体算子后再关掉。服务层的埋点是最有价值的。我习惯在请求进入和返回时各打一个时间戳同时记录这次请求的输入长度比如token数或图片分辨率。这样你才能回答延迟高是因为请求变长了还是因为系统变慢了这个关键问题。2.3 解读指标时最容易踩的三个坑第一个坑是把相关性当因果。你看到GPU利用率上去了、延迟也上去了就以为是GPU不够用。但真实原因可能是批处理策略把太多请求攒在一起导致单个请求等待时间变长GPU只是被动地处理更大的批次。这时候加GPU没用要改的是批处理窗口。第二个坑是忽略冷启动和预热。AI服务刚启动时模型加载、显存分配、算子编译尤其是用了即时编译的框架都会让前几十个请求特别慢。如果你把这段数据混进统计里P99会被严重污染。我的做法是服务启动后先跑一批预热请求等指标稳定了再接入流量。第三个坑是只看平均值不看分布。平均延迟50毫秒听起来不错但如果P99是2秒那1%的用户体验就是灾难。AI系统的延迟分布往往是长尾的因为输入长度、批大小、显存碎片都会造成波动。分位数是必看的。3. 定位瓶颈从延迟曲线反推系统卡在哪一环3.1 延迟分解把端到端时间拆成可归因的几段性能优化的第一步永远是定位而定位的核心手段是延迟分解。一个AI推理请求的端到端时间大致可以拆成这几段请求排队等待、数据预处理解码、缩放、tokenize、批处理攒批、模型前向计算、后处理解码输出、格式化、网络传输。我通常会在代码里给每一段打上时间戳跑一轮压测后统计各段的占比。经验上如果模型前向计算占比超过80%那优化重点在模型和硬件如果预处理或后处理占比异常高那问题往往出在CPU侧的代码效率上跟GPU没关系。举个我实际遇到的例子一个图像推理服务端到端延迟200毫秒但GPU计算只占30毫秒。分解后发现图片解码和缩放花了120毫秒全在CPU上单线程跑。后来把预处理改成多进程并行加批量化端到端直接降到60毫秒。这个案例说明不要一上来就盯着GPUCPU侧的预处理经常是隐藏的瓶颈。3.2 用排队论视角理解为什么并发一高就崩很多人不理解为什么并发从10涨到50延迟不是线性增加而是指数爆炸。这背后是排队论在起作用。当系统利用率接近100%时排队时间会急剧上升。公式上排队时间大致与 利用率/(1-利用率) 成正比。利用率0.5时排队时间是服务时间的1倍利用率0.9时是9倍利用率0.99时是99倍。这个规律对AI系统的指导意义是不要把系统压到满负荷运行。留出20%到30%的余量延迟才能保持稳定。如果你发现系统在某个并发点之后延迟陡增那基本就是接近饱和了要么扩容要么优化单请求耗时。批处理是AI系统特有的一个变量。增大批大小能提升GPU吞吐因为并行度更高但会增加单个请求的等待时间要等批次攒满。这里存在一个吞吐和延迟的权衡曲线。我的经验是在线服务用小批次加短等待窗口离线批处理用大批次。在线服务的批处理窗口一般设几毫秒到几十毫秒超过这个范围用户就能感知到延迟了。3.3 显存AI系统最容易被忽视的硬约束显存是AI系统区别于传统服务的核心约束。它不像内存那样可以随便扩GPU显存是固定的而且碎片化问题严重。显存不足的表现往往不是直接报错而是性能骤降——因为系统开始频繁地在显存和内存之间换入换出。排查显存问题我关注三个数峰值显存占用、稳态显存占用、显存碎片率。峰值和稳态的差距越大说明显存管理越激进风险越高。碎片率可以通过对比最大可分配块和总空闲显存来估算如果总空闲很多但最大可分配块很小那就是碎片严重。减少显存碎片有几个实用手段一是预分配显存池避免运行时频繁申请释放二是固定输入尺寸比如把图片统一缩放到固定分辨率避免动态shape导致的显存重分配三是控制并发请求数别让太多请求同时占用显存。这些手段我在多个项目里验证过效果立竿见影。4. 优化手段的取舍哪些该做哪些是伪优化4.1 模型层面的优化量化、蒸馏、算子融合模型层面的优化收益通常最大但代价也最需要评估。量化是把浮点权重和激活值转成低精度表示常见的有INT8和FP16。INT8量化理论上能带来2到4倍的吞吐提升和显存节省但精度损失需要实测验证。我的做法是先在验证集上对比量化前后的指标差异如果掉点在接受范围内再上线同时保留一个FP16的兜底版本。知识蒸馏是用大模型教小模型适合对延迟极度敏感的场景。但蒸馏需要重新训练周期长而且小模型的上限受限于大模型的能力。我一般只在明确知道延迟预算卡死、且业务能接受一定精度损失时才考虑。算子融合是框架层面的优化很多推理框架已经自动做了。你需要关注的是有没有融合失败的算子比如某些自定义算子或动态控制流会打断融合。用profiler看计算图如果发现大量小算子单独执行那就是融合没生效可以考虑手动改写或换框架。4.2 服务层面的优化批处理、并发、缓存服务层面的优化见效快、风险低是我优先动手的地方。动态批处理是核心手段但要调好参数。批处理窗口太短攒不满批次GPU利用率低窗口太长延迟高。我通常从5毫秒起步根据实际批大小分布调整。并发控制要跟显存和计算资源匹配。并发太高会导致显存溢出和排队太低则资源闲置。一个实用的方法是做压测找到延迟开始明显上升的并发点然后把生产并发设在这个点的70%左右。缓存在AI系统里要慎用。模型推理的结果缓存命中率通常不高因为输入很少完全重复。但有些场景可以缓存比如固定的系统提示词对应的KV缓存、或者embedding结果。缓存的关键是设计好key既要能命中又不能因为key太粗导致返回错误结果。4.3 那些看起来很美但实际没用的优化我踩过不少伪优化的坑这里列几个典型的。盲目增大批大小批大小超过某个点后GPU计算已经饱和再增大只会增加延迟吞吐不再提升。过度并行把请求拆成多个子任务并行处理听起来能加速但子任务间的同步开销和显存竞争可能让总时间更长。频繁的显存整理有些框架会在每次推理后整理显存这本身就很耗时应该关掉让框架自己管理。判断一个优化是不是伪优化标准很简单在真实负载下压测看端到端指标有没有改善。任何只在微基准测试里有效、一到真实场景就失效的优化都不值得投入。5. 压测与验证怎么确认优化真的生效了5.1 压测流量要尽量贴近真实分布压测最大的陷阱是用均匀分布的请求去打系统。真实流量里输入长度是长尾分布的有大量短请求和少量超长请求。如果你压测时全用固定长度的请求得到的性能数据会严重偏乐观。我的做法是从生产环境采样一批真实请求脱敏后做成回放集。压测时按真实的时间间隔和分布回放。如果拿不到真实数据就手动构造一个混合分布70%短请求、20%中等、10%长请求这样更接近实际。压测还要分阶段先低并发跑基线确认功能正常再逐步加压找到性能拐点最后在拐点附近持续跑一段时间看指标是否稳定。稳定性比峰值性能更重要一个能扛住峰值但跑十分钟就崩的系统没有实用价值。5.2 建立优化前后的对照实验每次优化都要有对照。我的习惯是记录优化前的基线指标延迟分位数、吞吐、显存峰值优化后在同一套压测流量下再跑一遍对比差异。如果优化涉及多个变量尽量一次只改一个否则无法归因。有个细节容易被忽略环境一致性。优化前后的压测必须在同一台机器、同一套依赖版本、同样的后台负载下进行。我见过因为压测时后台在跑别的任务导致数据完全不可比的案例。压测前先确认机器干净没有其他进程抢资源。5.3 上线后的持续观测与回归预警优化上线不是终点。AI系统的性能会随着流量模式变化、模型更新、依赖升级而漂移。我建议建立性能回归预警把关键指标P99延迟、吞吐、显存峰值设阈值超过就告警。同时定期比如每周跑一次标准压测跟历史数据对比发现漂移及时处理。还有一个实战经验保留性能档案。每次优化记录改了什么、预期收益、实测收益、副作用。时间长了这就是团队的宝贵资产下次遇到类似问题能快速参考避免重复踩坑。6. 几个真实场景下的性能问题排查链路6.1 场景一延迟周期性抖动每隔几分钟出现一次尖峰这个问题我遇到过两次表现是P99延迟每隔三五分钟突然飙高持续十几秒后恢复。第一次排查时怀疑是流量突增但看QPS曲线很平稳。后来把延迟曲线和系统指标对齐时间轴发现尖峰时刻显存占用也同步上升。进一步排查发现是某个定时任务在跑它会加载一批数据做预处理占用了大量显存导致推理服务显存不足触发换入换出。解决方案是把定时任务和推理服务隔离到不同进程甚至不同机器问题消失。这个案例的教训是AI服务的性能问题不一定来自服务本身同机其他任务可能是元凶。排查时要把机器上所有进程的资源占用都纳入视野。6.2 场景二吞吐上不去GPU利用率只有40%一个文本生成服务压测时GPU利用率死活上不去吞吐远低于预期。用profiler抓trace后发现GPU大部分时间在等待等待的原因是CPU侧的tokenize成了瓶颈。tokenize是纯CPU操作单线程处理请求一多就排队。解决方案是把tokenize改成多进程并行并且提前批量处理。改完后GPU利用率提到85%吞吐翻了近一倍。这个案例说明GPU利用率低不一定是GPU的问题很可能是上游供给不足。要顺着数据流往上游找。6.3 场景三显存溢出但显存占用看起来没满有个服务报显存溢出但监控显示显存占用只有70%。这就是典型的显存碎片问题。总空闲显存够但没有一块连续的大显存能满足新的分配请求。解决办法是开启显存池预分配并且在服务启动时就把显存池设成固定大小。另外把动态shape的输入统一成几个固定档位比如短、中、长三档减少运行时显存重分配。改完后溢出问题再没出现过。排查这类问题的关键是不要只看总占用要看最大可分配块。很多监控工具不显示这个指标需要自己写代码查询。7. 我在AI性能工程里踩出来的几条经验做AI系统性能工程这几年最大的体会是性能问题很少是单一原因往往是多个因素叠加。你优化了一个瓶颈下一个瓶颈立刻浮现这是个持续迭代的过程不要指望一次优化解决所有问题。第二条经验是先测量再优化永远不要凭直觉。我见过太多人一上来就说肯定是GPU不够结果加了GPU发现没用。花在观测和定位上的时间最终都会以更高的优化效率回报你。第三条是关注长尾别被平均值骗了。AI系统的用户体验由P99甚至P999决定平均值好看没有意义。所有优化都要看分位数指标有没有改善。第四条是留余量。系统跑到90%以上利用率时延迟会变得极不稳定。生产环境留20%到30%的余量是保证稳定性的基本要求。最后一条性能优化要有业务视角。不是所有延迟都值得优化也不是所有吞吐都值得追求。搞清楚业务能接受的延迟预算和成本约束在约束内找最优解比盲目追求极致性能更有价值。有时候把延迟从100毫秒优化到50毫秒的投入远不如把这部分资源用来提升系统稳定性划算。