不是又一个大模型，而是把「编排」做成了产品
2026 年 9 月 11 日，Sakana AI 发布了 Fugu Max 与 Fugu Ultra v2。两者都不是传统意义上的基础模型，而是同一套多智能体编排架构的两个工作点：系统读取请求，动态决定由池子里的哪些模型参与、如何分工，再合成结果，对外只暴露一个兼容 OpenAI 协议的端点。
把这条消息放进 9 月的行业节奏里看会更有意思。同一个月，OpenAI 把 Agents API 推进公测，把 Codex 的编排框架做成托管运行时；Sakana 选择的是另一条路——不做平台，把编排本身交付成一个模型端点。一个是“编排即平台”，一个是“编排即 API”，两条路线在同一个月份正面相遇。
两轴战略：能力与成本同时推
Sakana 在发布说明里的论证方式很直白：过去十年行业沿单一轴竞赛，就是把基础模型做得更大更贵；但对真实任务而言，前沿其实是二维的——能力是一轴，成本是另一轴。用一个数万亿参数的模型去执行一次简单的数据查询，不是聪明，是浪费。
基于这个判断，Fugu Max 与 Fugu Ultra v2 被设计成两个优化目标。Fugu Max 问的是“在尽可能低的成本下，我们能交付多好的结果”，它的做法是扩大可编排的模型池，把任务路由给池中最轻、但足以完成的模型。Fugu Ultra v2 问的是“在复杂多步任务上，我们能达到多高的能力上限”，同样的编排架构，但把算力与路由预算花在需要强推理、工具调用与视觉理解的任务上。
架构：一个协调器，一个指挥
根据公开的技术说明，Fugu 的编排逻辑由两部分组成。一层是 TRINITY，一个参数量约 6 亿的轻量协调器，负责给池中的模型分配角色，大致分为思考者、执行者与校验者。另一层是 Conductor，一个 70 亿参数规模的模型，用强化学习训练，负责在运行时生成自然语言的协调策略；它可以在需要时递归调用自己，从而在不改变外部 API 的前提下提升测试时的计算量。
Fugu Max 相对前代的主要变化是模型池的扩张，纳入了更多开放权重与专用模型，其中包含通过新合作接入的英伟达 Nemotron 系列。Sakana 强调路由逻辑是“学出来的”而不是手写规则，也就是说，编排器被训练成能跨编程、数学、推理与知识类任务泛化，而不是依赖工程师维护一张静态路由表。
自报的数字与代价
价格是这次发布被讨论得最多的部分。Fugu Max 定价为每百万输入 token 2 美元、每百万输出 token 6 美元，且不随上下文长度变化；官方称其输出价格比 Claude Sonnet 5、GPT-5.6 Terra 与 Kimi K3 低 40% 到 60%。Fugu Ultra v2 定价为每百万输入 5 美元、输出 30 美元，在超过 272K 上下文时升至 10 美元与 45 美元，保留 100 万 token 的上下文窗口。
能力侧的基准全部来自厂商自报，需要标注口径：Fugu Max 在六个基准上取得其口径下的最佳总分，包括 Terminal Bench 2.1、GPQAD、AA-LCR、GDP.pdf、AutomationBench，以及 Sakana 内部用于反映自身编程用例的 SWEFish；官方称其在十个基准中的七个上扩展了成本与性能的帕累托前沿。Fugu Ultra v2 在图表理解与数据解读基准 Chartography 上得到 48.3，Sakana 列出的对照为 Opus 5 的 27.3 与 Fable 5 的 29.5；在软件工程基准 DeepSWE 上得到 74.3；在八个基准中取得五个最佳或并列最佳，七个进入前二。Sakana 同时说明，Ultra v2 的模型池中不含 Fable 5、Fable 5.1 与 GPT-6 Astra，因此这些分数不是靠背后调用前沿模型得来的。
Ultra v2 相比上一版还补齐了三项工程能力：原生视觉输入（图片与 PDF）、通过 tools 与 tool_choice 的函数调用，以及通过 response_format 传入 JSON schema 的结构化输出。训练截止时间更新至 2026 年 8 月 28 日。迁移成本方面，已有的 Fugu 用户只需改一个参数，客户端、密钥与请求结构都不变；除官方端点外，该模型也在第三方网关渠道提供，官方另有每月 20、100、200 美元三档订阅。
四条必须知道的边界
价格之外，官方与公开报道披露的约束同样重要。
一条是区域可用性。该服务目前不覆盖欧盟与欧洲经济区，Sakana 表示正在推进合规但未给出时间表。对基础设施在欧洲的团队，这直接排除了选项。
第二条是权重不可得。它只提供托管 API，不支持自托管、权重审计或离线推理。对需要模型可审计、可私有化部署的场景，这是一道硬门槛。
第三条是延迟不确定。编排系统每次请求可能协调多个模型，链路更长；此前版本在 2026 年 6 月曾被用户反馈在峰值负载下出现较长的等待。本次发布说明没有正面回应这一点，因此对延迟敏感的在线业务需要自行压测。
第四条是路由不透明。用户无法控制、也看不到请求具体由池中哪个模型处理。这在成本优化上是特性，在可复现性与故障定位上是负担——尤其对需要向监管或客户解释“这个结论是怎么来的”的场景。
中立思辨
需要辩证看待几件事。其一，所有性能与成本对比都来自厂商自报，且相当一部分基准是内部或半内部性质，独立复现尚未出现，因此“帕累托前沿扩展”这一表述应理解为“在厂商设定的评测条件下成立”。其二，价格优势的来源是任务分级而非模型更强，也就是说省下的钱本质上是“把简单任务从贵模型上挪走”，这对任务难度分布不均的负载收益明显，对全是难题的负载收益有限。其三，路由层不透明与工程可复现性存在结构性张力：当结果出现偏差时，团队既无法复现路径，也难以判断是路由选错了模型还是模型本身出错。其四，把“可替换的模型池”包装为供应链韧性是合理的叙事，但也意味着输出质量的稳定性依赖池中所有模型的表现，任一模型的版本更新都可能改变整体行为，而用户看不到变更通知。其五，编排系统把模型选择从应用代码搬进服务端，短期降低了开发成本，长期却把一项关键能力交给了外部黑盒——当企业需要针对自身业务做精细化路由时，可干预空间有限。其六，按量计费的成本优势需要与延迟、可观测性成本一起核算，如果因为延迟上升而需要额外扩容或引入更复杂的重试机制，账面上的节省可能被抵消。
趋势研判
短期看，多模型路由会从“演示技巧”变成生产标配，尤其是编码、数据抽取、客服这类任务难度分布极不均的场景；中期看，路由层会逐渐从模型厂商的私有能力，演化为可观测、可干预的独立产品层，企业会要求看到“这一跳为什么选它”；长期看，真正的分水岭可能不在路由准确率，而在责任归属——当编排器选错模型导致错误动作，责任落在编排服务、模型提供方还是应用方，这个问题的答案会决定路由层需要保留哪些证据、开放哪些控制点。
对正在做选型的团队，一个务实的起点是先把自己过去一个月的请求按难度分层统计：如果大量请求其实只需要轻量模型，那么路由带来的收益是真实且可观的；如果请求集中在少数高难任务上，那么把预算花在提升单次调用的可靠性与可观测性上，回报可能更高。