某个工作日的上午，客服同事把一段三百多字的说明贴进对话框，按下回车。光标闪了两秒，文字才开始一个字一个字往外冒。这两秒里发生的事情，比后面那段漂亮的回答更能决定她下次还会不会打开这个页面。推理优化要处理的，往往就是这两秒。
先分清是在等首字，还是在等结尾
一次生成请求可以粗略拆成两段：模型读入提示词，算出第一个词；然后一个词一个词地往外蹦。前一段吃算力，后一段更吃显存带宽——每生成一个词，都要把权重和缓存重新过一遍，而算出来的只有一个词。所以很多时候，把 GPU 利用率拉满并不会让打字变快，瓶颈在搬运数据，不在计算。
这也解释了为什么批处理是个带刺的工具。把多个请求拼在一起，单位算力的产出明显上升，但排在后面的那位用户，等待时间也跟着变长。吞吐和时延从来不是同一个指标，选哪个取决于产品形态：离线的批任务可以慢慢等，实时对话不行。
缓存与显存：最容易被低估的一笔账
对话越长，KV 缓存越大，显存被一点点吃掉，能同时服务的请求数就往下掉。于是有了各种腾挪办法：把不常用的历史片段挪到低速内存、压缩精度、按需重算。每一种都是在记忆完整性和显存占用之间做交换，没有免费选项。调整的尺度也很难一刀切——短问答为主的场景，和需要反复读长文档的场景，合适的策略差别不小。
量化常被当成省钱的默认手段。权重从高精度压到低精度，显存和带宽压力确实下降，但精度损失在不同任务上表现不一：有的几乎无感，有的会在长输出里慢慢跑偏，前半段正常、后半段开始重复或跳题。上线前拿自己的真实请求做一轮对照，通常比参考通用经验可靠。
投机解码的思路更巧一些：先用一个小模型猜几个词，再让大模型一次性并行校验。猜对了就省下若干次前向计算，猜错了就退回重来。省不省，取决于小模型与你业务文本的贴合程度；它在某个领域里猜得准，换个场景可能就白忙一场，额外开销反而压过了收益。
有些问题它解决不了
见过把时延当成唯一目标的团队，指标压下去了，用户流失却没有改善——因为用户真正在意的是答案对不对、要不要返工重问。也见过为了省算力把上下文砍得太狠的，模型开始忘记前文，返工率往上走，省下的那点资源又被人力补了回去。
所以更实用的顺序是先说清楚在优化什么：首字时延、每秒输出词数、单次请求成本，还是任务的完成率。这几个指标经常互相拉扯，按住一个，另一个就翘起来。把测量做扎实——按真实请求的长度分布和并发形态去压测，而不是只用几百个短提示词跑出一组好看的数字——往往比追新方法更有价值。
还有一层边界值得讲清：推理优化改的是“怎么算”，不改“算得对不对”。模型自身的知识盲区、提示词里的歧义、外部工具调用的失败，都不会因为你把等待从三秒压到一秒而消失。有时候它甚至会掩盖问题：响应快了，用户来不及细看，错误被更快地转发出去。
回到那个闪了两秒的光标。缩短等待当然值得做，但前提是缩短之后给出的东西仍然值得等。这大概是推理优化最朴素的一条底线。