Sakana AI 想帮你把选择大模型这件事变成别人的问题

两年来，使用生成式 AI 构建应用的核心决策一直是一个选择题：用哪个模型？哪个版本？哪个层级？每个产品团队都进行过同样的筛选：用前沿模型处理复杂推理，用更便宜的模型处理批量任务，也许再用一个开放权重模型处理必须内部执行的任务。结果是 API 密钥、提示格式、回退机制和计费面板纠缠不清。这就是集成债务，而每增加一个模型，它就会扩大。

Sakana AI 的答案是 Fugu，旨在将选择权完全从开发者手中移除。根据其产品描述，Fugu 提供“一个 API，以优化方式访问所有模型”：一个通过单一端点可达的专用模型协调池，模型选择和切换针对每个任务自动处理。其明确目标是降低 API 复杂性，同时提升成本效益。这就是全部卖点，而正因为它如此朴实无华，才值得认真对待。

本报告涵盖的内容

• Fugu 实际声称的内容，以及它没有声称的内容
• 为什么“一个 API”已悄然成为一个产品类别
• 成本效益论据及其隐性成本
• Sakana AI 应对该问题的独特视角
• 路由器无法回避的开放性问题

去掉包装后的卖点

从字面上看，Fugu 做出了三项声明。第一，单一 API 背后不是一个通用模型，而是一组专用模型。第二，Sakana 称之为 Fugu 的路由层逐个任务地选择和切换这些模型。第三，这种组合降低了使用多个模型的操作开销，同时获得更高的每美元性能。

这些声明单独来看都不算稀奇。重要的是它们的包装方式。其价值主张不是更聪明的模型，而是决策的消失。在这个意义上，Fugu 与其说是一个 AI 产品，不如说是一个抽象层，就像负载均衡器之于 Web 服务器，CDN 之于内容分发。成熟市场中有趣的产品，往往是那些隐藏市场自身复杂性的产品。

为什么“一个 API”成为一个品类

路由的想法并非凭空出现。随着可用模型数量激增, , 专有前沿模型、开放权重家族、针对窄任务调整的精简小模型, , 选择成本也随之上升。一个单一应用可能确实需要不同的模型来处理分类、长上下文摘要、代码生成以及廉价的大批量调用。直接连接每一个模型意味着要分别维护每一个。

聚合器和路由器的出现，是为了将这种表面面积压缩到一个接口中。“模型作为实现细节”已成为一种可识别的设计理念。Fugu 将 Sakana AI 坚定地置于这一阵营。其背后的赌注是方向性的：随着时间的推移，开发者将越来越不关心哪个模型运行了某个任务，而更关注结果、延迟和价格。就像如今大多数工程师不知道或不关心是哪台物理服务器响应了他们的 HTTP 请求一样。

如果这个赌注是对的，那么路由器就是持久层，而各个模型则是其下可互换的廉价商品。如果错了，如果顶级模型之间的差异仍然很大且值得手动优化，那么路由就是图个方便，而不是护城河。

成本效益计算及其限制条件

Fugu 做出的最具体承诺是经济层面的：通过将每个任务发送到能够最高效处理它的模型，实现更好的成本效益。这个逻辑是成立的。将一个简单的提取任务发送给前沿模型，就像请一位专科外科医生来贴创可贴。虽然可行，但你多花了钱。一个能够识别简单任务并将其分派给廉价模型的路由器，在数百万次调用中能带来实实在在的节省。

但限制条件同样真实存在，任何评估这类产品的团队都应牢记以下几点：

• 路由本身就是一个模型决策。 要准确分类任务以达到正确路由，需要计算资源，并且可能引入延迟或路由错误。将任务错误地路由到较弱的模型，会导致静默的质量下降，而不是明显的错误。
• 行为在不同模型之间会变得非确定性。 当回答某个提示的模型可能在每次调用时变化时，输出风格、格式和边缘情况处理都可能发生漂移。对于任何依赖一致性的工作来说，这都令人头疼。
• 可观测性变得更难。 调试“为什么这个答案变差了？”在答案可能来自与昨天不同的模型时，会变得更加复杂。

这些都不是否定因素。它们是抽象化的代价。对买家而言，全部问题在于：集成工作和推理开销的减少是否超过了新增加的不透明性。

Sakana AI 的独特视角

Sakana AI 是东京的一家实验室，由前谷歌研究员联合创立，其身份建立在受自然启发的方法以及组合模型而非构建越来越大的单体模型之上。这一知识脉络在其公开研究 中有所描述。一个协调一组专用模型而不是把一切押注在一个巨型网络上的产品，与这种世界观高度一致。在行业大部分力量追逐规模之际，Sakana 反复提出的论点是：智能可以通过协同工作的许多更小、更专业的部件组装而成。

Fugu 可以看作是这一论点的商业体现：不是单一的生物体，而是一群鱼。这个名字, , 日语中的河豚, , 很适合一个喜欢水生隐喻的实验室，尽管它也不经意间提醒人们，河豚是一道以准备功夫至关重要、一旦出错便很危险的菜肴而闻名的菜。编排也是如此，成也执行，败也执行。

路由器无法回避的问题

原始资料告诉我们产品的形态，而非其被证实的性能。仍有几个问题悬而未决，将决定 Fugu 是基础设施还是新奇玩意儿。

池中包含哪些模型，由谁控制？ 路由器的质量受限于它的目录。Fugu 是使用 Sakana 自己的模型、第三方前沿模型、开放权重模型还是混合使用，以及谁来决定何时更改列表，这些都将影响性能和锁定程度。

路由的透明度如何？ 向生产环境交付的团队需要知道是哪个模型回答了问题，并且能够在必要时固定行为。对于任何有合规性或可重复性要求的团队来说，黑箱式路由器很难被接受。

节省的成本实际落在何处？ “更有成本效益”是一个最好用团队自己的流量来验证的说法。路由带来的节省在原则上是真实的，但高度依赖工作负载。一个所有任务都同样困难的应用，几乎没有路由的必要。

Fugu 所阐明的是发展方向。随着模型数量增加且它们在边缘上的差异缩小，战略价值会向上迁移。从模型本身，迁移到决定使用哪个模型的这一层。Sakana AI 并非唯一看到这一点的公司，但它正在明确提出一个产品论据：选择本身是值得抽象化掉的额外开销。对于那些被 API 密钥淹没的开发者来说，这个论点会奏效。而证明，就像处理河豚鱼那样，在于准备功夫。