晚上十一点，有人对着对话框等回答。光标闪了两秒，文字才开始一个一个往外蹦。这两秒里发生的事情，和“模型正在思考”这种说法相去甚远。
快的部分和贵的部分不是一回事
一次生成大致可以分成两段。前一段把用户输入的整段话读进去，算出上下文状态，只做一次；后一段逐字往外吐，每吐一个字，都要把已经出现的内容重新算一遍注意力。前一段的问题是慢，后一段的问题则是重复——重复意味着算力和显存的持续消耗。
很多人谈推理优化，脑子里想的是“让回答更快”。但真正下手时，第一件事往往不是加速，而是把这两段的账分开算。用户感知到的是首字延迟和吐字速度，服务方承担的是单位时间能处理多少请求、每千字花多少钱。这两组指标并不总是同向变化。
几种常见做法，各有各的代价
- 缓存中间结果。把已经算过的键值状态留下来，下一个字就不必从头再来。省下的是重复计算，付出的是显存。
- 把请求攒在一起算。多个请求同时进入计算，硬件利用率上去了，吞吐变好，但排在后面的那个人的等待会变长。
- 降低数值精度。权重和激活用更少的位宽表示，内存带宽压力小一些，代价是输出可能更不稳定，需要挑合适的场景。
- 先猜后验。用一个小而快的模型草拟几个字，再由主模型一次性校验。猜中的部分几乎白赚，猜不中则要回退，收益取决于任务本身的可预测程度。
这些手段并不互斥，但也不是叠加就更好。有些组合在离线批处理里很漂亮，搬到实时对话里就会把尾部延迟拉得很难看。
优化会把瓶颈推到别处
这是推理优化里最容易被低估的一点：每一次提速，都会让新的瓶颈浮出来。计算快了，瓶颈可能变成内存带宽；内存够了，瓶颈可能变成调度；调度顺了，瓶颈可能落在网络和前后处理的琐碎环节上。盯着一个指标调到极致，往往只是把队列挪了个位置。
所以真正有用的顺序通常是反过来的：先测，再改。把一次请求拆成若干段，看时间落在哪一段，看长尾请求和普通请求差在哪里。没有测量支撑的调优，很容易变成给某个数字做美容。
还有一个边界值得说清楚。推理优化改变的是交付方式，不是模型的能力上限。它能让本来就答得出来的问题答得更快、更便宜，但不会让答不出来的问题突然有了答案。把延迟降下来之后，用户对质量的容忍度反而会下降——等得久了会原谅含糊，答得快了就会挑剔措辞。
回到那两秒。它可能来自排队，可能来自一次没猜中的投机，也可能来自把一个本可以缓存的中间状态丢掉了。搞清是哪一种，比笼统地说“再快一点”要有用得多。