AIREITER在 OpenRouter 的模型页面上，一次 Fusion 请求可能显示为免费，但实际成本却是普通补全的数倍。原因并不复杂：OpenRouter Fusion 的价格来自多个底层模型调用之和，而不是一项独立的 Token 费率。最终是否值得这份额外的交叉审查，主要取决于面板规模和 Token 用量。
先用一个结论理解 OpenRouter Fusion 定价
与只调用一次同档模型相比，OpenRouter Fusion 通常更贵。OpenRouter 的 Fusion Router 文档介绍了默认的三模型面板，以及一次分析员调用；按同一提示词计算，总成本大约是单次补全的 4–5 倍。
如果一个预算型面板能通过提升回答质量来减少复核工作，它的总成本可能低于直接使用高端模型。但 Fusion 本质上是“成本换验证”的选择，并不是天然更便宜的模型。
| 使用场景 | 默认更合适的选择 |
|---|---|
| 简短、常规、低风险请求 | 单模型 |
| 存在相互竞争证据的研究任务 | 有选择地使用 Fusion |
| 高并发或对延迟敏感的流量 | 单模型或针对性升级 |
| 错误代价高，或需要人工复核 | 先试用 Fusion，并量化节省的成本 |
计费单位是一组调用，而不是一个 Fusion Token
OpenRouter 的 Fusion API 页面将 Fusion 定义为路由器，并显示该路由别名的提示词和补全价格为 0。这个标签只代表 Fusion 没有单独的独立费率，并不意味着底层推理免费。
文档描述的执行过程如下：
- 提示词会发送给每个选中的面板模型。
- 分析员或评审模型会比较各个面板模型的回答。
- 外层模型生成最终答案。
做预算时，可以使用下面这个公式：
Fusion cost = sum(panel model costs)
+ analyst/judge cost
+ any final outer-model cost shown for your integration具体如何计费，取决于你是通过 openrouter/fusion 模型别名调用 Fusion，还是将其作为 openrouter:fusion 服务器工具使用。不要根据路由器显示的 $0 一行来推断最终账单，应该检查实际的生成记录以及 OpenRouter Activity。
OpenRouter 文档支持使用1–8 个分析模型。默认面板包含三个模型。由于 Quality、Budget 和自定义配置各不相同，Fusion 不存在一个适用于所有情况的统一“每百万 Token 价格”。
面板规模会线性推高账单，但评审成本还会继续增长
如果每个面板模型收到相同的提示词，并生成长度相近的回答，那么每增加一个面板成员，基本就等于多增加一次模型调用。OpenRouter 明确表示，成本会随面板规模线性增长。
不过，只看调用次数还不足以估算评审成本，因为评审模型的输入会随着面板输出变长：
C(n) = n × Cp + Cj(n) + Co其中，n 是面板模型数量，Cp 是单个面板回答的平均成本，Cj(n) 是包含增长中输入成本在内的评审成本，Co 是适用时的外层响应成本。
| 面板规模 | 面板调用 | 分析员调用 | 外层响应之前的简化调用栈 |
|---|---|---|---|
| 1 | 1 | 1 | 2 次调用 |
| 2 | 2 | 1 | 3 次调用 |
| 3（默认） | 3 | 1 | 4 次调用 |
| 4 | 4 | 1 | 5 次调用 |
| 5 | 5 | 1 | 6 次调用 |
| 8（最大值） | 8 | 1 | 9 次调用 |
因此，默认三模型面板的 4–5 倍估算，比路由器显示的 $0 更适合作为预算起点。如果评审模型价格较高、输出较长，或者外层模型又增加了一次付费补全，实际倍数还会继续上升。
一个可替换费率的计算示例
你可以将实际选用模型的最新费率代入下面这张计算表。以下数字仅用于演示，并不是 OpenRouter 的价格：假设输入 Token 为 10,000，每个面板回答输出 2,000 Token，评审输入 6,000 Token，评审输出 1,000 Token。
Panel input = 10,000 × sum(panel input rates)
Panel output = 2,000 × sum(panel output rates)
Judge input = 6,000 × judge input rate
Judge output = 1,000 × judge output rate
Fusion total = panel input + panel output + judge input + judge output如果单模型基线处理同样的 10,000 个输入 Token 和 2,000 个输出 Token，就可以直接将其总成本与这张计算表的结果比较。以三模型面板为例，提示词会产生三次输入费用，而评审模型在这个示例中还要读取单独的 6,000 Token 上下文。如果你的提示词或回答更长，应相应调整这些假设。
在各调用成本相同的简化假设下，调用次数大致如下：
| 配置 | 面板小计 | 分析员 | 标准化总成本 |
|---|---|---|---|
| 单模型 | — | — | 1× |
| Fusion，1 个面板模型 | 1× | 1× | 2× |
| Fusion，3 个面板模型 | 3× | 1× | 4× |
| Fusion，5 个面板模型 | 5× | 1× | 6× |
| Fusion，8 个面板模型 | 8× | 1× | 9× |
这些不是 OpenRouter 的实际价格，只是为了展示在模型费率出现差异之前，面板数量本身就会如何影响成本。便宜面板搭配昂贵评审模型时，评审成本可能占主导；反过来，如果面板使用前沿模型，面板成本也可能超过评审成本。
Token 用量会从两个方面改变成本对比
与单次调用相比，Token 用量对 Fusion 的影响更大：提示词会被重复处理，评审模型还要接收面板模型生成的回答。
1. 面板中的输入 Token 会重复计费
设 I 为提示词 Token 数，Pi 为面板模型 i 的输入价格：
Panel input cost = I × (P1 + P2 + ... + Pn)一段 10,000 Token 的提示词发送给三个面板模型，就会产生三次底层输入费用，而且三个模型的费率还可能不同。
2. 输出 Token 也会随面板数量增加
如果每个面板模型输出 O 个 Token，那么整个面板大约会生成 n × O 个输出 Token。若计费中包含推理 Token，最终差距还可能大于可见回答长度所体现的差距。
随后，评审模型还要读取这些输出：
Judge input ≈ original prompt + n × panel output + orchestration overhead因此，回答越长，成本不仅会通过每个面板响应增加，还会进一步扩大评审模型的输入上下文。
| 工作负载特征 | Fusion 的主要成本压力 | 实际建议 |
|---|---|---|
| 短提示词、短回答 | 面板调用次数占主导 | 除非已经证明质量提升，否则保持较小面板 |
| 长提示词、短回答 | 重复输入占主导 | 仔细比较输入费率 |
| 短提示词、较长面板回答 | 评审输入快速增长 | 限制补全长度和推理预算 |
| 长研究提示词、长回答 | 两种影响叠加 | 只有在复核节省足以抵消成本时才使用 Fusion |
| 高并发的重复任务 | 每次请求都会重复整套调用 | 单模型通常是更经济的基线 |
可以用下面的公式估算月度成本：
Total monthly cost ≈ requests × (panel input + panel output
+ judge input + judge output
+ outer response)实际计算时，应使用面板中具体模型 ID 对应的最新费率。“Budget”只是预设名称，并不保证总成本一定低于所有单模型方案。
该选 Budget、Quality，还是单模型？
如果速度、结果稳定性和可预测的账单比独立复核更重要，就选单模型。这适用于格式化、信息提取、自动补全、常规改写，以及许多普通的编程请求。
如果遗漏问题的代价很高，则可以考虑 Fusion，例如资料密集型研究、专家评审、尽职调查，或存在相互竞争证据的决策场景。先从能够回答问题的最小面板开始。三个模型是文档中的默认配置；八个模型是上限，不是建议值。
真正应该比较的是：
incremental Fusion cost
versus
avoided correction cost + saved human review time + reduced error exposureOpenRouter 在另一篇基准测试公告中公布了包含 100 个任务的 DRACO 评测结果，其中前沿 Fusion 配置的成绩为 69.0%，预算型面板为 64.7%。这些数据说明 Fusion 适合深度研究场景，但不能当作所有提示词的通用转化率，也不能证明面板越大就越划算。
扩大规模前，先核对真实成本
第一次部署 Fusion 时，最好把它当成一次测量实验。记录以下信息：
- 面板模型 ID 和评审模型 ID。
- 输入、输出以及在接口中可见的推理 Token 用量。
- 能够确认 Fusion 是否实际运行的路由器元数据。
- 总成本和延迟。
- 最终答案是否减少了人工修正。
Fusion 文档表示，生成元数据可能包含 "router": "openrouter/fusion"。普通的 model 字段只标识实际处理请求的具体模型，不足以证明请求确实经过了 Fusion。
一则用户报告也说明了配置方面的风险：
“这个 \"Fusion\" 仍然会调用 Opus 4.8 作为评审模型。我没找到禁用它的方法。”——X 用户 @teortaxesTex
这是一则用户报告，并不是 OpenRouter 的定价规则。它说明，即使面板成本很低，如果评审模型价格昂贵，或者实际配置与你预期不同，一次运行的总成本也未必低。
用于生产环境时，如果 API 支持，应该固定面板模型和评审模型，设置预算上限，并将 Fusion 作为明确的升级路径，而不是让每个自主请求都默认使用它。
OpenRouter Fusion 定价常见问题
Fusion 比单模型便宜吗？
如果对比的是价格相近的单模型，通常不会。预算型面板有时能以低于高端模型的成本提供足够的质量，但最终结果取决于面板费率、评审成本和 Token 用量。
OpenRouter Fusion 免费吗？
路由别名自身的提示词和补全字段可能显示为 $0。但 OpenRouter 另行说明，底层面板模型和评审模型的补全会计费，因此不能默认认为一次普通 Fusion 请求的成本为零。
一次 Fusion 请求会产生多少次调用？
文档描述的流程包含 N 次面板调用和一次分析员调用，最终的外层响应次数则取决于具体集成方式。默认三模型配置的成本约为一次可比单模型补全的 4–5 倍。
面板越大，性价比就一定越高吗？
不一定。增加模型可以扩大覆盖范围，但也会增加面板费用、评审输入、延迟以及相关性错误。只有当留出测试表明新增质量带来的收益高于成本时，才应该扩大面板规模。
如何估算 OpenRouter Fusion 的成本？
列出所有底层模型调用，按预期 Token 数乘以当前输入和输出费率，同时计入包含面板输出的评审输入成本；完成真实请求后，再到 Activity 中核对结果。第三方计算器可以帮助你模拟不同场景，但 OpenRouter 的实时费率和 Activity 记录才是最终依据。
实际应该怎么选
先把单模型作为基线，用这套方案和一个小型 Fusion 面板分别跑一组包含 20–50 个提示词的留出测试。只有当减少的事实错误、遗漏证据或人工复核时间足以覆盖额外的面板和评审 Token 成本时，才值得保留 Fusion。
对大多数团队来说，更稳妥的成本控制方案是：常规流量使用单模型；不确定或高成本决策使用小面板 Fusion；只有在实测收益经得起账单检验时，才扩大面板规模。