1. 推理延迟概述
我记得那是去年双十一的晚上。凌晨两点，监控告警突然炸了——用户反馈 App 卡在「正在生成报告」界面，平均响应时间从 200ms 飙升到了 3.2 秒。我打开链路追踪一看，问题出在推理服务上：模型推理延迟从 80ms 涨到了 1.8 秒，直接拖垮了整个用户体验。
那次事故让我彻底明白了一个道理：推理延迟不是锦上添花的指标，而是生死线。今天这第一节课，我们就来聊聊推理延迟到底是什么、为什么它如此重要，以及怎么设定合理的优化目标。
什么是推理延迟
说白了，推理延迟就是模型从收到输入到返回输出所花的时间。单位通常是毫秒（ms）。
我习惯把它拆成三个部分来看：
- 预处理延迟：把原始数据转成模型能吃的张量。比如文本分词、图像缩放归一化。
- 模型计算延迟：模型前向传播的时间。这是大头，也是我们优化的主战场。
- 后处理延迟：把模型输出转成业务可用的结果。比如 softmax 转概率、NMS 去重。
关键认知：很多新手只盯着模型计算延迟，却忽略了前后处理。我在项目中遇到过好几次，预处理用了 Python 的 for 循环，结果比模型推理还慢。记住：端到端延迟才是用户感知到的延迟。
为什么推理延迟如此重要
你想想看，用户点一下「生成」按钮，等 5 秒才出结果，他会怎么想？大概率直接关掉 App，甚至卸载。
我整理了几个典型场景的延迟要求：
| 场景 | 可接受延迟 | 延迟过高的后果 |
|---|---|---|
| 实时语音助手 | < 200ms | 对话卡顿，用户放弃使用 |
| 在线推荐系统 | < 100ms | 用户流失，收入下降 |
| 自动驾驶感知 | < 30ms | 安全事故 |
| 批量离线推理 | 分钟级 | 任务超时，资源浪费 |
嗯，这里要注意：延迟每增加 100ms，用户转化率可能下降 1%。这是亚马逊和谷歌用血泪教训换来的数据。
延迟 vs 吞吐量：一对欢喜冤家
很多同学会混淆这两个概念。我打个比方：
- 延迟：你开车从家到公司需要多久。这是单次请求的体验。
- 吞吐量：一条路上同时能跑多少辆车。这是系统的处理能力。
它们之间有个经典的 trade-off：提高吞吐量往往会增加延迟。为什么？
举个例子。你为了提升吞吐量，把 batch size 从 1 调到 32。模型计算效率上去了，每秒能处理更多请求。但第一个请求要等后面 31 个请求凑齐才能开始推理——这叫 batching delay。结果就是：吞吐量翻倍，延迟也翻倍。
我的经验：做优化时，一定要先明确你的核心指标。如果是实时交互场景，延迟优先；如果是离线批处理，吞吐量优先。我曾经在一个项目中同时优化两个指标，结果两边都没做好。后来学乖了：先定主指标，再保副指标。
优化目标怎么设定
设定优化目标不是拍脑袋。我一般按这个步骤来：
- 摸清业务需求：问产品经理，用户能接受的最长等待时间是多少？
- 测量当前基线：用 profiling 工具跑一遍，拿到 P50、P95、P99 延迟。
- 确定优化目标：比如「P99 延迟从 500ms 降到 200ms」。
- 拆解瓶颈：是模型太大？算子太慢？还是 I/O 卡住了？
- 设定里程碑：分阶段达成，比如第一周降到 350ms，第二周降到 200ms。
避坑指南：我曾经设定了一个「把延迟降到 0」的目标——结果可想而知，根本不可能。延迟优化有物理极限，比如网络传输至少需要几毫秒。合理的做法是：设定一个「够用就好」的目标，而不是追求极致。
本章知识体系
下面这张图帮你快速建立本章的知识框架：
小结
这一章我们聊了三个核心问题：
- 推理延迟是什么：端到端的三个组成部分，缺一不可。
- 为什么重要：直接影响用户体验、业务收入和系统稳定性。
- 怎么设定目标：从业务出发，测量基线，拆解瓶颈，分阶段达成。
嗯，最后说一句：延迟优化不是一锤子买卖，而是一个持续迭代的过程。后面的课程里，我会带你一步步深入每个优化环节，从模型压缩到算子优化，从推理引擎到硬件适配。准备好了吗？我们开始吧。