NVIDIAは2025年7月、LLM（大規模言語モデル）トラフィックを自在にルーティングし、異なるAPI間の変換をリアルタイムで実行するRust製プロキシ「Switchyard」を公開した。このツールは、Claude Code（Anthropic Messages API）、Codex CLI（OpenAI API）といった、異なるAPIを話すコーディングエージェントと、vLLM、NVIDIA NIM、Ollamaなど多様なバックエンドの間に立つ翻訳層として設計されている。Apache 2.0ライセンスで提供されるが、NVIDIAはこれをプレアルファ版かつ実験的ステータスと位置づけており、本番環境での使用は推奨していない。
Switchyardが必要とされる背景——コーディングエージェントのAPI断片化問題
近年、Claude CodeやCodex CLIに代表されるAIコーディングエージェントの普及が急速に進んでいる。しかし、各エージェントが話すAPIは統一されていない。AnthropicはMessages API、OpenAIはChat Completions APIやResponses APIを採用しており、開発チームが実際に使いたいLLMはNVIDIA NIMやvLLM、Ollamaといった異なるバックエンドで稼働している。エージェント側のコードを書き換える選択肢が取れない場合、API変換層は別の場所に存在する必要がある。この課題への答えとしてNVIDIAが提供するのがSwitchyardである。
Switchyardの中核機能——プロトコル変換とルーティング
Switchyardは、クライアントが本来のAPI形式のままリクエストを送信できる点が最大の特徴だ。内部では、受信したリクエストをプロバイダーに依存しないRust型にデコードし、ルーティングアルゴリズムによって最適なバックエンドを選択、そのバックエンドのワイヤーフォーマットに再エンコードして呼び出し、レスポンス（ストリーミングイベントを含む）をクライアントが期待する形式に変換して返す。
サーバーは3つのインバウンド形式——OpenAI Chat Completions、OpenAI Responses、Anthropic Messages——を受け入れ、どの形式からも任意のルートにリクエストを送ることができる。各LLMクライアントは独自のアップストリーム形式を選択可能で、エージェントのAPIとバックエンドのAPIが一致する必要は一切ない。この分離こそがSwitchyardの核心的な設計思想である。
3つの実行方法——ランチャー、サーバー、ライブラリ
Switchyardは用途に応じて3つの実行パスを提供する。まずランチャーパスは、コーディングエージェント向けに設計されている。uv tool install --python 3.12 "nemo-switchyard[cli]"codeでツールをインストールし、switchyard launch claudecodeやswitchyard launch codexcodeといったコマンドで、あらかじめパッケージ化されたデプロイメントや独自のTOMLファイルを指定して起動する。
サーバーパスでは、cargo install --locked switchyard-servercodeでスタンドアロンプロキシをインストールし、--dry-runcodeで設定を検証した後、任意のホストとポートで稼働させる。
ライブラリパスは、switchyard-libsycodeクレートを通じてルーティングアルゴリズムをRustアプリケーションに直接埋め込む方式だ。HTTPスタックを自前で持たず、アルゴリズムがターゲットを決定し、モデル呼び出しはすべて呼び出し元に委ねられる。
4つのルーティングアルゴリズム
Switchyardのルートは、クライアントから見える1つのモデルIDとその背後にあるアルゴリズムの組み合わせとして定義される。現在4つのアルゴリズムが実装されている。
passthroughは最もシンプルで、すべてのリクエストを単一のターゲットに送る。randomは重み付けランダム選択でトラフィックを分割し、オプションのシードで選択シーケンスを再現可能にする。これはA/Bテストやコスト実験のための経路である。
llm_classifierは、より高度なルーティングを実現する。まずクラシファイアモデルにタスクの能力レベルを判定させ、その結果に基づいて強いターゲット（strong）か弱いターゲット（weak）に振り分ける。base_thresholdcodeは必須パラメーターで、min_confidencecode、capability_elevated_floorcode、session_affinitycodeによって動作を微調整できる。判定不能なリクエストは自動的に強いターゲットへフォールバックする。mode = "escalation"codeを設定すると、すべてのターンでまず弱いターゲットを試し、判定モデルが強いターゲットでの再実行が必要と判断した場合にエスカレーションする仕組みになる。
stage_routerは、ツールの実行結果やエージェントの進行状況シグナルを直近のターンからスコアリングし、capable（高能力）かefficient（効率的）なターゲットを選択する。ほとんどのターンでクラシファイアの呼び出しを省略できるため、オーバーヘッドを低減できる。
ここで重要なのは、strong、weak、capable、efficientといったラベルがターゲットそのものの固定属性ではなく、ルート内での役割（ロール）にすぎない点だ。同じアップストリームモデルが異なるルートで異なるロールを担うことも可能である。
観測可能な運用——Prometheusメトリクスとルーティングオーバーヘッド
Switchyardは運用面でも充実した観測機能を備える。GET /metricscodeエンドポイントは、OpenTelemetryプロバイダーを通じてPrometheusテキスト形式のメトリクスを返す。リクエスト数、エラー数、モデル呼び出しレイテンシ、ターン全体のレイテンシ、プロンプトトークン数、完了トークン数、キャッシュ関連トークン数、推論トークン数、そしてアップストリームHTTPの試行結果とステータスコード別の統計が含まれる。tiercodeラベルには、クラシファイアの判定結果としてstrongcodeまたはweakcodeが付与され、クラシファイア呼び出し自体はこれらのメトリクスから除外される。
特に注目すべきはswitchyard_routing_overhead_mscodeメトリクスである。これはアルゴリズムの実行時間から、リクエストを処理したモデル呼び出しの時間を差し引いた値だ。クラシファイア呼び出しは減算対象から除外されるため、llm_classifierルートでは分類にかかった時間が報告される一方、passthroughやrandomではターゲット選択にかかるサブミリ秒単位のコストが把握できる。バケットは0.1ミリ秒から始まる。さらに、--routing-log-filecodeオプションで完了したレスポンスごとにJSONレコードを追記でき、GET /v1/routing/session-statscodeエンドポイントからはセッションごとの呼び出し数とトークン合計を取得可能である。
設定構造とセキュリティ——3層のTOMLデプロイメント
Switchyardの設定はTOML形式で記述され、3つの層で構成される。llm_clientsではベースURL、ワイヤーフォーマット、認証情報の環境変数名、リトライポリシーを定義。targetsはアップストリームのモデルIDをクライアントに紐づける。routesはクライアントから見えるモデルIDとそのアルゴリズムを公開する。機密情報は設定ファイルに直接記述せず、api_key_envcodeで環境変数名のみを指定する方式が取られている。max_retriescodeのデフォルト値は2で、トランスポート障害、タイムアウト、HTTP 408/429、5xx系レスポンスに対して適用される。
評価ツールとしての位置づけと今後の展望
NVIDIAはSwitchyardをプレアルファ版かつ実験的ステータスと明確にラベリングしており、v1.0までにAPIやアルゴリズムが大幅に変更される可能性があると警告している。crates.ioからのバイナリインストールおよびPyPIからのランチャーインストールが可能で、どこでもセルフホスティングできるが、現時点ではあくまで評価目的での使用が想定されている。
コーディングエージェントのエコシステムが拡大し、APIの断片化が進む中で、Switchyardはプロトコル変換とインテリジェントルーティングを1つのツールで提供する点で独自の価値を持つ。特に、llm_classifierによる能力ベースのルーティングやstage_routerによるオーバーヘッド低減のアプローチは、効率的なLLM運用を模索するチームにとって検討に値する。プロダクション利用には時期尚早ではあるものの、NVIDIAがこの分野でどのような方向性を示すのか、今後のアップデートに注目が集まる。
