演示间里，最容易被忽略的瞬间不是模型给出答案，而是屏幕上的光标停了半秒。用户不会关心背后是排队、批处理还是显存不足，只会觉得这次对话“有点慢”。这类体验问题，往往把团队推向同一个词：推理优化。
延迟不是一个数字，而是一段路径
一次请求从进入系统到返回文本，会经过预处理、排队、模型计算、解码、网络回传。只看端到端耗时，容易把原因归给模型；只看单次调用，又容易忽略并发时的抖动。推理优化先要做的是拆路径：等待发生在哪一段，哪一段会随请求量放大，哪一段只是偶发。
如果首字迟迟不出现，问题可能在排队和预填充；如果输出过程忽快忽慢，解码策略和缓存命中就值得检查；如果只在高峰期变慢，容量与调度策略比模型结构更相关。把这些分开看，优化才不会变成盲目换模型。
省下来的不只是算力
常见手段各有代价。批处理能提高单位时间处理量，却可能拉长尾延迟；量化能降低显存占用，却需要重新检查输出稳定性；缓存复用能减少重复计算，但命中率取决于请求分布。推理优化在这里更像资源调度，而不是某个单点技巧。
- 先明确目标：首字延迟、完整响应时间、单位时间处理量，指向不同做法。
- 再保留基线：用贴近真实请求的测试集记录分段耗时和失败情况。
- 最后小步上线：每次只改一个变量，观察质量与延迟是否同步变化。
边界比技巧更值得说清
有些慢并不来自模型。检索、工具调用、外部接口、前端渲染都可能把等待叠加到用户侧。把问题全压在推理优化上，团队容易在错误层面反复调参，最后只得到一张好看的局部曲线。
可验证的做法是建立贴近真实请求的测试，记录分段耗时、错误类型和输出变化，再决定是否量化、缓存或调整批处理。推理优化不是一次上线动作，而是随流量、内容和使用方式变化的持续校准。它解决的是等待与资源之间的紧张关系，不是把所有场景都压成同一个答案。