很多人第一次接触推理优化，是从一张延迟曲线开始的。模型没换，机器没换，只是把请求攒一攒再发，曲线就平滑了不少。于是团队得出结论：优化空间很大。可等到线上流量真的上来，曲线又变得难看。问题往往不在某个算子写得不够快，而在于对“推理”这件事的理解偏窄。
先把请求看清楚，再谈优化
推理服务不是一条流水线上的固定工序。请求有长有短，有的一进来就要结果，有的可以等上几秒；有的输入很短但输出很长，有的反过来。把这些差异抹平，用同一套参数去服务所有请求，本身就是一种浪费。推理优化的第一步，常常是把请求分门别类，而不是急着换框架。
比如首字延迟和整体吞吐，目标就不一样。前者关心用户看到第一个字有多快，后者关心单位时间能处理多少请求。把两者混在一个指标里讨论，优化方向容易左右摇摆。实际做法通常是给不同场景设不同队列，或者在同一服务里划出快慢通道。这类调整听起来不“技术”，却经常比换一个更快的算子更有效。
批处理的甜点区在移动
批处理是推理优化里被说得最多的手段之一。把多个请求合并成一批，能更充分地利用硬件。但批大小不是越大越好。批越大，单次计算更划算，排队等待的时间也越长；批越小，响应更及时，硬件却可能吃不饱。这个平衡点会随流量、输入长度分布和硬件状态变化，不是一个可以一次调好的常数。
更实际的问题是，很多线上服务并不知道下一秒会来多少请求。静态设定的批大小，在低谷期显得浪费，在高峰期又可能造成堆积。于是连续批处理之类的思路被引入：不等一批凑满，而是边走边加。它的代价是调度更复杂，状态管理更麻烦。是否值得，要看业务能不能接受额外的工程复杂度，而不是看它是否流行。
缓存能省下的，和它省不下的
缓存常被当作推理优化的捷径。相同的提示词、相同的上下文，重复计算确实可惜，复用中间结果可以省下可观的开销。但缓存命中率取决于请求的重复程度。面向开放用户的对话场景，重复往往没有想象中高；而一些固定模板、固定知识库的调用，重复率可能很高。先测命中率，再决定投入，比先建缓存再找场景要稳妥。
缓存还带来一致性问题。中间结果被复用，意味着计算路径被跳过，一旦上下文有细微差别，结果可能偏离预期。工程上通常要靠严格的键设计和失效策略来控制，这部分工作量经常被低估。
调度是容易被忽略的一层
当多个模型共享同一批机器时，调度决定了谁先算、谁等待、谁被挤出去。推理优化如果只盯着单个模型的执行效率，可能会在整体上留下空洞。比如一个长请求占住资源，后面一堆短请求只能排队；或者某张卡忙得转不过来，另一张卡却闲着。这些问题不是靠改模型结构能解决的。
调度层面的取舍很直白：是优先保证公平，还是优先保证整体吞吐；是允许抢占，还是让请求跑完。每种选择都会影响用户体验和资源利用率，没有统一答案。能把这些问题摆到台面上讨论的团队，通常比只谈算子的团队走得更远。
优化的边界在哪里
推理优化有明确的上限。模型本身的规模、硬件的算力、网络往返的时间，都不是靠调参能突破的。更重要的是，优化往往在交换：用延迟换吞吐，用内存换速度，用复杂度换稳定性。承认这些交换的存在，比宣称某项技术能“全面提升”更接近真实。
所以看待推理优化，不妨先问几个具体问题：当前瓶颈在计算、在排队，还是在数据传输？请求的分布是否稳定？能接受多复杂的调度逻辑？回答完这些，再决定动哪里。很多时候，最有效的改动并不显眼，只是把请求分对了类，或者把批大小从固定值改成了随流量调整。
推理优化不是一个可以一次性完成的项目，它更像一段持续的对账过程：每隔一段时间，重新看看流量形态、硬件状态和业务目标是否还匹配。技术会更新，但这份对账的习惯，才是让服务保持稳定的东西。