从提分到付费：Model Fusion 的需求错觉

▲ 图 1：同一个月，两种 Fusion

本文把 Model Fusion 限定为一种较窄的架构：多个模型对同一任务并行作答，评审模型比较结果，最后再由一个模型输出答案。Devin Fusion 不属于这个定义，它更接

近动态路由和任务委派。之所以把它放在开头，是因为市场正在把 “Fusion” 当成所有多模型编排的统称，而真正有效的产品，往往正在远离狭义的模型融合。

我们的判断偏悲观：Model Fusion 是一份昂贵的质量保险。它能提高某些任务的绝对表现，却很少能把成本—质量—延迟的效率前沿真正推向外侧。真正值得购买这份保险的任务很少。它会留下来，但更可能成为一个低频触发的功能，而不是默认架构，更难成为独立品类。

▲ 图 2：模型智能与单任务成本，横轴为对数刻度

图中最值得关注的不是最右上角的最高分，而是偏离价格—能力趋势的点：它们以更低价格提供了足够能力，是特定工作负载上的效率 outlier。综合指数无法直接回答哪

个模型最适合代码审查、中文研究或受监管部署，但它揭示了一个方向：模型供给正在商品化，“最强模型”与“最优选择”正在分开。

面对同一个质量缺口，市场目前有四种主要买法。

第一种是直接升级到更强的单模型。它最简单，也最容易审计；只要高端模型的边际提价低于错误或返工成本，这通常仍是首选。第二种是在同一个模型上增加测试时计算，例如延长推理、self-consistency 或多次采样。第三种是路由、级联和任务委派：先用便宜模型处理可验证或机械性的部分，只有遇到困难才升级。第四种才是狭义的 Model Fusion：让多个模型对同一问题重复作答，再由评审和综合模型形成最终答案。

这四种方式都能“用更多计算换质量”，区别在于计算花在哪里。单模型扩展购买更深的推理，路由购买更准确的资源分配，Fusion 则购买更多候选答案。前三种方法把预算集中在最可能改变结果的环节；Fusion 却先为重复意见付费，再赌评审模型能从中找出有效差异。候选模型只有带来足够多的独立信息，而且评审能够识别这些信息，

Fusion 才可能胜过前三种方案。

路由已经证明，模型之间的能力差异首先是一项调度机会。RouteLLM 在部分评测中把成本降低超过 2 倍而不损失质量；Switchcraft 以 82.9% 的准确率实现 84% 的成本下降，按论文测算，每百万次请求可节省超过 3,600 美元。结果仍需在企业自己的流量上复现，但经济逻辑很直接：不必让多个模型开会，只需把每项任务交给最便宜的合格模型。

这意味着，市场会先用升级、路由和验证解决质量缺口；只有当这些方法仍然不够时，才有理由为 Fusion 购买更多候选答案。

因为 Fusion 必须同时跨过三道门槛：增量质量要覆盖新增成本与延迟，候选模型要提供独立信息，评审还要稳定识别更好的答案。任何一项不成立，分数提升都无法转化为生产价值。

Fusion 的提分首先是一笔确定的计算支出。OpenRouter 会并行调用多个 panel 模型，再由评审和综合模型生成答案。DRACO 的三组对照都提了分：Fable 5 + GPT-5.5 从 65.3 升至 69.0；Opus 4.8 自融合从 58.8 升至 65.5；低成本三模型组从 60.3 升至 64.7。

但 Opus 自融合的提升更大，说明收益可能来自额外搜索和采样，而非跨模型知识互补。公平对照应比较相同 token 预算下的 self-consistency、更长推理和强单模型。现有研究也显示：多智能体在约 20 倍计算量下最多提升 7.1 个百分点；预算相同时，debate 和 Mixture-of-Agents 仅比 self-consistency 高 1.3 和 2.7 个百分点，另一项等 reasoning-token 研究则发现单 agent 持平或更优。不少“协作收益”会在计算账对齐后消失。

▲ 图 3：OpenRouter 的基准提升与产品成本

OpenRouter 默认 3 模型 panel 的成本约为普通生成的 4-5 倍，速度慢 2-3 倍，但没有披露各 DRACO 配置的完整 token、成本和延迟，无法判断 3.7 分提升是否值得。评测也只有 100 个纯文本英文任务，Fable 相关配置只完成 93 项；更换评审模型可让绝对分数移动 10-25 个百分点。它证明了 Fusion 能提分，没有证明 Fusion 改善了生产 ROI。

选择性调用只能摊薄成本。按 OpenRouter 披露的区间估算，触发率为 1% 时，整体成本约为 1.03-1.04 倍；10% 时为 1.30-1.40 倍；25% 时已达 1.75-2.00 倍。

▲ 图 4：选择性调用 Fusion 的整体经济性

最难的请求最可能触发 Fusion，系统却必须等待最慢的 panel 成员，再串行完成评审和生成，因此尾延迟集中在最有价值的任务上。多供应商调用还扩大故障面、审计复杂度和隐私暴露。Fusion 的成本不只是 API 价格，也包括等待时间和新增的系统风险。

Fusion 的价值取决于候选模型是否带来独立信息，但不同模型往往共享训练语料、网页来源和错误前提。研究任务中，这会导致“引用洗白”：多个模型追溯到同一来源，却被包装成多份独立证据。若系统不保留 claim-level provenance 和搜索路径，随着模型数量增加，API 成本几乎线性上升，证据多样性却未必增加。

KAIKAKU.AI 联合创始人兼 CEO Josef Chen 在 2026 年的论文 When DoesCombining Language Models Help? 中研究了 21 家服务商的 67 个模型。开放式数学任务中，所有模型同时答错的预测概率为 2.3%，实测却达到 5.2%——约为预测值的 2.3 倍；执行评分代码任务和自由回答版 GPQA-Diamond 的共同失败率进一步升至 7.9% 和 12.7%

换成 100 道 GPQA-Diamond，大约有 13 道题会让所有候选模型一起答错，投票、评审或综合都无正确答案可选。模型在容易题上的分歧会放大组合价值，而在最需要保险的尾部问题上，它们反而可能一起失手。

即使候选答案互补，价值仍取决于评审。候选一致时，评审可能把相关错误误认成高置信度；候选分歧时，它又必须具备足够专业知识才能选对。综合模型还可能抹掉关键少数意见，或把真实分歧改写成确定结论。

在代码任务中，编译器、测试和静态分析通常比另一份模型意见更可靠；在创意任务中，评审与综合又容易把差异压成平均答案。LitBench 中最强的现成评审模型与人类创意写作偏好的一致率也只有 73%。当任务已有廉价外部验证器，或“好”本身依赖主观判断时，Fusion 的提分很难转化为可付费价值。

Fusion 的需求取决于两道门槛：任务是否能从多模型中获益，以及这种收益是否足以形成持续付费。前者是技术问题，后者才是市场问题。

Fusion 把错误改对的概率 × 单次错误可避免的损失，必须大于新增的 API 成本、延迟、运维复杂度和隐私风险。

基准分数无法回答这道损益题。Fusion 只有在错误代价高、候选模型提供互补搜索路径、缺少更便宜的外部验证器，而且业务能接受额外延迟和供应商风险时才可能成立；最终结果仍应由人或外部证据确认。