NVIDIA、AIエージェントのタスクを複数モデルへ最適に振り分ける「NeMo Switchyard」を発表
要点
-
NVIDIAは、AIエージェントの処理を複数の特化型モデルや最先端モデルへ最適に振り分けるライブラリ「NeMo Switchyard」を発表した。
-
単一のAIモデルに依存せず、タスクの難易度や特性に応じてモデルを切り替える「System of Models」アプローチを容易に実現する。
-
ルーターはモデルの能力、コストやレイテンシ、システム負荷などのリアルタイムシグナルをもとに送信先を判定する。
-
ベンチマーク検証では、ML・RL分野で「Kimi K2.6」、数学・科学分野で「Qwen3.5 397B A17B」、その他で「DeepSeek V4」を組み合わせる有効性が示された。
-
米NVIDIAは2026年8月11日、AIエージェントのワークロードを複数のAIモデルへ柔軟にルーティング（振り分け）する新技術「NVIDIA NeMo Switchyard」に関する技術記事を公式ブログで公開した。エージェント処理の各ステップを要件やコストに合わせて最適なモデルへ割り振ることで、システム全体の精度向上と運用コスト削減の両立を支援するという。
単一モデル運用の課題とモデルルーティングの必要性
AIエージェント（自律的に目標を達成するために推論やツール実行を行うシステム）を構築する際、すべての処理を単一のモデルで賄うことには実用上の難点が存在する。すべての要求を最大規模の最先端モデルに送信するとコストや応答遅延（レイテンシ）が増大し、逆に小型モデルのみで運用すると高度な推論を要する複雑なタスクで品質が低下するためだ。
実際のワークロードでは、あるステップでは分類処理が必要とされ、次のステップでは深い推論が求められ、その後の定型的な追跡作業には小型モデルで十分であるといったように、求められる要件が目まぐるしく変化する。NVIDIA NeMo Switchyardは、開発者がプロバイダーやモデルの選択ごとにアプリケーションを一から作り直すことなく、複数のモデルを束ねて状況に応じた振り分けを行えるオーケストレーション層を提供するライブラリだ。
ルーティング判断を支える3つのシグナル
NeMo Switchyardのルーターは、実行時に各リクエストの内容と利用可能なコンテキストを評価し、タスクの要件、制約、ポリシーに最も適したモデルへ処理を送信する。効果的なルーティング判断を行うため、システムは主に以下の3領域から得られるシグナルを活用しているという。
- モデルの能力（Model capabilities）：どのモデルがタスクを正確に解決できるかを識別する。リクエストのテキストを分類器や埋め込みモデルで解析してトピックや推定難易度を把握するほか、モデルの対数確率（logprobs）、実行トレース、残差ストリーム、アテンション行列といったモデルの内部状態もシグナルとして活用される。
- モデルのコストプロファイル（Model cost profile）：各モデルの利用コストや応答遅延、トークン消費量、ツール呼び出しの頻度といった出力特性を評価する。
- インフラストラクチャ（Infrastructure）：価格変動、遅延、サーバー負荷、エラー発生状況などのリアルタイムデータを指し、モデル間のシームレスで安定した切り替えを実現する。
ベンチマークに見る「適材適所」のモデル連携
NVIDIAは、コンピューター操作タスクを評価するベンチマーク「Terminal-Bench Hard」において、「Terminus」エージェントを用いた検証結果を提示している。
この検証によると、全体の総合精度では「DeepSeek V4」が最も高い数値を記録したものの、すべての個別タスク群において単独で最適だったわけではないことが判明した。例えば、機械学習（ML）や強化学習（RL）に関するタスク群では「Kimi K2.6」がより適しており、数学や科学分野のタスク群では「Qwen3.5 397B A17B」が優れた結果を示した。残る6つのタスク群にはDeepSeek V4を割り当てるといった組み合わせが有効だという。
さらに、トークン消費と処理時間の観点でもモデルごとに明確な差異が確認されている。検証データでは、Kimiは入力プロンプトのトークン管理において最も効率的であり、Qwenは出力トークンの消費効率で最も優れていると報告されている。
エージェント設計に応じた柔軟な適用粒度
NeMo Switchyardでは、ルーティングを適用する粒度や範囲をシステムの要件に合わせて柔軟に設定できる。複数回のやり取りが発生するエージェントタスク全体を1つのモデルに任せるだけでなく、処理の1ステップごとに異なるモデルへ切り替える運用も可能だ。
また、システム全体で共通のモデルプールを共有する形態に加え、特定のサブエージェントごとに特化型のモデルプールを割り当てる構造など、遅延の許容度やスループット、エラー許容度に応じた多様な構成がサポートされている。