NVIDIA、LLM トラフィックをルーティング・変換する Rust プロキシ「Switchyard」を発表

コードエージェントを運用するチームは、誰もが同じ壁にぶつかります。Claude Code は Anthropic Messages API を使い、Codex CLI は OpenAI に依存します。しかし、実際に提供したいモデルが vLLM、NVIDIA NIM、あるいは Ollama の背後にある場合、エージェント自体を書き換える選択肢はありません。そこで、翻訳レイヤーを別箇所に設ける必要があります。

Switchyard は NVIDIA が提案する解決策です。これは LLM トラフィック向けの Rust プロキシおよびライブラリで、プロバイダ間でリクエストをルーティングし、OpenAI と Anthropic の形式間を変換します。また、運用メトリクスを記録し、型安全で組み合わせ可能なルーティングアルゴリズムも公開しています。Apache 2.0 ライセンスの下でリリースされており、ドキュメントは docs.nvidia.com/nemo/switchyard で確認できます。

導入可能でしょうか？はい、可能です。ただし評価用に限られます。バイナリは crates.io から、ランチャーは PyPI からインストールでき、どこでもセルフホスト可能です。しかし NVIDIA は Switchyard をプレアルファおよび実験段階として位置づけ、本番環境での使用には適さないとし、API やアルゴリズムが v1.0 になるまで大幅に変更される見込みであることを警告しています。

Switchyard の仕組み

クライアントはネイティブの API をそのまま維持します。Switchyard は受信リクエストをプロバイダに依存しない Rust タイプに変換し、ルーティングアルゴリズムを実行してバックエンドを選択します。その後、そのバックエンド固有のワイヤーフォーマットで再エンコードして呼び出し、レスポンス（ストリーミングイベントを含む）をクライアントが期待する形式に変換して返却します。

サーバーは、OpenAI Chat Completions、OpenAI Responses、Anthropic Messages の 3 つの入力形式を受け付けます。どの形式でも任意のルートにアクセス可能で、各設定された LLM クライアントは独自の上流側フォーマットを一つ選択します。この分離こそが本質です。エージェント側の API とバックエンド側の API が一致している必要はありません。

運用方法はいくつかあります。

ランチャーパスはコーディングエージェント向けに設計されています。公開ツールを uv tool install --python 3.12 "nemo-switchyard[cli]" でインストールし、パッケージ化されたデプロイメントまたは独自の TOML ファイルに対して switchyard launch claude、switchyard launch codex、あるいは switchyard launch openclaw を実行します。

サーバーパスでは、cargo install --locked switchyard-server でスタンドアロンのプロキシをインストールし、--dry-run で設定を検証した上で、指定したホストとポートでサービスを開始します。

ライブラリパスは switchyard-libsy を使用します。これは HTTP スタックを保持することなくルーティングアルゴリズムを Rust アプリケーションに埋め込むものです。モデル自体を呼び出すことはなく、アルゴリズムがどのターゲットを使用するかを決定し、すべてのモデル呼び出しを呼び出し元に返却します。

ルーティングアルゴリズムについて

ルートとは、クライアントから見えるモデル ID と、その背後にあるアルゴリズムの組み合わせです。サーバーは以下のアルゴリズムをサポートしています。

• passthrough：すべてのリクエストを一つのターゲットに転送します。
• random：オプションの相対重みを用いてトラフィックを複数のターゲット間で分割し、選択シーケンスを再現するためのシードも指定可能です。A/B テストやコスト実験に適したパスです。

llm_classifier は、機能の判定を行うために分類器ターゲットを呼び出し、その後、弱いターゲットまたは強いターゲットへルーティングします。base_threshold は必須であり、min_confidence、capability_elevated_floor、session_affinity で調整可能です。もし判別者が決定を下せない場合は、自動的に強いターゲットへフォールスルーされます。

mode に "escalation" を設定すると、すべてのターンでまず弱いティアで実行され、その後、判別者によって強いティアでの再実行が必要かどうかを判断します。

stage_router は、直近のターンからのツール結果やエージェント進捗のシグナルをスコアリングし、能力に優れたターゲットか効率的なターゲットかを決定します。これにより、ほとんどのターンで追加の分類器呼び出しを回避できます。

"Strong（強い）"、"weak（弱い）"、"capable（能力に優れる）"、"efficient（効率的）" は、ルーティング内の役割であり、モデル自体に固定された属性ではありません。同じアップストリームモデルでも、異なるルート内では異なる役割を果たすことができます。

観測可能性 (Observability)

GET /metrics エンドポイントは、サーバーのプロセス全体で動作する OpenTelemetry プロバイダーから Prometheus 形式のメトリクスデータを返します。対象となるメトリクスファミリーには、リクエスト数、エラー数、モデル呼び出しのレイテンシ、1 ターン全体のレイテンシ、プロンプト・コンプリート・キャッシュされたトークン数、キャッシュ作成時のトークン数、推論用トークン数、そして結果やステータスコード別のアップストリーム HTTP 試行回数が含まれます。

分類器の判断が明確な場合、"strong（強い）" または "weak（弱い）" を示す tier ラベルが付与されます。なお、これらのメトリクスファミリーには分類器自体の呼び出し数はカウントされません。

より興味深い指標は switchyard_routing_overhead_ms です。これはアルゴリズムの実行時間から、リクエストに応じた呼び出し時間を差し引いた値を報告します。ただし、分類器（classifier）の呼び出し時間は差し引きません。そのため、LLM による分類ルートの場合は分類に要した時間がここに記録され、パススルーやランダム選択の場合はターゲットを選定するサブミリ秒単位のコストが報告されます。バケットは 0.1 ms から開始します。

また、--routing-log-file オプションを使用すると、完了したレスポンスごとに JSON レコードが追加記録されます。さらに GET /v1/routing/session-stats エンドポイントでは、そのログからセッションごとの呼び出し数とトークン総数が取得可能です。

設定

TOML 形式のデプロイ構成には、3 つの層があります。

• llm_clients: ベース URL、ワイヤーフォーマット、認証クレデンシャルを格納する環境変数名、リトライポリシーを定義します。
• targets: 1 つの上流モデル ID をクライアントに紐付けます。
• routes: クライアントから見えるモデル ID と、それに対応するアルゴリズムを公開します。

シークレットはファイル内に保存されません。api_key_env は単に環境変数名を指定するだけです。max_retries のデフォルト値は 2 で、トランスポート障害、タイムアウト、HTTP 408/429、および 5xx レスポンスに対して適用されます。

主なポイント

Switchyard は、Apache-2.0 ライセンスの Rust 製プロキシおよびライブラリで、LLM トラフィックのルーティングと変換を行います。

OpenAI Chat、OpenAI Responses、Anthropic Messages の相互間（ストリームを含む）をブリッジします。

4 つのルートタイプが用意されています：パススルー、ランダム、LLM クラスフィア、信号駆動型ステージルーターです。

Prometheus メトリクスにより、モデル呼び出しのレイテンシとは別に、ルーティング自体のオーバーヘッドをモデルおよびティアごとに分離して計測できます。

現在はプレアルファ版であり、本番環境での使用は想定されていません。評価用ツールとして取り扱ってください。

GitHub リポジトリとドキュメントはぜひご覧ください。また、Twitter でフォローや、15 万人以上の ML 専門家が参加する SubReddit に加入、ニュースレターの購読も歓迎します。

Telegram を利用している方へ：今なら Telegram でもコミュニティに参加できます。