在做AI系统的性能工程时最怕一个错觉拿着一张“GPU利用率打满”的截图就认为性能已经没有问题了。实际排查过一轮线上服务之后你就会发现GPU利用率和用户体验之间还隔着显存带宽、内存拷贝、预处理耗时、排队调度、框架开销一大串东西任何一个环节冒出来都能让P99延迟翻倍而GPU利用率看着还挺正常。所以这个系列走到第二篇我想认真聊一聊“瓶颈定位”和“专项优化”这件事——上一篇讲清楚了怎么建立基线、怎么搭观测体系这一篇就围绕实际优化过程中最常见的卡点、工具和取舍分享一些可以直接复用的做法。这篇文章适合正在做模型推理服务、训练任务加速或者给AI平台做性能调优的同学。你会看到一套从指标拆解到根因定位的方法路径也会看到推理优化、训练数据管道、分布式通信这几类典型场景里的实操手段和踩坑记录希望能帮你少走一些弯路。1. 性能工程不是“调参数”而是一套系统化拆解方法很多人把性能优化理解为“把某个参数调大调小再试一轮”这个思路在单一组件上可能有效放到整个AI系统里就很危险。因为AI系统的性能瓶颈是流动的今天卡在模型推理明天卡在数据加载后天可能是网关排队和下游超时把整体延迟拖慢了。如果不先把系统拆解清楚你就会一直被“表面瓶颈”牵着走。1.1 先定义清楚“性能”延迟、吞吐、成本三件事聊优化之前先得把“性能”这个词拆开。在AI系统里性能至少包含三个维度延迟单个请求从发出到拿到结果的时间重点关注P50、P95、P99。P99尤其重要因为它代表“最差的那批用户体验”。吞吐单位时间能处理的请求数或Token数通常用QPS每秒请求数或TPS每秒Token数衡量。成本完成同样任务消耗的GPU卡数、显存量和电力。在降本增效的大环境下这个维度越来越关键。这三个维度互相牵制想压低延迟往往会牺牲吞吐想疯狂加大吞吐P99延迟可能失控想省GPU卡就得接受排队时间变长。做性能工程本质是在这个三角里找到当前业务最合适的平衡点。我见过很多团队一开始就要求“延迟越低越好、吞吐越高越好、成本越省越好”这种目标没法落地因为它是互相矛盾的。正确的做法是先定业务SLO比如“P99延迟小于300ms单卡吞吐不低于500 QPS”然后让系统朝着这个SLO去优化。1.2 端到端视角把一次AI请求拆成七段一个AI请求从进来到最后返回结果很少只有“GPU计算”这一步。以常见的在线大模型推理服务为例一次完整请求要经过客户端到网关的网络传输网关路由和鉴权请求预处理文本清洗、Tokenize、Prompt拼接排队等待等前一个请求释放GPU资源GPU推理prefill阶段与decode阶段输出后处理Detokenize、格式校验、安全过滤响应返回很多性能问题根本不发生在“GPU推理”这一段。我遇到过P99延迟从300ms涨到2s的案例查到最后是网关层做了一次超时的重试底层模型本身并没有变慢。所以做性能工程必须养成端到端拆解的习惯——从用户视角出发把响应时间拆到每一段量化每一跳的耗时找出真正的“大头”。2. 瓶颈定位先量化再优化别拍脑袋优化最大的忌讳就是凭感觉。特别是一些经验丰富的同学看到“GPU利用率不高”就推荐“加大batch size”看到“显存占用高”就推荐“换小模型”这些建议在某些场景下是对的但如果不做量化分析很容易把问题带偏。正确路径永远是先测出来再定位最后才动手优化。2.1 建立一套分层的性能观测指标体系想要定位瓶颈先得有“尺子”。我在实际项目中至少会拉这样一张指标清单层级关键指标常见采集方式网关/入口请求量、超时率、重试率Nginx日志、网关监控应用/服务P50/P95/P99延迟、活跃线程数Prometheus Grafana推理引擎Prefill耗时、Decode耗时、排队等待耗时Triton/vLLM内置指标GPU资源利用率、显存使用量、显存带宽、SM活跃度DCGM Exporter、nvidia-smi系统资源CPU使用率、磁盘IO、网络带宽、内存node_exporter、dstat数据管道加载耗时、预处理耗时、队列积压自定义埋点关键点在于每一层指标都要和“请求”关联上。比如看到GPU利用率是80%你得知道这80%是为哪个批次的请求服务的看到P99延迟涨了你得能定位涨在哪一段。如果指标是割裂的比如只知道GPU利用率高但不知道每个请求的平均排队时长每次排查都要重新翻日志效率极低。2.2 profiling工具怎么选从粗到细的排查顺序定位瓶颈是一个漏斗过程。我会按“从系统级到代码级、从外围到核心”的顺序逐层收窄范围系统级先用top、htop、dstat看CPU、内存、IO、网络是否有异常。比如CPU飙到100%但GPU在摸鱼大概率瓶颈在预处理或调度逻辑。GPU级用nvidia-smi dmon或 DCGM 看GPU利用率、显存、温度、功耗。重点看“GPU利用率的波动曲线”如果是一条锯齿状波形说明GPU在一阵忙一阵闲后面往往藏着等待逻辑。内核级用ncuNVIDIA Nsight Compute分析kernel函数层面的耗时和SM利用率用nsys看时间轴上CPU与GPU的同步、内存拷贝事件这是判断“是不是GPU在等CPU”的利器。代码级Python侧用py-spy抓调用栈C侧用perf看火焰图。搞不清线程卡在哪的时候一把火焰图比读半天源码都直观。这套顺序我用了很长时间基本能覆盖90%的瓶颈定位场景。核心思路是“先看外围再看核心”因为系统级的排查最便宜GPU kernel分析虽然精细但成本高没必要一上来就上重器。2.3 一个典型瓶颈案例GPU在等数据而不是在算数据说一个我印象特别深的排查案例。线上一个CV模型推理服务GPU利用率一直在40%-60%之间波动吞吐不达标。团队第一反应是“batch size不够大”改成动态batch之后利用率涨到了70%但延迟反而变差了——因为请求在排队等batch凑满。我用nsys对一次推理请求做了time-line分析发现GPU kernel之间的空闲时间很长尤其是每次推理前都有一次HtoDHost to Device拷贝。再往上层查发现预处理是在Python侧用OpenCV做的每张图要经过resize、归一化、通道转换然后在CPU上转成内存连续的张量再拷贝到GPU。这部分耗时占到整个推理pipeline的35%而且由于Python的GIL多个预处理线程根本没真正并行起来。最终方案是把预处理改成GPU算子用CUDA实现的resize和normalize同时把数据加载放到独立进程通过共享内存传递Tensor。改造之后GPU利用率稳定在95%以上P95延迟降低了接近一半。这个案例给我最大的教训是看到GPU利用率低第一反应不应该是“加大batch”而应该是“看看GPU到底在等什么”。很多时候GPU是饿了不是不想干活。3. 推理服务优化延迟、吞吐与成本的平衡术推理服务是AI系统性能工程的主战场。和训练相比推理对延迟更敏感、流量波动更大、硬件利用率更难做高。这一节聊聊我在推理侧用得最多、见效最明显的三块动态批处理、算子级优化、量化取舍。3.1 动态批处理别让请求排队等batch静态batchfixed batch的思路很直接攒够N个请求再一起跑。问题显而易见——如果流量稀疏请求就要一直等着如果流量陡增batch会过大导致单次推理时间拉长。动态批处理continuous batching解决的就是这个痛点请求到达后立即插入到当前正在执行的那个batch里一个请求完成就立刻移除始终让GPU“满载运行”。很多推理框架已经内置了动态批处理比如vLLM的continuous batching、Triton的dynamic batching。落地时注意两个参数max_batch_size不是越大越好。batch太大单次迭代时间变长每个请求的感知延迟都会升高。建议从能压满GPU利用率的batch size开始往上试探P99延迟的拐点。max_queue_delay控制请求最多等多久。设得太小batch凑不齐就频繁执行吞吐上不去设得太大延迟就会恶化。我习惯从50ms开始调结合业务SLO做取舍。实测下来动态批处理对“短请求多、并发波动大”的聊天类场景收益最明显吞吐通常能提升2-3倍。3.2 算子融合与CUDA Graph把kernel开销压下去GPU执行一个算子的开销分为两部分真正计算的时间和kernel launch的时间。当模型层数很多、算子比较碎的时候kernel launch开销会被放大到不可忽略——尤其在小batch、延迟敏感的场景里几千次launch加起来甚至比计算本身还慢。算子融合的思路是把多个连续算子合并成一个kernel减少launch次数和中间显存读写。这一块现在很多框架做了自动化比如PyTorch的torch.compile和Triton Inference Server的算子融合基本不用手写CUDA。但要注意融合不是永远有收益。有些算子在融合后由于占用寄存器太多反而降低了SM利用率。所以做完融合一定要对比实测别只看“kernel数量变少了”就觉得是优化。CUDA Graph是另一项“免费”的性能红利。它可以把一整个推理计算图捕获成一张图之后每次执行只需要replay省去大量CPU侧的调度开销。对decoder这种固定形状的计算尤其有效。我在LLM服务里开启CUDA Graph之后单次decode的CPU调度耗时降了50%以上。代价是显存占用会增加一些所以小显存卡上需要权衡。3.3 INT8量化与KV Cache用精度换吞吐要算清楚账量化是推理优化里绕不开的话题。INT8量化能让显存占用降低一半左右同时在带宽瓶颈型场景下明显提升吞吐。但“能提多少”和“掉多少点精度”必须实测不同模型差异极大。我在实际项目里一般遵循这样的原则先做PTQ训练后量化用一小批真实业务数据跑一下精度对比如果掉点可接受就直接上。如果PTQ掉点太明显再考虑QAT量化感知训练成本高一些但精度保持好得多。只对重计算密集的层做量化比如Linear和Attention的QKV投影LayerNorm、Softmax这类精度敏感算子保持FP16。这样能在精度和收益之间取平衡。KV Cache的管理也是一块隐藏的性能空间。LLM推理时KV Cache要占一大块显存Cache不足会导致显存溢出或被迫降低并发。要不要开PagedAttention、KVCache的复用策略怎么定都会直接影响在线服务的吞吐。这块建议直接依赖推理框架的实现vLLM、SGLang都做得挺成熟自己要关注的是给KV Cache预留多少显存以及max_model_len设多大——这两者的比例直接决定你能支撑的最大并发。3.4 并行策略的选择Tensor Parallel与数据并发的取舍当单张卡放不下模型或吞吐不够的时候就要考虑多卡并行。推理场景里常用的有Tensor ParallelTP把模型参数切分到多张卡每张卡算一部分。优点是单请求延迟低缺点是通信开销大且多卡利用率难做满。数据并行DP/ 多实例每个GPU放一份完整模型各处理各的请求。吞吐扩展性最好但显存门槛高。我的经验是同一个服务实例里优先做数据并行只有当单张卡放不下模型时才被迫引入TP。而且TP的并行度不宜过大——实践里2路或4路TP比较常见8路TP的通信开销会吃掉不少算力收益。如果你用的是vLLM这类框架里头的tensor_parallel_size参数就控制这个调参的时候注意观察通信占比不要盲目堆大。4. 训练性能工程数据管道和分布式通信常常是被忽视的大头训练侧的性能优化很多人的第一反应是“看GPU利用率”。但训练场景下GPU利用率低绝大多数原因不在GPU计算本身而在数据管道的“喂饭速度”和分布式通信的“握手成本”。4.1 数据管道让GPU吃上热饭数据加载这条链路是训练性能工程里最容易恢复收益的地方。典型问题有磁盘IO慢、解码慢、预处理占用CPU太多、DataLoader的num_workers不够、不同进程之间的均匀性差。建议按这个顺序排查和优化多进程加载PyTorch的DataLoader里num_workers设置为CPU核数的2-4倍。太少会导致每轮迭代都在等数据。预处理放GPU如果能用torchvision.transforms的GPU版本或cuDNN算子就把resize、normalize搬到GPU上。CPU上的预处理是数据管道的最大隐性瓶颈。预取prefetch开启prefetch_factor让数据在训练迭代开始前就加载到内存/显存。效果是让空闲等待消失。用TFRecord/WebDataset这类格式替代大量小文件几千个小文件随机读取极慢合并成大文件后随机读取效率提升非常明显。开启pin_memoryTrue锁页内存能大幅加速CPU到GPU的数据拷贝。还有一个容易被忽略的点数据增强逻辑越复杂数据管道越容易成为瓶颈。有些增强操作比如随机裁剪、色彩抖动在CPU上的开销比一个GPU step还长这时候可以考虑把一部分增强逻辑移到GPU算子里面去。4.2 分布式训练通信占了墙钟时间的大头多机多卡训练瓶颈常常是通信而不是计算。几个实战里的体会梯度同步的通信量全量参数梯度汇总的通信量是固定的但通信效率受网络带宽、NCCL配置影响极大。先检查nvidia-smi topo -m看GPU拓扑——多卡之间是NVLink还是PCIe会影响你做数据并行还是模型并行。梯度压缩与通信重叠现代框架默认把“反向计算”和“梯度通信”重叠起来但如果你的模型结构特殊比如BERT类模型里层数很深这种重叠可能没法自动生效。需要看profiling结果必要时手动设置gradient_accumulation_steps来减少同步频率。NCCL的坑NCCL_P2P_DISABLE、NCCL_IB_DISABLE这些环境变量在有些云环境里需要按需调整。我遇到过一次集群网络拓扑特殊默认NCCL走RoCE但网卡配置有问题导致通信特别慢最后通过NCCL_SOCKET_IFNAME指定网卡解决。如果你的训练在容器环境里跑一定先验证NCCL通信的真实带宽别等训练吃满了才发现传数据比算数据还慢。4.3 Micro Batch Size与梯度累积吞吐和显存的权衡训练超大模型时单卡的显存放不下大batch一般用梯度累积模拟大batch。但梯度累积有个副作用累积步数越多参数更新频率越低收敛速度变慢。同时如果micro batch太小每个GPU step里矩阵乘法的算力利用率也上不去类似推理里的小batch问题。我的建议是在总显存允许的前提下尽量把micro batch size调到“让乘法的计算时间显著大于kernel launch时间”的水平。对于Transformer类模型这个阈值一般在单卡batch size达到8-16以上。如果单卡batch只能放4就用梯度累积补齐batch的同时认真考虑要不要开torch.compile或者换用省显存的注意力实现比如FlashAttention因为小batch对kernel效率的影响实在太大。5. 压测与持续监控优化效果要能证明而不是靠感觉性能优化做完一轮最要紧的是“怎么证明它有效”。没有压测没有前后对比一切都是主观感受。我在团队里定了一条规矩所有的性能优化必须要有压测数据支撑否则不合并进主线。5.1 压测场景设计别用一条“你好”压大模型很多同学压测喜欢用最简单的一句话请求比如“你好”然后得出结论“性能很好”。但这个结论对真实业务几乎没参考意义——真实请求的输入长度、输出长度、并发形态完全不同。设计压测至少要覆盖输入长度分布短文本、中等文本、长文本各占一定比例最好从线上日志抽样做回放。输出长度分布大模型场景尤其重要因为decode阶段的耗时和输出长度成正比。并发模型固定并发恒定压力和突发流量脉冲压力都要测。突发流量最容易暴露排队和超时问题。持续时长至少跑15-30分钟让缓存预热、动态batch策略稳定下来再取指标。压测工具方面在线服务常用wrk、hey做HTTP压测大模型服务如果走OpenAI兼容接口也可以用Locust写点脚本控制长度分布。关键是记录完整的参数组合包括并发数、请求长度分布、持续时间否则换个人来压数据完全没法对比。5.2 优化前后对比指标口径必须一致对比优化效果时最容易犯的错是“偷换指标口径”。举例来说优化前压测用的是“最大并发100、平均输入长度256”优化后压测用“最大并发500、平均输入长度512”然后宣称“吞吐从100提升到400”——看起来提升巨大但口径变了这个对比就是无效的。正确的对比方法固定压测参数并发数、请求长度分布、持续时长完全一致。同时记录延迟和吞吐只看延迟不知道吞吐被牺牲了多少只看吞吐不知道延迟已经超了SLO。多做几轮取中位数或平均值避免单次波动影响判断。记录资源数据GPU利用率、显存、CPU、网络IO也一起打出来方便判断优化是“真正提升效率”还是“多占用了资源”。5.3 持续监控性能优化是常态不是一次性活动线上系统是动态变化的模型版本更新、流量结构变化、底层硬件替换都可能让之前调优的参数失效。所以要让性能工程变成一种持续动作而不是“上线前调一次”。我的建议是至少做三件事给核心指标配告警P99延迟、吞吐、GPU利用率、排队长度任何一个偏离基线就告警。定期跑回归压测每次模型版本升级、推理引擎升级前跑一轮与上一次相同口径的压测对比关键指标。建立性能基线库把每次压测的参数、结果、环境信息记录到文档或CI配置里形成团队自己的性能基线历史。这样每次优化都能快速定位“从哪个版本开始变慢的”。6. 性能排查实录高频问题与排查路径速查把常见问题整理成一张速查表能极大加速定位效率。下面这些是我在实际项目里反复遇到过的高频问题。现象可能原因优先排查手段典型解法GPU利用率低但CPU很高预处理在CPU侧且不并行py-spy dump抓调用栈搬到GPU算子或多进程并行GPU利用率锯齿状波动同步等待、batch不饱满nsys看kernel间隙开启动态批处理、加大batchP99延迟飙升但P50正常存在尾部长请求按输入长度分层统计延迟限制单请求最大Token数显存OOM但显存“好像没用满”显存碎片化或KV Cache膨胀查看按tensor拆分的显存占用开PagedAttention、释放碎片多卡训练时单卡利用率低通信等待nsys看通信时间占比调整NCCL参数、减少同步频率数据加载卡死或极慢小文件随机IOiostat看IO等待合并为WebDataset格式推理响应突然变慢下游服务超时重试网关日志看重试次数降低超时阈值、排除下游影响CPU核数大量空闲但GPU利用率低预处理进程与推理进程间共享GILperf看线程栈独立进程处理预处理这里要额外强调一点排查时要先看“变化“而不是看“绝对数值”。某个指标今天比昨天差了多少、上线新版本后哪些指标变了这些变化信息往往比绝对值更容易定位根因。所以每次排查性能问题我都会先回答三个问题最近改了什么、指标从什么时候开始变的、变的是哪个分位数的延迟。回答完这三个问题一大半问题已经定位到原因了。7. 几条实操心得写给正在做性能工程的人写了这么多最后想分享几条实操层面的体会。第一性能优化的收益上限取决于你愿不愿意往深处钻。很多人停在了“换一个大batch”或者“换个更大的显卡”这个层面这不是性能工程这是资源堆砌。真正有效的优化往往要求你理解GPU是怎么执行kernel的、数据是从哪条路径流动的、网络在什么时候会卡住。工具箱越多定位越准。第二优化过程一定要留记录。我见过很多团队做了大量优化但半年后问起来“当时为什么这么调参”没人说清楚。我的习惯是每做一次优化在文档里记三个东西问题现象、用的什么工具怎么定位的、改了什么配置带来了什么量化结果。这个记录不仅方便自己回顾也是团队后续接手的重要资产。第三不要神化任何一个框架或工具。vLLM、TensorRT、torch.compile 各有各的适用场景没有银弹。我在实践中发现同一个模型在不同业务形态下的最优方案差别很大——聊天场景可能vLLM最顺手但批量离线推理任务用TensorRT配合定制batch策略可能效果更好。所以选型时多做对比别因为它是“热门框架”就默认它一定最快。如果你正在做AI系统性能相关的工作希望这篇内容能给你一些排查思路上的启发。下一步你可以尝试把你当前系统的性能指标拆到每一层先画清楚端到端的延迟分布再动手优化——这个过程本身往往就能带来不小的收益。