OpenRouter 推出 Fusion 複合式推理系統

Fusion 是我們的複合模型。它接受一個提示並將其轉換為多個模型之間的簡短辯論。我們一次將您的提示傳送給一組專家模型，並由審判員比較每個回應，讓呼叫模型能寫出一個最終答案。

使用 Fusion，您會犧牲一些速度和代幣以換取品質。本頁說明 Fusion 的功能、成本、何時優於單一模型，以及何時不優於單一模型。

TL;DR

Fusion 的功能。它讓模型能使用多模型協商工具。多個模型並行回答，審判員對同意與反對進行對映，呼叫模型則撰寫最終回應。
成本。呼叫 Fusion 會產生面板和審判員的額外完成。預設的三模型面板成本大約是同一提示單個完成的四到五倍，且通常耗時兩到三倍。
何時使用。將 Fusion 作為複雜研究、專家評論以及錯誤答案會產生較高成本的決策的選擇性升級路徑。

什麼是 OpenRouter Fusion？

Fusion 是一個複合推理系統，讓模型能進行多模型協商。當模型呼叫 Fusion 時，數個模型會並行回答提示。審判員比較他們的回應並產生結構化分析，進而用於產出最終答案。

這使 Fusion 與單一模型呼叫不同。單一呼叫遵循單個模型的推理路徑，而 Fusion 能將多條推理路徑、來源選擇與解讀整合於同一回應。

Fusion 與 auto-routing 扮演不同角色。Auto‑routing 會根據提示的任務型別分類，並選擇 OpenRouter 社群在該類任務上投入最多的模型。Fusion 結合多個模型並融合其答案，能產出比任何單一面板成員更強大的回應。

Diagram of the Fusion pipeline: a prompt fans out to several panelist models with web tools in parallel, then converges through a judge that synthesizes their outputs into one final answer

OpenRouter Fusion 的工作原理

Fusion 在普通模型請求中加入一個協商迴圈。

流程包含四個階段：

呼叫模型評估提示。當您使用 the …
面板並行運作。一到八個參與模型獨立回答提示。每位面板成員可使用 OpenRouter 網路搜尋與網路抓取來尋找最新來源。
審判員比較回應。我們的檔案稱此角色為分析師。審判員辨識共識、矛盾、部分覆蓋、獨特洞見與盲點，並以結構化分析回傳。
呼叫模型撰寫答案。原始模型接收審判員的分析並用其產生回應，回傳給您的應用程式。

審判員的工作是比較，而非簡單投票。三個模型重複相同未經證實的主張並不會自動…

品質提升的來源

Fusion 受益於模型之間的多樣性以及不同執行之間的變化。不同模型可能採用不同的方法、注意不同的限制，或檢索不同的資料來源。即使是同一模型的兩次執行，也可能採用不同的推理路徑並呼叫不同的工具。

我們透過將 Claude Opus 4.8 與另一個 Opus 4.8 執行配對，並使用相同模型進行合成，測試了第二個效果。合成配置在我們的 DRACO 基準測試中取得 65.5% 的分數，與單獨 Opus 4.8 執行的 58.8% 相比。這 6.7 分的提升顯示，即使沒有模型多樣性，比較與合成流程仍能帶來實質價值。

多模型整合是一項成熟技術。Fusion 的產品價值是可運作的。您可以透過單一模型 slug 或伺服器工具加入面板、評審、工具以及合成迴圈，而無需自行構建與維護這些協調機制。

Fusion 與單一模型的比較

Fusion 能提升困難答案的品質，但它是透過執行更多工作來實現的。

品質取決於任務

在 Perplexity AI 的深度研究基準 DRACO 上，使用 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。若要逐步升級至單一更強模型，請參閱 Advisor 伺服器工具。

將其用於高風險、研究型提示，因錯誤成本高昂

研究問題、專家審查、比較與盡職調查摘要，任何地方準確性為首要，之後的修正會耗費實際時間或金錢。實務上，想像在決定策略前先從十餘個現行來源彙總競爭領域。

當你本來需要手動詢問多個模型時，使用它。

若目前工作流程是向三個模型提出同一問題並自行比較答案，Fusion 正是執行此工作。判斷器的答案比較也比人工審核更為一致。

對於延遲敏感或高 QPS 的互動路徑，請跳過。

當使用者等待回覆時，兩到三倍的延遲太長。實務上，這代表客戶聊天機器人或即時程式碼補完。

對於需要可重現性的工作負載，請跳過。

評估、回歸測試套件，以及任何需要跨執行穩定結果的專案。非確定性會使比較不可靠。實務上，指 CI 管道檢查 LLM 輸出是否變更。

對於單一中階模型已能處理的簡單、範圍明確任務，請跳過。

若一個中階模型今天已能給出正確答案，使用面板僅會增加成本與延遲而無實質收益。實務上，分類、抽取、簡短重寫與格式轉換等。

如何使用 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 documentation 以瞭解完整的請求格式，並參閱 Presets guide 以進行可重複使用的設定管理。

結論

Fusion 讓困難提示可嘗試多次，並為你的應用程式提供結構化的比較方式。這可提升研究、批判與高成本決策，當快速的首個答案不足以應對時尤為重要。

額外的審查會帶來可量化的成本。面板與判斷器會增加 tokens、成本、延遲與輸出變異。當它們能降低重試、人工比較或因不完整答案而採取錯誤行動的風險時，這些成本是合理的。

先從你實際工作負載中的一個難題起始。以每個被接受結果的成本來比較 Fusion 與你目前的模型，而非僅看模型價格。

嘗試使用 Fusion Router，或閱讀 Fusion benchmark 公告以瞭解完整的 DRACO 方法論與結果。

常見問題

OpenRouter Fusion 如何運作？

OpenRouter Fusion 允許呼叫模型將提示同時傳送給多個面板模型。評審會比較各回覆並回傳涵蓋共識、矛盾、部分覆蓋、獨特見解與盲點的結構化分析。呼叫模型利用該分析撰寫最終答案。

AI 中的模型融合是什麼？

模型融合可能指結合模型引數或結合多個模型的輸出。OpenRouter Fusion 在推理時使用輸出層的協商。它收集獨立回覆，通過評審進行比較，並將所得分析提供給撰寫最終回覆的模型。

OpenRouter Fusion 是否優於 Fable 5？

Fusion 在 Perplexity AI 的 DRACO 深度研究基準上，在多個前沿面板設定中單獨表現優於 Fable 5。預算面板得分 64.7%，Fable 5 為 65.3%，而前沿面板得分 69.0%。基於 Fable 的結果因內容過濾顯示 93/100 個任務。這些結果僅適用於深度研究，並未證明 Fusion 能取代 Fable 在長期或一般工作負載中的表現。

OpenRouter Fusion 有 API 嗎？

有。你可以使用 openrouter/fusion 模型 slug 呼叫 OpenRouter Fusion API，或將 Fusion 附加為 openrouter:fusion 伺服器工具。fusion 外掛程式為兩個入口點配置面板和評審，但不會自行啟動 Fusion 執行。兩個入口點均使用相同的底層面板、評審與最終答案流程。