单一模型服务不再是生产级AI系统的天花板

现代应用通常拥有一套模型组合：快速模型、廉价模型、私有模型、推理模型、供应商API以及本地vLLM后端。难点在于判断何时一个模型就足够，何时一个请求应当成为一个协调的模型系统。

Fusion 正是 vLLM Semantic Router 为这一场景设计的下一个原语。它允许一条路由运行一组模型（panel），让一个评判模型（judge）分析一致性与差距，并综合生成一个面向用户的答案，同时将策略、配置和追踪保留在路由内部。

这是一个有用的信号，说明为什么现在这件事很重要：模型面板正在成为一种在线服务模式，而不仅仅是离线研究思路。本文并非关于克隆一个托管端点，而是关于将 Fusion 打造成一个可编程、可观测的 vLLM-SR 原语，用于 Mixture-of-Models 服务。

图1：Fusion API 将模型多样性转化为 vLLM-SR 路由原语：面板、评判、综合、追踪。

vLLM-SR 的核心理念

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

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

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

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

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

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

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（一个围绕困难开放式任务构建的深度研究 benchmark）上，OpenRouter 报告称融合面板的表现优于单个模型。

这些是 OpenRouter 的数据，而非 vLLM-SR 的 benchmark。我们将其视为外部证据，表明模型组合值得成为一等公民的服务原语：

OpenRouter 报告的配置	分数
Fusion: Fable 5 + GPT-5.5, 由 Opus 4.8 综合	69.0%
Fusion: Opus 4.8 + GPT-5.5 + Gemini 3.1 Pro, 由 Opus 4.8 综合	68.3%
Fusion: Opus 4.8 + Opus 4.8, 由 Opus 4.8 综合	65.5%
单独 Claude Fable 5	65.3%
Fusion: Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro, 由 Opus 4.8 综合	64.7%
单独 DeepSeek V4 Pro	60.3%
单独 Kimi K2.6	53.7%
单独 Gemini 3 Flash	43.1%

对 vLLM-SR 来说，最有趣的一行是预算面板。它表明独立的模型多样性可以弥补单个廉价模型所缺乏的质量。这正是路由器应该控制的权衡类型。

Fusion 在 vLLM-SR 中如何工作

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

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

图2：Fusion 在 vLLM-SR 中是由信号驱动的。自动路由可以选择任何决策；直接 Fusion 路由仅在 Fusion 决策中进行选择；请求插件覆盖执行，而非全局策略。

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

入口路径	vLLM-SR 如何处理
model: "vllm-sr/auto"	运行完整的 vLLM-SR 信号和决策策略。仅当所选决策使用 algorithm.type: fusion 时才执行 Fusion；否则匹配的非 Fusion 路由正常运行。遗留别名如 auto 和 MoM 仍受支持。
model: "vllm-sr/fusion"	运行相同的信号提取，但将决策匹配限制为支持 Fusion 的决策。如果没有匹配的 Fusion 决策，除非请求提供了面板覆盖，否则 vLLM-SR 返回一个明确的无匹配错误。
plugins: [{ "id": "fusion", ... }]	为一个请求覆盖评判、面板和选定的运行时参数。如果没有匹配的 Fusion 决策且提供了 analysis_models，vLLM-SR 会构建一个请求作用域的 fusion_direct 执行。

一旦请求进入 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。简单的 prompt 可以停留在快速的单模型路由上。困难的研究、模糊的分析、高风险的综合或分歧有价值的任务可以匹配一个 Fusion 决策。在路由器支付延迟成本之前，相同的信号-决策层还可以编码领域、租户、隐私、成本、会话或安全策略。

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

图3：Fusion 是一个决策，而非默认设置。vLLM-SR 使用策略来决定何时额外的延迟是值得的。

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

生产问题	vLLM-SR 控制
这个请求应该使用 Fusion 吗？	vllm-sr/auto 配合信号和决策
应该应用哪个 Fusion 策略？	支持 Fusion 的决策，带有优先级和规则
哪些模型应该参与？	每个决策的评判和面板配置
如何处理延迟和失败？	max_concurrent、on_error 和可选的 token 策略
模型可以在哪里运行？	本地 vLLM 后端、私有端点和公共供应商
运维人员如何调试路由？	决策元数据、Fusion 追踪、失败和聚合使用量

决策之后：可追踪的 Fusion

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

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

图4：Fusion 使用显式的阶段合约，因此面板输出、评判分析、综合和追踪统计保持可检查性。

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

使用 vLLM-SR 尝试

让路由器决定

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

{
  "model": "vllm-sr/auto",
  "messages": [
    {
      "role": "user",
      "content": "支持与反对碳税的最有力论点是什么？"
    }
  ]
}

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

显式请求 Fusion

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

{
  "model": "vllm-sr/fusion",
  "messages": [
    {
      "role": "user",
      "content": "支持与反对碳税的最有力论点是什么？"
    }
  ]
}

为一个请求覆盖面板

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

{
  "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": "找到最新的 benchmark 结果并解释它是否会改变我们的发布计划。"
    }
  ],
  "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: 为具有高综合风险的研究 prompt 使用模型多样性。
      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 正是这个系统应该可编程的地方。