晚上十一点，有人对着输入框敲下一段问题，按下回车，光标闪了三四秒才开始吐字。多数人把这个瞬间归因于「模型不够快」，但在工程侧，它往往是另一件事：一次请求在算力、显存和调度之间被反复安排的过程。
等待其实有两种
体感上的慢可以拆成两段。一段是从提交到第一个字出现，另一段是字与字之间的间隔。前者受排队和预填充影响，后者与逐 token 解码的成本相关。这两段经常不能同时压得很低——把大量请求攒在一起处理，吞吐上去了，单个用户在队列里等待的时间可能反而变长。
这也是推理优化最先要面对的现实：它很少是一条可以一路向下的曲线，更像在几条约束之间找位置。
几处常见的着力点
- 缓存已经算过的东西。自回归生成里，前文的键值状态可以缓存下来复用，避免每次从头计算。上下文越长，这块缓存占的显存越多，怎么分配、何时回收，直接影响能同时接多少请求。
- 减少每个数字的位宽。把权重或激活压到更低精度，能省显存、提高带宽利用率，但要确认精度损失是否落在可接受范围内，通常需要实际评测，而不是凭直觉判断。
- 一次处理多个请求。批处理提升硬件利用率，代价是调度复杂度上升，长短请求混在一起时容易互相拖累。
- 猜测式解码。用较小的模型先草拟若干 token，再由大模型校验，命中时能省下若干步解码。收益高度依赖任务类型，草稿质量差时反而增加开销。
有些瓶颈不在算法里
推理优化经常被理解成调模型，但实际卡住的地方常常是显存带宽、算子实现，甚至请求的到达方式。解码阶段每生成一个 token 都要把权重读一遍，带宽吃紧时，换更聪明的调度也收效有限。同理，如果输入长度分布极不均匀，任何固定的批处理策略都会在某些时刻浪费资源。
所以更稳妥的顺序是先观测：首字延迟、token 间隔、显存峰值、队列长度，这些数字比「感觉快了」更能指向问题。没有测量就改参数，多半只是把瓶颈从一个位置挪到另一个位置。
不是所有场景都值得优化
如果一次调用背后是批量离线任务，用户并不盯着屏幕，那吞吐和成本更值得关心，个别请求慢一点无所谓。反过来，交互式产品里，把首字延迟压下去带来的体验改善，往往比整体吞吐提升更容易被感知。判断标准应该来自使用方式，而不是某个通用配置。
还有一种情况值得留出余地：流量有峰谷。为峰值准备的容量在低谷时闲置，为均值准备的容量在峰值时排队。这种时候，弹性调度和降级策略的作用可能大过一次精细的推理优化——后者决定跑得多快，前者决定忙的时候还能不能跑。
回到那个闪着的输入框。用户不会关心背后用了哪种批处理策略，只知道答案来得是否顺畅。工程侧能做的，是把「慢」拆成可以分别对待的几段，在每一段上做出明确的取舍，并且清楚这个取舍是为了谁。