有时，同一个问答入口，白天几秒就出结果，夜里却要等到进度条走完。排查时先看模型，再看机器，最后发现请求并没有变多，变的是上下文长度和并发形态。这类现场问题，往往把“推理优化”从论文词拉回到工程桌面：不是让模型更聪明，而是让同样的模型在真实请求下稳定、省资源、可解释地跑完。
先弄清楚在等什么
用户感知到的是首字延迟和完成时间，系统内部却由预填充、解码、调度、网络回传几段拼成。长上下文会把预填充推高，输出越长，逐 token 解码越难压缩；并发一上来，显存和带宽又成了看不见的墙。平均延迟容易掩盖尾延迟，而用户往往正好撞上后者。做推理优化时，先问清楚瓶颈在哪一段，再决定是否换框架。
手段各有代价
批处理能摊薄单位请求的调度开销，但批次变大也可能抬高排队时间；KV 缓存减少重复计算，却会占用显存，长会话下尤其明显；量化与蒸馏降低资源占用，但可能改变输出风格和边界表现；投机解码用较小模型试探、再由目标模型校验，适合部分生成场景，并不是所有任务都能受益。把这些手段当成一组旋钮，按场景逐项验证，别急着一次全开。
- 先设定可观测目标：首字延迟、尾延迟、吞吐、单位请求成本，至少盯住两个。
- 把缓存、批处理、模型压缩分开验证，避免一次改太多变量。
- 保留回退路径，线上出现异常时能快速切回稳定配置。
边界条件也值得记录
推理优化需要克制。上下文缓存命中率低时，缓存层可能只增加复杂度；请求稀疏时，复杂调度未必划算；输出质量要求高的场景，压缩带来的细微漂移需要被评估。一个可用的做法，是把每次优化和它对应的业务指标绑在一起，记录适用条件与失效条件。这样下一次遇到类似问题，团队不必从零猜起。
回到那个进度条，真正要修的也许不是某个单点技巧，而是对请求形态的理解。推理优化做到后面，更像是在延迟、吞吐、成本和输出稳定性之间做可复述的取舍。能说清楚为什么这样改、在什么情况下不成立，才算把优化做扎实。