Fusion 是我们的复合模型。它接收一个提示词，并将其转化为多个模型之间的一场简短辩论。我们会把你的提示词同时发送给一组专家模型，由一名评判者比较每一个回答，从而让调用模型写出单一的最终答案。
使用 Fusion，你是用一定的速度和 token 换取质量。本页介绍 Fusion 能做什么、成本是多少、何时它优于单一模型，以及何时并非如此。
简而言之
- Fusion 能做什么。它让模型能够使用一个多模型审议工具。一组模型并行作答，一名评判者梳理出其中的一致与分歧，随后调用模型写出最终回答。
- 成本是多少。一次调用 Fusion 会增加专家组的回答和评判者的回答。默认的三模型专家组成本大约是同一提示词单次回答的四到五倍，耗时通常也是两到三倍。
- 何时使用它。将 Fusion 用作一种有选择性的升级路径，适用于复杂研究、专家评审，以及错误答案造成的代价高于额外几次模型调用的决策场景。
什么是 OpenRouter Fusion？
Fusion 是一种复合推理系统，让模型能够进行多模型审议。当模型调用 Fusion 时，多个模型会并行回答提示词。一个评判模型会比较它们的回答并生成结构化分析，随后用于生成最终答案。
这使得 Fusion 不同于单次模型调用。单次调用遵循一个模型的推理路径。Fusion 则可以将多条推理路径、来源选择和解读融入同一个回答中。
Fusion 和 自动路由承担不同的任务。自动路由通过分类提示词的任务类型，并选择 OpenRouter 社区在该类任务上花费最多的模型，为你的请求挑选一个模型。Fusion 则组合多个模型并融合它们的答案，能够产生比任何单个参与模型都更强的回答。
OpenRouter Fusion 的工作原理
Fusion 在普通模型请求内部加入了一个审议循环。
该流水线包含四个阶段：
- 调用模型评估提示词。当你使用 Fusion 时，我们会将该别名解析为一个模型并附加 Fusion 工具。模型可以直接回答，也可以在任务需要更多分析时调用 Fusion。
- 该小组并行工作。 一到八个参与模型独立回答提示词。每个小组成员都可以使用 OpenRouter 网页搜索和网页抓取来查找最新来源。
- 评判模型对回答进行比较。 我们的文档将这一角色称为分析师。评判模型识别共识、矛盾、部分覆盖、独特见解和盲点。它将这些比较结果以结构化分析的形式返回。
- 调用模型撰写答案。 原始模型接收评判模型的分析，并据此生成返回给您的应用程序的回复。
评判模型的职责是比较，而非简单的投票。三个模型重复同一个没有依据的说法，并不会自动使该说法变得正确。评判模型还可以揭示仅出现在一个回答中的有用观点，或识别出所有小组成员都遗漏的空白。
质量提升从何而来
融合受益于模型之间的多样性和不同运行之间的差异。不同的模型可能选择不同的方法、注意到不同的约束条件，或检索到不同的来源。即使是同一模型的两次运行，也可能遵循不同的推理路径并做出不同的工具调用。
我们通过将 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 的交互路径，请跳过它
当用户在等待响应时，两到三倍的延迟太长了。在实践中，这意味着客服聊天机器人或行内代码补全。
对可复现性敏感的工作负载，请跳过它
评估、回归测试套件，以及任何需要在多次运行间获得稳定结果的任务。非确定性会让这些比较变得不可靠。在实践中，就是一条检查大语言模型输出是否发生变化的 CI 流水线。
对于单个中端模型就能处理的简单、范围明确的任务，跳过它。
如果单个中端模型今天就能返回正确答案，那么一个模型组合只会增加成本和延迟，却没有任何实际收益。在实践中，就是分类、抽取、短文本改写和格式转换。
如何使用 OpenRouter Fusion
你可以在网页界面中测试 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 文档，可复用配置管理请参阅 预设指南。
结论
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 运行。两种入口使用相同的底层面板、评判模型和最终答案流水线。
Fusion is our compound model. It takes one prompt and turns it into a short debate among several models. We send your prompt to a panel of expert models at once, and a judge compares every response so the calling model can write a single final answer.
With Fusion, you trade some speed and tokens for quality. This page covers what Fusion does, what it costs, when it beats a single model, and when it doesn’t.
Tl;dr
- What Fusion does. It gives a model access to a multi-model deliberation tool. A panel answers in parallel, a judge maps agreement and disagreement, and the calling model writes the final response.
- What it costs. An invoked Fusion call adds panel and judge completions. The default three-model panel costs roughly four to five times as much as one completion on the same prompt and often takes two to three times longer.
- When to use it. Use Fusion as a selective escalation path for complex research, expert critique, and decisions where an incorrect answer creates more cost than a few additional model calls.
What is OpenRouter Fusion?
Fusion is a compound inference system that gives a model access to multi-model deliberation. When the model invokes Fusion, several models answer the prompt in parallel. A judge compares their responses and produces structured analysis, which is then used to produce the final answer.
That makes Fusion different from a single model call. A single call follows one model’s reasoning path. Fusion can bring several reasoning paths, source selections, and interpretations into the same response.
Fusion and auto-routing serve different jobs. Auto-routing picks one model for your request by classifying the prompt’s task type and choosing the model the OpenRouter community spends the most on for that kind of task. Fusion combines many models and blends their answers, and it can produce a stronger answer than any single panelist would give.
How OpenRouter Fusion works
Fusion adds a deliberation loop inside a normal model request.
The pipeline has four stages:
- The calling model evaluates the prompt. When you use Fusion, we resolve the alias to a model and attach the Fusion tool. The model can answer directly or invoke Fusion when the task warrants more analysis.
- The panel works in parallel. Between one and eight participant models independently answer the prompt. Each panelist can use OpenRouter web search and web fetch to find current sources.
- The judge compares the responses. Our docs call this role the analyst. The judge identifies consensus, contradictions, partial coverage, unique insights, and blind spots. It returns that comparison as structured analysis.
- The calling model writes the answer. The original model receives the judge’s analysis and uses it to produce the response returned to your application.
The judge’s job is comparison rather than simple voting. Three models repeating the same unsupported claim don’t automatically make that claim correct. The judge can also surface a useful point that appears in only one response or identify a gap that every panelist missed.
Where the quality gain comes from
Fusion benefits from diversity between models and variation between separate runs. Different models may choose different methods, notice different constraints, or retrieve different sources. Even two runs of the same model can follow different reasoning paths and make different tool calls.
We tested that second effect by pairing Claude Opus 4.8 with another Opus 4.8 run and using the same model for synthesis. The fused configuration scored 65.5% on our DRACO benchmark run, compared with 58.8% for a solo Opus 4.8 run. That 6.7-point improvement suggests that the comparison and synthesis process contributes meaningful value even without model diversity.
Multi-model ensembling is an established technique. Fusion’s product value is operational. You can add a panel, judge, tools, and synthesis loop through one model slug or server tool instead of building and maintaining that orchestration yourself.
Fusion vs. a single model
Fusion can improve difficult answers, but it does so by performing more work.
Quality depends on the task
On DRACO, a deep-research benchmark by Perplexity AI, a budget Fusion panel using Gemini 3 Flash, Kimi K2.6, and DeepSeek V4 Pro scored roughly 64.7% against about 65.3% for Claude Fable 5 on its own. Fable-based results reflect 93 of 100 tasks because of content filters, so direct comparisons are slightly uneven.
DRACO measures deep research, not raw coding or general chat. Fusion’s synthesis tends to help most on research and analysis prompts, where several viewpoints genuinely sharpen the answer. Don’t assume the same margin carries to every task.
More tokens, but cost per task can still win
Fusion pays for several model calls plus the judge, so a single request uses more tokens than a single-model call. Cost per call isn’t always the number that matters, though. Cost per correct answer often matters more.
If one Fusion call returns the right answer while a cheaper model needs three attempts, a rerun, and a human to check it, Fusion can come out cheaper across the whole task. Count the total cost of reaching the result, not the price of one request. Our Fusion model page has current costs.
Latency runs two to three times longer
Fusion calls often take two to three times as long as a standard single-model call. The panel runs concurrently, so you’re not waiting on each model in sequence, but you still wait for the slowest panelist and then for the judge. That delay usually rules out chat, autocomplete, and other real-time paths.
Non-deterministic by design
A panel plus a synthesis step can return different results run to run. That’s by design. It’s fine for a one-off research task, but it becomes a problem when you need repeatable output, like evaluation suites, regression tests, or any check that compares today’s result against yesterday’s.
When to use Fusion and when to skip it
The strongest production pattern is selective escalation. Let a model handle routine work directly and invoke Fusion for the smaller set of prompts that deserve additional scrutiny. For per-step escalation to a single stronger model, see the Advisor server tool.
Use it for high-stakes, research-style prompts where being wrong is expensive
Research questions, expert review, comparisons, and due-diligence summaries, anywhere accuracy is the priority and a later correction costs real time or money. In practice, think of summarizing a competitive field from a dozen current sources before you commit to a strategy call.
Use it when you’d otherwise poll several models by hand
If your current workflow is asking three models the same question and comparing the answers yourself, Fusion is doing exactly that job. The judge also compares answers more consistently than a manual review.
Skip it for latency-sensitive or high-QPS interactive paths
When a user is waiting for a response, the two-to-three-times latency is too long. In practice, this means a customer chatbot or inline code completion.
Skip it for reproducibility-sensitive workloads
Evals, regression suites, and anything that needs stable results across runs. Non-determinism makes those comparisons unreliable. In practice, a CI pipeline that checks whether an LLM’s output changed.
Skip it for simple, well-scoped tasks a single mid-tier model already handles
If one mid-tier model returns correct answers today, a panel just adds cost and delay for no real gain. In practice, classification, extraction, short rewrites, and format conversion.
How to use OpenRouter Fusion
You can test Fusion in the web interface or call it through any supported inference endpoint.
The no-code path
Open the Fusion lab, select a preset, and enter a prompt that benefits from multiple perspectives.
Start with a prompt you already know is difficult. Compare the fused result with the answer from your current production model. Look for fewer factual errors, broader coverage, clearer disagreement handling, or less human editing.
The interface also lets you build a custom panel before moving the configuration into your application.
The Fusion API
The simplest API path is to replace your current model slug with openrouter/fusion. With no additional configuration, Fusion uses the default Quality panel and lets the model decide whether deliberation is necessary.
The example below selects the general-budget preset, overrides its judge model, and requires Fusion to run:
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)The preset chooses a curated panel. The nested model field selects the judge and, when you use the Fusion model alias, the model that writes the final response. Explicit analysis_models or model values override the corresponding preset settings. tool_choice: "required" forces the model to invoke Fusion instead of letting it decide.
The available general-purpose presets currently include:
general-highfor the strongest all-around panelgeneral-budgetfor cheaper panelists with a frontier judgegeneral-fastfor a panel optimized around similar response times
You can also attach the openrouter:fusion server tool to your own outer model. That path is useful when the same model needs access to Fusion alongside your application’s other tools.
See the Fusion Router documentation for the full request formats and the Presets guide for reusable configuration management.
Conclusion
Fusion gives difficult prompts more than one attempt and gives your application a structured way to compare those attempts. That can improve research, critique, and high-cost decisions where a fast first answer isn’t enough.
The additional scrutiny has a measurable price. The panel and judge add tokens, cost, latency, and output variance. Those costs are justified when they reduce retries, manual comparison, or the risk of acting on an incomplete answer.
Start with one hard prompt from your real workload. Compare Fusion with your current model using cost per accepted result, not model price alone.
Try it with the Fusion Router, or read the Fusion benchmark announcement for the full DRACO methodology and results.
Frequently asked questions
How does OpenRouter Fusion work?
OpenRouter Fusion lets a calling model send a prompt to several panel models in parallel. A judge compares the responses and returns structured analysis covering consensus, contradictions, partial coverage, unique insights, and blind spots. The calling model uses that analysis to write the final answer.
What is model fusion in AI?
Model fusion can refer to combining model parameters or combining outputs from several models. OpenRouter Fusion uses output-level deliberation during inference. It gathers independent responses, compares them through a judge, and gives the resulting analysis to the model that writes the final response.
Is OpenRouter Fusion better than Fable 5?
Fusion outperformed Fable 5 on its own in several frontier-panel configurations on the DRACO deep-research benchmark by Perplexity AI. A budget panel scored 64.7%, compared with Fable 5 at 65.3%, while a frontier panel scored 69.0%. Fable-based results reflect 93 of 100 tasks because of content filters. These results apply to deep research and don’t establish that Fusion replaces Fable across long-horizon or general workloads.
Does OpenRouter Fusion have an API?
Yes. You can call the OpenRouter Fusion API with the openrouter/fusion model slug or attach Fusion as an openrouter:fusion server tool. The fusion plugin configures the panel and judge for either entry point but does not start a Fusion run on its own. Both entry points use the same underlying panel, judge, and final-answer pipeline.