一次 API 调用，让一群模型先吵架再交卷：拆解 OpenRouter 的 Fusion
一次 API 调用，让一群模型先吵架再交卷：拆解 OpenRouter 的 Fusion
本期关键词：复合模型 Compound Model（不是把多个模型缝成一个更大的模型，而是同一个问题同时问好几个模型、再让一个模型把它们的答案揉成一份）/ 裁判模型 Judge（专门负责读所有答案、挑出共识与矛盾、写出最终结论的那个模型）/ MoA Mixture of Agents（"一群智能体"架构，2024 年学术界就有的老配方：多个模型分层协作出一个答案）
过去一年，AI 圈的重磅发布几乎都长一个样：某家实验室甩出一个更大、更强、跑分更高的新模型，然后大家围着排行榜吵谁是本周第一。2026 年 6 月 12 日，OpenRouter 发的东西不是这个套路——它没有训练任何新模型，而是把一件"高级用户早就在手动干的脏活"做成了一个按钮。
这件脏活是这样的：你有个难题，不放心只问一个模型，于是你分别去问 Claude、问 GPT、问 Gemini，再自己对着三份答案逐条比对、挑毛病、最后手动拼一份你觉得最靠谱的结论。OpenRouter 给这套流程起名 Fusion（融合），把它压缩成一行代码——model: "openrouter/fusion"。你照常发一个 prompt（给模型的提问），背后却有一支模型小组在并行作答、一个裁判模型在汇总，最后吐给你一个答案。
The Neuron 的评论一句话点破了它的份量："这听起来像件小事，它不是。"（"That may sound small. It is not."，来源见引用 5）这篇文章要拆的，正是它为什么不是小事，以及它身上那些被发布通稿刻意略过的麻烦。
一、它到底在干什么：把"问一圈、再裁决"做成一次调用
先把机制说清楚，因为 Fusion 的全部价值和全部争议都长在这套机制上。
按 OpenRouter 官方博客和 byteiota 的拆解，整条流水线分四步（来源见引用 1、4）：
第一步，你的 prompt 被并行分发给一支模型小组（panel），默认最多 8 个模型同时作答，每个模型都开着联网搜索（web_search）和网页抓取（web_fetch）的工具。第二步，一个裁判模型（judge）读完所有答案，产出一份结构化分析——不是简单把文字拼一起，而是拆成五类：共识点（多数模型都认同、可信度更高）、矛盾点（模型之间直接打架的地方）、部分覆盖（只有几个模型提到的内容）、独特洞见（某个模型单独贡献的想法）、盲区（所有模型都没覆盖到的缺口）。第三步，一个写手模型拿着这份分析，写出最终答案。第四步，你收到一个回复。
OpenRouter 官方对这套结构的描述是："裁判模型并非盲目地把文本合并。"（explainx 转述官方文档，来源见引用 6）这句话是整个产品的命门——Fusion 卖的不是"问得多"，而是"裁得好"。
接入成本被刻意压到极低。byteiota 给的代码示例里，你只需要把现有 OpenAI 兼容请求里的一个参数从某个模型名改成 openrouter/fusion，其余一行不动（来源见引用 4）。OpenRouter 还留了个细节：Fusion 会自己判断一个问题值不值得动用整个小组，简单提问会自动跳过 panel，省掉不必要的开销。
这意味着，对开发者来说，一个"多模型协作系统"被伪装成了"一个普通模型"。你不用搭基础设施、不用自己写裁决逻辑、不用管哪个模型超时——这些全在 OpenRouter 的服务器端跑掉了。
二、跑分：一群便宜模型，干翻了单个贵模型
光有机制不够，OpenRouter 必须证明"一群模型"真的比"一个最强模型"强。它选的考场叫 DRACO。
DRACO 是 Perplexity AI 出的深度研究基准（论文见引用 2），100 道题，横跨学术、金融、法律、医学、技术、UX 设计、通用知识、大海捞针式检索、个性化助理、产品比较十个领域。每道题配一份约 39 条加权标准的评分细则，分四类打分：事实准确性、广度与深度、表达质量、引用质量。关键是有些标准是负分——比如给出危险的医疗建议会被重罚。OpenRouter 特意指出，这种负分设计让"靠啰嗦刷分"行不通：一个自信地说错话的模型会被扣分（来源见引用 1）。
结果（OpenRouter 官方数据，来源见引用 1）：
- Fable 5 与 GPT-5.5 融合、由 Opus 4.8 合成，拿到 69.0%，超过任何单个模型，包括单跑的 Fable 5（65.3%）。
- 一个全便宜模型的小组（Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro）拿到 64.7%，打败了单跑的 GPT-5.5 和 Opus 4.8，距离 Fable 5 只差不到 1%，而成本约为一半。
OpenRouter 由此给出三条结论：模型小组持续跑赢单个模型；用顶级模型组队能拿到"超越前沿"的表现；用便宜模型组队就能逼近甚至超过顶级单模型。它把这归因于"模型多样性"，类比人类团队——不同视角凑在一起解决复杂问题，效果更好。
这里有个容易被忽略、但作者特意做的诚实标注：Fable 5 的 100 道题里有 7 道因为内容过滤器拦截没跑完，OpenRouter 选择不回退到 Opus 4.8，所以 Fable 的分数其实是 93 道题的成绩，"与跑满 100 道题的模型直接比分略有不公平"（来源见引用 1）。一家公司愿意在自家跑分的脚注里写下"这个对比对我有利方略不公"，比那个 69.0% 的数字更值得记一笔。
三、最反直觉的一条：模型跟自己融合，也能涨分
发布通稿里藏着一个最有意思的实验。OpenRouter 让 Opus 4.8 和它自己组成一个两模型小组，再由 Opus 4.8 自己当合成者。结果是 65.5%，比单跑的 Opus 4.8（58.8%）足足高了 6.7 个百分点（来源见引用 1）。
同一个模型、同一个问题，问两遍再让它自己汇总，就涨了将近 7 分。
OpenRouter 给的解释是：这说明 Fusion 的提升有一大块来自"合成"这一步本身，而不只是来自"凑了不同架构的模型"。同一个 prompt 跑两遍，会走出不同的推理路径、调用不同的工具、选取不同的信源——把这些差异收拢再裁决，本身就有价值。
这条数据的意义在于，它把 Fusion 的卖点从"我帮你凑齐了全明星阵容"往下拆了一层，露出了真正的引擎：结构化的自我审阅。这也解释了为什么 OpenRouter 敢说便宜模型组队能逼近顶级模型——你买的与其说是模型，不如说是"逼模型把答案再审一遍"的那道工序。
四、它解决的真问题：别再赌单一供应商
Fusion 上线的时机，被一条背景新闻衬得格外刺眼。
据 explainx 的梳理（与其引用的 X 帖子交叉印证，来源见引用 6），2026 年 6 月 12 日同一周，Anthropic 因美国商务部一纸指令暂停了 Claude Fable 5——调用 claude-fable-5 直接报错，新会话回退到 Opus 4.8。OpenRouter 的发布恰好踩在这个点上。一位开发者在 X 上的话被广泛转引："fable 5 宕了 12 小时……别怕——OpenRouter 的 fusion 来了，我们把一组模型组队，用一半成本做到了 fable 5 性能的 1% 以内。"
（说明：Fable 5 被暂停一事来自多家二手媒体的交叉报道，本文未取得 Anthropic 或商务部一手公告，此处仅作为 Fusion 发布时机的背景，不作为本文核心事实采信。）
OpenRouter CEO Alex Atallah 把这层意思讲成了产品哲学："AI 的未来是神经多样性，不是单一模型的赢家通吃。"（"The future of AI is neurodiversity, not single-model takeovers."，来源见引用 6）翻译成大白话：别把全部身家押在一家实验室的一个模型上——它可能涨价、可能被监管下架、可能某天就是状态不好。Fusion 的真正用途，不是复刻某个被下架的强模型，而是让你的应用"绕开对单一供应商的依赖"。
这不是 OpenRouter 一家的直觉。The Neuron 指出，微软的 Microsoft 365 Copilot Researcher 里已有一个"模型议会"（Model Council），把同一个问题同时丢给 GPT 和 Claude 的研究智能体，再展示它们在哪里一致、在哪里分歧（来源见引用 5）。两家走的是同一条路：当几个模型能组成一个相互审查的回路时，就别强求一个模型当整个大脑。
五、盲区与过于乐观的地方
把通稿翻过来读，麻烦不少，而且大多是 OpenRouter 自己没主动说的。
这是厂商自测，没有第三方验证。 The Neuron 的措辞很克制："说得挺响，但在第三方下场验证之前，仍应当作厂商跑分来看待。"（"Big if true, and still worth treating as a vendor benchmark until third parties kick the tires."，来源见引用 5）100 道题全是 OpenRouter 自己跑、自己用 Gemini 3.1 Pro Preview 当裁判打的分——而 DRACO 论文自己就承认，换个裁判模型，绝对分数能漂移 10 到 25 分（来源见引用 1）。
它绕开了编程。 byteiota 反复点出：整个 benchmark 完全排除了 coding 任务（来源见引用 4）。OpenRouter 在 6/14 的 FAQ 里也承认 Fusion 不是编程模型的替代品，只能当成一个"服务器工具"，让你的编程模型在遇到架构决策这类值得多花钱的问题时选择性调用（来源见引用 1）。换句话说，开发者最高频的那类活，恰恰是 Fusion 没证明过的。
合成算法是黑箱。 byteiota 称之为"一个站得住脚的担忧"——OpenRouter 没有公开裁判模型如何给互相打架的答案分配权重、如何裁决矛盾（来源见引用 4）。对企业用户来说，多个模型同时处理你的 prompt，还牵出法务要操心的数据流向问题。
它不快。 当 Fusion 真被触发时，整个多步流程通常比一次普通调用慢 2 到 3 倍（OpenRouter FAQ，来源见引用 1）。byteiota 直接划线：实时交互、低延迟 API、任何对响应时间敏感的场景，都不适合 Fusion。早期使用者还反馈，在狭窄的垂直任务上 Fusion 会出现逻辑不一致——而这恰恰是宽口径研究基准最容易漏掉的失败模式（来源见引用 4）。
这配方不新。 Fusion 冲上 Hacker News 首页（107 分、37 评，来源见引用 4），评论区分成三派：觉得有用的、指出"一群智能体"MoA 架构 2024 年学术界就有了的、以及揪着跑分排除编程不放的。byteiota 的判断比较公道：MoA 的批评没错但没说到点子上——Fusion 没声称自己是新研究，它是把一个成熟架构产品化成了托管、即插即用、零基础设施的 API，价值在于"要不要让别人替你管这一层"。
六、对从业者意味着什么（可执行）
把上面这些落到具体动作上。
如果你是 Coze / Dify / n8n 这类工作流的搭建者：Fusion 最直接的用法是"高风险节点的保险丝"。把它挂在那些"答错代价很大"的环节——尽职调查里的结论汇总、医疗法律类的事实核对、给客户的研究报告——用 openrouter/fusion 一行替换原有模型；其余高频低风险节点（提取、分类、闲聊）保持单模型，别为它们付多模型的钱和延迟。ModelFusion、Fusion AI（NeuroSwitch）等同类产品也在抢这块"答错有下游成本"的市场，可横向比价。
如果你在做成本核算：byteiota 算得很清楚——Fusion 按所有底层 completion 之和计费，路由四个模型就付四份钱。它的省钱逻辑只在一种情况成立：你原本的基线是 Fable 5 这类顶级单模型，那么便宜模型组队确实更划算；但如果你本来就在用 Opus 或 GPT-4o 这类中端模型，Fusion 大概率更贵（来源见引用 4）。先问自己"我要替换的那个模型有多贵"，再决定值不值。
如果你在做技术选型/尽调：把 OpenRouter 这次发布当成一个信号读——多模型路由这层基础设施正在被资本和大厂同时押注（OpenRouter 2025 年 6 月融了 4000 万美元专门扩多模型推理，微软在 Copilot 里做了 Model Council，来源见引用 4、5）。"选一个最强模型"正在让位于"为任务设计一组模型"。但落地前务必自测：用你自己的真实任务、你自己选的裁判，跑一遍对比，别把厂商那张 69.0% 的图当成你的业务结论。
最后一句不带判断的事实：从机制看，Fusion 把"模型选择"从一场赌哪家实验室本周第一的赛马，变成了一道"给这个任务配什么阵容"的编排题。这道题以前是高级用户的手艺，现在是一个 API 参数。它好不好用要等第三方下场，但它把问题从"谁最强"挪到"怎么搭"——这个转向，比任何单条跑分都更值得记住。
引用
- OpenRouter 官方博客《Surpassing Frontier Performance with Fusion》（《用 Fusion 超越前沿性能》），Brian Thomas，2026-06-12（含 6/14 FAQ 更新）。https://openrouter.ai/blog/announcements/fusion-beats-frontier/
- DRACO 深度研究基准论文（Perplexity AI）。https://arxiv.org/abs/2602.11685
- OpenRouter Fusion API 定价与提供方页面（《Fusion - API Pricing & Providers》）。https://openrouter.ai/openrouter/fusion/api
- byteiota《OpenRouter Fusion Launches: Multi-LLM API at Half the Cost》（《OpenRouter Fusion 上线:半价的多模型 API》),2026-06-13。https://byteiota.com/openrouter-fusion-launches-multi-llm-api-at-half-the-cost/
- The Neuron《OpenRouter Fusion Makes the Case for Compound AI Models》（《OpenRouter Fusion 为复合 AI 模型正名》），Corey Noles，2026-06-15。https://www.theneuron.ai/explainer-articles/openrouter-fusion-makes-the-case-for-compound-ai-models/
- explainx.ai《OpenRouter Fusion API: Fable-Level AI Guide 2026》（《OpenRouter Fusion API:Fable 级 AI 指南 2026》）。https://explainx.ai/blog/openrouter-fusion-api-fable-5-alternative-2026
- officechai《OpenRouter Launches Fusion API》报道。https://officechai.com/ai/openrouter-launches-fusion-api-which-uses-a-combination-of-models-to-achieve-fable-like-performance-at-half-the-price/