晚上十点，客服机器人把“稍等，我正在处理”重复了三遍。屏幕另一端的人未必知道，背后不一定是模型不会答，而是服务在并发上来后开始排队。模型参数没变，体验却变了，这类问题常被归到“推理优化”里。
先把慢在哪里说清楚
训练看吞吐，推理看等待。一次请求从进入服务到返回文本，中间要经过预处理、排队、前向计算、采样和返回。任何一段变长，用户感知到的都是“怎么还没好”。所以推理优化不是单独调一个参数，而是先分清瓶颈：算力不够、显存吃紧、批处理策略不合适，还是请求长度波动太大。不同原因，处理方式并不一样。
常见的做法有批处理、缓存、量化、剪枝、算子融合和并行调度。它们各自解决不同层面的问题。批处理提升设备利用率，但可能增加单请求等待；量化压缩显存占用，却需要关注精度变化；缓存适合重复上下文，不适合每次都不同的输入。把这些手段简单叠加，有时只会让系统更难观测。
吞吐与延迟之间，需要一条可解释的线
做推理优化时，团队容易盯着平均延迟。平均值好看，不代表长尾请求也好看。对交互式产品来说，用户更在意少数慢请求是否可接受。因此，监控要能拆开看：排队时间、首字生成时间、每个 token 的耗时、显存水位和请求长度分布。指标拆细后，优化才有方向，而不是只靠加大机器。
另一个常被忽略的点是请求形态。短问答和长文档摘要对系统的压力完全不同。把不同长度的请求混在一起调度，短请求可能被长请求拖住；简单按长度分桶，又可能让资源利用变得不均衡。这里没有通用答案，只有结合业务流量、模型大小和硬件条件的取舍。
优化之后，别把复杂度藏起来
优化带来的收益通常不是免费的。更激进的量化可能让输出风格变化，更复杂的调度会增加排障成本，缓存命中率高时很省事，命中率下降时却可能放大延迟波动。上线前留好回退路径，记录每次策略调整前后的关键指标，比单纯追求某个数字更实际。
回到开头那个客服场景。用户真正需要的不是“模型正在思考”的提示，而是稳定、可预期的响应。推理优化最终要服务的，也是这种可预期：知道系统在什么条件下会慢，知道慢在哪里，知道下一步该动哪一块。它更像一项持续维护的工程工作，而不是一次性的调参动作。