Fugu Max

1. 成本优先的模型路由

这是 Fugu Max 和 Ultra v2 最大的区别。

Ultra v2 更倾向选择能力更强的模型，而 Max 会优先寻找能够完成任务、同时成本更低的方案。

系统会根据任务需求筛选模型，再决定调用哪个。

例如批量整理资料、生成基础代码、处理结构化内容，这类任务通常不需要每一次都使用最高能力模型。

但如果任务涉及复杂架构设计、深度推理或者关键决策，成本优先的策略可能会影响最终质量。

我如果测试 Fugu Max，会先拿它跑一批低风险任务。

比如资料整理、简单代码处理、重复性分析。

这些任务即使结果不够理想，也容易人工检查。如果它能稳定完成，再考虑扩大使用范围。

2. 更大的模型池，加入 NVIDIA Nemotron 系列

Fugu Max 使用 Fugu 系列中较大的模型池。

Sakana 提到加入了 NVIDIA 的 Nemotron 系列，扩大了可调用模型范围。

模型数量增加，对调度系统来说意味着更多选择。

但用户看不到每次请求具体调用了哪个模型。

Sakana 没有开放完整路由记录，因此开发者无法直接确认：

• 任务经过了哪些模型；
• 为什么选择这个模型；
• 每一步消耗了多少成本。

普通使用者可能不会关心这些信息。

但如果企业需要控制预算、分析成本或者优化流程，这种不可见性会成为一个限制。

3. OpenAI 兼容 API

Fugu Max 使用和 Ultra v2 相同的 OpenAI 兼容 API。

已经接入 Fugu 的用户，不需要重新搭建系统，只需要修改模型 ID：

fugu-max

即可切换。

这对想快速测试不同方案的开发者比较方便。

但内部路由仍然由 Fugu 控制。

如果你希望明确指定某一步必须使用哪个模型，或者要求每次调用成本完全可预测，自建工作流可能更适合。

Fugu Max 的核心吸引力很明确：更低的 API 成本。

输出价格降到 $6 / 1M tokens 后，它和 Ultra v2 的定位差异非常明显。

如果任务需要多步骤处理，但没有必要追求最高级别推理，Max 会更有吸引力。

我会先把它放在批量任务里测试，比如资料整理、基础代码处理、重复分析。

如果它能减少人工时间，我会继续用。

但如果为了省 API 费用，最后需要花更多时间检查和修改结果，那我会直接换回更强的模型。

涉及核心架构设计、复杂推理，或者错误成本很高的任务，我不会优先选择 Max。

Fugu Max 不是为了取代 Ultra v2。

它解决的是另一个问题：

不是“怎么让 AI 做得更强”，而是“怎么让多模型系统用更低成本运行”。