用户点击发送，界面转圈。日志里模型计算耗时并不突出，端到端却让人等得明显。团队常先想到换模型、加机器，但线上链路里，推理优化往往不是算力不够，而是数据搬运和调度让计算单元空等。模型等内存，请求等队列，等待被拆散在很多环节。
先判断等待发生在哪
推理优化要回答一个问题：时间花在哪。把一次请求拆成排队、预处理、权重读取、缓存读写、后处理，逐段看延迟分布，能帮助判断瓶颈位置，而不是只盯总耗时。工具不必复杂，先看资源利用率和请求延迟是否同步变化：计算单元忙而吞吐不动，可能是批处理策略不合适；内存带宽先饱和，继续加机器未必能解决。
- 排队时间是否占据主要部分，还是计算本身在拖长尾；
- 批大小变化时，延迟和吞吐是否一起出现异常；
- 缓存命中率是否稳定，失效时会不会引发抖动；
- 平均延迟是否掩盖了少量长请求的等待。
吞吐和延迟不是同一道题
线上系统经常在吞吐和延迟之间做取舍。离线批量任务可以堆批处理，在线对话则要顾及首字返回和交互节奏。推理优化要按场景拆目标，不能用一个指标覆盖所有请求。把长短请求混在一起，容易让短请求陪跑。按路径分流，给不同请求不同队列和缓存策略，往往能减少互相干扰。
缓存省下的，要看命中
KV缓存、提示词缓存能减少重复计算，但缓存本身占内存，也会引入查找和失效成本。命中率低时，缓存可能只是把计算压力换成内存压力。推理优化在这里要做的是算清收益边界：哪些请求会重复，缓存保留多久，失效后是否引发抖动。没有命中率支撑的缓存，容易变成另一个等待点。
给优化留出回退空间
这类调优不是一次性调参。流量结构会变，模型版本会变，硬件也会变。上线前保留可回退配置，记录每次变更对应的延迟分布和错误率，才方便判断问题来自模型、调度还是基础设施。小步验证，便于定位代价来源；一次性大改，问题出现时很难分清哪一步带来副作用。
这类工作听起来不激动，却决定服务在忙时是否还稳。把等待拆开、把收益边界写清、把回退路径留好，追逐某个漂亮指标，未必能换来稳定服务。