多模型推理请求分流：智能网关与GPU队列调度实战

一个在线客服系统接入了三个模型：4B 小模型响应常见问答、7B 通用模型处理中等复杂度问题、70B 大模型兜底复杂推理。上线两周后，发现 70B 集群 GPU 利用率长期 90% 以上，4B 集群不到 30%，但用户投诉的 TP99 延迟反而出在 70B 那条线上——大量简单问题因为“默认走强模型”的配置堆积在队列里，真正的复杂请求被挤到 300ms 之外。

这就是典型的多模型推理请求分流没做对。它不是简单的负载均衡，而是要在请求到达 GPU 之前完成一次“模型选择判断”：该走小模型还是大模型？什么时候升级？长耗时任务如何不阻塞实时请求？下面的讨论从网关路由策略和 GPU 队列调度两个维度展开，把流程拆成可落地的步骤。

一、多模型推理请求分流的核⼼原理是什么

1. 请求分流与普通负载均衡有什么区别

普通负载均衡只看后端实例的健康状态和连接数，把请求均匀地“撒”给一组相同的模型副本，不关心请求内容本身。多模型推理请求分流则要求网关“读懂”请求：判断任务的复杂度、紧急程度和成本预算，然后把它扔给最匹配的模型——可能是 7B 的通用模型，也可能是 70B 的强推理模型，甚至同一个请求在小模型给出低置信度结果后，自动升级到大模型重新处理。

这背后依赖的不是 Nginx 的轮询算法，而是一套模型感知的路由逻辑。RouteLLM 社区的一个公开 benchmark 显示，基于 embedding 相似度做语义路由，比按 API 端点静态路由的“模型匹配准确率”能提升 15-20 个百分点。准确率提升意味着更少请求被“错配”到大模型浪费算力，或者被“错配”到小模型导致结果质量不达标。

2. GPU 队列调度解决的是什么问题

网关决定“用哪个模型”，调度器决定“什么时候执行”。多个模型共享同一个 GPU 集群时，如果没有合理的调度机制，会出现一个很常见的故障：一个 batch 里全是长序列文本生成任务，耗时 2-3 秒，后面排队的一堆短问答请求只能干等着。

GPU 队列调度的核心是用优先级、抢占和连续批处理三类机制来管理显存和计算资源的分配。连续批处理是当前主流推理引擎的标配能力——vLLM 的 PagedAttention 机制允许在一个 batch 正在计算时，把刚完成推理的请求踢出去，新的请求塞进来，不用等整个 batch 结束。这可以视为在队列层面对 GPU 算力的“碎片化整理”。

3. 网关路由与队列调度如何协同

一条完整的推理链路上，智能网关负责“模型选择 + 请求分发”，调度器负责“显存管理 + 优先级执行”，两者解耦但信息互通。网关需要知道各模型当前队列积压情况（通过调度器上报的队列深度指标），调度器则需要按照网关下发的请求优先级标签（如“实时”“批处理”）来组织排队顺序。

小团队起步时容易把这个协同逻辑做成“一刀切”：所有请求打同一个标签，网关把所有请求都发给默认模型。这样做的后果是架构上虽然支持多模型，但实际执行时和多模型分流已经没什么关系了。

二、智能网关如何做模型感知路由

1. 从业务线固定路由起步

第一版不建议一上来就做动态路由。先把路由逻辑拆成“按业务线”或“按 API 端点”的静态映射跑通整体链路。比如客服系统里，常见问答 API 请求固定走 4B 模型，工单分析 API 走 7B 模型，知识库检索 API 走 70B 模型加 RAG 流程。这个阶段的目标是验证网关到各模型服务的连通性、延迟基线和错误处理逻辑。

配置层面，可以用 LiteLLM 这类开源网关，在 model routing 配置里把不同 API 路径映射到不同的模型名称，网关转发时自动替换模型参数。这里有一个容易踩的坑：静态路由的规则一旦固定下来，产品经理改一个场景就得运维改一次配置。静态路由只适合不超过 5 个模型的初期阶段，模型数量上来了必须向动态路由演进。

2. 语义路由如何实现动态分发

动态路由的核心是让网关根据请求内容判断“该用哪个模型”，而不是人来预先指定。一个可落地的方案是先跑 embedding 匹配：对每个模型能力定义一个代表性的 prompt 集合（比如 4B 擅长闲聊和短问答，70B 擅长多步推理），计算这些 prompt 的 embedding 向量作为各模型的“能力锚点”。当新请求进来，计算它的 embedding 与各模型锚点的相似度，路由到相似度最高的模型。

这个方案不需要训练专用路由模型，工程复杂度中等。另一个思路是训练一个小路由模型（参数量可控制在 100M 以内），直接输出“目标模型 + 置信度”，参考 FrugalGPT 论文中的级联路由思路。但路由模型本身也是一个额外开销，每次调用增加约 5-15ms 延迟，需要和路由准确率的提升做权衡。

路由方式	准确率	额外延迟	工程复杂度	适用阶段
静态按端点路由	依赖人工规则	无	低	初期 3-5 个模型
Embedding 语义路由	中高	5-10ms	中	模型数量增多后
专用路由模型	高	5-15ms	高	长期生产优化
级联混合路由	最高	视升级比例	中高	成本敏感场景

3. 级联策略如何用可控成本换质量保障

级联路由是目前业界验证效果最好的降本方案之一。逻辑清晰：请求默认走小模型，小模型输出带上置信度评分，评分低于阈值的自动升级到大模型重新推理。Stanford FrugalGPT 论文验证过这条路径后，大量生产系统采用了类似的架构。

阈值设置是落地的关键。设 0.9 太高，大部分请求都会升级，起不到降本效果；设 0.6 太低，大量应该升级的请求直接被小模型结果挡掉，端到端质量下降。建议先用离线评估集回放统计各模型在不同任务类型下的置信度分布，再找一个业务可接受的质量损失边界来反推阈值。举个例子，一个客服场景的离线回放可能显示：阈值设在 0.75 时，约 23% 的请求升级到大模型，整体推理成本下降约 40%，端到端回答准确率仅下降 1.2 个百分点——这 1.2% 能不能接受，由业务方拍板。

三、GPU 队列调度的配置与避坑

1. 在线与离线请求如何拆分队列

长文本总结、批量数据分析这类离线任务，执行时间可能在 2-5 秒甚至更长。如果不和在线短问答拆开队列，几个长任务就能把整个推理集群的响应延迟拖垮。

操作上，建议在调度器层创建至少两个队列：实时队列和批处理队列。实时队列配置更高的优先级和更短的排队超时，批处理队列允许积压但设置单请求上限。vLLM 启动时可以指定不同端口服务不同优先级的请求组，或者通过请求头里的 priority 字段在调度器层做区分。KServe 社区也有类似的 ingress scheduling 配置，适合已经用了 Kubernetes 和 KServe 的团队。

一个容易被忽略的点：拆分队列后，GPU 算力不是物理隔离的，两个队列共享同一组 GPU 显存和算力。这就意味着，如果批处理队列里塞进大量并发长任务，显存碎片化会导致实时队列也受影响。解法是给批处理队列设置最大并发数和显存上限。

2. 连续批处理为什么是提升 GPU 利用率的必修课

如果不启用连续批处理，推理引擎会等一个 batch 里所有请求都执行完才释放显存，新的请求才能进来。遇到一个 batch 里请求长度差异大，比如一个 512 token 输出混在 8 个 64 token 输出里，整个 batch 都得等那个最长的。

连续批处理的核心机制是“迭代级调度”：每完成一个生成步骤（iteration），就检查有没有请求已经生成结束，结束的立即释放 KV cache 显存，新请求立刻补位。这要求推理引擎支持 PagedAttention 或类似显存管理机制。vLLM 是当前开源方案里文档和社区最完善的，启动参数里打开 enable_prefix_caching 可以进一步提升相似 prompt 的显存复用率。

3. 如何避免长耗时请求阻塞短请求

队列级别的解决方案是设定抢占策略和超时机制。vLLM 支持在请求参数里指定 timeout，超过时间未完成可以触发优雅降级——网关接到降级信号后可以选择返回部分结果，或者升级到更大吞吐的模型快速输出。

另一个工程手段是在网关层做请求拆分：超过一定 token 数的生成任务，在网关层切成多个短段，逐一请求后拼接。这样做虽然增加了总请求数，但每段耗时短，对队列里其他短请求的阻塞影响更小。实践中可以把段长设置在 128-256 token 之间，具体值取决于业务能容忍的端到端延迟和 GPU 集群的并发处理能力。

四、多模型推理请求分流的常见误区与纠偏

1. 静态路由≠一直不动

一个很典型的翻车场景：业务上线初期配好“简单请求走 4B、复杂请求走 70B”的路由规则，半年后业务场景变了，简单请求的定义其实已经和初始判断偏差很大，但没人回去调路由配置，结果是 4B 模型都在答不该它回答的问题，客服投诉率升高。

路由规则需要定期复盘。建议建立一套以“路由准确率 + 单请求成本 + 延迟 P95”为核心的指标体系，每周或每次重大业务变更后，抽样一批请求日志，人工标注“该请求应该走哪个模型”，和路由决策对比，算出路由准确率。准确率低于设定阈值时，触发路由规则调整流程。

2. 不是所有请求都值得走语义路由

语义路由需要额外的 embedding 计算开销，这对延迟极度敏感的实时场景可能得不偿失。一些调用频率极高、任务类型极其固定的请求（比如同一类商品描述生成），静态路由的效率和成本反而更优。建议在网关层加一层判断：频次高、任务类型固定的请求按预设规则直通，不确定或低频请求才走语义路由，这样能在延迟和路由灵活度之间取得平衡。

3. 级联不是“套娃”

有些团队把级联路由理解成“小模型→中模型→大模型”三层甚至四层链式调用，认为层级越多成本越优。实际上每次升级调用都会引入网络延迟和额外计算开销，三层以上链条的收益递减效应明显。大部分场景两层足够：第一层是轻量模型处理大多数请求，非高置信度结果直接升级到最强模型，中间层反而增加了架构复杂度和故障排查难度。

五、从零搭建多模型推理分流架构的落地步骤

1. 架构分层：网关层、路由层、调度层各自负责什么

围绕多模型推理请求分流这条链路，可以把架构拆成三层理解。网关层负责接入认证、限流、请求日志记录和统一出口，这里是 LiteLLM 或自建网关发挥作用的地方；路由层是大脑，负责模型选择决策，可以集成 RouteLLM 这类开源路由框架，或者用 embedding 匹配做轻量实现；调度层管理 GPU 任务队列和显存分配，vLLM 或 Triton Inference Server 在这一层干活。

分层的好处是每一层的决策逻辑和性能指标可以独立观测和优化。网关层看请求延迟和错误率，路由层看模型匹配准确率和升级比例，调度层看 GPU 利用率和队列积压深度。三层各看各的指标，出问题时能快速定位。

2. 选型评估：开源方案能覆盖到什么程度

当前开源生态已经能覆盖多模型推理请求分流的大部分需求：LiteLLM 做多模型网关接入，支持接入不同厂商和开源模型，统一 API 格式；RouteLLM 提供路由策略框架，支持相似度路由、成本路由、延迟路由等多种策略；vLLM 做推理引擎调度，提供连续批处理和显存管理能力。三个组件组合起来，已经能跑通从“接入→路由→执行”的完整链路。

不过开箱即用的整合方案还不成熟，三个组件之间需要自己写胶水代码来打通指标上报和动态配置。如果团队没有专门的基础架构人力，起步时可以先只用 LiteLLM + vLLM 这两个组件，路由策略先用 LiteLLM 自带的成本路由做简单的模型选择，后续再逐步引入更复杂的分流逻辑。

3. 监控与迭代：用什么指标驱动持续优化

这套架构跑起来之后，最怕的是扔在那里没人看。核心监控面板需要至少四个指标：路由准确率（抽样评估）、单请求成本（各模型加权平均）、P95 延迟（分模型看）、GPU 利用率（别只看平均值，看 P50 和 P90）。路由准确率低于 90% 时优先调整路由策略，P95 延迟飙高先查调度层队列积压，GPU 利用率低查是不是连续批处理没生效或 batch size 配得太小。

生产环境建议先从按量付费的 GPU 实例起步测一周，观察实际访问模式和高峰期压力，调好参数后再转包年包月。这种做法比一上来就锁定长期资源更稳妥，具体采购方式需要以各云厂商官网或客服实时信息为准。

多模型推理请求分流的本质是把“用哪个模型、什么时候用、用多少算力”这三个决策从人工静态配置变成系统自动判断。它不是一次性项目，而是需要持续观测路由准确率、成本、延迟三类指标，并结合业务变化不断调整路由策略和调度参数的长线工程。拿到生产数据后第一件事，是抽一批请求日志做一次完整的路由回放评估，看看你的网关到底把多少请求送错了模型——这个数字会告诉你接下来该从哪里改起。