vLLM Semantic Router 提出 Mixture-of-Models 系统架构

大多数 AI 应用都围绕单一模型端点构建。但随着模型、设备和部署约束的多样化，没有哪个单一模型能成为每个请求或环境的最佳选择。实际问题是，如何让多个专用模型通过一个接口进行协调、评估和提供服务。我们把这种系统化方法称为 Mixture-of-Models（模型混合）。

在公开发布后不到一年的时间里，vLLM Semantic Router 已经达到了 5,000 颗星、150+ 位贡献者，以及在我们 Hugging Face 模型系列中累计超过 300,000 次下载。在三个主要版本——Iris、Athena 和 Themis——中，系统边界从选择模型，发展到治理多模型推理，再到跨会话保持状态与协调。这些版本为从第 0 天就构想的 MoM 架构奠定了基础。

本文介绍 vLLM Semantic Router 的下一步：从在模型之间进行路由，转向用这些模型构建可靠的模型系统。在一个版本化契约之下，独立的模型、策略、偏好和执行路径成为一个系统，可以通过一个接口进行训练、评估、导出、导入、部署和调用。我们的目标是让 vLLM Semantic Router 成为 Mixture-of-Models 的训练、评估和推理引擎。

vLLM-SR 是如何走到这里的

第一篇 vLLM Semantic Router 文章提出了一个实际问题：为什么要给简单和困难的请求相同的推理预算？一个轻量级分类器使用固定领域标签在快速路径和推理路径之间进行选择，帮助 vLLM 更有选择性地使用推理算力。

生产流量很快暴露了这种设计的局限。仅靠领域无法表示隐私、安全、上下文、语言、模态、工具、偏好、延迟和授权。静态标签也无法应对一个端点虽然便宜但过载、能力强但远程，或者在 agent 会话中途切换不安全的情况。

我们围绕模块化模型支持、共享 LoRA 计算、Rust/Candle 推理和 Go 集成重建了分类器层。随后我们用 Signal–Decision 架构取代了固定分类，将观察到的证据与策略和执行分离。这成为接下来三个版本的骨干。

Iris 让路由变得可组合。领域、关键词、嵌入、事实性、反馈和偏好信号驱动显式决策，而安全、PII 保护、缓存、幻觉检测和工具选择则成为路由范围内的行为。Iris 还引入了 MoM 模型家族，并将 vLLM-SR 描述为“面向混合模型（Mixture-of-Models）的系统级智能”。

Athena 加入了一等公民的模型选择、记忆与 RAG、多语言多模态模型栈、ROCm 加速以及运维仪表盘。该项目正在成为围绕多模型推理的控制系统，而不仅仅是 vLLM 前面的一个分类器。

Themis 将这一更广泛的系统转化为一份可操作的契约：

信号成为投影。投影驱动决策。决策选择算法。算法选择模型。

Themis 加入了会话感知的智能体路由、可回放的追踪、更强的协议支持、运维控制台，以及跨 AMD ROCm、NVIDIA CUDA、Intel OpenVINO 和 CPU 环境的运行时路径。它还让每条路由变得可解释：运维人员可以看到每个决策背后的证据、策略、算法和物理模型。

从信号–决策到工作负载–路由器–池

这些版本构建了运行时。两篇项目论文解释了其背后的架构。

白皮书《面向混合模态模型的信号驱动决策路由》形式化了神经证据与符号策略之间的分离。快速启发式和学习型分类器将提示、上下文、身份、安全和模态转化为结构化信号向量；随后布尔引擎将这些信号组合成可审计的策略。类型化的神经符号 DSL 在将该策略编译为可部署配置之前对其进行解析和验证。论文发表时，系统覆盖了十三种信号类型和十三种模型选择算法，并配有用于缓存、RAG、记忆、安全、提供商处理和响应验证的逐决策插件。

愿景论文《面向 LLM 推理优化的工作负载–路由器–池架构》拓宽了框架。它主张三个变量必须协同设计：

• 工作负载：聊天或智能体、单轮或多轮、热或冷、预填充密集或解码密集
• 路由器：静态语义策略、在线反馈或 bandit 自适应、基于 RL 的选择，以及质量感知级联
• 池：同构或异构加速器、预填充/解码拓扑、模型放置和 KV 缓存管理

这些变量无法独立优化。工作负载形态会改变哪种路由策略有效；路由策略会改变所需的池规模和拓扑；池状态会改变哪条路由高效。安全与隐私横跨所有三个维度，而成本、质量、延迟和能耗定义了优化前沿。论文将项目的研究映射为一个 3 × 3 的 WRP 矩阵，并指出了二十一个这些维度仍需交汇的开放方向。

两篇论文共同让路由变得可编程，并将其与工作负载和硬件绑定——这是 MoM 纳入同一模型契约的两大基础。

与此同时，运行时早已超越了单一模型选择。Fusion、ReMoM、Confidence、Ratings 和有界 Workflows 让一次请求即可调用多个模型之间受控的协作。正如 Micro-Agent 工作所展示的，客户端可以调用一个模型名称，而服务层则选择一个配方，向各个 worker 分发任务，验证或综合它们的结果，并返回一个普通的响应。

路由仍然是根本。它是 Mixture-of-Models 分配工作、应用策略并协调各部分的方式。但路由只是机制。模型系统才是产品。

为什么模型边界必须移动

当今的 AI 技术栈在四个维度上是碎片化的：

• 模型是碎片化的。闭源前沿模型、开源通用模型、领域专家模型、紧凑的本地模型、验证器和多模态模型将共存。没有任何一个能在质量、成本、延迟、信任、隐私和领域契合度上同时胜出。

• 算力是碎片化的。GPU、CPU、专用加速器、边缘设备、云容量和私有集群在内存、内核、可用性、价格和能耗上各不相同。模型选择与部署位置正在成为同一个决策。

• 位置是碎片化的。推理横跨云、数据中心和边缘。隐私或驻留要求可能排除一个更强的远程模型，而本地工作负载仍可能需要按需调用的云端专家。

• 偏好是碎片化的。不存在通用的“最佳”。产品和用户在准确率、延迟、价格、隐私、安全性、风格和多模态之间做出不同的权衡。这些选择应当直接塑造执行过程。

如今，每个应用都必须自行调和这些碎片。

Mixture-of-Models 将这一职责移到了一个模型边界之后。

在那个边界上，智能分配成为模型的一部分。引擎决定哪些模型有资格参与、执行可以在哪里运行、模型是否应当协作，以及如何满足硬性约束。

能耗使分配与效率密不可分。硬件和推理引擎通过每瓦每美元产出更多 token 来改善供给侧。分配层则控制需求：哪些工作值得获得这些 token，以及哪个模型或协作方式能够在所需的质量、延迟和能耗预算内提供它们。

应用选择一个带版本号的模型身份，并收到一个可归因的响应。它的物理实现仍然可以横跨开源与闭源模型、云与边缘，以及不同代的加速器。碎片化依然存在，但它变成了模型系统的内部事务，而不再渗漏到每一个应用中。

我们所说的 Mixture-of-Models 是什么

模型混合是一种版本化的复合模型，其引擎通过偏好条件化、资源受限的路径，跨独立模型和算子实现每个请求。它通过一个模型接口呈现给用户，并返回一个可归因的结果。

多上游网关可以转发流量而不拥有系统质量。MoM 拥有一个目标、一个评估契约、一个可复现的组合以及执行它的运行时。

MoM 也不同于专家混合。MoE 在一次前向传播中在内部专家之间路由令牌；MoM 协调可能架构、所有者、许可证、模态、协议、上下文窗口和硬件各不相同的独立模型。一个 MoE 检查点本身可以是 MoM 的一个组件。

因此，一个可移植的 MoM 需要的不仅仅是权重和配置：它需要组件清单、能力元数据、路由和协作配方、策略、偏好、评估套件、运行时约束、来源和版本历史。

开放检查点可以随工件一起传播；封闭模型仍然是经过认证的外部引用，具有明确的能力和策略契约。导出一个 MoM 并不会使专有检查点变得可移植。它使模型系统可复现。

将偏好转化为模型

当偏好作为模型身份发布时，它们就变得具体。一个 MoM 系列可以提供多个操作点：

每个名称都是一个版本化的模型契约，而不是路由器预设。应用程序选择它需要的行为；vLLM-SR 选择并协调提供该行为的模型，同时保留硬性隐私、驻留、授权和安全约束。

对应用程序而言，整个系统仍然是一次普通的模型调用：

{
  "model": "vllm-sr/mom-v1-ultra",
  "messages": [
    {"role": "user", "content": "Review this design and identify its weakest assumption."}
  ]
}

该身份可以选择一个模型、通过级联升级、比较并行答案、要求接地或运行有界工作流——而无需更改外部接口、版本或响应契约。

四个平面划分所有权：

部署必须将逻辑需求映射到其环境中可用的模型和机器上。该方案使用四个对象：

1. bundle 固定接口、图、策略、行为变体、边界和不可变的语义资产。
2. binding 将逻辑组件映射到符合条件的部署，而不改变模型的决策语义。
3. resolution lock 冻结组成修订、运行时、镜像、加速器和提供商观测结果。
4. run record 将每个决策、调用、约束检查、成本和结果归因于产生它的 bundle、binding 和 lock。

这种分离使可移植性保持诚实。同一个 mom-v1-ultra 可以绑定到 ROCm、CUDA、私有 CPU 或 NPU 节点，或混合部署，而不承诺从不透明的提供商那里获得相同的输出。相反，它保留控制语义，暴露替换项，并让服务和评估使用同一个已解析的系统。

vLLM-SR 作为 MoM 引擎

训练、评估和推理必须共享一个契约；否则研究、基准测试和生产会漂移到不同的系统中。

训练分配，而不仅仅是权重

MoM 训练涵盖路由器拥有的嵌入、信号编码器、偏好和安全模型以及选择器。它还学习分配与协作：哪条路径适合某个工作负载和预算，级联应在何时停止，面板应如何判断或综合，以及智能体会话应在何时切换模型。由于组成部分可能是独立的或封闭的，进展不需要通过所有部分的梯度；策略、阈值、池、提示、契约和拓扑可以从轨迹和结果中优化。

目标是在质量、延迟、成本、安全、隐私、可靠性、局部性和能耗方面达到前沿。回放和结果将生产经验反馈到离线训练中，而不让热路径悄悄重写策略。

将 MoM 作为一个模型进行评估

评估必须端到端地对模型身份进行评分；后端基准测试是输入，而不是结果。一个带版本的记分卡应衡量路由遗憾、协作增益、恢复、会话连续性、尾部延迟、成本、安全、隐私和能耗。它应压力测试提供商故障、设备丢失、模型分歧、工作负载漂移和偏好变化。每个声明的操作点也需要自己的测试：flash 在其延迟–质量前沿上，light 对照其质量下限，ultra 在其预算内。

科学测试比询问更多调用是否能改善基准更严格。在匹配的活跃计算下，条件系统能否比最佳固定模型更好地利用互补优势和失败模式？没有这种控制，MoM 可能会在巧妙的图背后隐藏暴力扩展。评估必须报告调用、token、成本、延迟和能耗以及质量——并在组合无帮助时予以公布。

在推理时执行智能

在推理时，引擎决定一个模型是否足够。它可以选择本地专家、保留热会话、通过置信度级联逐级升级、要求检索或验证、运行 Fusion 面板，或执行有界工作流。运行时拥有预算、拓扑、回退、追踪和响应契约；应用程序进行普通的模型调用。

一个可以移动的模型

我们的目标是构建一个完整的 MoM，它可以作为一个统一模型被构建、导出、导入、版本化、评估、部署和调用。逻辑规范编译为不可变包，绑定到环境，解析具体部署，并在服务和评估中保持相同的身份。

该产物应能在开发者机器、私有集群、云集群和边缘环境中运行，而其物理实现会发生变化。专家可能解析为可接受的本地检查点或托管端点；加速器运行时可能被替换。如果隐私导致远程专家不可用，引擎会遵循声明的回退或弃权路径。绑定不能静默重写图、放宽防护或将面板变成级联——这些更改需要新的模型版本。

“在任何硬件上运行”是一项架构要求，而不是声称每个组件今天都可移植。该项目已经支持跨 ROCm、CUDA、OpenVINO 和 CPU 的路径。接下来，硬件能力和放置成为 MoM 契约的一部分，允许引擎将模型系统映射到可用资源上。

用户体验的标准很简单：

一个模型身份。多个模型。任何硬件。

如果应用程序需要知道每个子模型归哪个提供商所有、哪个设备运行它，或执行哪个回退图，那么抽象就已经泄漏了。

现在改变什么

下一阶段聚焦于四个相互关联的领域：

1. 定义可移植的 MoM 规范。将组件、目标、策略、偏好、评估、约束和执行语义打包为一个版本化产物。
2. 闭合训练–评估–推理循环。通过评估和重放改进模型和配方，然后通过可审查、可安全回滚的发布交付它们。
3. 构建异构运行时。以硬件、位置、能耗和数据边界为输入，将一个 MoM 映射到云、数据中心和边缘。
4. 保持模型接口无聊。让 MoM 像单个模型一样易于导入、部署和调用。

这是一个研究计划，研究独立模型应如何专业化、竞争、验证和协作；如何衡量由此产生的系统；以及一个模型契约如何跨设备和环境存续。我们的使命是：

推进跨模型、设备和环境的智能科学。

我们将研究组合何时能产生超越单个检查点的能力，将放置与能耗视为智能的一部分，并将同一模型契约从边缘带到云端、从研究带到生产。

与我们一起构建

构建模型混合（Mixture-of-Models）所需的远不止路由。这项工作横跨模型训练、评估、服务系统、硬件和生产运维。

Iris、Athena 和 Themis 之所以进步，是因为贡献者带来了真实工作负载、添加了后端、训练了模型、发布了基准、发现了失败案例，并为更好的接口据理力争。MoM 需要同样广泛的工作：学习式分配、偏好优化、模型协作、能耗感知推理、可移植产物、开放评估以及异构运行时。

如果你正在研究这些问题，我们希望从你的工作负载和测量中学习。构建一个工作点、添加一个运行时、测试一种协作配方，或发布一个组合失败的案例。如果 MoM 的假设能在公开环境中被检验，它就会更强大。

致谢

vLLM-SR 的成长得益于工程、研究以及更广泛生态中的工作。我们感谢 Xunzhuo Liu、Huamin Chen、Bowei He、Yankai Chen、Fuyuan Lyu 和 Steve Liu 帮助塑造其技术与研究方向。我们也感谢 Andy Luo 和 Haichen Zhang 在 ROCm 支持、路由器模型训练和开放 MoM 实验方面的工作。

这项工作也由 FAUST、David Shrader、Yang Wu、Ramakrishnan Sathyavageeswaran、Kuntai Wu、Aayush Saini、siloteemu、Chen Wang、Yue Zhu、Senan Zedan、Yossi Ovadia、Samzong Lu、Liav Weiss、Asaad Balum、Yehudit、Noa Limoy、Marina Koushnir、Jared Wen、Abdallah Samara、Hen Schwartz、Srinivas A、Yang Zhu、Jintao Zhang、yuluo-yx、cryo、Bishen Yu、Zhijie Wang、Hao Wu 和 Qiping Pan 共同承担。他们的代码、评审、测试、文档和管理工作推动项目从一个版本走向下一个版本。

在这个里程碑上，项目已达到 1,734 次提交 和 150+ 位贡献者。我们感谢 MBZUAI、McGill University、Mila 和 Rice University 的合作者，以及更广泛的 vLLM、AMD、Intel、Meta、Red Hat、Microsoft、Google、IBM、NVIDIA、Hugging Face、NASA、Nutanix、DaoCloud 和开源社区。这个里程碑属于每一位帮助将一个早期路由器变成真实系统的人。

在 GitHub 上加入我们，探索文档，试用 MoM 模型家族，并在 vLLM Slack 的 #semantic-router 频道中与社区见面。

vLLM Semantic Router 最初是帮助基础设施为每个请求选择正确的模型。

现在，我们正在将这一基础扩展到单个模型之外：走向能够在不同设备和环境中协调、评估和运行多个模型的系统。

我们邀请社区公开帮助构建和测试该方法。