Model Routing
マルチモデルシステムにおいて、精度、コスト、レイテンシ、リソース使用量のバランスを最適化するために、モデルルーティングが各リクエストに対して適切なAIモデルを選択する仕組みを学びます。
モデルルーティングとは、どのAIモデルが各受信リクエストを処理すべきかを選択するプロセスです。すべての入力を1つのモデルに送信する代わりに、ルーティングレイヤーは、要求されたタスク、入力タイプ、複雑さ、レイテンシ目標、コスト制限、ハードウェアの可用性、信頼度要件などのシグナルを評価します。その後、リクエストを最も適した候補に転送します。この文脈において、「ルーター」とは物理的なネットワークルーターではなく、推論の決定コンポーネントです。ルーティングは、マルチモデルの機械学習システムが予測品質、リソース使用量、および推論レイテンシのバランスを取るのに役立ちます。
モデルルーティングの仕組み#
ルーティングシステムには通常、デプロイされたモデルのプール、決定ロジック、および共通のアプリケーションインターフェースが含まれます。アプリケーションが1つのリクエストを送信すると、ルーターが適格なモデルを選択し、モデルサービングレイヤーがそのモデルの出力を返します。
ルーティングの決定方法は以下の通りです。
- ルールベース: マスクを要求する画像をセグメンテーションモデルにルーティングするなど、明示的なメタデータを使用してモデルを選択します。
- スコアベース: 各候補の期待される品質、コスト、または応答時間を推定し、最もスコアの高いオプションを選択します。
- 学習ベース: 軽量な分類器またはルーティングモデルを使用して、どの候補が入力に最も一致するかを推論します。
- カスケードベース: 高速なモデルを最初に実行し、不確実な結果やリスクの高い結果をより性能の高いモデルにエスカレーションします。
たとえば、Amazon Bedrockのインテリジェントプロンプトルーティングは、言語モデルを選択する前に応答の品質を予測し、一方Microsoftのモデルルーティング戦略ガイダンスではコスト、品質、およびバランスの取れたルーティングについて説明しています。同様の原則がコンピュータビジョンにも適用され、リクエストはタスク、カメラの場所、画像の解像度、または必要な予測の詳細度によってルーティングできます。
関連概念と主な違い#
モデルルーティングは他のマルチモデル技術密接に関連していますが、これらの用語は互換性のあるものではありません。
- AIゲートウェイ: AIゲートウェイは、認証、クォータ、ロギング、およびトラフィック管理のためのより広い制御レイヤーを提供します。モデルの選択は、ゲートウェイの機能の1つである場合があります。Kubernetes Gateway API Inference Extensionでも、モデルを認識したルーティングがエンドポイントの選択や負荷分散と区別されています。
- モデルアンサンブル: アンサンブルは通常、複数のモデルを実行してその予測を組み合わせます。ルーターは通常1つのモデルを選択し、計算量を削減します。代わりに、NVIDIA Tritonのアンサンブルモデルでは、複数のモデルを通る固定されたデータフローが定義されます。
- Mixture of Experts: MoEアーキテクチャは、内部表現を1つのニューラルネットワーク内のコンポーネントにルーティングします。モデルルーティングでは、個別にデプロイ可能なモデルまたはエンドポイントの中から選択が行われます。
- エージェントルーティング: エージェントルーターは、特化したエージェント、ワークフロー、またはツールを選択します。モデルルーティングは、推論ステップを実行する基礎となるモデルを選択します。エージェントシステムでは、両方の形式のルーティングが存在する場合があります。
ロードバランシングは、もう1つの重要な区別点です。可用性やスループットを向上させるために、同じサービスのレプリカ間でリクエストを分散させます。モデルルーティングでは、異なる機能、コスト、または出力を持つモデル間で選択が行われます。
実世界での利用例#
視覚検査: 製造システムでは、通常の部品カウントに物体検出を使用する一方で、正確な境界を特定するために疑わしい表面欠陥をインスタンスセグメンテーションにルーティングする場合があります。Ultralytics YOLO26は物体検出とインスタンスセグメンテーションの両方をサポートしており、一貫したAPI内でタスクベースのルーティングを可能にします。これにより、バウンディングボックスで十分な場合にセグメンテーションのコストを支払うのを避けることができます。
AIアシスタント: サポートアシスタントは、単純な分類およびルックアップのリクエストを小さく高速な言語モデルに送信しつつ、複雑な推論やツールの使用のために強力なモデルを予約することができます。Google Cloudのエージェントアーキテクチャガイダンスでは、このパターンを品質、レイテンシ、コストのバランスを取る方法として説明しています。固定されたカスケードとは異なり、動的ルーティングでは、最初の回答を生成する前に強力なモデルを選択できます。
ルーターの実装と評価#
この最小限のUltralyticsの例では、アプリケーションによって要求された出力に応じて、画像が検出またはセグメンテーションにルーティングされます。
from ultralytics import YOLO
models = {
"detect": YOLO("yolo26n.pt"),
"segment": YOLO("yolo26n-seg.pt"),
}
requested_task = "segment"
source = "https://ultralytics.com/images/bus.jpg"
model = models.get(requested_task)
if model is None:
raise ValueError(f"Unsupported task: {requested_task}")
results = model(source)
result = results[0]
result.save(filename=f"{requested_task}_result.jpg")このルールは意図的にシンプルにされています。オブジェクトマスクを必要とするリクエストはセグメンテーションに送られ、バウンディングボックスのみを必要とするリクエストは検出を使用できます。本番環境のルーターでは、測定された精度、キューの深さ、デバイスの種類、プライバシーの制約、またはサービスのヘルスも考慮に入れることができます。
モデルの平均値だけではなく、代表的なトラフィックに基づいてルーティングを評価してください。選択された各モデルについて、ルートの分布、エンドツーエンドのレイテンシ、コスト、障害、およびタスクレベルの品質を追跡します。OpenTelemetryのオブザーバビリティガイダンスでは、分散サービス全体でトレース、メトリクス、およびログが個々のリクエストをどのように追跡できるかを説明しています。Ultralytics Platformのデプロイメントモニタリングでも同様に、エンドポイントのレイテンシ、エラー、ヘルス、およびリクエストアクティビティの検査がサポートされています。
ルーティングの誤りは、コストの増加、レイテンシ目標の未達成、または困難な入力を不十分なモデルへ送信することにつながる可能性があります。したがって、チームはフォールバック動作を定義し、機密性の高いワークロードに対する適格なモデルを制限し、選択されたルートをログに記録し、定期的にポリシーを再テストする必要があります。これらの制御により、ルーティングの決定がNIST AI Risk Management Frameworkのより広範なプラクティスと整合するようになります。
