模型路由应该根据哪些指标决定，用户请求如何被发送到合适的推理节点

模型路由应该根据哪些指标决定，用户请求如何被发送到合适的推理节点

在大规模 AI 推理系统中，模型路由并不是简单地把请求平均分配给几台 GPU 服务器。真正的路由决策需要回答两个问题：当前请求需要什么样的推理资源，以及哪个节点能够以最低的代价完成这次请求。

当系统同时部署多个模型、不同规模的 GPU 以及不同推理框架时，请求的输入长度、预计输出长度、模型类型、量化精度、并发状态和 KV Cache 使用情况都会影响最终性能。因此，一个有效的模型路由器实际上更接近一个实时调度系统，而不是传统 Web 服务中的简单负载均衡器。

请求特征首先决定候选模型

模型路由的第一层不是选择 GPU，而是判断请求应该进入哪个模型服务。

例如，一个系统同时部署通用对话模型、代码模型和视觉语言模型，那么路由器首先需要根据请求类型、业务标签或者模型指定信息确定候选模型。对于已经明确指定模型的 API 请求，路由器通常不需要重新判断模型能力，而应该直接在对应模型的可用实例中进行调度。

对于允许自动选择模型的系统，则可以进一步根据任务类型、上下文长度、输出要求、质量等级以及成本限制选择模型。

因此，“模型参数量”并不是路由器最重要的实时指标。175B 模型通常需要更多计算和显存资源，但一次具体请求的实际资源消耗还取决于精度、上下文长度、批处理方式、并行策略以及 KV Cache 等因素。

尤其是在推理阶段，不能简单根据参数量推导显存需求。模型权重只是显存占用的一部分，运行时还可能需要 KV Cache、中间激活、通信缓冲区以及推理框架本身的额外内存。

请求长度是非常重要的路由指标

对于大语言模型，输入 token 数量和预计输出 token 数量直接影响推理成本。

一个只有几百 token 的请求，与一个几十万 token 的长上下文请求，即使使用同一个模型，对 GPU 的资源需求也可能完全不同。

因此，路由系统通常需要至少掌握：

输入 token 数量

最大上下文长度

预计输出 token 数量

请求优先级

是否支持流式输出

是否需要特定模型能力

这些信息可以帮助路由器判断请求应该进入哪个实例。

例如，一个已经积累大量 KV Cache 的实例可能正在处理多个长上下文请求。即使它当前 GPU utilization 看起来并不高，也不代表它适合接收新的长上下文请求。相反，一个 GPU 利用率较高但当前请求即将结束的实例，可能比一个正在建立大量 KV Cache 的实例更适合作为下一次请求的目标。

因此，单纯使用 GPU 利用率进行路由通常是不够的。

排队时间往往比 GPU 利用率更有价值

传统 Web 服务经常使用 CPU 利用率、连接数或者请求数量进行负载均衡，但大模型推理存在明显不同。

推理服务器通常包含等待调度、Prefill、Decode 等不同阶段。一个节点的 GPU 利用率可能很高，但如果当前批次很快完成，新请求实际上可能很快得到处理。

反过来，一个 GPU 利用率只有几十个百分点的节点，也可能已经排队了大量长上下文请求。

因此，模型路由应该尽可能估算请求的排队时间和预计完成时间。

一个比较实际的评分思路是：

候选节点得分 = 排队成本 + 预计计算成本 + 通信成本 + 资源压力 + 迁移或加载成本

最终选择综合成本最低的节点，而不是简单选择 GPU utilization 最低的节点。

对于延迟敏感型 API，还可以进一步区分首 token 延迟和完整请求延迟。

Prefill 阶段主要受到输入上下文长度和计算资源影响，而 Decode 阶段则与输出 token 数量、批处理以及 KV Cache 管理密切相关。对于流式对话服务，首 token 延迟可能比总生成时间更加重要；对于批量离线任务，则更应该关注整体吞吐量。

KV Cache 会改变路由决策

在大模型推理系统中，KV Cache 是传统负载均衡模型很难直接处理的因素。

同一个模型实例处理不同上下文长度的请求时，KV Cache 占用会持续变化。如果一个节点已经积累了大量长上下文请求，再把新的长请求发送过去，很可能迅速增加显存压力。

因此，路由器除了观察 GPU 显存使用率，还应该关注 KV Cache 的实际使用情况以及剩余容量。

对于支持 Prefix Cache 的推理系统，还可以进一步考虑缓存命中情况。

例如两个节点运行的是同一个模型，其中一个节点已经缓存了与新请求高度相似的前缀，那么把请求发送到这个节点可能减少重复计算。此时，即使该节点的基础负载略高，也可能拥有更低的实际推理成本。

这意味着现代模型路由已经从传统的“哪个服务器空闲”逐渐发展为“哪个节点最适合处理这一个请求”。

GPU 类型需要作为约束条件，而不是简单排名

异构 GPU 环境会进一步增加路由复杂度。

例如，同一个模型分别运行在不同代际 GPU 上，其计算能力、显存容量、显存带宽以及互联能力都不同。但是不能简单建立一个固定排名，然后永远优先选择性能最高的 GPU。

原因很简单：GPU 的价值取决于请求。

对于计算密集型请求，更强的计算能力可能明显降低推理时间；对于显存受限的长上下文请求，显存容量可能比峰值计算性能更加重要；对于多 GPU 模型，还需要考虑 GPU 之间的互联拓扑。

因此，路由系统应该维护的是“模型—硬件组合”的性能画像，而不是简单的 GPU 性能排行榜。

例如，可以通过历史监控数据建立：

模型 A + H100 → 平均首 token 延迟

模型 A + A100 → 平均首 token 延迟

模型 B + H100 → 每秒生成 token 数

模型 B + A100 → 每秒生成 token 数

然后结合实时负载估算当前请求在不同节点上的实际完成时间。

多 GPU 模型还涉及拓扑问题

对于 Tensor Parallelism、Pipeline Parallelism 等部署方式，请求并不是简单发送到一张 GPU。

一个模型实例可能由多张 GPU 共同组成。这时，路由器选择的实际上是一个 GPU 集合或者一个推理实例，而不是单张 GPU。

因此需要考虑 GPU 之间的互联拓扑。

同一服务器内部的高速互联通常能够提供比普通跨节点网络更低的通信延迟和更高的有效带宽。但具体性能取决于 GPU 型号、互联方式、拓扑结构以及推理框架的通信模式，不能简单用某一个理论带宽数字代替实际性能。

如果模型并行跨越多个节点，那么网络通信就会进入请求关键路径。此时，节点之间是否具备高速网络、拓扑是否满足要求以及当前网络拥塞情况，都可能影响最终延迟。

因此，对于多 GPU 推理服务，路由器应该把“实例拓扑”作为调度资源，而不是把所有 GPU 看成完全相同的独立资源。

模型加载状态也必须纳入路由

模型自动扩缩容时，模型是否已经加载到 GPU 显存，是一个非常现实的路由指标。

假设某个新节点刚刚启动，但模型权重还没有加载完成，那么它虽然已经被云平台标记为 Running，却实际上无法立即承担推理请求。

如果路由器没有区分“节点在线”和“模型 Ready”，就可能把请求发送给一个尚未完成初始化的实例。

更进一步，如果一个模型权重需要从对象存储或本地 NVMe 加载，启动延迟可能达到数十秒甚至更长。在这种情况下，频繁扩容和缩容可能造成明显的冷启动成本。

因此，模型实例至少应该具有类似这样的状态：

Starting

Loading Model

Ready

Draining

Unhealthy

Stopped

路由器只应该把正常请求发送给真正处于 Ready 状态的实例。

对于已经进入缩容流程的实例，则应该进入 Draining 状态，不再接收新的长请求，同时允许正在处理的请求自然完成。

自动扩缩容不能只看当前请求量

模型路由和 Auto Scaling 实际上是两个不同层次的问题。

路由器解决的是“这个请求现在交给谁”。

自动扩缩容解决的是“系统现在需要多少个实例”。

如果请求队列持续增加，路由系统可以将请求发送到当前可用节点；当预计等待时间超过服务目标时，扩缩容系统才需要增加实例。

因此，扩缩容决策应该观察更长时间窗口的数据，例如请求速率、排队长度、GPU 使用情况、KV Cache 压力、首 token 延迟以及实例启动时间。

如果模型冷启动需要较长时间，仅仅等到 GPU 已经满载之后才启动新实例通常已经太晚。更合理的方式是根据排队趋势和预测负载提前扩容。

路由策略也应该避免频繁震荡

实时路由最大的工程问题之一是状态变化非常快。

如果路由器每隔几秒重新计算一次所有节点权重，很容易出现这样的情况：

节点 A 负载下降 → 大量请求立即进入 A → A 负载上升 → 路由器又把请求全部转向 B → B 随后出现同样问题。

这种反馈循环会导致系统产生不必要的负载震荡。

因此，实际系统通常需要加入平滑机制，例如使用滑动窗口、负载预测、最大并发限制、排队长度阈值以及节点冷却时间。

对于不同类型的请求，还可以采用不同的路由策略。

短请求可以优先降低首 token 延迟；长上下文请求需要优先考虑 KV Cache 和显存容量；批量任务则可以优先考虑吞吐量和单位计算成本。

模型路由最终应该变成一个多目标优化问题

成熟的模型路由系统不会依赖一个指标决定所有请求的去向。

比较合理的决策维度包括：

请求类型和模型能力

输入与输出 token 数量

上下文长度

KV Cache 使用情况

当前排队长度

预计等待时间

首 token 延迟

Decode 吞吐

GPU 显存压力

GPU 计算负载

CPU 与网络资源

GPU 型号和实例拓扑

模型是否已经加载

节点健康状态

请求优先级

运行成本

这些指标之间还存在明显的优先级关系。

例如，当节点已经没有足够显存容纳新请求时，成本和 GPU 利用率再低也没有意义；当两个节点都能够正常处理请求时，才需要进一步比较预计延迟和资源成本。

因此，实际工程中可以采用“硬约束 + 动态评分”的方式。

先过滤掉无法满足模型、显存、并行拓扑和健康状态要求的节点，再对剩余候选节点计算综合评分。这样比单纯给 CPU、GPU、显存分别设置固定权重更加合理。

模型路由的核心并不是寻找一台“最空闲”的 GPU，而是预测哪个推理实例能够以最低的资源和延迟成本完成当前请求。

随着模型规模扩大以及 GPU 集群越来越异构，路由系统最终需要同时理解请求、模型、GPU、KV Cache、网络拓扑和队列状态。传统负载均衡器只负责把流量分出去，而 AI 推理路由器需要进一步判断请求应该在哪里计算，以及在那里计算需要付出多少代价。

这也是 AI 推理基础设施与传统 Web 服务调度之间最重要的区别之一。