OpenRouter Fusion API
Openrouter Fusion API

原始链接: https://openrouter.ai/openrouter/fusion

Fusion 将您的提示词转化为多模型协作研讨。一个专家模型小组(见下文)会并行分析您的提示词,并同时启用网络搜索和网页抓取功能;随后,一个判决模型会将它们的回复综合为结构化分析——包括共识、矛盾点、覆盖差异、独特见解及盲点——并据此撰写最终答案。 默认情况下,专家小组采用“质量”预设;您可以切换到“预算”模式以使用成本更低的模型,或通过 Fusion 插件的 analysis_models 和 model 字段完全替换专家小组与判决模型。当单个模型无法满足需求时(例如需要深度研究、专家评判,或任何容错率极低的场景),请选择 Fusion。 由于 Fusion 会运行所有小组模型并进行一次判决调用,因此您的请求费用为这些底层模型调用费用的总和,而非单一模型的费用。如需查看运行过的模型,请访问“活动”页面。详情请参阅我们的文档。如需了解其他路由方式,请查看自动路由(Auto Router)。

Hacker News 关于 OpenRouter “Fusion” API 的讨论凸显了使用多模型“集成”(ensembles)来提升 AI 性能的增长趋势。其核心概念是同时向多个大语言模型(LLM)发送提示词,并使用一个“评判”模型来综合它们的输出结果。 **讨论中的关键要点包括:** * **性能与成本:** 虽然多模型融合的表现可以优于单一模型(特别是在复杂的架构规划或验证任务中),但它显著增加了延迟和成本。许多用户指出,结果往往有好有坏,且高度依赖于评判模型的质量。 * **“同一模型”策略:** 一些参与者建议,仅仅让一个模型进行自我评估,或者以不同的“专家”角色运行同一个模型的多个实例,通常比混合不同模型能获得更好、更具成本效益的结果。 * **提示词工程与可靠性:** 普遍的共识是,质量的提升很大程度上依赖于提示词工程(例如,强制进行对抗性审查、定义特定角色,或要求“零错误”输出)。 * **质疑态度:** 一些用户认为,融合通常只是增加“推理时计算量”(test-time compute)的一种花哨说法,所获得的“智能”提升有时仅仅是统计噪声,而非真正的架构突破。
相关文章

原文

Fusion turns your prompt into a small multi-model deliberation. A panel of expert models (see below) analyzes your prompt in parallel with web search and web fetch enabled, then a judge model synthesizes their responses into a structured analysis — consensus, contradictions, partial coverage, unique insights, and blind spots — and writes the final answer from it.

By default the panel is the Quality preset; switch to Budget for cheaper members, or override the panel and judge entirely with the fusion plugin's analysis_models and model fields. Reach for Fusion when a single model isn't enough — research, expert critique, or anywhere the cost of being wrong outweighs a few extra completions.

Because Fusion runs every panel member plus a judge call, your request is priced as the sum of those underlying completions rather than a single model. To see which models ran, visit Activity.

Learn more in our docs. For another way to route, see the Auto Router.

联系我们 contact @ memedata.com