マイクロエージェント：モデルAPI内のコラボレーションでフロンティアモデルを凌駕する

目次 誰もが次のフロンティアモデルに注目しています。しかし、より興味深い層は、その手前にあるかもしれません。ルーターはAI推論の制御プレーンになりつつあります。その最初の役割は実用的でした：適切なリクエストを適切なモデルにルーティングすることです。これはすでに重要です。なぜなら、本番環境のAIはもはや単一モデルの世界ではないからです。ルーターは、リクエストがフロンティアモデルに値するか、それともオープンソースモデルやローカルモデルで十分かを判断することでコストを削減できます。また、機密性の高いドメインをより厳格なモデル、より厳格なフィルター、またはより強力なレビューパスに送ることで、安全ポリシーを実行可能にできます。クラウドとエッジを連携させ、プライベートな意図や低レイテンシーの意図をローカルに保ちながら、より困難な作業をクラウドにエスカレートさせることも可能です。これらは重要な仕事です。しかし、次のルーターの仕事はもっと興味深いものです：ルーターはモデルをより良くすることができます。重みを変えることによってではありません。すべてのアプリケーションに特注のエージェントグラフを構築するよう求めることによってでもありません。1つのモデルAPIコールを、サービングレイヤー内での境界のあるコラボレーションに変えることによってです。 図1：ルーターはモデル選択から機能構築へと移行しています。 これがSakana Fuguがこれほど大きな反響を呼んだ理由です：それは、シンプルだが強力なアイデア、つまり「モデル」が表面であり、その表面の裏にはチームが存在しうるというアイデアから商業製品を生み出しました。Fuguの技術レポートやConductor、Trinityといった連携に関する論文を含むこのアイデアに関する研究は、オーケストレーションについて考える上で役立つ言語を提供します。しかし、vLLM Semantic Routerのビジョンは、抽象化をどこに置くかという点で異なります。コラボレーションは、単一の商用エンドポイントや単一のアプリケーション固有のエージェントグラフ内でのみ存在するべきではありません。それはオープンなサービングプリミティブとなるべきです。vLLM Semantic Routerは、そのアイデアをオープンなサービングレイヤーにもたらします。ユーザーは引き続き1つのモデルを呼び出します： { "model": "vllm-sr/auto", "messages": [{"role": "user", "content": "..."}] } その安定したモデルIDの背後で、ルーターはレシピを選択し、ワーカーにファンアウトし、クォーラムを収集し、不一致を検証し、最終的な回答を合成し、出力契約を修正し、通常のOpenAI互換の応答を1つ返します。ポイントは複雑さを露呈することではありません。ポイントは、コラボレーションをモデルのように感じさせることです。 ルーパーはランタイムである vLLM Semantic Routerでは、ルーパーは境界のあるマイクロエージェントの実行ランタイムです。リクエストは通常のチャット補完としてルーターに入ります。ルーターはシグナルを抽出し、それらをタスク形状またはリスクバンドに投影し、決定をマッチングし、その後アルゴリズムを選択します。そのアルゴリズムは通常の単一モデルルートである場合もあれば、ルーパールートである場合もあります。現在、主なルーパーパターンは次のとおりです。 信頼度（Confidence）：シーケンシャルなエスカレーションループです。まず安価な候補を試し、信頼度を測定し、スコアが低すぎる場合にのみエスカレートします。 評価（Ratings）：境界のあるファンアウトループです。ハードな並列実行上限の下で複数の候補を実行し、評価を考慮した重みで集計します。 ReMoM（Repeated Mixture-of-Model Reasoning）：モデルの反復混合推論です。幅広くサンプリングし、十分な成功応答を待ち、最終的な合成ラウンドを実行します。 融合（Fusion）：パネル審査員最終パターンです。独立したモデル応答が審査員と最終化のための証拠となります。 ワークフロー（Workflows）：マイクロエージェントワークフローランタイムです。静的な役割または動的なプランナーをサポートし、境界のあるワーカーステップを実行し、最終応答を合成します。 図2：ルーター内でルーパーアルゴリズムが実行され、モデルAPIの表面を保持します。 実装の詳細が重要です。ルーパーは「より多くのモデルに尋ねる」というスローガンではありません。それは、予算、トポロジ、トレース、および失敗ポリシーを備えた小さなランタイムです。 信頼度：困難なケースにのみエスカレーションを費やす 信頼度はコストを意識したループです。まず、より小規模または安価な候補から始め、次にその回答が停止するのに十分な信頼度があるかどうかを評価します。信頼度シグナルは、トークンレベルのログ確率、ログ確率マージン、ハイブリッドスコア、自己検証、またはAutoMixスタイルの含意検証器から得られます。スコアがしきい値を超えると、ルーターはすぐに応答を返します。スコアが低すぎる場合、ルートは次の候補にエスカレートします。重要なのはエスカレーションが存在することではありません。エスカレーションが明示的なルーターポリシーになることです：しきい値、失敗動作、および停止条件は可視化され、調整可能です。 図3：信頼度はエスカレーションを測定された停止ポリシーに変えます。 評価：ハードキャップ下の並列品質 評価は制御されたアンサンブルループです。複数の候補を並行して起動しますが、設定されたmax_concurrent上限までです。これにより、すべてのリクエストを無制限のファンアウトに変えることなく、複数のモデルビューからルートが恩恵を受けるべき場合に役立ちます。ルーターは成功した応答を収集し、評価を考慮した集計を適用し、ルートポリシーに従って失敗を処理します。実際には、評価はA/Bスタイルの評価、アンサンブル戦略、およびオペレーターがすでに意味のある候補ごとの品質シグナルを持っているルートに適しています。 図4：評価は複数候補の実行を境界化し、評価を考慮します。 ReMoM：契約のある幅広さ ReMoMは、タスクの推論のばらつきが大きく、回答形式がコラボレーションに耐える必要がある場合に役立ちます。複数の推論試行をファンアウトし、最小成功クォーラムを待ち、その後合成モデルに証拠を要求された出力契約にマージするように求めます。合成が失敗しても、以前のワーカーが有効な証拠を生成した場合、ルートはAPIエラーに崩壊する必要はありません。最良の有効な証拠にフォールバックし、それでも通常の応答を返すことができます。 図5：ReMoMは、幅広さ、クォーラム、合成、およびフォールバックをサービング時制御として扱います。 融合：不一致をシグナルとして 融合は異なる賭けから始まります。有用なオブジェクトは平均的な回答ではなく、不一致の構造である場合があります。独立したパネルの回答が証拠となります。審査員は合意、矛盾、独自の洞察を把握し、その後最終化者がAPIの背後にトレースが畳み込まれた1つの回答を返します。これにより、融合は、もっともらしい競合するパスがある場合に特に役立ちます。たとえば、困難な多肢選択式推論、長文の専門家判断、または単一の自信に満ちた応答が脆弱である可能性がある厳密な回答タスクなどです。 図6：融合は不一致を隠しません。不一致を証拠に変えます。 ワークフロー：予算下の役割 ワークフローは最もエージェント的なパターンであり、最も厳格な境界を必要とします。プランナーは許可されたワーカーモデルしか選択できません。計画は検証されます。ステップは最大ステップ数、最大並列処理数、タイムアウト、エラーポリシーによって境界が定められます。最終応答は出力契約を満たす必要があります。SWEスタイルのタスクの場合、これはルーターがプランナー、パッチャー、検証者、最終化者を表現できることを意味し、アプリケーションが特注のエージェントスタックを所有する必要はありません。本番環境のサービングでは、この区別が重要です。ループは強力ですが、依然としてインフラストラクチャによって管理されます。 図7：ワークフローはルーターに境界のある役割システムを与え、無制限の自律エージェントではありません。 自動レシピ：1つのモデル名、多くのループ パブリックインターフェースは引き続き1つのモデル名：vllm-sr/autoです。内部的には、ルーターはシグナルとプロジェクションを使用して、リクエストに適したループを選択できます。難易度、リスク、契約のプレッシャー、レイテンシー、コストはプロンプト内のコメントではありません。これらは、信頼度、評価、ReMoM、融合、ワークフロー、またはフォールバックパスを選択できるルーティングファクトです。 図8：自動レシピにより、シグナルがコラボレーションパターンを選択しながら、1つのモデルIDを保持します。 これが「アプリロジックとしてのエージェント」と「サービングランタイムとしてのマイクロエージェント」の違いです。ルーターは予算、ポリシー、トポロジ、トレース、および失敗モードを制御します。 レシピは1つのユニバーサルループを打ち負かす 私たちの評価作業から得られた最も重要な教訓は、1つのアルゴリズムが常に勝つわけではないということです。その逆です：最適なループはタスクの形をしています。GPQA-Diamondは厳密な多肢選択式回答の保持を望んでいます。LiveCodeBenchは実行可能なコードと隠されたテストの堅牢性を望んでいます。Humanity's Last Examは不一致の解決と厳密な回答形式を望んでいます。SWEスタイルのタスクにはプランナー、パッチャー、検証者、最終化者が必要です。そのため、vllm-sr/autoは「常に」を意味すべきではありません。