Skip to main content

1. 特性介绍

Fusion 模型(融合模型)是 PPIO 智能模型网关提供的多模型融合推理能力。调用 Fusion 模型时,网关不会只询问一个模型,而是将您的请求同时分发给多个各有所长的“专家模型”并行作答,再通过思考编排与交叉验证,由主模型融合生成最终答案——相当于让每一次模型调用都变成一场“专家会诊”。 与仅做简单请求转发的传统 API 网关不同,Fusion 模型以智能优先、兼顾性价比:通过工程化的融合手段,把回答质量稳定在头部旗舰模型梯队,同时把成本控制在中低梯队。
实测数据:在 DRACO 深度研究基准测试中,PPIO Fusion 模型以 Kimi K3、GLM 5.2、MiniMax M3 为参考模型(Advisors)、DeepSeek V4 Flash 为融合主模型(Aggregator)进行融合推理,取得 57.34 分,超越 Claude Fable 5 的 55.14 分,而总成本仅为其约 1/10
核心特性一览
  • 多模型并行推理:一次请求,多个专家模型同时作答
  • 交叉验证与融合:多模型思考编排,避免单模型“偏科”导致的错误
  • OpenAI 兼容接口:仅需修改 model 参数即可接入,无需改造现有代码
  • 支持流式输出、工具调用(Function Calling)、结构化输出与多模态输入

2. 应用场景

Fusion 模型专为高价值、高风险或结果不确定的关键任务设计。单模型可能在推理时不够深刻、在检索时记忆不足、在生成时文采平平,而 Fusion 模型通过多专家协同显著提升这类任务的一次性成功率,减少返工。 典型场景包括:

3. 工作原理

Fusion 模型的一次完整调用包含以下阶段: Fusion 模型工作原理
  1. 请求分发:您以 pprouter/fusion 为模型发起请求,网关将问题同时分发给参考模型面板(当前为 PPIO 官方选定并持续调优的专家模型组合)。
  2. 并行作答:各参考模型独立、并行地处理您的请求,互不干扰。
  3. 思考编排与上下文压缩:网关对多个模型的思考过程和答案进行编排与压缩,提炼共识、识别分歧、发现各自的盲区,同时控制传递给主模型的上下文规模。
  4. 主模型融合作答:主模型基于编排后的多方结果生成最终回复;如请求中携带工具定义,工具调用也由主模型在此阶段发起。
整个过程对开发者完全透明——您发出一次标准的 Chat Completions 请求,收到一次标准的响应,融合过程在网关内部完成。

4. 使用说明

Fusion 模型提供 OpenAI 兼容接口。您只需将 base_url 指向 PPIO 网关,并将 model 设置为 pprouter/fusion
  • Base URLhttps://api.ppio.com/openai
  • 模型名称pprouter/fusion
  • 鉴权方式Authorization: Bearer <您的 API Key>(API Key 可在 PPIO 控制台创建)

cURL

Python(OpenAI SDK)

JavaScript / Node.js(OpenAI SDK)

支持的能力

5. 费用说明

Fusion 模型按实际消耗汇总计费
  • 一次 Fusion 模型请求在网关内部会产生多次模型调用(多个参考模型的并行调用 + 主模型的融合作答)。
  • 每次内部调用按对应模型自身的 token 单价计费,最终汇总为本次请求的总费用。
  • 各模型的具体单价请以 价格页面 为准。
成本预期:由于涉及多个模型协同,单次 Fusion 模型请求的费用高于调用单个模型。但在复杂任务上,Fusion 模型以中低梯队的模型成本达到甚至超越头部旗舰模型的效果——以 DRACO 基准为例,Fusion 模型总成本仅为 Claude Fable 5 的约 1/10。同时,网关内置的上下文压缩机制会控制内部调用的 token 消耗,避免成本随模型数量线性膨胀。 成本建议
  • 将 Fusion 模型用于高价值、高风险的关键步骤,而非全部请求;
  • 简单、高频的任务使用模型调度功能或直接调用轻量模型;
  • 通过 PPIO 控制台查看用量明细,持续监控实际消耗。

6. 常见问题

Q1:每次调用 pprouter/fusion 都会触发多模型融合吗? 是的。当前版本中,每次请求都会执行完整的多模型并行推理与融合流程,确保输出质量稳定。 Q2:我可以指定参考模型面板中包含哪些模型吗? 当前版本的参考模型组合由 PPIO 官方选定并持续调优,暂不支持自定义。参考模型自定义能力将在后续版本开放,敬请关注官方更新公告。 Q3:Fusion 模型的响应延迟会比单模型高吗? 会有一定增加。虽然参考模型是并行调用的,但融合流程包含“参考模型作答 → 思考编排 → 主模型作答”多个阶段,整体延迟高于单模型直接调用。因此 Fusion 模型更适合对结果质量敏感、对延迟相对宽容的场景;延迟敏感的高频任务建议使用模型调度功能。 Q4:Fusion 模型既然内部调用多个模型,为什么说它性价比高? Fusion 模型的对标对象是头部旗舰模型。在复杂任务上,直接使用旗舰模型价格昂贵;Fusion 模型用多个中低价位模型协同,达到甚至超越旗舰模型的效果,而总成本显著更低(DRACO 基准中约为 Claude Fable 5 的 1/10)。此外,上下文压缩与思考编排机制也在持续控制内部 token 消耗。 Q5:现有基于 OpenAI SDK 的代码需要改造吗? 不需要。Fusion 模型完全兼容 OpenAI Chat Completions 接口,只需将 base_url 改为 https://api.ppio.com/openaimodel 改为 pprouter/fusion 即可。 Q6:如何查看每次 Fusion 模型请求的实际费用? 请登录 PPIO 控制台查看用量与账单明细。
最后修改于 2026年8月4日