Nate Herk · 12:15 · 发布 2026-06-23 · 11万次观看(截至抓取) · 观看原视频
🔥 观众最高回放 05:45 — 从”多模型能给出更好结果”突然转向”代价是什么?速度与真金白银”,开启 speed/cost reality 章节。
主旨
把 Sakana Fugu Ultra 当成”新模型”测试是误读——它是一个 manager 路由 Opus/GPT/Gemini 的多 agent 编排 API;在 38 任务对照下质量几乎与 Opus 4.8 平手,代价是 4.5 倍慢、5 倍贵。
核心论点
- Fugu 不是新模型,是 manager + frontier 模型的编排 API——拆任务后路由到 Opus/GPT/Gemini 等 specialists,与 Claude Code 自带的 Subagent 编排逻辑同源。(→ 详解2、4)
- 38 任务对照显示质量平手——36/38 与 Opus 4.8 打成平局,只有 2 题 Opus 胜出,胜的那次还是因为 Opus 4.8 本身就在 Fugu 的候选池里。(→ 详解7)
- 速度 4.5×、成本 5× 是真痛点——Fugu 全程 357 分钟、约 50 美元;Opus 4.8 全程 80 分钟、约 10 美元;同质结果下没有理由等更久付更多。(→ 详解6、7)
- 对接入 Claude Code 的人来说,Fugu 的体感是”靠谱但巨慢”——底层仍是 Opus/GPT/Gemini 组合,知识工作类不会更聪明,只是把”等回复”和”等开销”同时放大。(→ 详解3、6)
- Fusion API 是另一种”多模型组合”思路——不切分任务,而是把同一 prompt 并行发给三个模型再用 judge 合并;Fugu 的”切分+委派”和 Fusion 的”fan-out+judge”对应两条不同轴。(→ 详解5)
知识点详解
1. Fugu Ultra 是什么——不是新模型,而是编排 API 00:00
Sakana 在公告里把 Fugu Ultra 定位成 “delivering frontier capability without the risk of export controls” (00:05)——这是规避出口管制的卖点,不是新模型。Nate 在视频里直接把这个误解拆掉:“Fugue is not its own large language model that’s better than Fable”。
00:14 “You can see right here in my Claude Code I am running on Fugu Ultra 1 million.”
他把 Fugu Ultra 1M 上下文接入到自己的 Claude Code 里跑 YouTube 仪表盘,结果生成”真的能跑、视觉也好看”的 Web 页面。但那不是 Fugu 自己的本事——它是 Opus + GPT + Gemini 几个 frontier model 一起干出来的活。
Sakana AI 是日本 AI 实验室,“Sakana” 在日语里是”鱼”,所以 UI 上用了一群小鱼合成大鱼的视觉。这与 Fugu 河豚(箱鲀)的命名呼应,也是它”小模型聚合成大能力”的隐喻。
2. Fugu 怎么工作——manager + 多个 frontier model 的小型协调层 01:00
机制是单 API 入口,内部有一个小的 manager/conductor 模型做任务分派:
01:13 “it is a multi-agent system delivered as one model. So, basically we have one API to hit, and that API orchestrates and routes to different frontier models. So, Opus, GPT, Gemini, and probably some more.”
01:27 “Fugu achieves superior performance by dynamically coordinating and orchestrating a diverse pool of powerful models.”
manager model 本身是被专门训练来”拆任务、决定谁做什么”的——它只做编排,不做实质生成。实质内容由 Opus(写作/长链推理)、GPT-5.5(代码/修复)、Gemini(设计/事实)分别出。Nate 强调:“this is literally trained just to break down a task, and then hand it off to a bunch of different AI models”。
这与 Agent 编排(Orchestration) 在概念上同源,但 Fugu 的编排是跨厂商的——通常 agent 编排都在一家厂商的模型族内做(Claude Code 派 Haiku/Sonnet/Opus),而 Fugu 把 Opus/GPT/Gemini 一起拉进同一个工作流。
3. 怎么把它接进 Claude Code 02:32
Nate 实际演示了 Fugu Ultra 在 Claude Code 里的运行状态——自己日常的 dashboard 任务用 forward-goal (slash goal) prompt 触发,Fugu 接管后跨多个模型协作,大约一小时回了一个可刷新的 HTML 仪表盘 (00:46)。
接入方式 Nate 没在视频里详细讲,而是放在他的免费 school 社区里以 markdown 文件形式提供——“give it that markdown file, give it your API key, and you’ll be up and running”。他强调:不像 GLM 5.2 那种换 endpoint 加 API key 就能用的方式,Fugu 接入要在 routing 层改一些东西,直接调通需要动 Claude Code 的请求路径。
实际体感上,Fugu 在 Claude Code 里”可以使用他的 skill、做研究都没问题”——只是很慢且完全不耗 Claude Code 的 context window(因为 round-trip 走了 Fugu 的服务端)。
4. 编排光谱——从手写到全自动 03:30
Nate 把”谁决定谁做什么”画成一条光谱:
03:33 “On the left side of the spectrum, you write everything. You decide who does what. And on the far right end, you have a model that’s automatically doing all of this.”
- 左端:人全管,自己手动在 Codex、Claude Code 之间切换、各取所长
- 中段:Claude Code 自动 spawn sub-agent 在 Haiku/Sonnet/Opus 间分发,但仍是同一家厂商内
- 右端(Fugu):全自动跨厂商分发,你只丢任务、收结果
Nate 强调这条光谱不是新概念——你在 Claude Code 里每天都在做,只是用手动方式选哪个 sub-agent 干什么。Fugu 把”决定谁做什么”这一小步自动化了。
编排本身就是两个小问题 (04:34):谁做哪块(分派)和怎么把结果合起来(组合)。第二个问题还需要一个 LLM 读所有 specialist 输出再做合并,这是隐藏成本——Fugu 内部还会再调一次合并模型,所以单次 API 调用背后实际可能跑了 2-3 次推理。
5. vs OpenRouter Fusion API——切分 vs fan-out 05:07
视频里 Nate 主动把 Fugu 与同期的 OpenRouter Fusion API 做了区分:
05:18 “the Fusion API, what that does is it sends your prompt to three models all at once. So it doesn’t break up the task and delegate, it just says, all three of you guys answer this. And then it comes back with a judge that merges all three.”
两者都是”组合多模型”思路但走法相反:
- Fugu:manager 切任务 → 不同 specialist 出对应子答案 → 合并模型汇总。优势是效率高(每个子任务最小),但不擅长需要多视角的任务(如开放式写作评估)。
- Fusion API:同一 prompt 复制三份 → 三个模型各自出完整答 → judge 模型挑/合。优势是天然多视角、适合”哪个答案更好”的问题,但浪费 3 倍推理成本。
Nate 的结论:“when you’re getting different perspectives and you’re getting different large language models processing your stuff, you’re probably going to get better results”——但代价是速度与金钱,这两点他马上在下一节拆。
6. 速度与成本——4.5× 慢、5× 贵 05:39
视频专门用一节给”代价”打预防针:
05:49 “I went for a 200 dollars a month plan and I filled up my 5-hour window and I’m at 34 percent of my weekly limit.”
200 美元月费档、5 小时窗口,半小时就吃掉 34% 周额度——这个消耗速度比 Nate 自己的 Claude Code 订阅还快得多。背后逻辑很直接:每次 Fugu 调用的实际成本是多个 frontier model 的推理总和。
观众最高回放的 05:45 节点正是从”多模型给更好结果”突然急转”代价是什么?速度与真金白银”——这一拍是观众反复回看的转折点,所有”看似免费的能力”都要先算经济账。
7. 38 任务对照测试 06:28
测试设计:Nate 用 ChatGPT Codex 生成了 38 个题(避开 bias),用 API 计费方式跑过 Opus 4.8 和 Fugu Ultra,Codex 当 grader。题目分四波——puzzles、traps、specs、heavy algorithms,每题做 pass/fail 二元判定。
质量结果:36/38 平局,Fugu 没赢过;Opus 赢了 2 题。但讽刺的是 Opus 4.8 本来就是 Fugu 候选池里的模型——“60% of this was built with Opus 4.8” (02:56)。
07:07 “Overall, we had 36 of the 38 tasks end in a tie. We had Fugu being 4.5 times slower overall and five times more expensive.”
速度结果:Fugu 累计 357 分钟,Opus 累计 80 分钟 (09:36)。Nate 特别点出”一些非常简单的题,Opus 6 秒答完,Fugu 同一个题要好几分钟”——多步编排在简单任务上是纯亏。
成本结果:Opus 全程约 10 美元,Fugu 全程约 50 美元 (10:04)。Nate 原本预期更贵但没预期 5 倍,且没有看到对应的质量提升。
体感:在 Claude Code 里跑 Fugu 做知识工作”really solid but really slow” (08:10)——本质就是 Opus/GPT/Gemini 那些模型的能力,不会因为换了包装就更聪明。
8. 总结判断——不切,但会盯着 10:27
Nate 的最终立场很明确:
10:41 “my honest takeaway is for my use cases, Fable noticeably felt better than Opus 4.8. But Fugu Ultra does not noticeably feel better than Opus 4.8.”
但他不否定方向:
10:51 “I really do think that this is amazing, these metrics that they were able to get, and I do think that this is the future. Not locking yourself into one provider.”
他给读者留下的核心技能命题 (11:00):“understanding how to play with the unit economics to understand what is the cheapest model that I can use for this task that doesn’t sacrifice quality”——
不是”哪个模型最强”,而是”哪个模型对这个任务性价比最高”。当 Fable 5 回归(且大概率更贵)、多家模型都在涨价时 (11:28),这个能力会成为越来越值钱的杠杆。
9. 收尾与社区 11:45
Nate 在结尾用两件事收:一是他会继续关注 Sakana AI 与编排方向,但短期内不会切;二是引他免费的 school 社区(超 40 万人),并把接入 Fugu 的 markdown 文件、整套 prompt 与 skill 模板都放在那里。Fugu Ultra 与 Fugu 同账号分两个产品档,他只测过 Ultra(明示,避免无对照)。
可执行步骤
- 打开 Sakana.ai 注册账号,在订阅档($200/月 5 小时窗口)与 API pay-as-you-go 之间按用量规模选型;先小量试跑再升级。
- 加入 Nate 的 free school 社区(描述区链接),在”all YouTube resources”里下载 Fugu-on-Claude-Code 的 markdown 文件,按其说明把 API key 接入。
- 跑 5-10 个与 Opus 4.8 相同的小型任务,自己统计两者的 latency 与 cost,验证”4.5× 慢、5× 贵”是否对你的工作流成立。
- 评估自己是不是”多模型共同在跑同一代码库”的开发者——Nate 指出那种场景他没充分测,Fugu 的价值可能在团队型软件工程里更大 (08:20)。
- 把”每个任务用什么模型最划算”列成可复用的 routing 清单(参考 模型分散 笔记),而不是默认”用最强的那一个”。
关联
- 互补 OpenRouter——Fugu 与 OpenRouter 都是”一个 key 跨多家模型”,但 Fugu 多一层自动任务切分与合并(manager + judge),OpenRouter 只做”按需路由”;Fugu 走”全自动”,OpenRouter 走”半自动”。各自覆盖”组合多模型”这条轴的不同半。
- 互补 模型分散——模型分散强调”主力 70% + 多家分流,手动组合”,Fugu 是把”手动组合”自动化成”manager 自动选”——目标相同,执行力度不同;你若已经在用模型分散的纪律,接入 Fugu 的边际收益会被 5× 成本抵消,反之亦然。
- 印证 Agent 编排(Orchestration)——Fugu 在生产环境用近一年(2025-Q3 公布、2026 年中病毒传播)的实验数据再次证明:多 agent 跨模型编排能跑通、是方向;但前提是总成本必须小于单模型加起来的成本——Nate 的 5× 贵证据给”单 API 编排一定更优”画了一条明确的经济边界。
一手来源与延伸
(无可收录的一手链接——视频 .meta.json description 内的全部 URL 均为博主自身课程/社群的导流,无 Sakana Fugu 官方公告、Fugu 模型技术说明或 benchmark 原始论文链接;按规则本节删除,避免贴猜的链接。)
术语
- Fugu(Sakana Fugu):Sakana AI 出的”多模型编排 API”,不是单一大模型,而是一个 manager model 拆任务后路由到多个 frontier model 协同的包装层
- Fugu Ultra:Fugu 的大上下文版本(1M context),本视频唯一测试的产品档
- Sakana AI:日本 AI 实验室(Sakana 在日语里是”鱼”),“小鱼合成大鱼”是产品视觉与产品哲学的双关
- Conductor model / Manager model:Fugu 内部的小型编排模型,被专门训练来”拆任务 + 派任务”,不做实质内容生成
- OpenRouter Fusion API:OpenRouter 提供的”同一 prompt fan-out 给 N 个模型 + judge 合并”的多模型融合 API,与 Fugu 的”切分+委派”是另一条多模型组合轴
- Frontier model:OpenAI/Anthropic/Google 等厂商的旗舰大模型(此处特指 Opus 4.8、GPT-5.5、Gemini 等)
金句
“Fugue is not its own large language model that’s better than Fable.” — 戳破”Fugu = 新模型”误解的关键澄清,提醒读者把 Fugu 当 manager 看待而非竞争者 (01:38)。
“Fugu achieves superior performance by dynamically coordinating and orchestrating a diverse pool of powerful models.” — 官方对 Fugu 机制的最简定义,读懂这一句就懂 Fugu 不是模型 (01:27)。
“I had to wait in total for all of the Fugu runs 357 minutes, whereas for Opus, I was waiting total of 80 minutes across these 38 different tasks.” — 4.5× 慢的硬数字,38 任务总时长而非单任务平均,凸显”等不起”的工程现实 (09:36)。
“understanding how to play with the unit economics to understand what is the cheapest model that I can use for this task that doesn’t sacrifice quality.” — Nate 留的”未来核心技能”命题,把”用最强模型”的旧思维换成”按任务挑最便宜够用模型” (11:00)。
立场与利益
本片关键主张按博主商业关联度分档:
- 与利益同向(待印证):
- “继续用 Claude Code/Codex 比切到 Fugu 好”——Nate 卖 AI OS / Claude Code 相关付费课程(skool.com AI Automation Society, 描述里有 referral),保留订阅是直接保住他能继续卖课的地基;需要外部独立 benchmark 印证”Fugu 在知识工作类不可替代”。
- “单位经济学(unit economics)是核心技能”——这也是他 AI 课程内容方向,主张同向于课程卖点。
- 利益中性(可独立验证):
- Fugu 的 manager + specialists 机制(技术事实,与课程商业无直接挂钩)。
- 36/38 平局、4.5× 慢、5× 贵的具体数字(可由第三方重跑复现)。
- 编排光谱(左手动 → 右自动)的概念描述(通用方法论)。
- 与利益反向(可信度最高,单独标出):
- “我不切,我留 Claude Code 与 Codex”——这句话没有任何商业动机,他不卖 Fugu 也不卖 Sakana 任何产品;承认”短期不值得”是降低读者决策成本而非维护自己生意;Nate 同时承认”this is the future”又把方向标对,展现的是不偏袒的实测态度。
利益证据(不枚举):描述里有 skool 课程(导流)、Glaid(免费月 affiliate)、Hostinger(NATEHERK 优惠码 affiliate)、UppitAI 咨询服务(自营);全部为他自己的 AI 业务线,与 Sakana AI 无任何商业关联,这是他给 Fugu 差评却可信的根本原因。
价值定位
适合谁:已经在用 Claude Code / Codex 做知识工作或单兵开发的实践者,看到”自动编排”宣传想决策要不要切工具的人;以及正在搭建自己多 agent 系统的工程师,想参考”前人实测的边界”。
解决什么:用一个 38 任务对照的实测样本,定量回答”Fugu 是不是 Fable Killer”——结论是对 Opus 4.8 而言不是,但对更复杂的”多模型同时在跑同一代码库”的团队型软件工程,Nate 自承”没充分测、可能有价值”。
认知 vs 实操:本片是决策类内容(切不切工具)而非”教学”内容;真正可执行的动作(接入方式)在 Nate 的免费 school 社区的 markdown 文件里,本视频只展示结果与数字。
与 Agent 编排(Orchestration) / 模型分散 / OpenRouter 笔记有重叠:本片独有的是”38 任务、4.5× 慢、5× 贵”这一组数字结论,以及”manager model 只做编排不做生成”的具体机制描述;通用编排原理不重述,看那些笔记。
自检问题
- Fugu Ultra 与传统 frontier model(比如 Opus 4.8)在本质上有何不同?为什么说”它不是新模型”? 答案:Fugu 不是单一大模型,而是 manager model 拆任务后路由到 Opus/GPT/Gemini 等 frontier specialists 的编排 API;质量上限由底层 specialists 决定,不高于其候选池中能力最强的模型——见详解1、2(→ ?t=5,73)。
- 在 Nate 的 38 任务对照测试中,Fugu Ultra 与 Opus 4.8 在质量、速度、成本三方面各表现如何? 答案:质量 36/38 平(剩 2 题 Opus 胜)、速度 Fugu 慢 4.5×(357min vs 80min)、成本 Fugu 贵 5×($50 vs $10)——见详解7(→ ?t=427,576,604)。
- Fugu 与 OpenRouter Fusion API 在”组合多模型”上有什么本质区别? 答案:Fugu 走”manager 切分任务 → specialists 出子答案 → judge 合并”路线,Fusion API 走”同一 prompt fan-out 三个模型 → judge 合并”路线;前者按子任务分工、效率高,后者按视角并列、天然多视角但浪费 3× 推理——见详解5(→ ?t=318,325)。
- Nate 的”未来核心技能”主张是什么?为什么他把它留到 Final Takeaway 章节? 答案:“按任务挑最便宜够用模型”取代”用最强模型”,是 unit economics 思维;在 Fable 回归、所有模型可能涨价背景下,这个能力会成为越来越值钱的杠杆——详解8(→ ?t=660)。