OpenRouter Fusion API：多模型合成以提升效能

OpenRouter 推出了 Fusion API，一個將單一使用者請求同時路由至多個 LLM，並使用評判模型將這些回應合成為最終高效能答案的系統。此方法旨在透過平行測試時運算，超越前沿模型的效能。

效能提升與取捨

Fusion 的主要價值主張是能在深度研究與複雜推理任務上提升效能。根據 OpenRouter 的基準測試，API 提供兩種主要預設：

  • 預算預設： 使用三個較便宜的模型，效能大致相當於「Fable」模型，且成本僅為 Fable 的一半。
  • 品質預設： 使用三個較昂貴的模型，效能超過 Fable，然而成本是其兩倍。

然而，這些提升伴隨著顯著的營運取捨。使用者的質性評估顯示，Fusion 的速度可能慢至原本單一前沿模型（如 GPT‑5.5 或 Claude Opus 4.7）呼叫的 7 倍，且成本高出 4 倍。因此，Fusion 更適合作為「只有在需要時才使用」的高風險任務工具，而非單模型推論的通用替代方案。

測試時運算的角色

OpenRouter 的資料顯示，一個模型自行融合（例如同時執行多個 Claude Opus 4.8 實例）即可提升效能。這暗示提升的主要驅動力不一定是模型架構的多樣性，而是總測試時運算量的增加。

社群討論中也出現了關於多模型共識是否真的具備加成效果的爭論。部分開發者認為，因為前沿模型多在相似資料集上訓練，可能形成「回音室」，提供的只是統計噪聲而非真正的智識多樣性。另一些人則認為，只要提升單一模型的 temperature，產生多個候選答案，也能達到相同效果。

替代實作策略

社群中有多位開發者實作了類似「聯盟」或「集成」的模式，以優化結果：

  • 專家角色（Expert Personas）： 不僅將相同提示發送給多個模型，而是事先為每個實例設定特定的專業角色，迫使其提供不同的智識觀點，形成真正的辯論。
  • 多輪審查（Multi‑Round Review）： 實作模型之間的交叉審查輪次，雖然會導致 token 使用量激增。
  • 排序與合成（Rank‑and‑Synthesize）： 為了控制成本，先使用快速、廉價的模型（如 Mercury‑2）對候選回應池進行排序，然後再讓較大的模型完成最終合成。

實務應用案例

雖然一般聊天可能無法從 Fusion 中受益，但以下高 token 效率的任務非常適合此方法：

  • 架構審查（Architectural Review）： 在編碼前分析 markdown 規格的缺口，因為多次 LLM 呼叫的成本相較於遺漏需求的價值可忽略不計。
  • 複雜程式碼稽核（Complex Code Audits）： 使用一群代理人檢查檔案的架構問題，透過輪流回應與反駁，彙整最終的發現報告。
  • 平行策略測試（Parallel Strategy Testing）： 同時執行不同的代理策略，並由評判模型審查其變異，以發掘單一路徑可能錯過的洞見。

摘要：OpenRouter Fusion API 透過評判模型同時合成多個 LLM 的回應，在複雜任務上提升效能，但會帶來較高的延遲與成本。

標題：OpenRouter Fusion API：多模型合成以提升效能

Sources