AI エージェントの構築は、単一のモデルを選べばそれで終わり、というわけではありません。 各モデルには、独自の長所、短所、コスト プロファイルがあり、それらはワークロードごとに、さらには同じワークロードの中でも変化します。たとえば、エージェントがあるタスクを処理するとき、あるステップでは分類 (Classification) が必要になり、次のステップでは推論 (Reasoning) が必要になり、その後の定型的な処理にはより小規模なモデルで十分、ということがあります。すべてのリクエストを最大規模のモデルに送信するとコストと遅延が増加する恐れがあり、すべてのリクエストをより小規模なモデルに送信すると、複雑なタスクの品質を低下させる恐れがあります。
モデル ルーティングは、特化型モデルやフロンティア モデルをオーケストレーションし、各タスクに最適なモデルが使用されるようにすることで、この課題に対処します。NVIDIA NeMo Switchyard は、この複雑なエンジニアリング問題をエージェント ワークロード向けに実用化することで、開発者は、選択したプロバイダーやモデルのそれぞれにアプリケーションを再構築することなく、複数のモデルに作業をルーティングできます。
実行時には、ルーターが各リクエストと利用可能なコンテキストを評価し、タスクの要件、制約、ポリシーに最適なモデルへ処理を送ります。ワークロードによって、この System of Models (複数モデルからなるシステム) を採用することで、全てのリクエストを常に最も高性能なモデルで処理する場合と比べて、精度を向上させながらコストを削減できる可能性があります。
NeMo Switchyard は、複数のルーティング アプローチを適用するためのライブラリを提供します。 このブログでは、NeMo Switchyard を使って、System-of-Models のアプローチをどのように実現し、実際のAI ワークフローにより適した、効率的で制御しやすい AI エージェントを構築できるのかを解説します。
モデル ルーターの意思決定方法
あるシステムで、複数のモデルにコンピューター操作タスクを実行させ、その性能を Terminal-Bench Hard ベンチマークで評価する場合を考えてみましょう (図 1)。この例では、DeepSeek V4 が全体的な精度が最も高くなっていますが、あらゆるタスク グループに最適なモデルというわけではありません。 たとえば、Kimi K2.6 は、ML および RL のタスク グループに適しています。一方、Qwen3.5 397B A17B は、数学および科学に適しています。 残り 6 つのタスク グループは、DeepSeek V4 を使用する必要があります。 このアプローチは、個々のタスク レベルでも、単一タスクを解決するフェーズ全体でも適用できます。
図 2 に示すように、コストと完了までの時間は意思決定をさらに複雑化します。各モデルには、その実行やアクセスに伴うコストと、トークンだけでなくツール呼び出しにも関連する独自の詳細度 (Verbosity) プロファイルがあります。
ルーターを構築するには、さまざまなソースからの信号を考慮する必要があります。 各ルーティング アルゴリズムは、それらのシグナルをどこから導き出すかを決定するのに役立ちます。
大まかに言えば、効果的なルーティングの意思決定は、3 つの分野からのシグナルに依存します。
- モデル機能: どのモデルがタスクを正しく解決できるか。
- モデル コスト プロファイル: 各モデルに伴う遅延とコスト。
- インフラストラクチャ: 信頼性の高いシームレスなハンドオフを可能にするシステムレベルのシグナル。
能力とコストのシグナルを理解するには:
- リクエスト自体をご覧ください。 ルーターは、分類結果を利用して、トピックや推定される難易度に基づいてリクエストを適切なモデルに振り分けることができます。たとえば、分類器でクエリのトピックを特定し、それに適したモデルをモデルプールから選び、クエリをルーティングできます。埋め込みモデルや特徴量生成モデルを使用することで、クエリから特徴を抽出することができます。
- モデルの状態をご覧ください。 ルーターは、モデルの logprobs、カスケード、エージェント型トレースの評価、モデルの残留ストリーム、アテンション マトリクス、レバレッジなどを検証できます。
- システムの詳細をご覧ください。料金、遅延、負荷、エラーを含むエージェント固有のシグナルも利用できます。 これらのシグナルは、モデル ルーターの評価に利用できるだけでなく、リアルタイムのルーティング判断にも利用できます。
重要なのは、ルーターは「どの」シグナルを使用するかだけでなく、それらを「いつ」、「どこで」評価するかも考慮する必要があるということです。たとえば、マルチターンのエージェント タスクの場合、ルーターは各ステップで、リクエスト全体を特定のモデルにルーティングすることも、特定のルートにルーティングすることもあります。システム全体でプールを共有する場合もあれば、サブエージェントがタスクに合わせて特定のモデル プールを使用する場合もあります。
これらの質問への回答は、ユース ケース、デプロイの複雑さ、エラー トレランス、遅延、スループットの制約など、いくつかの要因によって異なります。 システムには、エージェント/ユーザーへのシームレスで目に見えないハンドオフを実現するためのインフラストラクチャも必要です。
NeMo Switchyard は、複数のルーターをサポートするインテリジェント オーケストレーション レイヤーにより、これらの課題を解決します。 開発者は、独自のルーティング アルゴリズムやカスタマイズデータを NeMo Switchyard に持ち込むこともできます。
NeMo Switchyard がルーティングを可能にする仕組み
ルーティング アルゴリズムは、強みの異なるモデル間でルーティングの決定を通知するシグナルを生成します。 システムには、ルーターの回答を受け取り、選択したモデルにリクエストを送信し、その応答をアプリケーションに持ち帰ることができるインフラストラクチャも必要です。
これは、NeMo Switchyard を支えるプロバイダー非依存の SDK である NeMo switchyard-libsy から始まります。これは、リクエストを表し、システムが利用可能なモデルを定義し、選択したモデルへの呼び出しを管理します。各モデル ターゲットにはセマンティックな名前があり、その背後にあるクライアントは、その名前をプロバイダー エンドポイントとモデル ID にマッピングします。 この分離により、ルーティング ロジックが特定のプロバイダーに依存しない状態を維持できます。
NeMo Switchyard は、ポリシーによって必要とされる場合、エージェントのセッション全体でルーティング ステートを伝送できます。 また、ツールの結果やアフィニティの判断など、以前のターンからの情報を保持し、そのコンテキストを後のルーティングの判断に利用することもできます。履歴が必要ない場合、ルートはステートレスのままになります。
モデルのデプロイは変化するため、この分離は重要です。 チームは、ルーティング統合を変更することなく、モデルを更新、別のエンドポイントに移行したり、異なるプロバイダーを使用したりする場合があります。 NeMo Switchyard は、ターゲット クライアントを通じてモデル コールを発信するか、ホスト アプリケーションにそのコールを返却できます。 これにより、エージェントのランタイム、推論プラットフォーム、またはゲートウェイが、同じルーティング コントラクトを維持しながら、リクエストの処理方法を制御できるようになります。
NeMo Switchyard サーバーは、LLM ゲートウェイをシミュレーションする共通の API を介してルーティング機能を提供するリファレンスです。OpenAI、Anthropic、Responses API のリクエストを受け付け、NeMo Switchyard の内部リクエスト フォーマットに変換し、想定されるレスポンス フォーマットを返します。また、選択されたモデル、意思決定の根拠、トークンの使用状況、遅延、呼び出しの結果も記録されるため、チームは実行中のルートを検査できます。
NeMo Switchyard のルーティング アルゴリズム
インフラストラクチャを導入した上で、次のステップは、インフラストラクチャを活用して意思決定を行うルーティング アプローチを検討することです。 NeMo Switchyard は、チューニング不要ルーターとチューニング可能なルーターの両方を提供しています。
チューニング不要のルーター
NeMo Switchyard には、LLM 分類器、ステージ ルーター、エスカレーション ルーターなど、ワークロード固有のデータに基づいてトレーニングすることなく意思決定を行うチューニング不要のルーターがいくつか用意されています。
LLM 分類器
LLM 分類器は、LLM を審査役として候補となる LLM を選択し、その後のターンでもそのモデルとのセッション アフィニティを維持します。これにより、エージェントがタスクを解決する過程を通じて、実質的な変化を伴わない作業を繰り返し再分類することを回避できます。
このアプローチは、ヘッドレス システムやドメイン固有システムに適しています。 チームは、コーディング、数学、またはヘルスケア業務タスクを選択したモデル ターゲットにルーティングでき、NeMo Switchyard はルーティングと状態管理の部分を提供します。
ステージ ルーター
コーディング エージェントは、さまざまなステージを経ます。 初期段階では、コードベースを探索し、エラーから回復します。 後で、より機械的な実装に移行します。 これらのステージには異なるレベルのモデル機能が必要であり、ステージ ルーターはそれを利用してルーティングの意思決定を行います。
各ターンごとに、ステージ ルーターは最近のツール アクティビティを調べ、エージェントにどの程度のモデル機能が必要かを判断します。 深刻なエラー、非生産的な作業の繰り返し、または長引く探索は、高性能なモデルへとターンを移行させます。着実な書き込みや編集、特にテストに合格した後は、効率的なモデルが適しています。シグナルが決定的でない場合、ルーターは、設定されたデフォルトに戻る前に、LLM ジャッジに照会することができます。
エスカレーション ルーター
エスカレーション ルーティングは、低コストのモデルで各会話を開始します。 LLM ジャッジがタスクの進捗をターンごとに監視し、継続的な困難を検出すると、セッションをより能力の高いモデルに移行させます。
このアプローチは、小規模なモデルで日常業務を処理できるものの、エラー、ループ、またはドリフトが繰り返された場合にはサポートが必要になるかもしれないマルチターン型のエージェント ワークロード向けに設計されており、LLM 分類器のルーティング アプローチを静的から適応型へと拡張します。
チューン可能なルーター
チューン可能なルーターは、このルーティング基盤を基盤に、固定されたヒューリスティックスを実世界のワークロード データから学習したシグナルに置き換えます。リクエスト テキストに基づいてどのモデルが最も適切かを判断するのではなく、チューン可能なルーターは、各候補モデルがリクエストに正しく答える可能性を予測することを学習できます。
プリフィル ルーター
トレーニング中、プリフィル ルーターが LLM の残留ストリームを抽出して、クエリの複雑度を推定します。共有トランク MLP は、残留ストリームからのシグナルを使用し、ルーティング プール内の各 LLM の精度ラベルにそれらをマッピングします。
推論時には、プリフィル状態がルーターへの入力として機能し、共有トランクが各 LLM がタスクを正常に完了するか、クエリに回答する可能性を予測します。
これにより、ルーターは、予測精度とコスト、遅延、またはその他のデプロイの制約をブレンドしたポリシーを適用できます。 各候補モデルにスコアが与えられ、そのリクエストは、そのワークロードに最適なトレードオフを考慮したモデルにルーティングされます。 図 5 は、ルーティングは単に最強のモデルを選択することではないことを示しています。 これは、適切なコストで必要な品質レベルを満たす可能性が最も高いモデルを選択することです。
NeMo Switchyard によるエージェント効率の向上
NVIDIA は、エージェント、モデル、エンタープライズ アプリケーション エコシステム全体にわたるパートナーと協力して、別途セットアップすることなく、NeMo Switchyard モデル ルーティングを既存の開発者ワークフローに組み込むことを目指しています。 これらのコラボレーションは以下を含みます。
- エージェント ワークフロー: Cognition によるコーディング エージェント ワークフロー、Nous Research による構成が容易な Hermes エージェント モデル ルーティング、Ramp による金融ソフトウェア エンジニアリング ワークフロー、LangChain によるモデル ルーティング評価。
- アプリケーションとインフラストラクチャの統合: LiteLLM を使用したプラグインとしての LLM アプリケーション スタック、Kong を使用した AI ゲートウェイ、ガバナンス、および API トラフィック管理、Classmethod を使用した Claude モデル ルーティング、Boomi Agent Garden を使用したエンタープライズ オートメーションと接続。
- 業界固有 AI エージェント: ChipStack AI Super Agent における Cadence との形式検証ワークフロー、および Siemens との EDA エージェント ワークフロー。
LangChain は、社内のディープ エージェント評価スイートを使用して NeMo Switchyard をベンチマークしました。このスイートには、ポリシー制約下での顧客サポートの対話、オンコール インシデント調査、メッセージング、問題追跡、メール全体にわたるマルチステップのワークフローの自動化など、量産段階のワークロードを反映した 145 のマルチターン エージェント タスクが含まれています。このスイートは、T²-bench 航空会社、Berkeley Function Calling Leaderboard、FRAMES、Nexus から得られたシナリオを使用して、ツールの使用、マルチステップ検索、ファイル システム操作、長コンテキストの要約を評価します。 5 回の実行において、エスカレーション ルーターを使用して NVIDIA Nemotron 3.5 Lightning と Claude Opus 4.8 の間でリクエストをルーティングしたところ、フロンティアのみのベースラインと比較して 74% のコスト削減を実現しました。この際、フロンティア モデルへの呼び出しはわずか 7% に抑えられ、測定値の精度の低下は約 6 ポイントに留まりました。
Cognition は、Devin Desktop に NeMo Switchyard の段階的ルーティング手法を実装し、実世界のテストのために NVIDIA 内部ユーザーにデプロイしました。 本番環境レベルのコーディング タスク向けの Cognition のベンチマークである FrontierCode Main では、Opus 5 と Kimi K2.7 の間で実装をルーティングしました。 このシステムは、フロンティアに近いパフォーマンスを実現し、平均コスト 3.11 ドルで 50.6% の精度を達成しました。これは、Opus 5 の精度から 2.8 パーセントポイント以内の差でありながら、平均コストは約 28% 低く抑えられています。このベンチマークと内部デプロイは、モデルニュートラルエージェントと適応型エージェントの実践的なケーススタディを提供し、タスクの進化に合わせてさまざまなモデルの補完的な強みを動的に応用できる方法を示します。
開発者は、NeMo Switchyard を使い慣れたエージェント ツール、フレームワーク、ゲートウェイに導入するパートナーとの統合から始めることができます。また、NeMo Switchyard の GitHub 手順を使用して、自社エージェントや LLM ゲートウェイにカスタム ルーティングを構築できます。
オーケストレーションは今後も不可欠
モデル ルーティングにより、特化型モデルとフロンティア モデルを組み合わせて連携させ、それぞれを単独で利用する以上の成果を引き出すことができます。しかし、実用的で本番環境に対応できるルーティング システムの構築は、依然として非常に難しいエンジニアリング上の課題です。
NeMo Switchyard は完全にオープン ソースであり、すでに使用しているテクノロジと統合できます。 GitHub 上の NeMo Switchyardを使い始めることができ、特定のユース ケースに合わせたルーティング アルゴリズムの作成、テスト、コントリビューションが可能です。
AI システムでで複数のモデルを組み合わせることがますます一般的になる中、効率、品質、コストのバランスを取りながら、タスクごとに最適なモデルを選択するために、ルーティングは不可欠です。
NVIDIA ニュースの購読や、LinkedIn、X、Discord、YouTube で NVIDIA AI をフォローすることで、NVIDIA AI に関する最新情報を入手できます。開発を始めるためのリソースについては、開発者ページをご覧ください。 Hugging Face で公開されている Nemotron モデルとデータセット、および build.nvidia.com の Blueprints をぜひご覧ください。また、Nemotron ライブストリーム、チュートリアル、NVIDIA フォーラムと Discord のデベロッパー コミュニティで交流しましょう。
翻訳に関する免責事項
この記事は、「Route AI Agent Workloads Across Models with NVIDIA NeMo Switchyard」の抄訳で、お客様の利便性のために機械翻訳によって翻訳されたものです。NVIDIA では、翻訳の正確さを期すために注意を払っておりますが、翻訳の正確性については保証いたしません。翻訳された記事の内容の正確性に関して疑問が生じた場合は、原典である英語の記事を参照してください。
