OpenRouter 推出 Fusion API：把多个模型拼成一个用

OpenRouter 这次玩的不是路由，是融合

6 月 13 日，OpenRouter 悄悄上线了一个叫 Fusion API 的新东西。和它之前那套以路由、负载均衡为主的玩法不太一样，Fusion 这次干的事更激进——把多个模型串/并联在一起协同工作，对外暴露成一个 API 端点。官方给的卖点很直白：用一半的价格达到 Fable 级别的智能。

这事如果你只看一眼标题，会觉得不过是又一个 MoA（Mixture-of-Agents）的工程化包装。但仔细看 OpenRouter 给出的基准任务，会发现一些耐人寻味的细节：评测项是 Deep Research，不是 coding。在它放出的对比图里，DeepSeek V4 Pro solo 模式的分数甚至能跟一线模型掰手腕——这个组合本身就说明，Fusion 想打的市场不是写代码这种确定性强、有标准答案的活儿，而是开放式、长链路、需要多视角综合的研究型任务。

为什么是「融合」而不是「路由」

要理解 Fusion 跟过去 OpenRouter 那套 Model Routing 的区别，得先把概念分清楚。

过去 OpenRouter 干的事，本质是**「选一个最合适的模型来回答」**。你发一个请求过来，它根据延迟、价格、可用性甚至模型擅长的领域，挑一个 provider 转发过去。整个过程对调用方透明，但每次请求最终还是一个模型在干活。

Fusion 不一样。它干的是**「让好几个模型一起干，然后合成一个答案」**。从社区流出的信息看，Fusion 内部跑的是一套类 MoA 的 pipeline：

• 第一层 多个模型并行生成草稿（draft），每个模型从自己的偏好和知识盲区出发产出不同视角
• 第二层 一个或多个 aggregator 模型读完所有草稿，做事实交叉验证、去重、补漏
• 第三层 最终的 synthesizer 输出统一答案，并对前面的中间结果做风格和逻辑上的统一

这套架构在学术圈不新鲜，Together AI 早在 2024 年就发过 MoA 论文，证明用 6 个开源模型分层组合可以在 AlpacaEval 上超过 GPT-4 Omni。Fusion 的价值不在于「发明了什么」，而在于把这套需要工程师自己拼装的东西做成了一个端点——你 POST 一个 prompt 过去，剩下的事不用管。

为什么是 Deep Research，不是 coding

这个选择不是偶然。MoA 这类架构有个天然属性：对模型间多样性高度敏感。

写代码这事，正确答案的搜索空间相对窄。你让五个模型写一个二分查找，它们的差异更多体现在变量命名和注释风格上，aggregator 拿到这些草稿做合成，收益非常有限——甚至会因为引入了次优模型而拉低代码质量。这也是为什么 Claude、GPT-5 这种顶级模型在 coding 上的 solo 表现，至今没被任何 MoA 方案稳定超越过。

但 Deep Research 完全是另一种生态。一个研究型问题——比如「分析过去 18 个月稳定币监管在欧美日的演化分歧」——它的答案是一个多维度、多视角、需要综合的内容空间。这种场景下：

• DeepSeek V4 Pro 擅长中文语境和金融监管细节
• Claude 4 Opus 擅长长文档归纳和结构化输出
• Gemini 3 擅长跨语言的事实检索
• GPT-5 擅长论证逻辑的把控

把它们的输出叠在一起做融合，信息覆盖度的提升是实打实的。这也是为什么 Fusion 选 Deep Research 当评测项——这是 MoA 架构最能扬长避短的场景。

说白了，OpenRouter 没在硬碰硬地挑战单模型的 SOTA，而是聪明地挑了一个「集体智慧 > 个体智慧」最明显的赛道。

价格逻辑：为什么能做到「Fable 一半」

「半价达到 Fable 级智能」这个口号听着像营销，但拆开来看是站得住的。

Fable 作为闭源模型，定价里包含了它整个研发链路的成本——预训练、对齐、安全审计、品牌溢价。Fusion 的玩法是用一堆中端开源模型的 API 调用（DeepSeek V4 Pro、GLM-5、Qwen3-Max 这些）通过组合拿到接近的输出质量，单次请求的 token 成本天然就低一个量级。

但要注意，Fusion 不是免费午餐：

1. 延迟更高。多层 pipeline 意味着至少 2-3 倍的端到端等待时间，对实时应用基本没法用
2. token 消耗膨胀。中间层的 draft 和 aggregation 都要烧 token，OpenRouter 用「一半价格」做营销，但前提是任务本身的复杂度撑得起这种铺张
3. 不可控的方差。多模型协同的输出稳定性，比 solo 模式要难调试得多

所以 Fusion 的合理使用场景非常清晰：异步的、深度的、对质量比对延迟更敏感的任务。研究报告生成、长文档分析、复杂决策辅助——这些场景下，多等 30 秒换一份更全面的答案，绝对划算。

对开发者意味着什么

如果你之前自己写过 MoA pipeline，应该深知里面有多少坑：

• 不同 provider 的 rate limit 和重试逻辑要各自维护
• 中间层失败如何降级（aggregator 挂了怎么办？某个 draft 模型超时了用谁兜底？）
• prompt 工程要分别为 drafter、aggregator、synthesizer 设计
• 成本统计要按层级拆分

Fusion 把这些全收进去了。从 API 形态看，它依然是标准的 OpenAI 兼容格式，模型名换成 openrouter/fusion 就行，调用方完全不需要感知背后跑了几个模型。这对中小团队的价值非常实际——省下的不是 API 费用，是工程师月薪。

但这也带来一个隐忧：黑盒程度更高了。你不知道这次回答是哪几个模型贡献的、哪个 aggregator 做的合成、中间是否触发了降级。对于需要可审计、可追溯的企业场景（法律、医疗、金融），Fusion 这种「端到端融合」的形态短期内未必能直接用。OpenRouter 后续大概率得加上完整的 trace 输出，把每一层的中间产物暴露给调用方做合规审查。

横向比一下

这条赛道并不是 OpenRouter 一家在跑：

• Together AI 一直有官方的 MoA 实现，但更偏研究 demo，没做成稳定商业产品
• Anyscale 和 Fireworks 提供了 Agent Orchestration 框架，让你自己拼，但不是一站式 API
• 国内的硅基流动、SiliconCloud 这几个月也在推「多模型协同」的概念，但还停留在让你自己路由的层面

OpenRouter 这次最大的差异，是把多模型协同从「框架」做成了「服务」。一个 API endpoint、一个统一的计费、一个标准的兼容格式。这种工程化打磨，恰恰是 OpenRouter 这种聚合层平台最该干的事。

顺便提一句，OpenAI Hub 这边目前已经把主流模型（GPT、Claude、Gemini、DeepSeek 等）做了 OpenAI 格式的统一兼容，如果你想在国内直连环境下自己拼一套类似 Fusion 的 MoA 流程，用一个 Key 调度多家模型，技术门槛比海外要低不少。等 OpenRouter Fusion 这套架构跑稳了，国内聚合层会不会跟进做类似的「服务化融合」，值得观察。

几个值得继续盯的点

短期内 Fusion 还有几个问题没回答清楚：

1. 模型组合是固定的还是动态的？ 如果是固定，那么遇到不擅长的任务表现会很尴尬；如果动态，路由策略本身就是核心 IP
2. 是否支持自定义融合？让用户指定「我要用 Claude + DeepSeek + Qwen 这三家融合」会是企业用户的强需求
3. 跟 Agent 框架的关系。如果 Fusion 能跟 Tool Calling 和 MCP 打通，那它就不只是一个 Q&A 端点，而是一个「多模型协同 Agent」的雏形

OpenRouter 这次出手时机挺微妙——大模型单点能力的提升曲线开始放缓，模型间的差异化反而更明显，「组合套利」的窗口期正在打开。Fusion 是不是终极答案不重要，重要的是它把「多模型协同」这件事从论文里拽到了生产环境的 API 调用里。

这一步走出去之后，回不去了。

参考来源

• linux.do - OpenRouter 推出 Fusion API 讨论帖：社区最早讨论 Fusion API 性能数据和定价的帖子，包含 Deep Research 基准对比
• 知乎 - 大模型时代的万能接入点：OpenRouter：对 OpenRouter 整体定位和聚合层价值的深入分析