WEBVTT
Kind: captions
Language: zh-CN

00:00:00.000 --> 00:00:02.000
大家好 我是為什麼叫QQ

00:00:02.000 --> 00:00:04.166
最近 Sakana AI發佈了Fugu

00:00:04.166 --> 00:00:05.900
這是一個很特殊的模型：

00:00:05.900 --> 00:00:08.666
它不是另一個超大的單體模型

00:00:08.666 --> 00:00:10.400
而是一個"模型編排器"

00:00:10.400 --> 00:00:13.533
你可以理解成：Fugu是一個輕量級的協調器

00:00:13.533 --> 00:00:14.900
它會根據你的任務

00:00:14.900 --> 00:00:17.900
動態地調度其他大模型來幫你完成工作

00:00:17.900 --> 00:00:18.700
結果呢？

00:00:18.700 --> 00:00:22.566
在代碼審查 論文復現 安全評估這些複雜任務上

00:00:22.566 --> 00:00:25.733
Fugu Ultra的表現已經接近或超越了Fable 5

00:00:25.733 --> 00:00:27.000
這就很離譜了

00:00:27.000 --> 00:00:30.200
一個參數量只有0.6B的輕量級協調器

00:00:30.200 --> 00:00:33.733
憑什麼能管住那些百億 千億參數的大模型？

00:00:33.733 --> 00:00:35.300
看到這裏你可能會想

00:00:35.300 --> 00:00:37.066
這不就是簡單的投票機制嗎？

00:00:37.066 --> 00:00:39.166
三個臭皮匠頂個諸葛亮

00:00:39.166 --> 00:00:42.700
這種老掉牙的套路也能在AI時代大放異彩？

00:00:42.700 --> 00:00:44.000
事情沒那麼簡單

00:00:44.000 --> 00:00:47.700
如果只是簡單的算平均分 模型組合早就爛大街了

00:00:47.700 --> 00:00:50.900
為什麼直到現在 多模型編排才真正展現出

00:00:50.900 --> 00:00:52.933
能打敗單體巨獸的實力？

00:00:52.933 --> 00:00:55.300
這背後到底藏着什麼黑科技？

00:00:55.300 --> 00:00:57.633
今天 我們就來硬核拆解兩個

00:00:57.633 --> 00:00:59.866
最近爆火的多模型編排方案：

00:00:59.866 --> 00:01:03.133
Sakana AI的Fugu和OpenRouter的Fusion

00:01:03.133 --> 00:01:05.466
看看它們到底在底層動了什麼手腳

00:01:05.466 --> 00:01:07.433
憑什麼能達到Fable 5的級別

00:01:07.433 --> 00:01:09.400
先説個Sakana AI是誰

00:01:09.400 --> 00:01:12.333
這是一家不太為人所知的日本AI公司

00:01:12.333 --> 00:01:14.066
但幕後的人物很不一般

00:01:14.066 --> 00:01:15.933
創始人中有Llion Jones

00:01:15.933 --> 00:01:17.666
很多人可能沒聽過這個名字

00:01:17.666 --> 00:01:19.733
但在AI圈子中他是個傳奇

00:01:19.733 --> 00:01:22.500
他是著名論文《Attention is All You Need》

00:01:22.500 --> 00:01:23.966
的主要作者之一

00:01:23.966 --> 00:01:26.300
這篇論文提出了Transformer架構

00:01:26.300 --> 00:01:29.533
直接打開了今天整個大模型時代的大門

00:01:29.533 --> 00:01:31.900
業界稱他為"Transformer八子"之一

00:01:31.900 --> 00:01:34.033
就是這樣一個上一代頂會的研究者

00:01:34.066 --> 00:01:36.066
現在在日本搞模型編排

00:01:36.066 --> 00:01:38.666
前段時間 美國政府對Anthropic的

00:01:38.666 --> 00:01:41.366
Fable 5和Mythos 5實施了出口管制

00:01:41.366 --> 00:01:42.533
這意味着什麼？

00:01:42.533 --> 00:01:45.966
意味着對很多公司來説 這個地表最強模型

00:01:45.966 --> 00:01:48.733
突然就不能用了 這下圈子裏爆鍋了

00:01:48.733 --> 00:01:50.100
大家突然意識到

00:01:50.100 --> 00:01:53.566
把身家性命綁在一個閉源模型上 風險太大了

00:01:53.566 --> 00:01:54.733
你需要一個備胎

00:01:54.733 --> 00:01:58.100
或者説 你需要一個不依賴單一廠商的解決方案

00:01:58.100 --> 00:02:01.566
就在這個節骨眼上 兩個方案几乎同時放了出來

00:02:01.666 --> 00:02:04.866
6月13日 OpenRouter推出了Fusion API

00:02:04.866 --> 00:02:08.633
緊接着 6月22日 Sakana AI發佈了Fugu

00:02:08.633 --> 00:02:10.966
這兩個方案的思路出奇的一致：

00:02:10.966 --> 00:02:13.933
別死磕單個大模型了 搞個模型團隊吧

00:02:13.933 --> 00:02:15.800
Open Router用了Perplexity

00:02:15.800 --> 00:02:19.166
的DRACO基準測試來驗證Fusion

00:02:19.166 --> 00:02:21.066
這個測試不考腦筋急轉彎

00:02:21.066 --> 00:02:24.933
專門考深度研究——寫學術報告 做財務分析

00:02:24.933 --> 00:02:27.100
全是大長篇的硬核任務

00:02:27.100 --> 00:02:30.866
結果就是剛才説的 Fusion預算面板64.7分

00:02:30.866 --> 00:02:32.966
Fable 5單獨65.3分

00:02:32.966 --> 00:02:36.500
但這裏要説清楚一點：DRACO測的是深度研究能力

00:02:36.500 --> 00:02:38.666
不包括長期自治任務

00:02:38.666 --> 00:02:40.933
Fable 5在那種任務上可能還有優勢

00:02:40.933 --> 00:02:41.900
那Fugu呢？

00:02:41.900 --> 00:02:45.700
Sakana用的是另一套基準——SWE Bench Pro

00:02:45.700 --> 00:02:47.000
Terminal Bench

00:02:47.000 --> 00:02:49.833
LiveCodeBench這些工程和推理類的任務

00:02:49.833 --> 00:02:51.833
兩個方案用的評測標準不一樣

00:02:51.833 --> 00:02:54.300
但都展示了多模型編排的威力

00:02:54.300 --> 00:02:57.500
它們到底是怎麼做到的？我們一層一層來扒

00:02:57.500 --> 00:02:59.466
先看Sakana AI的Fugu

00:02:59.466 --> 00:03:01.633
第一層： Fugu的編排策略

00:03:01.633 --> 00:03:04.333
（輕量級協調器如何調度大模型）

00:03:04.333 --> 00:03:08.766
Fugu的研究基礎包括兩篇ICLR 2026論文：

00:03:08.766 --> 00:03:10.666
Trinity和Conductor

00:03:10.666 --> 00:03:13.000
Trinity論文證明了一個關鍵觀點：

00:03:13.000 --> 00:03:15.900
輕量級協調器可以有效調度大模型

00:03:15.900 --> 00:03:18.500
具體怎麼做？通過角色分配

00:03:18.500 --> 00:03:20.766
Trinity把任務分給三種角色：

00:03:20.766 --> 00:03:23.633
Thinker（思考者） Worker

00:03:23.633 --> 00:03:26.633
（工作者）和Verifier（驗證者）

00:03:26.633 --> 00:03:29.900
你可能會想 這麼小的協調器怎麼管得住百億

00:03:29.900 --> 00:03:31.533
千億參數的大傢伙？

00:03:31.533 --> 00:03:34.300
秘密在於它不需要自己懂所有領域

00:03:34.300 --> 00:03:35.466
它只需要知道

00:03:35.466 --> 00:03:38.633
遇到代碼題 該把哪個模型叫出來當Worker；

00:03:38.633 --> 00:03:41.500
遇到需要驗證的地方 該誰來當Verifier

00:03:41.500 --> 00:03:43.233
它通過隱狀態表示

00:03:43.233 --> 00:03:45.800
把豐富的上下文塞給這些大模型

00:03:45.800 --> 00:03:48.033
但Trinity論文最硬核的地方

00:03:48.033 --> 00:03:50.366
是它用什麼方法訓練協調器

00:03:50.366 --> 00:03:54.766
現在大家訓練模型 動不動就是強化學習（RL）

00:03:54.766 --> 00:03:56.333
Trinity的作者偏不

00:03:56.333 --> 00:03:59.900
他們用的是進化策略 具體來説是sep-CMA-ES

00:03:59.900 --> 00:04:03.200
（可分離的協方差矩陣自適應進化策略）

00:04:03.200 --> 00:04:04.766
為什麼這個選擇很關鍵？

00:04:04.766 --> 00:04:06.700
因為在協調多個模型時

00:04:06.700 --> 00:04:09.833
維度太高了 而且計算預算卡得很死

00:04:09.833 --> 00:04:13.100
強化學習在這種高維度 嚴約束的場景下

00:04:13.100 --> 00:04:14.666
很容易陷入局部最優

00:04:14.666 --> 00:04:21.366
而sep- CMA- ES能利用一種叫做塊- epsilon-可分離性的數學特性

00:04:21.366 --> 00:04:23.333
在龐大的搜索空間裏

00:04:23.333 --> 00:04:25.500
更高效地找出最優的協調策略

00:04:25.500 --> 00:04:27.400
現在 Fugu產品本身的

00:04:27.400 --> 00:04:30.066
訓練方式包含了大規模微調

00:04:30.066 --> 00:04:32.600
進化算法和強化學習的組合

00:04:32.600 --> 00:04:35.466
這説明Sakana在Trinity的研究基礎上

00:04:35.466 --> 00:04:37.266
做了更復雜的工程優化

00:04:37.266 --> 00:04:41.433
這就好比你讓一個眼光毒辣的HR去管一羣頂尖程序員

00:04:41.433 --> 00:04:43.400
HR不需要自己會寫代碼

00:04:43.400 --> 00:04:46.633
只要知道誰適合幹什麼活 這個團隊就能起飛

00:04:46.633 --> 00:04:50.600
在代碼審查這種髒活累活上 早期用户反饋説

00:04:50.600 --> 00:04:54.500
Fugu Ultra找出的bug比GPT-5.5多了好幾倍

00:04:54.500 --> 00:04:56.900
這就是專業分工的降維打擊

00:04:56.900 --> 00:04:59.166
第二層： Fusion的結構化合成

00:04:59.166 --> 00:05:01.766
（為什麼"投票"能超越單模型）

00:05:01.766 --> 00:05:03.733
再來看看OpenRouter的Fusion

00:05:03.733 --> 00:05:05.466
它的思路更直接粗暴

00:05:05.466 --> 00:05:07.766
Fusion沒有用什麼複雜的進化算法

00:05:07.766 --> 00:05:11.500
它走的是一條非常工程化的路子：服務端管道

00:05:11.500 --> 00:05:15.166
它分三步走 第一步 並行分發 你扔個問題過去

00:05:15.166 --> 00:05:18.100
它同時派發給1到8個不同的模型

00:05:18.100 --> 00:05:20.600
每個模型都配了聯網搜索的工具

00:05:20.600 --> 00:05:23.800
第二步 判官分析 這是最關鍵的一步

00:05:23.800 --> 00:05:26.466
它不是簡單地把大家的答案拼起來

00:05:26.466 --> 00:05:29.233
它用一個判官模型 把所有人的答案看一遍

00:05:29.233 --> 00:05:30.733
然後做個結構化分析

00:05:30.733 --> 00:05:35.133
它要找出什麼？找共識 大家都同意的 置信度就高

00:05:35.133 --> 00:05:38.500
找矛盾 模型之間打架的地方 説明有爭議

00:05:38.500 --> 00:05:41.366
還要找盲點 也就是大家都忽略了什麼

00:05:41.366 --> 00:05:42.733
第三步 合成

00:05:42.733 --> 00:05:45.400
最後讓一個大哥（比如Opus 4.8）

00:05:45.400 --> 00:05:48.400
拿着這份詳盡的分析報告 寫出最終答案

00:05:48.400 --> 00:05:49.366
你猜怎麼着？

00:05:49.366 --> 00:05:52.900
哪怕是Opus 4.8自己和自己組合 經過這套流程

00:05:52.900 --> 00:05:55.666
分數也能硬生生拔高6.7個百分點

00:05:55.666 --> 00:05:58.566
這意味着什麼？意味着Fusion提升成績

00:05:58.566 --> 00:06:02.233
一大半功勞要歸結於這個"判官+合成"的機制

00:06:02.233 --> 00:06:04.500
而不是模型本身變聰明了

00:06:04.500 --> 00:06:07.433
你讓一個人做一道題做兩遍 可能還是錯的

00:06:07.433 --> 00:06:10.100
但你讓他做兩遍 然後自己給自己挑刺

00:06:10.100 --> 00:06:12.700
最後再總結 那質量絕對上一個台階

00:06:12.700 --> 00:06:14.600
這就是Fusion的底層邏輯

00:06:14.600 --> 00:06:17.766
第三層：兩種方案的第一性原理對比

00:06:17.766 --> 00:06:20.766
好 現在我們把Fugu和Fusion放在一起比一比

00:06:20.766 --> 00:06:23.533
你會發現 這是兩種完全不同的流派

00:06:23.533 --> 00:06:27.300
Fugu的研究基礎強調進化算法和學習式協調

00:06:27.300 --> 00:06:29.766
它認為在資源受限的情況下

00:06:29.766 --> 00:06:32.033
可以通過進化策略讓協調器

00:06:32.033 --> 00:06:34.100
自己學到最優的分配策略

00:06:34.100 --> 00:06:36.466
這是一種"黑盒"的 基於學習的協調

00:06:36.466 --> 00:06:38.366
Fusion走的是工程學派

00:06:38.366 --> 00:06:41.233
它的第一性原理是"多視角綜合"

00:06:41.233 --> 00:06:43.233
它模仿的是人類團隊開會

00:06:43.233 --> 00:06:46.333
大家先各自調研 然後彙總意見 找出分歧

00:06:46.333 --> 00:06:47.700
最後由leader拍板

00:06:47.700 --> 00:06:50.966
這是一種"白盒"的 基於規則的協調 誰更好？

00:06:50.966 --> 00:06:52.200
看場景

00:06:52.200 --> 00:06:54.866
如果你要做長期 多步的複雜任務

00:06:54.866 --> 00:06:57.466
比如讓AI自己去復現一篇論文

00:06:57.466 --> 00:07:01.000
Fugu這種學習式的協調更靈活 容錯率更高

00:07:01.000 --> 00:07:04.566
但如果你要做深度的研究報告 需要查閲大量資料

00:07:04.566 --> 00:07:07.766
做對比分析 Fusion這種結構化的合成方式

00:07:07.766 --> 00:07:12.066
在DRACO基準上表現出色 而且成本控制得極好

00:07:12.066 --> 00:07:14.933
但不管走哪條路 它們都證明了一件事：

00:07:14.933 --> 00:07:18.366
在深度研究 代碼驗證 多步驟問題這類任務上

00:07:18.366 --> 00:07:21.833
模型編排正在成為一條新的性能擴展路線

00:07:21.833 --> 00:07:24.233
説到這裏 事情開始變得有意思了

00:07:24.233 --> 00:07:27.200
很多人潛意識裏覺得 搞多模型編排

00:07:27.200 --> 00:07:29.666
是因為買不起Fable 5這種頂級模型

00:07:29.666 --> 00:07:31.233
所以搞個平替湊合用

00:07:31.233 --> 00:07:34.400
以前我們總是追求一個無所不能的"超級大腦"

00:07:34.400 --> 00:07:38.366
但你想想 人類社會是靠一個超級天才運轉的嗎？

00:07:38.366 --> 00:07:41.333
不是 人類社會是靠分工協作運轉的

00:07:41.333 --> 00:07:43.500
Fugu和Fusion的成功告訴我們：

00:07:43.500 --> 00:07:46.933
在深度研究 代碼驗證 多步驟問題這類任務上

00:07:46.933 --> 00:07:49.800
模型編排正在展現出新的競爭力

00:07:49.800 --> 00:07:52.100
它不是説單體模型已經結束了

00:07:52.100 --> 00:07:55.866
而是説明：有些問題 分工協作確實更高效

00:07:55.866 --> 00:07:58.200
特別是在現在這個大環境下

00:07:58.200 --> 00:08:00.200
美國政府對Fable 5的出口

00:08:00.200 --> 00:08:02.266
管制就是個活生生的例子

00:08:02.266 --> 00:08:03.966
Anthropic因合規壓力

00:08:03.966 --> 00:08:06.333
對所有客户臨時關閉了這兩個模型

00:08:06.333 --> 00:08:09.500
如果你把所有的業務邏輯都綁死在一個模型上

00:08:09.500 --> 00:08:11.733
那無異於在火山口上建房子

00:08:11.733 --> 00:08:14.666
多模型編排 本質上是在做風險對沖

00:08:14.666 --> 00:08:16.833
它把對單一廠商的依賴

00:08:16.833 --> 00:08:19.433
變成了一個可以隨時插拔的代理池

00:08:19.433 --> 00:08:21.666
這才是真正的AI主權

00:08:21.666 --> 00:08:24.166
那麼 作為一個工程師或者產品經理

00:08:24.166 --> 00:08:25.733
我們能從中學到什麼？

00:08:25.733 --> 00:08:28.700
我總結了一個多模型編排的思維框架

00:08:28.700 --> 00:08:31.466
下次你要設計AI架構時 可以套用一下

00:08:31.466 --> 00:08:33.733
第一 必須有模型多樣性

00:08:33.733 --> 00:08:36.733
如果你把三個一模一樣的模型拼在一起

00:08:36.733 --> 00:08:39.200
那不叫編排 那叫浪費算力

00:08:39.200 --> 00:08:42.400
你需要不同的知識結構 不同的推理風格

00:08:42.400 --> 00:08:45.400
比如一個擅長寫代碼 一個擅長找邏輯漏洞

00:08:45.400 --> 00:08:47.466
第二 需要智能的協調機制

00:08:47.466 --> 00:08:50.333
不要自己手寫幾百個if-else來分發任務

00:08:50.333 --> 00:08:54.233
學學Fusion 用結構化的方式去提取共識和矛盾；

00:08:54.233 --> 00:08:57.300
或者學學Fugu 用小模型去調度大模型

00:08:57.300 --> 00:08:59.266
把協調的工作交給AI去做

00:08:59.266 --> 00:09:01.433
第三 高質量的合成是靈魂

00:09:01.433 --> 00:09:04.933
多模型系統的成敗 往往取決於最後那一下合成

00:09:04.933 --> 00:09:06.333
不能簡單拼接

00:09:06.333 --> 00:09:09.533
必須有"判官"的角色去審視所有的中間結果

00:09:09.533 --> 00:09:12.433
記住 複雜問題只能通過分解來解決

00:09:12.433 --> 00:09:15.033
讓不同的模型幹自己最擅長的事

00:09:15.033 --> 00:09:18.400
這才是工程實踐的真諦 最後 我們來聊聊未來

00:09:18.400 --> 00:09:21.600
單體超級模型的時代 可能真的要結束了

00:09:21.600 --> 00:09:23.933
未來的API 不會只是調用一個模型

00:09:23.933 --> 00:09:25.666
而是調用一個編排網絡

00:09:25.666 --> 00:09:26.833
你輸入一個prompt

00:09:26.833 --> 00:09:29.100
背後可能是一羣模型在瘋狂開會

00:09:29.100 --> 00:09:32.666
隨着開源模型越來越強 比如DeepSeek V4這種

00:09:32.666 --> 00:09:35.333
預算模型的組合能力會越來越恐怖

00:09:35.333 --> 00:09:36.500
你可以想象一下

00:09:36.500 --> 00:09:39.733
一年後 你可能只需要花幾十分之一的成本

00:09:39.733 --> 00:09:43.600
就能自己搭建一個超越現在Fable 5級別的AI團隊

00:09:43.600 --> 00:09:46.366
更重要的是 地緣政治的摩擦不會停止

00:09:46.366 --> 00:09:49.666
供應鏈多元化會成為所有科技公司的戰略必需

00:09:49.666 --> 00:09:52.833
多模型編排 就是在這種不確定性下

00:09:52.833 --> 00:09:56.100
保持靈活性的一條路 一句話總結今天的內容：

00:09:56.100 --> 00:09:58.266
這不是單體模型已經結束

00:09:58.266 --> 00:10:01.366
而是説明：在深度研究等特定任務上

00:10:01.366 --> 00:10:04.833
模型編排正在成為一條新的性能擴展路線

00:10:04.833 --> 00:10:07.800
架構的力量 有時候比單純的規模更重要

00:10:07.800 --> 00:10:08.900
那麼問題來了：

00:10:08.900 --> 00:10:11.066
你的團隊現在在用什麼AI架構？

00:10:11.066 --> 00:10:15.166
如果能用一半的成本在某些任務上達到頂級模型的水平

00:10:15.166 --> 00:10:17.233
你會考慮試試多模型編排嗎？

00:10:17.233 --> 00:10:19.000
把你的看法打在公屏上

00:10:19.000 --> 00:10:21.833
如果你覺得這期硬核拆解對你有啓發

00:10:21.833 --> 00:10:24.900
別忘了點贊 投幣 收藏 一鍵三連支持一下

00:10:24.900 --> 00:10:27.133
我是 為什麼叫QQ 我們下期見！