vLLM 語意路由器 Fusion 原語實現可程式化的多模型服務

TL;DR

vLLM 發佈了其語意路由器的 Fusion 原語，使生產系統能夠運行協調的異質模型面板、評估它們的輸出，並在路由器內部保留政策、配置與追蹤的同時合成單一回應。這使得模型混合成為一種一等的、可程式化的服務模式，而不再是臨時的實驗。

超越單一模型的需求

傳統的服務只問 哪一個單一模型應該處理請求？ 現代 AI 應用現在需要一組模型——快速且便宜的模型、私有本地模型、專業推理模型，以及外部供應商的 API。營運者必須決定何時請求能由單一模型滿足，何時應觸發協調的多模型工作流程，以符合成本、延遲、隱私與安全政策。

Fusion 作為路由器原語

Fusion 被引入為 路由演算法，而非全域端點。它由路由器的訊號‑決策層觸發，並遵循清晰的流程：

訊號提取 – 請求會被標註領域、複雜度、安全性等資訊。
決策制定 – 路由器根據這些訊號選擇普通路由或 Fusion 路由。
Fusion 入口 – 使用 model: "vllm-sr/fusion" 只會匹配具備 Fusion 能力的決策。
面板執行 – 一組 分析模型 同時產生獨立的候選答案。
評判 – 一個 評判模型 評估共識、矛盾、缺口與獨特見解。
合成 – 評判（或獨立的合成模型）產生單一面向使用者的回應，並可選擇發出相容 OpenAI 的 tool_calls。
追蹤 – 路由器記錄執行了哪些模型、失敗情況、代幣使用量以及結構化分析，以供除錯與核算。

此設計使每個階段皆為明確且可觀測，允許營運者為每個決策配置面板組成、錯誤處理 (on_error: skip 與 fail)、併發限制與執行時參數。

入口路徑與政策控制

入口路徑	行為
`model: "vllm-sr/auto"`	執行完整的訊號/決策邏輯；只有當所選決策的 `algorithm.type` 為 `fusion` 時才會執行 Fusion。
`model: "vllm-sr/fusion"`	仍會提取訊號，但只考慮具備 Fusion 能力的決策；若無匹配則返回明確錯誤。
Request plugin `{"id": "fusion", ...}`	為單一請求覆寫面板、評判與執行時參數，即使沒有匹配的決策也能建立範圍限定的 Fusion 執行。

此分離讓營運者能將 Fusion 保持為可選且受成本控制的功能，而非每個請求的預設。

來自 OpenRouter 的證據

OpenRouter 最近的 Fusion 發布（DRACO 基準測試）顯示，多樣模型的面板可超越最強單一模型。他們報告的分數包括：

配置	DRACO 分數
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%
單模型 Claude Fable 5	65.3%
單模型 DeepSeek V4 Pro	60.3%

預算面板的行列說明，混合較便宜的模型可以彌補單一低成本模型失去的品質——正是路由器應該管理的取捨。

詳細的 Fusion 工作流程

解析政策 – 合併決策層級的 Fusion 設定與任何請求層級的覆寫。
保護路由器 – Fusion slug 不能作為面板或評判模型，以防止遞迴的 Fusion 呼叫。
執行面板 – 所有分析模型同時被呼叫，遵守 max_concurrent。
處理失敗 – on_error: skip 繼續執行剩餘模型；on_error: fail 立即中止。
評判分析 – 評判返回結構化的 JSON，描述共識、矛盾、部分覆蓋、獨特見解與盲點。
合成或工具呼叫 – 最後一步產生純文字答案或相容 OpenAI 的 tool_calls 回應。
返回追蹤 – 回應負載可包含完整的 Fusion 追蹤、中間面板輸出、失敗紀錄與彙總的代幣使用量。

由於追蹤是明確的，營運者可以除錯路由決策、監控成本，並根據實際的分歧模式改進政策。

Fusion 是決策，而非預設

Fusion 會增加延遲與代幣成本，因此路由器必須決定何時值得使用。使用 vllm-sr/auto 時，路由器會評估訊號（例如請求複雜度、領域、租戶政策），僅在高風險或高價值的查詢中選擇 Fusion 決策。簡單的提示仍會使用快速的單模型路由。明確的 vllm-sr/fusion 別名讓客戶端在需要額外觀點時強制使用 Fusion。

API 呼叫範例

讓路由器自行選擇

{
  "model": "vllm-sr/auto",
  "messages": [{"role": "user", "content": "What are the strongest arguments for and against carbon taxes?"}]
}

如果匹配的決策指定 algorithm.type: fusion，請求將走 Fusion 流程；否則使用選定的單模型。

強制使用 Fusion

{
  "model": "vllm-sr/fusion",
  "messages": [{"role": "user", "content": "What are the strongest arguments for and against carbon taxes?"}]
}

只會考慮具備 Fusion 能力的決策；若無匹配則返回明確錯誤。

為單次呼叫覆寫面板

{
  "model": "vllm-sr/fusion",
  "messages": [{"role": "user", "content": "..."}],
  "plugins": [{
    "id": "fusion",
    "model": "google/gemini-3-flash-preview",
    "analysis_models": [
      "google/gemini-3-flash-preview",
      "moonshotai/kimi-k2.6",
      "deepseek/deepseek-v4-pro"
    ]
  }]
}

此覆寫僅限於本次請求，且不會修改全域路由設定。

Agent 迴圈中的 Fusion

Fusion 可與相容 OpenAI 的工具呼叫一起使用。面板模型會收到對話歷史，但不會看到 tools 或 tool_choice。只有最終的評判才能發出 tool_calls。

{
  "model": "vllm-sr/fusion",
  "messages": [{"role": "user", "content": "Find the latest benchmark result and explain whether it changes our launch plan."}],
  "tools": [{
    "type": "function",
    "function": {"name": "web_search", "parameters": {"type": "object", "properties": {"query": {"type": "string"}}, "required": ["query"]}}
  }],
  "tool_choice": "auto"
}

面板產生分析；評判決定是直接回答還是返回 tool_calls 負載。

設定布局

全域執行時設定僅註冊入口別名：

global:
  router:
    auto_model_names:
      - vllm-sr/auto
      - auto
      - MoM

Fusion slug 於 looper 整合下註冊：

global:
  integrations:
    looper:
      fusion:
        model_names:
          - vllm-sr/fusion

每個決策的路由設定保存實際的 Fusion 政策：

routing:
  decisions:
    - name: deep-research-fusion
      description: Use model diversity for research prompts with high synthesis risk.
      rules:
        operator: AND
        conditions:
          - type: domain
            name: research
          - type: complexity
            name: needs_reasoning:hard
      algorithm:
        type: fusion
        fusion:
          model: google/gemini-3-flash-preview
          analysis_models:
            - google/gemini-3-flash-preview
            - moonshotai/kimi-k2.6
            - deepseek/deepseek-v4-pro
          max_concurrent: 3
          on_error: skip

此分離讓全域狀態保持最小，同時允許細粒度、工作負載特定的 Fusion 政策。

未來方向

OpenRouter 的 DRACO 結果激發了在 vLLM‑SR 中系統性評估 Fusion 的動機：

大規模公共基準測試，超越簡易測試。
比較 Fusion、ReMoM、AutoMix、Router‑R1 與單模型基線。
分析預算面板與前沿模型面板的差異。
加強追蹤診斷，以檢測分歧、覆蓋缺口與評判行為。
政策研究延遲‑成本的取捨，以決定何時需要 Fusion。

整體願景很明確：最佳答案將越來越來自由可程式化路由器協調的 模型系統，而非最大的單一檢查點。vLLM‑SR 的 Fusion 原語使該系統可觀測、可配置且適合生產環境。

參考資料

OpenRouter Fusion launch: https://openrouter.ai/blog/announcements/fusion-beats-frontier/
Mixture‑of‑Models on AMD GPUs: https://vllm.ai/2026/01/23/mom-on-amd-gpu.html
DRACO benchmark paper: https://ar5iv.labs.arxiv.org/html/2602.11685

摘要: vLLM 為其語意路由器引入了 Fusion 原語，使可程式化的多模型面板、評判與合成成為一等的服務模式。

標題: vLLM 語意路由器 Fusion 原語實現可程式化的多模型服務

vLLM 語意路由器 Fusion 原語實現可程式化的多模型服務

vLLM 語意路由器 Fusion 原語實現可程式化的多模型服務

TL;DR

超越單一模型的需求

Fusion 作為路由器原語

入口路徑與政策控制

來自 OpenRouter 的證據

詳細的 Fusion 工作流程

Fusion 是決策，而非預設

API 呼叫範例

讓路由器自行選擇

強制使用 Fusion

為單次呼叫覆寫面板

Agent 迴圈中的 Fusion

設定布局

未來方向

參考資料

Sources