产品经理说响应慢，财务说这个月账单翻倍，两边指的其实是同一套权重。模型没换，参数没动，变的是请求的形状：高峰时段的并发、上下文长度、输出长度的分布。这类问题很难靠换一张卡解决，它更接近系统工程，也就是人们常说的推理优化。
先分清两段耗时
一次生成大致分两段。prefill 把整段提示词读进去，算力密集、可以并行；decode 一个 token 一个 token 往外吐，显存带宽密集、并行度低。前者随输入长度增长，后者随输出长度增长，而且每一步都要把全部权重过一遍。很多“慢”的抱怨，其实是输出太长而不是输入太大；很多“贵”的账单，反过来是输入里塞了太多检索内容。
分不清这两段，调整就容易打偏。把输入压缩一半，对 decode 几乎没有帮助；把输出砍短，对 prefill 也无关。
批处理不是免费午餐
连续批处理是被讨论得比较多的一种手段：不等一整批做完，谁结束谁让位，新请求立刻补进来，把加速卡的空转时间填满。吞吐确实能上去，代价是尾延迟——一个请求可能被后来者挤在后面，长尾请求的等待时间会变得难看。
所以真正要回答的不是“要不要开批处理”，而是“这个接口能不能忍受两秒的抖动”。面向人的对话界面和面向系统的批量任务，答案并不一样。
KV cache 与量化的两面
KV cache 用显存换计算，避免每一步重算历史。它让长对话成为可能，也让长对话变贵：上下文越长，缓存越大，能同时容纳的并发越少。这也是为什么一些服务会对超长上下文单独计费。
量化把权重和激活压到更低精度，省显存也省带宽。它不是无损的，误差在需要多步推理的任务上会累积。宽松场景可以接受，对数值敏感的输出要谨慎，稳妥的做法是先跑小流量验证再放量。
投机解码：赌的是接受率
用一个小草稿模型先猜若干 token，再由目标模型一次性验证。猜对得多，收益就大；猜错就白算一遍。它的效果高度依赖任务的可预测性，代码补全、模板化文本通常比开放式写作更容易命中。部署上多一个模型，也多一份显存占用和调度复杂度，这笔账要一起算进去。
先量，再改
推理优化的顺序常被搞反。看到别人说某个手段有效就先上，测出来却没变化，因为瓶颈根本不在这里。更稳的做法是先回答三个问题：延迟预算是多少，流量形状是什么样，成本主要落在哪一段。三个答案不同，该动手的地方就完全不同。
有件事值得强调：多数团队缺的不是技巧，而是对自己流量的了解。日志里有没有记录输入输出长度分布，有没有按接口拆分延迟，决定了后续所有调整是有据可依还是碰运气。
另外说一句判断。推理优化不是一次性任务，更像一种持续观察系统的习惯：模型会升级，流量会变形，上个月有效的配置这个月可能就不合适。把它放进发布流程当常规动作，比当成一次攻坚更实际。