OpenRouter 发布 Fusion：多模型融合在 DRACO 深度研究基准上超越单个前沿模型

我们发现，将多个模型的结果综合起来，可以显著超越单个模型的能力。隆重推出 Fusion：一个能像调用单个模型一样轻松获得这些综合结果的工具。它允许你选择一组参与模型，以及一个负责将各个结果融合在一起的评判模型。

为了理解 Fusion 的优势，我们使用了一个深度研究基准，用于测试推理、工具使用和知识的结合。我们发现：

1. 模型组合始终优于单个模型
2. 借助前沿模型组合，可以实现超越前沿的性能
3. 预算模型组合可以超越前沿模型，并接近前沿组合的性能

立即试用 Fusion，在聊天室中体验，或查看 API 文档 将其集成到你的应用中。

模型组合在深度研究上始终表现更优

我们在 DRACO 基准 的 100 个深度研究任务上测试了 Fusion。以下是我们发现的一些亮点：

• Fable 5 + GPT-5.5 融合后得分 69.0%**，超越了每一个单独模型，包括单独 Fable 5 的 65.3%**。
• 一个预算组合（Gemini 3 Flash、Kimi K2.6 和 DeepSeek V4 Pro）击败了 GPT-5.5 和 Opus 4.8。它的得分与 Fable 5 相差不到 1%，而成本仅为其 50%。

** 100 个 DRACO 任务中有 7 个未完成，因为 Fable 5 的内容过滤器阻止了它们执行。我们选择不为这些任务回退到 Opus 4.8，因此 Fable 的结果反映的是 93 个已评分任务，而非全部 100 个。这能最准确地反映 Fable 自身的性能，但也意味着与完成了全部 100 个任务的模型进行直接得分比较时略有不对等。

我们相信这展示了模型多样性的优势，类似于人类团队表现中所见的优势。为复杂问题带来多种不同视角，能产生更优的结果。

一次 API 调用即可融合多个模型的最佳输出

当你向 Fusion 发送提示词时，我们会将其并行分发给一组模型，每个模型都启用了网页搜索和网页抓取。一个评判模型会阅读每个参与模型的响应，并生成结构化分析：共识点、矛盾点、部分覆盖、独特见解、盲点。然后，调用模型基于该分析撰写最终答案。

整个流程在服务器端运行，因此可以像调用单个模型一样调用它。

使用单个模型 slug 直接调用 Fusion：

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

或自定义模型组合：

{
  "model": "openrouter/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"
    ]
  }]
}

我们选择 DRACO 来测试推理、工具调用和简洁性

我们需要一个基准，能够区分一个模型是听起来详尽，还是真的详尽。标准基准测试的是事实回忆或推理谜题。它们并不测试 Fusion 所擅长的东西：研究一个复杂问题、综合多个来源，并生成一份全面、引用充分的深度分析。

DRACO（由 Perplexity AI 开发）正是为此设计的。它包含 100 个深度研究任务，涵盖 10 个领域：学术研究、金融、法律、医学、技术、UX 设计、通用知识、大海捞针式检索、个性化协助和产品比较。

每个任务都配有一套评分标准，包含约 39 项加权指标，分为四个类别：

• 事实准确性（约 20 项指标）：回答必须正确无误的可验证陈述
• 广度与深度（约 9 项指标）：综合质量、权衡分析、可操作指导
• 呈现质量（约 6 项指标）：术语、格式、可读性
• 引用质量（约 5 项指标）：一手来源引用及可用的参考文献

指标可以带有负权重。满足负向指标意味着回答包含错误。例如，危险的医疗建议会带来大幅扣分。这些负向指标也使得模型难以通过冗长来刷分：一个自信地陈述错误内容的模型会受到惩罚。

每个回答由评判模型逐项评分，独立进行三次。我们报告了所有任务的平均归一化得分（0-100）。

DRACO 存在作者承认的局限性：它评估的是纯文本、纯英文的交互，其静态任务集可能无法完全推广到未来的深度研究应用。绝对分数还取决于评判模型的选择（论文报告不同评判者之间有 10–25 分的差异），不过系统间的相对排名保持稳定。

防止模型作弊

当我们为评审团模型提供网络搜索时，我们发现了一件令人担忧的事：它们在网上找到了 DRACO 的评分标准。虽然这是搜索词偶然导致的，而非有意作弊，但它仍然暴露了真实的污染风险。

我们通过将结果托管的位置从网络搜索和网络抓取中排除来解决这个问题，防止模型访问与基准评分标准相关的页面。OpenRouter 的 服务器工具通过使用 Exa 或 Parallel 等第三方提供商，在所有模型上普遍支持这些排除列表，因此应用它们只需一行配置更改，而无需针对每个模型打补丁。本文中的所有结果都是在排除列表生效后产生的。

如果你在运行自己的评估，同样的机制也可用：在你的工具定义中向 web_search 传入 excluded_domains，或向 web_fetch 传入 blocked_domains，以防止评审团访问特定来源。

将模型与自身融合带来显著提升

我们运行了 Opus 4.8 与自身搭档组成的双模型评审团，并由 Opus 4.8 同时担任综合器。结果：65.5%，比单独使用 Opus 4.8（58.8%）跃升 6.7 个百分点。这表明 Fusion 的提升中有相当一部分来自综合步骤本身，而不仅仅是来自组合不同的模型架构。将同一提示运行两次会产生不同的推理路径、不同的工具调用、不同的来源选择。这不足以超越一组多样化的模型，但有助于我们理解综合本身的影响。

关于我们 DRACO 实现的说明

我们仔细复现了 DRACO 论文中描述的方法，唯一例外是使用 Gemini 3.1 Pro Preview 作为评判者，而非论文所选的 Gemini 3 Pro。这意味着我们的分数无法与原始论文发表的结果直接比较。

我们希望保留促成作者选择的高人类–LLM 对齐特性，同时捕捉更新模型的辨别力。在 Gemini 3.1 Pro Preview 在该基准测试本身上得分较低后，我们用 Claude Sonnet 4.6 对评判进行了健全性检查，发现它保留了促成作者选择其作为评判者的那些特质。我们的目标是展示 Fusion 与各个模型之间的相对差异。

试试 Fusion

API：发送 "model": "openrouter/fusion" 直接调用 Fusion，或将 {"type": "openrouter:fusion"} 添加到你的 tools 数组中，让模型自行决定何时使用它。Fusion 文档

聊天室：打开 openrouter.ai/fusion，选择一个预设或构建自定义面板。

6/14 更新：发布常见问题解答

大家对 Fusion 的反响非常热烈。谢谢！我们正在审阅所有反馈、建议和错误报告。多项改进已经上线，我们将在接下来几天继续处理。以下是一些最常见问题的解答：

Fusion 是 Fable 的直接替代品吗？

不是。基准测试表明，将多个模型融合在一起可以在深度研究任务上达到并超越 Fable 级别的性能。我们只对一类任务（DRACO 深度研究）进行了基准测试，但该方法可能适用于我们尚未测试的许多其他工作流。我们很想听听你发现它在其他用例中表现良好的情况。

DRACO 也不包含长时程任务，而这正是 Fable 的强项。

我应该如何将 Fusion 用于编程？

Fusion 不是编程模型的直接替代品。相反，它让你的编程模型可以访问一个服务器工具。基础模型直接处理日常编程，并可以选择性地在值得花费更多时间和金钱来获得详尽答案的问题上调用 Fusion（例如架构决策或对最佳实践方法的研究）。模型会判断问题何时需要多个视角。

基准测试中的模型可以访问哪些工具？

每个模型，无论是在 Fusion 面板中还是单独运行，都拥有相同的三个服务器工具：

• openrouter:web_search（通过 Exa）
• openrouter:web_fetch（通过 Exa）
• openrouter:bash

在所有配置中保持工具集完全相同，确保了公平比较。Fusion 面板和单独运行之间的唯一区别在于是否综合了多个模型的输出，而不是可用工具的不同。

DeepSeek V4 Pro 的表现令人惊讶。这准确吗？

我们对 DeepSeek 的得分之高感到惊讶。它以 60.3% 的成绩与 Opus 4.8 和 GPT-5.5 表现相近。

一种假设是：如果有更大的工具调用预算，Opus 4.8 会得分更高。它似乎是一个更贪心的模型，在更多时间和更多工具使用下表现更好。相比之下，Fable 更善于明智地使用工具调用预算，并在行动前思考更长时间。基准测试固定的工具调用预算可能压缩了具有不同工具使用策略的模型之间的差距。

它慢吗？慢多少？

你发起请求的模型的表现与平时相同。只有当你的模型遇到它认为可以从使用 Fusion 中受益的问题时，响应才会变慢。当 Fusion 被调用时，它会启动一个多步骤流程，通常比标准调用长 2-3 倍。在此期间，它会将你的提示发送给多个模型，等待它们全部完成，然后处理结果以生成融合后的响应。我们这样做是为了在正常模型执行的速度与在你需要时获得超越前沿的答案之间取得平衡。

我可以通过哪些方式使用 Fusion？

使用 Fusion 有四种方式，它们都使用相同的底层逻辑：

• 聊天室。打开 openrouter.ai/fusion，选择一个预设或构建自定义面板。无需代码。
• 模型 slug。将 "model": "openrouter/fusion" 发送到我们的任意推理端点，Fusion 插件会自动注入，并带有默认的前沿模型面板。你只需替换模型字符串即可使用它。文档
• 服务器工具。将 { "type": "openrouter:fusion" } 添加到你的 tools 数组中。控制力最强：选择你希望执行融合的模型，并将 Fusion 与其他工具结合使用。你发送请求的模型将决定何时以及是否调用 Fusion。文档
• 插件。像平常一样调用 completions 或 responses，然后添加 "plugins": [{ "id": "fusion", ... }] 和你选择的面板。你在调用中指定的模型将负责融合结果。文档