影片筆記：Sakana Fugu用hidden states编排开源模型超越Fable 5

一句話總結

Sakana AI 發布的 Fugu Ultra 模型通過基於 Hidden State 的動態編排機制，協調開源與閉源模型池，在 SWE Bench Pro 等基準測試中達到 SOTA，並聲稱具備繞過出口管制限制的能力。

核心重點

• 架構創新：Fugu Ultra 不依賴單一超大模型，而是採用「集體智能」與「動態編排」架構。核心是一個語言模型骨幹，生成 Hidden State 來協調背後一系列可自由切換的 AI 智能體池（包含自有、開源及閉源模型）。
• 技術原理：
• 非傳統 Prompt 編排，而是通過骨幹語言模型生成 Hidden State。
• 在 Logits 之前的 Hidden State 被路由到工作池中的所有模型。
• 工作池模型輸出其 Logits，由骨幹模型協調。
• 此機制使得開源模型能作為工作池的一部分，因為閉源模型通常無法接觸其 Hidden State 作為 Input。
• 性能表現：
• 在 SWE Bench Pro 和 Terminal Bench 2.1 基準測試中達到當前最優水平（SOTA）。
• 在科學推理方面超越部分競爭對手（如 Methos Preview 和 Fuble 5）。
• 與多個前沿模型（Germel 3.1 Pro High, Op4.8 Max, GPT 5.5 X High）對比表現優異。
• 市場定位與韌性：
• 性能比肩 Cloud Fable 5 和 Mythos。
• 明確聲明無需承擔出口管制的牽連能力（針對 Fable 5 而言）。
• 當遇到單一供應商限制時，系統能自動繞道，通過換模型繼續運行，提升系統韌性。
• 訓練策略：
• 兩步走：大規模監督微調（編程、數學、語言） + 針對單個任務的微調（端到端優化）。
• 使用真實世界多輪軌跡數據（迭代編程、工具調用、執行反饋）進行優化。

詳細大綱

一、 市場背景與競爭對手

• 競爭環境：
• Unthorbit 發布最強模型 Cloud Fable 5，在全球金融領域表現強勁，引發多方效仿。
• OpenRouter 上線了 Fusion 模型，此前已分享過的競爭產品。
• Sakana AI 背景：
• 由 Transformer 發明者 Ion Jones 共同創辦。
• 公司在日本創建，命名為日本風格的 Sakuna AI。
• 發布模型名為 Fugu Ultra（河豚）。

二、 Fugu Ultra 的核心架構與理念

• 性能定位：
• 聲稱性能比肩 Cloud Fable 和 Mythos。
• 聲明中明確表示無需承擔出口管制的牽連能力（針對 Fable 5 而言）。
• 在工程科學推理基準測試中，與 Fable 表現幾乎無差異，幾乎可匹配。
• 架構差異：
• Mythos 與 Fable：據說是單模型架構。
• Fugu：採用「集體智能」，背後編排了一整個可自由切換的 AI 智能體池。
• 系統韌性與繞道機制：
• 當遇到單一供應商限制（無法實驗所需能力）時，系統能自動繞道。
• 通過換模型繼續運行，大幅提升系統韌性。
• 圖示顯示 Sakuna Fugu 更像是一個編排的 Agent，編排對應一系列模型（自有、開源、閉源）。
• 核心觀點：未來競爭不在於誰的模型更大，而在於誰能將全球模型編排得更好、更穩、更自主。

三、 性能表現與基準測試

• 基準測試成績：
• 在 SWE Bench Pro 和 Terminal Bench 2.1 兩個基準測試上達到當前最優水平（SOTA）。
• 性能明顯提升。
• 科學推理能力：
• 表現顯著，甚至超越了 Methos Preview 與 Fuble 5。
• 印證了 Fugu 的核心能力：智能調度成為提升性能的另一個維度。
• 不依賴增加更多的訓練算力。
• 前沿模型對比：
• 與以下三個前沿模型進行對比：
• Germel 3.1 Pro High
• Op4.8 Max
• GPT 5.5 X High
• 結果顯示 Fugu 在這種情況下依然很難打（表現優異）。

四、 運行機制與技術原理

• 非傳統工作流編排：
• 不是按照傳統意義上的人工提示詞（Prompt）來編排工作流。
• 通過一個語言模型作為骨幹，基於 Prompt 生成 Hidden State（隱藏狀態）。
• 基於引擎狀態協調其他工作模型池。
• 所有編排工作在 Hidden State 內實現。
• 路由邏輯細節：
• 語言模型（指 Sekona Fugu）生成 Output。
• 在 Logits 之前的 Hidden State 會路由出來，傳到工作池中的所有模型。
• 由工作池模型輸出其 Logits。
• 開源與閉源的關鍵區別：
• 若能做到此步驟，工作池模型應多為開源模型。
• 原因：閉源模型無法接觸其 Hidden State 作為 Input 來輸出 Logits。
• 整個過程設計巧妙，不僅是靠 Agent 編排實現路由邏輯。

五、 訓練策略

• 兩步走訓練法：

1. 大規模廣度監督微調：涵蓋編程、數學推理、語言理解等多方面。
2. 針對單個任務的監督微調：實現端到端優化。

• 數據來源：
• 使用不同的編程助手（Hardless, Codex, Cloud Code, OpenCode）。
• 收集真實世界的多輪軌跡。
• 構建設計倉務上要文（疑點：語意不清）。
• 內容包括：迭代編程、工具調用、執行反饋和最終任務的多個端到端任務用力虛擬（疑點：語意不清）。

工具 / 模型 / 名詞整理

• 模型/產品名稱：
• Cloud Fable 5（或 Fable 5）
• Fusion 模型（OpenRouter 上線）
• Fugu Ultra
• Mythos / Methos Preview
• Germel 3.1 Pro High
• Op4.8 Max
• GPT 5.5 X High
• Sekona Fugu（疑點：應為 Sakuna Fugu）
• Fuble 5（疑點：應為 Fable 5）
• 公司/組織名稱：
• Unthorbit
• OpenRouter
• Sakuna AI
• Transformer（發明者 Ion Jones）
• 工具/平台名稱：
• Codex
• Cloud Code
• OpenCode
• Hardless（疑點：工具名稱）
• 基準測試（Benchmarks）：
• SWE Bench Pro
• Terminal Bench 2.1
• 技術概念：
• Hidden State（隱藏狀態）
• Logits
• 集體智能（Collective Intelligence）
• 動態編排（Dynamic Orchestration）

操作流程整理

1. 輸入處理：用戶輸入 Prompt。
2. 骨幹模型生成：Sakuna Fugu（骨幹語言模型）接收 Prompt，生成 Hidden State。
3. 狀態路由：將骨幹模型在 Logits 之前的 Hidden State 路由到工作池中的所有模型。
4. 工作池計算：工作池中的模型（包含開源、閉源、自有模型）接收 Hidden State 作為輸入，並輸出各自的 Logits。
5. 協調與輸出：骨幹模型協調這些 Logits，生成最終輸出。
6. 訓練優化：

• 收集真實世界多輪軌跡數據（迭代編程、工具調用、執行反饋）。
• 進行大規模監督微調（編程、數學、語言）。
• 進行針對單個任務的監督微調（端到端優化）。

值得注意的限制或風險

• 供應商依賴與繞道：雖然系統設計旨在繞過單一供應商限制，但實際運行仍依賴於工作池中模型的可用性與性能。
• 閉源模型限制：閉源模型無法接觸其 Hidden State 作為 Input，這限制了閉源模型在該架構中的參與方式，工作池模型應多為開源模型。
• 出口管制聲明：Sakana AI 明確聲明 Fugu Ultra 無需承擔出口管制的牽連能力，這是一項重要的市場區別聲明，但需驗證其技術實現是否真能完全隔離受限制的核心組件。
• 性能依賴調度：性能提升部分來自於智能調度而非單純增加訓練算力，這意味著調度算法的質量直接決定最終效果。

逐字稿辨識疑點

• Ion Jones：通常 Transformer 發明者為 Ian Goodfellow 或 Geoffrey Hinton 等，此處聽寫為 "Ion Jones"，需查證具體創始人姓名。
• 牽沿能力：疑為「牽連」或「牽涉」的口誤，指出口管制相關的責任。
• Mythos 和 Fable 據說是一個單模型的架構：需確認 Mythos 是否為單模型架構。
• Methos Preview：疑點，可能為 Mythos Preview 的聽寫錯誤。
• Fuble 5：疑點，可能為 Fable 5 的聽寫錯誤。
• Germel 3.1 Pro High：疑點，模型名稱不常見，需查證。
• Op4.8 Max：疑點，模型名稱不常見，需查證。
• GPT 5.5 X High：疑點，模型名稱不常見，需查證。
• 利民的對比：疑點，語意不通，可能為「領先的對比」或「類似的對比」。
• Sekona Fugu：疑點，應為 Sakuna Fugu 的聽寫錯誤。
• 必源模型：疑點，應為「閉源模型」的聽寫錯誤。
• 設影：疑點，應為「設計」的聽寫錯誤。
• Hardless 的數據：疑點，工具名稱不常見，可能為特定內部工具或聽寫錯誤。
• 設計倉務上要文：疑點，語意不清，可能為「設計任務上下文」或「設計場景上下文」的聽寫錯誤。
• 任務用力虛擬：疑點，應為「任務用例」或「任務數據」的聽寫錯誤。

可延伸追問

• Sakana AI 的創始人 Ion Jones 具體背景是什麼？與 Transformer 發明者的關係為何？
• Fugu Ultra 的「集體智能」架構在實際部署中如何處理延遲問題？
• 如何確保工作池中的開源模型在接收 Hidden State 後的輸出質量與一致性？
• 該模型在繞過出口管制方面的具體技術實現細節是什麼？
• SWE Bench Pro 和 Terminal Bench 2.1 的具體評分標準與 Fable 5 的對比數據詳情為何？