OpenRouter融合预算模型面板超越GPT-5.5和Claude Opus 4.8

我们发现，将多个模型的结果综合起来，可以显著超越单个模型所能达到的水平。隆重推出 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 等第三方提供商，在所有模型上普遍支持这些排除列表，因此应用它们只需修改一行配置，而无需针对每个模型逐一打补丁。本文中的所有结果都是在排除列表生效之后产生的。

如果你在运行自己的评测，同样的机制也可用：传入excluded_domains给 web_search 或blocked_domains给 web_fetch，在你的工具定义中以阻止该面板访问特定来源。

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

我们将 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 的反响非常热烈。谢谢大家！我们正在审阅所有的反馈、建议和 bug 报告。若干改进已经上线，我们将在接下来几天继续处理。以下是我们收到的一些最常见问题的解答：

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", ... }] 并附上你选定的面板。你在调用中指定的模型将负责融合结果。文档