队列满了该拒绝谁：用 Token 预留实现可解释的准入控制

两个同为一个 QPS 的请求，可能一个只需要短问答，另一个带着几万 Token 的文档。只限制请求数，会让负载看起来稳定，显存和排队时间却突然失控。准入规则需要描述工作量，同时能解释一次请求为什么被拒绝。

10 月 19 日 Elastic EP 讨论了在线扩容的准备与提交阶段。官方文章 扩容完成之前，可用容量仍然有限；队列不能无限积累来“等待新机器”。

先预留，再排队

最小模型为每个请求预留一个成本上界，完成、取消或失败后归还。这里用 Token 数做教学代理；真实系统应结合 KV 块、上下文、最大输出、模型布局和共享前缀计算增量资源。预留太保守会浪费容量，太乐观则需要后续扩充失败的处理策略。

class Admission:
def __init__(self, capacity):
if capacity <= 0:
raise ValueError("invalid capacity")
self.capacity, self.reserved = capacity, {}

def reserve(self, attempt_id, cost):
if cost <= 0 or attempt_id in self.reserved:
raise ValueError("invalid or duplicate reservation")
if sum(self.reserved.values()) + cost > self.capacity:
return False
self.reserved[attempt_id] = cost
return True

def release(self, attempt_id):
return self.reserved.pop(attempt_id, None) is not None

pool = Admission(10)
assert pool.reserve("a:1", 8)
assert not pool.reserve("b:1", 4)
assert pool.release("a:1")
assert not pool.release("a:1")
assert pool.reserve("b:1", 4)
assert sum(pool.reserved.values()) <= pool.capacity
print("reservation, rejection and idempotent release passed")

程序把释放做成幂等操作，避免重复完成通知把池子“加出”不存在的容量。使用 attempt_id 而不是只用逻辑请求 ID，是为了区分一次重试与原尝试；真实系统还需要阻止迟到的原尝试释放新尝试的资源。

拒绝策略不能只留下一个 503

若请求本身超过单请求上限，应明确告知不能接收；若总容量暂时不足，可以有限排队或建议稍后重试。两种失败混成同一种返回，会让客户端用同样策略反复撞门。

公平性也需要定义。先进先出可能被超长请求阻塞；短请求优先可能让长请求饥饿。可以分服务等级、设置等待上限或为长请求留份额，但这些都是额外策略，不能从一个 Token 计数器自然得到。

本例没有并发锁、持久化或分布式一致性。在多线程、多进程网关中，检查与扣减必须成为受保护的原子操作。离线通过只表明顺序状态逻辑成立，没有验证 GPU OOM、生产网关或真实大促洪峰。