凌晨两点，一个聊天应用的响应时间从 1.2 秒涨到 8 秒。模型没换，机器没坏，流量也只涨了三成。值班工程师排查一圈，发现问题出在排队：新请求进不来，老请求算不完，显存里塞满了还没释放的中间结果。
这类场景在推理服务里并不罕见。关于速度的讨论，常被压缩成“换更强的卡”或“用更小的模型”，但真正拉开差距的，往往是那些不显眼的调度与内存细节。
延迟不是一个数字
用户感知到的“慢”，和工程师看到的指标往往不是一回事。首字延迟、每字间隔、整体完成时间，这三者对体验的影响完全不同。对话类产品里，首字延迟超过两秒，人就开始怀疑网络；而长文生成时，每字间隔的稳定性比峰值速度更影响阅读节奏。
推理优化首先要做的，是把目标拆开：到底在优化哪一段。盲目追求吞吐，可能把单个请求拖进长队列；一味压低单次延迟，又可能让显卡空转。两者之间存在结构性矛盾，工程上只能选一个主目标，再用其他手段补偿。
一个常见的误区是把批处理当成万能药。把多个请求合并计算，确实能提升单位时间的处理量，但代价是排在后面的请求要等前面凑齐。流量平稳时这是划算的，流量忽高忽低时，等待时间就会失控。更稳妥的做法是设定等待上限，让批处理在“凑够”和“等太久”之间主动放弃。
显存是被低估的瓶颈
很多人以为推理的瓶颈在算力，实际运行中，先撞墙的常常是显存。模型权重占一块，缓存占一块，中间激活值又占一块。上下文越长，缓存增长越快，能同时服务的请求数就越少。
于是就有了各种腾挪的办法：把不常用的权重挪到别处、压缩缓存的存储精度、按需分配而不是一次占满。这些手段单独看收益有限，叠在一起却能决定一台机器能扛多少并发。真正做过线上服务的人，对显存的敏感程度往往高于对算力的敏感程度。
围绕推理优化的很多争论，本质上是资源分配问题：把有限的内存留给更长的上下文，还是留给更多的并发用户。没有通用答案，只有与产品形态匹配的选择。
- 对话产品更在意首字延迟，愿意为它牺牲一部分吞吐；
- 批量处理型任务更在意总成本，可以接受请求排队；
- 长文档场景要先解决缓存增长，否则并发数会被迅速吃掉。
调度比模型更影响体感
同一套模型，换一种请求排队方式，用户感受到的速度可能差出一截。优先级、超时、重试、降级，这些看起来属于后端工程的词，实际上直接塑造了“快”与“慢”。
比如超时设置过短，请求被反复重试，反而加重了后端负担；设置过长，用户又迟迟等不到反馈。再比如降级策略，在主链路拥堵时切到更轻的处理路径，能让大部分请求先拿到结果，而不是一起卡住。这些决策不需要改模型，却需要对自己业务的流量曲线有足够了解。
也正因如此，推理优化很难外包给一个通用方案。别人调好的参数，搬到自己的流量结构里，未必成立。
边界在哪里
需要承认的是，优化有天花板。当模型能力本身要求较长的计算链路时，压缩和调度只能缓解，不能消除等待。用户对速度的容忍度也和场景强相关：一次复杂的分析任务，多等十几秒是合理的；一句简单的寒暄，多等两秒就显得迟钝。
更务实的思路，是把速度当成产品设计的一部分，而不是事后补救的技术指标。哪些请求必须即时，哪些可以异步，哪些可以先给粗略结果再逐步补全，这些问题在架构阶段想清楚，比上线后再调参数省力得多。
回到开头那个深夜故障。最终的修复并不复杂：限制了单次请求的上下文长度，给批处理加了等待上限，并把一部分非即时任务挪到了另一条链路。机器没换，模型没动，响应时间回到了正常区间。这类改动不惊艳，却是推理优化在真实系统里最常见的样子。