晚上十点，用户发来一句问题，窗口里的光标闪了两下才动。产品同事说模型“不够快”，工程师看监控却会发现，等待被拆成几段：请求进入队列，做预填充，逐字生成，再回传。只盯模型大小，容易把问题看窄；推理优化要处理的，是这些环节如何相互挤压。
慢不一定慢在生成
对话服务里，首字延迟和后续生成速度是两种体验。预填充阶段要读取上下文，生成阶段要逐 token 计算，二者对算力与内存带宽的要求并不相同。长上下文、多人并发、输出长度不确定，都会让队列里的请求形态变得复杂。把预填充与生成拆开调度，或对短请求设置更轻的路径，往往比笼统地换小模型更贴近现场。
缓存是另一个常被低估的部分。多轮对话中，历史内容反复参与计算，若能把可复用的中间状态留住，后续请求就不必从零开始。KV 缓存、前缀缓存、会话级缓存，名字不同，指向的是同一类问题：重复计算能否被识别并跳过。这里也有边界，缓存命中依赖请求相似度，内存占用和失效策略要一起考虑，不能只看单次加速。
并行与压缩之外
并行切分听起来直接，实际会引入通信开销。把一次请求拆到多张卡上，若同步等待过长，收益可能被抵消。相反，在服务层做路由，把长请求与短请求分开，把需要长上下文的流量引到更适合的实例，常常属于另一种推理优化。它不改变模型，却改变请求如何相遇。
压缩模型、量化权重、投机解码也常被提及。它们有用，但并非无条件成立。量化可能影响输出稳定性，投机解码依赖草稿质量，压缩后的模型在复杂任务上是否保持原有行为，需要评估。把延迟指标压下去，却让答案质量悄悄波动，这种交换在真实业务里并不划算。
先定义要改善的等待
讨论推理优化时，先问清楚要改善哪一段等待，比追一个笼统的“快”更实际。是首字出现太慢，还是长回答后程拖沓；是高峰期排队，还是单请求资源浪费。不同答案对应不同入口。监控若只记录平均耗时，容易掩盖长尾请求；把队列时间、预填充时间、生成时间拆开看，才知道该动调度、缓存，还是模型本身。
我的判断是，推理优化越来越像服务设计，而不是单点算法。模型能力决定上限，服务层决定用户实际感受到的节奏。把两者分开讨论，再在边界处做取舍，或许比寻找一个通用方案更可靠。