推理服务的延迟抖动通常不是模型前向计算变慢了，而是请求在网关、队列和推理实例之间经历了不均匀的等待。一个原本只需要几十毫秒的短文本生成任务，可能因为排在某个长序列后面而多等数百毫秒；一次普通的在线对话，也可能因为离线评估任务占满显存而被拖到秒级。想把尾部延迟压下去，不能只盯着算子优化，还要从流量入口的负载均衡和请求调度优先级入手。
抖动不是单点问题：先拆链路
请求从进入网关到真正被执行，通常会经过负载均衡、请求队列、调度器、GPU执行这几个环节。任何一个环节出现排队都会对最终延迟产生贡献。模型单次前向计算的时间可能非常稳定，但动态批处理机制会改变这一状态。推理引擎为了提升吞吐，会等待多个请求组成一个批次，或者等待一定时间窗口后再执行。如果队列中同时存在长度为512的长文本和长度为8的短文本，短请求也可能被拖到和长请求一起处理，等待时间因此被明显拉长。
实例之间的负载不均衡同样会放大抖动。如果负载均衡器只是简单轮询，两个实例一个忙一个闲，请求仍可能被分到忙实例，导致闲实例资源白白浪费。再加上显存碎片、KV cache占用不同，相同模型在不同实例上的可用上下文长度可能不一样，某些请求甚至会因为显存不足被拒绝或触发降级策略，进而引入重试和额外延迟。
因此，优化延迟抖动不能只改一个点。只调负载均衡却不区分请求优先级，在线请求仍可能被离线任务阻塞；只做优先级队列却不解决实例倾斜，高优请求也可能被路由到繁忙节点。有效的方案需要同时覆盖入口流量分配和队列调度策略。
负载均衡策略：从轮询到实时负载打分
传统负载均衡策略在推理场景下各有局限。轮询实现简单，但完全无视实例状态，一旦某个实例正在处理长请求，后续分过来的短请求就会被拖累。随机策略类似，只是把倾斜概率降低了一些。最少连接策略在长连接服务中比较常见，但推理服务里一个连接可能同时承载多个请求，连接数并不能真实反映压力。最少请求策略比最少连接更接近实际，但不同请求耗时差异巨大，短请求多时容易误判，以为实例空闲，实际上它可能正在排队处理少量长任务。
更合理的做法是采集每个实例的实时负载指标，通过加权打分选择目标实例。可以关注排队深度、活动请求数、平均等待时间和显存占用等维度。下面是一个简单的负载打分示例，分数越低表示越空闲：
def select_instance(instances):
best = None
best_score = float('inf')
for inst in instances:
score = inst.queue_depth * 10 + inst.active_requests * 5 + inst.kv_cache_usage * 0.1
if score < best_score:
best_score = score
best = inst
return best
实际系统中通常不会直接用单次采样值，而是采用滑动窗口统计最近若干秒的平均值，避免瞬时波动导致路由抖动。权重系数可以根据业务场景调整，例如对显存敏感的服务可以增大KV cache使用量的权重，对并发敏感的在线服务可以增大排队深度的权重。
如果推理服务需要复用KV cache，一致性哈希是一个常见选择。按照用户ID或会话ID路由到固定实例，可以提升缓存命中率，减少重复计算。但固定哈希容易造成热点，比如某一类用户恰好都映射到同一个实例。可以在一致性哈希之上增加负载上限，当某个实例的实时负载超过阈值时，让它暂时退出哈希环，由其他实例承接新请求，待负载回落后再恢复。
请求优先级：双层队列与防饥饿机制
同一个推理服务往往既要支持实时对话，也要跑离线评估或批量生成。如果所有请求共用一个先进先出队列，离线任务会很快填满队列，在线请求被迫排队，延迟抖动的概率大幅上升。因此需要按业务场景划分优先级，至少拆成高优和低优两个队列。调度器优先从高优队列取请求，高优队列为空时再处理低优队列。离线任务通常放在低优队列，同时限制其并发数量，避免占满GPU资源。
下面是一个基于堆实现的优先级请求队列，优先级数值越小越先被调度，相同优先级按入队顺序先进先出：
import heapq
class PriorityRequestQueue:
def __init__(self):
self.heap = []
self.seq = 0
def push(self, priority, request):
heapq.heappush(self.heap, (priority, self.seq, request))
self.seq += 1
def pop(self):
if not self.heap:
return None
_, _, request = heapq.heappop(self.heap)
return request
严格优先级虽然能保证高优请求快速响应，但可能导致低优请求长时间得不到调度，尤其离线任务可能被饿死。可以引入等待时间补偿机制，当低优请求在队列中等待超过预设阈值后，临时提升其优先级。也可以采用加权轮询，比如每处理4个高优请求，至少处理1个低优请求，保证低优流量不会完全停滞。更精细的做法是给离线任务分配资源配额，例如限制其最多占用30%的算力，剩余资源始终保留给在线请求。
可观测性驱动的动态调优
负载均衡和优先级调度都需要数据支撑。关键指标包括队列等待时间、批处理等待时间、实例排队深度、活动请求数、GPU利用率、显存占用以及P50、P95、P99延迟。把这些指标暴露给负载均衡器和调度器，可以形成闭环调整。例如当某个实例的排队等待时间P95连续超过阈值，就降低它被选中的概率；当高优请求的P99开始上升，说明当前调度策略可能已经接近瓶颈，需要限制普通和离线流量。
设置分级SLO有助于量化目标。例如高优在线请求P99低于300毫秒，普通在线请求P99低于1.5秒，离线任务不设硬性延迟要求但需要保证一定吞吐。根据SLO违反情况动态调整权重，比人工不断调参更可靠。高优延迟上升时，可以临时降低普通请求的并发上限，或者缩小动态批处理等待窗口，让请求更快被处理。
上线前还需要进行混合流量压测。构造不同长度、不同优先级的请求，观察P99、吞吐和实例负载变化，重点验证两个问题：低优请求是否被彻底饿死，以及负载上限触发后请求是否被正确迁移。灰度阶段先切一小部分流量，对比改造前后的尾部延迟和吞吐。如果P99明显下降而吞吐损失可控，说明方案有效；如果吞吐下降严重，则需要调整低优请求的配额或加权比例。