推理服务平时 P99 延迟 300ms，业务一搞活动就飙到 3 秒，GPU 利用率看着也不高。延迟尖刺很多时候不是算力不够，而是排队和调度没跟上突发。先确认瓶颈在哪：延迟拆成排队等待和实际推理两段，埋点一看，尖刺时排队等待占了 80% 以上。GPU 利用率不高是因为请求在队列里等着，没到 GPU 上。再看排队模型：单队列 FIFO 在突发下最容易出长尾，短请求被长请求堵在后面。改成按请求长度分级调度，短请求优先，P99 延迟立刻降下来。当然分级要防饥饿，长请求加个等待上限。然后看弹性扩容：固定实例数扛突发就是赌运气。按队列深度而不是 CPU/GPU 利用率触发扩容，队列一涨就加实例，扩容信号比利用率早 1~2 分钟到。冷启动慢的模型提前做权重预热，别等扩容了才开始加载。最后看客户端侧：突发时客户端重试会放大队列压力。重试加指数退避、加熔断，服务端的队列才有机会排空。服务端和客户端一起调，只调一侧效果有限。这次是分级调度加队列深度扩容两招一起上，P99 从 3 秒压回 500ms 以内。大家做推理服务时，扩容触发指标用的是利用率还是队列深度？有没有被客户端重试雪上加霜的经历？