摘要： 採預設的三模型面板，成本大約是單一模型呼叫的 4 到 5 倍，延遲通常落在 2 到 3 倍。 但這層額外的審查有其可量化的代價：更多 token、成本、延遲以及輸出變異。 務實的做法是挑一個你已知困難的真實 prompt，讓 Fusion 與目前生產用的模型各跑一遍，並以「每個被接受的結果的成本」來衡量，而不是只單看模型單價。
單一 prompt 交給多個模型互相辯論
OpenRouter 在 2026 年 9 月 10 日推出 Fusion，一套複合推論系統。同一個 prompt 會同時發派給數個模型各自作答，接著由裁判把這些回應放在一起比對，最後交由呼叫端的模型根據這份分析寫出答案。這裡的機制不是投票取多數，而是一種有結構的對照：裁判會指出哪些地方彼此同意、哪裡互相衝突、哪些只被部分涵蓋、有哪些獨到看法，以及整體忽略了什麼。
對做產品開發的人來說，Fusion 的價值在於把原本得自己動手寫的協調流程，收進一個 model slug 或 server tool 裡。直接呼叫 openrouter/fusion 就行，面板、裁判與合成迴圈都不必自己養。
品質提升從哪裡來
Fusion 的品質增益有兩個來源：不同模型之間的差異，以及同一個模型重複執行所產生的變異。OpenRouter 的實測把 Claude Opus 4.8 與自己配成一組，融合後的 DRACO 分數由 58.8% 上升到 65.5%，等於多出 6.7 個百分點。由此可見，光是比較與合成這件事本身就帶來價值，未必要湊齊不同的模型。
不過 DRACO 是 Perplexity AI 的深度研究基準，並不代表通用的 coding 或聊天場景。Fusion 的合成效果在需要匯集多方觀點的研究與分析任務上最突出；別把同樣的增益直接套到所有任務上。
成本與延遲的實際代價
採預設的三模型面板，成本大約是單一模型呼叫的 4 到 5 倍，延遲通常落在 2 到 3 倍。面板是平行跑的，所以不必一個模型接一個模型等，但最慢的那位 panelist 再加上裁判的時間仍要算進去。也因為如此，Fusion 不適合放在聊天、自動完成這類即時路徑上。
評估成本時不能只看單次呼叫。假如一次 Fusion 呼叫就拿到正確答案，而便宜模型得試三次、重跑一回、再找人檢查，那麼把整個任務攤開來算，Fusion 反而可能更省。關鍵在於計算「達到結果的總成本」，而不是單一請求的價格。
什麼時候該用，什麼時候該跳過
生產環境中最有效的做法是選擇性升級：讓模型自己處理日常任務，只把少數需要額外審查的 prompt 交給 Fusion。這和 把測試證據放進開發流程 提到的「把驗證放在關鍵節點」是同一種思路。
該用的情況包括：高風險的研究問題、專家評論、比較與盡職調查摘要，以及你本來就會手動問過多個模型再自行比對的工作。該跳過的情況則有：對延遲敏感的互動路徑、需要可重現結果的評估或迴歸測試，以及單一中階模型就能正確處理的簡單任務。
Fusion 的輸出帶有非確定性，這是刻意的設計。用在一次性的研究任務上沒有問題，但碰上 CI 管線，或任何要把今天與昨天的結果拿來對照的檢查，就會變得很麻煩。
實際接入方式
最省事的 API 做法，就是把 model slug 換成 openrouter/fusion。在沒有其他設定的情況下，它會採用預設的 Quality 面板，並由模型自行判斷這個請求是否需要辯論。想強制啟動 Fusion，也可以設 tool_choice: "required"。
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)目前提供三個通用 preset：general-high 最強、general-budget 以較便宜的 panelist 搭配 frontier 裁判、general-fast 則針對相近的回應時間做最佳化。另一個選擇是把 openrouter:fusion server tool 掛在自己的 outer model 上，這樣同一個模型就能同時取用 Fusion 與應用程式的其他工具。
從一個困難 prompt 開始驗證
面對困難的 prompt，Fusion 會給出多次嘗試，並附上有結構的比較方式。但這層額外的審查有其可量化的代價：更多 token、成本、延遲以及輸出變異。唯有在能減少重試、省下手動比較，或降低依據不完整答案行事的風險時，這些代價才划得來。
務實的做法是挑一個你已知困難的真實 prompt，讓 Fusion 與目前生產用的模型各跑一遍，並以「每個被接受的結果的成本」來衡量，而不是只單看模型單價。