批越大吞吐越高，但尾延迟越难守住。

推理服务最常见的误区，是把“吞吐”和“延迟”当成同一件事来优化。实际生产中，二者是同一张卡上互相挤压的资源：调大批处理能压低单位请求成本，却会让排队时间变长，尾延迟迅速恶化；投机解码能改善单请求响应速度，但在高并发下反而可能挤占算力，让排队更长。真正决定用户体验的往往不是平均值，而是 P99 尾延迟，而尾延迟的根因多半在排队结构，而非模型本身。

输入侧：排队与准入控制。 请求到达后并非立即进入计算，而是先进入调度队列。队列长度、请求长度分布、优先级共同决定等待时间。长短请求混排是典型陷阱：一个超长请求进入批次后，会拖慢同批所有短请求，尾延迟被显著放大。因此输入侧的关键不是“快点收请求”，而是按长度分桶、设置队列上限和超时丢弃策略，避免无界排队。

推理/执行侧：批处理与投机解码的真实成本。 连续批处理通过动态拼批提升 GPU 利用率，吞吐随批大小近似增长，但单请求完成时间随批大小上升。投机解码用一个小模型草拟多个 token，再由大模型并行验证，本质是用额外算力换更少的大模型串行步数。它在低并发、单请求延迟敏感场景收益明显；但在高并发下，草稿模型同样占用计算与显存带宽，会与主模型争抢资源，吞吐提升有限甚至倒退。

输出/评测侧：看分布而非均值。 评测必须同时记录 TTFT（首 token 时间）、TPOT（每 token 时间）和 P99 尾延迟分布。只看平均延迟会掩盖排队造成的长尾；只看吞吐会忽略用户感知。正确做法是在固定 SLO 下做压测，观察不同批大小与并发下 P99 的拐点，找到吞吐与尾延迟的平衡区。