夜班客服是最能暴露模型脾气的地方。白天流量平稳，系统看起来从容；到了凌晨，咨询量骤降，值班的人少，可一句含糊的回答仍会被截图放大。于是很多团队把目光投向推理优化，希望用更少的卡、更低的延迟撑住这个长尾时段。但真正做起来会发现，优化很少是“加个开关”那么简单。
先分清两段完全不同的工作
一次生成大致分两段：模型先读完输入，建立可复用的中间状态，这段计算密集但并行度高；随后逐字吐答案，每吐一个词都要重新走一遍网络。前一段像批量备课，后一段像现场答题，节奏完全不同。很多团队盯着总量做优化，却忽略了两段的时间占比会随输入长度和回答长度剧烈变化。长文档摘要卡在预填充，开放式问答则被解码拖住。不先量清楚瓶颈在哪一段，调参很容易白费。
缓存的收益，藏在重复里
对话场景天然有重复：系统提示词、产品手册片段、固定话术，每轮都会重新喂给模型。把已经算过的中间状态缓存下来，下一轮直接复用，能省掉大量重复计算。这类做法的前提是前缀稳定，一旦提示词顺序变动或内容频繁改写，缓存就失效。所以推理优化在工程上的一个实际动作，往往不是改模型，而是把提示词结构固定下来，让可复用的部分尽量靠前。听上去不够性感，收益却实在。
另一个容易被低估的点是批处理。把多个请求拼在一起算，能提高硬件利用率，但用户要等同一批里最慢的那条完成。夜间咨询稀疏时，批处理几乎攒不起来，延迟优势反而消失。白天高峰和深夜低谷，本就该用不同的策略，一套参数打天下只会让两头都不舒服。
降级不是失败，是设计的一部分
很多讨论把优化等同于“又快又准”，现实中更常见的是一组有意识的放弃。回答长度上限、上下文窗口裁剪、复杂问题转人工、模糊问题先给确认再继续，都是把不确定性挡在用户感知之外的手段。关键在于降级要让人知道：是回答得简短，还是暂时接不住。含糊其辞的降级比慢一点更伤信任。
还要承认边界。推理优化能压缩计算浪费，却压不掉问题本身的难度。需要多步核对的任务，省掉核对步骤就会出错；需要长上下文的场景，截断之后信息就丢了。把优化当成万能解，最后往往是把成本从机器转移到了人工复核和用户投诉上。
回到那个夜班
回到夜班客服。合理的做法也许不是追求极致的单次响应速度，而是让常见问题走缓存和短回答，复杂问题明确转交，同时在低峰期保留足够的余量，避免一次异常输入拖垮整条链路。推理优化的价值，更多体现在这些具体的取舍里，而不是某次压测数字好看。它是一套关于“哪些可以省、哪些不能省”的判断，需要跟着业务节奏一起调整。