性能指标定义：吞吐量、延迟、P99延迟、资源利用率、成本效益比
做多模型流水线部署，第一件事不是调参数，而是搞清楚——你到底要优化什么？
我见过不少团队，一上来就盯着某个指标猛调，结果发现另一个指标崩了。说白了，性能调优是个多目标博弈。你得先定义清楚游戏规则，才能知道往哪个方向使劲。
吞吐量（Throughput）
吞吐量，就是单位时间内能处理多少个请求。比如每秒能跑多少个推理任务，或者每分钟能处理多少张图片。
我个人习惯用 QPS（Queries Per Second） 来衡量。在多模型流水线里，吞吐量往往受限于最慢的那个环节。你想想看，A模型每秒能处理100个请求，B模型只能处理10个，那整个流水线的吞吐量就是10。
我在项目中遇到过一个问题：两个模型单独跑都能达到50 QPS，但串起来之后，总吞吐量只有15 QPS。为什么？因为中间的数据传输和格式转换成了瓶颈。嗯，这里要注意，吞吐量不只是模型推理速度，还包括I/O、预处理、后处理这些环节。
延迟（Latency）
延迟，说白了就是一个请求从进来到出去，总共花了多少时间。单位通常是毫秒。
延迟分两种：
- 端到端延迟：用户发起请求到收到响应的总时间
- 单模型延迟：流水线中每个模型的处理时间
我建议你在做性能分析时，先把端到端延迟拆开，看看每个环节各花了多少时间。我曾经遇到一个案例，端到端延迟是500ms，结果发现光数据预处理就占了300ms。你说这模型优化得再好，有啥用？
P99延迟
平均延迟有时候会骗人。你算出来平均延迟是100ms，但可能有10%的请求延迟超过500ms。对于用户体验来说，那些慢请求才是真正的痛点。
P99延迟，就是排除了最慢的1%请求之后，剩下的请求中最大的那个延迟值。换句话说，99%的请求都比这个值快。
我记得有一次做线上压测，平均延迟只有80ms，看起来挺漂亮。但一查P99，好家伙，直接飙到1.2秒。后来发现是某个模型在并发高的时候触发了内存交换，导致部分请求被阻塞。如果不看P99，这个问题根本发现不了。
常见的P99优化手段：
- 增加超时控制和重试机制
- 对慢请求做降级处理
- 使用异步流水线，避免串行阻塞
资源利用率
你买了8张GPU卡，结果每张卡只用了30%的算力，这不是浪费吗？资源利用率就是看你的硬件到底被用到了什么程度。
主要关注几个指标：
| 资源类型 | 关键指标 | 理想范围 |
|---|---|---|
| GPU | 算力利用率、显存占用 | 70%-90% |
| CPU | CPU使用率、上下文切换 | 60%-80% |
| 内存 | 内存使用量、交换分区 | 避免swap |
| 网络 | 带宽使用率、延迟 | 低于80% |
我曾经犯过一个错误：为了追求高吞吐量，把GPU利用率压到了95%以上。结果呢？P99延迟直接翻倍，因为GPU队列太长，请求都在排队等着。后来我学乖了，资源利用率不是越高越好，得留点余量应对突发流量。
成本效益比
做性能优化，最终还是要算账的。你花10万块钱买新硬件，把延迟从200ms降到150ms，值不值？这就要看成本效益比了。
我一般用这个公式来算：
成本效益比 = 性能提升幅度 / 投入成本
举个例子：
方案A：加1张A100显卡，吞吐量提升30%
方案B：优化模型结构，吞吐量提升15%，但只需要人力成本
如果方案A的成本是方案B的3倍，那方案B的性价比反而更高。说白了，性能调优不是炫技，是做生意。你得考虑投入产出比。我见过有人为了把延迟降低5ms，花了两周时间调优，结果发现换个网络协议就能降10ms。嗯，方向比努力更重要。
常见的成本效益分析维度：
- 硬件成本：GPU、CPU、内存、网络设备
- 运维成本：电力、散热、机房空间
- 人力成本：开发调优的时间
- 机会成本：优化这个环节，可能耽误了其他更重要的优化
最后总结一下这五个指标的关系：
- 吞吐量和延迟通常是矛盾的——想提高吞吐量，往往要牺牲延迟
- P99延迟是用户体验的底线，不能只看平均值
- 资源利用率要适度，别为了省成本把系统压垮
- 成本效益比是决策的最终依据，别为了优化而优化
你想想看，如果连指标都没定义清楚，你怎么知道优化有没有效果？所以，动手之前，先把这五个指标定下来。后面所有的调优工作，都是围绕它们展开的。