Nvidia、NeMo Switchyardでモデルルーティング市場に参入

NvidiaはNeMo Switchyardでモデルルーティング市場に参入した。ゲートウェイ、プロキシ、カスタムルーティングシステムがすでにひしめく領域に、新たなソフトウェアレイヤーを加える動きだ。このリリースはNvidiaの最新モデル発表とともにGoogle Newsにも掲載されたが、争点は単なる製品投入にとどまらない。Nvidiaは、その下層のハードウェアを供給するだけでなく、各リクエストをどのAIモデルが処理するかという判断にも影響力を持とうとしている。

Switchyardは、アプリケーションと複数のモデルバックエンドの間に置かれるオープンソースのプロキシだ。API形式の変換、リクエストの分類、会話アフィニティの維持、利用データの収集、呼び出しごとの異なるモデルへの振り分けを行える。たとえばコーディングエージェントは、計画立案やエラーからの復旧には高度なモデルを使い、通常の編集には効率的なモデルを使うよう設定できる。

この設計は、アプリケーションやエージェントセッション全体に単一モデルを割り当てる主流の慣行に挑むものだ。またNvidiaは、モデルゲートウェイ、クラウドプラットフォーム、オープンソースのルーター、そして企業がすでに運用する社内オーケストレーションシステムとの競争に踏み込むことになる。中心となる問いは、Nvidiaが自動モデル選択を本番業務に十分な信頼性を備えたものにできるかどうかだ。

Nvidiaはモデルエンドポイントの上層へ進出した

Switchyardは、モデル選択をアプリケーション設定から運用ポリシーへと変える。

同社のプロジェクトドキュメントによれば、SwitchyardはOpenAIおよびAnthropicのAPI形式でリクエストを受け付ける。その後、設定済みのバックエンドへ各リクエストを転送する前にルーティングポリシーを適用する。バックエンドには、ホスト型プロバイダー、Nvidia NIMサービス、プライベートエンドポイント、vLLM、あるいはOllamaなどのローカルサーバーを指定できる。

この配置には重要な意味がある。通常、アプリケーションはモデルを直接指定し、開発者はプロバイダーごとの差異をコード内、あるいは基本的なプロキシを通じて処理する。Switchyardはこの2層の間に、プログラム可能な判断ポイントを挿入する。アプリケーションは使い慣れたAPIを使い続け、ルーターがリクエストの送信先を決める。

このソフトウェアには複数のルーティングパターンが含まれる。チームは比較テストのためにトラフィックをランダムに分散したり、LLM分類器を使ったり、カスタムルーティングロジックを作成したり、ステージ認識戦略を適用したりできる。また、最適化よりも決定論的な経路が重要な場合には、ルーティングを迂回して単一モデルを選択することも可能だ。

Switchyardのステージルーターは、今回のリリースで最も重要な要素だ。エージェントの直近の活動から得られるシグナルを評価し、高性能モデル層と効率重視モデル層のどちらを選ぶかを決定する。Nvidiaのルーティングガイドでは、探索、難しい推論、エラー復旧を高性能モデル向けの作業として説明している。より機械的な実行は、効率重視の層へ回せる。

これは、すべてのユーザープロンプトをトピック別に振り分けることとは異なる。エージェントのワークロードには、1つのタスクの中で多数の呼び出しが含まれ、そのタスクの進行に伴って難易度も変わる。コーディングエージェントは、未知のリポジトリを調査している間にはより強い推論力を必要とするかもしれない。計画を立てた後は、ファイル更新や構造化変換にそれほど高い能力を要しない場合がある。

したがってSwitchyardは、セッション開始時だけでなく、セッション内でルーティング判断を下す。設定済みのフォールバックをサポートしつつ、セッションアフィニティにより関連するターンを同じバックエンドに維持できる。この組み合わせは、モデルごとにコンテキストの解釈が異なる場合、無制限な切り替えが継続性を損なうという実務上の問題に対応する。

ルーターはプロバイダー間のプロトコル変換も担う。AnthropicのMessages APIを前提に設計されたクライアントでも、クライアント統合を書き換えることなくOpenAI互換バックエンドに接続できる。Switchyardはリクエストを正規化し、送信先を選択し、ペイロードを変換したうえで、クライアントが期待する形式のレスポンスを返す。

この変換はNvidiaの役割を拡張する。同社はもはやNvidiaホスト型モデル向けに最適化されたエンドポイントだけを提供しているわけではない。Nvidia自身のポートフォリオと競合するモデルを含め、複数プロバイダーのモデル上に位置できるソフトウェアを提供している。

Google Newsの報道は、この動きをNvidiaの注目市場への参入として位置付けた。より重大な変化はアーキテクチャ上のものだ。Nvidiaは、選ばれたモデルを他社が提供する場合であっても、あらゆる推論呼び出しに先立つ判断の一部に自社ソフトウェアを組み込もうとしている。

モデルルーティングがコスト競争の主戦場になった理由

エージェントワークフローにより、1セッション1モデルというアプローチは正当化しにくくなっている。

従来型のチャットボットは、多くの場合、1つのユーザーリクエストに対して1つの回答を生成する。エージェントは、ファイルの調査、ツール呼び出し、計画の修正、エラーからの復旧、出力の検証、最終応答の作成まで行える。各ステップでさらにモデル呼び出しが発生し、会話履歴は増え続ける。

あらゆるステップで利用可能な最も高性能なモデルを使えば、エンジニアリングは単純になる。しかしその場合、JSONの整形、ツール出力の要約、既知の文字列の変更といった作業にも最高水準の推論能力を適用することになる。大規模運用では、こうした繰り返しの呼び出しが、モデルの能力を実際のタスク難易度に合わせる必要性を生む。

逆のアプローチにも問題がある。チームは、タスク種別、長さ、ユーザーグループ、アプリケーション状態に応じてプロンプトを振り分ける手動ルールを書ける。だが、そのルールは、モデルやワークフローが変わるたびにテスト、監視、調整を必要とするインフラとなる。

InfoWorldによるモデルルーティングの分析は、この新たなレイヤーを、プロンプト要件に応じてモデル利用を変化させる手段として説明した。基礎となる論理は単純だ。すべてのリクエストに同じモデルが必要なわけではないが、誰かがその選択を確実に行わなければならない。

Switchyardは、この判断を再利用可能なインフラとしてパッケージ化しようとしている。ステージルーターは、進行中の会話からツール関連のシグナルを調べる。チームは2つのターゲットを設定し、ルーティング動作を定め、モデル層ごとのトラフィックを測定する。

このシステムは不確実なターンに分類器を使えるが、分類は必須ではない。Nvidiaのドキュメントは、すべてのリクエストを分類するために別のモデルを呼び出すと、レイテンシ、コスト、そして新たな障害点が加わるため、まずツールシグナルから始めることを推奨している。分類器は、ルーターが十分な確信を持てないケースに限定できる。

この違いは企業導入において重要だ。モデル消費を減らしても、すべてのターンに別のモデル呼び出しを追加するルーターは、その利点の一部を失いかねない。固定ルールだけに依存するルーターは高速性を維持できるかもしれないが、タスク難易度の変化を見逃す可能性がある。

市場はすでに単純なプロンプト分配を超えている。AIゲートウェイは一般に、レート制限、フォールバック、ログ記録、ポリシー適用、プロバイダー抽象化を提供する。CIOによるAIゲートウェイの解説では、モデルルーティングをより広範な企業向け制御レイヤーの一部として挙げている。

つまり、Nvidiaが作り出そうとしているのは空白のカテゴリーではない。同社は、顧客がすでに商用ゲートウェイ、クラウドネイティブの制御機能、オープンソースプロジェクトを使っている可能性がある競争の激しいレイヤーに参入している。一部の組織は、評価データや業務ルールを軸に独自のプライベートルーティングシステムも構築している。

Switchyardの機会は、マルチモデルアプリケーションの増加にある。企業は、汎用推論モデルを小型モデル、プライベートモデル、専門特化エンドポイントと組み合わせるケースを増やしている。複数の選択肢が存在すれば、選択は開発者の好みではなく運用上の課題になる。

その課題もまた、同じ多様性から生まれる。組織ごとに品質の定義は異なる。顧客サポートでは正しいルートでも、コード生成、セキュリティ分析、契約書レビューでは誤っている可能性がある。コストとレイテンシは測定可能だが、タスクレベルの品質には多くの場合、ドメイン固有の評価が必要となる。

Google Newsでの注目は認知度を高めるかもしれないが、導入はそうした測定に左右される。購入者は、自社のプロンプト、ツール、障害事例、コンプライアンスの境界にわたり、ルーティングが許容可能な成果を生むことを示す証拠を求めるだろう。

Switchyardはポリシー駆動ルーティングを固定モデル選択と競わせる

主たる競争は、Nvidiaと単一のゲートウェイベンダーの対決ではない。動的ルーティングと固定モデルの予測可能性の対決だ。

固定モデルの経路には明確な利点がある。チームは、どのプロバイダーがデータを受け取るか、どの挙動を評価するか、どのコンテキストウィンドウが適用されるか、どこで障害を調査するかを把握できる。モデル更新によって変動は依然として生じるが、リクエスト経路は比較的単純なままだ。

動的ルーティングは、その単純さの一部を効率性と引き換えにする。アプリケーションは同じワークフロー内で異なるモデルを呼び出せる。高性能モデルが難しい推論を処理し、効率的なモデルが定型的なターンを処理する。また、ターゲットが利用不能になった場合や現在のコンテキストを受け付けられない場合には、フェイルオーバーも可能だ。

Switchyardのアーキテクチャは、リクエストの正規化、ルーティング、実行、レスポンス変換を分離している。この分離により、開発者はクライアント向け統合を変更せずにルーティングポリシーを置き換えられる。また、ルーティング判断を隠れたアプリケーションロジックではなく、観測可能なコンポーネントにする。

ステージルーターは、エージェントの実行を変化する条件の連続として扱うことで、さらに踏み込む。直近のツール結果、失敗、会話シグナルが、次のリクエストをどの層に送るかに影響する。このアプローチは、難易度がアプリケーションレベルだけでなくターンレベルにも存在することを認識している。

ソフトウェア保守エージェントを考えてみよう。最初にリポジトリを探索し、関連モジュールを見つけ、馴染みのないテストを解釈するかもしれない。これらの作業はより強い推論力の恩恵を受ける。狭い範囲の修正を特定した後には、明確なパターンに従う複数の編集と検証ステップが続く場合がある。

固定モデル構成では、両方のフェーズを同じエンドポイントへ送る。ステージ認識ルーターなら、探索と復旧にはより高性能なターゲットを確保し、定型的な作業は効率的なターゲットへ移せる。検証に失敗した場合、ルーターは後続の呼び出しを再び高性能層へ戻せる。

この仕組みは、「コーディング」には1つのモデル、「文章作成」には別のモデルを割り当てるより柔軟性が高い。一方で、ルーティングエラーが最終結果に影響する経路も増える。弱いモデルが早すぎる段階で選ばれると、制約を誤解したり、不具合のある編集を行ったり、もっともらしい出力の背後にエラーを隠したりする恐れがある。

その影響は、ルーティングされたターンで常に見えるとは限らない。小さな誤りがコンテキストに残り、後続の呼び出しに影響を与えることがある。より高性能なモデルが根本的な欠陥を見つけずに表現だけを修復した場合、最終回答は一見整合的に見えるかもしれない。

そのため、モデルルーティングは総トークン使用量や平均レイテンシだけで評価することはできない。チームには、ワークフロー全体が成功したかを検証するタスクレベルの評価が必要だ。また、各ルーティング判断を、その結果として生じたツール呼び出し、出力、再試行、最終結果に結び付けるトレースも必要になる。

Switchyardは、レイテンシ、トークン消費量、推定コストに関するリクエスト単位の統計を公開している。ステージルーターのドキュメントでは、層ごとの統計も説明されている。これらの測定により、運用者は各モデルが選択された頻度や、ルーティング動作がどこで変化したかを把握できる。

しかし、可観測性が正しさを自動的に保証するわけではない。ダッシュボードは効率的なモデルが大半の呼び出しを処理したことを示せるが、法的要約が条項を見落としていないかを判断することはできない。その判断には、評価セットまたは別の信頼できる受け入れテストが必要となる。

したがって、固定モデルというアプローチは依然として有力な対抗手段だ。説明、再現、監査が容易である。動的ルーティングが優位に立つのは、効率化による便益が、評価、デバッグ、ガバナンスにかかる運用コストを上回る場合に限られる。

Nvidiaの戦略は、その運用コストを下げることにある。Switchyardがプロトコル変換、共通のルーティングパターン、統計、ランチャーを提供すれば、チームはポリシーと評価に集中できる。これらのコンポーネントの調整が依然として難しければ、組織は重要なワークフローで固定モデルを使い続ける可能性がある。

ルーターの判断が最も弱いリンクになり得る

Switchyardの価値は、選択プロセス自体を別の高価な推論ワークロードに変えることなく、適切なモデルを選べるかどうかにかかっている。

あらゆる組織に共通する万能分類器が、「簡単なタスク」の定義を把握することはできない。短いプロンプトでも専門知識を要する場合があり、長いプロンプトでも機械的な抽出を求めるだけの場合がある。ツールの利用履歴はワークフローの状態を明らかにできるが、次のターンが単純であることを保証するものではない。

ステージを意識したシグナルは有用な文脈を提供する。探索、繰り返される失敗、復旧の試みは、より強力なモデルを正当化することが多い。安定したツール利用や反復的な実装は、定型的なフェーズを示している可能性がある。しかし、実際のエージェント実行が、推論から実行へと常にきれいに進むわけではない。

一見すると定型的な編集でも、大きな影響を伴うことがある。認可ルールの変更は数行で済むかもしれないが、微妙なミスがデータを露出させる可能性がある。長い要約依頼は、出力を人間がレビューするなら低リスクかもしれない。

したがって組織には、予測された難易度だけでなく影響も考慮するルーティングポリシーが必要だ。機微な操作では常に承認済みのモデルを使用することがある。特定のツールには高性能ティアを要求できる一方、低リスクな変換は効率的なルーティングの対象にとどめられる。

プロバイダー間の変換も、別の不確実性をもたらす。OpenAI、Anthropic、および互換APIは、同一のセマンティクスを公開しているわけではない。ツール呼び出し、推論フィールド、ストリーミングの挙動、構造化出力、エラーレスポンスは、プロバイダーによって異なる場合がある。

Switchyardは、別のバックエンドと通信しながらも、クライアントが期待するレスポンス形式を維持することを目指している。この抽象化は有用だが、チームは自らのエージェントが依存する具体的な機能をテストしなければならない。プロトコル互換性は、モデル間の挙動の等価性を意味しない。

コンテキスト上限もルーティングを複雑にする。効率性を理由に選ばれたモデルが、蓄積されたセッションを受け付けられない可能性がある。Switchyardは、stage-routerのドキュメントによれば、コンテキスト超過時に設定可能なフォールバック動作をサポートしている。フォールバックは可用性を維持するが、コスト、レイテンシ、出力特性を変える可能性がある。

さらに、分類器そのものという問題がある。オプションのLLM分類器は不確実なリクエストに役立つ場合があるが、ネットワーク呼び出しが追加される。Nvidiaは、分類器と効率的な対象モデルでプロバイダー容量を共有すると、レート制限への圧力につながる可能性があると警告している。

分類器にも評価が必要だ。簡単なリクエストを高性能ティアへ頻繁に送れば、節約効果は縮小する。難しい作業を効率的なティアへ送れば、品質は低下する。しきい値はバランスを変えるが、トレードオフをなくすものではない。

ルーティングに関する研究は、推論コストを削減しながら品質を維持することに繰り返し焦点を当ててきた。RouteLLMプロジェクトは、学習済みルーターが選好データを用いて、より強力なモデルとより弱いモデルを選択できることを示した。その結果は、より広い論点も浮き彫りにする。ルーターの性能は、学習データ、評価設計、そしてルーティング対象となるモデルの組み合わせに依存する。

ある組み合わせに合わせて調整されたポリシーが、別の組み合わせに自動的に移行できるわけではない。プロバイダーはモデルを更新し、プロンプトは進化し、アプリケーションには新しいツールが加わる。チームには、デプロイ前に一度だけ実施するベンチマークではなく、継続的な評価が必要だ。

このリリースはまだ新しい。公開リポジトリには、既知の問題、活発な開発状況、増え続けるルーティングコンポーネントの一覧が記されている。この公開性は検証と実験を後押しするが、すべての機能が規制対象または高リスクのワークロード向けに成熟していることを示すものではない。

NvidiaはSwitchyardをモデル非依存のインフラとして位置付けているが、そのより広い動機は明確だ。より効率的な推論はエージェントの導入を経済的に成立させ、基盤となるコンピュートシステムへの需要を増やす可能性がある。このルーターは競合プロバイダーを支援しつつ、AI作業の総量を拡大することもできる。

この動機が製品の有効性を損なうわけではない。これは、Nvidiaが推論エンドポイントより上位のソフトウェアへ進出している理由を説明するものだ。同社は、顧客がより多くのモデル、より多くのエージェント、より広範なハードウェア上でより多くの推論を実行することで利益を得る。

したがって、慎重な解釈はGoogle Newsの見出しサイクルよりも限定的であるべきだ。Switchyardは、マルチモデルのトラフィックを実験するための信頼できるツールキットを提供する。その本番環境での価値は、ルーティングエラーが許容範囲内に収まることを示す、ワークロード固有の証拠に依然として左右される。

Nvidiaはフルスタック推論戦略を拡大している

Switchyardは、モデル選択を、推論運用スタックのより多くを制御しようとするNvidiaの大きな取り組みにつなげる。

NvidiaのAIにおける地位はアクセラレーターから始まり、ネットワーキング、最適化ライブラリ、モデル提供ソフトウェア、エンタープライズ向けパッケージ、オープンモデルへと拡大してきた。ルーティング層は、そのスタックをアプリケーション境界により近づける。

同社はすでに、標準化されたエンドポイントを通じてモデルをパッケージ化・提供するNvidia NIMを提供している。Dynamoは、ワーカー間における分散推論のスケジューリングとリクエスト配置に対応する。NeMoはモデル開発とカスタマイズを支援する。OpenShellはエージェントワークロード向けの制御されたランタイムを提供する。

これらのシステムは異なるルーティング問題を解決する。DynamoのKV-aware routingは、再利用可能なキャッシュ状態とアクティブな負荷を考慮しながら、適切なワーカーを選択する。Switchyardは、アプリケーションレベルのポリシーに従ってモデルまたはバックエンドを選択する。

この区別は重要だ。インフラのルーティングは、効率的な提供のためにリクエストをどこで実行すべきかを問う。モデルルーティングは、どのモデルがリクエストを受け取るべきかを問う。デプロイメントは両方の判断を使える。Switchyardがモデルを選び、その後に提供システムがワーカーを選択する。

その結果、Nvidiaが管理するコンポーネントの連鎖はさらに長くなる。企業は、NeMoツールでエージェントを構築し、呼び出しをSwitchyard経由でルーティングし、NIMを通じてオープンモデルを提供し、Nvidiaハードウェア上でDynamoにより推論をスケジュールできる。

この戦略が重要であるために、NvidiaがすべてのリクエストでNemotronモデルを使う必要はない。Switchyardが一般的な制御点になれば、Nvidiaは開発者がマルチモデルシステムを評価・運用する方法に影響力を持つ。ルーティングの選択を、自社の提供・可観測性スタックにも結び付けられる。

これが、このローンチが生み出す真の競争圧力である。ゲートウェイベンダーは、主要AIハードウェアサプライヤーによる潤沢な資金を持つオープンソースの新規参入者に直面する。クラウドプロバイダーは、自社ネイティブのルーティング・ガバナンス層がなぜより大きな価値を提供するのかを示さなければならない。モデル企業は、混在デプロイメント内で自社エンドポイントを容易に評価できるようにする必要がある。

オープンソースプロジェクトは別の比較に直面する。多くはすでに統一API、フォールバックロジック、負荷分散、モデル選択を提供している。Switchyardは、単にリクエストを転送できるかではなく、ルーティング品質、エージェント認識、プロトコル対応範囲、運用上の明確さで競争しなければならない。

Apache 2.0ライセンスにより、実験への障壁は下がる。チームはルーティングコードを検証し、カスタムポリシーを追加し、アプリケーションの近くにプロキシをデプロイできる。この柔軟性は、ホスト型ゲートウェイにすべてのプロンプトを監視させたくない組織にとって魅力的かもしれない。

ただし、セルフホスティングは責任を移転する。運用者は認証情報を保護し、更新を管理し、ログを保持し、ルーティング動作を監視し、プロバイダー統合を検証しなければならない。オープンソースはシステムを誰が制御するかを変えるが、安全に運用するために必要な作業をなくすものではない。

Nvidiaの最大の強みは、単一のルーティングアルゴリズムではなく統合にあるかもしれない。同社はSwitchyardを、モデル、推論サーバー、エージェントランタイム、ハードウェアテレメトリーと接続できる。より小規模なルーターベンダーは、より広範なプロバイダー中立性を提供できるかもしれないが、このようなエンドツーエンドのエンジニアリング能力には及ばない可能性がある。

顧客にとっての危険は、不要なスタック集中である。開発、ルーティング、提供、コンピュートを一社のベンダーで統一すれば、サポートを簡素化できる。一方で、個々のコンポーネントがオープンソースのままであっても、切り替えコストを高める可能性がある。

Switchyardが複数のプロバイダーをサポートしていることは、この懸念を和らげる一助となる。その有用性は、Nvidiaがプロジェクトを拡大する中で、これらの統合が一級の扱いを維持できるかにかかっている。顧客はNvidia以外のバックエンドも、Nvidiaがホストするものと同じくらい慎重にテストすべきだ。

同社の動きは、モデルルーター市場に決着をつけるものではない。ルーティングが戦略的インフラになったことを確認するものだ。どのモデルがリクエストに応答するかという判断は、いまやコスト、レイテンシ、信頼性、データ処理、プロバイダーに対する交渉力に影響を及ぼす。

Google Newsの読者が次に注目すべきこと

Switchyardが本番インフラになるのか、それとも興味深い開発者向け実験にとどまるのかを示すシグナルは3つある。

第1のシグナルは、ワークロードレベルの評価だ。Nvidiaと早期導入者は、ルーティング判断を完全なタスク成果へ結び付ける結果を公表する必要がある。エージェントがなお正確に割り当てを完了できる場合にのみ、トークン消費量の削減は意味を持つ。

有用な証拠には、複数のモデル組み合わせにわたる失敗率、復旧動作、レイテンシ分布、品質比較が含まれる。また結果は、ルーターのオーバーヘッドと、呼び出しを効率的なモデルへ移すことで生じる節約を区別すべきだ。

独立したテストが強力なタスクレベルの結果を再現できれば、Nvidiaの主張はより強くなる。結果が狭いベンチマークや慎重に選ばれたモデル組み合わせに依存するなら、重要なワークフローでは固定モデルのデプロイメントが引き続き魅力的だろう。

第2のシグナルは、Nvidia自身のサービスを超えた統合だ。Switchyardはすでに、OpenAI、Anthropic、OpenAI互換エンドポイントのサポートを説明している。本番利用者は、ツール呼び出し、ストリーミング、構造化レスポンス、コンテキスト処理、エラーが、これらのプロバイダー間で信頼できる状態を保てるかを検証するだろう。

広範で適切に保守された統合は、Nvidiaのモデル非依存という主張を支える。競合バックエンドで挙動にばらつきがあれば、その主張は弱まり、中立的なゲートウェイの魅力が増す。

第3のシグナルは、エンタープライズの制御だ。購入者は、成熟したポリシー適用、監査証跡、認証情報の分離、デプロイメント指針、評価ワークフローを求める。また、機微なリクエストを承認済みモデルに固定する明確な手段も必要となる。

強力なガバナンス機能があれば、ルーティングは開発者の最適化からプラットフォームエンジニアリングへと進む。制御が弱ければ、導入は実験、社内ツール、低リスクのエージェントに限定されるだろう。

これらのシグナルは、ダウンロード数や見出しよりも重要だ。Google NewsはNvidiaの参入を増幅できるが、ルーティング判断が正しかったかを立証することはできない。その証明は、変化するモデル、ツール、ビジネス上の制約のもとで行われる実際のエージェント実行から得られる。

開発者にとって、直近の行動は実践的だ。範囲を限定したワークフローを1つ選び、ルーティング前に成功を定義し、Switchyardを固定モデルのベースラインと比較する。レイテンシやモデル利用状況と並行して、完全なタスク成果を追跡する。

エンタープライズの購入者は、誰がルーティングポリシーを所有し、組織が悪い判断をどれほど迅速に検知できるかを問うべきだ。手戻りを生み、コンプライアンスを弱め、エラーを隠すのであれば、安価な呼び出しは安価ではない。

Nvidiaは、モデルルーティングをニッチな抽象概念として片付けにくいものにした。今後数カ月で、Switchyardが動的なモデル選択をロードバランシングと同じくらい運用上当たり前のものにできるのか、それともルーターそのものが依然として最も信頼しにくいモデルであり続けるのかが明らかになるだろう。