NVIDIA NeMo Switchyardの使い方|複数AIモデルを自動振り分ける設定手順とNemotron 3.5 Lightning【2026年8月時点】
AIエージェントを業務に組み込むと、必ずぶつかるのが「毎回フロンティアモデルを叩くとコストが跳ね上がる」という問題です。かといって安いモデルに寄せると、複雑な判断でつまずいて手戻りが増えます。この記事では、その中間を自動で埋めるNVIDIAの新しいOSS「NeMo Switchyard」の使い方を、インストールから設定ファイルの書き方まで手を動かせる形で整理します。
NeMo Switchyardとは|モデルルーティングを自前で回すためのOSS
結論から言うと、NeMo Switchyardは「リクエストの内容に応じて、どのAIモデルに投げるかを自動で選ぶ振り分け層」です。オープンモデル・商用API・NVIDIA製モデルを混在させ、簡単なタスクは安いモデル、難しいタスクは高性能モデルへと自動でルーティングします。NVIDIAは2026年8月11日に、このSwitchyardと軽量高速モデル「Nemotron 3.5 Lightning」を同時に発表しました(NVIDIA公式ブログ)。

出典: NVIDIA公式ブログ
効果は数字でも示されています。NVIDIA社内ベンチマークでは、Switchyardでルーティングしたシステムがフロンティア級の精度を保ちつつ、タスク完了コストをOpus 4.8単体運用の約3分の1に削減したと報告されています(NVIDIA Technical Blog)。ただし、いずれもNVIDIA自身が公表した値である点は押さえておきましょう。
概要・料金・ライセンス|「無料」の範囲はどこまでか
まず費用面を整理します。NeMo Switchyard本体はApache 2.0ライセンスのオープンソースで、ライセンス購入もアカウント登録も不要です(GitHub README)。一方で、Switchyardが呼び出す先の商用APIは通常どおり従量課金です。「ツールは無料、裏側のモデル呼び出しコストは別」と理解してください。
Nemotron 3.5 Lightningは300億パラメータ(アクティブ3B)のMixture-of-Experts(MoE、タスクごとに一部の専門家ネットワークだけを使い分けて計算量を抑える構成)型モデルで、Mamba-2層(Transformerより計算コストの低い系列処理層)とMoE層を交互に配置したハイブリッド構成です。投機的デコーディング(軽量モデルが下書きの出力候補を先に作り、本体モデルがそれをまとめて検証・採用することで生成を高速化する手法)と量子化(NVFP4という低ビット精度でモデルの重みを圧縮し、メモリ使用量と処理速度を改善する手法)により、同クラス比で最大4倍の出力速度をうたっています。ライセンスはLinux Foundationの「OpenMDW-1.1」で、モデルカードにも商用利用可と明記されています。

出典: NVIDIA公式ブログ
| 項目 | NeMo Switchyard | Nemotron 3.5 Lightning |
|---|---|---|
| 種別 | モデルルーティング用OSS | オープンウェイトのMoEモデル |
| ライセンス | Apache 2.0 | OpenMDW-1.1(商用利用可) |
| 規模 | Rust製プロキシ+CLI | 30B(アクティブ3B) |
| 入手先 | GitHub(NVIDIA-NeMo/Switchyard) | Hugging Face / Ollama / OpenRouter / build.nvidia.com |
| 費用 | 無料(呼び出し先API料金は別) | 無料(自前ホスティング時。API経由の利用は別途課金の場合あり) |
| 動作環境 | ローカル・自社サーバー | DGX Spark(GB10)1GPU、H100 1GPUなど |
2026-08-12時点の公開情報にもとづく
NVIDIA発表のベンチマーク(NVFP4版)では、MMLU Pro 81.62、GPQA Diamond 75.57、SWE-bench Verified 52.80を記録しています(Hugging Face モデルカード)。手元で試すだけならollama run nemotron-3.5-lightningが最短で、Ollama公式ページによるとモデルサイズは約25GB(30bタグ、MLX版は約23GB)です。公式に名指しされている動作環境はNVIDIA RTX PC、DGX Spark、DGX Station、RTX PRO、Jetson、クラウド環境で、DGX Spark(GB10)やH100であれば1GPUで動作します(NVIDIA公式ブログ)。ただし手元のコンシューマー向けGPUで動かす場合に必要なVRAM容量やCPU実行の可否、より軽量なタグの有無は一次情報から確認できていないため、自分の環境で動くかは実際に試すか公式ドキュメントで要確認です。

出典: NVIDIA公式ブログ
NeMo Switchyardのインストール・設定手順【2026年8月時点】
導入経路は3つある
READMEでは3つの入り口が示されています。用途に応じて選びます。
| 経路 | コマンド例 | 向いている用途 |
|---|---|---|
| ランチャー | uv tool install --python 3.12 "nemo-switchyard[cli]" |
まず挙動を試したい |
| サーバー | cargo install --locked switchyard-server |
複数アプリから共有したい |
| ライブラリ | switchyard-libsy / switchyard-protocol を依存に追加 |
Rustアプリに直接組み込む |
事前準備として、ランチャー経由ならPython 3.12とuv、サーバー経由ならRustツールチェーン(Cargo)が必要です。
ランチャー経由でClaude Codeと連携する
最短で試すならこちらです。インストール後、switchyard launch claude --model switchyardを実行すると、Claude CodeなどのツールをSwitchyard経由で起動できます。普段のエージェント運用にそのまま差し込めるため、既存ワークフローを壊さずに効果を測れます。
スタンドアロンサーバーとして動かす
共有プロキシとして常駐させる場合は、cargo install --locked switchyard-serverでインストールし、設定ファイルを用意してから起動します。
switchyard-server --config routes.toml --host 127.0.0.1 --port 4000
各アプリのAPIベースURLをhttp://127.0.0.1:4000に向ければ、振り分けはSwitchyard側で完結します。
routes.tomlの基本構成
GitHubリポジトリで確認できる設定ファイルはTOML形式で、大きく3ブロックに分かれます。
| ブロック | 役割 |
|---|---|
[llm_clients] |
接続先エンドポイントの定義(OpenAI Chat / OpenAI Responses / Anthropic Messages形式) |
[targets] |
強いモデル・弱いモデルなど振り分け先の指定 |
[routes] |
ランダム振り分け・LLM分類器・ステージルーターなどアルゴリズムの選択 |
考え方はシンプルで、「どこに繋ぐか」「どのモデルを候補にするか」「どう選ぶか」を上から順に書くだけです。最小構成のイメージは次のようになります(キー名・書式は今後変わる可能性があるため、実際に書く際は最新のREADME/ドキュメントで確認してください)。
# 1. どこに繋ぐか(接続先エンドポイント)
[llm_clients]
name = "local-lightning"
type = "openai_chat" # OpenAI Chat / OpenAI Responses / Anthropic Messages のいずれか
base_url = "http://127.0.0.1:11434/v1" # ローカルのNemotron 3.5 Lightningなど
[llm_clients]
name = "frontier-api"
type = "anthropic_messages"
base_url = "https://api.anthropic.com"
# 2. どのモデルを候補にするか(振り分け先)
[targets]
name = "weak"
client = "local-lightning"
model = "nemotron-3.5-lightning"
[targets]
name = "strong"
client = "frontier-api"
model = "claude-opus-4.8"
# 3. どう選ぶか(振り分けアルゴリズム)
[routes]
strategy = "llm_classifier" # random / llm_classifier / stage_router から選択
default = "weak"
escalate_to = "strong"
[routes]で選べるアルゴリズムは、大まかには次のような使い分けになります(詳細な挙動は公式ドキュメントで確認してください)。
- ランダム振り分け: 名前のとおりリクエストを確率的に複数モデルへ分散させる方式。負荷分散やA/Bテスト的な比較検証に向いています。
- LLM分類器: 別のLLMがリクエストの内容・難易度を判定してから振り分け先を決める方式。「簡単なタスクは弱いモデル、複雑なタスクは強いモデルへ」といった内容ベースの制御をしたい場合に使います。
- ステージルーター: あらかじめ定義した処理段階(ステージ)ごとに振り分け先を切り替える方式。複数ターンにまたがるエージェントの処理で、段階に応じてモデルを使い分けたい場合に向いています。
つまずきやすいポイント
最大の注意点は仕様の流動性です。実行前に以下を押さえておくと迷いにくくなります。
- 設定形式の食い違い: GitHub公式では
routes.toml(TOML)が確認できますが、公開直後のClassmethodの検証記事ではYAML(profiles.yaml)ベースの構成とswitchyard serveというコマンドが紹介されており、記述が食い違っています。 - pre-alphaである旨の明記: READMEには「Pre-alpha software with rapidly evolving APIs; not recommended for production use.」と明記されています。
- 確認すべきドキュメント: 実行前に必ず最新のREADMEと
docs/getting_started.mdを確認してください。 - 本記事の情報時点: 本記事のコマンドは2026年8月時点の一次情報にもとづくものです。
実務ワークフロー例|コスト・速度・品質で使い分ける
典型的なのはコーディングエージェントです。定型的なリファクタやログ整形はNemotron 3.5 Lightningのようなローカル・低コストモデルに任せ、設計判断や難易度の高いバグ修正だけフロンティアモデルへエスカレーションします。全リクエストの数%だけ高価なモデルを通す構成にできれば、体感品質を保ったまま請求額を大きく下げられます。

出典: NVIDIA公式ブログ
NVIDIAが公表した導入事例も、狙う効果ごとに整理すると参考になります。
| 企業 | 主な効果 | 補足 |
|---|---|---|
| Ramp | コスト58%削減、タスク実行時間33%短縮 | 金融プラットフォーム |
| LangChain | 145タスクでコスト74%削減 | フロンティアモデル呼び出し率7%、精度低下は約6ポイント |
| Boomi | 後続ターンのレイテンシ21%削減 | 一部トラフィックを高速な微調整モデルへ振り分け |
| Cognition | 精度50.6%・平均コスト3.11ドル | ルーティング実装での実測値として報告 |
出典: NVIDIA公式ブログ、NVIDIA Technical Blog。いずれもNVIDIA発表値
LangChainの例が示すとおり、コスト削減と精度は完全な両立ではありません。許容できる精度低下の幅を先に決め、そこから振り分け比率を調整するのが現実的です。

出典: NVIDIA公式ブログ
競合ツールとの比較|OpenRouter・RouteLLM・Not Diamondとの違い
同種のサービスと比べると、Switchyardの立ち位置は「自分で動かす」点にあります。OpenRouterは単一APIエンドポイントで多数のモデルにアクセスできるホスト型クラウドサービスですが、Switchyardは自分の環境で動かすOSSで、含めるモデル・ルーティングロジック・データの行き先を自分で制御できます(MindStudio Blog)。
| 観点 | NeMo Switchyard | OpenRouter | RouteLLM / Not Diamond |
|---|---|---|---|
| 提供形態 | OSS(セルフホスト) | ホスト型クラウド | OSS/商用ルーティング |
| データの行き先 | 自社で制御 | サービス経由 | 実装により異なる |
| ルーティング制御 | 設定ファイルで自由に定義 | Auto mode等が中心 | ルーター学習が中心 |
| 費用 | 本体無料+呼び出し先API料金 | トークン従量課金 | 実装により異なる |
2026-08-12時点の公開情報にもとづく整理
データの外部送信を避けたいチーム、社内推論基盤とクラウドAPIを併用したいチームには、セルフホスト型のSwitchyardが噛み合います。逆に運用を任せたいなら、ホスト型のほうが手間は少ないでしょう。
制限・セキュリティ・注意点
導入前に確認しておきたい点は次のとおりです。
- pre-alpha段階: READMEが本番利用を推奨していません。まずは検証環境で試すのが前提です。
- ログの範囲: Switchyardはモデル選択・判断根拠・トークン使用量・レイテンシ・呼び出し結果を記録できますが、コンプライアンス用途の正式な監査証跡・権限管理・PIIマスキングまでを単体で担うものではありません。厳格なガバナンスが必要ならKong AI GatewayのようなAPIゲートウェイとの併用が想定されています。
- ベンチマークの出所: 本記事の数値はすべてNVIDIA発表値で、第三者による独立検証は確認できていません。
- 外部APIの利用: OpenRouterなど外部プロバイダーへ振り分ける設定では社内データが外部に送信されます。各サービスの利用規約とセキュリティポリシーを必ず確認してください。
まとめ|まずランチャー経由で挙動を確認する
NeMo Switchyardは、複数モデルでエージェントを運用していてコストと速度のバランスに悩んでいるチームにとって、試す価値の大きい選択肢です。本体は無料で、設定ファイル3ブロックの理解から始められます。
最初の一歩は、uv tool install --python 3.12 "nemo-switchyard[cli]"でランチャーを入れ、普段使っているエージェントをSwitchyard経由で動かして挙動を見ることです。pre-alphaで仕様変更が速いため、公式GitHubリポジトリのREADMEとIssue/Discussionsをウォッチしながら進めてください。本記事の内容は2026-08-12時点の情報です。
