夜里调试问答助手时，最容易暴露问题的不是回答对不对，而是用户发出问题后，界面先转了两秒圈。产品经理问：模型不是已经跑通了吗？工程师指着监控说，跑通只是开始，真正决定体验的是推理阶段怎么安排计算。
训练像集中备课，推理更像每天上课。每一次请求都要经过输入处理、模型前向计算、输出生成。长上下文、并发请求、输出长度不确定，都会让等待时间变得难以预测。推理优化要处理的，正是这些看起来琐碎、却直接落在用户指尖的延迟。
先分清在省时间还是省资源
很多人把推理优化理解成“让模型算得更快”。这只说对一半。对单次请求，优化可能意味着减少不必要的计算、复用已算过的中间结果，或者把部分低精度计算放到更合适的位置；对整台服务，优化还要考虑同一时间能接多少请求、显存是否够用、峰值过后资源能否及时回收。单次更快，不代表整体更稳；吞吐上去，也可能让个别请求排队更久。
以长对话为例，历史内容会被反复带进计算。缓存中间状态能减少重复工作，但缓存本身也占空间。缓存留得久，命中机会多；留得太久，显存又可能被挤满。类似地，批处理能把零散请求拼在一起提高利用率，可批次越大，先到的人未必先走。这里的取舍没有统一答案，只能回到业务场景：是更在意首字延迟，还是更在意整体成本。
优化不是把参数一调了事
量化、蒸馏、剪枝、投机采样，这些词经常被放在一起讨论。它们各自解决不同问题：有的压缩模型占用，有的减少计算量，有的试图用更轻的方式先猜出结果。真正落地时，任何一项都要重新检查输出质量、稳定性和边界表现。把模型压小后，某些普通问答可能看不出差别，遇到需要细粒度推理或多步约束的任务，问题才会露出来。
所以推理优化更像一套持续校准的工程习惯：先建立能复现的测量方式，分清首字延迟、整段生成时间和并发下的等待；再判断瓶颈在计算、内存还是调度；最后才决定改哪一层。没有测量，优化容易变成凭感觉调参，今天快一点，明天在另一个场景慢回去。
把边界留在设计里
还有一种常见误会，是把所有请求都送往同一个大模型。实际系统里，简单分类、固定格式提取、常见问题，未必需要最重的计算路径。把请求分层处理，或者在合适的时候复用结果，往往比一味追求单模型极限更有效。但分层也会带来维护复杂度，缓存也可能让旧答案显得过时。推理优化的价值不在于把指标推到某个数字，而在于让系统在可解释的边界内稳定工作。
回到那个转圈的界面。用户感知不到缓存命中率，也不会关心批次大小，只会记住这次等待是否值得。推理优化最终要回答的，不是“还能不能再快一点”，而是“在当前质量要求下，哪些等待可以省掉，哪些保障不能省”。这个判断，往往比调参更花时间。