「沒有 Fable 5 也沒關係」：Sakana Fugu 用多模型編排打到前沿水準

瀏覽次數: 1

當前最強的兩個模型 —— Anthropic 的 Fable 5 與 Mythos Preview —— 都還沒公開可用。對多數團隊、企業，甚至整個國家來說，最頂尖的權重買不到、租不到、也擋在出口管制與供應商綁定的另一邊。那麼問題就變得很尖銳：如果你拿不到那把最利的劍，還能不能打到前沿水準？

Tokyo 的 Sakana AI 給的答案是：能 —— 但不是靠訓練一個更大的模型，而是靠把現有模型編排起來。他們在 2026 年 6 月發表的 Fugu 系統，核心賭注就一句話：能力可以被「組合」出來，而不是只能被「訓練」出來。這篇文章用論文與官方 primary source，把 Fugu 的真實機制、真實數字與它老實承認（與沒承認）的限制拆給你看。

本文大綱

一、Fugu 要解決的問題：從「選一個模型」到「編排一群模型」

今天你用 ChatGPT 或 Claude，請求基本上被送進單一語言模型。市面上的「router」產品多半也只是用一層規則或分類器，把問題丟給某一個後端模型。Fugu 想做的是更進一步的東西：不是選一個,而是動態地組織一整群前沿模型協作 —— 而且這套協作策略是學出來的,不是工程師手寫死的 workflow。

Sakana AI 的底子正好適合做這件事。這家實驗室過去以演化式模型合併（evolutionary model merging）與 The AI Scientist 聞名,擅長「不靠蠻力訓練、而靠巧妙組合」的路線。Fugu 建立在他們 2026 年的兩篇研究之上：TRINITY（An Evolved LLM Coordinator）與 Conductor（Learning to Orchestrate Agents in Natural Language）,兩者都收錄於 ICLR 2026。對外,Fugu 包成一個 OpenAI 相容的單一 API 端點 —— 你照常打一個 endpoint,後面是誰、怎麼分工,由 Fugu 自己決定。

關鍵概念是論文說的 functional model composition（功能性模型組合）：Fugu 不去合併權重、也不縫合網路層,而是把每個前沿模型當成黑箱 agent,在行為層學會怎麼路由、協調、驗證、合成它們的輸出。這跟傳統的 model merging 是兩條完全不同的路。

二、運作原理：編排器本身就是一個 LLM

Fugu 最反直覺的設計是：編排器本身就是一個語言模型,被訓練來理解你的查詢、並動態設計出解題的 agentic scaffold。它有兩個版本,機制不同。

Fugu（base）：學會「該自己答，還是該分派」

base 版的目標是在不犧牲延遲的前提下做出好的路由決策。它的做法很精巧：在 backbone 最終隱藏層上接一個輕量選擇頭（lightweight selection head）,對於每個 worker 模型輸出一個分數。重點是 —— 這個決策不需要自迴歸生成。系統在一個很早的 token 位置就算出隱藏狀態、套上選擇頭、立刻分派,論文稱之為 "decision-only parametrization",這正是它能維持低延遲的關鍵。

參數適配上,它沒有做全量微調,而是用 singular-value fine-tuning:把選定的權重矩陣分解,只訓練奇異值的縮放,保持正交分量不動,因此可訓練參數極少。訓練分兩階段:

監督微調(SFT)：每道題讓全部 K 個 worker 各跑 n 次,依實測表現排序,用帶溫度的 softmax 轉成軟標籤分布,再讓編排器用 KL 散度去學。論文指出軟標籤比硬標籤提供「更豐富的訓練訊號」,當好幾個 worker 能力相近時路由也更穩。
演化最佳化：用 sep-CMA-ES 直接在真實 coding harness(Claude Code、Codex)的端到端多輪任務上最大化最終 reward。這一步能抓到從分數看不出來的差異 —— 例如工具使用的可靠度、對環境回饋的反應能力。

base 版每道題只會選一個最適 worker,所以它的延遲「與直接呼叫一個前沿模型相當」。

Fugu-Ultra：用強化學習學會寫工作流

Ultra 版建立在 Conductor 框架上,用 GRPO（Grouped Relative Policy Optimization）強化學習訓練。它的輸出不再是「選一個」,而是一整份用自然語言寫成的 agentic workflow:把任務拆成多個步驟,每步指定(a)子任務描述、(b)一個整數 agent ID、(c)一個 access list（要把先前哪幾步的輸出放進 context）。

reward 是兩段式的:格式條件(workflow 無法被解析 → reward 0)、正確性條件(最終輸出對 → 1,部分對 → 0.5)。

Ultra 真正有意思的工程貢獻,是它怎麼處理互動式環境裡的多 agent 協作。論文提出 intra-workflow agent isolation:每個 agent 的 function call 彼此隔離,避免「orchestration collapse」—— 也就是第一個碰到環境的 agent 把後面所有 agent 的軌跡都帶歪。同時又用 persistent shared memory 讓 agent 能看到先前 workflow 的工具呼叫,在多輪對話間保留環境脈絡。隔離當下、共享歷史 —— 這個拆法相當乾淨。

Worker 池與遞迴

目前的 worker 池是三個前沿模型:GPT-5.5、Gemini-3.1-Pro、Claude-Opus-4.8。論文觀察到的專長分工是:GPT 強在數學、Gemini 強在科學與事實記憶、Opus 強在軟體工程與除錯,Fugu 學會這些差異並據此路由。值得注意的是 —— Conductor 允許把編排器自己也指定為一個 worker agent,等於開啟了遞迴式的協調拓樸。而 Fable 5 與 Mythos Preview 因為「未公開可用」,並不在池中。標題那句「沒有 Fable 5 也沒關係」就是這個意思。

三、數據與限制：誠實看數字

論文 Table 1 的數字（越高越好）:

基準	Fugu-Ultra	Fugu	Claude Opus 4.8	Gemini 3.1	GPT-5.5
SWE-Bench Pro	73.7	59.0	69.2	54.2	58.6
Terminal Bench 2.1	82.1	80.2	74.6	70.3	78.2
LiveCodeBench v6	92.0	90.3	90.3	88.9	90.7
GPQA-Diamond	95.5	95.5	92.0	94.3	93.6

結論很清楚:Fugu-Ultra 在這四個基準上,都超越池中任一單一模型。最戲劇化的是 SWE-Bench Pro —— 73.7 對上 Opus 的 69.2、GPT-5.5 的 58.6,證明「編排 > 池中最強單體」確實可能發生。

但要誠實地補幾個 caveat:

base Fugu 不是全面贏。在 SWE-Bench Pro 上 base 只有 59.0,低於 Opus 的 69.2。單 worker 的低延遲模式,換來的是上限被「池中最強單體」壓住的事實。真正把分數推過前沿的是會多 agent 協作的 Ultra。
「追平 Fable 5 / Mythos」是研究方與報導的說法。VentureBeat 等報導稱 Fugu-Ultra 與 Fable 5、Mythos「並肩」,但因為這兩個模型未公開,Table 1 裡並沒有它們的直接對照數字。把它當成廠商宣稱,不要當成已驗證的同台結果。
這是「公開可用模型中的 SOTA」,不是絕對 SOTA。前提條件要記得。
成本完全沒有被核算。論文沒有揭露 Ultra 多模型查詢相對單一前沿模型的 token 成本與總推論開銷 —— 對部署可行性來說這是個實質缺口。Ultra 的多步工作流(報導提到 5 步)會帶來額外延遲與多次 API 計費,但都沒被量化。
分布外行為未分析。論文沒談 distribution shift:當查詢類型偏離訓練分布時,學出來的路由會怎樣?沒有答案。
論文裡少數的坦白出現在交易實驗(Appendix B.3),作者自己聲明那個 +回報的數字「使用單一匿名股票、單一 50 週歷史窗口,目的是比較循序、無前瞻的決策,而非建立可泛化的交易績效,結果不保證能轉移到其他資產、時期或真實市場」。這種誠實值得肯定,但也反過來提醒:其他亮眼的質化例子,可能也帶有挑選成分。

四、什麼時候該用、什麼時候別用

該考慮 Fugu 的情境:

你在意供應商綁定與地緣風險。Fugu 的池子可以「偏好特定供應商、排除特定模型,或滿足資料、隱私、合規限制,而不需要重新訓練」。當某個 provider 限制存取,系統能繞過。對受出口管制影響的組織,這是論文主打的價值。
你的任務跨領域(同時碰數學、科學、工程),沒有單一模型全項最強。
你願意用延遲與成本換品質的硬問題 —— 這是 Ultra 的甜蜜區。

別硬上的情境:

成本敏感且單一模型已經夠用。多模型查詢的帳單沒有被論文量化,你得自己算,而且很可能比單打貴。
追求極致低延遲。即使 base 號稱延遲與直接呼叫相當,Ultra 的多步協作必然更慢。
需要單一供應商的可解釋性與 SLA。一個請求散到三家模型,稽核、除錯、責任歸屬都更複雜。

Fugu 與 Fugu-Ultra 本身就是一組 trade-off:前者是低延遲、上限受限的日常檔;後者是高品質、高開銷的攻堅檔。選型時先想清楚你要的是哪一端。

五、對工程團隊的意義

第一,路由正在變成一種可學習的資產,而不是一串 if-else。如果你現在的 LLM gateway 還在用手寫規則決定打哪個模型,Fugu 的訊號是:這層決策值得被資料驅動地學起來 —— 哪怕你不打算自己訓練編排器,至少該開始記錄「哪個模型在哪類任務上實際更好」這種端到端訊號。

第二,「組合 > 訓練更大」是一條對非巨頭友善的路徑。論文的論點是:如果能力可以靠組合現有模型放大,那 AI 進展就不必只綁在能跑最大訓練的少數玩家身上。對沒有最大算力的團隊、甚至國家,這在策略上是有意義的。

第三,OpenAI 相容 API 降低了接入成本,但別把可觀測性也外包掉。Fugu 把複雜度藏在一個端點後面很方便,可是成本、延遲、每個 worker 的命中率,這些你都得自己建監控 —— 論文沒幫你算的帳,線上會替你算。

第四,評估要看你自己的分布,不要照搬 benchmark。SWE-Bench Pro 上漂亮不代表你的 codebase 上漂亮。在自己的任務集上跑一輪 base vs Ultra vs 你現在的單一模型,用你的成本與延遲預算去框,才是負責任的選型。

編排式系統不是萬靈丹,但 Fugu 把一件事做實了:在拿不到最強權重的世界裡,會編排的人,有機會打贏只有一把劍的人。

六、來源

技術報告：Sakana Fugu Technical Report, arXiv:2606.21228 — https://arxiv.org/abs/2606.21228 （作者：Yujin Tang, Edoardo Cetin, Jinglue Xu, Qi Sun, Stefan Nielsen, Vincent Richard, Haruto Goda, Iaroslav Tymchenko, Nhan Nguyen, Hyunin Lee, Mari Ashiga, Shashank Kotyan, So Kuroki, Tarin Clanuwat，Sakana AI）
官方發布：Sakana Fugu: One Model to Command Them All — https://sakana.ai/fugu-release/
程式碼：https://github.com/SakanaAI/fugu
底層研究：TRINITY（An Evolved LLM Coordinator, ICLR 2026）、Conductor（Learning to Orchestrate Agents in Natural Language, ICLR 2026）
報導：VentureBeat — https://venturebeat.com/orchestration/no-claude-fable-5-no-problem-sakana-achieves-frontier-performance-with-new-fugu-multi-model-auto-synthesis-system