搞AI系统性能工程这几年，我越来越觉得，真正让一个AI服务“快起来”的，不是某个神奇的优化手段，而是一套能反复复现、能定位瓶颈、能验证结果的方法论。这个系列第一篇，我想先把这套方法论讲清楚，再落到大模型推理这条链路上，聊那些一上来就能用的工具和思路。不管你是AI工程师、后端开发还是SRE，只要手头有一个跑起来总觉得“慢半拍”的模型服务，这篇文章应该能给你一个比较完整的起点。
很多朋友一听到性能工程，第一反应就是压测工具加调参。我最早也这么想，后来发现完全不是这么回事。压测只是照X光，调参是开药，真正难的是知道该照哪里、该吃什么药。所以第一步不是开测，而是把“慢”翻译成一组可量化、可对比、可追踪的指标。
1. 性能工程不等于性能测试：先把目标定义清楚
1.1 从“服务很慢”到一组可量化指标
你问业务方“服务慢不慢”，他大概率会告诉你接口平均耗时几十毫秒。但光有平均耗时一点用都没有。举个典型例子，一个AI问答服务，用户点完发送之后，真正感受到的不是整个请求完成的时间，而是“第一个字多久出来”和“后面每个字流不流畅”。对应到系统指标，就是TTFT（首Token延迟）和TPOT（每个输出Token的间隔时间）。这两个指标比单纯看响应时间的p95更能反映大模型服务的真实体验。
除了体验指标，还要关注系统侧的吞吐和资源利用率。我习惯把指标分成三层：
- 业务体验层：端到端延迟、TTFT、TPOT、错误率、超时率。
- 系统容量层：QPS、吞吐Tokens/s、并发数、队列长度。
- 资源效率层：GPU利用率、显存占用、CPU利用率、内存带宽、NCCL通信量。
指标不是越多越好，关键是每一层能对应到“用户能不能感知到”。比如GPU利用率很高，但用户还是觉得卡，那问题大概率不在算力，而在调度和排队；TTFT一直很稳，但TPOT突然抖动，那可能是Decode阶段被别的请求抢占了。
这一步最容易被忽视，但恰恰是最值得花时间的。我在实际项目里发现，只要指标定义统一了，后面80%的争论都会消失。否则你说是延迟问题，我说是显存问题，最后变成各说各话。
1.2 压测场景设计：先复现，再定量
定义完指标，下一步就是用可信的场景把性能基线打出来。我的习惯是先做小规模真实流量回放，不上来就大并发压测。很多压测工具默认用固定并发连续打，这在传统Web服务上还能凑合，但在AI服务上很容易失真。因为AI服务的负载是可变长输入和可变长输出，比如聊天场景有人问几个字，有人贴一大段文档，返回长度也不一样，对计算和显存的影响天差地别。
我通常这样搭压测场景：
- 从线上日志抽取一段真实请求样本，包含Prompt长度分布、输出长度分布、调用频率曲线。
- 用Locust或k6写压测脚本，按线上比例回放请求。
- 先跑小并发冒烟，确认链路联通，再按阶梯加压：10并发跑5分钟，20并发跑5分钟，40并发跑5分钟。
- 观察延迟曲线和错误率，找到“拐点”——也就是并发数继续增加，但吞吐不再线性增长、延迟开始急剧飙升的那个点。
压测前必须记录环境信息：模型版本、推理引擎版本、GPU型号和数量、显存容量、Batch策略、并发上限、量化方式、Prompt长度分布。我见过太多次“我这边压测60 QPS没问题，你那边怎么才30”，结果一对环境，一个开了连续批处理，一个没开，一个用了FP16，一个用了INT8，数据完全没法对比。
2. AI推理链路的核心瓶颈拆解
2.1 从请求进入到Token返回，时间都去哪了
大模型推理不是一个模型调用，而是一条完整流水线。一次请求大致经过：客户端发起到网关，网关转发到推理服务，服务做鉴权和路由，然后加载对话上下文，走Tokenizer编码，组装输入Batch，交给GPU执行模型前向，采样生成Token，再通过流式接口返回。
这条链路长，意味着瓶颈可能藏在任何一个环节。我接手过一个线上服务，GPU利用率只有40%，但接口延迟忽高忽低。查了半天，发现不是GPU的问题，而是Token编码那一步在CPU上串行执行，一次要处理几千个Token的Prompt，把整个线程卡住了。GPU在干活，但CPU喂不上数据，GPU只能空转等待，这个现象在长上下文场景特别明显。
所以定位瓶颈时，不要一上来就盯GPU。先把链路打点起来，记录每个阶段的耗时。只要每个阶段都有时间戳，真相就藏不住。调用链缺失的项目，第一步永远是补可观测性，而不是优化代码。
2.2 Prefill和Decode：两个阶段，两张面孔
生成式模型处理一次请求，内部明显分成Prefill和Decode两个阶段。Prefill阶段是把用户输入的Prompt一次性并行计算，产出KV Cache，这个阶段是典型计算密集型，GPU算力越高，处理越快。Decode阶段是逐Token生成，每一步都依赖上一个Token，而且每一步都要读取KV Cache，这个阶段变成访存密集型。
这个区别特别重要。哪怕你买了一堆顶级GPU，如果Decode阶段的内存带宽上不去，性能一样被锁死。很多优化手段本质上是围绕这两个阶段的不同特征做文章：
- Continuous Batching：不再等一个Batch全部生成完才释放资源，而是动态地把新请求插入空出的位置，提升GPU利用率。
- PagedAttention：把KV Cache按页管理，像操作系统管理内存一样减少显存碎片，从而支持更大的并发和更长的上下文。
- FlashAttention：通过分块计算和重计算，减少HBM访问量，让Prefill和Decode的Attention都更快。
我经常用一个生活化类比：Prefill像一次把所有货全搬进仓库，需要的是搬运速度；Decode像在仓库里按清单一个一个往外取货，每次取货都要跑到货架前。这时候如果你只在仓库门口加一条传送带，效果有限，真正要优化的是货架摆放和取货路径。
2.3 吞吐、延迟和成本：三角取舍
大模型推理性能里，吞吐、延迟、成本是互相拉扯的。最直接的表现就是Batch Size。Batch Size调大，GPU一次处理更多请求，吞吐上去了，但排在后面的请求要等更长时间，TTFT会显著增加。Batch Size调小，响应很快，但GPU算力浪费，成本居高不下。
我通常的做法是这样的：先和业务方确认SLA，比如TTFT的p95小于1.5秒，TPOT的p90小于80毫秒。在这个约束下，再去压测不同Batch Size策略下能达到的最大吞吐。压测数据里可以看到一个“甜点区”：Batch Size继续增加，吞吐增长变缓，但延迟还在快速上升，那Node就是性价比拐点。
如果成本压力很大，还可以考虑在SLA允许的范围内适当降低精度，或者调整max_new_tokens限制。但每个取舍都要用回放流量验证，不能拍脑袋。
3. 一次性能调优的完整实操记录
3.1 用Profiler拿到可信证据，而不是猜
前面说的都是方法论，这里记录一次我实际做过的调优。当时一个基于PyTorch自研的生成式模型服务，线上GPU利用率在30%到50%之间波动，响应延迟时不时飙到三秒以上。团队第一反应是“模型算子太慢”，有人提出换更贵的GPU，我拦住了，建议先采样。
GPU侧我用Nsight Systems看整条时间线，算子热点用Nsight Compute，模型内部用PyTorch Profiler做逐步打点。命令大概是这样的：
# 抓取GPU timeline，包含CUDA kernel和NVTX标记 nsys profile -o trace -t cuda,nvtx,osrt --capture-range=cudaProfilerApi python serve.py # 分析具体kernel耗时 ncu --set full --target-processes all python serve.py # 实时看GPU状态 nvidia-smi dmon -s pucmet -d 1采样结果出来之后，完全没有争议：GPU上真正耗时的算子并没有明显异常，但CPU侧Token编码线程和Python事件循环里出现大量阻塞段，每次阻塞大约200毫秒，正好和线上延迟抖动的节奏吻合。瓶颈在CPU的数据预处理和调度，不在GPU计算。如果没有这份Trace文件，后面极可能会走弯路。
3.2 动手优化：CPU侧与GPU侧分别处理
定位之后，我做了两步优化，每步只改一个变量，避免混在一起不好评估。
先处理CPU侧。把Tokenizer编码和请求组装放到独立线程池，避免阻塞主事件循环。服务端从同步接口改成异步接口，用Python的async/await把I/O等待时间释放出来。针对动态长度的Prompt，我之前用的是每次Padding到Batch内最大长度，有时候一条长Prompt会把整个Batch的无效计算拉高很多。后来改成按长度分组Padding，配合Attention Mask，无效Token的计算明显减少。
CPU侧改完，GPU利用率从40%提升到了65%，延迟也降了，但离目标还差一点。于是做GPU侧优化：打开模型推理引擎的算子融合，开启FlashAttention，并切换到支持Continuous Batching的推理框架，比如vLLM。这一步的效果更明显，因为框架本身把调度、显存管理、批处理都重写了，不是零散地调某个算子。
优化项我习惯记录成这样一张表：
| 优化项 | 主要作用 | 风险点 | 实测效果 |
|---|---|---|---|
| Tokenizer异步化 | 降低CPU阻塞 | 线程安全 | TTFT p95下降32% |
| 动态Padding改分桶 | 减少无效计算 | 代码复杂度 | GPU利用率提升15% |
| FlashAttention | 加速Attention计算 | 部分算子精度变化 | TPOT p90下降28% |
| 换vLLM引擎 | 自动批处理与显存优化 | 框架适配成本 | 吞吐提升1.8倍 |
这不是说每个项目按这个顺序就一定有效，而是想强调：每一步都要有数据支撑，每步只动一处，这样最终结果才能归因清楚。
3.3 验证与回滚：不要让优化变成一锤子买卖
优化完成后，我没有直接合入生产，而是先做回归验证。具体做法是把线上真实流量回放一份到预发环境，压低并发到生产峰值的80%，跑30分钟，和优化前的基线数据做对比。对比的指标不只看平均延迟，而是看p50、p95、p99、错误率、GPU利用率、显存占用全套数据。
这里有个容易踩的坑：GPU性能波动比CPU大得多，温度变化、其他任务抢占、PCIe链路状态都会影响单次压测结果。所以我每次至少跑三轮，取中位数做结论，别被一次脏数据骗了。如果某一轮出现明显离群值，我不会急着下结论，而是把这个离群值单独拿出来看是不是有冷启动或者碎片收集。
回滚方面，建议把优化前后的推理引擎版本、模型权重哈希、启动参数、环境变量全部固化成配置，最好做到一个“部署包”对应一个可复现的版本。这样即使上线后出了问题，也能快速切回旧版本，而不是花半天时间回忆当时到底改了什么。
4. 让性能工程日常化：监控、预警和团队协作
4.1 搭一套能讲清故事的监控体系
性能不能光靠临时压测，必须有日常监控兜底。很多团队监控面板上只有CPU、内存、GPU利用率这几个老几样，遇到问题根本定位不到原因。我的建议是按“用户链路”搭监控，而不是按“机器资源”搭。
至少分三层：
- 链路层：记录每次请求的TTFT、TPOT、端到端耗时、Token吞吐、错误码。
- 调度层：记录队列长度、排队等待时间、批处理大小、被抢占请求数。
- 资源层：记录GPU利用率、显存使用量、显存碎片率、CPU和内存带宽。
采集端可以用Prometheus，GPU指标通过DCGM Exporter暴露，再配合Grafana做可视化。告警阈值不要拍脑袋。我通常先收集两周历史数据，用基线值加浮动百分比来定，比如“TTFT p99连续5分钟超过基线30%”才告警，避免频繁误报。
4.2 把性能回归测试嵌进CI/CD流程
还有一个容易被忽视的点：性能退化往往不是大版本优化造成的，而是日常小改动一点点累积出来的。比如有人加了一个日志打印，请求量一高内存就涨；有人改了模型前处理逻辑，每次请求多复制一份Tensor，GPU显存压力变大。这些改动单看都不起眼，累积起来很致命。
所以我会在CI/CD里塞一个轻量级性能烟测：固定一小批请求样本，固定并发，每次提交代码时自动跑一遍，对比关键指标是否在可接受范围内。超出阈值就直接拦截合并请求，要求开发者提供原因。这个环节刚推的时候大家觉得烦，时间长了反而是最有效的护栏。
如果要动模型结构、推理引擎或者GPU配置，那可以用更重的性能流水线，晚上定时跑全量压测，生成对比报告发到团队群。别看这个流程土，它比任何“性能负责人”都稳定。
5. 常见问题与排查技巧实录
5.1 从症状到原因的速查表
这些年处理过大大小小不少AI服务性能问题，我整理了一张速查表，虽然不能覆盖所有情况，但至少能让你在“两眼一抹黑”的时候找到方向。
| 症状 | 可能原因 | 第一步排查动作 |
|---|---|---|
| GPU利用率低但接口慢 | CPU侧预处理阻塞、锁竞争、数据加载慢 | 打点链路耗时，用Nsight Systems看CPU/GPU间隙 |
| GPU利用率高但单请求延迟大 | Batch过大、显存带宽不足、存在慢算子 | 用Nsight Compute看Kernel热点 |
| 并发一高就超时 | 队列堆积、未开启连续批处理 | 看队列长度和批处理引擎配置 |
| 显存OOM | KV Cache增长、静态显存分配过大 | 监控KV Cache大小和显存碎片率 |
| 响应忽快忽慢 | 冷启动、其他任务抢占GPU、时钟降频 | 查看GPU时钟频率、任务调度日志 |
| 吞吐上不去但资源没满 | 请求长度极度不均匀、Padding浪费 | 统计Prompt长度分布，检查是否有动态Padding |
这张表是我踩过不少坑才换来的。每次看到新问题，先照着症状找到对应排查方向，再考虑要不要深入优化。
5.2 几个我反复踩过的坑
第一个坑：只看平均延迟。平均延迟被少数慢请求拉高或拉低都看不出来，真正影响用户体感的是长尾请求。所以我后来定了规矩，任何压测报告必须带p50、p95、p99和最大延迟，少一个都算报告不完整。
第二个坑：压测数据不可复现。有一次优化完模型，压测结果比之前好了一倍，团队都挺高兴，后来发现是压测那台机器刚好没有其他任务抢占，而线上是有多个服务共享GPU的。从那以后，我压测之前先检查环境，确认GPU独占、时钟频率稳定、Docker资源限制一致，并且至少跑三轮取中位数。
第三个坑：只优化不回归。优化代码合入后，如果没有一个自动化的性能基线兜底，很容易在新版本上线两周后悄悄退化回去。现在我把“性能基线”当成和单元测试一样的CI检查项，宁可多花十分钟，也不让性能问题漏到生产。
第四个坑：忽略错误率。有时候优化目标只盯着延迟，但压测过程中已经出现大量超时代码返回了错误，延迟数据看似“变好”，其实是慢请求都变成了失败请求，被剔除了统计范围。这属于自己骗自己。
这个系列以后还能聊什么
第一篇先写到这儿，整个框架比单个技巧更重要。我个人的体会是，AI系统性能工程里最值钱的不是某个高性能算子，也不是某个压测工具，而是“定位问题、验证归因、回归防护”的闭环习惯。你每次优化之前，先问自己三个问题：瓶颈到底在哪一层、有没有数据支撑、怎么验证这次改动没有副作用。能把这套闭环跑起来，后面再聊GPU Kernel优化、分布式推理、长上下文显存优化，或者训练阶段的性能工程，就不会觉得是在堆技巧，而是顺着同一条思路往下挖。
最后分享一个我的小习惯：每次优化记录里都写一句“我为什么改”，不光是“我改了什么”。这个习惯帮我省了无数次返工。希望这个系列的开篇也能帮你把AI服务的性能底子打牢。
