Fugu Ultra：一种AI协调模型如何挑战GPT与Claude
解释了 Sakana AI 的 Fugu Ultra v2 如何将任务分配给多个专业模型而非依赖一个庞大的大型语言模型，以及它在基准测试、价格和透明度方面的表现如何。
来源: This AI Model Beats GPT-6 and Claude Opus 5 — Without Even Using Them
这里重要的并非排行榜上的分数，而是产生这些分数的思维过程。
关注过去一年中各类AI模型的发布情况，你会发现一种规律。
参数更多。
上下文窗口更大。
基准测试分数略高一些。
生成文本的token成本更低。
又一款号称“目前最强大的模型”。
然而在9月11日，Sakana AI推出了Fugu Ultra v2.0，而这次发布打破了这一规律。
引人注目的并非基准测试分数本身。
真正值得关注的是产生这些分数的机制。
Fugu Ultra并不追求成为地球上最聪明的AI模型。
相反，它着眼于一个完全不同的问题：
如果最强大的人工智能系统并非单一模型，而是一个足够智能、能够判断该用哪个模型来解决特定问题的系统，那会怎样？
从长远来看，这个问题可能比任何一次基准测试的胜利都更为重要。
那么，Fugu Ultra究竟是什么？
这就是让Fugu区别于其他产品的第一个特点。
Fugu Ultra的运作方式不同于GPT或Claude这类标准模型。
Sakana将其定义为控制器，或者说协调层。
可以把它想象成一位擅长管理团队的工程经理。
你把一个复杂的任务交给他。
与其试图亲自处理任务的每个环节，控制器可以：
- 解析任务内容
- 将任务拆分成更小的子任务
假设你提交这样的请求：
“分析这家公司的财务报告，生成图表，标出异常点，并总结分析结果。”
传统模型会试图用一套统一的技能来完成整个请求。
而协调式系统则将同样的请求视为分配给团队的项目：
文档解析 → 专用模型 数据解读 → 另一种专用模型 图表分析 → 面向视觉或数据的专用模型 代码编写 → 编程专家 整合所有部分 → 控制器
从使用者的角度来看，这仍然看起来像是一次单一的API调用。
不过在幕后，你实际上是在与由另一套人工智能系统协调管理的多个AI模型进行交互。
据报道，Sakana的模型库结合了开源模型与专用模型，其中包括NVIDIA的Nemotron系列。
从这里开始，事情才真正变得有趣起来。
基准测试数据
根据Sakana自行公布的数据，Fugu Ultra v2.0在多个基准测试类别中均取得了优异成绩。
该公司称，Fugu在8项基准测试中的5项中表现最佳或并列第一，另有7项中位列前二。
其中最引人注目的数据是DeepSWE：74.3。
DeepSWE值得关注，因为它衡量的是软件工程能力，而非简单的编程题测试。
Fugu在Chartography、SWEFish、GDP.pdf和Toolathon这些测试中的表现也同样出色。
Fugu Ultra v2与其他前沿模型的对比
根据相关对比结果，Fugu Ultra v2的表现优于多个知名系统，其中包括：
- Claude Opus 4.8
- GPT-5.5
- Gemini 3.1 Pro
据称它在Chartography这一基于图表及其他结构化视觉数据解析的基准测试中尤为出色。
需要强调的是：
这些数据是Sakana对其自身系统公布的。
在目前所报道的时间点，尚无独立实验室能够复现这些数值。
这一点很重要。
即便由模型开发公司发布的基准测试结果看起来很亮眼，仍需外部验证才能完全被信任。
因此，处理这些结果的公平方式是：
确实有趣，值得进一步深入研究。目前尚无定论。
基准测试情况
可以说，这里最具参考价值的并非某个单一分数，而是8项中的5项这一数据。
为什么它更重要？
因为仅在一个特定基准测试中取得胜利往往只意味着该模型是为完成那个具体任务而调优的。
能在多种不同类型的任务中都名列前茅，才是更有意义的信号。
不过仍需重申：这些是自我报告的结果，并非经过独立验证的。
更有趣的对比：这些系统的思维方式
这里真正的区别或许不在于分数本身，而在于其底层架构。
传统边界模型
User
↓
One large model
↓
Answer
GPT、Claude和Gemini大多遵循这种设计，不过它们当前的产品越来越多地加入了自定义的路由逻辑、工具使用功能以及类似智能体的行为。
Fugu的思路
┌── Coding specialist
│
User → Controller├── Vision specialist
│
├── Reasoning specialist
│
└── Other models
↓
Final answer
这重新定义了整个优化难题。
与其问：
“如何构建一个在所有方面都更出色的单一模型？”
Sakana实际上是在问：
“如何更擅长为每个具体问题选择合适的模型？”
这是一种根本不同的思路。
Fugu与Claude、GPT、Gemini及DeepSeek的对比
那么Fugu与人们在选择AI服务提供商时通常会考虑的系统相比如何呢？
Claude
Claude在需要复杂推理、编程及长篇写作任务的场景中，依然是首选之一。
它的最大优势在于开箱即用就能获得一个功能强大的通用模型。
无需自行考虑如何协调多个模型。
Fugu则采取完全相反的策略：模型间的协调本身即为产品核心。
GPT
OpenAI一直致力于提升通用模型的能力，同时不断添加各类工具与智能体功能。
Fugu的理念则几乎与之相反：
它不试图让单个模型处理所有任务，
而是构建一个能够同时协调多个模型的系统。
随着可用模型数量的不断增加，这种差异变得越来越重要。
Gemini
当多模态输入、极大的上下文窗口或与谷歌更广泛的生态系统整合成为重点时，Gemini往往能表现出色。
Fugu的独特之处并不在于其多模态支持能力或上下文长度本身。
真正关键的是位于多个底层模型之上的路由层。
DeepSeek
DeepSeek提供了另一个值得考虑的选择。
对许多开发者而言，它的吸引力源于一个简单的原因：
在极具竞争力的价格下仍能保持出色性能。
Fugu则追求完全不同的目标。
它不会问：
“哪种模型是最便宜且能处理此任务的？”
而是其控制器会询问：
“哪种模型最适合处理这项任务的特定部分？”
那是两个不同的优化问题。
还有定价问题
在定价方面，情况变得更加有趣了。
Sakana显然将河豚模型分成了两个定价层级。
Fugu Max
输入成本：每百万个标记2美元
输出成本：每百万个标记6美元
根据公布的数值，其价格比该公告中提到的几款竞品模型低约40%到60%。
Fugu Ultra v2
输入成本：每百万个标记5美元
输出成本：每百万个标记30美元
对于需要超过272,000个标记上下文的提示，其费用则上升为：
输入成本：每百万个标记10美元
输出成本：每百万个标记45美元。
据说Ultra层级还具备100万token的上下文窗口，以及2026年8月的知识更新截止时间。
价格对比
上述数据（按每百万token计算）来自原始资料；在做出购买决定之前，您应核实各供应商当前公布的实际价格。
但有个问题
这可以说是整个Fugu方案中最值得注意的复杂之处。
任务协调并非免费服务。
每当系统需要：
- 将任务拆分成多个部分
- 调度这些部分
- 调用其他模型
- 等待该模型的回复
- 检查结果质量
- 再将所有部分整合起来
都会产生额外的开销。
这种开销会表现为更高的延迟。
试想这样一个请求：
“帮我写一条关于咖啡的推文。”
对于这么简单的需求，几乎完全没有必要使用协调层来管理多个专用模型。
这就好比为了拧紧一个松动的水龙头而请来一整个咨询公司。
再对比一下更复杂的任务：需要输入一份冗长的技术文档，让系统遍历相关的代码库，找出设计缺陷，权衡多种可能的解决方案，最终制定出实施最佳方案的具体计划。
在这种情况下，协调层的作用就显得非常重要了。
隐藏的问题：黑箱效应
还有另一个问题，甚至可能比速度更为重要。
通常你无法知晓究竟是哪个底层模型处理了请求中的各个部分。
对于普通消费者而言，这并非大问题。
但对于企业应用来说，这可能成为一个严重的障碍。
试想那些需要处理以下内容的机构：
- 机密源代码
- 财务记录
- 客户信息
- 专有文档
- 受监管的数据
如果路由层在幕后悄悄选择不同的模型，企业自然会希望得到如下问题的答案：
究竟是哪个模型处理了我的数据？它在何处被处理？到底有哪些数据被发送给了各个模型？路由决策是否可审计？能否让特定的工作负载仅使用经过审批的模型？
这些并非假设性的担忧。
在企业环境中，对系统进行监控与管理的能力往往与模型本身的智能水平同样重要。
任何希望被视为核心基础设施而非仅仅另一个API封装层的编排平台，最终都需解决这些管理上的缺陷。
为何这比单一模型发布更为重要
以下正是最值得关注的观点。
假设某竞争对手下个月推出性能大幅提升的编码模型。
传统的模型供应商需要重新训练、评估，并发布全新的版本。
而基于编排的系统则可以直接将新模型加入现有的选项池中。
如此一来，管控层便多了一位可调用的高级专家。
这无疑是一大优势。
最终的架构大致如下所示：
AI Model A
│
AI Model B
│
User → Controller → AI Model C
│
AI Model D
│
AI Model E
在这种模式下，由于周边模型生态的持续改进，整个系统的能力便能不断提升。
控制器本身并不一定需要在每次迭代中都变得极其智能。
它需要的是不断提升决策能力。
这种重点的转变或许会成为代理型人工智能未来的重要发展方向。
更大规模的AI竞争可能正在发生变化
很长一段时间里，AI发展的模式相当可预测：让模型更大、提供更多训练数据、提升其推理能力、投入更多计算资源，然后重复这一循环。但这种模式似乎已不再适用。
第一代
单个模型独立处理所有任务。
第二代
单个模型与外部工具结合使用。
第三代
一个智能体协调多个工具与模型。
第四代？
一个能够根据所面临的问题即时组建定制化模型团队的系统。
最后这个阶段似乎正是Fugu所追求的目标。
如果这一设想成真，未来最有价值的AI产品可能并非那些推理能力最强的模型，而是那些足够聪明、能够识别出何时根本不应使用某个特定模型的系统。
真的应该使用Fugu吗？
以下是具体的分析。
适用于简单的API式任务
或许可以跳过它。
如果你的应用场景包括以下内容：
- 简短摘要生成
- 简单的分类任务
- 常规内容创作
- 快速的事实查询
那么额外的协调层很可能并不值得增加这样的复杂性。
针对复杂的智能体系统
这里就变得有趣了。
尤其适用于以下工作：
- 软件开发
- 研究任务
- 分析大量文档
- 数据密集型处理流程
- 多阶段推理链
- 自主智能体行为
- 需要多种不同专业技能解决的问题
正是在这类场景中，模型间的路由功能才开始显现其价值。
总结
现在就宣称Fugu Ultra是GPT或Claude的终极继任者还为时过早。虽然其基准测试成绩相当出色，但这些数据目前来自厂商自身，在得出明确结论之前仍需进行独立验证。
尽管如此，若将此视为基准测试竞争中的又一场较量而忽视其本质，那就错了。这里的关键在于架构设计，而非数值指标。
OpenAI、Anthropic 和谷歌都投入了大量资源，力求让各自的模型具备尽可能强的能力。而 Sakana 似乎在验证另一种假设：
也许目标并非打造一个完美无缺的模型，而是为一系列有缺陷的模型构建一个出色的协调器。
这虽只是概念上的微小转变，但绝非无关紧要。如果这一假设得到验证，它可能会彻底改变未来人工智能应用的开发方式。
最终胜出的人工智能系统未必是参数最多、上下文窗口最长，或在任何排行榜上得分最高的那个。它可能只是那个能够审视一项任务并得出结论的系统：对于这项特定工作，这个模型才是最合适的。
这正是 Fugu Ultra v2.0 值得关注的部分，而非排名表。