ルーターによる AI 推論の進化：マイクロエージェントとサービングランタイムの新境地

皆様は次期フロンティアモデルの登場を注視していますが、それよりも興味深い層がその直前に存在します。それは、AI 推論における制御プレーンとなっている「ルーター」です。

1. ルーターの新たな役割と使命

従来のルーターは単なる経路選択機能に留まっていましたが、現在の状況では生産環境において**「一つのモデルの世界」は終了**しています。次なるミッションは以下の通りです：

• コスト削減の実現:
  • リクエストがフロンティアモデルにふさわしいか、オープンソースまたはローカルモデルで十分かを判断し、適切なリクエストを適切なモデルへ導きます。
• 安全性ポリシーの実行:
  • 機密性の高いドメインに対し、厳格なモデル、フィルタ、審査プロセスへと自動的に振り向けます。
• クラウドとエッジの調整:
  • 個人データや低レイテンシを求められる意向はローカルで保持し、高度な処理についてはクラウドへ昇華させます。

2. 「ルーターはモデル自体をより良くする」

この能力は単なるモデル重みの変更や、各アプリケーション固有のエージェントグラフ構築によるものではありません。インフラ層内で API 呼び出しを有界な協調作用（Coordination）へと変換することで実現されます：

• 【図 1: 移行の概要】
  • 役割が「モデル選択」から「能力構築」へ移行しています。
  • 「モデル」を表面とし、「背面」にはチームが存在するという思想を商用製品として昇華しました。
• オープンなサービングプリミティブ:
  • 協調作用は単一の商用エンドポイントや特定のアプリケーショングラフ内に限定されず、オープンなサービング層へ持ち込まれます。
• vLLM セマンティックルーターのアプローチ:
  • ユーザーが呼び出すのは依然として一つのモデルです。

{
  "model": "vllm-sr/auto",
  "messages": [{"role": "user", "content": "..."}]
}

• 背後の仕組み:
  • ルーターがレシピを選択し、ワーカーへブロードキャスト（fan out）して回答を集約します。
  • 意見の不一致を検証し、最終的な回答を合成します。
  • 出力契約を修復し、通常の OpenAI 互換レスポンスとして一つの回答を返します。
• 目的:
  • 複雑さを暴露することではなく、協調作用がモデルのように感じられるようにすることです。

3. ルーパー（Looper）：実行時のランタイム

vLLM セマンティックルーターにおいて、「ルーパー」は有界なマイクロエージェントの実行ランタイムです。リクエストは普通のリクエストとして処理され、ルーターがシグナル抽出や判断を経てアルゴリズムを選定します。

主なルーパーパターン

現在、実装されている主要なルーパーのパターンは以下の通りです：

1. 信頼度 (Confidence):
   • シーケンシャルなエスカレーションループ。
   • コストの低い候補を試し、回答の信頼度を測定します。
   • スコアが閾値以下の場合のみエスカレーションを行います。
2. 評価 (Ratings):
   • ハードな並行性キャップ（上限）を持つ有界ブロードキャストループ。
   • 複数の候補を並列実行し、評価を意識した重み付けで集約します。
3. **ReMoM **(Repeated Mixture-of-Model reasoning):
   • 幅優先サンプリングを行います。
   • 十分な数の成功した回答（クォーラム）を得るまで待ち、合成モデルを用いて証拠を統合します。
   • 合成に失敗しても、最良の有効な証拠にフォールバックし、通常のレスポンスを返すことができます。
4. フュージョン (Fusion):
   • パネル・ジャッジ・フィナルのパターンです。
   • 独立したモデル回答は証拠となり、それを元にして最終決定者（フィナライザー）が一つの回答を生成します。
5. **ワークフロー **(Workflows):
   • マイクロエージェントワークフローランタイムです。
   • 静的な役割からダイナミックなプランナーまでをサポートし、有界なステップを実行して最終回答を合成します。

実装の詳細: ルーパーは「より多くのモデルに問い合わせる」スローガンの代名詞ではなく、予算、トポロジ、トレース、フェイルポリシーを有する小さなランタイムです。 【図 2】 ルーパーアルゴリズムはルーター内部で動作し、モデル API の表面を保ち続けます。

各パターンの詳細実装

信頼度：困難なケースへのみのエスカレーション

• コストを意識したループであり、低コストな候補から始めて信頼度を評価します。
• シグナル源: トークンレベルのログ確率、マージンスコア、自己検証、AutoMix 式のエンタイルメントベリファイアなど。
• 挙動: スコアが閾値以上なら即座に返却。低すぎる場合はエスカレーション。

評価：ハードキャップ内での並列品質

• 制御されたアンサンブルループです。設定された

  max_concurrent

  を超えない範囲で並列起動します。
• これにより、無制限なブロードキャストを防ぎつつ、複数のモデルビューからの恩恵を受けます。
• A/B テストやアンサンブル戦略において非常に適しています。

ReMoM：契約を持つ幅

• 高い推論変動があり、回答形式の整合性が求められるタスクに有用です。
• 最小成功数（quorum）を得るまで複数回の試行を待機し、合成モデルで証拠を統合します。
• 合成失敗時は、以前生成された有効な証拠へのフォールバックが可能です。

フュージョン：不一致をシグナルとする

• 平均的な回答ではなく、不一致の構造そのものを利用します。
• ジャッジャーは合意や矛盾を検出し、フィナライザーがこれを一つの回答に統合します。
• 難易度の高い択一推論や、長文書での専門家判断、単一の自信あるレスポンスが必要な場合に有用です。

ワークフロー：予算内での役割

• エージェント的な最も厳格な境界を持ちます。プランナーは許可されたモデルのみを選択でき、計画は検証され、ステップ数やタイムアウトで制限されます。
• SWE 風のタスクにおいて、ルーターがプランナー、パッチャー、ベリファイア、フィナライザーを表現できます。
• 重要: ループは強力ですが、インフラストラクチャによって依然として統治されています。

4. オートレシピ：一つのモデル名、多数のループ

公開された表面は単一のモデル名（

vllm-sr/auto

）です。内部ではシグナルと射影を利用して、リクエストに適したループ（アルゴリズム）を選択します。

• 選択基準: 難易度、リスク、契約圧力、レイテンシー、コストなど。
• 「エージェントをアプリロジックとする」vs「マイクロエージェントをサービングランタイムとする」の違い:
  • ルーターが予算、ポリシー、トポロジ、トレース、フェイルモードを制御します。

レシピは万能な単一ループに勝つ

重要な教訓：最適なループはタスク形状によって決まります。常に最大のループを実行するのではなく、タスクに特化したレシピを選択します。

• GPQA-Diamond: 難易度の高い科学関連択一プロンプトに対し、厳密な ANSWER: X の保存を行う ReMoM レシピを使用。
• LiveCodeBench: 制約条件や隠蔽テストリスクを検出し、コード形ループを選択する前に安全性をチェック。
• **HLE **(Humanity's Last Exam): 形式推論や長文脈の正確さを重視し、より深い ReMoM やフュージョンを選択。

結論: プロンプトは一部です。レシピがモデルプール、役割、推論労力、並行性、合成モデル、出力契約などを定義し、プロンプトエンジニアリングを超えた制御を実現します。

5. スコアカード：ベンチマーク結果

3 つの難易度の高いベンチマークで評価した結果、以下のスコアが得られました（数字は有用であり、思想の実用性を示しています）。

ベンチマーク	VSR Closed スコア	リファレンス行 (対照成績)
LiveCodeBench (2025 年 1〜4 月)	92.6	Fugu Ultra 92.0, GPT-5.5 90.7 など
GPQA-Diamond	96.0	Fugu Ultra 95.5, GPT-5.5 93.6 など
Humanity's Last Exam	50.0	Fugu Ultra 50.0, Gemini 3.1 Pro 45.0 など
**HLE **(VSR Hybrid)	47.1	GLM-5.2 40.5, Qwen3.7 Max 41.4 など

• VSR Closed: レシピがクローズドモデルバックエンドのみを使用します。
• VSR Hybrid: リスクの高い箇所や修復・合成が必要な部分で、オープン・クローズドをミックスし強力なクローズドモデルを使用します。

慎重な解釈

これが多様なリクエストで常にすべてのクローズドモデルを使用することを意味するわけではありません。ルーター所有の協調作用は、個々の呼び出しよりも強い**「モデルアイデンティティ」**を創造可能です：

• ユーザーは一つのモデル名しか見ていません。
• オペレーターはレシピを制御します。
• システムはクライアント統合を変更せずに改善できます。
• オープンとクローズドのモデルが同じサービング抽象化の下で参加できます。

6. モデルサービングにおける意義

古いサービングスタックは受動的（モデル名を受け取り送信のみ）でしたが、次なるサービングスタック是能動的です。

「このリクエストはどう処理すべきか？」という問いを投げかけます：

• 証拠は何ですか？
• どの品質・コスト・安全性のバンドに分類されますか？
• 一つのモデルで十分ですか？
• 回答契約を守れるか？
• プロバイダーが誤った場合、どう対処するか？
• 一つのきれいなレスポンスを暴露する方法は？

これはアプリケーションの接着材ではなくインフラストラクチャです。マイクロエージェントはルーターに属すべきであり、その理由はルーターが既にすべての制御要素（モデルエイリアス、認証情報、コストメタデータなど）を所有しているためです。

7. 結論と展望

「フロンティアモデル」というフレーズは、今やチェックポイントとシステム境界の二つの意味を持ち始めています。vLLM セマンティックルーターはこの能力がサービング層においてプログラミング可能で、観測可能であるべきとの賭けに出ました。

次なるモデルレースにはより良いモデルが関与しますが、同時により良いルーターも関与します。

• お金を使わない時を知るルーター
• 安全性を強制する時を知るルーター
• エッジに残る時とクラウドへ行く時を知るルーター
• 一つのリクエストを小さな規律あるチームへと変換する時を知るルーター

それが、Model API 内部におけるマイクロエージェントの約束です。

---

本稿は MBZUAI、マギル大学、Mila、Agentic Intelligence Lab の研究者らによる研究協力に基づいています。AMD の GPU 評価サポートにも感謝します。