AI 中转站如何防止租户互相拖慢：公平调度和“吵闹邻居”测评清单

Written by

多租户 AI 网关最容易被忽略的问题不是总吞吐，而是资源分配。一个租户突然启动批处理，可能占满连接、队列和上游并发，其他租户的短请求即使很快也只能排队。只设置一个全局 QPS 上限，无法解决这种“吵闹邻居”问题。

先定义公平对象

请求数公平不等于资源公平。一个短文本请求和一个长上下文请求消耗的 token、连接时间和费用不同。调度可以同时考虑租户并发、token 预算、队列等待时间和请求类别。交互请求需要低延迟，批处理可以接受排队，但不能无限饿死。

常见做法是为租户设置并发池和令牌桶，再在池之间使用加权公平队列。高优先级不应意味着无限资源，而是更早获得调度机会。对超出配额的租户，系统要返回可解释的限流状态和预计重试时间，而不是静默堆积任务。

长请求会占用连接和模型上下文，短请求则容易被大量堆积。可以限制单请求最大 token、为长任务使用独立队列、给交互请求预留并发，并用 aging 机制提升等待过久的普通请求。对工具调用还要区分读取和写入，避免批量写操作占满所有执行槽。

通过 top-api.cc 统一多模型入口时，可以把租户、项目、环境和请求类型作为调度标签，记录排队时间、服务时间、token 和回退次数。这样才能判断是上游拥塞，还是某个租户的任务分配策略不合理。

不要只报告总吞吐。一个系统即使每分钟处理更多请求，也可能让普通用户的 P99 延迟变得不可接受。公平调度的目标是让资源使用可预测，让每个租户知道自己的预算、优先级和等待原因。

参考资料：加权公平队列、令牌桶和多租户资源隔离的通用实践，以及 AI 网关的并发和 token 限制文档。

如果需要先统一不同上游的鉴权、计量和回退，再细分租户队列，可以用 top-api.cc 作为入口，但公平策略应在自己的网关配置中明确记录。