1. AI 系统性能工程的核心命题拆解1.1 为什么性能工程在 AI 时代变得不可回避做后端或者做基础架构的同学这几年应该有个明显感受以前性能优化是锦上添花现在做 AI 系统性能直接决定这套东西能不能上线。我接触过好几个团队模型效果调得漂漂亮亮一上生产环境就崩——推理延迟从实验室的 200ms 飙到 2sGPU 利用率长期趴在 30% 以下显存动不动就 OOM。这不是模型的问题是性能工程没做到位。AI 系统性能工程和传统 Web 性能工程最大的区别在于瓶颈的位置变了。传统系统瓶颈通常在数据库 IO、网络带宽、锁竞争这些地方而 AI 系统的瓶颈高度集中在计算密集型的矩阵运算、显存带宽、以及数据在 CPU 和 GPU 之间的搬运上。你拿以前那套加缓存、加索引、加机器的套路去套 AI 系统大概率是无效的因为 GPU 利用率上不去的时候加机器只是让更多 GPU 一起闲着。这一篇我打算把 AI 系统性能工程里最核心的几个环节拆开讲性能指标怎么定义、瓶颈怎么定位、推理服务怎么调优、以及工程落地时那些文档里不会写的坑。内容偏实战适合已经有一定 AI 部署经验、但性能总是差一口气的工程师参考。1.2 性能工程要盯住的四类核心指标很多人一上来就说我要优化性能但问他优化什么指标答不上来。性能工程的第一步永远是把指标定义清楚否则你根本不知道优化有没有效果。AI 系统里我通常盯这四类指标类别具体指标典型目标说明延迟类P50/P95/P99 延迟、首 token 延迟P99 500ms首 token 延迟对交互式应用尤其关键吞吐类QPS、tokens/s、batch 吞吐视业务而定吞吐和延迟通常互相拉扯资源类GPU 利用率、显存占用、CPU 占用GPU 利用率 70%利用率低说明有等待或调度问题成本类单次推理成本、每千 token 成本越低越好最终决定商业可行性这里要特别强调P99 而不是平均值。平均值是最会骗人的指标一个系统平均延迟 100ms但 P99 是 3s用户体验就是时不时卡一下这种系统在交互场景里基本没法用。我见过太多团队拿着平均延迟汇报性能良好结果线上投诉不断。提示定义指标时一定要和业务方对齐。离线批处理看吞吐在线交互看 P99 延迟两者优化方向完全不同别用一套标准衡量所有场景。1.3 性能优化的收益递减规律还有个心态问题必须提前说清楚性能优化是收益递减的。从 30% GPU 利用率优化到 60%可能只需要改几个配置从 60% 到 80%要动调度逻辑从 80% 到 90%可能要重写整个推理框架。所以工程上要算投入产出比别为了最后那 5% 的利用率把团队拖垮。我的经验是先把系统从明显有问题优化到行业平均水平这一步性价比最高通常能拿到 2-3 倍的提升。再往上就是精细活了要看业务是否真的需要。很多场景下60% 的 GPU 利用率配上合理的成本控制已经足够支撑业务了。2. 性能瓶颈定位的完整方法论2.1 先分层再定位别一上来就猜性能问题最忌讳的就是我觉得是 XX 的问题。我见过有人一遇到延迟高就怀疑模型太大结果查了半天发现是数据预处理在 CPU 上单线程跑把整个 pipeline 卡住了。正确的做法是分层定位把 AI 系统的执行链路拆成几段逐段测量。一个典型的推理请求链路是这样的请求接入 → 数据预处理 → 模型推理 → 后处理 → 结果返回。每一段都要有独立的耗时埋点。我通常用一张表把各段耗时列出来一眼就能看出瓶颈在哪# 简化的分层埋点示例 import time def handle_request(raw_input): t0 time.perf_counter() preprocessed preprocess(raw_input) t1 time.perf_counter() output model_inference(preprocessed) t2 time.perf_counter() result postprocess(output) t3 time.perf_counter() metrics.record(preprocess_ms, (t1 - t0) * 1000) metrics.record(inference_ms, (t2 - t1) * 1000) metrics.record(postprocess_ms, (t3 - t2) * 1000) return result这段代码看着简单但它是定位问题的起点。没有分层数据后面所有优化都是盲猜。2.2 GPU 利用率低的三类根因GPU 利用率上不去是 AI 系统性能问题里最高频的一类。我把它归成三类根因对应不同的排查手段第一类是数据供给不足。GPU 算得飞快但数据从磁盘、从网络、从 CPU 预处理送不过来GPU 就在那干等。这种情况用nvidia-smi看利用率会看到锯齿状的波动一会儿高一会儿低。解决办法通常是加大数据预取的 buffer、把预处理放到 GPU 上做、或者用多进程并行预处理。第二类是 kernel 启动开销。小 batch 推理时每个 kernel 执行时间很短但启动 kernel 本身有固定开销导致 GPU 大量时间花在启动而不是计算上。这种情况的典型特征是 batch size 越小利用率越低。解决办法是增大 batch、用 CUDA Graph 把多个 kernel 合并提交。第三类是同步等待。比如 CPU 和 GPU 之间频繁做同步拷贝或者代码里有隐式的.item()、.cpu()调用强制同步。这类问题最隐蔽因为代码逻辑上没问题但性能就是上不去。2.3 用 profiling 工具把问题钉死光靠nvidia-smi只能看个大概要精确定位得用 profiling 工具。PyTorch 生态里torch.profiler是标配它能告诉你每个算子花了多少时间、GPU 空转了多少import torch from torch.profiler import profile, ProfilerActivity with profile( activities[ProfilerActivity.CPU, ProfilerActivity.CUDA], record_shapesTrue, profile_memoryTrue, ) as prof: for _ in range(10): model(input_tensor) print(prof.key_averages().table(sort_bycuda_time_total, row_limit20))跑完这段你会拿到一张按 CUDA 耗时排序的算子表。如果发现某个意料之外的算子排在前面比如某个 reshape 或者 copy那基本就是问题所在。我踩过的一个坑是模型里有个torch.cat在循环里反复调用每次都在 GPU 上重新分配显存导致大量时间花在显存分配上。改成预分配 buffer 之后推理速度直接快了 40%。注意profiling 本身有开销别在生产环境常开。我一般是在压测环境跑 profiling定位到问题后再针对性优化。2.4 显存瓶颈的排查思路显存 OOM 是另一个高频问题。排查显存不能只看用了多少要看谁用的。torch.cuda.memory_summary()能给出详细的显存分配情况包括已分配、已缓存、碎片情况。显存问题通常有三个来源模型参数、激活值、以及临时 buffer。模型参数是固定的激活值跟 batch size 和序列长度强相关临时 buffer 则经常被忽略。我遇到过一个案例模型本身只占 8GB但推理时峰值显存到了 20GB最后发现是 attention 计算里的中间张量没有及时释放。解决办法是用torch.no_grad()包住推理、及时del中间变量、必要时用 gradient checkpointing 的思路做激活重计算。3. 推理服务性能调优的实操路径3.1 batch 策略动态 batch 才是生产环境的答案实验室里大家习惯固定 batch size但生产环境的请求是随机到达的固定 batch 要么浪费等不满、要么延迟高等太久。动态 batch也叫 continuous batching 或 in-flight batching是生产环境的标配。它的核心思想是不等一个 batch 凑满再送 GPU而是每来一个请求就塞进当前正在执行的 batch 里谁先算完谁先走。这样 GPU 几乎不会空转吞吐能提升好几倍。vLLM、TensorRT-LLM 这些推理框架都内置了这个能力。但动态 batch 不是免费的午餐它带来两个新问题一是显存管理变复杂每个请求的 KV cache 大小不同二是调度逻辑本身有开销。所以 batch 的上限要设合理我一般从 32 或 64 开始试根据显存和延迟表现调整。3.2 量化用精度换性能的取舍量化是提升推理性能最直接的手段之一。FP16 换 FP32 通常无损且提速明显INT8 量化能再快一截但可能掉点INT4 就更激进了。我的建议是分层量化对精度敏感的层比如第一层和最后一层保留高精度中间层大胆量化。实操上PyTorch 的torch.quantization和 TensorRT 的量化工具都能用。但要注意量化后的模型一定要做精度回归测试别只看速度。我见过量化后速度翻倍、但输出质量明显下降的案例最后只能回退。精度相对速度显存占用精度损失适用场景FP321x100%无训练、精度敏感推理FP161.5-2x50%极小大多数推理场景INT82-4x25%小到中吞吐优先场景INT44-8x12.5%中到大边缘设备、极致成本3.3 KV cache 管理长上下文场景的命门做 LLM 推理的同学对 KV cache 一定不陌生。它把历史 token 的 key/value 缓存下来避免重复计算但代价是显存占用随上下文长度线性增长。长上下文场景下KV cache 往往比模型本身还占显存。优化 KV cache 有几个方向一是PagedAttention把 KV cache 分页管理减少碎片二是KV cache 量化把缓存也压到 INT8三是前缀共享多个请求如果有相同前缀比如相同的 system prompt可以共享这部分 cache。这几个手段组合起来长上下文场景的显存占用能降一半以上。3.4 一个完整的调优案例说个我实际做过的案例。一个文本生成服务初始状态是单卡 A100P99 延迟 1.8sGPU 利用率 35%QPS 只有 8。业务方要求 P99 降到 500ms 以内QPS 提到 30。我的调优步骤是这样的第一步profiling 定位。发现 60% 的时间花在数据预处理上而且预处理是单线程的。改成多进程预处理后延迟降到 1.2s。第二步上动态 batch。用 vLLM 替换原来的手写推理循环吞吐直接翻倍QPS 到 18。第三步FP16 量化。模型从 FP32 换成 FP16延迟再降 30%QPS 到 26。第四步调 KV cache 和调度参数。把 block size 从 16 调到 32gpu_memory_utilization 从 0.8 调到 0.9QPS 到 32P99 稳定在 420ms。整个过程花了大概一周没有改模型结构纯工程优化。这个案例说明一个道理大部分 AI 系统的性能问题根因都在工程层面而不是模型层面。4. 环境搭建与基础设施的性能考量4.1 云主机选型别只看 GPU 型号搭建 AI 推理环境时很多人只盯着 GPU 型号忽略了其他配置。实际上CPU 核数、内存带宽、网络带宽、磁盘 IO都会成为瓶颈。我见过 GPU 是 A100 但 CPU 只有 4 核的配置数据预处理直接卡死GPU 全程闲着。选型时我的经验是CPU 核数至少是 GPU 数的 4-8 倍内存至少是显存的 2 倍网络带宽要能支撑模型加载和数据传输。如果是多机推理机器间的网络延迟和带宽更是关键这时候专线或者高带宽内网就很有必要。4.2 操作系统与驱动版本稳定压倒一切云主机用什么系统这个问题看似简单实则坑很多。我的建议是用推理框架官方推荐的系统版本别自己乱选。比如某些 CUDA 版本对内核版本有要求内核太新或太旧都可能出问题。驱动版本同理。GPU 驱动、CUDA、cuDNN、推理框架这四者的版本兼容性是个矩阵任何一个不匹配都可能报奇怪的错。我一般会锁定一套经过验证的版本组合写进部署文档团队统一使用避免我这能跑你那不能跑的问题。提示部署前一定要在目标环境做一次完整的冒烟测试包括模型加载、单次推理、并发推理。很多兼容性问题只在特定环境暴露。4.3 高可用与容灾性能工程的隐藏维度性能工程不只是快还包括稳。一个 P99 延迟 400ms 但每周挂一次的系统实际可用性远不如 P99 延迟 600ms 但全年稳定的系统。所以高可用设计是性能工程的一部分。AI 推理服务的高可用要考虑几点一是多副本部署单副本挂了能自动切换二是健康检查不只是端口通不通还要检查模型是否真的能推理三是优雅降级GPU 资源不足时能降级到小模型或者排队而不是直接报错。对于有安全防护需求的场景前置的防护层要能扛住流量冲击避免异常流量直接打到推理服务上。这块的配置要和推理服务的容量匹配别防护层扛住了但推理层被打垮。4.4 监控体系没有监控就没有性能工程最后说监控。性能优化做完不是终点得持续监控才能保证不退化。我通常搭三层监控基础设施层GPU 利用率、显存、温度、CPU、内存、网络服务层QPS、延迟分布、错误率、队列长度业务层生成质量、用户反馈、成本指标这三层要能联动。比如业务层发现质量下降能快速下钻到服务层看是不是延迟升高导致超时再下钻到基础设施层看是不是 GPU 出了问题。没有这套体系性能问题永远是事后救火。5. 常见性能问题速查与避坑经验5.1 高频问题速查表现象可能根因排查手段解决方向GPU 利用率低且波动数据供给不足看预处理耗时多进程预处理、预取 bufferGPU 利用率低且平稳kernel 启动开销看 batch size 影响增大 batch、CUDA Graph延迟高但 GPU 不忙CPU 侧瓶颈分层埋点优化预处理、减少同步显存 OOM激活值或碎片memory_summary减小 batch、激活重计算吞吐上不去调度或 batch 策略看队列长度动态 batch、调调度参数长上下文变慢KV cache 膨胀看 cache 占用PagedAttention、cache 量化5.2 几个我踩过的坑坑一盲目增大 batch。以为 batch 越大吞吐越高结果显存爆了或者延迟高到没法用。batch 要结合显存和延迟目标一起调不是越大越好。坑二忽略冷启动。模型第一次加载、第一次推理特别慢如果没做预热线上第一批请求体验极差。解决办法是服务启动后主动跑几次推理预热。坑三profiling 开在生产。profiling 有开销生产环境常开会让性能数据失真甚至拖慢服务。只在需要时开开完就关。坑四只看平均值。前面说过平均值会骗人。一定要看 P95、P99甚至 P999。坑五优化完不回归。性能优化可能引入正确性问题每次优化后都要跑精度回归测试别为了速度丢了质量。5.3 性能优化的心态建议最后分享一点心态上的经验。性能优化是个迭代的过程不是一次性的任务。你今天优化到 P99 400ms明天业务量涨了、模型换了、数据分布变了性能可能又退化。所以要把性能工程当成持续的工作而不是项目上线前突击一下。另外别追求极致性能。工程上讲究的是够用且稳定。一个 P99 500ms 但稳定运行半年的系统比一个 P99 300ms 但每周出一次故障的系统有价值得多。性能是手段业务稳定才是目的。我在实际项目里最深的体会是AI 系统性能工程80% 的收益来自 20% 的关键优化——分层定位、动态 batch、合理量化、KV cache 管理把这四件事做好大部分系统都能达到生产可用的水平。剩下的精细调优等业务真的需要了再说。