先是响应变慢，然后才想起它
值班的人最先察觉的往往不是错误率，而是等待。同一份模型权重，同一批机器，上周还在一秒出头返回，这周就要多等半秒。日志里没有异常，GPU 利用率看着也不低。这时候才会有人提一句：是不是该做一轮推理优化了。
这类问题很少由模型变差引起。更多时候，是流量结构变了——上下文变长、并发分布变陡、某个上游开始重复发送相同的系统提示词。推理优化之所以难，不在于手段少，而在于你得先判断问题出在哪一段。
延迟和吞吐，往往不能一起要
把推理拆开看，是两个阶段。prefill 处理输入，把整段上下文一次性算完，计算密集；decode 逐个 token 生成，每步只算一个位置，却要把权重和缓存从显存里搬一遍，属于访存密集。用户感知的“慢”，可能卡在 prefill 的长输入上，也可能卡在 decode 的排队上，两者的解法完全不同。
这也解释了为什么增加显卡不一定变快。如果瓶颈是单请求的访存带宽，让更多设备同时运行只会让排队更整齐，不会让单个请求更早结束。
再往上一层，是延迟与吞吐的取舍。批处理能提高设备利用率，提高单位时间产出，代价是每个请求要等同伴凑齐；连续批处理让新请求在旧请求生成中途插入，缓解了这个矛盾，但没有消除它。
几件真正省事的事
- 前缀缓存。系统提示词、few-shot 示例、固定的文档片段，在很多业务里是重复的。把这部分 KV 缓存复用起来，等于每次请求少算一大段。
- KV cache 的量化与分页管理。长上下文下，缓存本身就占用大量显存；把它压到更低精度、按页分配，能明显改变可承载的并发量。
- 投机解码。用一个小模型先草拟若干 token，再由大模型批量校验，适合输出可预测性高的场景；草拟命中率低时，收益会迅速消失。
- 算子融合与图编译。属于底层优化，收益稳定，但需要跟随框架版本更新，升级时容易回退。
- 路由与降级。简单请求交给小模型，复杂的再往上分流。这不完全是模型侧手段，却常常见效明显。
代价藏在看不见的地方
量化省的是显存和带宽，付出的可能是长尾质量——平均值几乎不变，少数难题会悄悄变差，而这类退化在常规抽检里不容易被抓到。批处理提升吞吐，换来的是尾延迟变长，对交互式产品尤其敏感。缓存复用省了计算，却带来失效问题：提示词改了一个字，缓存还算不算数？
所以优化做到后期，要问的往往从“还能快多少”变成“哪些慢可以接受”。工程上更需要的是可观测性：把 prefill 时长、decode 步速、排队等待、缓存命中率分开看，而不是只盯一个平均值。
它不是一次性的项目
很多团队把推理优化当成上线前的一道工序，做完就归档。但流量会变，上下文会变长，业务方会加新的提示词模板，框架会升级。上个月有效的参数，这个月可能正好卡在临界点上。
更实际的姿态是把它当成一项常态工作：留出可以快速切换的配置，保留一套贴近线上分布的评测输入，改动前后都能对比。做到这一步，这类工作才不至于变成一次性的“调参表演”。下次响应再变慢时，先问一句——是 prefill 变长了，还是 decode 在排队。