文章作者、来源:“唐韧”(ID:RyanTang007)
早上看了个新闻,日本一家 AI 公司发布了一个新模型,号称对标目前人类最强的 Fable 5。
但看完他们的技术文档后我发现,属实有点扯。
这家名叫 Sakana AI 的公司发布了名为 Sakana Fugu 系列编排器模型,某种程度上说,这个 Fugu 都不能称之为模型,而是一个分发器。
因为这个 Fugu 本身并不是大模型基座,而是根据不同任务类型去调用其他模型能力。
比如,用户发出一个编程任务,Fugu 去调用 Claude Opus 4.8,用户发出一个数学任务,Fugu 去调用 GPT-5.5。
当然,实际的执行过程肯定比我说的更复杂,但大概逻辑其实就是这样。
所以,Fugu 自己其实并不生产模型能力,他们只是模型的搬运工。
在这种技术架构和逻辑下,他们还跟包括 Opus 4.8 和 GPT-5.5 在内的模型做了一些跑分测试。
从结果看,Fugu Ultra 的结果都超过 Opus 4.8。
另外,Fugu Ultra 在工程、科学和推理测试中,性能接近或超越了目前最强的 Fable 5 和 Mythos Preview。
看到这我在想,这家公司还真有点拿面子当里子用。
明明调用的是别人的能力,结果还说自己的模型在各项比拼中超过了别人。
当然,不能说他们毫无用处,毕竟卖水的还是要做点包装和加工。在我看来,Fugu 的核心能力其实就是任务分类和调度能力。
现在各家模型能力号称都很强,但确实各有所长,没有一个全能模型可以胜任所有任务。
因此,Fugu 算是捕捉到了这个需求,所以才做了这么一个产品。
他们会识别和判断用户提出的任务类型,然后对任务进行拆解,比如科研类、代码类、推理类,也会对是否需要调用多模态能力做判断。
接下来就是根据细分后的任务调用不同的工作模型,这些工作模型其实就是现在一些主流的模型,比如 Claude 和 GPT、Gemini 这些。
即便是在同一个任务内部,也可以根据任务拆解去调用不同模型的能力。
这种集众家之所长的模式,让 Fugu 在测评中取得了这样的成绩。本质上,它扮演了一个调度者的角色。
价格方面,Fugu Ultra 的每百万 token 输入价格是 5 美元,输出价格是 30 美元,如果上下文超过 272k,价格还会贵一点。
目前使用方式也是通过 API 调用,有专门的 API Key 和开发文档。
今天我之所以跟你们聊这个案例,其实是想说一个问题,就是 AI 发展到今天,接下来的竞争可能会发生转向。
过去是比模型能力,未来会比应用能力。
在接下来的一段时间,模型能力进化的上限可能不会像之前那么高,所以很多基于用户场景的需求会逐渐得到落地。
Fugu 就是一个典型的例子,他们有点像当年的 Hao123,自己本身只起到一个中转调度作用。
但是这种统一入口的方式,的确解决了很多人的场景化需求。
我自己现在使用 Agent 其实就有这样的问题,不同场景下的需求是交给不同 Agent 去做的,每个 Agent 用的也是不同的模型。
虽然中转站现在能解决一个 API Key 搞定所有模型的问题,但是依旧还是得各配各的。
但 Fugu 的好处就是实现了内部路由,其实一定程度上是产生用户价值的。
不过,我觉得作为一个卖水的,不确定性就在于被他们调用的模型厂商是否长期支持。
你想啊,入口被你拿走了,自己反而成了供应商,这显然不符合模型厂商的利益。
有一种可能,就是假设 Fugu 到一定规模后,大概率会受到打压,到时候模式就不成立了。
我觉得,这个例子对于做产品的读者或许会有所启发。
做产品从来不是新发明技术,而是把技术跟场景、用户、需求、产品定位组合在一起。
虽然我不看好 Fugu 的长期发展,但是这个思路是值得借鉴的,发现问题、识别需求、回归场景、给出方案。
有时候,做产品最难的不是把产品做出来,而是识别到那个需求信号。
AI 时代就这么迅速来了,但是我反而觉得产品经理的含金量提升了。
那些需要识别、洞察、判断、决策的场景,依旧少不了优秀产品经理的参与。
如果具备这些能力的产品经理能和 AI 结合,那将是生产力爆棚的。
最后,我查了下 Fugu 这个词是什么意思,原来是河豚。
看来,小日子是想一鱼通吃。


