一个聊天窗口里，用户按下回车，进度条转了半秒。对产品经理来说，这是体验问题；对工程团队来说，这可能是一次推理请求在排队、分配显存、读取缓存、逐词生成。很多团队一提到推理优化，会先想到换模型或压缩参数，但真正影响体感的，往往是链路上更拥挤的一段。
先要分清两个指标：首字延迟和每字耗时。前者决定用户多久看到第一段回答，后者决定整段答案要等多久。两者并不总是同向变化。把请求攒成更大的批次，可能提高吞吐量，却让单个请求多等一会儿；把模型量化得更轻，可能降低单次计算压力，却需要在效果和稳定性上重新评估。讨论这类取舍时，如果只盯一个数字，很容易把问题从一处推到另一处。
缓存省下的是重复劳动
多轮对话里，系统提示和历史上下文经常重复。KV 缓存、前缀缓存一类手段，思路是别让相同内容每次重算。它们有用，但有边界：缓存命中率低时，收益会被管理开销吃掉；上下文变化频繁时，缓存也可能变成负担。工程上更值得问的是，哪些请求真的重复，缓存失效的策略是否足够简单，监控能不能看出命中与未命中的差别。
批处理也是类似。它把多个请求放在一起算，提升设备利用率，但排队本身会引入等待。交互式场景里，一味追求大批次会让用户觉得“卡”；离线任务里，延迟容忍度高，批处理才更容易发挥作用。难点不在于知道这些手段，而在于知道什么时候不该用。
先让瓶颈可见
没有观测，优化容易变成猜谜。至少要把请求排队时间、首字延迟、生成速度、缓存命中情况、显存占用和错误率放在同一张视图里看。否则，模型侧看似变快了，端到端体验却可能被网络、鉴权或后处理拖慢。推理优化不是一次性的参数调整，更像持续排查：先找到等待发生在哪，再决定是改调度、改缓存，还是改模型结构。
边界比技巧更重要
还要接受一个现实：优化有成本。更复杂的调度会增加维护难度，更激进的压缩可能牺牲稳定性，更多缓存会占用内存。对业务来说，合适的目标不是把每个指标推到极限，而是让体验、成本和可维护性处在可解释的范围内。当回答开始变慢，先别急着换模型；把请求路径拆开看，推理优化往往从那个被忽略的等待点开始。