一个问答接口在测试环境响应很快，接入真实流量后却频繁转圈。排查下来，模型本身没有变化，问题出在每次请求都从头计算，并发一上来，排队时间被迅速放大。这类问题在模型训练阶段很少暴露，却在上线后成为体验的分水岭。也正是在这个阶段，推理优化才从工程细节变成产品问题。
训练关注的是让模型收敛，推理关注的是让同样的计算少浪费。两者目标不同，手段也不能直接套用。推理优化不改变模型“会不会”，它改变的是“多快、多贵、多稳定地把结果交出来”。
先看瓶颈，再谈手段
常见的推理优化围绕几件事展开：批处理把多个请求合并计算，提升硬件利用率，但单请求等待时间会变长；缓存复用相似请求的中间结果，命中率却高度依赖场景；量化、蒸馏一类方法降低计算精度或模型规模，换来更低的资源占用，同时对数值敏感的任务需要单独验证。调度策略则决定请求落到哪块硬件、什么时候执行，避免算力空转。
这些手段没有通用配方。一个离线批处理任务可以接受几秒延迟，优化重点在吞吐；一个实时对话接口对首字延迟敏感，批处理窗口就不能开得太大。把别人的参数直接搬过来，往往解决不了自己的问题。先量清楚瓶颈在计算、在内存、还是在排队，再决定动不动，这一步比选工具更重要。
被忽略的取舍
推理优化常被当成后期补丁：模型先上线，慢了再优化。更合理的做法是把延迟目标、成本上限和可接受的准确率变化，在产品定义阶段就写清楚。否则优化容易变成无底洞——为了压几毫秒，引入复杂链路，维护成本反而上升。
另一个取舍在于精度。量化能减少显存占用，但不是所有任务都能承受数值误差。有些生成任务对细微变化不敏感，有些结构化输出却可能因此出错。是否采用，需要用小流量对照验证，而不是只看平均指标。缓存也一样，命中率高时收益明显，命中率低时只是多了一层查询开销。
还有一个现实边界：不是所有业务都值得做深度推理优化。低频内部工具，用户对几秒等待并不敏感，投入产出比有限；高并发实时场景，推理优化则直接关系到服务能不能撑住。判断标准应该来自业务指标，而不是技术潮流。
把它当成持续动作
模型版本会更新，流量结构会变化，硬件环境也会调整。一次调整做完，不代表可以长期不动。更稳妥的方式是保留可观测的延迟、错误率和资源占用指标，在版本迭代时重新确认瓶颈是否转移。这类工作不是一次性项目，而是上线后的持续维护动作。
回到开头那个转圈的接口，真正有效的第一步不是立刻上量化或换硬件，而是把请求链路拆开，看清时间花在哪里。很多团队在这一步就会发现，问题可能只是某个同步调用堵住了并发。先定位，再优化，比堆方案更接近问题的答案。