晚上八点，业务看板突然变红：接口响应变慢，机器负载却没跑满。工程师常会先想到换模型、加显卡，但真正要回答的问题是，延迟到底花在哪里。也正是在这种场景里，推理优化才值得被认真对待。
不少团队把推理优化理解成“把模型压小”。这只是一条路径。模型变小可能减少计算量，却未必减少端到端等待；请求排队、内存拷贝、解码策略、批处理窗口，都可能把节省下来的时间又吃掉。先分解，再动手，能避免把问题从一个环节推到另一个环节。
延迟不是单一数字
用户感知的是首字时间和完成时间，系统内部看到的却是排队、预填充、解码、网络回传等不同阶段。把这些阶段混成一个平均值，容易掩盖长尾。可行的做法是按请求类型拆开：短请求看首字，长请求看持续吞吐，交互式场景还要关注抖动。指标拆得细，推理优化才有落点。
批处理与缓存：省时间也借时间
动态批处理能提升硬件利用率，但等待凑批本身会带来延迟。窗口设得太宽，吞吐好看，交互变迟钝；设得太窄，又可能让计算资源空转。缓存也类似：命中率提升能减少重复计算，但缓存失效、内存占用和一致性维护会引入新的复杂度。把它们当成开关，往往会忽略业务节奏；按请求类型调节，才符合实际。
量化和蒸馏，不该被当成默认答案
量化、蒸馏、剪枝常被放在同一张清单里，实际约束并不相同。量化降低表示精度，可能影响输出稳定性；蒸馏依赖训练侧投入，部署侧未必立刻变轻；剪枝则需要考虑硬件对稀疏计算的支持。若缺少评测集和回归流程，这些手段容易把线上问题从“慢”变成“偶发错”。
调度层常被低估
同样的模型，放在不同调度策略下，表现可能差异明显。队列分级、超时控制、降级路径、副本伸缩，看似属于工程侧，却直接决定高峰时谁先拿到算力。如果流量结构不清、服务目标不清，单纯调参只是在局部打转。
先建立可重复的观测
我的判断是，推理优化不该从某个热门技巧开始，而应从可重复的观测开始。固定请求样本，记录阶段耗时和错误类型，保留变更前后的对照，再决定是否引入批处理、缓存或量化。小步上线、可回滚，符合工程现实。延迟预算有限时，先改哪一层，答案往往藏在监控里，而不是模型文件名里。