vLLM 语义路由器 Fusion 原语实现可编程的多模型服务

TL;DR

vLLM 为其 Fusion 原语 发布了 Semantic Router，使生产系统能够运行协同的异构模型面板，评估它们的输出，并在路由器内部保持策略、配置和追踪的同时合成单一响应。这使得模型混合成为一等的、可编程的服务模式，而不再是临时实验。

超越单一模型的需求

传统的服务只问 哪个单一模型应该处理请求？ 现代 AI 应用现在需要一组模型——快速且廉价的模型、私有本地模型、专门的推理模型以及外部提供商的 API。运营者必须决定何时请求可以由单一模型满足，何时应触发一个协同的多模型工作流，以遵守成本、延迟、隐私和安全策略。

Fusion 作为路由原语

Fusion 被引入为 路由算法，而不是全局端点。它由路由器的信号‑决策层激活，并遵循明确的流水线：

信号提取 – 请求被标注上领域、复杂度、安全性等信息。
决策制定 – 路由器根据这些信号选择普通路由或 Fusion 路由。
Fusion 入口 – 使用 model: "vllm-sr/fusion" 强制仅匹配支持 Fusion 的决策。
面板执行 – 一组 analysis models 并发生成独立的候选答案。
评判 – 一个 judge model 评估共识、矛盾、缺口和独特洞见。
合成 – 评判模型（或单独的合成模型）生成单一面向用户的响应，可选地发出兼容 OpenAI 的 tool_calls。
追踪 – 路由器记录运行了哪些模型、失败情况、令牌使用情况以及结构化分析，以便调试和计费。

入口路径与策略控制

入口路径	行为
`model: "vllm-sr/auto"`	运行完整的信号/决策逻辑；仅当所选决策的 `algorithm.type` 为 `fusion` 时才运行 Fusion。
`model: "vllm-sr/fusion"`	仍然提取信号，但仅考虑支持 Fusion 的决策；如果没有匹配项，则返回明确的错误。
Request plugin `{"id": "fusion", ...}`	为单个请求覆盖面板、评判模型和运行时参数，即使没有匹配的决策，也构建一个作用域化的 Fusion 执行。

这种分离使运营者能够将 Fusion 保持为可选的、受成本控制的特性，而不是每个请求的默认设置。

来自 OpenRouter 的证据

OpenRouter 最近的 Fusion 推出（DRACO 基准）表明，多样化模型的面板可以超越最强的单一模型。他们报告的分数包括：

配置	DRACO 分数
Fusion: Fable 5 + GPT‑5.5, synthesized by Opus 4.8	69.0%
Fusion: Opus 4.8 + GPT‑5.5 + Gemini 3.1 Pro, synthesized by Opus 4.8	68.3%
Solo Claude Fable 5	65.3%
Solo DeepSeek V4 Pro	60.3%

预算面板行说明，混合使用更便宜的模型可以弥补任何单一低价模型失去的质量——这正是路由器应当管理的权衡。

详细的 Fusion 工作流

解析策略 – 将决策层面的 Fusion 配置与任何请求层面的覆盖合并。
保护路由器 – Fusion 标识符不能用作面板或评判模型，以防止递归的 Fusion 调用。
运行面板 – 所有分析模型并发调用，遵守 max_concurrent。
处理失败 – on_error: skip 继续剩余模型；on_error: fail 则立即中止。
评判分析 – 评判模型返回结构化的 JSON，描述共识、矛盾、部分覆盖、独特洞见和盲点。
合成或工具调用 – 最后一步产生普通答案或兼容 OpenAI 的 tool_calls 响应。
返回追踪 – 响应负载可以包含完整的 Fusion 追踪、中间面板输出、失败记录以及聚合的令牌使用情况。

由于追踪是显式的，运营者可以调试路由决策、监控成本，并根据真实世界的分歧模式改进策略。

Fusion 是一种决策，而非默认

Fusion 会增加延迟和令牌成本，因此路由器必须决定何时值得使用。使用 vllm-sr/auto 时，路由器评估信号（例如请求复杂度、领域、租户策略），仅对高风险或高价值查询选择 Fusion 决策。简单的提示仍然使用快速的单模型路由。显式的 vllm-sr/fusion 别名允许客户端在需要额外视角时强制使用 Fusion。

示例 API 调用

让路由器自行选择

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

如果匹配的决策指定 algorithm.type: fusion，请求将走 Fusion 流程；否则将使用选定的单模型。

强制使用 Fusion

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

仅考虑支持 Fusion 的决策；若没有匹配项，则返回明确的错误。

为单次调用覆盖面板

{
  "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

Fusion 与兼容 OpenAI 的工具调用一起工作。面板模型接收对话历史，但不会看到 tools 或 tool_choice。只有最终的评判模型可以发出 tool_calls。

{
  "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"
}

面板生成分析；评判模型决定是直接回答还是返回 tool_calls 负载。

配置布局

全局运行时配置仅注册入口别名：

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

Fusion 标识符在 looper 集成下注册：

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

每个决策的路由配置保存实际的 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

这种分离保持全局状态最小化，同时允许细粒度、工作负载特定的 Fusion 策略。

未来方向

OpenRouter 的 DRACO 结果激励在 vLLM‑SR 中系统性评估 Fusion：

大规模公共基准测试，超越烟雾测试。
在 Fusion、ReMoM、AutoMix、Router‑R1 与单模型基线之间的比较。
对预算面板与前沿模型面板的分析。
增强的追踪诊断，用于分歧、覆盖缺口和评判行为。
关于延迟‑成本权衡的策略研究，以决定何时采用 Fusion 是合理的。

总体愿景很明确：最佳答案将越来越来自由可编程路由器编排的 模型系统，而不是最大的单一检查点。vLLM‑SR 的 Fusion 原语使该系统可观察、可配置且可投入生产。

参考文献

OpenRouter Fusion 发布：https://openrouter.ai/blog/announcements/fusion-beats-frontier/
AMD GPU 上的模型混合：https://vllm.ai/2026/01/23/mom-on-amd-gpu.html
DRACO 基准论文：https://ar5iv.labs.arxiv.org/html/2602.11685

vLLM 语义路由器 Fusion 原语实现可编程的多模型服务

vLLM 语义路由器 Fusion 原语实现可编程的多模型服务

TL;DR

超越单一模型的需求

Fusion 作为路由原语

入口路径与策略控制

来自 OpenRouter 的证据

详细的 Fusion 工作流

Fusion 是一种决策，而非默认

示例 API 调用

让路由器自行选择

强制使用 Fusion

为单次调用覆盖面板

Agent 循环中的 Fusion

配置布局

未来方向

参考文献

Sources