vLLM、モデル混合時代のシステム構築を提唱

多くの AI アプリケーションは、単一のモデルエンドポイントを中心に構築されています。しかし、モデルやデバイス、デプロイの制約が多様化する中で、すべてのリクエストや環境に最適な単一モデルが存在するわけではありません。現実的な課題は、複数の専門化されたモデルをどのようにして一つのインターフェースを通じて調整し、評価し、提供するかという点です。私たちはこのシステムアプローチをMixture-of-Models（モデルの混合）と呼びます。

公開から 1 年足らずで、vLLM Semantic Router は、Hugging Face のモデルファミリー全体を通じて5,000 スター、150 人以上のコントリビューター、そして30 万回を超える累積ダウンロードを達成しました。主要な 3 つのリリースであるIris、Athena、Themisを経て、システムの境界は「モデルを選択する」段階から「マルチモデル推論を統制する」段階へ、さらに「セッション間で状態と調整を維持する」段階へと進化しました。これらのリリースが、ゼロ日目から構想されていた MoM アーキテクチャの基盤を築きました。

本記事では、vLLM Semantic Router の次のステップについて解説します。それはモデル間のルーティングから、それらを用いて信頼性の高いモデルシステムを構築することへの移行です。バージョン管理された一つの契約の下で、独立したモデル、ポリシー、優先順位、実行パスが統合され、一つのインターフェースを通じて学習、評価、エクスポート、インポート、デプロイ、そして呼び出しが可能になるシステムへと進化します。私たちの目標は、vLLM Semantic Router を Mixture-of-Models 専用のトレーニング、評価、推論エンジンにすることです。

vLLM-SR のこれまでの歩み

最初の vLLM セマンティック・ルーター記事では、シンプルなリクエストと複雑なリクエストに同じ推論予算を割く理由を問いました。軽量な分類器が固定されたドメインラベルを用いて、高速パスと推論パスの切り替えを行うことで、vLLM が推論計算資源をより選択的に使えるようにしました。

しかし、実際の運用トラフィックがこの設計の限界を浮き彫りにしました。ドメインという要素だけでは、プライバシー、安全性、文脈、言語、モダリティ、ツール、ユーザー設定、レイテンシ要件、権限など多様な要因を表現しきれないのです。また、固定されたラベルでは、安価だが過負荷状態にあるエンドポイントや、能力はあるが遠隔地にあるもの、あるいはエージェントセッションの途中で切り替えると危険なケースにも対応できませんでした。

そこで私たちは、モジュール型モデルサポート、共有 LoRA 計算、Rust/Candle による推論、Go 言語との統合を軸に分類器層を再構築しました。さらに、固定された分類方式から「シグナルと意思決定」アーキテクチャへと移行し、観測される証拠とポリシー、実行プロセスを明確に分離しました。これが次の 3 つのリリースを支える基盤となったのです。

図 2：制御の単位は各段階で変化しました。モデル、意思決定、システム、セッション、そして最終的にはモデルライフサイクル全体です。

Iris はルーティングを構成可能なものに変えました。ドメイン、キーワード、埋め込み、事実性、フィードバック、そして優先度のシグナルが明示的な意思決定に活用される一方、安全性、個人情報（PII）保護、キャッシュ、ハルシネーション検出、ツール選択は、ルーティングごとの挙動として実装されました。また Iris は MoM モデルファミリーを導入し、vLLM-SR を「混合モデルのためのシステムレベル知能」と定義しました。

Athena では、ファーストクラスのモデル選択機能、メモリ管理、RAG（検索拡張生成）、多言語・マルチモーダルなモデルスタック、ROCm による加速、そして運用ダッシュボードが追加されました。このプロジェクトは単に vLLM の前に置かれる分類器ではなく、複数モデル推論を統括する制御システムへと進化を遂げています。

Themis は、この広範なシステムを実行可能な契約として完成させました。

シグナルは投影となり、投影が意思決定を導き、意思決定がアルゴリズムを選択し、アルゴリズムがモデルを選定する。

Themis には、セッション認識型のエージェントルーティング機能、再生可能なトレース記録、強化されたプロトコルサポート、オペレーターコンソールが追加されました。さらに、AMD ROCm、NVIDIA CUDA、Intel OpenVINO、CPU 環境など多様なプラットフォーム間で実行パスを提供しています。また、各意思決定の根拠となる証拠、ポリシー、アルゴリズム、物理モデルをオペレーターが確認できる仕組みも実装し、ルーティングの透明性を確保しました。

シグナルと意思決定から、ワークロード・ルーター・プールへ

今回のリリースでランタイムが完成し、その背後にあるアーキテクチャは 2 つの論文によって解説されています。

「Mixture-of-Modality Models における信号駆動型意思決定ルーティング」(Signal Driven Decision Routing for Mixture-of-Modality Models) と題されたホワイトペーパーでは、ニューラルな証拠とシンボリックなポリシーの分離が明確に定義されました。高速なヒューリスティックや学習済み分類器が、プロンプト、コンテキスト、アイデンティティ、安全性、モダリティといった要素を構造化された信号ベクトルに変換します。その後、ブールエンジンがこれらの信号を組み合わせて監査可能なポリシーを生成します。型付けされたニューラル・シンボリック DSL（ドメイン固有言語）がこのポリシーを解析・検証し、デプロイ可能な設定へとコンパイルします。この論文が発表された時点では、13 種類の信号タイプと 13 のモデル選択アルゴリズムに対応しており、キャッシュ、RAG、メモリ、安全性、プロバイダー処理、レスポンス検証など、意思決定ごとのプラグインも用意されていました。

一方、「LLM インフェレンス最適化のためのワークロード・ルーター・プールアーキテクチャ」(The Workload–Router–Pool Architecture for LLM Inference Optimization) と題されたビジョンペーパーでは、議論の枠組みがさらに広げられました。ここでは、以下の 3 つの変数を一体的に設計する必要があると主張しています。

• ワークロード: チャットまたはエージェント、単一ターンまたはマルチターン、ウォーム状態またはコールド状態、プリフェッチ重視またはデコード重視

ルーターには、静的なセマンティックポリシー、オンラインフィードバックやバンディット適応に基づくRL（強化学習）による選択、品質を考慮したカスケード処理などが含まれます。

プールは、均質または異種アクセラレータ、プレフィル/デコードのトポロジ、モデル配置、KVキャッシュ管理などを指します。

これらの変数は独立して最適化することはできません。ワークロードの形状がどのルーティングポリシーを有効にするかを決定し、ルーティングポリシーが必要なプールの規模とトポロジを変化させます。また、プールの状態がどのルートが効率的かを決めます。安全性とプライバシーはこれら3つの次元すべてに横断する課題であり、コスト、品質、レイテンシ、エネルギー消費が最適化のフロンティアを定義します。

論文では、このプロジェクトの研究を 3×3 の WRP（Workload-Routing-Pool）行列として整理し、これらの次元がいまだに統合される必要がある21の未解決方向を特定しています。

図3：ホワイトペーパーはプログラマブルなルーティングエンジンを定義しており、ビジョンペーパーではそれがワークロードと物理的なプール設計にどのように結びつくかが示されています。

これら2つの論文によって、ルーティングがプログラム可能となり、ワークロードとハードウェアに結びつけられました。これはMoM（Mixture-of-Models）が1つのモデル契約の下で統合する2大基盤です。

一方、ランタイムはすでに単一のモデル選択の枠を超え始めていました。Fusion、ReMoM、Confidence、Ratings、そして制約付きワークフロー（bounded Workflows）により、一つのリクエストで複数のモデルが制御された形で協力する仕組みが可能になっています。Micro-Agent の取り組み が示したように、クライアント側では単に一つの名前を指定するだけで済みます。実際にはサービング層がそのリクエストに応じたレシピを選択し、ワーカーへ分散して処理を実行します。その後、結果の検証や合成を行い、最終的には通常のレスポンスとして返却されます。

ルーティングは依然として根幹です。Mixture-of-Models（MoM）がどのようにして作業を割り当て、ポリシーを適用し、各部分を調整するかを決めるのがルーティングだからです。しかし、ルーティングはあくまで仕組みに過ぎません。真の製品となるのは、モデルシステムそのものです。

モデルの境界線が変わらなければならない理由

現在の AI スタックは、4 つの軸に沿って分断されています。

• モデルが分断されている クローズドなフロンティアモデル、オープンな汎用モデル、ドメイン特化型エキスパート、軽量なローカルモデル、検証器、そしてマルチモーダルモデルなどが共存します。いずれも品質、コスト、レイテンシ、信頼性、プライバシー、ドメイン適合性のすべての面で同時に優位に立つことはできません。

• 計算リソースが分断されている GPU、CPU、専用アクセラレータ、エッジデバイス、クラウド容量、プライベートクラスターは、メモリ、カーネル、可用性、価格、エネルギー消費においてそれぞれ異なります。モデルの選択と配置は、もはや同じ判断課題となっています。

• 場所が分断されている 推論処理はクラウド、データセンター、エッジにまたがります。プライバシーやデータ所在地の要件により、より強力なリモートモデルの利用が制限される一方で、ローカルワークロードでもオンデマンドでクラウド上のエキスパートを必要とすることがあります。

• 優先順位が分断されている 普遍的な「最善解」は存在しません。製品やユーザーは、精度、レイテンシ、価格、プライバシー、安全性、スタイル、マルチモーダル性といった要素の間で異なるトレードオフを迫られます。これらの選択こそが、実行プロセスに直接反映されるべきです。

現在では、各アプリケーションが自らこれらの断片を統合する必要があります。

図4：MoM以前は、断片化された知能がアプリケーション側のルーティング接着剤として機能していた。

Mixture-of-Models（MoM）はこの責任を1つのモデル境界の背後に移動させる。この境界において、インテリジェントな割り当てがモデルの一部となる。エンジンがどのモデルが実行可能か、どこで実行できるか、モデル同士が協力すべきかどうか、そして厳しい制約をどう満たすかを決定する。

エネルギー効率を考慮すると、割り当てと効率性は切り離せない。ハードウェアや推論エンジンは、ワットあたり・ドルあたりのトークン生成数を向上させることで供給側を改善する。一方、割り当て層は需要を制御する：どの作業にそのトークンを割くべきか、また必要な品質、レイテンシ、エネルギー予算内でそれらを供給できるのはどのモデルか、あるいはどの協力体制か。

アプリケーションはバージョン付きのモデルIDを1つ選択し、帰属可能な応答を1つ受け取る。物理的な実装は依然としてオープンとクローズドなモデル、クラウドとエッジ、異なるアクセラレータ世代にまたがることがある。断片化は残るものの、それはアプリケーションごとに漏れ出すのではなく、モデルシステム内部の問題となる。

*図5：MoMでは、同じく断片化したリソースが1つのモデルの内部的な実装となる。

Mixture-of-Models が意味するもの

「モデルの混合（Mixture-of-Models）」とは、バージョン管理された複合モデルのことです。このエンジンは、独立したモデルや演算子を横断する、リソース制約のあるパスを、ユーザーの嗜好条件に基づいて選択することで、各リクエストを実現します。ユーザーには単一のモデルインターフェースとして提示され、帰属可能な結果が1 つ返されます。

複数の情報源からトラフィックを受け取るゲートウェイは、システム全体の品質を保証するものではありません。一方、Mixture-of-Models は、明確な目的を持ち、評価契約を定め、再現性のある構成を備え、それを実行するランタイム環境そのものを所有しています。

また、Mixture-of-Models は「エキスパートの混合（Mixture-of-Experts）」とも異なります。MoE は1 回の順伝播の中でトークンを内部のエキスパート間でルーティングしますが、MoM はアーキテクチャ、所有者、ライセンス、モダリティ、プロトコル、コンテキストウィンドウ、ハードウェアが異なる独立したモデルを調整・連携させます。なお、MoE のチェックポイント自体が、MoM の構成要素となることもあります。

したがって、ポータブルな MoM（モデルの混合物）を実現するには、単に重みと設定を備えていればよいわけではありません。コンポーネントのマニフェスト、機能メタデータ、ルーティングや協調のためのレシピ、ポリシー、優先順位、評価スイート、ランタイム制約、出所情報、バージョン履歴といった要素も不可欠です。

オープンなチェックポイントはアーティファクトと共に移動できますが、クローズドなモデルは、明確な機能とポリシー契約を持つ外部参照として認証されたまま維持されます。MoM をエクスポートしても、プロプライエタリなチェックポイントがそのままポータブルになるわけではありません。重要なのは、モデルシステム全体を再現可能にすることです。

優先順位をモデル化する

優先順位は、モデルのアイデンティティとして公開された時点で具体的な形を持ちます。一つの MoM ファミリーでは、複数の運用ポイントを提供可能です：

各名称は、バージョン管理されたモデル契約であり、ルーティングの事前設定ではありません。アプリケーションは必要な振る舞いを選択し、vLLM-SR がそれを実現するモデルを選定・調整します。その際、厳格なプライバシー、データ所在地、権限付与、安全性の制約も維持されます。

アプリケーションから見れば、この全体システムは通常のモデル呼び出しとして機能します：

{
  "model": "vllm-sr/mom-v1-ultra",
  "messages": [
    {"role": "user", "content": "Review this design and identify its weakest assumption."}
  ]
}

この識別子によって、単一のモデルが選択されることもあれば、カスケード処理でエスカレーションが行われたり、並列回答の比較が必要になったり、グラウンディング（根拠提示）を要求されたり、制約付きワークフローが実行されたりします。しかし、外部インターフェースやバージョン、レスポンス契約に変更はありません。

所有権を分けるための 4 つの平面があります：

デプロイでは、環境に存在するモデルやマシンに対して論理的な要件をマッピングする必要があります。この提案では、以下の 4 つのオブジェクトを用います。

• バンドルは、インターフェース、グラフ、ポリシー、動作バリアント、制約条件、そして不変の意味資産を固定します。

• バインディングは、モデルの意思決定における意味論を変更することなく、論理的なコンポーネントを利用可能なデプロイ先へマッピングします。

• 解決ロックは、構成要素となるリビジョン、ランタイム、イメージ、アクセラレータ、およびプロバイダーからの観測情報を凍結（固定）します。

• 実行記録は、各意思決定、呼び出し、制約チェック、コスト、結果を、それらを生成したバンドル、バインディング、ロックに紐付けて記録します。

この分離により、ポータビリティの誠実性が保たれます。同じ mom-v1-ultra を ROCm、CUDA、プライベートな CPU または NPU ノード、あるいはハイブリッド展開にバインドしても、不透明なプロバイダーから同一の出力が得られることを約束する必要はありません。代わりに、制御セマンティクスを維持し、置換可能性を明示し、サービングと評価に対して同じ解決済みシステムを提供します。

vLLM-SR を MoM エンジンとして

トレーニング、評価、推論は共通の契約を共有する必要があります。そうでなければ、研究、ベンチマーク、そして生産環境が異なるシステムへと分断されてしまいます。

重みだけでなく、割り当ての学習も

MoM（モデルの混合）のトレーニングでは、ルーターが所有する埋め込み表現、信号エンコーダー、選好モデル、安全モデル、およびセレクターを扱います。さらに、割り当てと協働の学習も行われます。具体的には、「どのパスがワークロードや予算に適合するか」「カスケード処理をいつ停止すべきか」「パネルによる評価や合成をどのように行うべきか」「エージェントセッションでいつモデルを切り替えるべきか」といった判断です。

構成要素が独立している場合もあれば、クローズドな環境にある場合もあるため、すべての構成要素を通じて勾配を計算する必要はありません。ポリシー、閾値、プール、プロンプト、契約、そしてトポロジーは、トレースと結果から最適化できます。

目指すべきは、品質、レイテンシ、コスト、安全性、プライバシー、信頼性、ローカリティ、エネルギー効率のすべての領域における最前線です。リプレイと結果は、ホットパスがポリシーを静かに書き換えることを防ぎながら、生産現場での経験をオフライントレーニングにフィードバックします。

MoM を単一のモデルとして評価する

評価はモデルのアイデンティティをエンドツーエンドでスコアリングする必要があります。バックエンドベンチマークは入力であって結果ではありません。バージョン管理されたスコアカードでは、ルーティングの後悔（regret）、協働による利益、回復力、セッションの継続性、極端な遅延（tail latency）、コスト、安全性、プライバシー、エネルギー効率を測定すべきです。また、プロバイダーの障害、デバイスの喪失、モデル間の不一致、ワークロードの変化、ユーザーの嗜好変化といったストレス要因もテストに含める必要があります。

各宣言された運用ポイントには個別のテストが必要です。flash は遅延と品質のフロンティアで評価し、light は品質の下限に対して、ultra は予算内で評価します。

科学的な検証は、「呼び出し数を増やすことがベンチマークを改善するか」という問いよりも厳格です。アクティブな計算リソースを同等に調整した上で、条件付きシステムが固定モデルよりも相補的な強みと故障モードをより効果的に活用できるかどうかを検証する必要があります。この制御がない場合、Mixture-of-Models（MoM）は巧妙なグラフ構造の背後で、単なる力任せのスケーリングを隠蔽してしまう可能性があります。評価では品質とともに呼び出し数、トークン数、コスト、遅延、エネルギー消費量を報告し、組み合わせが効果をもたらさないケースについても公表すべきです。

インフランス時のインテリジェンス実行

推論時には、エンジンが「1 つのモデルで十分か」を判断します。ローカルの専門モデルを選択したり、ウォームセッションを維持したり、信頼性のカスケードを通じてエスカレーションを行ったり、検索や検証を要求したり、Fusion パネルを実行したり、制限付きワークフローを実行したりする可能性があります。ランタイムが予算、トポロジ、フォールバック、トレース、レスポンス契約を管理し、アプリケーション側は通常のモデル呼び出しを行います。

動く一つのモデル

目指すのは、構築・エクスポート・インポート・バージョン管理・評価・デプロイ・呼び出しをすべて統合されたモデルとして扱える完全な MoM です。論理仕様は不変のバンドルにコンパイルされ、環境にバインドされて具体的なデプロイ先が解決されます。そして、サービス提供時にも評価時にも同じアイデンティティを維持します。

このアーティファクトは、開発者機、プライベートクラスター、クラウドフレート、エッジ環境など、物理的な実装が異なる場所を横断して実行されるべきです。専門家は、利用可能なローカルチェックポイントや管理されたエンドポイントに解決策を定めたり、アクセラレータランタイムを置き換えたりできます。プライバシーの制約によりリモート専門家へのアクセスが不可能な場合、エンジンは宣言されたフォールバック経路または中止パスに従います。

バインディングは、グラフを黙って書き換えることも、ガードを緩和することも、パネルをカスケードに変えることもできません。これらの変更には、新しいモデルバージョンが必要です。

「あらゆるハードウェアで実行可能」というのは、すべてのコンポーネントが今日すぐに移植可能であるという主張ではなく、アーキテクチャ上の要件です。同プロジェクトはすでに ROCm、CUDA、OpenVINO、CPU を横断するパスをサポートしています。次期では、ハードウェアの能力と配置が MoM（Mixture-of-Models）契約の一部となり、エンジンが利用可能なリソースに対してモデルシステムをマッピングできるようになります。

ユーザーエクスペリエンスにおける基準はシンプルです：

一つのモデルID。複数のモデル。あらゆるハードウェア。

もしアプリケーションが、各サブモデルをどのプロバイダーが所有しているか、どのデバイスで実行されているか、あるいはどのフォールバックグラフを実行すべきかを知らなければならない場合、その抽象化は漏れています。

今、何が変わるか

次の段階では、4 つの相互に関連する領域に焦点を当てます：

ポータブルな MoM（Mixture-of-Models）の仕様を定義する。コンポーネント、目的、ポリシー、優先度、評価基準、制約条件、実行セマンティクスを、バージョン管理された単一のアーティファクトとしてパッケージ化する。

トレーニング・評価・推論のループを閉じる。評価結果やリプレイデータからモデルとレシピを改善し、レビュー可能でロールバック安全なリリースを通じて提供できるようにする。

異種ランタイムを構築する。ハードウェア、ローカリティ、エネルギー、データの境界を入力として活用し、クラウド、データセンター、エッジのいずれにおいても単一の MoM をマッピングする。

モデルインターフェースは「地味」に保つ。MoM は、単一モデルと同様に簡単にインポート・デプロイ・呼び出せるように設計する。

これは、独立したモデルがどのように専門化し、競い合い、検証し、協力すべきかという研究プログラムです。また、生成されたシステムをどう測定するか、そして一つのモデル契約がデバイスや環境を超えてどう生き残るかも含みます。私たちのミッションは以下の通りです。

モデル、デバイス、環境全体で知性の科学を推進する。

私たちは、単一のチェックポイントを超える能力を生み出す組み合わせの条件を研究し、配置とエネルギーを「知性」の一部として捉え、エッジからクラウドへ、そして研究から実装へと一貫したモデル契約を引き継いでいきます。

Build It With Us

Mixture-of-Models（MoM）の実現には、単にリダイレクトするだけでは不十分です。モデルのトレーニングから評価、サービングシステム、ハードウェア、そして生産環境での運用まで、広範な領域をカバーする必要があります。

Iris、Athena、Themis が改善されたのは、貢献者が実世界のワークロードを持ち込み、バックエンドを追加し、モデルを訓練し、ベンチマークを発表し、失敗事例を発見し、より良いインターフェースを主張したからです。MoM も同様に、学習による割り当て、選好最適化、モデル間の協力、エネルギー効率を意識した推論、移植可能な成果物、オープンな評価、そして異種ランタイムといった多様な取り組みが必要です。

これらの課題に取り組んでいる方々には、ぜひワークロードや測定結果を共有していただきたいです。運用上のポイント（Operating Point）の構築、ランタイムの実装、協力手法のテスト、あるいは組み合わせが失敗するケースの公開など、どのような形でも構いません。MoM の前提条件がオープンな場で検証されることで、その強固さはさらに高まります。

謝辞

vLLM-SR は、エンジニアリング、研究、そして広範なエコシステム全体での取り組みを通じて発展してきました。技術的・研究的な方向性の策定に貢献してくれた Xunzhuo Liu 氏、Huamin Chen 氏、Bowei He 氏、Yankai Chen 氏、Fuyuan Lyu 氏、Steve 氏に感謝します。また、ROCm の対応、ルーターモデルのトレーニング、オープンな MoM（Mixture-of-Models）の実験に取り組んだ Andy Luo 氏と Haichen Zhang 氏にも謝意を表します。

本プロジェクトは、FAUST をはじめ、David Shrader、Yang Wu、Ramakrishnan Sathyavageeswaran、Kuntai Wu、Aayush Saini、siloteemu、Chen Wang、Yue Zhu、Senan Zedan、Yossi Ovadia、Samzong Lu、Liav Weiss、Asaad Balum、Yehudit、Noa Limoy、Marina Koushnir、Jared Wen、Abdallah Samara、Hen Schwartz、Srinivas A、Yang Zhu、Jintao Zhang、yuluo-yx、cryo、Bishen Yu、Zhijie Wang、Hao Wu といった多くの貢献者によって支えられています。

Qiping Pan 氏。コード、レビュー、テスト、ドキュメント作成、そしてプロジェクトの維持管理により、彼らはこのプロジェクトを次のリリースへと導きました。

このマイルストーンにおいて、プロジェクトは1,734 コミットと150 人以上の貢献者を誇ります。MBZUAI、マギル大学、Mila、ライス大学の協力者をはじめ、vLLM、AMD、Intel、Meta、Red Hat、Microsoft、Google、IBM、NVIDIA、Hugging Face、NASA、Nutanix、DaoCloud、そしてオープンソースコミュニティのみなさまに感謝いたします。このマイルストーンは、初期のルーターを実用的なシステムへと変えたすべての人々に捧げられるものです。

GitHub で参加し、ドキュメント を探索し、MoM モデルファミリー をお試しください。また、vLLM Slack の #semantic-router チャンネルでコミュニティのみなさんと交流してください。

vLLM Semantic Router は、各リクエストに対してインフラが適切なモデルを選択する支援から始まりました。

現在、私たちはこの基盤を単一のモデルを超えて拡張し、デバイスや環境を跨いで複数のモデルを調整・評価・運用できるシステムへと進化させています。

私たちは、コミュニティに対してこのアプローチをオープンに構築・検証するよう呼びかけます。