OpenRouter Fusion API
(openrouter.ai)- 複数モデルの結果を**統合（synthesize）**すると、個別モデル単体の性能を大きく上回り得るという発見から出発
- 単一のプロンプトを複数の専門家モデルが並列に分析し、その後**ジャッジモデル（judge model）が結果を統合して最終回答を作成するマルチモデル熟議（multi-model deliberation）**方式
- パネルモデルはWeb検索とWebフェッチを有効化した状態で並列分析を実行し、ジャッジモデルが合意、矛盾、部分的一致、固有の洞察、盲点を構造化された分析として整理
- デフォルトはQualityプリセットで、Budgetプリセットにより低価格モデルへ切り替え可能。また fusion プラグインのフィールドでパネル・ジャッジを完全に再定義可能
- 単一モデルでは不十分なリサーチ、専門家レビュー、誤答コストが追加の生成コストを上回る状況に適している
- パネルの全構成員とジャッジ呼び出しをすべて実行するため、リクエスト料金は単一モデルではなく個別の completion の合算方式で課金
仕組み
- 単一プロンプトを小規模なマルチモデル熟議に変換する方式
- 専門家モデルのパネルが**Web検索（web search）とWebフェッチ（web fetch）**を有効化した状態で、プロンプトを並列分析
- ジャッジモデルがパネルの応答を統合し、**合意（consensus）、矛盾（contradictions）、部分的カバレッジ（partial coverage）、固有の洞察（unique insights）、盲点（blind spots）**として構造化した分析を生成
- 構造化分析を基に、ジャッジモデルが最終回答を作成
パネル構成と設定
- デフォルトのパネルはQualityプリセットを使用
- より安価な構成員が必要ならBudgetプリセットへ切り替え可能
- fusion プラグインの
analysis_modelsおよびmodelフィールドで、パネルとジャッジを完全にオーバーライド可能
- 単一モデルでは不十分な場合の利用を推奨
- リサーチ、専門家レビュー、または誤答コストが追加の生成コストを上回る領域に適する
価格と制約
- パネルの全構成員とジャッジ呼び出しをすべて実行するため、リクエスト料金は単一モデル基準ではなく個別 completion の合算で課金
- 実際に実行されたモデルはActivityページで確認可能
- コンテキスト上限は選択したモデルによって異なる
プリセットでは6つのモデルを使用
- 最高品質: Claude Opus, OpenAI GPT, Google Gemini Pro
- 最低コスト: Google Gemini Flash, DeepSeek V4 Flash, MoonshotAI Kimi
関連発表: "Fusionでフロンティア性能を超える"
- 複数モデルの結果を統合して個別モデル単体の性能を上回るツールで、参加モデルのパネルと結果を融合するジャッジモデルを直接選択し、単一モデルのように呼び出せる
- DRACOベンチマークの deep research 課題100件の測定で、パネルが個別モデルを一貫して上回った
- Fable 5 + GPT-5.5 の融合は**69.0%**で、単独の Fable 5（65.3%）を含むすべての個別モデルを上回った
- 低価格パネル（Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro）は**コスト50%**で Fable 5 のスコアに1%以内まで迫り、GPT-5.5・Opus 4.8を上回った
- プロンプトをパネルモデルへ並列送信し、ジャッジが合意点・矛盾・固有の洞察・盲点を分析し、呼び出しモデルがそれを根拠に最終回答を作成
- パイプライン全体はserver-sideで実行されるため、個別モデル呼び出しと同じ方式で利用可能
- Opus 4.8を自分自身と融合した場合でも65.5%となり、単独（58.8%）比で6.7ポイント上昇し、synthesis 段階自体の効果を確認
- パネルモデルが採点ルーブリックをオンラインで見つける汚染リスクが見つかり、Web search・Web fetch の除外リストを1行設定で適用して遮断
- 利用方法は4種類: Chatroom（コード不要）、Model slug（文字列置換）、Server tool（最高レベルの制御）、Plugin（パネル指定）
- Fable の drop-in 代替ではなく、Fable が強みを持つlong-horizon 課題は含まれておらず、コーディングでは選択的に呼び出すツールとして活用
1件のコメント
Hacker News のコメント
数か月前に、OpenRouter を使う MCP で Fusion を作ってみた。Claude が詰まったときに頼れる「専門家パネル」を用意しようというアイデアだった
テストやベンチマークをたくさんやってみたが、あるモデルに別のモデルの回答を評価させても、実際にはより良い答えにはならなかった。結局のところ「この答えは、自分なら出した答えとどれくらい似ているか」を聞いているようなもので、追加ラウンドや思いつく「当然の」解決策も、実質的には温度を上げるのと似ていた。解決策自体は見つかったが、コストがばかげて高い。この方式がもっと注目されるようなら、自分のものも公開するかもしれない
自分は明示的に重大度ごとの問題を見つけさせ、その問題を判定モデルのパネルに通し、特定のしきい値を超えたものだけ元の応答で修正させている。結果が大きく改善した気づきは、判定モデルに 真実性 と「有用性／修正すべきか」という軸を分けて評価させることだった。問題を見つけるよう強制すると、結局は細かな粗探しになってしまうからで、真実性の軸は自分の用途に合う問題検出モデルを評価するうえでもより良かった。こうした説明を生成するときに一部適用している: https://hanzirama.com/character/%E6%9D%A5#explain — 今ではこのサイトが、自分の LLM 評価装置の小さな副産物になっている。最高品質が必要なら、OpenRouter ではプロバイダーを固定する必要がある可能性が高い。特にオープンウェイトモデルでは、
:exactoだけで再現可能な良い結果を得るのは難しいLLM を「自分のほうが優れていると感じている」モードにだませると、かなり意地悪になると感じた人がほかにもいるのか気になる
2年前とはまったく違う状況になっているので、もう一度見直す価値はある。[0] https://github.com/Ceroxylon/konsensis
自分のアプリで判定モデルを2つ試した。1つ目は履歴書最適化モデル向けの判定モデルで、出力された履歴書を元の履歴書と求人票に照らして、適合性と誠実性を10点満点で評価したが、うまく機能して有用だった。2つ目は LLM トレーディングボット基盤のレビュー用モデルで、メインモデルの判断を見直すもの。こちらではボットが曖昧さを扱うため、誤ったローソク足価格で判断したり、本来 SELL すべきところで BUY してしまうような明白なミスを捕まえない限り、むしろ害になりかねない。まず判断の遅延が追加され、Gemma 4 31B では30秒だったものが60秒のように倍になってしまう。さらにレビュー用モデルは BUY/SELL の判断時にだけ回り、HOLD には回らないので、遅延とコストのために取引回数が増えるどころか、ボットが過度に慎重になるかもしれない。なので、答えが簡単に検証できないなら、レビュー用モデルを挟むより、より良いモデルで一度に処理するほうがよいと思う。そうなると、なぜ判定モデルが必要なのか、同じエージェントに自分でレビューさせない理由も曖昧になる。しかも Gemma 4 のような推論モデルの推論テキストを読むと、すでに自分でレビューしている。最善を尽くしているわけで、再レビューで情報が大きく増えるわけではない。興味深い実験ではあるが、案件ごとに評価すべきだ
Claude Code だけを使って、こんなふうに使っていたプロンプトがあった
アーキテクチャの問題をレビューしよう。エージェントを10個立ち上げ、それぞれにペルソナを作らせたうえで
_api.goをレビューし、reviews/-review.mdにレビューを書かせる。各エージェントは各レビュー冒頭の要約を見て、希望するレビュー3件にラウンドロビン方式で応答し、response/--response.mdに書き込む。その後、応答への反論をrebuttals/-rebuttal.mdに書かせる。最後に、各エージェントが自分のレビュー、応答、反論をレビューするための別エージェントを再度立ち上げ、結果をfindings/-findings.mdにまとめさせる。最後に別のエージェントが結果を統合してreview-findings.mdに書き、そこで簡潔なバージョンを提示させる。この方式は最先端モデルでもローカルホストのモデルでもうまくいった。最後に使ったのは Qwen 3.5 だった生成されたすべてのファイルを確認して幻覚がないかを見るのか、それとも最後の簡潔な結果ファイルだけを見るのか気になる。複数のエージェントを経ることで幻覚が互いに打ち消し合い、最終的に真実だけが残るという意図なのかも気になる。最終版でひどく間違った内容を見たことがあるかも知りたい。コストは心配だったが、ローカルホストのモデルを使えばその点は軽くなりそうだ。ただ、ローカルホストのモデルは依然としてローカルコマンド実行やインターネットアクセスに問題があるのではないか？ だとすると、プロジェクトの残りの部分を参照せず、そのファイルの文脈だけで回す方式なのかも気になる
背景文脈はこちら: Surpassing Frontier Performance with Fusion
https://news.ycombinator.com/item?id=48525392
UI が少し良いのは https://openrouter.ai/fusion。OpenRouter の Fusion API はリクエストを複数のモデルに同時送信し、判定モデルが回答を統合して最終応答を作る。時間はよりかかる代わりに、性能を大きく高めるという。少なくとも彼らがテストしたディープリサーチのベンチマークではそうだった。Budget プリセットはより安価なモデル 3 つで構成されており、そのベンチマークでは Fable とおおむね同等で、コストは半分。Quality プリセットは高価なモデル 3 つで構成され、Fable を上回るがコストは Fable の 2 倍。パレートグラフ: https://openrouter.ai/blog/images/blog/fusion-benchmark-cost...。興味深いことに、同じモデルを自分自身と融合させても性能は向上していた。2xOpus4.8 はベンチマークで Fable とおおむね同等だが、コストは Fable の 2 倍。異なるモデルを混ぜると追加の利得が少しある。主な利得は追加の テスト時演算 から来ているように見える。最近出た安価なモデル、たとえば DSV4 を自分自身と、あるいは Mimo と融合するケースを中心に、さらに研究が出てほしいし、並列テスト時演算である融合と、推論量増加やターン増加とのトレードオフも見てみたい
要するに、可能な出力空間から サンプルをより多く取ること だ。モデルがある作業を 60% の確率でこなせるなら、5〜10 個のサンプルを取り、多数決のようなものを実装すればよい。結果の結合が容易な問題でモデル精度が上がるにつれて使われにくくなったが、より複雑な判定器、つまり有能な LLM があれば、出力空間をより多くサンプリングして良い部分を選び出すだけでも、依然として性能を上げられる
私には、Gemini はそのタスクでは弱い一方で、自分の解法を判定モデルに納得させる能力は高いように聞こえる。そして Opus 4.8 を 2 つ並べたパネル が Fable 5 単体とほぼ正確に同じ水準なのも、少し怪しい匂いがする。Anthropic が裏でこういうことをそのままやっていたりしないのだろうか?
Opus 4.7 や GPT 5.5 を直接呼ぶのと質的にどう違うのかを見たくて、手早い評価を回してみた
予想どおり Fusion は 7 倍遅く、コストは 4 倍 だった。これを批判したいわけではなく、Fusion は「必要なときだけ使う」カテゴリに入ると見ている。https://3fpi5avcqq.evvl.io/
核心のアイデアは、もっと単純で安いモデルで Fusion を使うことなのだろう
実運用でこの人たちのバージョンがどう持ちこたえるのか気になる
この問題についてかなり考えてきたが、単純化して理解するなら、各モデルを人間の知識上にある ベルカーブ分布 と見なせて、モデルごとに分布が異なる
複数のモデルを使うと、本来の曲線の外にあるテキストで別のモデルの分布を変えられる。しかし考え直してみると、SFP と強化学習が元のテキスト分布を十分に変えて、モデル同士の結合出力がより良い何かになるほど多様になるのか、それとも単なる エコーチェンバー になるのか疑問だ。まだ証明する方法はないが、私はそうではないと信じている
Fusion についての逸話的な結果として、Fable で使ったのと同じクエリを OpenRouter Fusion に投げたところ、結果はより悪かった
Fable はかなり深い知識/知能の層をある程度とらえていて、もっともらしい答えを返すだけでなく、解決項目の優先順位を提案し、一部の項目は捨てるべきだとも言ってきたが、それは私にはかなり妥当に思えた。一方の Fusion は、Fable 以前の最先端モデル群が出していた同系統の答えを少し多様化したような印象で、私が Fable にアクセスできた際のごく限定的なテストでは、Fable が到達していた 深さ には届かなかった
週末に新しい OpenRouter Fusion モデルに触発されて、これを Claude Code で動かせるか、また他の人も簡単に試せる形にできるかを見ようとして作業した
作ったのは claude-fusion-launcher — Claude Code を単一モデルではなく、モデルパネルの上で実行する。コストも表示する。https://github.com/smorinlabs/claude-fusion-launcher
同じモデルで同じプロンプトを複数回、より高い温度で再生成することが、異なるモデルを回すのと同等なのか気になる
異なる最前線モデル間で感じる変動性は、そのかなりの部分が 0 ではない温度によるランダム性から来ているのではないかと疑っている。モデルは 5、10、15 のような見栄えの良い丸い数の項目を返すよう訓練されているように見える。マーケティング資料の学習による干渉のせいかもしれない。しかも大きな文脈では想起率は 100% にはほど遠い。だからコードにバグが 27 個あるなら、複数モデルを使うにせよ同じモデルを繰り返し呼ぶにせよ、各実行でその 27 個のうち異なる 10 個の問題 を見つけることがありうる
この分野に正式な研究があるのか気になる。自分もこうしたアプローチの変形を試してみたが、結果がより良かったと自信を持って言うのは難しかった。
事業の最適戦略をコンサルタント2〜3人にそれぞれ尋ねるのと似ているのではないかと懸念している。答えをまとめることで、実質的により良い何かが生まれるのかよく分からない
私のTrustedRouterにも似た機能をオープンソースで、エンドツーエンド暗号化まで適用して公開した: https://trustedrouter.com/