一个内部知识库问答入口上线，模型答得不错，试点群里却没什么人用。原因很朴素：打完问题，光标闪着，两秒、三秒，人已经切走了。团队第一反应是换个更强的模型，但这三秒大概率不在模型本身。
先把这三秒拆开
一次请求的耗时并不是一整块。请求在队列里等算力、预填充阶段读入整段提示词、逐字生成、结果回传，中间还夹着检索、拼接、过滤和日志。用户感知的是首字延迟，也就是多久看到第一个字；之后才是吐字速度，决定读起来顺不顺。这两件事的优化手段不一样，混在一起谈，很容易做完一轮却不知道收益在哪。
所以动手之前，值得先把时间按环节记一遍。哪一段占大头，就往哪一段使劲。这个动作本身不性感，但省下的返工最多。
批处理是绕不开的取舍
服务端为了不让算力空转，会把多个请求凑成一批处理。批越大，单位时间处理的请求越多，但新来的请求要等这一批凑齐或算完，排队时间随之变长。连续批处理让先完成的请求先走、新的请求补进空位，缓解了这个矛盾，代价是调度更复杂，缓存管理也更琐碎。这里是推理优化中典型的“两头都不能拉满”——吞吐和延迟各自都有天花板，选哪个取决于业务能不能等。
显存是看不见的墙
长上下文和并发数一起涨的时候，缓存会迅速吃掉显存，剩下的空间不够，就只能降并发或截断上下文。量化把权重和缓存压到更低精度，换来显存和带宽上的余量，但精度损失在长上下文、复杂指令下可能被放大，需要在自己的任务上验证，不能只看通用评测。投机解码则是让一个小模型先起草、大模型再校验，输出可预测的场景里能省下不少生成步数；换成开放式写作，草稿被推翻的比例上来，收益就薄了。
被忽略的那半条链路
提示词拼装、检索结果塞入、敏感词过滤、埋点与落盘，这些看起来不怎么“AI”的部分，经常悄悄吃掉可观的时间。它们大多可以并行，也可以缓存，改动往往比调模型参数更直接。很多团队做完推理优化回头看，发现真正拖慢体验的是某个串行调用的外部接口，而不是生成环节。
不是所有场景都值得追极限
离线跑批的报告生成，可以牺牲首字延迟去换吞吐；面向人的对话界面，逻辑正好相反。判断标准其实很朴素：有没有人在等，等多久会走。把这条线画出来，优化目标就不用争论了。
从这个角度看，推理优化更像是在一条链路上做减法，而不是给模型继续加东西。