OpenRouter 这次展示的 Fusion API，有一个容易被误读的点：它看起来像一个模型，slug 也只是 openrouter/fusion，但后端并不是一个模型在回答。

它会把同一个提示分发给多个专家模型并行分析。Fusion 默认启用 web search 和 web fetch，用来辅助这些模型做并行分析。然后，再由一个 judge 模型综合生成最终答案。

这件事有意思的地方不在“又多了一个 API”。我更在意的是，它把多模型审阅这件事产品化了：不是让开发者自己写编排、自己收集答案、自己做裁判，而是把这套流程包装成一个可调用的模型入口。

但代价也很直接。

它不是免费服务，也不是固定单价模型。你调用的不是一个模型，而是一组模型加一个 judge。账单自然也不是一口价。

Fusion 到底怎么工作：一个提示，多路分析，一个裁判

OpenRouter 目前给 Fusion 提供了三种调用入口：OpenAI-compatible Chat Completions、Responses API，以及 Anthropic Messages API。

开发者可以像调用普通模型一样传入 openrouter/fusion。这对已有 OpenAI 或 Anthropic 兼容工作流的团队比较友好，不需要先推倒接口层。

真正的区别在后端。

普通单模型调用，是“一个模型直接答”。Fusion 更像“几个人先各自看一遍，再让一个人汇总”。它的价值不是保证答案一定正确，而是更容易看到共识、冲突和盲点。

这里要特别注意一个页面信息：OpenRouter 页面上的 “Top models used by Fusion” 只是使用占比展示，不等于固定面板成员。不能把它抄成 Fusion 的固定模型列表。

维度单模型 APIFusion API
调用入口指定一个模型指定 openrouter/fusion
后端流程一个模型生成答案多个分析模型并行分析，judge 综合
联网能力取决于模型和工具配置默认启用 web search 和 web fetch
主要价值成本、速度、稳定性更好控制发现共识、矛盾、盲点，降低单模型误判风险
主要风险单点误判成本、延迟、可控性更复杂

所以，Fusion 不是“更聪明的单模型”。它更像一层多模型工作流。

这对需要在生产环境里处理复杂问题的开发者有现实影响：如果过去团队已经在应用层写了多模型投票、交叉审阅、总结裁判，Fusion 可能减少一部分编排工作。采购或技术负责人可以先延后自研编排的投入，拿 Fusion 做一轮小规模验证。

但如果业务只是普通客服问答、简单摘要、低价值闲聊，把它放到全量请求上，多半不划算。

成本和控制：别把 Fusion 当固定价模型用

Fusion 最容易踩坑的是价格理解。

它的费用不是 openrouter/fusion 这个 slug 对应一个固定单价。每次请求会按实际调用的底层分析模型完成量，加上 judge 调用，一起累加计费。

换句话说，Fusion 的价格取决于当次跑了哪些模型、跑了多少 token、judge 又用了什么模型。公开信息里没有给出固定价格数字，也没有给出固定延迟或成功率。

OpenRouter 提供了几层控制入口：默认面板是 Quality preset，也可以切换到 Budget preset。开发者还可以通过 fusion plugin 的 analysis_models 和 model 字段覆盖配置，分别指定分析模型组和 judge 模型。

配置项作用适合谁
Quality preset默认面板，偏质量取向高风险审阅、研究、复杂推理
Budget preset更强调成本控制想试水 Fusion，但不能让账单失控的团队
analysis_models覆盖并指定分析模型组已经知道哪些模型适合自己任务的开发者
model覆盖 judge 模型需要控制最终裁判能力和成本的团队
Activity查看本次实际跑了哪些模型财务复盘、效果复盘、排查异常输出

这张表背后的判断很简单：Fusion 能不能进生产，不只看答案好不好，还要看能不能控账。

对企业团队来说，比较稳妥的做法不是直接全量迁移，而是设一个高风险分流：普通请求继续走单模型；需要审阅、核对、争议判断的请求，再走 Fusion。

上线前至少要做三件事。

一是看 Activity，确认每次实际跑了哪些模型。二是分别测试 Quality 和 Budget 的输出差异。三是给高风险路径单独设预算和日志，不要把 Fusion 混进普通调用池里。

这也是它和 Auto Router 这类路由能力的差别。Auto Router 更像“帮你选谁来答”，常见目标是可用性、速度或价格之间的取舍。Fusion 是“让多个人先答，再由裁判整合”。前者偏路由，后者偏审阅。

多跑模型，本来就是用成本换检查。

适合怕错的任务，不适合便宜问答

Fusion 的合适场景，应该围绕一个问题判断：错一次贵不贵。

如果只是问天气、改标题、写短回复，单模型通常更合适。便宜、快、链路短，出了问题也容易定位。

但在研究、专家审阅、复杂问题求解里，情况不同。用户要的不是一个顺滑答案，而是希望模型帮忙找分歧、找证据缺口、找推理漏洞。

比如技术团队做方案评审，可能需要多个模型从安全、成本、实现复杂度几个角度拆问题。研究人员检查一段假设，也会更在意有没有被单个模型忽略的反例。法务、合规、投研这类场景同理，关键不只是“生成”，而是“少漏”。

不过，Fusion 也不是保险箱。

多模型有时会形成假共识。judge 也可能把冲突抹平，给出一个看似稳妥、实际证据不足的答案。OpenRouter 目前没有提供可让外部直接下结论的基准测试、固定延迟或成功率数据，所以不能说 Fusion 一定比某个单模型更准。

更审慎的说法是：它提供了一种降低单模型误判风险的机制。

接下来最该看的，不是它能不能“击败某个大模型”。这个问题太粗。

更实际的观察点有两个：开发者能不能稳定控制分析模型组合、judge 模型和账单上限；judge 在面对冲突答案时，能不能给出可复查的理由，而不是把不同意见揉成一段漂亮废话。

如果这两点做不到，多模型会诊也可能变成多模型噪声。

Fusion 的位置因此很清楚：它适合作为高风险路径的升级选项，而不是所有请求的默认入口。怕错的地方用它，怕贵的地方慎用它。