下午三点，客服机器人回复开始变慢；到了夜里，同一套系统又显得轻快。模型没换，问题也没变，变的往往不是“聪明程度”，而是背后排队和计算的方式。这也解释了为什么很多团队谈推理优化时，谈的不是让模型多懂一点，而是让一次回答少等一会儿。
等待从哪里来
一次生成式回答通常要经历两段：先读入问题，再逐个吐出字词。前一段像把材料铺开，后一段像沿着上下文继续写。用户感知到的卡顿，常常出在后一段：每生成一个词，都要重新读取模型参数和历史上下文。显存带宽、并发请求、输出长度，都会把等待放大。推理优化要处理的，就是这些看似琐碎却直接落在体验上的环节。
省下来的不是同一个东西
常见做法里，缓存历史上下文能减少重复计算，尤其适合多轮对话；连续批处理把不同请求拼在一起，让空闲算力少一点浪费；量化则用更低的数值精度换取更小的内存占用和更快的传输。它们各自省下的是不同成本：有的省计算，有的省显存，有的省调度空档。把它们混成一句“加速”，容易忽略代价。
比如批处理提高吞吐，却可能让单个请求多等一点；量化降低资源压力，但输出稳定性需要验证。推理优化的难点不在堆技巧，而在明确当前瓶颈：是首字延迟，还是持续输出速度，是单用户响应，还是高峰并发。瓶颈不同，手段的侧重也不同。
边界比技巧重要
并非所有场景都值得做深度优化。离线摘要、批量标注这类任务，可以接受更长等待，侧重吞吐；实时问答、语音交互则对首字延迟敏感，调度策略要更谨慎。还要留意质量边界：缓存命中后上下文是否仍然一致，量化后长文本是否出现波动，批处理是否让超时请求互相拖累。这些问题不会因为一句“用了推理优化”自动消失。
我的判断是，推理优化更像一项运营工作，而不是一次性的技术开关。它需要持续观察请求分布、输出长度和失败重试，把延迟拆开看，再决定哪些请求走快路径，哪些可以排队。对多数团队来说，先找到那几类真正影响体验的请求，再决定是否全面铺开手段。夜里回答更快，不一定是系统神奇，而可能只是排队的人少了；理解这一点，才知道该优化什么。