第1章 · 性能优化全景图
说实话，我做了这么多年推理系统，最常被问到的问题就是：“我的模型跑得挺快，还需要优化吗？” 嗯，每次听到这个，我都想反问一句——你确定它真的“快”吗？还是只是没遇到真正的压力？
这一章，咱们不急着上工具，也不谈复杂的算子。先退一步，看看全局。我个人习惯把性能优化比作“找短板”——你想想看，一个推理应用就像一串水管，水流速度取决于最窄的那一节。而我们要做的，就是找到那节窄管，把它撑大。
为什么推理应用需要优化？
你可能觉得，模型能跑出结果不就行了？但实际线上环境根本不是这么回事。我记得有一次帮一个团队排查线上服务，他们的模型在单机测试时延迟只有 30ms，结果一上线并发一上来，直接飙到 800ms，用户疯狂超时。你说这是为什么？说白了，就是没考虑资源竞争和排队效应。
推理优化不是为了炫技，而是为了省钱、省时间、省资源。你想想看，同样的硬件，优化后吞吐量翻倍，意味着你可以少买一半的机器。这可不是小数目。
性能瓶颈的常见类型
我习惯把瓶颈分成四大类，几乎所有的性能问题都能归到这几类里。咱们一个一个说。
- 计算瓶颈 —— 算子本身太重，或者调度开销大。比如 Transformer 里的 Attention 计算，显存带宽不够时计算单元就在空转。我曾经在一个 BERT 推理服务里发现，40% 的时间花在了小算子的 kernel launch 上，而不是真正的计算。
- 内存瓶颈 —— 显存不够、带宽打满、或者碎片太多。大模型推理时，KV Cache 动不动就占几十 GB，一旦超过容量就得换入换出，延迟直接爆炸。
- I/O 瓶颈 —— 模型加载、预处理、后处理、磁盘读写。我见过一个 OCR 服务，预处理部分用了 PIL 反复解码，一张图花了 200ms，推理本身才 20ms。你说冤不冤？
- 网络瓶颈 —— 客户端到服务端的传输、跨机通信、gRPC 序列化。尤其是分布式推理，AllReduce 的通信量一大，网络带宽就成了天花板。
💡 避坑指南： 我曾经犯过一个低级错误——优化了半天算子，结果发现瓶颈是客户端把图片转成了 base64 再传输，解码开销比推理还大。所以，先测量，再优化，别凭感觉。
性能优化的核心指标
没有指标，优化就是瞎忙活。我个人最关注的三个指标：
| 指标 | 定义 | 典型场景 |
|---|---|---|
| 延迟 (Latency) | 单个请求从发起到返回的时间 | 在线对话、实时翻译，要求 p99 < 200ms |
| 吞吐量 (Throughput) | 单位时间内处理的请求数 | 离线批量处理、数据标注，追求 QPS 最大化 |
| 资源利用率 | GPU/CPU/内存的使用率 | 成本敏感场景，希望把硬件压到 80% 以上 |
这三个指标经常互相制约。你降低延迟，可能就得牺牲吞吐量；你拼命压吞吐，延迟可能就上去了。嗯，这就是所谓的性能三角。实际项目中，你得根据业务目标做取舍。
🎯 我的经验： 对于在线推理服务，我一般先卡 p99 延迟的硬上限（比如 500ms），然后在这个约束下最大化吞吐量。千万别只盯着平均延迟，平均延迟会骗人——尾延迟才是用户体验的杀手。
怎么开始优化？一个简单的框架
你不需要一上来就搞大动作。我建议按这个步骤来：
- 定义指标 —— 延迟、吞吐量、资源利用率，选一个作为北极星。
- 测量基线 —— 用 perf、nsys、py-spy 等工具跑一次完整的 profile。
- 定位瓶颈 —— 看看是计算、内存、I/O 还是网络？用本章的分类去套。
- 针对性优化 —— 算子融合、显存复用、异步加载、连接池……后面章节会细讲。
- 验证效果 —— 同样的条件再测一次，对比基线。如果没提升，就回退。
这个循环看起来简单，但很多人跳过了第一步和第二步，直接开始改代码。我见过太多“优化”之后反而变慢的例子了。
⚠️ 注意： 不要同时优化多个地方。一次只改一个变量，否则你根本不知道哪个改动起了作用。我曾经同时改了量化精度和批处理大小，结果延迟下降了，但搞不清是谁的功劳——后来发现量化引入的误差让模型提前退出了，根本不是优化。
好了，这一章咱们把全景图搭起来了。后面每一章都会深入一个具体的瓶颈类型或优化手段。你心里有了这张图，再遇到性能问题就不会慌了——先分类，再定位，最后动手。