值班群里跳出一条告警：某个生成接口的 P99 延迟在半小时内抬升，GPU 利用率却没有跟着涨。有人提议先加两张卡。这个反应不难理解，扩容路径短，审批也熟。但在按下扩容之前，值得先问一句：请求到底长什么样？
算得慢，还是等得久
大模型推理的耗时并不只发生在模型前向计算。请求进入服务后，要排队、做预处理、组装 batch、执行计算，再经过后处理和流式返回。任何一段出现堆积，端到端延迟都会变差。GPU 利用率不低，可能是在算；利用率不高，也可能是在等。把链路拆开看，才能判断瓶颈在计算、内存带宽，还是调度排队。
这也是推理优化常被误解的地方。它不像换一个算子那样有明确的开关，更像在吞吐、延迟、显存和精度之间做取舍。批处理能抬高吞吐，但请求等待拼批的时间会进入延迟；KV 缓存能减少重复计算，却要占用显存；量化能压低计算和带宽压力，也可能带来精度波动。每项手段都有适用条件，离开请求形态谈优化，容易变成凭经验押注。
先看请求，再看手段
一个朴素的起点是采样。把线上真实请求的长度分布、并发曲线、超时比例和返回方式拉出来，看看长请求和短请求是否混在一起，流式与非流式是否共用同一条路径。很多延迟问题不是模型算不动，而是长短请求互相拖累：长请求占着批次，短请求排队；或者缓存命中率被少数前缀打散，重复计算反复发生。
在这个基础上，可以落到具体动作：按请求类型分流，给长请求单独设队列；对共用前缀做缓存复用；对离线任务放宽延迟目标，把峰值让给在线请求；在精度允许的范围内尝试量化，但保留回退路径。这些动作不炫目，却接近系统工程。它们需要监控支撑，也需要提前约定指标，否则优化容易变成局部调参。
代价要一起算
优化不是免费的。量化可能影响输出稳定性，缓存会带来一致性和失效问题，批处理会改变尾延迟的形态，分流则增加运维复杂度。一个在压测里表现平稳的方案，到了真实流量里可能因为请求分布变化而失去效果。所以，做推理优化时，除了看吞吐和平均延迟，也要看尾延迟、错误率和回退成本。保留回退路径，意味着还有调整空间。
回到那条告警。团队后来没有立刻加卡，而是先把长请求挪到单独队列，又给高频前缀加了缓存。延迟曲线回落，但这不是终点。流量结构会变，模型会换，硬件也会换。推理优化是一项持续治理工作：先承认瓶颈会转移，再保留观察和调整的余地。下一次告警响起，先看请求，还是先看卡？这个问题本身，就值得留在值班手册里。