KDnuggetsメディア報道·2026年9月4日 23:00·約13分

NVIDIA、AI エージェントの経路制御ライブラリ「Switchyard」をオープンソース化

#LLM #オープンソース #NVIDIA NeMo #コスト最適化 #ルーティング

整理・翻訳:ainew.jp 編集システムAIによる自動処理作り方と限界

本文の状態

日本語全文を表示中

詳細モードで約13分の本文を読めます。

同じ出来事の情報源

この情報源を基点に整理

KDnuggets

まず要点

NVIDIA は LLM コストとレイテンシを削減するオープンソースのルーティング層「Switchyard」を発表し、アプリケーションからモデル選択を分離して動的に最適なモデルを割り当てる仕組みを提供した。

AI深層分析を開く2026年9月4日 23:22

キーポイント

コストと遅延の解消

既存の AI エージェントはすべての LLM 呼び出しを高価な最先端モデルへ送信する傾向があるが、Switchyard はこれを解決し、不必要なコストと遅延を防ぐ。

ルーティング層の機能

エージェントとモデル間に位置するプロキシおよびライブラリとして動作し、リクエストごとまたはターンごとに処理を担当する最適なモデルを決定する。

柔軟な実装アプローチ

ランダムルーティングからコンテンツ認識型ルーティングへと段階的に移行できるチュートリアルを提供し、開発者が二つのモデル間で動作するルーターを構築可能にする。

インストールと設定

CLI またはサーバーパスで uv や Cargo を使用してインストールでき、OpenRouter などの外部 API キーを活用した構成ファイルによる柔軟な設定が可能である。

確率的ルーティングの設定

strong_probability: 0.3 は強モデルと弱モデルの比率をそれぞれ 30% と 70% に設定する。ランダムなルーティングは知能型ではないが、A/B テストや分類器導入前の検証に有用である。

重要な引用

Most production AI agents still send every LLM call to the same expensive frontier model.

It is an open-source routing layer (proxy + library) that sits between your agent and the models.

The application does not need to know which upstream model ultimately serves the request.

Random routing is not intelligent routing, but it is useful for A/B tests and for validating the proxy before introducing a classifier.

編集コメントを表示

編集コメント

NVIDIA が提供するこのライブラリは、大規模な AI エージェント開発においてモデル選択の複雑さを抽象化する重要なツールとなる。特にコスト管理が課題となっている現場では、即座に導入可能な実用的なソリューションとして注目される。

Source Article

元記事を日本語で読む

本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。

現在、多くの実運用されている AI エージェントは、すべての LLM 呼び出しを同じ高価な最先端モデルに送っています。分類処理、単純なツール呼び出し、進捗確認、そして複雑な推論に至るまで、すべてが同一のエンドポイントに集中してしまいます。その結果、不要なコストとレイテンシが発生しています。NVIDIA NeMo Switchyard はこの課題を解決します。

Switchyard は、エージェントとモデルの間に位置するオープンソースのルーティング層（プロキシおよびライブラリ）です。リクエストごとに、あるいはターンごとに判断し、どのモデルがその処理を担当すべきかを決定します。本チュートリアルでは、動作する 2 モデル構成のルーターを構築し、ランダムなルーティングからコンテンツ認識型ルーティングへと段階的に移行していきます。それでは始めましょう。

Switchyard は具体的に何をするのか？

通常の LLM アプリケーションは以下のような構造になります。

code

Application
    |
    v
GPT / Claude / Local LLM

Switchyard を導入すると、ルーティング層が追加されます。

code

Application
    |
    v
Switchyard
   /   \
  v     v
Cheap   Powerful
Model   Model

アプリケーション側では、最終的にどのアップストリームモデルがリクエストを引き受けるかを意識する必要はありません。Switchyard が実際のターゲットを選択し、リクエストを転送します。実際にどのように機能するかを見てみましょう。

ステップ 1: Switchyard のインストール

CLI またはサーバーパスを利用する場合、プロジェクトのドキュメントでは uv を使用したインストール手順が推奨されています：

code

uv tool install "nemo-switchyard[cli,server]"

インストールの確認を行います。

code

switchyard --version

出力：

code

switchyard 0.2.0
nemo-switchyard v0.2.0

あるいは、ネイティブの Rust サーバーを Cargo で直接インストールすることも可能です。

code

cargo install --locked switchyard-server

このチュートリアルでは、モデルを OpenRouter を経由してルーティングします。まず、API キーをエクスポートしてください。

code

export OPENROUTER_API_KEY="your-key-here"

API キーは設定ファイルに直接保存しないでください。

ステップ 2: Switchyard の構成を理解する

まずは最もシンプルなセットアップから始めましょう。2 つのモデルとランダムルーティングです。

routes.random.yaml という名前の YAML ファイルを作成し、以下を追加してください。

code

defaults:
  base_url: https://openrouter.ai/api/v1
  api_key: ${OPENROUTER_API_KEY}

routes:
  ab-test:
    type: random_routing

    strong:
      model: openai/gpt-4o

    weak:
      model: openai/gpt-4o-mini

    strong_probability: 0.3
    rng_seed: 42
    fallback_target_on_evict: weak

重要な設定は以下の通りです。

code

strong_probability: 0.3

Switchyard はこれを以下のように解釈します。

code

30% -> strong model
70% -> weak model

ランダムルーティングは知的なルーティングではありませんが、A/B テストや、分類器を導入する前にプロキシの検証を行う際に有用です。このルートタイプには fallback_target_on_evict が必須であり、これは strong や weak などのティア ID を指します。

ステップ 3: ルーティングサーバーの起動

Switchyard は以下のように起動します。

code

switchyard serve \
  -c routes.random.yaml \
  --host 127.0.0.1 \
  --port 4000

テスト対象の serve コマンドには --dry-run オプションが存在しません。サーバー起動自体が検証ステップとして機能するため、無効なルーティングバンドルは起動時に即座に失敗します。プロキシが正常に動作しているか確認するには、以下のコマンドを実行してください。

code

curl -s http://127.0.0.1:4000/health

出力結果:

code

{"status":"ok"}

ステップ 4: ルーター経由でリクエストを送信する

次に、OpenAI と互換性のある形式のリクエストを送信します。

code

curl http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"ab-test","messages":[{"role":"user","content":"Explain gradient descent in simple terms."}]}'

このフィールドに注目してください。

code

"model": "ab-test"

クライアントは特定のモデル（gpt-4o または gpt-4o-mini）を指定していません。実際のモデル選択は Switchyard が行います。今回の例では、リクエストが「弱性能」ティアに振り分けられました。

code

"model": "openai/gpt-4o-mini",
"usage": { "prompt_tokens": 14, "completion_tokens": 247, "cost": 0.0001503 }

レスポンス:

code

Gradient descent is a method used in optimization to find the minimum of a function. Imagine you're on a hilly landscape, and your goal is to get to the lowest point in the valley. Here's how it works, step by step:
1) Start at a Random Point: You begin at a random location on the hill.
2) Find the Slope: You look around and determine the steepness of the hill (the gradient) at your current location. This tells you which direction is downhill.
3) Take a Step Downhill: You take a step in the direction that goes down the steepest slope. The length of your step is called the "learning rate" — if you take small steps, you're cautious, while larger steps will get you there faster but might lead you off course.
4) Repeat: You keep repeating this process, recalculating the slope and stepping down until you can't go any lower — that's the bottom of the valley or the minimum of the function.

In simple terms, gradient descent is about marching down the hill step by step until you reach the lowest point. It's widely used in machine learning to adjust models so they make better predictions.

ステップ 5: インテリジェントなルーティングへの移行

ランダムなルーティングは実験には適していますが、以下のような挙動を実現したい場合もあります。

簡単なリクエストには軽量モデルを、複雑なリクエストには高性能モデルを使用する——この目的のために Switchyard は classifier ルートを提供しています。この分類器は、軽量モデルがタスクを解決できるかを推定し、設定された閾値に基づいて判断を下します。

まず routes.smart.yaml を作成し、以下のような設定を書き込みます：

code

defaults:
  base_url: https://openrouter.ai/api/v1
  api_key: ${OPENROUTER_API_KEY}

routes:
  smart:
    type: deterministic

    classifier:
      model: openai/gpt-4o-mini

    strong:
      model: openai/gpt-4o

    weak:
      model: openai/gpt-4o-mini

    profile: general
    session_affinity: true
    fallback_target_on_evict: weak

そして、これを起動します：

code

switchyard serve \
  -c routes.smart.yaml \
  --host 127.0.0.1 \
  --port 4000

これで 3 つの役割が定義されます：

code

classifier
    |
    | predicts weak-model capability
    v
+-------------------+
| Should weak solve?|
+-------------------+
       /      \
      /        \
    yes         no
     |           |
     v           v
   weak        strong

分類器は p_solve という値を含む構造化された推定結果を生成します。これは、軽量モデルがリクエストを正常に完了できる確率の推定値です。

ステップ 6: スマートルートのテスト

簡単な質問を試してみましょう：

code

curl http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "smart",
    "messages": [
      {
        "role": "user",
        "content": "What is 15% of 200?"
      }
    ]
  }'

出力：

code

To find 15% of 200, you can multiply 200 by 0.15:
200 × 0.15 = 30
So, 15% of 200 is 30.

次に、より難しい質問に挑戦します：

code

curl http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "smart",
    "max_tokens": 1500,
    "messages": [
      {
        "role": "user",
        "content": "Find the race condition in a distributed job queue where workers acquire leases using non-transactional Redis operations, then propose a failure-safe redesign."
      }
    ]
  }'

出力：

code

In a distributed job queue system using Redis to manage and lease
jobs to workers, race conditions can occur if multiple workers
attempt to acquire a lease for the same job simultaneously using
non-transactional operations. This can lead to multiple workers
incorrectly believing they have successfully acquired the lease,
resulting in duplicate processing of the same job.

### Typical Race Condition Scenario
...
By incorporating these redesign elements into the distributed job
queue architecture, race conditions can be significantly reduced
and job leases can be handled more reliably and safely.

ここではモデルの選択をハードコードしていません。代わりに、分類器が各プロンプトに対して適切なティア（レベル）を判断し、リクエストをそれに合わせてルーティングします。ログを確認すれば、各リクエストに対して実際にどのモデルが選択されたかを確認できます。

プロンプト	提供されたモデル	ティア	レイテンシ
"200 の 15% はいくらか？"	`openai/gpt-4o-mini`	弱	1,428 ms
Redis の競合状態再設計	`openai/gpt-4o`	強	4,475 ms

ステップ 7：進捗状況に基づいてコーディングエージェントをルーティングする

プロンプトの難易度だけが、ルーティングに役立つシグナルではありません。

30 ターンにわたって作業を行うコーディングエージェントを考えてみましょう。初期のターンではファイルの探索やデバッグ、アーキテクチャに関する推論に時間を費やす可能性があります。一方、後半のターンでは確立された計画の実行や反復的な編集が中心になるでしょう。すべてのターンで最も高性能なモデルを使用すれば、推論コストを無駄にしてしまいます。

Switchyard の stage_router は、このような多段階ワークロードのために設計されています。会話履歴やツールの結果といったシグナルを活用し、各ターンを「高性能」または「高効率」のどちらのティアに振り分けるかを判断します。

以下のような設定を行うことができます：

code

routes:
  stage:
    type: stage_router

    strong:
      model: openai/gpt-4o

    weak:
      model: openai/gpt-4o-mini

    picker: efficient_first
    confidence_threshold: 0.5
    signal_recent_window: 3
    fallback_target_on_evict: weak

この仕組みのアイデアは以下の通りです：

code

Agent turn
    |
    v
Recent progress / failure signals
    |
    v
Is extra capability useful now?
     / \
    /   \
 weak   strong

ここでルーターが検出するのは、エラーや非生産的な反復行動、探索行為、そして直近の有効な変更といったシグナルです。目的は、追加の能力が必要とされるターンにのみ、より強力なモデルを確保することにあります。

ステップ 8：弱モデルが困難に直面した後のみエスカレーションする

別の戦略として、事前に難易度を予測しない方法もあります。

まずは低コストのモデルを試行させ、持続的なトラブルの兆候が確認された段階でエスカレーションします。フローは以下のようになります：

code

Request
   |
   v
Weak model
   |
   v
Judge result
  /    \
okay   struggling
 |        |
 v        v
stay    strong model

Switchyard ではこれをエスカレーション型ルーティングと呼びます。以下のような設定が可能です：

code

routes:
  agent:
    type: escalation_router

    strong:
      model: openai/gpt-4o

    weak:
      model: openai/gpt-4o-mini

    judge:
      model: openai/gpt-4o-mini
      confirmations: 2
      recent_turn_window: 28
      window_message_chars: 500

    fallback_target_on_evict: weak

これは、事前に決定論的に分類するアプローチとは概念的に異なります。

決定論的/能力ベースのルーティングが問うのは、以下の点です：

code

How difficult does this request appear?

一方、エスカレーション型ルーティングが問うのは、以下の点です：

code

Is the weak model actually getting into trouble?

これにより、タスクの難易度が時間とともに変化する長時間実行型のエージェントセッションにおいて、エスカレーション機能が有用なものとなります。

ステップ 9：ルーティングが実際に役立っているかの測定

ルーティング機能は、品質とコストのトレードオフを改善する場合にのみ価値があります。Switchyard では、リクエスト、エラー、レイテンシ、トークン数、およびルーティング動作に関する Prometheus メトリクスや統計情報を公開しています。また、構造化されたリクエストテレメトリーやオプションのルーティングログにも対応しています。

サーバーメトリクスを取得するには以下を実行します：

code

curl -s http://localhost:4000/metrics | head

集計された JSON 統計情報は以下の通りです：

code

curl -s http://localhost:4000/v1/stats | python3 -m json.tool

実験を行う際は、少なくとも 3 つのランニング結果を比較してください。

設定	目的
常に強力	品質の上限とコストの基準値
常に弱い	安価な基準値
Switchyard ルーター	低コストで高品質モデルの性能をどれだけ捉えられるかをテストする

重要なのは、ルーターの精度が 85% だったかどうかではなく、強力なモデルの性能をどの程度維持し、コストとレイテンシをどれだけ削減できたかです。例えば：

code

Strong-only:
$20
92% task success

Weak-only:
$5
71% task success

Router:
$9
89% task success

これにより、ルーティングが経済的に有効かどうかを判断できます。

まとめ

LLM システムがより自律的になるにつれて、問われているのは以下の通りです。

どのモデルを使うべきか？

から

このリクエストには、ワークフローのこの段階で、このコスト予算の中でどのモデルを使うべきか？

へと変化しています。

Switchyard は、この意思決定を再利用可能なインフラとして実現しようとする NVIDIA の取り組みです。

最初の試行では、いきなりステージ別ルーティングや複雑なエージェントのエスカレーションを導入するのではなく、まずは 2 つのモデルを用意してください。それぞれを独立して評価し、設定が正しく動作しているか確認するために加重ランダムルーティングを使用します。その後、機能ベースのルーティングを導入し、強力なモデルの性能をほぼ維持したまま、意味のある割合のリクエストをより安価なティアへ移行できているかを測定しましょう。

この実験は、単なる LLM ベンチマークよりもはるかに有用な成果をもたらします：

code

a quality-versus-cost curve for your actual workload.

これが、インテリジェントなモデルルーティングが究極的に最適化しようとしているものです。

Kanwal Mehreen 氏は、機械学習エンジニアであり技術ライターです。データサイエンスと AI と医療の交差点に対する深い情熱を持っています。ChatGPT を活用して生産性を最大化するための電子書籍「Maximizing Productivity with ChatGPT」の共著者でもあります。2022 年のアジア太平洋地域向け Google Generation Scholar に選出され、多様性と学問的卓越性の推進に尽力しています。また、Teradata のテック分野におけるダイバーシティ・スカラー、Mitacs Globalink Research スカラー、Harvard WeCode スカラーとしても認められています。Kanwal氏は変革の熱心な支持者であり、STEM 分野での女性を支援するために「FEMCodes」を設立しました。

この記事をシェア

VentureBeat AI2026年8月11日 22:00

Nvidia、AI モデルをタスク中に切り替えるルーター「Switchyard」を発表

Latent Space2026年9月2日 16:46

Anthropic、SOTAモデルClaude Fable/Mythos 5.1発表とキャッシュ価格引き下げ

Vercel Blog2026年9月2日 09:00

DigitalOcean AI Gateway で GLM-5.3 が 50% オフ

今日のまとめ

AIデイリーブリーフで今日の重要ニュースをまとめ読み

NVIDIA、AI エージェントの経路制御ライブラリ「Switchyard」をオープンソース化

キーポイント

重要な引用

編集コメント

元記事を日本語で読む

Switchyard は具体的に何をするのか？

ステップ 1: Switchyard のインストール

出力：

ステップ 2: Switchyard の構成を理解する

ステップ 3: ルーティングサーバーの起動

出力結果:

ステップ 4: ルーター経由でリクエストを送信する

レスポンス:

ステップ 5: インテリジェントなルーティングへの移行

ステップ 6: スマートルートのテスト

出力：

出力：

ステップ 7：進捗状況に基づいてコーディングエージェントをルーティングする

ステップ 8：弱モデルが困難に直面した後のみエスカレーションする

ステップ 9：ルーティングが実際に役立っているかの測定

まとめ

関連記事

調べる

選ぶ

サイト