客服机器人回一句话要等两秒。工程师查了显卡利用率，没满；查了模型，也没坏。慢的地方在队列里——请求排着队，等前面那批算完。这类问题刨到根上，大多会落到同一个词：推理优化。
训练和推理常被当成同一件事的前后两段，其实目标相反。训练要把一大批数据一次性喂进去，追的是吞吐；推理是用户敲一句、系统答一句，追的是别让人干等。同一套权重，挪到线上，评价标准就从「多久训完」变成了「首字多快出来」。
先分清是算不动，还是排不上
遇到慢，第一反应往往是加卡。但延迟的来源至少有三处：单个请求本身的计算量、同一时刻涌进来的请求数量、以及系统在两者之间怎么分配。头一种是算不动，后两种是排不上。分不清就动手，钱花出去了，曲线未必动。
省事的做法是先看延迟的分布，而不是平均数。均值好看、尾部难看，是线上很常见的状态：平均三百毫秒听着不错，可每二十个请求里有一个卡到两秒，用户记住的就是那两秒。均值是给报表看的，尾部才是给人受的。
几个常见的着力点
- 算子与内核：同样的计算，写法贴合硬件与否，跑起来差别不小。
- 批处理与调度：把多个请求攒成一批能抬高吞吐，代价是单条请求多等一会儿。
- 缓存：自回归生成是一个字一个字往外吐，前面算过的键值没必要每步重来，缓存下来能省掉大量重复计算，但它吃显存，上下文越长越明显。
- 压缩：量化、蒸馏这类做法把模型变小变轻，速度和显存都受益，代价是精度可能掉一点——掉在哪、能不能接受，得看具体任务，不能一概而论。
这些手段常被并列成一张清单，实际彼此牵制。批处理抬高吞吐却推高单条延迟；缓存省下计算却占住资源；量化省显存，但有些任务对数值精度格外敏感。所谓推理优化，多数时候不是把某一项拉满，而是在几条互相拉扯的曲线之间，找一个业务能接受的交点。
业务不同，容忍度差得很远
长文档摘要是可以等的，等十秒也没人报警，那就尽可以用更慢更省成本的方式跑；输入法的补全慢一百毫秒就废了，用户手指已经打下个字。同样叫优化，方向可能完全相反。先问清楚这条链路能容忍多少延迟，比先问用什么技术要紧。
还有一层不太好绕过去：能力与速度常常此消彼长。把模型换小是最直接的办法，可如果任务本身需要多步推敲，小模型答不对，快也白快。反过来，为了几百毫秒的收益去牺牲正确率，很多场景并不划算。
它更像运维，而不是调参
真正难的从来不是知道有哪些手段，而是判断哪一处值得动。先量，再改，改完再量；把「算力不够」和「调度不好」分开记账；把峰值和常态分开看。这些事做久了，推理优化给人的感觉更像运维，而不是坐下调几个参数就能收工。