OpenRouter 推 Fusion API：三模型混合逼近 Fable 5，成本僅一半

OpenRouter 於 6 月 13 日正式發表 Fusion API，讓開發者透過單一 API 呼叫，同時呼叫多個模型平行推理，再由 Judge 模型融合出最佳答案。在 DRACO 深度研究基準測試中，Fusion 以 69% 超越 Claude Fable 5 的 65.3%，而一組由 Gemini 3 Flash、Kimi K2.6 和 DeepSeek V4 Pro 組成的低成本面板更僅差不到 1%，成本卻只要一半。
（前情提要：Google 領投 AI 路由平台 OpenRouter，估值 13 億美元一年成長 240%）
（背景補充：OpenRouter 分析 100 兆 Token 研報：人類到底用 AI 做什麼、中國模型崛起與使用者留存秘密）

本文目錄

Toggle

• DRACO 基準實測：Fusion 全面超越單體王者
• 預算面板也能打：三模型合體只輸 Fable 不到 1%
• Fusion 不是 Fable 的取代品，但適用場景很明確
• 四種呼叫方式一次看懂

人氣 AI 路由平台 OpenRouter 於 6 月 13 日正式推出 Fusion API，這項全新功能允許開發者將同一問題同時派送給多個模型處理，再由一個 Judge 模型融合所有輸出、提煉出最佳答案，而且只要一個 API call 就能完成。

Fusion 的核心機制相當直觀：當使用者傳送一個 prompt，OpenRouter 會將其平行派送給一個「panel」內的數個模型（每個模型都配有 web search 與 web fetch 工具），接著 Judge 模型閱讀所有 panel 回應，產出結構化分析，包含共識點、矛盾點、部分覆蓋、獨到見解與盲點，最後由呼叫模型根據這份分析寫出最終答案。整個管線在伺服器端執行，體驗上就跟呼叫單一模型一模一樣。

DRACO 基準實測：Fusion 全面超越單體王者

OpenRouter 團隊以 Perplexity AI 的 DRACO 深度研究基準進行評測，該基準涵蓋 100 道跨 10 個領域的複雜研究任務，評分標準包含事實正確性（約 20 項）、廣度與深度（約 9 項）、呈現品質（約 6 項）及引用品質（約 5 項），且設有負權重機制，模型若給出錯誤資訊會受到懲罰。

以下是各項配置的評分結果：

• Fusion（Fable 5 + GPT-5.5 → Opus 4.8 融合）：69.0% 🥇
• Fusion（Opus 4.8 + GPT-5.5 + Gemini 3.1 Pro → Opus 4.8 融合）：68.3%
• Fusion（Opus 4.8 + GPT-5.5 → Opus 4.8 融合）：67.6%
• Fusion（Opus 4.8 融合自身）：65.5%
• Claude Fable 5 單體：65.3%（僅完成 93/100 題，因內容過濾器阻擋）
• Fusion（Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro → Opus 4.8 融合）：64.7% 🔥
• DeepSeek V4 Pro 單體：60.3%
• GPT-5.5 單體：60.0%
• Claude Opus 4.8 單體：58.8%

預算面板也能打：三模型合體只輸 Fable 不到 1%

最令市場驚豔的結果來自一組「預算面板」，Gemini 3 Flash、Kimi K2.6 和 DeepSeek V4 Pro 這三個相對便宜的模型，經 Fusion 融合後拿到 64.7%，不僅擊敗 GPT-5.5（60.0%）和 Opus 4.8（58.8%），更只差 Claude Fable 5 不到 1 個百分點，而成本僅需後者的一半。這意味著開發者可以用更低的推理成本，獲得接近頂級模型的深度研究能力。

另外一個值得注意的發現是：「自己融合自己」也有效。Opus 4.8 作為 panel 中的兩個成員（同型號兩份）再以 Opus 4.8 作為 Judge 融合，得分 65.5%，比單一 Opus 4.8（58.8%）高出 6.7 分。這顯示 Fusion 的效能提升有很大一部分來自 synthesis 步驟本身的價值，即使同一模型跑兩次，不同的推理路徑、不同的工具呼叫與來源選擇，也能帶來顯著增益。

Fusion 不是 Fable 的取代品，但適用場景很明確

OpenRouter CEO Alex Atallah 在 X 上表示，Fusion 可達到「Fable 等級的智慧，價格只要一半」。不過團隊也坦承，DRACO 基準並未包含長時間序列任務（long-horizon），而這正是 Claude Fable 5 真正的強項。對於需要多步驟推理、長時間上下文的複雜任務，Fable 短期內仍無可取代。

至於程式開發場景，Fusion 並非直接取代程式設計模型的方案。OpenRouter 將 Fusion 設計為一個 server tool，當基礎模型遇到需要深度研究的問題（如架構決策、最佳實踐研究）時，可以自動決定是否呼叫 Fusion 獲取多角度分析，日常程式碼撰寫則照舊由主模型處理。

四種呼叫方式一次看懂

開發者可透過以下四種方式使用 Fusion：

• Chatroom 試玩：直接到 openrouter.ai/fusion 選 preset 或自建 panel
• Model slug：API 中指定 "model": "openrouter/fusion"，自動帶入預設前沿面板
• Server tool：在 tools 陣列中加入 {"type": "openrouter:fusion"}，讓主模型自主決定何時呼叫
• Plugin 模式：在 API 呼叫中加入 plugins 引數，自訂 panel 模型組合

Fusion 預設面板的呼叫成本比 Fable 約低 50%，但回應時間約為標準呼叫的 2-3 倍（因需等待多模型平行推理後再融合）。OpenRouter 表示會持續根據使用者反饋改善效能。

本文源自 OpenRouter Blog，由動區動趨編譯整理。