午后三点，客服系统里的自动回复突然慢了一拍。模型没有换，问题也不复杂，等待却从“几乎立刻”变成“要等一下”。这类变化很少写在产品公告里，却会直接影响用户是否愿意继续对话。此时谈推理优化，不能只盯着模型本身。
慢半秒，不一定是模型变笨了
一次回答要经过请求排队、上下文读取、前向计算、结果返回等环节。前端看到的是半秒，后端可能已经跨过几道队列。午后流量上来，批处理等待变长；上下文变多，缓存命中下降；并发一高，显存和带宽开始互相挤占。模型参数没变，推理路径却变了。把“慢”拆开看，才会知道该动哪一段，而不是笼统地要求换模型或加机器。
批处理与缓存：省时间，也省算力
批处理把多个请求合并计算，能摊薄单次开销，但等待窗口一长，用户会先感到延迟。窗口调小，响应显得利落，单位算力又可能上升。缓存则更像把常见上下文留在手边，命中时省掉重复计算，命中不了就退回原路。它们都不是开关，而是需要按场景调的旋钮。这里的调整，不是把某个参数推到极端，而是让等待、吞吐和成本达成可接受的平衡。
量化与并行：别只看速度表
降低数值精度、拆分计算、让多张卡协同，听起来都像提速手段。实际落地时，精度损失、通信开销和调度复杂度会一起出现。某些任务对量化不敏感，换来的资源节省很实在；某些长文本场景里，缓存和带宽反而成为瓶颈。并行也不是越多越好，通信等待会吃掉一部分收益。判断一次推理优化是否值得，仍要回到具体请求：它有多长，用户能等多久，失败后能否重试。
边界比参数更难
推理优化常被理解成工程团队的提速工作，但它也在改变产品边界。响应快一点，交互可以自然；成本降一点，免费额度才可能持续；稳定性好一点，高峰时不必靠限流硬扛。反过来，过度压缩也会让回答变得短促、保守，或者在不该省的地方省掉校验。真正难的往往不是把某个指标压下去，而是知道哪些体验不能让步。
所以，当回答慢半秒，先别急着归因于模型能力。把请求路径摊开，看看等待发生在哪，算力花在哪，用户又卡在哪。推理优化不是一次性的调参动作，更像持续维护的工程习惯：在速度、成本和稳定之间，留出可解释的余量。