演示时，提问刚发出去，答案就顺着屏幕往下走；上线后，同一套界面却开始出现停顿。用户不会关心后台用了什么模型，只会觉得“今天怎么这么慢”。这类落差，往往不是模型突然变笨，而是请求的组成、并发、缓存状态和资源调度都换了环境。推理优化要处理的，正是这些藏在响应时间里的细碎成本。
先分清是算得慢，还是等得久
一次生成式请求大致会经历输入处理、逐字解码、结果返回几个阶段。输入处理更偏向并行计算，解码阶段则常常受内存带宽和缓存访问牵制。用户感知到的延迟，还包括排队、网络往返、前后处理和安全过滤。若只盯住模型计算，容易把“排队很久”误判成“算得很慢”。先把时间拆开，知道每一段大概花在哪里，后面的判断才不容易跑偏。
这也是为什么，单看吞吐指标会掩盖问题。批量请求能让硬件忙起来，却可能让单个请求等更久；缓存命中能省下重复计算，但缓存失效时的抖动也会被用户放大。对交互式产品来说，尾部延迟往往比平均值更接近真实体验：多数请求很快，少数请求卡住，用户的记忆却会停在卡住的那一次。
批处理不是越大越合适
批处理、量化、算子融合、KV缓存管理、请求调度，这些手段经常被放在同一个篮子里讨论，但它们解决的不是同一类问题。批处理改善硬件利用率，量化降低显存占用和部分计算成本，缓存管理减少重复劳动，调度则决定谁先走、谁再等等。把这些手段当成彼此替代，容易做出局部漂亮、整体别扭的选择。
比如，一个后台摘要任务可以容忍更长等待，把请求攒起来处理也许划算；一个面向客服的对话框，用户盯着光标，等待就会被放大。前者可以追求吞吐，后者要收住尾部延迟。同一个服务里同时存在两类请求时，混在一个队列里处理，就可能让轻请求被重请求拖住。按场景分流，或者给短请求留出快速通道，通常比单纯调大批量更接近问题本身。
把优化放回业务现场
推理优化听起来像算法团队的事，实际却很难脱离产品流程。输入长度限制、上下文裁剪、重试策略、流式输出、超时提示，都会改变用户对“快”的感受。一个系统如果总是等到整段答案生成完才展示，哪怕后台并不慢，前台也会显得迟钝；反过来，流式返回先把首段内容送到用户眼前，等待感会被重新分配。
还要留意优化带来的副作用。压缩上下文可能让回答丢掉关键信息，激进缓存可能把过期内容递给用户，过度合并请求会让故障影响面变大。每一次性能调整，都应该配一个可观察的回落方案：看延迟分布，也看错误率；看资源占用，也看回答质量。否则，数字上的轻快可能只是把成本挪到了别处。
在这个意义上，我更愿意把推理优化看成对请求路径的持续整理，而不是给模型加一个开关。先量清楚时间花在哪，再决定是减少计算、减少等待，还是减少不必要的往返。演示环境和真实业务之间的差距，通常就藏在这些看似琐碎、却天天发生的地方。