上次聊完AI系统性能工程的第一篇有朋友留言说方法论看了一堆真到定位问题的时候还是不知道从哪里下手。这个反馈很正常——性能工程分成两层一层是想清楚该优化什么另一层是能动手把它调好后者靠的是工具熟练度和对系统分层的感觉。这篇文章就是第二讲核心目标很直接把AI系统从离线训练到在线推理的常见性能瓶颈一条条拆开告诉你用什么工具、看什么指标、做什么调整。内容是我在多个GPU集群和推理服务上反复跑过的路径可以直接当操作手册用。1. 先分清性能目标延迟、吞吐、利用率还是成本很多人做性能调优的第一个动作是打开Profiler这其实顺序反了。我在实际项目里见过太多调了一天发现方向错了的情况根因是没定义清楚到底优化哪个指标。AI系统的性能指标不是互相独立的延迟、吞吐、资源利用率和成本经常是互相打架的必须先定好优先级后续工作才不会白做。1.1 四个目标四种优化路径先给一张我经常用来和团队对齐的表性能目标最直接的衡量指标典型优化手段低延迟P50/P99/P999、尾延迟、端到端耗时减少排队、取消同步等待、用小模型或剪枝、预填充和生成分离高吞吐QPS、TPS、每秒处理样本数、Tokens/s增大Batch、动态批处理、提高GPU利用率、计算与IO重叠高利用率GPU利用率、SM占用率、MFU、显存占用消除气泡、通信与计算重叠、优化算子实现、量化减小显存低成本每千Token成本、单样本成本、单位算力成本量化、混合部署、容器装箱、冷热资源调度、Spot实例策略这张表看起来简单但多数项目坑就坑在没选好主目标。比如一个在线推荐服务业务方说现在平均耗时有点高开发直接去调Batch大小调完平均耗时降了P99却飙到不可接受。原因就是在线服务的主目标应该是尾延迟Batch增大虽然提升吞吐但会让单个请求在队里等更久尾部延迟自然恶化。反过来离线训练集群的主目标如果是利用率或MFU那Batch就是要尽量大延迟根本不是第一优先级。目标没定对后面所有优化动作都会偏。1.2 用排队论先算理论天花板在动手之前我习惯先用最简单的排队模型估算系统大概能扛多少流量。这里最关键的是Little定律系统内的平均请求数L 到达率λ × 平均停留时间W。举个例子一个推理服务平均每秒进来500个请求单请求在GPU上的预估处理时间是80ms那系统内平均就有40个请求在同时排队等待。如果你的并发槽位只有32个那必然有8个请求在队列里积压P99延迟一定会炸。这个计算不复杂但它的价值是让你在压测之前就知道性能优化不是只调代码调度和并发模型往往才是瓶颈。我做完这个计算后一般会把结论写成一个性能验收清单主指标是什么SLO是多少测试流量模型是什么允许的最长尾延迟是多少。后续所有Profiling、压测、优化验证都围绕这份清单做避免一边调一边换靶子。2. 性能画像四层模型从应用代码看到CUDA Kernel定义好目标之后进入真正定位瓶颈的阶段。我习惯把AI系统看成四层每一层都有可能成为性能瓶颈应用层数据预处理、Python业务逻辑、API路由、线程池配置框架层模型结构、算子调度、数据加载器、自动混合精度、图优化运行时层CUDA Kernel启动、显存分配、CPU-GPU同步、NCCL通信硬件层GPU SM占用、显存带宽、NVLink/PCIe带宽、CPU算力、磁盘IO。对应用层和硬件层的工具很多人已经很熟但框架层和运行时层往往被忽略而AI系统的大部分性能问题恰恰藏在这两层。2.1 常用工具和它们到底能看什么工具/命令主要观测对象适合场景nvidia-smi / nvtop实时GPU利用率、显存、功耗、温度快速粗查确认GPU是不是在空转py-spyPython进程内函数调用栈看Python代码哪一行在耗时torch.profilerPyTorch算子耗时、CPU/GPU时间线定位单个算子和调度开销Nsight Systems (nsys)全系统时间线CPU、GPU、CUDA API、NCCL定位同步等待、通信等待、内存拷贝Nsight Compute (ncu)Kernel内部SM利用率、内存带宽、寄存器精细到算子底层的剖析Prometheus Grafana集群指标、队列长度、SLO告警长期监测和容量管理很多人一上来就ncu这在小项目里性价比很低。我通常的顺序是先nvidia-smi粗看GPU利用率再用nsys看完整时间线确定瓶颈在CPU侧、调度侧还是通信侧最后才用ncu去打磨具体kernel。2.2 一次GPU利用率95%但P99超标的排查过程这是个真实项目里的案例。当时是一个LLM在线推理服务nvidia-smi显示GPU利用率有95%看起来非常饱和但业务反馈P99延迟持续超标客户端一堆超时。团队第一反应是GPU都满了那就扩容但我感觉不对——GPU利用率高不代表它在做有效计算也可能是在空转等依赖。我让现场抓了一份nsys trace打开时间线一眼就看出问题GPU确实基本没闲着但里面每个kernel启动之间都夹着很长的CPU下发间隙。比如一个kernel执行完下一个kernel要等300多微秒才被提交到GPU这段时间GPU没有算力任务但因为上一个kernel仍在管线里nvidia-smi的利用率统计会把这段也算成busy。我自己给这种现象起名叫伪饱和。继续往应用层挖发现原因有两层预处理线程里有不少同步锁导致CPU端生成下一个batch的tensor时被互相卡住推理代码每次迭代都执行torch.cuda.synchronize()把所有异步计算强制同步CPU和GPU完全串行化。这两点叠加GPU在大多数时间都在等CPU把活干完看起来很忙实际上算力浪费严重。处理方式也很简单去掉无意义的同步点把预处理改成多线程并加大预取缓冲再把小算子合并成CUDA Graph。改完后CPU下发时间缩短到原来的五分之一P99从2.8秒降到了1.2秒机器数量反而没变。这件事给我最大的启发是功耗和利用率只能告诉你设备在不在工作不能告诉你工作在不在点子上。任何性能判断都要以端到端延迟和吞吐为准再叠加Profiler时间线判断到底在忙什么。3. 训练侧GPU利用率不等于训练效率MFU才是硬指标训练集群的性能问题和在线推理完全是两种画风。在线服务讲究稳定低延迟离线训练讲究单位时间能算多少有效算力。GPU利用率在训练场景里是个挺粗糙的指标它高只能说明GPU在跑但跑得是不是有效、算力是不是都花在模型前反向上要看MFU。3.1 MFU怎么算以及多少算正常MFUModel FLOPs Utilization是衡量训练效率的核心指标公式比想象中简单MFU 模型前反向有效FLOPs ÷ (GPU数量 × GPU峰值算力 × 实际运行时间)我们可以用一个例子感受一下假设一个7B参数规模模型一次训练step处理8192个token粗略按6N×D估算有效FLOPs约3.44×10^14。8张A100在BF16下的理论峰值大约是8×312×10^122.5×10^15如果这个step耗时0.5秒那理论可执行的总FLOPs是1.25×10^15MFU约27.5%。这个数在常规分布式训练里属于正常偏低的水平如果能把通信重叠、算子效率做好MFU可以到45%以上。如果MFU只有10%左右那基本可以断定系统有严重的等待或数据瓶颈不是单纯换张卡能解决的。3.2 从一次吞吐上不去的定位看训练调优链路某次我们在一台8卡A100机器上训练一个多模态模型目标是从单卡实验扩展到8卡。结果实测吞吐只提升了3.2倍扩展比远低于理论值。第一轮排查先加了Nsight System的NCCL和CUDA trace发现单次迭代0.8秒里有0.35秒花在梯度同步的通信等待上占比超过40%。进一步看通信拓扑发现8张卡里一部分走NVLink一部分竟然走PCIe转发原因是进程绑核没有按NVLink拓扑来分配导致通信走了最慢的路径。我们重新调整了GPU进程和CPU核心的亲和性使通信尽量落在同一个NVLink域内同时设置了NCCL通信的P2P层级参数第一次调整后吞吐直接提升了约20%。第二层问题来自梯度通信粒度太细。PyTorch默认的梯度分发是分bucket发送的bucket如果再小一点通信次数就会变多NCCL的启动开销占比也会更大。我们把梯度桶大小调大让梯度尽量合并成大块传输同时把反向计算和梯度同步做成重叠这一步又把扩展比往上拉了15%。最终8卡吞吐从3.2倍提升到6.1倍虽然还没到理想线性扩展但已经属于可接受范围。这里有个经验值得写在纸上分布式训练性能问题排查顺序应该是先看通信拓扑再看通信粒度再看计算重叠最后才怀疑算子效率。很多人一上来就纠结某个kernel是不是不够快殊不知通信阻塞早就把算力时间吃掉了。3.3 数据管道和显存优化怎么介入数据加载也是训练侧的高频瓶颈。最简单的判断方法是看GPU利用率的波形如果GPU利用率是规律性锯齿状基本就是数据供给的节拍跟不上计算节拍。这时候我会做三件事把数据加载的num_workers调到CPU核数的合理比例同时用prefetch在GPU计算的同时预取下一批数据检查是不是在GPU训练循环里执行了耗时高的数据预处理比如频繁的ONNX转换、Python解码、CPU数据增强这些应该全部挪到DataLoader的worker进程里如果磁盘IO是瓶颈先用压缩格式或TFRecord/webdataset这类大文件格式减少小文件随机读。显存层面最常用的是梯度累积、激活重计算和混合精度。激活重计算的思路是用额外计算换显存把某些中间激活不保存反向传播时重新算一遍。对长序列模型很有效代价是会增加约30%的计算量。所以它不是无脑开要在显存和MFU之间找一个折中点。4. 推理侧prefill/decode的博弈与调度策略在线推理性能工程是另一个世界。LLM推理有鲜明的两阶段特性prefill阶段处理整个输入序列计算密集decode阶段逐token生成访存密集。这两个阶段对资源的需求完全不同放在同一个GPU流水线里互相干扰是整个推理性能问题的根源。4.1 延迟拆解TTFT和TPOT衡量推理服务质量不能只看一个总耗时。我习惯拆成两个核心指标TTFTTime To First Token从请求发起到流式输出第一个token的时间主要受prefill和排队影响TPOTTime Per Output Token每生成一个token的平均时间主要受decode阶段和KV Cache访存影响。总延迟 TTFT TPOT × 预计生成token数。你只有把两项拆开才知道优化该往哪个方向打。TTFT高通常要解决排队和prefill调度TPOT高通常要解决显存带宽、KV Cache和量化问题。4.2 为什么连续批处理能同时提升吞吐和延迟传统的静态批处理是攒满一个batch再统一计算这样单个请求的等待时间会很高。现在主流的推理框架都会做连续批处理或动态批处理只要有新的请求进来而当前batch里某个序列已经生成完就把这个序列的位置立刻让给新请求而不是等整个batch结束。这个策略避免了batch尾部效应在不增加单请求尾延迟的情况下大幅提高吞吐。实际落地时我会限制队列长度和最大等待时间。举个例子如果允许请求在队列里等待最多100ms超过就直接进计算池或触发扩容告警避免长尾请求在排队阶段就超时。另外一个容易踩的坑是prefill和decode混跑。prefill计算量大、占用显存高decode虽然单步很轻但持续很久如果两者混在同一个插槽里容易互相抢资源。更稳的做法是把prefill和decode分到不同的worker池或者在同一worker内做优先级调度。团队达到的性能收益通常是P99端到端延迟下降30%整体吞吐提升40%以上。4.3 显存、KV Cache和量化decoding阶段的最大瓶颈是显存带宽而KV Cache又是显存消耗的大头。KV Cache越大允许的并发batch就越大显存带宽利用率也越高。工程上常用的手段有两类用PagedAttention这类显存管理器把KV Cache按页式管理减少显存碎片对KV Cache做量化比如从FP16降到INT8显存占用直接减半带宽压力也小很多。模型量化也值得做。FP16到INT8通常能把单卡吞吐提升70%到100%代价是质量可能有少量损失。INT4可以进一步压显存但需要更仔细地做校准。量化不是越低越好一定要带着业务指标测试。我自己的建议是如果一个在线推理服务已经到了扩容无底洞的阶段先别急着加卡先看三件事——动态批处理开没开、KV Cache显存管得好不好、模型和KV Cache能不能量化。这三样做完通常能把单卡承载量翻一倍以上。5. 性能闭环把项目从一次性调优变成可持续工程性能工程最怕的不是调不好而是调好了没人维护过两个月模型一换、框架一升级性能又回去了。所以真正成熟的团队会把性能工程做成一套闭环流程。5.1 基准测试性能优化的唯一裁判没有可复现的基准所有优化讨论都是各说各话。我团队里的基准测试有基本规范固定模型版本、固定输入形状和长度分布、固定随机种子先跑预热轮让显存分配、缓存和CUDA上下文稳定后再记录每轮测试至少跑多次取中位数或P50异常值单独记录端到端基准和Profiler微观基准分开不能混在一起。压测数据最好来自线上采样而不是用一句话给我造一个典型请求。线上序列长度、并发数、token生成长度的分布对性能表现影响极大拿一个理想情况测出来的数字没有参考价值。5.2 在CI里加性能回归门槛功能代码可以跑单测性能代码同样可以跑性能回归测试。我们在CI流程里加入了一个门槛任务对核心推理链路设置一个性能预算比如P99端到端延迟不超过150ms吞吐不低于某个绝对阈值。每次合入代码都会跑一遍精简版基准一旦性能回退超过5%CI会直接标红阻止合入。这个机制看起来会增加耗时但它的价值非常大。没有回归门槛的性能优化经常一周后被某个无关改动悄悄打回原形而没人能说清楚是哪一次改动导致的。5.3 容量规划和监控告警容量规划我用一个简单公式估算所需GPU副本数 预估QPS ÷ 单GPU能达到的QPS再乘以1.5到2的冗余系数。举例线上预估峰值QPS是1000单卡调优后实测可以扛500 QPS那至少需要2个GPU副本承载流量考虑滚动发布和突发流量实际准备4个副本更稳妥。这里冗余系数要看团队对尾延迟的容忍度越不能接受SLO损失冗余就要越高。监控层面除了常规CPU和内存GPU侧至少要看这几个GPU SM利用率而不是只看显存利用率Kernel启动间隙/CPU下发时间暴露伪饱和问题NVLink/PCIe带宽抓通信瓶颈请求队列长度、批量等待时间、超时丢弃率。告警不要设平均延迟超过多少而是基于错误预算。比如SLO是P99200ms当P99连续5分钟超过SLO或者在30分钟内消耗了超过20%的错误预算才触发告警。这样既能及时发现事故又不会因为单次抖动把人喊起来。6. 我踩过的几个可复现的坑以及第一次都会踩进去的原因最后把我这些年反复踩过、也看同事反复踩的坑写出来。这几条不算高深但每一条背后都有真实的代价。第一个坑是GPU利用率高没问题。前面说过伪饱和会让nvidia-smi给出误导性判断。现在我看到GPU利用率报告第一反应不是高兴而是追问延迟和有效吞吐。这个习惯救了我好几次。第二个坑是小Batch延迟一定低。直觉上好像每次处理少一点单个请求应该更快但GPU是强并行设备batch太小连算力峰值都摸不到吞吐压不上去排队反而更严重。我在一个推理服务里试过把batch从1调到4P99不但没升反而因为排队减少降了40%。这类优化一定要用数据和拐点说话不能凭感觉。第三个坑是平均值够用就行。在线系统的延迟分布往往是重尾的P90好看不代表P99和P999好看。做性能优化必须盯尾延迟必要时还要单独分析长序列请求、显存分配慢、缓存未命中等特殊路径它们常常是尾延迟的制造者。第四个坑是Profiler输出就是问题答案。Nsight给的trace是工具不是结论。你必须把它放回业务场景里知道哪个阶段对最终SLO影响最大再决定优化哪个环节。比如单纯优化一个kernel如果它只占整个流程的2%那优化到零也解决不了问题。性能工程就是这样基本功看着都不难难的是在每一次真实事故里不被表象带走。希望这篇第二讲能让你少走一些我走过的弯路。