1. 推理加速概述：为什么需要推理加速？

大家好，我是这门课的主讲。今天咱们聊聊推理加速——说白了，就是让训练好的模型在“干活”的时候跑得更快、更省、更稳。

你可能觉得，模型能跑起来不就行了？嗯，我刚开始也这么想。直到有一次，我把一个BERT模型部署到线上，结果单次推理耗时300毫秒，用户反馈“转圈圈转半天”。老板问我：“这玩意儿能用吗？”我哑口无言。从那以后，我彻底明白了——推理性能不是锦上添花，而是生死线。

1.1 为什么需要推理加速？

先看几个真实场景：

• 实时对话系统：用户说一句话，你必须在几百毫秒内回复。慢了，对话就断了。
• 自动驾驶：摄像头拍到障碍物，模型必须在几十毫秒内做出判断。延迟一高，可能就是事故。
• 批量图像处理：电商平台每天要审核几百万张图片，单张慢1毫秒，一天就多出近20分钟。
• 边缘设备：手机、IoT设备上跑模型，算力有限，内存有限，不加速根本跑不动。

我见过一个团队，把模型从PyTorch直接搬到手机端，没做任何优化。结果呢？推理一次要5秒，手机发烫，用户直接卸载。后来他们用了量化+剪枝，推理时间降到200毫秒，内存占用也砍了一半。这就是推理加速的价值。

1.2 推理加速的核心挑战

推理加速要解决三个核心问题：延迟、吞吐量、成本。这三个指标互相牵制，你很难同时做到最优。我习惯把它们称为“不可能三角”。

1.2.1 延迟（Latency）

延迟，就是模型处理一个请求需要多长时间。单位通常是毫秒。

• P50延迟：一半请求的耗时。这个指标代表“典型体验”。
• P99延迟：99%请求的耗时。这个指标代表“最差体验”。

为什么P99更重要？因为用户不会记住99次流畅的体验，但会记住那1次卡顿。我在做推荐系统时，P50只有50毫秒，但P99飙到了800毫秒。排查后发现，是某个特征工程模块在极端数据下触发了慢路径。优化后P99降到120毫秒，用户满意度直接提升了15%。

1.2.2 吞吐量（Throughput）

吞吐量，就是单位时间内模型能处理多少个请求。单位通常是QPS（每秒查询数）或TPS（每秒事务数）。

延迟和吞吐量是什么关系？你想想看：

• 如果每个请求处理得很快（低延迟），单位时间内就能处理更多请求（高吞吐量）。
• 但如果你把请求批量处理（batch），单个请求的延迟可能会增加，但整体吞吐量会大幅提升。

举个例子：

策略	单次延迟	批量大小	吞吐量（QPS）
单请求处理	10 ms	1	100
批量处理（batch=8）	40 ms	8	200

看到了吗？批量处理让单次延迟从10ms涨到40ms，但吞吐量翻了一倍。这就是延迟和吞吐量的权衡。我在做广告点击率预估时，就遇到过这种选择——用户点击广告必须实时响应，所以延迟不能超过50ms；但后台又有海量请求需要处理。最后我们用了动态批处理：请求少时单条处理，请求多时自动合并成batch。

1.2.3 成本（Cost）

成本，说白了就是钱。包括：

• 计算成本：GPU/CPU的算力消耗。用更贵的硬件当然更快，但预算有限。
• 内存成本：模型参数和中间结果占用的显存/内存。大模型动辄几十GB，不是所有设备都装得下。
• 带宽成本：数据传输的耗时和费用。尤其是跨机房、跨地域的推理。

我见过一个团队，为了追求极致延迟，给每个模型都配了A100 GPU。结果呢？月账单出来，老板直接叫停项目。后来他们改用量化+CPU推理，延迟只增加了30%，但成本降了80%。

1.3 三个挑战的权衡

延迟、吞吐量、成本，这三者就像跷跷板。你压下一头，另一头就会翘起来。我习惯用一张图来理解它们的关系：

你看，三个角互相拉扯。你追求低延迟，可能就要牺牲吞吐量或增加成本。你追求低成本，可能就要接受更高的延迟。没有完美的方案，只有最适合你业务的方案。

1.4 推理加速的常见手段

既然挑战这么明确，那怎么解决呢？我简单列一下后续章节会深入讲解的技术：

• 模型压缩：量化、剪枝、蒸馏。把模型变小，自然跑得快。
• 推理框架优化：TensorRT、ONNX Runtime、OpenVINO。这些框架专门为推理做了极致优化。
• 硬件加速：GPU、TPU、NPU。选对硬件，事半功倍。
• 系统级优化：批处理、流水线、异步推理。从架构层面提升效率。
• 算子融合：把多个小算子合并成一个大算子，减少内存访问和计算开销。

1.5 本章小结