OpenRouter推出复合方案，用一半价格实现性能碾压

一个名叫“合成大西瓜”的小游戏曾风靡一时，它的玩法很简单：两颗相同的水果撞在一起，会变成更大的一颗。葡萄合成樱桃，樱桃合成橘子，最终目标是合出一颗西瓜。

如果把这套逻辑搬进 AI 领域，会发生什么？

近日，美国大模型聚合平台 OpenRouter 真的做出了一个能“合成大 AI”的产品，名为 Fusion。在基准测试中，三个中等价位的模型经过 Fusion 的合理编排，最终表现系统性地超过了同期所有单一旗舰模型。而且，把三个同样的模型合在一起，其得分竟也高于原模型单独作答的结果。

中间层平台的生存焦虑，催生了 Fusion

成立于 2023 年的 OpenRouter，总部位于美国纽约，是一家提供 AI 中间层的初创公司。

创始人之一亚历克斯·阿塔拉（Alex Atallah）曾在 Palantir 担任工程师，2017 年联合创办了全球知名 NFT（非同质化代币）交易平台 OpenSea。另一位联合创始人路易斯·维奇（Louis Vichy）则是一位连续创业者，长期专注于开发者工具与平台层产品。

OpenRouter 为开发者提供统一 API 网关，接入超 400 个大语言模型，覆盖 OpenAI、Anthropic、谷歌、Kimi、DeepSeek 等主要厂商，盈利方式是抽取 5% 的佣金。

据其披露数据，成立以来，平台月消费金额已从 2024 年 10 月的约 80 万美元增长至 2025 年 5 月约 800 万美元，平台每周路由 token 额度已达 25 万亿到 27 万亿量级。融资方面，不到三年，OpenRouter 已踏入独角兽行列。

但其最大的商业风险是被绕过：一旦某家头部模型在某个场景明显占优，开发者完全可以直接接入该厂商的 API，不必额外向 OpenRouter 支付佣金。

为应对这一危机，Fusion 应运而生。他们要提供单一模型供应商都无法提供的跨厂商模型协同。

功能实现和实测表现

Fusion 的架构大致如下：用户在 API 请求中指定一个调用方模型，调用方模型决定启用 Fusion，系统将提示词（prompt）并行分发给若干面板模型（panel models），每个模型同时启用三项服务端工具，包括网页搜索和网页抓取，以及 bash 命令执行（Linux 和 macOS 系统最常用的命令行解释器）。

面板模型各自独立完成任务后，一个裁判模型（judge model）将读取全部回答，产出一份结构化的 JSON（一种通用的数据交换格式）分析。最后再由调用方模型基于这份分析撰写最终答案，撰写阶段不再启用网页搜索工具。在默认情况下，裁判模型和调用方模型是同一个模型。

整套流程封装在服务器端，开发者只需将模型字段填为“openrouter/fusion”即可调用整套工具，面板成员与裁判模型均可由用户自定义。

为避免编排的无限嵌套，每次内部请求都会携带一个“x-openrouter-fusion-depth”标头，阻止面板模型和裁判模型再次套娃式调用 Fusion。

聊完机制，Fusion 在基准测试中的实际表现如何？

2026 年 2 月，Perplexity 开源了一项名为 DRACO 的基准测试，包含 100 道深度研究任务。这些题目源于平台收集的真实用户请求，评分标准覆盖事实准确性、分析广度与深度、呈现质量、引用质量四个维度。部分标准带有负权重，模型如果说错或提供危险建议就会被扣分，这让凑字数刷分的策略难以奏效。

Fusion 在 DRACO 上的测试结果显示，Fable 5 与 GPT-5.5 组成的双面板（合成模型为 Claude Opus 4.8）拿到了 69.0 分。对比之下，Fable 5 单独作答得到 65.3 分，单独的 GPT-5.5 是 60.0 分。

（来源：OpenRouter）

在低价模型中，Fusion 体现出较高的性价比优势。Gemini 3 Flash、Kimi K2.6、DeepSeek V4 Pro 三个相对经济的模型经过合成后取得 64.7 分，已超过单独的 Opus 4.8（58.8 分）及 GPT-5.5（60.0 分），但整体推理成本只有前沿模型的一半。

（来源：OpenRouter）

OpenRouter 还让 Opus 4.8 与 Opus 4.8 组成“双胞胎面板”，裁判与调用方模型也是 Opus 4.8。结果显示，这套自我合成的组合拿到了 65.5 分，比单独测试 Opus 4.8 还高出 6.7 分。

研究者在测试中意外发现，开启网页搜索后，部分模型检索到了 DRACO 的评分标准，这种无意识的作弊构成了数据污染。团队随后通过域名排除机制统一屏蔽了相关页面，最终公布内容均为模型屏蔽后的表现。

集成学习早就有了，护城河在哪？

将多个模型组合以提升性能的思路，最早可以追溯到上世纪九十年代。机器学习有集成学习（Ensemble Learning）的传统，人们熟知的随机森林、提升方法（Boosting）等经典方法，都建立在“多个弱模型胜过单个强模型”上。

进入大语言模型时代，这一策略最具代表性的工作之一是 2023 年发布的双模块集成框架 LLM-Blender：其一从多个开源模型的候选答案中挑出最优；另一个模块把得分最高的若干候选答案与原始问题交给一个融合模型，最终生成综合答案。

图 | LLM-Blender 的架构（来源：DOI: 10.18653/v1/2023.acl-lo）

不难看出， Fusion“面板模型+裁判模型”的方案与老前辈 LLM-Blender 的结构高度相似：并行调用多个模型，让一个能力更强的模型阅读全部回答后输出答案。

“三个 Opus 4.8 比一个 Opus 4.8 更强”的结果，其实呼应了自一致性（self-consistency）的概念：同一个模型对同一问题独立采样多次再投票，效果通常优于单次输出。

但 Fusion 的价值并不在算法，闭源模型的调度协作、工程化封装以及多样性的工具调用才是它真正的护城河。

集成研究需要访问模型权重等内部参数和原始计算结果，最少也要了解完整的概率分布，因此，学术界相关工作绝大多数基于开源模型。但目前真正能力最强的几款模型基本都闭源，只能通过 API 获取文本输出，OpenRouter 要在闭源模型之间做集成，必然要同时拥有多家厂商的接入权限和稳定的调度能力。

其次，一套可用的多模型集成流程，需要处理并发调用、超时与失败回退、合成提示词模板、成本核算、负载均衡等问题。对一般开发团队而言，这是一笔不小的工程投入。而 Fusion 将整套流程封装成一次性的 API 调用，大大降低了开发者的操作门槛。

第三是工具调用层面的多样性。传统集成研究大多只涉及纯文本问答，多个模型的差异主要体现在生成策略。Fusion 执行任务时，每个面板模型会各自调用检索和筛选工具。在对信息覆盖要求较高的任务上，其最终合成的结果不仅综合多种推理路径，还涵盖多套独立资料来源，超越了单模型多次采样的表现。

产品不完美，但有望改写大模型的能力单位

OpenRouter 明确表示，Fusion 并不适合作为编程模型的直接替代品。挑选 DRACO 作为基准测试，更多是想评估其在单轮深度研究类任务中的表现，未涵盖编程、实时对话、多模态等场景，Fable 系列擅长的长周期任务也不在测试范围内。

调用 Fusion 后，单次响应的时间通常是普通调用的 2 到 3 倍，多个面板模型的并行推理与一次合成推理叠加，整体成本远高于单模型方案，耗时也将显著上升。

需要注意的是，Fusion 的合成质量上限取决于裁判模型的理解力和归纳能力。目前选用 Opus 4.8 当裁判，暂时能取得不错的效果。但当任务复杂度继续上升、面板模型的综合能力接近甚至超过现有的最强模型时，由单一模型进行评判与输出将变得不再可靠。考虑到模型可能存在系统性偏好，对于让大模型当裁判的评判方式，学界还一直存有争议。

在产品局限之外，Fusion 已经引出一个更值得关注的问题：大模型的能力单元将被重新定义，单个模型性能或许不再是用户选择的唯一取向。

头部厂商围绕单一模型的能力极限展开竞争，参数规模、训练数据、对齐手段轮番加码。Fusion 却证实了一种可能：编排技术系统性地组合多个中等模型，可使其达到接近甚至超过旗舰模型的水平。

如果这一规律在更多场景中被证实有效，旗舰模型的溢价空间将被压缩，但对于 OpenRouter 这样的中间层，更强大的调控能力，将使其从 API 中介升级为创造价值的环节。

设想一下，倘若面板模型从 2 个扩展到 10 个，合成模型本身也可由多模型集成担任，当代码执行、长期记忆等更多工具被纳入这一框架，最终合成出的“西瓜”到底能长多大，谁也说不准。

参考内容：

https://openrouter.ai/blog/announcements/fusion-beats-frontier/

https://openrouter.ai/docs/guides/features/server-tools/fusion

https://arxiv.org/abs/2602.11685

https://aclanthology.org/2023.acl-long.792/

注：封面/首图由 AI 辅助生成