有个做客服系统的朋友抱怨，模型回答的内容挑不出毛病，就是慢。用户打一行字，界面转三秒，人就走了。这类问题很少是模型“不够聪明”，多半卡在生成的那段时间上。
时间花在哪里
一次请求通常分两段：先把整段上下文读进去，再一个字一个字往外吐。前者计算密集，后者受限于显存带宽——每生成一个词，都要把模型权重和缓存过一遍。多数人感知到的“卡”，其实发生在后半段。
所以推理优化的第一步，不是急着换更小的模型，而是看清楚时间到底去了哪里。是首字等待长，还是输出越到后面越慢？这两种情况对应的方法并不一样。
常见几处着手点
- 批处理：把多个请求凑在一起算，把带宽用满。代价是排队，高峰期延迟抖动会更明显。
- KV 缓存：缓存已算过的上下文，避免重复计算；但缓存本身吃显存，长对话下会变成新的瓶颈。
- 量化：把权重压到更低的位宽，省显存也省带宽，精度损失需要按任务实测，不能只看论文里的数字。
- 投机解码：用小模型先猜、大模型再校验，猜得准时提速明显，猜不准时反而拖慢。
- 结构上的取舍：更短的上下文、流式输出、稀疏激活，都是在体验和成本之间换位置。
边界在哪
有一点常被忽略：延迟不只来自计算。网络往返、调度排队、下游拼接、前端渲染，都在预算里。见过把模型提速一倍、用户却毫无感知的情况——瓶颈在下游的某个接口。推理优化如果不能端到端地看，很容易变成局部自嗨。
另一层边界是场景。离线批量打分可以牺牲延迟换吞吐，实时对话反过来。同一个模型，两套配置，结论完全不同。所以谈优化之前先问清楚：这是给人看的，还是给程序看的？能不能接受首字慢一点、后面快一点？
一个更实际的判断
我倾向把推理优化当成预算分配问题，而不是技术选型问题。给定一个延迟上限，把钱花在最紧的那一段；省下来的算力未必用来跑更大的模型，也可能只是让高峰不再排队。
至于那些“一招提速数倍”的说法，先看它在什么上下文、什么并发、什么长度下成立。条件一变，数字就换一副面孔。更靠谱的做法往往是把链路上每一段都量一遍，然后承认大部分环节只能改一点，凑起来才有意义。
用户不会关心你用了哪种解码策略，他只记得那次等待有没有超过耐心。