为什么 OpenRouter Fusion 的跑分容易误导？

OpenRouter 最近发布 Fusion，并用一个很有传播力的标题包装它：“Surpassing Frontier Performance with Fusion”。官方图里，几个单独分数不高的模型混合后，分数反而超过 GPT-5.5、Claude Opus 4.8，甚至接近或超过 Claude Fable 5。这个结果很容易被传播成一句话：低分模型融合后，产生了超越 frontier model 的智能。

但这不是最准确的理解。

更准确地说：Fusion 不是智能突破，而是在有评分/验收机制时，通过多路径复跑提高命中率的一种数学作弊。

这里的“数学作弊”不是贬义，而是工程意义上的描述：它没有让单个模型变聪明，而是通过增加候选答案数量、改变推理路径、再用 judge/verifier 做筛选和综合，提高最终结果命中评分标准的概率。

官方跑分图为什么容易误导？

OpenRouter 官方文章的标题就是 “Surpassing Frontier Performance with Fusion”，并在开头总结了三点：panel models consistently outperform individual models，frontier panels can reach beyond-frontier performance，budget model panels can surpass frontier models。¹

官方跑分图如下：

图中最容易被传播的是这几组对比：

• Fable 5 + GPT-5.5，由 Opus 4.8 综合，得分 69.0%。
• Opus 4.8 + GPT-5.5 + Gemini 3.1 Pro，由 Opus 4.8 综合，得分 68.3%。
• Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro，由 Opus 4.8 综合，得分 64.7%。
• 单模型 GPT-5.5 得分 60.0%，Claude Opus 4.8 得分 58.8%，Kimi K2.6 得分 53.7%，Gemini 3 Flash 得分 43.1%。²

这个图的视觉效果非常强：紫色 Fusion 条几乎都在橙色 Solo 条上方，于是读者很容易得到一个直觉判断：模型混合能产生更高智能。

但这个图真正证明的不是“智能融合”，而是：多次生成、多路径搜索、再综合，确实能在某类评分机制下提高得分。

真正起作用的不是“融合”，而是多次搜索

OpenRouter 官方描述的 Fusion 流程并不神秘：同一个问题被发送给多个 panel model，每个模型并行回答；judge model 读取这些回答，整理共识、矛盾、覆盖缺口、独特观点和盲点；最后由外层模型生成最终答案。³

这不是模型权重融合，也不是训练出一个更强的新模型，而是外部编排。它更接近：

多个 generator 产生候选答案，judge/verifier 选择或综合更可能正确的部分。

如果一个任务单次成功率是 p，多跑 n 次，只要每次路径不完全相同，且后面有可靠机制识别正确答案，那么至少一次命中正确解的概率就会上升：

1 - (1 - p)^n

现实中的多次运行并不完全独立，所以不能直接套这个理想公式；但方向是成立的：只要候选之间存在路径差异，多跑几次就会提高出现较优答案的概率。

这也是为什么几个低分模型混合后可能高分。单个模型分数低，不代表它每个判断都错；它可能只是漏掉一些事实、引用不充分、结构不好、某些题偏题。多个模型一起跑时，A 可能提供事实点，B 可能提供结构，C 可能提供引用，judge 再把它们拼成一个更符合评分标准的答案。

这不是“几个低分智能合成了一个高分智能”，而是：

多个不稳定候选，在一个评分标准下被重新组合成了更优答案。

最关键的证据：同一个模型和自己融合也能大幅提升

OpenRouter 官方文章里其实给出了一个非常关键的线索：Opus 4.8 + Opus 4.8 再由 Opus 4.8 综合，得分是 65.5%；而 Opus 4.8 solo 是 58.8%。也就是说，同一个模型和自己组成 panel，也能提高 6.7 分。⁴

这点非常重要。

如果 Fusion 的主要收益来自“不同模型架构互补”，那么同模型自我融合的收益应该有限。但官方结果显示，同模型重复运行也能显著提升。这说明 Fusion 的收益很大一部分来自：

• 同一问题被多次采样；
• 不同运行产生了不同推理路径；
• 工具调用和资料选择不同；
• judge/synthesizer 能从多个候选里提取更符合评分标准的内容。

换句话说，Fusion 的核心不是“多模型智能融合”，而是 搜索放大。

这是一种有验收器时的数学作弊

“数学作弊”可以这样理解：

generator 可以不稳定，但 verifier 必须可靠。

在有可靠验收器的场景里，多次复跑非常有效。例如：

• 代码能不能编译；
• 单元测试能不能通过；
• SQL 查询结果是否符合断言；
• benchmark 分数是否提升；
• proof checker 是否接受证明；
• 输出是否满足明确格式和约束。

这时模型只是候选生成器，真正决定结果的是 verifier。多模型、多 prompt、多 agent、多次 rerun，本质上都是扩大搜索空间。只要 verifier 可靠，系统就可以不断试错，直到撞到正确答案。

所以 Fusion 在 DRACO 这种任务上能提高分数，并不奇怪。DRACO 是 deep research benchmark，包含 100 个深度研究任务，覆盖 academic research、finance、law、medicine、technology、UX design、general knowledge、needle-in-a-haystack retrieval、personalized assistance、product comparison 等领域；评分标准包括事实准确性、分析深度、表达质量和引用质量。⁵

深度研究题天然适合“多人查资料、多人写草稿、一个编辑综合”。只要评分器能识别哪些事实点、引用和结构更符合 rubric，多次候选综合就会有明显收益。

但真实项目里用途低得多

真实软件项目的困难，往往不在“多生成几个候选方案”，而在“验收标准本身很难建立”。

复杂项目里的很多问题无法简单通过一个自动 verifier 判断：

• 需求是否真的被理解；
• 架构是否长期可维护；
• UI 体验是否符合用户预期；
• 重构是否破坏隐含业务规则；
• 测试覆盖是否足够；
• 回归风险是否被发现；
• 这个方案是否符合团队未来演进方向。

这些验收标准本身就依赖人类工程经验，或者依赖更强的模型能力去构造。于是 Fusion 的优势会明显下降。

在真实项目里，最有价值的不是“多模型互评”，而是建立完整闭环：

任务定义 → 验收标准 → 自动化测试 → 失败回传 → 多路径复跑 → 证据链沉淀

没有这个闭环，Fusion 只是让答案更完整、更自信、更像专家意见；但它未必更正确。

OpenRouter 自己在 FAQ 里也更谨慎地承认：Fusion 不是 coding model 的直接替代品；它更适合作为 coding model 可以选择调用的 server tool，用在架构决策、最佳实践研究等值得花更多时间和成本的问题上。⁶

真正的问题不是官方造假，而是叙事压缩

OpenRouter 的官方实验并不等于造假。它说明了一个真实现象：在 deep research 这类开放任务上，多模型、多路径、再综合，确实可能提高分数。

问题在于，这个结果在传播中非常容易被压缩成：

低分模型融合后，产生了更高智能。

这个说法就误导了。

更准确的表达应该是：

在有评分/验收机制的任务里，多路径生成和综合可以提高命中评分标准的概率。

这两个说法看起来差别不大，但含义完全不同。前者把收益归因于“智能融合”；后者把收益归因于“搜索放大 + 验收筛选”。

结论

OpenRouter Fusion 的高分并不神秘。

它真正利用的是一个简单机制：

多路径生成候选答案，在有验收标准的情况下，通过筛选和综合提高命中正确结果的概率。

这就是“数学作弊”：不是模型变聪明了，而是系统花了更多计算预算，探索了更多路径，并利用评分机制选出了更好的结果。

在深度研究、方案评审、资料综合、风险发现这类开放任务里，Fusion 有实际价值。

但在真实工程项目里，它的价值会低得多，因为最难的部分往往不是生成候选，而是建立可靠验收器。

所以更准确的判断是：

Fusion 不是智能融合，而是搜索放大。它的上限不由 panel model 数量决定，而由 verifier 的可靠性决定。

---

原文引用与截图来源

Footnotes

1. OpenRouter Blog, Surpassing Frontier Performance with Fusion, 2026-06-12. 官方标题和开头三点总结见该文开头部分。https://openrouter.ai/blog/announcements/fusion-beats-frontier/ ↩

2. OpenRouter 官方跑分图与表格：DRACO benchmark scores for Fusion and solo configurations。官方图片链接：https://openrouter.ai/blog/images/blog/fusion-benchmark-chart.png ↩

3. OpenRouter 对 Fusion 流程的描述见官方文章 “One API call that fuses the best output of multiple models” 一节，以及 Fusion API 文档。https://openrouter.ai/docs/guides/routing/routers/fusion-router ↩

4. OpenRouter 官方文章 “Significant boost from fusing a model with itself” 一节：Opus 4.8 partnered with itself 得 65.5%，solo Opus 4.8 为 58.8%。https://openrouter.ai/blog/announcements/fusion-beats-frontier/ ↩

5. DRACO benchmark 原文：Evaluating Deep Research Performance in the Wild with the DRACO Benchmark。https://arxiv.org/abs/2604.06281 ↩

6. OpenRouter 官方 FAQ “How should I use Fusion for coding?” 一节：Fusion isn’t a drop-in replacement for coding models，而是 coding model 可选择调用的 server tool。https://openrouter.ai/blog/announcements/fusion-beats-frontier/#614-update-faq-from-the-launch ↩