晚上八点，同一个接口，前端进度条走到第三秒用户还没看到第一个字，群里已经有人问“是不是挂了”。而上午十点，同样的提问，答案几乎立刻开始滚动。模型没换，参数没动，变化的是排队的人和机器被使用的方式。这类落差，往往不是模型能力问题，而是推理优化要处理的现场。
延迟其实是两段拼起来的
一次生成大致分两段。前半段是预填充，模型要把你贴进去的整段上下文读一遍，算出缓存；后半段是解码，一个词一个词往外吐。前者吃算力，后者更吃显存带宽——每吐一个词，权重和缓存都要重新搬一遍。很多人只盯着“每秒多少字”，却忽略首字延迟。对交互式产品来说，用户感知最强烈的恰恰是按下回车到第一个字出现的那段时间。
这也解释了一个常见误会：显存够大，不等于跑得快。大模型推理的瓶颈常常不在算力峰值，而在数据搬运。
通常能动手的几处
- 连续批处理：不再等一整批请求凑齐才开工，谁先完成谁先走，新请求随时插进来。它对吞吐的改善明显，但调度没做好，尾部延迟会变难看。
- KV 缓存管理：上下文越长，缓存越占地方。分页式管理、按需回收，能减少显存碎片，也决定了长对话能撑多久。
- 量化：把权重和激活压到更低精度，换更小的搬运量和更低的显存占用。代价是分布被扰动，某些任务上会出现细微退化，需要自己评测，不能照搬别人的结论。
- 投机解码：用一个小模型先猜几个词，大模型批量校验。猜得准时快，猜不准时反而多做功，收益高度依赖任务类型。
- 前缀缓存：系统提示词、固定知识库这类重复前缀，算一次就够了。多轮对话和客服场景里，这一项常常比重写算子更划算。
优化不是免费的
上面每一条都在做交换。批得越大，单位成本越低，但排队时间变长；量化压得越狠，显存越宽松，但输出稳定性越难保证；缓存留得越久，命中率越高，但内存被长期占着。所谓推理优化，本质上是在延迟、吞吐、成本、质量之间找一个当下业务能接受的点，而不是把某个指标推到极限。
还有一个容易被忽略的代价：复杂度。组件堆得太多之后，线上出问题很难定位——是调度策略变了，是某个缓存没失效，还是那次量化把边界情况弄坏了。系统越“聪明”，排查越像猜谜。
先量，再改
比较稳妥的做法是先分清指标：首字延迟、每字间隔、整段完成时间、单位时间能服务多少请求，这几个数反映的事情完全不同。没有分场景的观测，调参很容易变成凭感觉。把真实流量的上下文长度分布、并发曲线拉出来看，往往会发现瓶颈和最初设想的位置不一样。
我更倾向于把推理优化看成一件长期的基础设施工作，而不是一次性的性能冲刺。模型会换，业务会长，流量峰值会挪位置，今天有效的配置过几个月可能就失效。真正留下来的，是那套能说明白“慢在哪”的度量方式，以及愿意为每次改动留出验证时间的习惯。