压测时，监控面板上常被盯住的是平均延迟。可只要把时间轴拉长，就会发现曲线并不平滑：有的请求很快，有的却卡在某个看不见的等待上。推理优化之所以难，往往不是模型不会算，而是算之前和算之后，数据在内存与计算单元之间来回搬运。
先分清“算得慢”和“等得久”
大模型推理可以粗略拆成两段：预填充阶段处理输入，解码阶段逐 token 生成。前者更像一次较大的矩阵计算，后者则要反复读取权重和缓存。很多场景里，解码阶段的瓶颈不在算力峰值，而在内存带宽和缓存访问。也就是说，模型不是一直在算，它有时在等数据。
这解释了一个常见现象：单条请求的延迟看起来尚可，并发一上来，吞吐和尾延迟就一起变形。若只盯着单次调用调参，容易把问题简化成换更快的卡或减模型层数；但真正的成本可能来自批次组织、缓存管理和请求排队。
批处理不是越大越好
把多个请求拼成一批，能提高计算单元的利用率，这是推理优化的常见手段。可批次变大后，单个请求的等待时间也会变长，首 token 延迟和尾延迟可能被拉高。对交互式应用来说，用户感知的是“多久开始出字”，而不是整批任务的平均完成时间。
更现实的做法是把预填充和解码分开看：预填充更吃计算，适合合并处理；解码更吃内存访问，批次过大未必划算。连续批处理、分页缓存这类思路，都在处理同一个矛盾——怎样让不同长度的请求共享计算，又不让短请求陪跑太久。
量化、缓存与投机解码的边界
量化能降低权重和激活的存储开销，缓存能减少重复计算，投机解码则试图用更小的模型先猜几个 token，再由大模型验证。它们都试图缓解这类压力，但各有边界。量化过度可能影响输出稳定性；缓存命中率依赖于请求之间的相似度；投机解码的收益则取决于猜测被接受的比例。把这些手段当成万能开关，往往会得到相反的效果。
所以，推理优化更像一场对瓶颈的持续定位，而不是一张固定的配置清单。先确认延迟花在哪里，再决定是否合并请求、压缩精度、调整缓存策略，顺序反了，努力就容易落在不痛的地方。
- 先看尾延迟和首 token 延迟，不只看平均值。
- 把预填充与解码分开评估，避免用一种策略覆盖两种负载。
- 任何压缩或缓存手段，都要回到输出质量和命中率上验证。
回到开头那条不平滑的曲线：它提醒我们，推理系统的性能不是一个单点数字，而是计算、内存、调度和用户体验之间的拉扯。这类工作的价值，也许就在于把这些拉扯看清楚，然后接受某些取舍，而不是假装所有指标都能同时变好。