夜里十一点，模型服务准备上线。监控大屏上，平均延迟看起来体面，P99 却偶尔抬高；GPU 利用率不算低，账单预估却比预算多出一截。团队原以为把模型量化一下，再换更快的算子，优化就算完成。真正把延迟、吞吐、显存和电费放进同一张表后，问题才显出来：瓶颈不在矩阵乘法，而在请求排队。
这类场景并不罕见。训练看的是把模型收敛到可用，推理看的却是长期运行的成本与稳定性。两者都关心算力，但推理面对的是连续到来的请求、长短不一的输入、波峰与波谷。一个在离线评测中跑得很快的模型，到了线上可能被批处理策略拖住；一个看似节省显存的方案，也可能因为频繁换入换出，让响应时间变得不稳定。
先找瓶颈，再谈压缩
谈推理优化，压缩模型是常见入口：量化、蒸馏、剪枝，各有适用边界。但压缩并不自动等于更快。若服务受限于内存带宽，降低权重精度可能有效；若受限于调度和排队，单次计算再快，用户仍要等。更稳妥的做法是先描出请求路径：输入预处理、批处理窗口、模型执行、后处理、网络返回。看哪一段在长时间运行中反复成为尾部延迟的来源，再决定优化对象。
批处理是个典型例子。把更多请求合并起来，吞吐通常会改善，但等待凑批的时间也会增加。对离线任务，这种交换划算；对交互式应用，用户感知的是从点击到返回的完整体验。动态批处理、连续批处理之所以被反复讨论，本质是在吞吐与延迟之间找一条可调的线。线画在哪里，不该由框架默认值决定，而应由业务能接受的等待上限决定。
账本里的推理优化
把电费纳入视角，会改变一些判断。推理服务不是跑一次评测，而是持续消耗资源。闲置实例、过度预留、低利用率的加速卡，都会把成本摊到每次请求上。此时，推理优化的目标不只是“更快”，还包括“在需求低谷时收得住，在峰值时撑得住”。弹性伸缩、请求排队上限、缓存命中率、模型路由，这些偏系统的动作，往往和算子优化同样重要。
- 先确认延迟指标：平均延迟会掩盖尾部问题，P95、P99 与超时率要一起看。
- 再确认成本口径：单次请求成本、空闲成本与峰值成本分开算，避免只看总额。
- 还要确认可回退：任何压缩或调度调整，都应保留灰度与回退路径。
也需要承认边界。推理优化不是把所有指标同时推到理想状态。更低延迟可能牺牲吞吐，更高吞吐可能增加排队，更省显存可能带来精度损失。可行的做法，是先把不可接受的下限说清楚：哪些请求不能超时，哪些场景允许降级，哪些成本不能越线。剩下的，才是工程取舍。
所以，上线前的那张账本值得认真推演。它不保证服务一定稳定，却能逼团队回答一个朴素问题：我们优化的究竟是某个评测数字，还是用户真正经历的那几秒。想清楚这一点，优化才不至于变成一堆看似先进的开关。