vLLM Semantic Router Fusion プリミティブがプログラム可能なマルチモデルサービングを実現

vLLM Semantic Router Fusion プリミティブがプログラム可能なマルチモデルサービングを実現

TL;DR

vLLM は Fusion プリミティブ を Semantic Router 用にリリースし、プロダクションシステムが異種モデルのパネルを協調的に実行し、出力を評価し、単一の応答に合成できるようにしました。ポリシー、設定、トレースはすべてルーター内部に保持されます。これにより、モデルミックスが臨時的な実験ではなく、第一級のプログラム可能なサービングパターンとなります。

単一モデルだけでは足りない理由

従来のサービングは 「どの単一モデルがリクエストを処理すべきか?」 という問いに答えるだけでした。現代の AI アプリケーションは、低コストで高速なモデル、プライベートなオンプレミスモデル、専門的な推論モデル、外部プロバイダー API など、ポートフォリオを必要とします。運用者は、リクエストが単一モデルで処理できるか、コスト・レイテンシ・プライバシー・安全性ポリシーを考慮した協調的なマルチモデルワークフローを起動すべきかを判断しなければなりません。

Fusion をルーターのプリミティブとして

Fusion は ルーティングアルゴリズム として導入され、グローバルエンドポイントではありません。ルーターのシグナル決定層で起動され、以下の明確なパイプラインに従います。

  1. シグナル抽出 – リクエストにドメイン、複雑度、安全性などのタグを付与。
  2. 意思決定 – ルーターはシグナルに基づき、通常ルートか Fusion ルートかを選択。
  3. Fusion エントリmodel: "vllm-sr/fusion" を指定すると、Fusion 対応の意思決定のみが対象になります。
  4. パネル実行分析モデル の集合が独立した候補回答を同時に生成。
  5. 評価ジャッジモデル がコンセンサス、矛盾、欠落、ユニークインサイトを評価。
  6. 合成 – ジャッジ(または別の合成モデル)が単一のユーザー向け応答を生成し、必要に応じて OpenAI 互換の tool_calls を出力。
  7. トレース – ルーターは実行したモデル、失敗、トークン使用量、構造化された分析結果を記録し、デバッグや課金に利用。

この設計は各ステージを明示的かつ観測可能に保ち、意思決定ごとのパネル構成、エラーハンドリング(on_error: skip vs. fail)、同時実行制限、ランタイムパラメータを柔軟に設定できるようにします。

エントリーパスとポリシー制御

エントリーパス 動作
model: "vllm-sr/auto" 完全なシグナル/意思決定ロジックを実行。選択された意思決定の algorithm.typefusion の場合にのみ Fusion が走ります。
model: "vllm-sr/fusion" シグナルは抽出されますが、Fusion 対応の意思決定のみが対象。該当が無い場合は明確なエラーが返ります。
リクエストプラグイン {"id": "fusion", ...} パネル、ジャッジ、ランタイムパラメータを単一リクエストで上書きし、マッチする意思決定が無くてもスコープされた Fusion 実行を構築します。

この分離により、運用者は Fusion をオプションかつコスト制御された機能として扱い、すべてのリクエストのデフォルトにすることはありません。

OpenRouter からのエビデンス

OpenRouter の最近の Fusion リリース(DRACO ベンチマーク)では、多様なモデルのパネルが最強単一モデルを上回ることが示されました。報告されたスコアは次の通りです。

構成 DRACO スコア
Fusion: Fable 5 + GPT‑5.5、Opus 4.8 によって合成 69.0%
Fusion: Opus 4.8 + GPT‑5.5 + Gemini 3.1 Pro、Opus 4.8 によって合成 68.3%
ソロ Claude Fable 5 65.3%
ソロ DeepSeek V4 Pro 60.3%

予算パネル行は、安価なモデルの組み合わせが単一の低価格モデルで失われた品質を回復できることを示しています。まさにルーターが管理すべきトレードオフです。

詳細な Fusion ワークフロー

  1. ポリシー解決 – 意思決定レベルの Fusion 設定とリクエストレベルの上書きをマージ。
  2. ルーター保護 – Fusion スラッグはパネルやジャッジモデルとして使用できず、再帰的な Fusion 呼び出しを防止。
  3. パネル実行 – すべての分析モデルが同時に呼び出され、max_concurrent を遵守。
  4. 失敗処理on_error: skip は残りのモデルで続行、on_error: fail は即座に中止。
  5. ジャッジ分析 – ジャッジはコンセンサス、矛盾、部分的カバレッジ、ユニークインサイト、盲点を記述した構造化 JSON を返す。
  6. 合成または tool‑call – 最終ステップでプレーンな回答または OpenAI 互換の tool_calls 応答を生成。
  7. トレース返却 – 応答ペイロードに完全な Fusion トレース、パネル出力の中間結果、失敗記録、集計トークン使用量を含められる。

トレースが明示的であるため、運用者はルーティング判断をデバッグし、コストを監視し、実際の不一致パターンに基づいてポリシーを改善できます。

Fusion はデフォルトではなく意思決定

Fusion はレイテンシとトークンコストを増加させるため、ルーターは いつ それが価値あるかを判断しなければなりません。vllm-sr/auto を使用すると、ルーターはシグナル(リクエストの複雑度、ドメイン、テナントポリシーなど)を評価し、高リスクまたは高価値クエリに対してのみ Fusion を選択します。シンプルなプロンプトは高速な単一モデルルートを継続して使用します。明示的な vllm-sr/fusion エイリアスにより、クライアントは追加の視点が必要と判断したときに Fusion を強制できます。

API 呼び出し例

ルーターに選択させる

{
  "model": "vllm-sr/auto",
  "messages": [{"role": "user", "content": "炭素税の賛成・反対の最も強い論点は何ですか?"}]
}

マッチした意思決定が algorithm.type: fusion を指定していれば Fusion パイプラインへ、そうでなければ選択された単一モデルで処理されます。

Fusion を強制する

{
  "model": "vllm-sr/fusion",
  "messages": [{"role": "user", "content": "炭素税の賛成・反対の最も強い論点は何ですか?"}]
}

Fusion 対応の意思決定のみが対象となり、マッチが無い場合は明確なエラーが返ります。

1 回だけパネルを上書き

{
  "model": "vllm-sr/fusion",
  "messages": [{"role": "user", "content": "..."}],
  "plugins": [{
    "id": "fusion",
    "model": "google/gemini-3-flash-preview",
    "analysis_models": [
      "google/gemini-3-flash-preview",
      "moonshotai/kimi-k2.6",
      "deepseek/deepseek-v4-pro"
    ]
  }]
}

この上書きは当該リクエストに限定され、グローバルなルーティング設定は変更されません。

エージェントループでの Fusion

Fusion は OpenAI 互換の tool calls と連携します。パネルモデルは会話履歴を受け取りますが toolstool_choice は見ません。最終ジャッジだけが tool_calls を出力できます。

{
  "model": "vllm-sr/fusion",
  "messages": [{"role": "user", "content": "最新のベンチマーク結果を取得し、我々のローンチ計画に影響があるか説明してください。"}],
  "tools": [{
    "type": "function",
    "function": {"name": "web_search", "parameters": {"type": "object", "properties": {"query": {"type": "string"}}, "required": ["query"]}}
  }],
  "tool_choice": "auto"
}

パネルは分析を行い、ジャッジが直接回答するか tool_calls ペイロードを返すかを決定します。

設定レイアウト

グローバルランタイム設定はエントリーエイリアスだけを登録します。

global:
  router:
    auto_model_names:
      - vllm-sr/auto
      - auto
      - MoM

Fusion スラッグは looper 統合の下に登録されます。

global:
  integrations:
    looper:
      fusion:
        model_names:
          - vllm-sr/fusion

意思決定ごとのルーティング設定に実際の Fusion ポリシーを保持します。

routing:
  decisions:
    - name: deep-research-fusion
      description: 高い合成リスクを伴うリサーチプロンプトにモデル多様性を使用。
      rules:
        operator: AND
        conditions:
          - type: domain
            name: research
          - type: complexity
            name: needs_reasoning:hard
      algorithm:
        type: fusion
        fusion:
          model: google/gemini-3-flash-preview
          analysis_models:
            - google/gemini-3-flash-preview
            - moonshotai/kimi-k2.6
            - deepseek/deepseek-v4-pro
          max_concurrent: 3
          on_error: skip

この分離により、グローバル状態は最小限に抑えつつ、ワークロード固有の細かい Fusion ポリシーを設定できます。

今後の方向性

OpenRouter の DRACO 結果は、vLLM‑SR 内で Fusion を体系的に評価する動機付けとなります。

  • 大規模な公開ベンチマーク(スモークテスト以上)
  • Fusion、ReMoM、AutoMix、Router‑R1、単一モデルベースラインの比較
  • 予算パネル vs. フロンティアモデルパネルの分析
  • 不一致、カバレッジギャップ、ジャッジ挙動のための高度なトレース診断
  • レイテンシ‑コストトレードオフに関するポリシー研究(いつ Fusion が正当化されるか)

最終的なビジョンは明快です。最高の回答は、プログラム可能なルーターによって編成されたモデル群 から得られるべきであり、最大の単一チェックポイントから得られるべきではありません。vLLM‑SR の Fusion プリミティブは、そのシステムを観測可能、設定可能、そして本番環境で利用可能にします。

参考文献


SUMMARY: vLLM は Semantic Router 用に Fusion プリミティブを導入し、プログラム可能なマルチモデルパネル、評価、合成を第一級のサービングパターンとして実現しました。

TITLE: vLLM Semantic Router Fusion プリミティブがプログラム可能なマルチモデルサービングを実現

Sources