晚上十点，客服系统还在回消息。用户问一句，屏幕上的“正在输入”停了两秒。模型没有报错，服务器也没满，但等待已经发生。很多人这时才意识到，推理优化不是训练结束后的收尾工作，而是产品体验的一部分。
先拆开“慢”从哪里来
一次推理请求会经过排队、预处理、模型计算、解码和后处理。用户感知到的延迟，可能来自批处理等待，也可能来自长上下文带来的缓存压力，还可能只是输出被逐字生成。把这些环节混在一起谈优化，容易变成调参比赛。可以先确定约束：是首字延迟重要，还是整段生成时间重要；是单请求响应重要，还是单位时间服务更多请求重要。约束不同，优化的方向也不同。
批处理、缓存与量化：各有各的账
批处理能提升吞吐，但批次等得越久，单个请求的首字延迟会变得明显。KV 缓存能减少重复计算，却会占用显存，长对话里尤其明显。量化可以压低内存和计算开销，但压缩到什么程度，需要看任务对细节的敏感度。投机解码、模型路由、结果缓存也有类似问题：它们不是免费开关，而是把成本从一个位置挪到另一个位置。
- 如果用户对等待敏感，先看排队策略和首字延迟，而不是只看平均耗时。
- 如果请求量大且上下文相似，缓存和前缀复用可能先被考虑。
- 如果显存吃紧，量化值得尝试，但要留出质量回退的验证空间。
这些手段并不互斥，也不存在一套通用配方。真正麻烦的是联动：批处理变大后，缓存命中可能变化；量化之后，某些长尾输出的稳定性可能变化。推理优化因此更像持续观测和回退设计，而不是一次性配置。
别把“快”当成唯一目标
我倾向于把推理优化看成三件事的平衡：响应速度、服务成本、输出质量。只看速度，容易把复杂度推给运维；只看成本，可能牺牲用户体验；只看质量，又会让服务难以承受真实流量。可行的做法是给每类请求设定不同的服务目标，把可接受的回退路径写清楚。比如哪些请求可以走短上下文，哪些请求需要保留完整历史，哪些结果可以缓存，哪些必须重新计算。边界清楚之后，优化才有讨论基础。
还要承认一点：很多线上问题不是模型算得慢，而是上下游配合得不够细。日志是否记录了排队时间，监控是否区分了首字延迟和总延迟，回退策略是否会引发连锁反应，这些工程问题常常直接决定体验，换一个算子未必能解决。推理优化不只是算法话题，它需要产品、后端和运维一起看同一张时间线。
所以，当下一次“正在输入”停住时，不妨先问：我们想优化的是哪一个等待？答案不同，它的落点就不同。