# 影片筆記：便宜模型组合打败 Fable 5？Fugu 和 Fusion 的编排秘密

## 一句話總結

影片解析了 Sakana AI 的 **Fugu** 與 OpenRouter 的 **Fusion** 兩種多模型編排方案，指出在地緣政治風險（如出口管制）與單一模型依賴的背景下，通過「學習式協調」與「結構化合成」的分工協作，低成本模型組合能在工程與深度研究任務上超越單一閉源巨獸（如 Fable 5），成為新的性能擴展與風險對沖路線。

## 核心重點

1.  **市場痛點與背景**：
    *   美國政府對 Anthropic 的 **Fable 5** 和 **Mythos 5** 實施出口管制，暴露了企業將身家性命綁定在單一閉源模型上的風險。
    *   市場需求從追求單一超級大腦轉向「模型團隊」與風險對沖（AI 主權）。

2.  **Fugu (Sakana AI)：學習式協調**
    *   **架構**：基於僅 0.6B 參數的輕量級協調器，採用進化策略（sep-CMA-ES）與強化學習組合。
    *   **機制**：動態調度其他大模型，進行角色分配（Thinker/Worker/Verifier）。
    *   **表現**：在代碼審查、論文復現等工程任務（SWE Bench Pro 等）中，**Fugu Ultra** 表現接近或超越 **Fable 5**，且在找 Bug 數量上超越 **GPT-5.5**。

3.  **Fusion (OpenRouter)：結構化合成**
    *   **架構**：服務端管道結構，模仿人類團隊開會流程。
    *   **流程**：
        1.  **並行分發**：同時派發問題給 1-8 個模型（配備聯網搜索）。
        2.  **判官分析**：分析共識、矛盾與盲點。
        3.  **合成**：由「大哥」模型（如 **Opus 4.8**）基於報告撰寫最終答案。
    *   **表現**：在 Perplexity 的 **DRACO** 基準測試（深度研究）中，**Fusion** 得分 64.7，僅略低於 **Fable 5** 的 65.3。即使同一模型自我組合，經此流程也能提升 6.7 個百分點。

4.  **戰略意義**：
    *   模型編排正在成為新的性能擴展路線，本質是對單一廠商依賴的風險對沖。
    *   未來 API 將轉向調用「編排網絡」而非單一模型。
    *   多模型編排思維框架強調：模型多樣性、智能協調機制、高質量合成（判官角色）。

## 詳細大綱

### I. 引言與背景
*   **講者**：為什麼叫QQ。
*   **現象級產品**：Sakana AI 發佈 Fugu，OpenRouter 發佈 Fusion。
*   **市場痛點**：
    *   美國政府對 Anthropic 的 **Fable 5** 和 **Mythos 5** 實施出口管制。
    *   企業意識到單一閉源模型依賴的風險。
    *   需求轉變：從單一超級大腦轉向「模型團隊」與風險對沖。

### II. 方案一：Sakana AI 的 Fugu (學習式協調)
*   **公司背景**：
    *   日本 AI 公司，創始人包含 **Llion Jones**（《Attention is All You Need》主要作者，Transformer 架構提出者之一，業界稱「Transformer 八子」）。
*   **核心架構**：
    *   **輕量級協調器**：參數量僅 0.6B，作為協調器而非單體模型。
    *   **動態調度**：根據任務類型（代碼、驗證等）調度其他大模型。
    *   **表現**：在代碼審查、論文復現等任務上，**Fugu Ultra** 表現接近或超越 **Fable 5**。
*   **技術底層 (基於 ICLR 2026 論文 Trinity 與 Conductor)**：
    *   **角色分配**：將任務分給 Thinker（思考者）、Worker（工作者）、Verifier（驗證者）。
    *   **訓練方法**：
        *   不使用單純的強化學習（RL），因高維度與預算限制易陷入局部最優。
        *   採用 **進化策略**，具體為 **sep-CMA-ES**（可分離的協方差矩陣自適應進化策略）。
        *   利用「塊-epsilon-可分離性」數學特性，在龐大搜索空間中高效找出最優協調策略。
    *   **產品訓練**：包含大規模微調、進化算法與強化學習的組合。
    *   **用戶反饋**：在代碼審查中找出的 bug 數量遠超 **GPT-5.5**。

### III. 方案二：OpenRouter 的 Fusion (結構化合成)
*   **核心思路**：工程化路線，服務端管道，模仿人類團隊開會流程。
*   **執行流程 (三步走)**：
    1.  **並行分發**：同時派發問題給 1-8 個不同模型，每個模型配備聯網搜索工具。
    2.  **判官分析**：
        *   使用判官模型分析所有答案。
        *   目標：找共識（高置信度）、找矛盾（爭議點）、找盲點（被忽略處）。
    3.  **合成**：由「大哥」模型（如 **Opus 4.8**）基於詳細分析報告撰寫最終答案。
*   **效果驗證**：
    *   使用 **Perplexity 的 DRACO 基準測試**（專注深度研究、學術報告、財務分析）。
    *   **Fusion** 預算面板得分 64.7 分。
    *   **Fable 5** 單獨得分 65.3 分。
    *   註：DRACO 不考長期自治任務，**Fable 5** 在該類任務可能有優勢。
    *   即使 **Opus 4.8** 自己與自己組合，經此流程分數也能提升 6.7 個百分點，證明提升來自「判官+合成」機制。

### IV. 兩種方案的第一性原理對比
*   **Fugu (黑盒/學習式)**：
    *   基於進化算法與學習式協調。
    *   適合長期、多步、複雜任務（如論文復現），容錯率較高。
*   **Fusion (白盒/規則式)**：
    *   基於「多視角綜合」的工程學派。
    *   適合深度研究報告、資料對比分析，在 DRACO 基準表現出色且成本控制極好。
*   **共同結論**：在深度研究、代碼驗證、多步驟問題上，模型編排是新的性能擴展路線。

### V. 戰略意義與架構思維框架
*   **地緣政治與風險對沖**：
    *   Anthropic 因合規壓力臨時關閉模型，證明單一依賴的風險。
    *   多模型編排將依賴變為「隨時插拔的代理池」，實現真正的 **AI 主權**。
*   **多模型編排思維框架 (工程師/產品經理適用)**：
    1.  **必須有模型多樣性**：避免相同模型拼湊浪費算力，需不同知識結構與推理風格。
    2.  **需要智能的協調機制**：避免手寫 if-else，學習 Fusion 的結構化提取或 Fugu 的小模型調度。
    3.  **高質量的合成是靈魂**：必須有「判官」角色審視中間結果，複雜問題需分解解決。

### VI. 未來展望
*   單體超級模型時代可能結束，API 將轉向調用「編排網絡」。
*   隨開源模型（如 **DeepSeek V4**）變強，預算模型的組合能力將提升。
*   供應鏈多元化成為科技公司戰略必需，多模型編排是在不確定性下保持靈活性。

## 工具 / 模型 / 名詞整理

*   **Sakana AI**：日本 AI 公司，發佈 Fugu。
*   **Fugu / Fugu Ultra**：Sakana AI 發佈的多模型編排模型/產品。
*   **OpenRouter**：推出 Fusion API 的公司。
*   **Fusion**：OpenRouter 推出的多模型編排方案。
*   **Anthropic**：模型廠商。
*   **Fable 5**：Anthropic 的模型（受出口管制影響）。
*   **Mythos 5**：Anthropic 的模型（受出口管制影響）。
*   **Llion Jones**：《Attention is All You Need》主要作者。
*   **Attention is All You Need**：提出 Transformer 架構的著名論文。
*   **Transformer**：架構名稱。
*   **Perplexity**：公司名稱。
*   **DRACO**：Perplexity 的基準測試名稱（考深度研究）。
*   **SWE Bench Pro**：Sakana 使用的工程類任務基準。
*   **Terminal Bench**：Sakana 使用的工程類任務基準。
*   **LiveCodeBench**：Sakana 使用的工程類任務基準。
*   **ICLR 2026**：會議名稱（文中提及 Trinity 與 Conductor 論文發表於此）。
*   **Trinity**：Sakana AI 的研究論文名稱。
*   **Conductor**：Sakana AI 的研究論文名稱。
*   **Thinker**：Fugu 中的角色（思考者）。
*   **Worker**：Fugu 中的角色（工作者）。
*   **Verifier**：Fugu 中的角色（驗證者）。
*   **RL (強化學習)**：訓練方法。
*   **sep-CMA-ES**：進化策略算法（可分離的協方差矩陣自適應進化策略）。
*   **GPT-5.5**：被比較對象。
*   **Opus 4.8**：Fusion 中使用的「大哥」模型。
*   **DeepSeek V4**：提及的開源模型。

## 操作流程整理

### Fugu (Sakana AI) 流程
1.  **輸入任務**：接收代碼、驗證或論文復現等任務。
2.  **輕量級協調器處理**：0.6B 參數協調器根據任務類型進行動態調度。
3.  **角色分配**：將子任務分配給 Thinker（思考者）、Worker（工作者）、Verifier（驗證者）等模型。
4.  **進化策略優化**：利用 sep-CMA-ES 算法在搜索空間中尋找最優協調策略（結合大規模微調與強化學習）。
5.  **輸出結果**：生成最終答案或代碼，在找 Bug 數量上表現優異。

### Fusion (OpenRouter) 流程
1.  **並行分發**：將問題同時派發給 1-8 個不同模型，每個模型配備聯網搜索工具。
2.  **判官分析**：
    *   使用判官模型分析所有模型的答案。
    *   識別共識（高置信度內容）、矛盾（爭議點）與盲點（被忽略處）。
3.  **合成**：由「大哥」模型（如 Opus 4.8）基於判官的分析報告撰寫最終答案。

## 值得注意的限制或風險

1.  **基準測試局限性**：DRACO 基準測試不考長期自治任務，**Fable 5** 在該類任務中可能仍具優勢。
2.  **單一依賴風險**：若協調器或關鍵模型（如 Opus 4.8）出現問題或受管制，編排網絡可能中斷。
3.  **成本與複雜度**：雖然 Fusion 成本控制極佳，但多模型調用與判官分析仍比單一模型調用複雜。
4.  **模型多樣性要求**：若使用相同模型拼湊，可能浪費算力，需確保不同模型具有不同的知識結構與推理風格。

## 逐字稿辨識疑點

*   **Fable 5**：逐字稿中多次提及此名稱，通常 Anthropic 知名模型為 Claude 系列（如 Opus, Sonnet 等），此處「Fable 5」可能為聽寫錯誤或特定內部/新模型名稱，需查證。
*   **Mythos 5**：同上，與 Fable 5 並列提及，需查證是否為真實存在的模型名稱。
*   **GPT-5.5**：逐字稿中提及「比 GPT-5.5 多了好幾倍」，目前市場常見版本為 GPT-4/4o 等，「5.5」版本是否存在或為口誤，需查證。
*   **Opus 4.8**：逐字稿中提及「Opus 4.8」，通常 Anthropic 的 Opus 模型版本號格式可能不同（如僅稱 Opus），此處「4.8」版本號需查證是否準確。
*   **ICLR 2026**：逐字稿提及「ICLR 2026 論文」，若當前時間未到 2026 年或該會議尚未發表此論文，可能為口誤（如 ICLR 2024/2025）或預測性描述，需查證。
*   **Llion Jones**：逐字稿稱其為《Attention is All You Need》主要作者之一及「Transformer 八子」之一。需查證該稱謂與事實是否完全吻合（通常該論文作者眾多，「八子」非標準業界通用稱謂，可能為講者特定說法）。
*   **Fugu Ultra**：Fugu 產品是否有「Ultra」版本，需查證。

## 可延伸追問

1.  **Fable 5 與 Mythos 5 的具體規格與現狀**：這兩款模型是否真實存在？其性能與 Claude 系列相比如何？
2.  **sep-CMA-ES 的具體實現細節**：該進化策略如何在實際的 LLM 協調中應用？其計算成本與訓練週期如何？
3.  **Fusion 的成本效益分析**：在 DRACO 基準測試中，Fusion 的具體成本是多少？與單獨使用 Opus 4.8 相比，成本節省比例為何？
4.  **多模型編排的標準化**：目前 Fugu 與 Fusion 的架構差異較大，未來是否會有統一的編排標準或協議？
5.  **地緣政治對 AI 供應鏈的影響**：出口管制如何具體影響多模型編排的部署與選擇？企業應如何構建「AI 主權」？