先看一个很常见的场景：接口文档上写着平均响应三百毫秒，上线后用户却抱怨“点了没反应”。排查一圈，模型没换，机器没扩容，日志里的平均值也很漂亮。问题往往出在请求的形状上——有人一次只发一句话，有人一次贴进整篇文档；有人问完就等，有人连续追问上下文越滚越长。平均值把这些差异抹平了，而用户体验由那条最慢的长尾决定。
这也是推理优化最容易被误解的地方：它常被当成一次“换更快的引擎”，实际上更像重新安排一条流水线的节拍。
先把时间花在哪里搞清楚
一次大模型推理的耗时，大致可以分成几段：请求排队、输入预处理、模型前向计算、逐字输出。前几段相对固定，最后一段却会随输出长度线性拉长。如果业务让模型写一段长文字，那么绝大部分时间都耗在“一个词一个词往外吐”上，此时去优化算子或换更快的显卡，收益可能远不如让用户先看到前两行。
另一些业务恰好相反，输入极长、输出极短，需要处理的就变成了长上下文的注意力计算与显存搬运。两种情况都叫慢，解法却几乎不重叠。所以讨论推理优化之前，值得先问三个朴素的问题：请求的输入输出比是多少？并发是平稳的还是成批涌来的？用户能接受的是首字延迟，还是整段完成时间？
这三个问题答不上来，任何优化都可能变成盲调。
几种手段各自在换什么
业界常用的做法，本质上都是在几种资源之间做交换。
- 批处理：把多个请求攒在一起算，提高硬件利用率，代价是排队时间变长，尾部延迟可能变难看。
- 缓存复用：把重复的前缀或历史上下文存下来，省掉重复计算，适合固定系统提示词、多轮对话这类结构稳定的场景；请求越多样，命中率越难保证。
- 量化与更轻的精度：用更少的位数表示权重和中间结果，降低显存占用与带宽压力，但要接受精度上的取舍，需要在自己的任务上验证。
- 投机解码一类的方法：用小模型先起草、大模型再校验，把串行的输出变快，效果依赖草稿的命中情况，并非稳定增益。
- 流式输出与分段返回：不减少总计算量，但改变用户感知，让首字更早出现。严格说这更像交互设计，却常常是投入产出最直接的一项。
把这张清单摆出来会发现，没有哪一项是普适的。批处理伤害实时性，缓存依赖重复度，量化要过质量关。所谓推理优化，很多时候是在明确业务底线之后，选一个愿意承受的损失。
边界比技巧更值得写进文档
一个容易被忽略的事实是：优化会改变系统的性格。原本单请求、低并发的服务，加了批处理之后，峰值时段的响应时间波动会明显变大；原本精度敏感的任务，做了量化之后，多数样本看起来没问题，少数边界输入却可能悄悄退化。这些变化不会在压测的平均值里显形，只会在真实流量里慢慢累积成投诉。
因此我更倾向于把推理优化看作一项需要持续观测的工程习惯，而不是一次性的调参动作。至少要把首字延迟、完成时间、单位请求成本分开记录，按请求长度和并发区间分层看，而不是只盯一个总数。只有当这些指标能被稳定地拆开，讨论才有意义。
还有一点需要克制：模型供应商在持续更新，硬件与推理框架也在变，今天有效的组合过几个月可能需要重测。把优化结论写成“某配置更优”是一种危险的简化，写成“在什么样的请求分布下、用什么代价换来了什么”，才更接近可复用的经验。
回到开头那个三百毫秒的故事。真正解决问题的，往往不是某个新工具，而是有人终于把请求按长短分了桶，承认平均值骗了人。推理优化做到最后，拼的常常是这种愿意把账单摊开看的耐心。