OpenRouter 发布 Fusion:多模型并行辩论加裁判合成的工作原理与适用场景
OpenRouter Fusion: How It Works and When to Use It
OpenRouter 发布 Fusion,一种复合推理系统:调用模型可将提示词并行发给 1-8 个 panel 模型,judge 对比共识、矛盾与盲点后生成结构化分析,再由调用模型写出最终答案。
官方解释了 Fusion 的多模型辩论机制、成本倍数和适用边界,读者可据此判断哪些任务值得升级调用。
Fusion 是我们的复合模型。它接收一个提示词,并将其转化为多个模型之间的简短辩论。我们将你的提示词同时发送给一组专家模型,然后由一名评判者比较每个响应,以便调用模型能够写出单一的最终答案。
使用 Fusion,你是在用一定的速度和 token 换取质量。本页介绍 Fusion 的功能、成本、何时优于单一模型,以及何时不优于。
简而言之
- Fusion 的功能。 它让模型能够使用多模型审议工具。一组模型并行回答,一名评判者梳理一致与分歧,然后由调用模型撰写最终响应。
- 成本。 一次调用的 Fusion 会增加面板模型和评判者的补全。默认的三模型面板成本大约是同一提示词单次补全的四到五倍,耗时通常也是两到三倍。
- 何时使用。 将 Fusion 作为选择性升级路径,用于复杂研究、专家评审,以及错误答案造成的代价高于额外几次模型调用的决策场景。
什么是 OpenRouter Fusion?
Fusion 是一种复合推理系统,让模型能够使用多模型审议。当模型调用 Fusion 时,多个模型并行回答提示词。一名评判者比较它们的响应并生成结构化分析,随后用于生成最终答案。
这使得 Fusion 不同于单次模型调用。单次调用遵循一个模型的推理路径。Fusion 可以将多条推理路径、来源选择和解释融入同一个响应。
Fusion 和 自动路由 服务于不同的任务。自动路由通过分类提示词的任务类型,并选择 OpenRouter 社区在该类任务上花费最多的模型,为你的请求挑选一个模型。Fusion 则组合多个模型并融合它们的答案,可能产生比任何单个面板成员都更强的答案。

OpenRouter Fusion 的工作原理
Fusion 在普通模型请求内部增加了一个审议循环。
该流程有四个阶段:
- 调用模型评估提示词。 当你使用 Fusion 时,我们将别名解析为一个模型并附加 Fusion 工具。模型可以直接回答,或在任务需要更多分析时调用 Fusion。
- 面板并行工作。 一至八个参与模型独立回答提示词。每个面板成员都可以使用 OpenRouter 网页搜索和网页抓取 来查找最新来源。
- 评判者比较响应。 我们的文档称此角色为分析师。评判者识别共识、矛盾、部分覆盖、独特见解和盲点。它将该比较作为结构化分析返回。
- 调用模型撰写答案。 原始模型接收评判者的分析,并用它生成返回给你的应用的响应。
评判者的工作是比较,而非简单投票。三个模型重复同一个无依据的主张,并不会自动使该主张正确。评判者还可以突出仅出现在一个响应中的有用观点,或识别所有面板成员都遗漏的缺口。
质量提升来自哪里
Fusion 受益于模型之间的多样性和不同运行之间的差异。不同的模型可能会选择不同的方法、注意到不同的约束条件,或检索到不同的来源。即使是同一模型的两次运行,也可能遵循不同的推理路径并做出不同的工具调用。
我们通过将 Claude Opus 4.8 与另一次 Opus 4.8 运行配对,并使用同一模型进行综合,测试了第二种效应。融合配置在我们的 DRACO 基准测试运行中得分为 65.5%,而单独一次 Opus 4.8 运行得分为 58.8%。这 6.7 个百分点的提升表明,即使没有模型多样性,比较和综合过程也能贡献有意义的价值。
多模型集成是一种成熟的技术。Fusion 的产品价值在于其可操作性。你可以通过一个模型 slug 或服务器工具添加面板、评判器、工具和综合循环,而无需自己构建和维护这套编排。
Fusion 与单一模型对比
Fusion 可以改进困难问题的答案,但代价是执行更多的工作。
质量取决于任务
在 DRACO(Perplexity AI 的深度研究基准)上,使用 Gemini 3 Flash、Kimi K2.6 和 DeepSeek V4 Pro 的预算型 Fusion 面板得分约为 64.7%,而 Claude Fable 5 单独运行得分约为 65.3%。由于内容过滤器,基于 Fable 的结果反映了 100 个任务中的 93 个,因此直接比较略有不对等。
DRACO 衡量的是深度研究,而非原始编码或一般聊天。Fusion 的综合在研究和分析类提示上往往帮助最大,因为多个视角确实能让答案更精准。不要假设同样的差距会适用于所有任务。
更多 token,但每任务成本仍可能胜出
Fusion 需要为多次模型调用加上评判器付费,因此单次请求比单模型调用使用更多 token。不过,每次调用的成本并不总是关键数字。每个正确答案的成本往往更重要。
如果一次 Fusion 调用就能返回正确答案,而一个更便宜的模型需要三次尝试、一次重跑和人工检查,那么 Fusion 在整个任务上可能更便宜。要计算达成结果的总成本,而不是单次请求的价格。我们的 Fusion 模型页面 列出了当前费用。
延迟延长两到三倍
Fusion 调用通常比标准单模型调用耗时两到三倍。面板是并发运行的,因此你无需依次等待每个模型,但仍需等待最慢的面板成员,然后再等待评判器。这种延迟通常排除了聊天、自动补全和其他实时路径。
设计上就是非确定性的
面板加上综合步骤每次运行可能返回不同结果。这是有意为之。对于一次性研究任务来说没问题,但当你需要可重复的输出时,比如评估套件、回归测试,或任何将今天的结果与昨天进行比较的检查,这就会成为问题。
何时使用 Fusion,何时跳过
最强大的生产模式是选择性升级。让模型直接处理常规工作,仅对少数需要额外审查的提示调用 Fusion。若需逐步升级到单个更强的模型,请参阅 Advisor 服务器工具。
用于高风险、研究型提示,即出错代价高昂的场景
研究问题、专家评审、对比分析以及尽职调查摘要,凡是准确性优先、事后更正会耗费真实时间或金钱的场景都适用。实践中,可以想想在决定召开战略会议之前,从十几个当前来源中总结一个竞争领域的情况。
当你本来要手动轮询多个模型时使用它
如果你当前的工作流程是向三个模型提出同一个问题并自己比较答案,Fusion 做的正是这件事。评判器比较答案的方式也比人工审查更一致。
对延迟敏感或高 QPS 的交互路径跳过它
当用户在等待响应时,两到三倍的延迟太长了。实践中,这意味着客户聊天机器人或内联代码补全。
对可复现性敏感的工作负载跳过它
评估、回归测试套件,以及任何需要跨运行稳定结果的任务。非确定性会让这些比较变得不可靠。实践中,比如检查 LLM 输出是否发生变化的 CI 流水线。
对单个中端模型已能处理的简单、范围明确的任务跳过它
如果今天一个中端模型就能返回正确答案,那么一个模型小组只会增加成本和延迟,没有实际收益。实践中,比如分类、抽取、短改写和格式转换。
如何使用 OpenRouter Fusion
你可以在 Web 界面中测试 Fusion,或通过任何支持的推理端点调用它。
无代码路径
打开 Fusion lab,选择一个预设,然后输入一个能从多视角中获益的提示词。
从一个你已经知道很难的提示词开始。将融合后的结果与你当前生产模型的答案进行比较。留意事实错误是否更少、覆盖面是否更广、分歧处理是否更清晰,或人工编辑是否更少。
该界面还允许你在将配置移入应用程序之前构建自定义模型小组。
Fusion API
最简单的 API 路径是将你当前的模型 slug 替换为 openrouter/fusion。无需额外配置,Fusion 会使用默认的 Quality 模型小组,并让模型自行决定是否需要进行审议。
下面的示例选择 general-budget 预设,覆盖其评判模型,并强制 Fusion 运行:
import os
from openai import OpenAI
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key=os.environ["OPENROUTER_API_KEY"],
)
response = client.chat.completions.create(
model="openrouter/fusion",
messages=[{
"role": "user",
"content": "Compare three approaches to multi-tenant data isolation.",
}],
tool_choice="required",
extra_body={
"plugins": [{
"id": "fusion",
"preset": "general-budget",
"model": "~openai/gpt-latest",
}]
},
)
print(response.choices[0].message.content)该预设选择一个精心策划的模型小组。嵌套的 model 字段选择评判器,并且当你使用 Fusion 模型别名时,也选择撰写最终响应的模型。显式的 analysis_models 或 model 值会覆盖相应的预设设置。tool_choice: "required" 强制模型调用 Fusion,而不是让它自行决定。
目前可用的通用预设包括:
general-high用于最强的全能模型小组general-budget用于更便宜的模型小组成员搭配前沿评判器general-fast用于围绕相似响应时间优化的模型小组
你也可以将 openrouter:fusion 服务器工具 附加到你自己的外层模型上。当同一个模型需要在应用程序的其他工具之外访问 Fusion 时,这条路径很有用。
完整的请求格式请参阅 Fusion Router 文档,可复用配置管理请参阅 Presets 指南。
结论
Fusion 让困难的提示词获得不止一次尝试,并为你的应用程序提供了一种结构化方式来比较这些尝试。这可以改善研究、评审和高成本决策,在这些场景中,快速的第一个答案是不够的。
额外的审查有可衡量的代价。模型小组和评判器会增加 token、成本、延迟和输出方差。当这些成本能减少重试、人工比较或基于不完整答案行动的风险时,它们就是合理的。
从你真实工作负载中的一个高难度提示词开始。用每个被接受结果的成本来比较 Fusion 与你当前的模型,而不是只看模型价格。
通过 Fusion Router 试用,或阅读 Fusion 基准测试公告 了解完整的 DRACO 方法论和结果。
常见问题
OpenRouter Fusion 是如何工作的?
OpenRouter Fusion 让调用模型将提示词并行发送给多个面板模型。一个评判模型会比较这些响应,并返回结构化分析,涵盖共识、矛盾、部分覆盖、独特见解和盲点。调用模型利用该分析来撰写最终答案。
AI 中的模型融合是什么?
模型融合可以指合并模型参数,或合并多个模型的输出。OpenRouter Fusion 在推理过程中使用输出级审议。它收集独立响应,通过评判模型进行比较,并将得到的分析交给撰写最终响应的模型。
OpenRouter Fusion 比 Fable 5 更好吗?
在 Perplexity AI 的 DRACO 深度研究基准测试中,Fusion 在若干前沿面板配置下表现优于单独的 Fable 5。一个预算面板得分为 64.7%,而 Fable 5 为 65.3%,而一个前沿面板得分为 69.0%。由于内容过滤器,基于 Fable 的结果反映了 100 个任务中的 93 个。这些结果适用于深度研究,并不能证明 Fusion 在长周期或通用工作负载中可以取代 Fable。
OpenRouter Fusion 有 API 吗?
有。你可以使用 openrouter/fusion 模型 slug 调用 OpenRouter Fusion API,或将 Fusion 作为 openrouter:fusion 服务器工具附加。fusion 插件为任一入口点配置面板和评判模型,但本身不会启动 Fusion 运行。两个入口点使用相同的底层面板、评判模型和最终答案流水线。
来源:OpenRouter:Announcements(RSS) · openrouter.ai