本文へ
ハクソク

世界を動かす技術を、日本語で。

オープンルーター フュージョン API

元記事: 原文(openrouter.ai)

概要

  • OpenRouter: Fusion は複数AIモデルを組み合わせた高度な分析を提供
  • パネル形式で 専門モデル が並列にプロンプトを解析
  • ジャッジモデル が全体の回答を統合・要約
  • コスト は利用した全モデル分が加算
  • 研究や専門的な批評など 高精度が求められる場面 で活躍

OpenRouter: Fusionの仕組みと特徴

  • Fusion は、プロンプト入力時に複数の エキスパートAIモデル を同時に起動
  • 各モデルが 独自の視点 から回答を生成
  • Web検索・Web取得 機能も活用し、情報の幅を拡張
  • 回答後、 ジャッジモデル が各モデルの出力を分析し、以下の要素を抽出
    • コンセンサス （意見の一致点）
    • 矛盾点 （意見の食い違い）
    • 部分的なカバー （一部のみカバーされた内容）
    • 独自の洞察 （個別モデル特有の視点）
    • 見落とし （全モデルが触れていない盲点）
  • 最終的な回答は、これらを踏まえて 構造化された分析結果 として提供

パネルとプリセット

  • デフォルトは Qualityプリセット （高品質モデル群）を使用
  • Budgetプリセット に切り替えることでコスト削減も可能
  • fusion plugin のanalysis_modelsやmodelフィールドで、パネルやジャッジモデルを カスタマイズ 可能

コストと利用シーン

  • コスト は、パネル内の全モデル＋ジャッジモデル分が合算される仕組み
    • 単一モデル利用時よりも 高額 になる傾向
  • 高精度が必要 なリサーチ、専門家による批評、失敗コストが高い場面で推奨
  • 実行したモデルの詳細は Activityページ で確認可能

利用に関する注意点

  • コンテキスト制限 は選択したモデルに依存
  • 詳細は 公式ドキュメント で確認推奨
  • ルーティングの別手段として Auto Router も提供

API利用方法

  • OpenRouterのAPI は OpenAI互換 で、ベースURLの差し替えのみで多くのSDKが利用可能
  • モデルごとに model slug を指定してAPI呼び出し
  • Quick Startコード も提供されており、簡単に導入可能

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

コンテキスト: フロンティアパフォーマンスを超えるフュージョン https://news.ycombinator.com/item?id=48525392 そして、こちらに少し良いUIがあります: https://openrouter.ai/fusion OpenRouterのフュージョンAPIでは、リクエストが複数のモデルに同時にルーティングされ、ジャッジモデルがそれらの回答を最終的なレスポンスにまとめます。これによりパフォーマンスが大幅に向上しますが、時間がかかるというデメリットがあります（少なくとも彼らがテストした1つのベンチマーク、深い研究ベンチマークでは）。彼らは、3つの安価なモデルからなるバジェットプリセットを用意していて（このベンチマークではFableに大体匹敵し、コストは半分）、3つの高価なモデルからなるクオリティプリセットもあります（これはFableを上回りますが、コストはFableの2倍です）。パレートグラフ: https://openrouter.ai/blog/images/blog/fusion-benchmark-cost... 興味深いことに、モデルを自分自身とフュージョンさせることでもパフォーマンスが向上しました（2xOpus4.8はこのベンチマークでFableに大体匹敵しますが、コストはFableの2倍です）。異なるモデルを混ぜることでさらに小さな利得が得られます。主な利得は追加のテスト時間の計算から来ているようです。これについてもっと研究が進むといいですね。特に最近出た安価なモデル（例えば、DSV4を自分自身とフュージョンさせたり、Mimoと組み合わせたり）に焦点を当てて、フュージョン（並行テスト時間計算）を実行することと、推論やターンの増加とのトレードオフがどうなるのか見てみたいです。

└

Fable 5 + GPT 5.5のパネルがそれぞれのフロンティアを超えるのが面白いけど、Geminiを加えると3つのパネルのパフォーマンスが悪化するのが不思議。私には、Geminiが与えられたタスクでは劣っているけど、解決策をジャッジに納得させるのが得意なように聞こえる。あ、それと2つのOpus 4.8モデルのパネルは、ほぼ1つのFable 5と同じくらい良い。それ、ちょっと怪しいね。Anthropicが裏で何かやっているのか知ってる？

└

現在のモデルでもそうかは分からないけど、数世代前にMicrosoftが行った研究結果では、モデルにN回繰り返すように頼むとパフォーマンスが大幅に向上することが分かっていて、最適な回数は4回だった。

└

興味深いことに、モデルを自分自身とフュージョンさせることでもパフォーマンスが向上しました GPT2からGPT3の時代には、これをやるのが結構一般的だったよね。実際、出力の可能性のあるサンプルをもっと取っているわけ。もしモデルが60%の確率でタスクをこなせるなら、5〜10サンプルを取って、何らかの多数決を実施すればいい。モデルが問題に対して高精度を持つようになると、結果を組み合わせるのが簡単な場合はあまり使われなくなったけど、より複雑なジャッジ（有能なLLM）がいると、出力空間をもっとサンプリングして、最良の側面を選ぶことでより良い結果が得られるよ。

Opus 4.7やGPT 5.5を直接呼び出すのと比べて、質的にどうなるかをサクッと評価してみた。予想通り、フュージョンは7倍遅く、コストは4倍だった。これはフュージョンを否定するものではなく、むしろ「必要な時だけ使う」カテゴリに入ると思う。 https://3fpi5avcqq.evvl.io/

└

これにはどのモデルを使ってたの？インターフェースにあるクオリティデフォルトを使ってたなら、3つのフロンティアモデルを1つのジャッジで評価するから、コストが約4倍になるのは納得できるよ。フュージョンはもっとシンプルで安価なモデルと組み合わせるのが理想だね。

└

フュージョンはすごく良い蒸留ターゲットになりそうだね？

└

そうなんだよね、ちょっと直感に反する感じ。これがうまく機能するためのフレームワークや構造を整えるのは簡単じゃないと思うし、モデル同士がうまく連携するのが苦手なんだよね。彼らのバージョンが実際の使用でどうなるのか気になるな。

へへ。数ヶ月前にOpenRouterを使って「フュージョン」をMCPとして作ったんだ。アイデアは、Claudeが行き詰まった時に「専門家パネル」に相談できるようにすることだった。広範なテストとベンチマークを行った結果、1つのモデルに別のモデルの回答を評価させても、実際にはより良い答えは得られないことが分かった。要するに、「これがあなたが私に与えるだろう答えにどれだけ似ているか」と尋ねているだけ。追加のラウンドや、前の文を読んで思いつく「明白な」解決策は、実質的に温度を上げているだけなんだ。解決策は見つけたけど、めちゃくちゃ高い。これが注目を集めたら、自分のものを公開するかもしれない。

└

うん、同じ経験した。客観的に見て良い答えを見つけるのはそんなに簡単じゃなかったし、コストもかかるし、遅いしね。

└

プロンプトは重要だよね。別のモデルの意見が欲しいなら、同じプロンプトを使ってゼロから生成しないといけないし、その後で合成を試みることができるけど、既存のレスポンスを使うのも可能だよ。私は、割り当てられた重要度で問題を見つけるために明示的な指示を使っていて、それが審査員のパネルを通過するんだ。特定の閾値を超えた問題だけが元のレスポンスで修正される。私の結果を大幅に改善した発見を共有するね：審査員には真実と有用性/修正すべき軸を別々に評価するように言うといいよ。プロンプトが問題を見つけることを強いると、どうしても細かい指摘が出てきちゃうからね。それに、真実の軸を使うことで、あなたのユースケースに合った問題発見モデルをより良く評価できるんだ。これが私がこういう説明を生成するときに起こることの一部だよ： https://hanzirama.com/character/%E6%9D%A5#explain - 現時点では、そのサイトは私のLLMs評価機構の小さな副産物なんだ。忍耐強い読者へのボーナスコンテンツ：最高の品質が必要なら、プロバイダーをORにピン留めする必要があるかも。:exactoだけでは、特にオープンウェイトモデルに対して良い再現性のある結果を得るには不十分だと思うよ。

└

ベンチマークについて書いたら、ぜひ興味あるな！人々はLLMをジャッジやパネルとして使うと結果が良くなると思ってるみたいだけど（コードレビューみたいな場合は確かにそうかも？）、でもそれは状況によると思うし、人間の専門家のパネルからの先入観がいつもきれいに翻訳されるわけじゃないと思うんだ。

Hacker Newsで議論の続きを見る

同じ出典の記事