模型服务网关的请求路由：多模型负载均衡与优先级调度的设计
一、当 5 个请求分给 3 个模型，谁先谁后是个问题
一个企业级的算法判题系统通常不止接入一个模型。可能在内部部署了开源的 Qwen，云上接入了百度的文心，还有 OpenAI 的 GPT 系列作为备选。这些模型的能力有高有低，价格有贵有便宜，响应速度有快有慢。前端源源不断地涌来判题请求，后端网关需要做两个决策：把这个请求派给哪个模型，以及当多个请求在排队时，谁优先被处理。
这就是模型服务网关的核心职能——请求路由。一个好的路由策略，能在资源有限的情况下最大化服务质量：高优先级的付费用户走最快的模型，低优先级的免费用户走兜底模型；复杂的代码分析交给推理能力强的模型，简单的语法检查交给轻量模型。
二、路由决策的三个维度
模型网关的路由不是简单的随机分发或轮询，它需要在三个维度上同时做决策。
维度一：优先级。不是所有请求都同等重要。实时判题场景（用户在前端等着结果）和批量判题场景（离线分析历史提交）对时延的要求完全不同。如果两者的请求进了同一个队列，批量任务会大量积压，拖慢实时请求的响应。优先级调度通常用双队列实现：一个高优队列，一个低优队列，调度器总是先消费高优队列，高优队列为空时才处理低优队列。为了防止低优队列永远得不到处理（即"饥饿"），可以设置一个时间上限，超过上限后强制处理低优请求。
维度二：模型能力匹配。不同题目适合不同模型。简单的语法判断（"代码能不能编译通过？"）用轻量模型就够了，响应快成本低。但复杂的算法复杂度分析（"这段代码的最坏情况时间复杂度是多少？"）就需要推理能力强的大模型。把能力匹配做在路由层，本质上是用计算资源的差异化分配，换取整体成本效益的最大化。
维度三：健康状态。模型实例会宕机、会超时、会在高并发下响应变慢。路由层必须实时感知每个实例的健康状态。实现上通常用两种手段：被动的失败计数（连续失败 N 次后剔除）和主动的健康探测（定时发送探活请求）。被剔除的实例会进入半开状态，定时发送少量请求试探是否恢复，确认恢复后重新加入可用池。
三、优先级调度器的生产实现
下面给出一个带双队列优先级调度的路由服务实现。核心是使用两个独立的优先级队列，调度器按权重从两个队列中取任务。
/** * 模型网关优先级调度器 * * 设计要点： * 1. 双队列分离高优和低优请求，物理隔离 * 2. 权重调度避免低优请求饥饿 * 3. 队列容量上限防止内存溢出 */ public class PriorityModelRouter { // 高优先级队列：容量较小，确保快速消费 private final BlockingQueue<JudgeTask> highPriorityQueue = new LinkedBlockingQueue<>(200); // 低优先级队列：容量较大，允许积压 private final BlockingQueue<JudgeTask> lowPriorityQueue = new LinkedBlockingQueue<>(1000); // 高优和低优的调度权重：每处理 7 个高优，处理 3 个低优 private static final int HIGH_WEIGHT = 7; private static final int LOW_WEIGHT = 3; // 连续处理高优请求的计数，用于饥饿检测 private int consecutiveHighCount = 0; // 饥饿阈值：连续处理 HIGH_STARVATION_THRESHOLD 个高优后强制处理一个低优 private static final int HIGH_STARVATION_THRESHOLD = 20; /** * 提交判题任务到对应优先级队列 * * @param task 判题任务 * @throws RejectedTaskException 队列满时抛出 */ public void submit(JudgeTask task) { BlockingQueue<JudgeTask> targetQueue = task.isHighPriority() ? highPriorityQueue : lowPriorityQueue; if (!targetQueue.offer(task)) { // 队列满，根据优先级决定是否降级 if (task.isHighPriority()) { // 高优请求队列满，尝试塞入低优队列（很少发生） if (!lowPriorityQueue.offer(task)) { throw new RejectedTaskException("所有队列已满"); } } else { throw new RejectedTaskException("低优先队列已满"); } } } /** * 调度循环：按权重从两个队列取任务分发 * * 在独立线程中运行 */ public void dispatchLoop() { while (!Thread.currentThread().isInterrupted()) { try { JudgeTask task = selectNextTask(); if (task != null) { // 根据任务复杂度选择模型池，然后转发 ModelInstance target = selectModel(task); target.dispatch(task); // 更新调度计数 if (task.isHighPriority()) { consecutiveHighCount++; } else { consecutiveHighCount = 0; } } else { // 两个队列都为空，短暂休眠 Thread.sleep(50); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } } /** * 按权重选择下一个任务 * * 规则： * - 有高优请求时优先处理高优 * - 但连续处理太多高优后强制处理低优（防止饥饿） * - 只有高优队列空时才处理低优 */ private JudgeTask selectNextTask() { // 饥饿保护：连续处理高优超过阈值，强制处理低优 if (consecutiveHighCount >= HIGH_STARVATION_THRESHOLD) { JudgeTask lowTask = lowPriorityQueue.poll(); if (lowTask != null) { consecutiveHighCount = 0; return lowTask; } } // 正常调度：优先高优，高优空时取低优 JudgeTask task = highPriorityQueue.poll(); if (task != null) { return task; } return lowPriorityQueue.poll(); } /** * 根据任务复杂度匹配合适的模型 */ private ModelInstance selectModel(JudgeTask task) { if (task.getComplexity() == Complexity.SIMPLE) { // 简单任务：优先轻量模型，响应快成本低 return modelPool.getLightweightInstance(); } else { // 复杂任务：分配推理能力强的模型 return modelPool.getHeavyInstance(); } } // 注入的模型池（此处省略具体实现） private ModelPool modelPool; }这个调度器的核心设计是双队列 + 饥饿保护。如果不做饥饿保护，高优队列持续有请求时，低优队列里的请求可能永远得不到处理。饥饿保护的策略不复杂：连续处理了一定数量的高优请求后，强制从低优队列取一个请求出来处理。
还有一个需要权衡的参数：队列容量。容量设太小，请求容易被拒绝；容量设太大，积压的请求会导致用户等待时间过长，且内存有溢出风险。合理做法是根据系统压测数据确定容量，然后在配置中心动态调整。
四、负载均衡算法的选择
优先级调度解决了"先处理谁"的问题，负载均衡解决的是"交给哪个实例"的问题。
最简单的方案是轮询，但在模型服务场景下效果不好。因为不同请求的计算量差异很大——一道复杂的动态规划题可能让模型推理 30 秒，而一道简单的语法检查可能只需要 2 秒。轮询不考虑当前负载，可能把多个繁重任务分给同一个实例，而另一个实例闲着。
更好的方案是最少连接算法：把请求分配给当前处理中请求数最少的实例。这个方案隐式地考虑了请求处理的耗时差异——处理慢的实例积压的请求多，新请求也就不会再分配过去。
还有一个容易忽略的设计点：连接复用。每次 HTTP 请求都重新建连，TLS 握手和 TCP 三次握手的开销不可忽略。路由层应该维护一个连接池，对相同模型实例复用长连接，减少建连开销。
五、总结
模型服务网关的请求路由，本质上是把有限的计算资源（不同能力的模型实例）分配给不同优先级和复杂度的任务。优先级调度用双队列解决了实时请求和批量请求的冲突，模型匹配用能力差异化分配降低了整体成本，负载均衡用最少连接算法提升了资源利用率。这三个层面的设计配合起来，就是一套实用的多模型路由方案。
