「このリクエストはどのモデルに投げるべきか」。LLMルーティングの議論はずっとこの問いを中心に回ってきた。安いモデルで足りるか、それとも高いモデルにエスカレーションするか。要は1リクエストにつき1モデルを選ぶ、という前提だった。
vLLMプロジェクトが6月16日に公開した Fusion は、その前提を外しにきている。1つ選ぶのではなく、複数のモデルに同じリクエストを同時に答えさせ、別のモデルがそれらを突き合わせて1つの回答に束ねる。発想自体は研究界隈で言うMixture-of-Agentsに近いが、これを推論サーバの「ルーター」の機能として、設定ファイル数行で本番運用に乗せられる形にしたのが今回の肝だ。
🔀 そもそもvLLM Semantic Routerとは何か
Fusionの前提として、土台になっている vLLM Semantic Router(以下SR)を押さえておきたい。これはOpenAI互換APIの手前に置く「賢いルーター」で、リクエストの中身を見てどのモデルに流すかを決める。READMEの言葉を借りれば、クラウドからエッジまでの複数モデル(mixture-of-models)を束ねる System Level Intelligent Router だ。
6月5日の v0.3 Themis でルーティングの考え方が整理された。リクエストから言語・意図・安全性・文脈長といった「シグナル」を抽出し、それを support_fast のような扱いやすい概念に正規化し、ポリシーで条件判定して、最終的にアルゴリズムがモデルを選ぶ。シグナル→投影→判定→アルゴリズム→モデル、という一本道だ。実装はGoが約半分でPythonとRust、TypeScriptが続く多言語構成になっている。
ここで重要なのは、Fusionはこの「アルゴリズム」の一種として差し込まれている点だ。つまり既存のルーティング基盤に対する追加機能であって、別物の新システムではない。
パネルと審判という構造
Fusionの処理は4段に分かれる。
- パネル実行: 複数の解析モデルが同じリクエストを並行して処理する
- 審判(judge): 専用のjudgeモデルがパネルの出力を読み、合意点・矛盾・抜けを分析する
- 合成(synthesis): 最終回答を生成する。エージェント用途ならツール呼び出しもここで起きる
- トレース: どのモデルが参加し、どこで失敗し、トークンをいくつ使ったかを丸ごと記録する
設定はアルゴリズムの定義としてこう書く。
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
analysis_models がパネル、model が審判兼合成役だ。on_error: skip でパネルの1つが落ちても残りで続行する、という運用上ありがたい設定が最初から入っている。呼び出し側は、リクエストの model フィールドを切り替えるだけで挙動を選べる。
{ "model": "vllm-sr/auto" } // ルーターがシグナルを見てFusion適用を判断
{ "model": "vllm-sr/fusion" } // 明示的にFusionだけを使う
加えてリクエスト単位で plugins にFusion設定を差し込み、パネル構成をその場で上書きすることもできる。サーバ側のデフォルトと、特定リクエストだけ厚くする、という使い分けができるわけだ。
どれだけ嬉しくて、どれだけ高くつくか
効果としてポストが挙げているのは、OpenRouterのDRACOベンチでFusion構成が69.0%、単体最強だったClaude Fable 5が65.3%だった、という数字だ。これはポストが引用している値で、私の手元で再現したものではない。とはいえ複数モデルを合議させれば単体の取りこぼしを拾える、という方向性自体は妥当に見える。
冷静に見るべきはコストだ。3モデルのパネルに審判が1回。素朴に考えれば1リクエストあたりのトークン消費は単体の4倍前後に膨らむ。レイテンシも、並行実行とはいえ「最も遅いパネルメンバー+審判の生成時間」が下限になる。つまりFusionは全リクエストに常時かけるものではない。vllm-sr/auto でシグナルを見て、難しい問い合わせのときだけパネルを開く、という選択的な使い方が現実的だろう。SRがこれをアルゴリズムの一種として組み込み、auto ルーティングと同居させた設計はこの点で理にかなっている。
| 従来のルーティング | Fusion | |
|---|---|---|
| 1リクエストの担当 | 1モデル | パネル複数+審判 |
| 主な狙い | コスト最適化 | 難問の品質底上げ |
| トークン/レイテンシ | 単体相当 | おおむね数倍 |
| 適用範囲 | 全リクエスト可 | 選択的に開くのが現実的 |
もう一つ実務的に効くのが4段目のトレースだ。どのモデルが何を言い、審判がどう判断したかが残る。合議の中身がブラックボックスだと障害解析も品質改善も難しいので、Themisの「再生(replay)」可能なルーティングと組み合わさると、後から「なぜこの回答になったか」を追えるのは大きい。
試すなら
導入はインストールスクリプトが用意されている。
curl -fsSL https://vllm-semantic-router.com/install.sh | bash
起動や対話、評価は vllm-sr serve / vllm-sr chat / vllm-sr eval といったCLIで回す。v0.3以降の設定は version: v0.3 を持つ単一フォーマットに統一されたので、まずThemisの設定構造を読んでから、アルゴリズムに fusion を足すのが入りやすい。
単一モデルのコスト最適化に閉じていたLLMルーティングが、「重要な問い合わせは合議させる」という品質側のレバーを得た。1つのモデルを選び切る前提を捨てたこの一手が、本番のルーティング設計をどう変えるかは見ておきたい。