有一段时间，我在一个内部工具上反复遇到同一幕：模型没有换，接口也没有加新功能，但用户开始抱怨“点了半天没反应”。产品同事的第一反应是模型太大，要不要换个小一点的。这个问题问得不算错，但它跳过了中间最重要的一步：先弄清楚时间花在哪里。
大模型的一次请求，通常被切成两段。前半段叫预填充，模型要把输入的整段提示读完，算出内部状态；这部分计算密集，但可以并行，提示越长越明显。后半段是逐 token 解码，一个字一个字往外吐，每一步都要把权重从显存搬到计算单元，受带宽限制。两段的瓶颈不一样，能用的手段也不一样。把“加速”当成一个笼统目标，往往会在错误的那一段上使劲。
批处理能提升吞吐，代价写在延迟里
把多个请求拼成一批送进去，是提高吞吐的常规做法。问题在于，后到的请求要先在队列里等，这段等待会计入用户感知的响应时间。连续批处理把排队摊薄了一些，可它并没有取消等待窗口。所以线上指标最好分开看：单位时间处理多少请求，和单个请求多久返回，是两个方向，混在一个数字里讨论，容易得出互相矛盾的结论。
几处常被忽略的细节
- KV 缓存的体积随上下文长度增长，长对话场景下它占的显存可能超过模型权重，缓存管理策略本身就是一个优化点。
- 量化省的主要是显存带宽和存储，但不同任务对精度损失的敏感程度并不均匀，压到哪一档需要在自家数据上验证。
- 投机解码用一个小模型先草拟若干 token，再由大模型并行校验，实际收益高度依赖草稿的接受率；接受率低的时候，多出来的计算反而成了负担。
- 前缀缓存对固定系统提示、固定工具描述这类重复内容有效，对每次都不同的长输入几乎不起作用。
它本质是一道取舍题
把上面这些放到一起看，推理优化并不存在一条通用路径，它更像是在延迟、吞吐、成本与输出质量之间画一条符合业务的曲线。面向人的对话产品，首字延迟和吐字流畅度决定了体感；跑在后台的批处理任务，单位成本才是关键；而对准确性要求高的场景，任何会引入近似的手段都要谨慎。同一种方法，放在不同场景里结论可能相反，这也是为什么别人的配置单很难直接照搬。
也有不该动模型的时候
我见过一些“慢”的情况，最后查下来跟模型关系不大：检索环节串行调用了几次外部服务，工具调用来回往返，前端渲染阻塞了首屏。这时候去做推理优化，投入不小，收益却落在别处。合理的顺序是先埋点、先测量，把端到端的时间切成几块，看哪一块最厚，再决定要不要动模型那一层。
回过头看开头那个工具，真正起作用的改动并不复杂：把系统提示固定下来做前缀复用，给解码阶段设一个合理的批处理等待窗口，长上下文请求单独走一条路径。模型还是原来那个。推理优化有时候就是这样，它不负责让模型变聪明，只负责让已有的能力被更完整地用上。而在此之前，先知道自己慢在哪里，比急着换方案要紧。