为什么顶尖 AI 公司都在押注 Fusion？

一个 AI 产品的背后，开始出现多个模型共同工作的身影。Fusion 到底融合了什么，又是怎样工作的？

FUMO Lab 也在探索这个方向。我们的 Fusion Max 面向复杂推理与研究，Fusion Code 面向软件工程，通过模型接口将融合能力提供给应用和 Agent。下面从公开研究出发，解释 Fusion 的几种主要机制，以及它们如何成为产品。

图 1｜代表性产品与研究节点，按事件顺序排列，间距非时间比例。

为什么最近都在谈 Fusion？

多模型融合的研究早于这轮产品发布：2023 年 FrugalGPT 研究串联调用不同模型；2024 年 Mixture-of-Agents（MoA）让多层模型输出递进形成结果。现在这些能力开始通过标准接口和 Agent 产品进入工作流。

翻译、检索、长文分析、代码修改对模型能力、速度与价格要求不同；Agent 更把一次问答拉长成连续任务：查报错→改代码→跑测试→迭代优化。融合模型让应用调用统一接口，底层自动完成多模型协作，兼顾易用与性能。

Fusion 的五种机制：到底在融合什么？

按发生环节分为：运行时融合（分配/聚合/协作）与构建时融合（知识迁移/参数合并）；同一系统可叠加使用。

1. 模型分配：这次请谁来回答？

图 2｜路由先选模型，再生成答案。

假设应用收到“翻译一句话”和“分析跨模块程序错误”两个请求，分配系统可以据此选择不同模型。常见做法包括路由和级联：前者在生成前选择模型，后者允许先调用一个模型，再根据结果决定是否继续调用其他模型。RouteLLM 研究从偏好数据中学习路由，FrugalGPT 研究多模型级联。模型池里可以有很多模型，一个请求实际调用的只是其中一部分。

2. 答案聚合：几份回答怎样合一？

图 3｜聚合处理的是已生成信息：挑选、比较或重新组织。

把同一个问题交给几个模型，会得到多份回答。后续环节可以投票、排序、挑选，也可以比较观点后重新作答。LLM-Blender 研究排序与融合；MoA 让后一层读取前一层的输出。OpenRouter 的 Fusion Router 是这一类机制的 API 入口：模型调用 Fusion 工具后，由并行回答、分析比较和最终作答几个步骤形成结果；其网页 Fusion 则用于配置和试用融合过程。两种入口的产品用途需要分开理解。

3. 任务协作：几个模型怎样分工？

图 4｜协作传递子任务、执行状态和反馈。

任务协作把模型放进不同的工作环节，例如提出方案、实现代码、审查结果，再根据反馈继续工作。Conductor 研究用一个协调模型组织其他模型的任务。这里还要区分多 agent与多模型：多个 agent 可以使用同一个底座模型，但拥有不同上下文和工具；多个模型也可以只分别回答同一个问题，再由系统汇总。是否属于任务协作，主要看它们之间有没有分工和交接。

4. 知识迁移：把经验教给一个模型

图 5｜融合发生在训练阶段，推理时调用单一模型。

知识迁移把多个模型的输出、概率分布或执行轨迹转成训练信号，更新一个目标模型。FuseLLM 研究从不同源模型的生成分布中整合知识；NeoHorse-1 利用 routing harness 产生的轨迹开展后训练。因此，需要把产生轨迹的运行系统与训练后的模型分开：前者在运行时组织调用，后者已经将部分经验转化成自身参数。

5. 参数与结构合并：直接融合内部

图 6｜直接处理模型内部权重与结构。

这条路线直接操作权重、参数增量或模型结构，形成合并后的模型。例如，TIES-Merging 研究合并中的参数干扰，MergeKit 提供多种合并方法的实现。它们通常要求访问模型权重，并考虑架构和参数的兼容性。与知识迁移相比，两者都可能交付一个模型，但前者借助训练信号更新参数，这一类则直接处理待融合的参数或结构。

路由 vs 编排：选模型，还是安排流程？

路由 =“交给谁”；编排 =“分几步、谁做、交接给谁、如何循环”。例如 Fugu普通版偏路由，Ultra延伸到多 Agent 工作流。

以一项代码修改为例，路由系统可以把请求交给某个模型；编排系统则可能安排实现、检查和修订几个环节。流程既可以预先设定，也可以根据任务与中间结果生成。六月 Fugu 技术报告中的普通版偏向模型选择，Ultra 则延伸到多 agent 工作流，是这两种决策范围的一个公开例子。

图 7｜同一请求：仅选模型，或安排完整流程。

融合模型：输出能力接口，接入你的应用/Agent（API/权重形式）。融合 Agent：直接交付完整工作流——含工具、环境、执行闭环，用户提需求即可。

图 8｜模型提供能力；Agent 组织模型、工具与流程交付应用。

FUMO：把融合能力接入你已有的工作流

FUMO 的 Fusion Max 与 Fusion Code 属于融合模型这一侧：Fusion Max 面向复杂推理、研究和高要求的 Agent 任务；Fusion Code 面向编码、调试、终端操作与软件工程。用户按工作类型选择模型，而应用继续通过一个接口获得响应。

接入时，FUMO 提供兼容 OpenAI 的 Chat Completions 与 Responses API，便于复用已有客户端和 Agent 工作流。工具仍由客户端执行，模型返回最终响应或工具调用。计费按照公开的输入、缓存输入和输出口径计算，Fusion 内部多模型协作产生的 token 不另行计费。

五种机制解释了融合发生在哪里，“模型”与“Agent”解释了如何使用它。对 FUMO 来说，产品要解决的问题很具体：让复杂研究和工程任务能直接用上融合能力，而不必先搭建一套多模型系统。

关于FUMO Lab

FUMO Lab 是一家位于新加坡的前沿 AI 实验室，研究多模型协作、交叉验证与计算资源分配。我们持续评测模型、分析模型行为，关注它们在具体任务中的能力、失败原因和使用成本。

我们正在构建 Fusion Max 与 Fusion Code，将融合能力用于复杂推理、研究与软件工程。如果你有希望验证的真实任务，欢迎扫码联系团队申请评测。