NVIDIAは2026年8月11日、AIエージェントの要求を複数の大規模言語モデル（LLM）へ振り分ける「NeMo Switchyard」を発表した。高価なモデルを全処理で呼ばず、難しい局面に絞って使うオープンソースのルーターだ。LangChainの評価では、Claude Opus 4.8単独と比べて費用を74%減らした一方、精度は86.0%から80.0%へ下がった。企業が手にするのは一律の値下げではなく、費用と品質の交換条件をワークフローごとに設計する仕組みである。
74%減の代わりに、精度は6ポイント下がった
LangChainは、顧客対応や障害調査、メッセージ・課題管理・メールをまたぐ自動化など、145件の複数ターンタスクでSwitchyardを評価した。各タスクは平均6.3回モデルを呼び出す。安価なNVIDIA Nemotron 3.5 Lightningで処理を始め、判定役のモデルが行き詰まりを検出するとClaude Opus 4.8へ切り替える「エスカレーション」方式を5回走らせた。
| 構成 | 精度 | 評価費用 | 完了タスク当たりの費用 |
|---|---|---|---|
| Claude Opus 4.8のみ | 86.0% | 11.45米ドル | 0.092米ドル |
| Switchyardで振り分け | 80.0% | 3.00米ドル | 0.026米ドル |
| Nemotron 3.5 Lightningのみ | 77.7% | 0.72米ドル | 0.006米ドル |
Switchyardの評価費用は11.45米ドルから3.00米ドルへ下がり、削減率は74%に達した。ただし精度の低下は6.0ポイントある。Lightning単独に対しては2.3ポイント高かったものの、評価ごとの変動幅2.7ポイントより小さい。LangChainも、ルーティングが安価なモデル単独を上回ったとは判断していない。最低費用を優先し、Lightningの77.7%で要件を満たせるなら、同じ評価ではルーターを挟まない方が安い。
評価条件にも幅がある。NVIDIAが紹介した別の検証では、CognitionがOpus 5とKimi K2.7を振り分け、コーディング評価FrontierCode Mainで50.6%を記録した。Opus 5より2.8ポイント低く、平均費用は3.11米ドルで約28%安かった。74%と28%の差は、モデルの価格差とタスク構成が変われば削減率も動くことを示す。
単価ではなく「仕事を終える費用」を選ぶ
Switchyardは、アプリケーションとモデル提供元の間に置くRust製のプロキシ兼ライブラリだ。OpenAI Chat Completions、OpenAI Responses、Anthropic Messagesの要求を共通の内部形式で扱い、選んだモデルの形式へ変換する。アプリケーション側は一つのモデルIDへ接続したまま、OpenAI互換サーバーやAnthropic API、ローカルで動かすモデルを切り替えられる。
ルーティングには四つの基本方式がある。ランダム方式はA/Bテスト向けで、LLM classifierは要求内容から必要な能力を判定する。stage routerはツールの実行結果やエラー、作業の進み方を読み、探索や復旧は強いモデルへ、機械的な編集は安価なモデルへ送る。エスカレーション方式は安価なモデルの実行結果を判定役が追い、既定では2回続けて問題を検出すると、そのセッションを強いモデルへ固定する。
判断基準をトークン単価に絞ると、実際の請求額を読み違える。安いモデルでも出力が長く、ツールを何度も呼べば、仕事を終えるまでの費用は膨らむからだ。Switchyardは選択したモデルや判断理由、トークン数、遅延、呼び出し結果を記録する。送り先は方式に応じて、要求内容、ツール履歴、セッションの進み方から決める。NVIDIAのJoey ConwayもThe Registerの取材で、強いモデルが全体を指揮し、小さな専門モデルへ実行を任せるエージェント構成が現れ始めていると説明した。
7%のOpusと、21.2%を使う判定役
LangChainの評価でOpusへ送られた呼び出しは全体の7%だった。それでもOpusは振り分け構成の費用の68.4%を占めた。Lightningは93%の呼び出しを処理しながら、費用の10.4%に収まった。呼び出し当たりの平均費用はOpusが0.0324米ドル、Lightningが0.00037米ドルで、約87倍の開きがあった。
残る21.2%は、安価なモデルが行き詰まったかを判定するモデルの費用だ。判定役は強いモデルへ切り替わるまで各ターンで動き、入力キャッシュの恩恵も受けなかった。LangChainの構成では評価当たり0.64米ドルを使い、安いモデルへの移管で採算を取るために必要な最低比率は5.9%だった。実測の93%は条件を満たしたが、二つのモデルの価格差が狭ければ必要比率は100%を超え、ルーティングでは節約できない。
請求額も一定にはならない。5回の評価でOpusへ送った割合は4.1%から9.1%、総費用は2.16米ドルから3.61米ドルまで動いた。平均費用は下げられても、難しい要求が重なる回では高価なモデルの利用が増える。企業は74%という一点ではなく、最も費用がかかった回を予算へ、6ポイントの低下を品質基準へ織り込む必要がある。
pre-alphaのルーターをどこから試すべきか
公開リポジトリはSwitchyardをpre-alphaとし、v1.0までAPIとアルゴリズムが大きく変わり得ると明記している。さらに「実験的で、本番利用向けではない」と警告する。Apache 2.0でコードを検証できる利点はあるが、現時点で企業の基幹経路へそのまま置ける完成品ではない。
運用基盤も別に用意しなければならない。Switchyardは設定された接続先へ要求を送り、選択モデルや判断理由、トークン数、遅延、呼び出し結果を記録するが、接続先のモデルサーバー自体は起動も管理もしない。複数の外部APIと自社運用モデルを混ぜるなら、認証情報、障害時の切り戻し、要求をどの接続先へ渡せるかというデータ管理は導入側の仕事として残る。
方式ごとの適用範囲も狭い。エスカレーションは複数ターンの履歴を前提とし、2回以上の連続判定を使うにはセッションIDが要る。単発の要求には向かない。安価なモデルの応答後に判定役を呼ぶため、LangChainは追加遅延を約700ミリ秒と測った。遅延を抑えたい場合は、追加のモデル呼び出しを必要としないstage routerが候補になる。ただし、ツール実行履歴が乏しいチャットでは判断材料が不足する。
導入の初手は、本番トラフィックを直ちに切り替えることではない。代表的なタスクを固定し、強いモデル単独、安価なモデル単独、振り分け構成の三つで完了率と総費用を測る。そのうえで判定役の費用、応答時間の上限、強いモデルへ送る割合を確認する。Switchyardが企業AIの支出を抑えられるかは、74%という発表値ではなく、自社の失敗コストを含めた完了タスク当たりの数字で決まる。
