做AI系统性能工程最容易翻车的不是不会用监控工具而是没把性能当成一个真正的工程质量问题去闭环管理。前面两篇已经聊过GPU利用率、显存、时延这些基础指标怎么采、怎么看到了这一篇我打算把完整的流程串起来讲指标口径怎么定、瓶颈怎么一层层揪出来、性能回归怎么守以及怎么把这些东西换算成GPU卡数和成本预算。这篇适合正在做推理服务优化、训练任务提速、模型上线前压测的工程师。如果你是刚入门建议先花半天把 torch.profiler 和 nvidia-smi 的常见输出看明白再看这篇会轻松很多如果你的团队已经上了监控面板但每次性能出问题还是七嘴八舌说不清那这篇关于指标口径和回归门禁的部分应该能解决你80%的痛点。1. 性能工程的完整闭环先定指标再谈优化1.1 从指标混乱到SLI/SLO把度量口径钉死你肯定见过这种场景业务同学反馈服务变慢了打开监控面板看到GPU利用率只有20%但应用指标里p99已经跑到200ms另一个人跑了个离线测试说模型推理只花了15ms性能好得很。两个人都在聊性能但说的根本不是一回事原因就是指标口径没对齐。AI系统的性能指标多到离谱光是GPU相关就有利用率、显存、功耗、温度、NVLink带宽应用侧又有QPS、p50/p99时延、排队长度、token吞吐。如果不把“到底看哪个指标、以哪个数值为准”先定下来后续所有优化都是无底洞。我强烈建议团队在动手之前至少把下面这套顶层结构写清楚系统类型SLI用什么测示例SLO目标值在线推理p99端到端时延≤80ms在线推理服务吞吐 QPS≥100在线推理GPU利用率≥40%离线训练每步训练耗时≤1.2s离线训练数据加载等待占比≤15%数据管线DataLoader预取命中率≥95%为什么要用p99而不是平均值平均耗时会被大量快请求拉低完全代表不了长尾用户的实际体验。打个比方一家餐厅平均上菜30分钟但你每次都等1小时你会觉得它快吗p99衡量的就是最惨的那部分用户。对在线服务来说p99不过关平均值再好看都是自欺欺人。提示SLI和SLO不是定了就完事最好还要配套“错误预算”。比如SLO要求99%的请求在80ms内完成那错误预算就是1%的请求可以超时。每次版本上线前先看错误预算还剩多少而不是上线后才发现超了。这个概念在AI系统里同样适用。在AI系统领域指标选择还有自己的行业特性。在线推理场景除了常规QPS和时延还要看每token生成时延离线训练场景光看step time不够更推荐看有效吞吐samples/s和硬件浮点利用率MFU/HFU因为它们能反映算力到底有没有用在刀刃上。先把团队统一到同一套指标语言下这是性能工程的第一优先级比任何调优技巧都重要。1.2 优化循环度量、剖析、优化、回归性能优化不是一次性动作也不是把batch size调大、卡数增多就完事。我习惯把整个工作压成一个循环每轮只动一个变量度量拿到当前系统与SLO的差距比如p99是150ms目标是80ms差了70ms。剖析逐层拆解找到最值得改的环节而不是凭感觉改一个参数。优化针对瓶颈做一次性改动比如调整并行策略、优化数据加载。回归跑同一套基准对比优化前后的指标曲线和profile产物确认没有副作用。这里要特别强调“每轮只动一个变量”。有人喜欢一口气把batch size、worker数量、量化精度全改了结果性能确实变好了但你说不清是哪项改动起了作用下次换个模型照样抓瞎。我在实际工作中吃过亏曾经同时改了DataLoader的worker数和模型并行策略结果时延掉了一半后来回滚数据加载改动发现性能还是好才知道瓶颈其实在并行策略上。那次之后我给自己立了一条规矩——一个PR只解决一个瓶颈假设。另外把“优化周期”控制在1到2天也很重要。性能调优特别容易陷入“边际递减”的怪圈明明已经达标了还想再抠1ms结果改了一周收益越来越小风险却越来越大。我一般做法是达到SLO之后立刻固化实验纪录转入下一个瓶颈而不是停留在局部最优里打转。2. 从外到内逐层拆怎么把瓶颈揪出来2.1 端到端时延拆解先定位慢在哪个环节在线推理服务的完整链路一般包括客户端发起请求 → 网关/负载均衡 → 服务端入队 → 预处理tokenize→ 模型推理prefill decode→ 后处理detokenize→ 序列化并返回。遇到时延问题第一件事是把这条链路拆开给每个环节打点计时。用OpenTelemetry做分布式追踪是生产环境的常规做法能还原一次请求经过的每个节点如果想看更细的算子级耗时用PyTorch Profiler生成trace或者用NVIDIA Nsight Systems做系统级剖析。命令行很直接nsys profile --tracecuda,nvtx,osrt python infer.py torch.profiler --schedule ... python train.py拿到数据后按耗时占比排序找大头。举个例子某次压测发现服务端总耗时120ms拆开看是入队等待15ms预处理5ms模型推理90ms后处理加序列化10ms。模型推理占了75%那肯定先查推理内部但如果查下来发现GPU利用率并不高说明推理函数内部存在大量小kernel启动开销或同步等待这时候要继续深挖而不是盲目增加并行度。这里有个AI系统的特殊经验如果是LLM推理服务建议把模型推理阶段进一步拆成prefill和decode两个阶段来统计。prefill阶段要一次性处理整段prompt计算量随输入长度线性增长属于算力密集decode阶段每生成一个token都要读取整条序列的KV cache属于访存/带宽密集。混在一起统计你只会看到一个虚高的GPU利用率均值但decode局部的时延可能早就爆炸了。对LLM服务更合理的方式是分阶段设SLO比如prefill p95耗时≤2sdecode每token间延时≤50ms这样定位问题会快得多。2.2 GPU利用率上不去的三个典型现场很多人一看到GPU利用率低就着急调batch size但同样是“利用率低”背后原因可能完全不同。我挑了三种最常见的“现场”对号入座比瞎调参数有用得多。现场AGPU利用率低QPS也低——小batch串行处理。每个请求单独推理GPU根本没吃饱。传统CV或NLP模型可以用动态batching把同时到达的多个请求拼到一个batch里LLM场景更推荐continuous batching在decode阶段动态拼接不同长度的序列但调度时要同时设max_batch_tokens和max_wait_ms两个阈值。比如max_batch_tokens4096, max_wait_ms20意味着攒批最多等20ms超过就直接启动避免为了等一个请求把整体时延拖垮。现场BGPU利用率波动剧烈峰值60%但平均只有20%——CPU侧数据加载成了瓶颈。GPU kernel跑几十毫秒然后空转几百毫秒等数据利用率自然被拉平。验证方法是用nsys看时间线GPU kernel之间的大段gap大概率都是CPU在忙着做数据加载和预处理。解决办法很标准调大DataLoader的num_workers和prefetch_factor开启pin_memory必要的话把图像解码、文本padding这类重活挪到GPU或异步线程里。这一套下来GPU利用率从20%提到50%是常有的事。现场C多卡利用率不均匀8张卡只有2张在满负荷跑——并行策略或通信问题。常见原因包括模型并行的气泡bubble太大、某个PP阶段计算量大或者NCCL集合通信和计算没有重叠。先别急着改代码用nvidia-smi topo -m看硬件拓扑再用NCCL的debug日志看通信耗时占比。如果通信占比高调整并行切分策略或者把梯度通信和反向计算做overlap往往比硬调batch size有效得多。3. 性能回归测试把性能当工程质量来守3.1 把性能断言写进CI挡住无声回归性能问题最阴的地方在于它不是某次重构马上引爆大事故而是每次改版慢一点点最后到某次升级p99从60ms变成200ms谁也说不清是哪次改动导致的。要根治就得把性能测试做成自动化回归门禁嵌进CI流程。第一步准备固定benchmark数据集。线上流量随机性太强不能直接拿生产数据测最好从公开数据集或业务样本里抽一份大小固定、分布稳定的subset连同模型权重一起放到Git LFS或者对象存储里。第二步写基准测试脚本固定输入shape、固定随机种子跑若干轮计算p50/p99时延、吞吐和GPU利用率。第三步在CI里用一套基线yaml做断言model: chat_v3 baseline: gpu: A100-40G batch_size: 16 max_new_tokens: 128 throughput_qps: 50 p50_ms: 70 p99_ms: 120 gpu_util_min: 0.4CI脚本读这份yaml把本次实测结果和基线对比超过阈值就阻断合并。核心判断逻辑很简单def check_performance(result, baseline): errors [] if result[throughput_qps] baseline[throughput_qps] * 0.95: errors.append(吞吐回归{:.1f} 基线 {:.1f}.format( result[throughput_qps], baseline[throughput_qps])) if result[p99_ms] baseline[p99_ms] * 1.1: errors.append(p99回归{:.1f}ms 基线 {:.1f}ms.format( result[p99_ms], baseline[p99_ms])) if result[gpu_util] baseline[gpu_util_min]: errors.append(GPU利用率下降{:.1f}% {:.1f}%.format( result[gpu_util], baseline[gpu_util_min])) return errors进入门禁之前有两个环境稳定性问题必须提前解决。一是测试机器要固定不同GPU型号、不同CUDA版本、甚至不同CPU型号都会影响结果。稳妥的做法是跑在专门的benchmark机器组上禁止跑其他任务。二是要解决“冷启动效应”刚拉起进程时显存分配、kernel编译缓存都是冷的前几次运行会明显偏慢。正确做法是先跑几轮warm-up等指标稳定后再正式采集或者直接取多次运行的中位数而不是第一次值。3.2 精度与性能的平衡门禁性能优化很容易走上另一条邪路GPU利用率上去了时延唰唰降但模型精度掉到不可接受。量化、剪枝、蒸馏、混合精度、算子融合这些手段都会引入数值变化有些变化是隐性的不跑评估集根本发现不了。我的建议是设三道门禁全部通过才允许合入功能正确性门禁跑一小批固定用例保证输出结构不崩、不出现NaN、不出现明显乱码。精度基准门禁在固定eval集上对比指标比如INT8量化后准确率下降不超过0.5个百分点BLEU下降不超过0.5loss回退不超过阈值。性能基准门禁对应上面说的吞吐和时延。举个例子INT8量化通常能把显存占用砍掉一半吞吐提升明显但如果校准集选得不好精度损失可能远超预期。有些框架支持per-channel量化效果比per-tensor好但有平台兼容性问题。这种优化属于典型的“收益看得见、风险藏得深”没有精度门禁拦着生产事故只是时间问题。提示精度门禁的阈值不要拍脑袋。最靠谱的来源是业务方给出的核心指标下限而不是你自己觉得“掉0.5%问题不大”。量化掉0.5%对用户可能无感知但对一个推荐模型来说可能就是收入曲线的明显下滑。4. 容量规划与成本治理让性能预算落到真金白银上4.1 从QPS和时延反推进卡数“这个模型上生产要多少卡”这是性能工程里最常被问到的问题。直接拍脑袋报个数字不专业我一般按下面四步走。第一步先压测单卡在目标时延下的最大吞吐。把batch size从1、4、8、16、32逐步往上加每个batch下记录QPS和p99找到满足“p99≤80ms”的最大吞吐点。比如batch8时QPS约50、p9975msbatch16时p99130ms超标那单卡容量就取50QPS而不是取吞吐最高的那个batch。第二步估算业务目标QPS。根据历史日均QPS和峰值倍数来定比如平均300QPS历史峰值是平均值的1.8倍那目标QPS就是540。第三步算实例数。公式很简单实例数 目标QPS / 单卡容量即540 / 50 10.8向上取整到11。考虑到N1冗余最终部署12个实例。如果单实例是多卡机器再按部署形态换算成GPU卡数。第四步留出扩缩容缓冲。线上流量永远有毛刺HPA可以应对短时抖动但不能把自动扩缩容当成时延兜底——冷启动和排队需要时间两次弹性的间隙请求早就超时了。所以水位数要留足但也不要超出太多否则成本每个月都在流血。4.2 batch size、并发与时延的三角关系容量规划绕不开batch size、并发与时延之间的权衡。简单说并发越大、攒的batch越大GPU吞吐越高但等待batch攒齐的时间也在增加时延自然上升。这里有一个硬约束公式特别重要攒批等待时间 ≈ batch_size / 请求到达速率。假设当前请求到达速率是100 req/s要攒一个batch16那平均要等160ms。如果SLO是p99≤80ms攒批这条路根本走不通。所以动态batching调度不能只看batch数量要看“最大等待时间”和“最大batch token”双条件谁先到就触发谁。这也是为什么现代LLM推理框架普遍用continuous batching——它不要求等满一个batch而是每有token完成生成就动态塞入新序列把GPU的每一帧都尽量填满同时把单请求的排队等待压低。4.3 成本治理和水位线设计成本治理不是抠门而是把预算花在该花的卡上。训练侧和推理侧侧重点完全不同。训练侧核心是提高端到端有效利用率。与其抠单个算子的耗时不如先看全局数据预取够不够、混合精度开没开、梯度通信有没有和计算重叠。一个经验值是训练集群长期平均GPU利用率做到50%以上算健康低于30%就有很大优化空间。这不是绝对标准但可以作为自查起点。推理侧要看单位请求成本或者每百token成本。如果GPU利用率长期低于30%还满负荷部署就该考虑合并实例或走serverless缩容。常见水位线设计如下扩容水位GPU利用率持续5分钟超过70%或请求队列长度超过单实例容量的80%。缩容水位GPU利用率持续15分钟低于30%且队列长度健康。显存水位显存占用超过85%触发批量调度迁移或限制最大并发。这里有个容易踩的坑缩容阈值比扩容阈值要更保守而且要有更长的观察窗口因为流量毛刺会导致频繁扩缩容CPU/GPU热切换反而制造新的抖动。我会把缩容观察窗口拉长到15分钟以上避免震荡。5. 常见问题与排查技巧实录5.1 五个真实案例复盘案例一动态batch导致时延抖动。现象QPS上来之后p99飙升但GPU利用率并不低。原因请求到达是泊松分布攒批等待时间不稳定某个批次等了很久才凑齐这一批请求的时延全被拉高。处理把调度从“攒满batch_size”改成“最大等待时间最大batch token”双阈值触发或者直接换continuous batching。改造之后p99趋于平稳。案例二数据加载线程瓶颈。现象GPU利用率平均20%但峰值有90%。原因DataLoader的worker太少预处理全在CPU跑GPU kernel之间出现大段空闲。处理num_workers从4调到8开启prefetch_factor4和pin_memory把resize和padding挪到GPU上做。最终GPU利用率稳定到50%以上训练每轮时间缩短了将近三分之一。案例三显存碎片化训练中段OOM。现象训练20分钟后才OOM刚启动时显存占用一切正常。原因动态shape加上反复申请释放显存碎片越来越多。处理固定输入shape或统一padding设置PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True并对长期运行任务单独做显存峰值监控。注意expandable_segments不是所有CUDA版本和框架版本都有效需要实测别盲目开。案例四多卡训练扩展性差。现象8卡训练只比单卡快3倍远低于预期。原因数据并行每一步都要AllReduce梯度通信时间占比太高也可能是GPU间P2P带宽不足NCCL选了低效路径。处理开启梯度通信和反向计算overlap检查nvidia-smi topo -m看拓扑用NCCL_DEBUGINFO看通信耗时。有时候换一种rank到物理GPU的映射方式就能提升一截。案例五LLM推理的KV Cache因素导致p99突刺。现象长文本请求一多p99直接几秒。原因KV cache占满显存后调度器被迫降低batch或触发重新规划某些请求被排到队尾。处理限制单请求最大生成长度按token数而不是请求数做调度prefill和decode分别走不同调度窗口。这类问题排查时光看QPS没用要按请求长度和token数维度去聚合时延分布。5.2 排查速查表现象排查工具大概率原因处理建议GPU利用率低CPU爆高nsys、top、perfDataLoader/预处理瓶颈增大worker、prefetch异步预处理GPU利用率低CPU也不高torch.profiler、nsys小batch、kernel启动开销大dynamic batching、算子融合GPU利用率波动大nvidia-smi dmon、DCGM排队/调度抖动分析请求到达模式平滑调度显存OOMtorch.cuda.memory_summary碎片化或峰值超限固定shape、expandable_segments多卡通信慢nsys、NCCL_DEBUGINFO带宽不足、拓扑不佳查拓扑、调整rank映射时延突刺tracing、请求采样冷启动、锁竞争、KV cache单独采样慢请求profile5.3 实操中的三点心得第一先固化最小基准集再动手优化。没有固定benchmark一切优化结论都是“疑似有效”海量指标只会让你更慌。第二每个优化动作都要先取证再动手。我见过太多次“这批请求慢所以我改模型并行”的误判最后发现瓶颈其实在锁竞争或网络连接复用上。第三每次实验结束时一定保存profile和trace产物并且把环境指纹写进文件名——GPU型号、驱动版本、CUDA版本、PyTorch版本、数据集hash。别小看这一行它救过我很多次。过两周回看你还能还原当时机器跑的是什么状态而不是靠聊天记录和记忆去猜测。 
长河君 · 2026/10/1 23:52:21 · 阅读 1.2k AI系统性能工程：从指标口径到瓶颈定位与成本治理
做AI系统性能工程最容易翻车的不是不会用监控工具而是没把性能当成一个真正的工程质量问题去闭环管理。前面两篇已经聊过GPU利用率、显存、时延这些基础指标怎么采、怎么看到了这一篇我打算把完整的流程串起来讲指标口径怎么定、瓶颈怎么一层层揪出来、性能回归怎么守以及怎么把这些东西换算成GPU卡数和成本预算。这篇适合正在做推理服务优化、训练任务提速、模型上线前压测的工程师。如果你是刚入门建议先花半天把 torch.profiler 和 nvidia-smi 的常见输出看明白再看这篇会轻松很多如果你的团队已经上了监控面板但每次性能出问题还是七嘴八舌说不清那这篇关于指标口径和回归门禁的部分应该能解决你80%的痛点。1. 性能工程的完整闭环先定指标再谈优化1.1 从指标混乱到SLI/SLO把度量口径钉死你肯定见过这种场景业务同学反馈服务变慢了打开监控面板看到GPU利用率只有20%但应用指标里p99已经跑到200ms另一个人跑了个离线测试说模型推理只花了15ms性能好得很。两个人都在聊性能但说的根本不是一回事原因就是指标口径没对齐。AI系统的性能指标多到离谱光是GPU相关就有利用率、显存、功耗、温度、NVLink带宽应用侧又有QPS、p50/p99时延、排队长度、token吞吐。如果不把“到底看哪个指标、以哪个数值为准”先定下来后续所有优化都是无底洞。我强烈建议团队在动手之前至少把下面这套顶层结构写清楚系统类型SLI用什么测示例SLO目标值在线推理p99端到端时延≤80ms在线推理服务吞吐 QPS≥100在线推理GPU利用率≥40%离线训练每步训练耗时≤1.2s离线训练数据加载等待占比≤15%数据管线DataLoader预取命中率≥95%为什么要用p99而不是平均值平均耗时会被大量快请求拉低完全代表不了长尾用户的实际体验。打个比方一家餐厅平均上菜30分钟但你每次都等1小时你会觉得它快吗p99衡量的就是最惨的那部分用户。对在线服务来说p99不过关平均值再好看都是自欺欺人。提示SLI和SLO不是定了就完事最好还要配套“错误预算”。比如SLO要求99%的请求在80ms内完成那错误预算就是1%的请求可以超时。每次版本上线前先看错误预算还剩多少而不是上线后才发现超了。这个概念在AI系统里同样适用。在AI系统领域指标选择还有自己的行业特性。在线推理场景除了常规QPS和时延还要看每token生成时延离线训练场景光看step time不够更推荐看有效吞吐samples/s和硬件浮点利用率MFU/HFU因为它们能反映算力到底有没有用在刀刃上。先把团队统一到同一套指标语言下这是性能工程的第一优先级比任何调优技巧都重要。1.2 优化循环度量、剖析、优化、回归性能优化不是一次性动作也不是把batch size调大、卡数增多就完事。我习惯把整个工作压成一个循环每轮只动一个变量度量拿到当前系统与SLO的差距比如p99是150ms目标是80ms差了70ms。剖析逐层拆解找到最值得改的环节而不是凭感觉改一个参数。优化针对瓶颈做一次性改动比如调整并行策略、优化数据加载。回归跑同一套基准对比优化前后的指标曲线和profile产物确认没有副作用。这里要特别强调“每轮只动一个变量”。有人喜欢一口气把batch size、worker数量、量化精度全改了结果性能确实变好了但你说不清是哪项改动起了作用下次换个模型照样抓瞎。我在实际工作中吃过亏曾经同时改了DataLoader的worker数和模型并行策略结果时延掉了一半后来回滚数据加载改动发现性能还是好才知道瓶颈其实在并行策略上。那次之后我给自己立了一条规矩——一个PR只解决一个瓶颈假设。另外把“优化周期”控制在1到2天也很重要。性能调优特别容易陷入“边际递减”的怪圈明明已经达标了还想再抠1ms结果改了一周收益越来越小风险却越来越大。我一般做法是达到SLO之后立刻固化实验纪录转入下一个瓶颈而不是停留在局部最优里打转。2. 从外到内逐层拆怎么把瓶颈揪出来2.1 端到端时延拆解先定位慢在哪个环节在线推理服务的完整链路一般包括客户端发起请求 → 网关/负载均衡 → 服务端入队 → 预处理tokenize→ 模型推理prefill decode→ 后处理detokenize→ 序列化并返回。遇到时延问题第一件事是把这条链路拆开给每个环节打点计时。用OpenTelemetry做分布式追踪是生产环境的常规做法能还原一次请求经过的每个节点如果想看更细的算子级耗时用PyTorch Profiler生成trace或者用NVIDIA Nsight Systems做系统级剖析。命令行很直接nsys profile --tracecuda,nvtx,osrt python infer.py torch.profiler --schedule ... python train.py拿到数据后按耗时占比排序找大头。举个例子某次压测发现服务端总耗时120ms拆开看是入队等待15ms预处理5ms模型推理90ms后处理加序列化10ms。模型推理占了75%那肯定先查推理内部但如果查下来发现GPU利用率并不高说明推理函数内部存在大量小kernel启动开销或同步等待这时候要继续深挖而不是盲目增加并行度。这里有个AI系统的特殊经验如果是LLM推理服务建议把模型推理阶段进一步拆成prefill和decode两个阶段来统计。prefill阶段要一次性处理整段prompt计算量随输入长度线性增长属于算力密集decode阶段每生成一个token都要读取整条序列的KV cache属于访存/带宽密集。混在一起统计你只会看到一个虚高的GPU利用率均值但decode局部的时延可能早就爆炸了。对LLM服务更合理的方式是分阶段设SLO比如prefill p95耗时≤2sdecode每token间延时≤50ms这样定位问题会快得多。2.2 GPU利用率上不去的三个典型现场很多人一看到GPU利用率低就着急调batch size但同样是“利用率低”背后原因可能完全不同。我挑了三种最常见的“现场”对号入座比瞎调参数有用得多。现场AGPU利用率低QPS也低——小batch串行处理。每个请求单独推理GPU根本没吃饱。传统CV或NLP模型可以用动态batching把同时到达的多个请求拼到一个batch里LLM场景更推荐continuous batching在decode阶段动态拼接不同长度的序列但调度时要同时设max_batch_tokens和max_wait_ms两个阈值。比如max_batch_tokens4096, max_wait_ms20意味着攒批最多等20ms超过就直接启动避免为了等一个请求把整体时延拖垮。现场BGPU利用率波动剧烈峰值60%但平均只有20%——CPU侧数据加载成了瓶颈。GPU kernel跑几十毫秒然后空转几百毫秒等数据利用率自然被拉平。验证方法是用nsys看时间线GPU kernel之间的大段gap大概率都是CPU在忙着做数据加载和预处理。解决办法很标准调大DataLoader的num_workers和prefetch_factor开启pin_memory必要的话把图像解码、文本padding这类重活挪到GPU或异步线程里。这一套下来GPU利用率从20%提到50%是常有的事。现场C多卡利用率不均匀8张卡只有2张在满负荷跑——并行策略或通信问题。常见原因包括模型并行的气泡bubble太大、某个PP阶段计算量大或者NCCL集合通信和计算没有重叠。先别急着改代码用nvidia-smi topo -m看硬件拓扑再用NCCL的debug日志看通信耗时占比。如果通信占比高调整并行切分策略或者把梯度通信和反向计算做overlap往往比硬调batch size有效得多。3. 性能回归测试把性能当工程质量来守3.1 把性能断言写进CI挡住无声回归性能问题最阴的地方在于它不是某次重构马上引爆大事故而是每次改版慢一点点最后到某次升级p99从60ms变成200ms谁也说不清是哪次改动导致的。要根治就得把性能测试做成自动化回归门禁嵌进CI流程。第一步准备固定benchmark数据集。线上流量随机性太强不能直接拿生产数据测最好从公开数据集或业务样本里抽一份大小固定、分布稳定的subset连同模型权重一起放到Git LFS或者对象存储里。第二步写基准测试脚本固定输入shape、固定随机种子跑若干轮计算p50/p99时延、吞吐和GPU利用率。第三步在CI里用一套基线yaml做断言model: chat_v3 baseline: gpu: A100-40G batch_size: 16 max_new_tokens: 128 throughput_qps: 50 p50_ms: 70 p99_ms: 120 gpu_util_min: 0.4CI脚本读这份yaml把本次实测结果和基线对比超过阈值就阻断合并。核心判断逻辑很简单def check_performance(result, baseline): errors [] if result[throughput_qps] baseline[throughput_qps] * 0.95: errors.append(吞吐回归{:.1f} 基线 {:.1f}.format( result[throughput_qps], baseline[throughput_qps])) if result[p99_ms] baseline[p99_ms] * 1.1: errors.append(p99回归{:.1f}ms 基线 {:.1f}ms.format( result[p99_ms], baseline[p99_ms])) if result[gpu_util] baseline[gpu_util_min]: errors.append(GPU利用率下降{:.1f}% {:.1f}%.format( result[gpu_util], baseline[gpu_util_min])) return errors进入门禁之前有两个环境稳定性问题必须提前解决。一是测试机器要固定不同GPU型号、不同CUDA版本、甚至不同CPU型号都会影响结果。稳妥的做法是跑在专门的benchmark机器组上禁止跑其他任务。二是要解决“冷启动效应”刚拉起进程时显存分配、kernel编译缓存都是冷的前几次运行会明显偏慢。正确做法是先跑几轮warm-up等指标稳定后再正式采集或者直接取多次运行的中位数而不是第一次值。3.2 精度与性能的平衡门禁性能优化很容易走上另一条邪路GPU利用率上去了时延唰唰降但模型精度掉到不可接受。量化、剪枝、蒸馏、混合精度、算子融合这些手段都会引入数值变化有些变化是隐性的不跑评估集根本发现不了。我的建议是设三道门禁全部通过才允许合入功能正确性门禁跑一小批固定用例保证输出结构不崩、不出现NaN、不出现明显乱码。精度基准门禁在固定eval集上对比指标比如INT8量化后准确率下降不超过0.5个百分点BLEU下降不超过0.5loss回退不超过阈值。性能基准门禁对应上面说的吞吐和时延。举个例子INT8量化通常能把显存占用砍掉一半吞吐提升明显但如果校准集选得不好精度损失可能远超预期。有些框架支持per-channel量化效果比per-tensor好但有平台兼容性问题。这种优化属于典型的“收益看得见、风险藏得深”没有精度门禁拦着生产事故只是时间问题。提示精度门禁的阈值不要拍脑袋。最靠谱的来源是业务方给出的核心指标下限而不是你自己觉得“掉0.5%问题不大”。量化掉0.5%对用户可能无感知但对一个推荐模型来说可能就是收入曲线的明显下滑。4. 容量规划与成本治理让性能预算落到真金白银上4.1 从QPS和时延反推进卡数“这个模型上生产要多少卡”这是性能工程里最常被问到的问题。直接拍脑袋报个数字不专业我一般按下面四步走。第一步先压测单卡在目标时延下的最大吞吐。把batch size从1、4、8、16、32逐步往上加每个batch下记录QPS和p99找到满足“p99≤80ms”的最大吞吐点。比如batch8时QPS约50、p9975msbatch16时p99130ms超标那单卡容量就取50QPS而不是取吞吐最高的那个batch。第二步估算业务目标QPS。根据历史日均QPS和峰值倍数来定比如平均300QPS历史峰值是平均值的1.8倍那目标QPS就是540。第三步算实例数。公式很简单实例数 目标QPS / 单卡容量即540 / 50 10.8向上取整到11。考虑到N1冗余最终部署12个实例。如果单实例是多卡机器再按部署形态换算成GPU卡数。第四步留出扩缩容缓冲。线上流量永远有毛刺HPA可以应对短时抖动但不能把自动扩缩容当成时延兜底——冷启动和排队需要时间两次弹性的间隙请求早就超时了。所以水位数要留足但也不要超出太多否则成本每个月都在流血。4.2 batch size、并发与时延的三角关系容量规划绕不开batch size、并发与时延之间的权衡。简单说并发越大、攒的batch越大GPU吞吐越高但等待batch攒齐的时间也在增加时延自然上升。这里有一个硬约束公式特别重要攒批等待时间 ≈ batch_size / 请求到达速率。假设当前请求到达速率是100 req/s要攒一个batch16那平均要等160ms。如果SLO是p99≤80ms攒批这条路根本走不通。所以动态batching调度不能只看batch数量要看“最大等待时间”和“最大batch token”双条件谁先到就触发谁。这也是为什么现代LLM推理框架普遍用continuous batching——它不要求等满一个batch而是每有token完成生成就动态塞入新序列把GPU的每一帧都尽量填满同时把单请求的排队等待压低。4.3 成本治理和水位线设计成本治理不是抠门而是把预算花在该花的卡上。训练侧和推理侧侧重点完全不同。训练侧核心是提高端到端有效利用率。与其抠单个算子的耗时不如先看全局数据预取够不够、混合精度开没开、梯度通信有没有和计算重叠。一个经验值是训练集群长期平均GPU利用率做到50%以上算健康低于30%就有很大优化空间。这不是绝对标准但可以作为自查起点。推理侧要看单位请求成本或者每百token成本。如果GPU利用率长期低于30%还满负荷部署就该考虑合并实例或走serverless缩容。常见水位线设计如下扩容水位GPU利用率持续5分钟超过70%或请求队列长度超过单实例容量的80%。缩容水位GPU利用率持续15分钟低于30%且队列长度健康。显存水位显存占用超过85%触发批量调度迁移或限制最大并发。这里有个容易踩的坑缩容阈值比扩容阈值要更保守而且要有更长的观察窗口因为流量毛刺会导致频繁扩缩容CPU/GPU热切换反而制造新的抖动。我会把缩容观察窗口拉长到15分钟以上避免震荡。5. 常见问题与排查技巧实录5.1 五个真实案例复盘案例一动态batch导致时延抖动。现象QPS上来之后p99飙升但GPU利用率并不低。原因请求到达是泊松分布攒批等待时间不稳定某个批次等了很久才凑齐这一批请求的时延全被拉高。处理把调度从“攒满batch_size”改成“最大等待时间最大batch token”双阈值触发或者直接换continuous batching。改造之后p99趋于平稳。案例二数据加载线程瓶颈。现象GPU利用率平均20%但峰值有90%。原因DataLoader的worker太少预处理全在CPU跑GPU kernel之间出现大段空闲。处理num_workers从4调到8开启prefetch_factor4和pin_memory把resize和padding挪到GPU上做。最终GPU利用率稳定到50%以上训练每轮时间缩短了将近三分之一。案例三显存碎片化训练中段OOM。现象训练20分钟后才OOM刚启动时显存占用一切正常。原因动态shape加上反复申请释放显存碎片越来越多。处理固定输入shape或统一padding设置PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True并对长期运行任务单独做显存峰值监控。注意expandable_segments不是所有CUDA版本和框架版本都有效需要实测别盲目开。案例四多卡训练扩展性差。现象8卡训练只比单卡快3倍远低于预期。原因数据并行每一步都要AllReduce梯度通信时间占比太高也可能是GPU间P2P带宽不足NCCL选了低效路径。处理开启梯度通信和反向计算overlap检查nvidia-smi topo -m看拓扑用NCCL_DEBUGINFO看通信耗时。有时候换一种rank到物理GPU的映射方式就能提升一截。案例五LLM推理的KV Cache因素导致p99突刺。现象长文本请求一多p99直接几秒。原因KV cache占满显存后调度器被迫降低batch或触发重新规划某些请求被排到队尾。处理限制单请求最大生成长度按token数而不是请求数做调度prefill和decode分别走不同调度窗口。这类问题排查时光看QPS没用要按请求长度和token数维度去聚合时延分布。5.2 排查速查表现象排查工具大概率原因处理建议GPU利用率低CPU爆高nsys、top、perfDataLoader/预处理瓶颈增大worker、prefetch异步预处理GPU利用率低CPU也不高torch.profiler、nsys小batch、kernel启动开销大dynamic batching、算子融合GPU利用率波动大nvidia-smi dmon、DCGM排队/调度抖动分析请求到达模式平滑调度显存OOMtorch.cuda.memory_summary碎片化或峰值超限固定shape、expandable_segments多卡通信慢nsys、NCCL_DEBUGINFO带宽不足、拓扑不佳查拓扑、调整rank映射时延突刺tracing、请求采样冷启动、锁竞争、KV cache单独采样慢请求profile5.3 实操中的三点心得第一先固化最小基准集再动手优化。没有固定benchmark一切优化结论都是“疑似有效”海量指标只会让你更慌。第二每个优化动作都要先取证再动手。我见过太多次“这批请求慢所以我改模型并行”的误判最后发现瓶颈其实在锁竞争或网络连接复用上。第三每次实验结束时一定保存profile和trace产物并且把环境指纹写进文件名——GPU型号、驱动版本、CUDA版本、PyTorch版本、数据集hash。别小看这一行它救过我很多次。过两周回看你还能还原当时机器跑的是什么状态而不是靠聊天记录和记忆去猜测。