监控面板上，延迟曲线在晚高峰后没有立刻回落。模型没换，流量也没有明显暴增，用户却开始觉得“它今天有点迟钝”。这类问题很少出现在发布材料里，却会在不少上线后的 AI 系统里冒出来。此时被拉出来讨论的，往往不是新模型，而是推理优化。
推理优化听起来像工程团队的内部词，实际解决的是很具体的事：一次请求从进入系统到返回结果，要经过预处理、调度、计算、显存读写和后处理。任何一段变慢，用户感知到的就是“等”。系统另一端，资源利用率、并发能力和单位请求成本又在拉扯。延迟、吞吐、成本很难同时舒展，优化常常是在它们之间找临时平衡。
先把“慢”拆开看
很多团队一开始会盯着模型计算，觉得算得不够快。但线上系统里，等待可能来自排队，也可能来自数据搬运。GPU 算力空转时，显存带宽已经吃紧；批量调大后吞吐上去了，单次请求的尾延迟却可能变长。于是不能只看一个指标，而要先判断瓶颈在哪一层。
- 请求在不同服务间排队，调度策略就值得检查。
- 长上下文反复读取缓存，KV cache 的管理方式会影响内存占用和响应速度。
- 模型权重和激活值占用过高，量化、算子融合可能换来更轻的运行时开销。
- 流量波动明显时，动态批处理与超时设置需要一起看，不能只调一个参数。
这些手段并不新鲜，难的是组合。把批量开大，吞吐可能改善，交互体验却变差；把量化压狠，资源占用下降，输出稳定性又需要重新评估。这套组合更像一场带约束的编辑工作：删掉不必要的等待，保留必须的可靠性。
缓存不是万能抽屉
缓存常被当成提速捷径。上下文缓存、前缀缓存、结果缓存，确实能减少重复计算。但它们也在引入新的判断：什么该存，存多久，命中不了时如何回退。若缓存策略和业务语义脱节，用户可能拿到过时结果，或者系统为了维护缓存付出更多内存。对缓存策略而言，价值不只在“命中”，更在“可预期的失效”。
另一个容易被忽略的边界是评估方式。离线基准里的平均延迟，和线上用户遇到的尾延迟，并不是一回事。只看平均值，可能掩盖少数请求的长等待；只看单次峰值，又可能让系统过度保守。更务实的做法，是把延迟分布、错误回退和资源占用放在同一张观察表里，再决定是否调整批处理、量化或调度。
优化到最后，是取舍透明
推理优化并不承诺把每个请求都压到极低延迟。它更像在告诉团队：当前系统的瓶颈在哪里，哪些体验可以妥协，哪些成本必须保留。模型能力继续演进，硬件也在变化，今天的参数组合未必适合下个月。把监控、回滚和灰度发布做扎实，比追逐某个单点技巧更耐久。
所以，当响应又慢半拍时，先别急着换模型。把请求路径摊开，看看等待发生在哪一段，再决定是否动用推理优化。它不响亮，却常常决定一个 AI 功能能不能被日常使用。