vLLM Semantic Router 推出 Fusion 多模型融合路由原语

单模型服务已不再是生产级 AI 系统的上限。现代应用往往拥有一个模型组合：快速模型、廉价模型、私有模型、推理模型、提供商 API 以及本地 vLLM 后端。难点在于判断何时一个模型就足够，以及何时一个请求应当成为一个协同的模型系统。

Fusion 是面向这一世界的下一个 vLLM Semantic Router 原语。它让一条路由运行一组模型面板，让一个评判模型分析一致性与差距，并综合出一个面向用户的答案，同时将策略、配置和追踪保留在路由器内部。

OpenRouter 的 Fusion 发布是一个有用的信号，说明了为什么这在当下很重要：模型面板正在成为一种实时的服务模式，而不仅仅是离线研究构想。本文并非要克隆一个托管端点，而是要让 Fusion 成为面向 Mixture-of-Models 服务的可编程、可观测的 vLLM-SR 原语。

vLLM-SR 的核心论点

多年来，默认的服务问题很简单：

哪一个单一模型应当服务这个请求？

这个问题仍然有用，但已不再足够。生产系统现在需要能够做到以下事项的策略：

• 将简单请求路由到快速、低成本的模型
• 将困难请求升级到更强的专家模型
• 在模型切换会损害上下文时保持会话连续性
• 在模型执行之前应用隐私、安全和租户策略
• 在分歧有价值时扇出到多个模型
• 记录决策路径，以便运维人员调试和改进它

这就是 vLLM-SR 的核心观点：模型质量不仅是检查点本身的属性，也是围绕该检查点的服务系统的属性。

AMD GPU 上的 Mixture-of-Models工作为 vLLM-SR 引入了这种以路由器为中心的视角：捕获信号、选择模型、协调异构后端，并暴露路由。ReMoM 将同一方向扩展到多轮模型协作。Fusion 为那些值得付出延迟代价进行多次独立处理的请求，增加了一种更直接的面板-评判-综合模式。

Fusion 增加了什么

Fusion 并非 Mixture-of-Models 故事的全部。它只是路由器工具箱中的一种算法。

在 vLLM-SR 中，Fusion 是路由策略的一部分，而不是一个固定的全局端点：

1. 信号描述请求：领域、复杂度、上下文、安全、反馈或其他证据。
2. 决策选择该请求应当走普通路由还是 Fusion 路由。
3. 仅限 Fusion 的入口配合 model: "vllm-sr/fusion" 将匹配范围缩小到支持 Fusion 的决策，因此请求仍能获得智能路由，而不会静默回退到单模型路由。
4. 面板模型生成独立的候选答案。
5. 一个评判模型提取共识、矛盾、部分覆盖、独特见解和盲点。
6. 一次综合调用返回一个面向用户的答案。
7. 追踪记录哪些模型参与了以及发生了什么。

最后一点很重要。一个托管模型 slug 隐藏了其中大部分内容。vLLM-SR 让面板、评判、策略和追踪变得显式，因此运维人员可以选择 Fusion 适用于何处，而不是为每个请求都付出代价。

为什么 OpenRouter 的结果是一个有用的信号

OpenRouter 的发布值得讨论，因为它为同样的系统理念提供了一个公开的佐证。在 DRACO 上——一个围绕高难度开放式任务构建的深度研究基准——OpenRouter 报告称融合面板的表现优于单个模型。

这些是 OpenRouter 的数据，不是 vLLM-SR 的基准测试。我们将其视为外部证据，表明模型组合理应成为一等公民的推理原语：

对 vLLM-SR 而言最有趣的一行是预算面板。它表明独立的模型多样性可以恢复单个更便宜模型所缺乏的质量。这正是路由器应当掌控的那类权衡。

Fusion 在 vLLM-SR 中如何工作

该实现围绕一个原则设计：Fusion 应当是一种路由算法，而不是全局模型设置。

全局运行时配置只注册哪些模型 slug 应触发直接 Fusion 执行。实际的面板、评判器、错误策略、模板和运行时旋钮都位于匹配到的路由决策上，因为这些选择是特定于工作负载的。一条研究路由可能想要三个多样化的提供商。一条代码审查路由可能想要两个本地专家和一个更强的综合模型。一条隐私敏感的路由可能将整个面板保留在自托管的 vLLM 后端上。

vLLM-SR 支持三种方式进入同一算法：

一旦请求到达 Fusion 循环器，执行就是显式且可观测的：

1. 解析策略。 vLLM-SR 合并决策级 Fusion 配置、决策模型引用和请求级插件覆盖。
2. 保护路由器。 已注册的 Fusion slug 不能用作评判器或面板模型，因此 Fusion 请求无法递归调用 Fusion。
3. 运行面板。 分析模型并发执行，受 max_concurrent 限制。
4. 按策略处理失败。 on_error: skip 允许部分面板；on_error: fail 使提供商故障立即可见。
5. 分析分歧。 评判器模型针对共识、矛盾、部分覆盖、独特见解和盲点生成结构化分析。
6. 综合或调用工具。 最终的评判/综合调用返回一个助手响应，或者当客户端提供了工具时，返回一个 OpenAI 兼容的 tool_calls 响应。
7. 返回追踪与核算。响应可以包含 Fusion 追踪数据、中间面板输出、失败的模型记录，以及跨面板、评判和综合调用的聚合 token 用量。

最后一项是路由器价值的一部分。调用方收到的是 OpenAI 兼容的响应，而运维方仍能获得系统级视图：触发了哪个决策、哪些模型参与、运行了多少次迭代、什么失败了，以及整个多模型执行消耗了多少 token。

本次发布聚焦于服务原语：策略控制的面板、显式的阶段契约、提供商互操作性，以及可追踪的执行。质量问题值得单独进行一次更大规模的公开评测，在共享任务上比较 Fusion、单模型基线和前沿面板。

Fusion 是一个决策，而非默认

Fusion 之所以有用，是因为某些请求能从独立的模型视角中获益。它之所以昂贵，是因为它增加了面板调用、评判分析、综合，并且通常带来更高的延迟。生产环境中的问题不只是“我们能否融合模型？”，而是“Fusion 何时值得？”。

这正是 vLLM-SR 的意义所在。model: "vllm-sr/auto" 让路由器决定一个请求是否应该使用 Fusion。简单的提示词可以留在快速的单模型路由上。困难的研究、模糊的分析、高风险的综合作业，或分歧有价值的任务，可以匹配到 Fusion 决策。同一个信号-决策层还可以在路由器付出延迟代价之前，编码领域、租户、隐私、成本、会话或安全策略。

model: "vllm-sr/fusion" 是希望仅使用 Fusion 路由的客户端的显式路径。它仍然使用 vLLM-SR 的信号和决策，但将匹配范围缩小到支持 Fusion 的决策，因此不会静默回退到普通的单模型路由。请求级 Fusion 插件是需要为单次调用提供面板的客户端的覆盖路径。

这为运维方提供了一个比单一托管 Fusion slug 更有用的控制平面：

决策之后：可追踪的 Fusion

一旦请求到达 Fusion 决策，vLLM-SR 就会运行一个具有显式阶段边界的小型多模型工作流。面板阶段返回独立的候选答案。评判阶段将这些候选答案转化为结构化分析。最终阶段消费该分析以生成一个助手答案，或在客户端提供了工具时生成工具调用。

阶段契约使系统保持可检查。如果某个面板模型失败，on_error: skip 可以在记录失败模型的同时以部分证据继续，或者 on_error: fail 可以立即停止。如果结构化评判输出无法解析，vLLM-SR 会保留原始分析并标记解析失败，而不是将其隐藏。最终响应可以包含 Fusion 追踪、中间面板输出、失败模型记录，以及整个运行的总 token 用量。

这就是 Fusion 如何超越一个功能。它成为可编程的 Mixture-of-Models 控制平面的一种实现。

用 vLLM-SR 试试

让路由器决定

当你希望路由器在所有已配置的决策中进行选择时，使用 vllm-sr/auto：

{
  "model": "vllm-sr/auto",
  "messages": [
    {
      "role": "user",
      "content": "What are the strongest arguments for and against carbon taxes?"
    }
  ]
}

如果匹配的决策使用 algorithm.type: fusion，请求进入 Fusion。如果匹配的决策是普通路由，vLLM-SR 使用正常选定的模型路径。

显式请求 Fusion

当客户端明确希望仅使用 Fusion 路由时，使用 vllm-sr/fusion。这仍会运行信号提取，但只有支持 Fusion 的决策才有资格：

{
  "model": "vllm-sr/fusion",
  "messages": [
    {
      "role": "user",
      "content": "What are the strongest arguments for and against carbon taxes?"
    }
  ]
}

为单个请求覆盖面板

请求还可以自定义面板。此覆盖是请求作用域的；它不会将评判或面板默认值移入全局配置：

{
  "model": "vllm-sr/fusion",
  "messages": [{ "role": "user", "content": "..." }],
  "plugins": [{
    "id": "fusion",
    "model": "google/gemini-3-flash-preview",
    "analysis_models": [
      "google/gemini-3-flash-preview",
      "moonshotai/kimi-k2.6",
      "deepseek/deepseek-v4-pro"
    ]
  }]
}

在 Agent 循环中使用 Fusion

对于 agentic 应用，继续使用相同的 OpenAI 兼容工具循环。Fusion 仅将工具调用权限授予最终评判者。面板模型和结构化评判分析调用仅运行文本：它们能看到对话历史，包括先前的工具结果，但它们不会收到 tools 或 tool_choice。

{
  "model": "vllm-sr/fusion",
  "messages": [
    {
      "role": "user",
      "content": "Find the latest benchmark result and explain whether it changes our launch plan."
    }
  ],
  "tools": [{
    "type": "function",
    "function": {
      "name": "web_search",
      "parameters": {
        "type": "object",
        "properties": {
          "query": { "type": "string" }
        },
        "required": ["query"]
      }
    }
  }],
  "tool_choice": "auto"
}

在该请求中，面板产生独立的文本分析，评判者比较面板，只有最终评判者可以直接回答或返回标准的 OpenAI 兼容 tool_calls。非流式客户端收到常规的 Chat Completions JSON 结构；流式客户端收到带有 finish_reason: "tool_calls" 的工具调用 SSE 块。客户端追加的工具结果会在下一个 Fusion 轮次中保留，因此多轮 agent 循环可以继续工作。

配置入口点和决策

全局配置仅注册 API 入口别名：

global:
  router:
    auto_model_names:
      - vllm-sr/auto
      - auto
      - MoM

Fusion slug 注册在 looper 集成下：

global:
  integrations:
    looper:
      fusion:
        model_names:
          - vllm-sr/fusion

每个决策的配置拥有路由语义、评判者、面板和运行时旋钮：

routing:
  decisions:
    - name: deep-research-fusion
      description: Use model diversity for research prompts with high synthesis risk.
      rules:
        operator: AND
        conditions:
          - type: domain
            name: research
          - type: complexity
            name: needs_reasoning:hard
      algorithm:
        type: fusion
        fusion:
          model: google/gemini-3-flash-preview
          analysis_models:
            - google/gemini-3-flash-preview
            - moonshotai/kimi-k2.6
            - deepseek/deepseek-v4-pro
          max_concurrent: 3
          on_error: skip

这种分离是有意为之。global 是与路由无关的运行时状态。评判者、面板、可选的 token 预算、并发和路由语义属于该决策。

当运维人员希望与现有客户端兼容时，可以选择启用 OpenRouter 风格的别名：

global:
  integrations:
    looper:
      fusion:
        model_names:
          - vllm-sr/fusion
          - openrouter/fusion

默认情况下，vLLM-SR 仅注册 vllm-sr/fusion。

接下来是什么

OpenRouter 的 DRACO 结果是一个强烈信号，表明模型面板值得认真评估。我们的下一步是让这种评估对 vLLM-SR 和 Mixture-of-Models 系统可复现：

• 运行超出冒烟覆盖范围的更大规模公开评估
• 比较 Fusion、ReMoM、AutoMix、Router-R1 和单模型基线
• 研究预算面板与前沿模型面板的对比
• 暴露针对分歧、覆盖缺失和评判者行为的追踪级诊断
• 让路由策略决定何时额外延迟是合理的

方向很明确。最佳答案不会总是来自最大的模型。它将越来越多地来自最佳模型系统，而 vLLM-SR 正是该系统应当可编程的地方。