1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@M_Ozu
in

NVIDIA PAIR(Personal AI Router)は何をルーティングするのか — LiteLLM / Switchyard との違いから「役割」を整理する

1
Posted at

本記事では実機検証の前段として、一次ドキュメントと公開リポジトリからNVIDIA PAIRのアーキテクチャと狙いを紐解き、既存のルーター群との住み分け・全体構造を整理します。

はじめに

2026年9月、NVIDIAが「PAIR(Personal AI Router)」というソフトウェアをベータ公開しました。同じLAN上のPCを束ねて、AI推論リクエストを空いているマシンに振り分ける——いわば手元のマシン群を小さな推論クラスタに変えるツールです。

「ルーター」という名前から、LiteLLMやNVIDIA LLM Routerを思い浮かべた人もいると思います。同じ「ルーター」でも、ルーティングしている対象がそれぞれ違います。なお本記事は2026年9月時点の情報です。PAIRはベータ版(0.1.1)、NeMo Switchyardはv0.2系(リポジトリ自身がpre-alphaで本番利用非推奨と明記)と、いずれも活発に開発中のソフトウェアのため、仕様は今後変わる可能性があります。一次情報へのリンクは末尾にまとめています。

NVIDIA PAIRとは何か

PAIRは公式ブログで「virtual inference router」と呼ばれています。同じLAN上にあるRTX搭載PC・DGX Spark・Mac(M4以降)を発見してペアリングし、AI推論リクエストを空いているマシンに振り分けます。GitHubでコードが公開されているオープンソースプロジェクトです。

まず「何でないか」から

PAIRの理解は、公式が明言している「やらないこと」から入るのが早道です。

  • 推論エンジンではない — モデルを実行するのはあくまで各マシン上のOllamaまたはLM Studio。PAIRは実行しない
  • GPUを束ねて1つの仮想GPUにするものではない — VRAMのプーリングはしない
  • 1つのリクエストを複数マシンに分割しない — モデルのシャーディングもしない。1リクエストは1ノードに割り当てられ、最後までそこで実行される

つまりPAIRが提供するのはワークロードレベルの並列性です。1つの重い推論は速くなりません。速くなるのは「独立したリクエストが同時にたくさん飛ぶ」ワークロード、つまりマルチエージェントです。リードエージェントがタスクを分解して複数のサブエージェントに委任すると、推論層では数十の独立したモデル呼び出しが発生し、1台のGPUの前に行列ができる。この行列を、LAN上の空きマシンに捌かせるのがPAIRの仕事です。

仕組み:5つのステップ

公式ブログの解説を構造化すると、動作は次の5段階です。

  1. 探索 — mDNSでLAN上の対応マシンを自動発見(IP直指定も可)。ユーザーがペアリング要求を承認して初めて信頼ノードになる
  2. セキュア接続 — ペアリング確立まではノード間通信をブロック。確立後はmTLSと生成証明書で通信を保護
  3. プロキシ — プロキシ — ドキュメント/Playbookによれば、アプリやエージェントハーネス側で設定変更を不要にするため、PAIRがOllama互換（およびOpenAI互換）のエンドポイントを提供してトラフィックを中継する設計をとっています。アプリやエージェントハーネスは従来のエンドポイントを見ているだけでよく、設定変更が不要。公式PlaybookによればOllama互換に加えてOpenAI互換のプロキシエンドポイントも提供される
  4. スケジューリング — リクエストからエンジンとモデルの要求を読み取り、「ノードがオンラインか」「エンジンが有効か」「要求されたまさにそのモデルが置いてあるか」「実行中ジョブ数」「GPU使用率(ゲーム等のグラフィックス負荷が走っていないか)」で候補を絞り、1ノードを選ぶ
  5. 応答返却と可視化 — 選ばれたノードのエンジンが実行し、PAIRが同じインターフェース経由でストリーミング返却。Jobsビューでどのリクエストがどのノードで動いたかを確認できる

なお、モデルは全ノードで同一である必要はなく、モデルの所在に応じてルーティングされます(同じモデルを複数ノードに置けば、そのモデルの候補プールが広がる)。

PAIRは何を見据えた製品か

名前がPersonalなのだから、個人向けというのはわかるが、実際どんな使われ方に落ち着きそうかが気になる。データセンター規模の「どこで動かすか」にはDynamo(分散推論サービング)やRun:ai(GPUスケジューリング)という道具がすでにあり、PAIRの前提はその正反対です。家庭のマシンは行儀よく待機していない。ノートPCはスリープで消え、デスクトップはゲームにGPUを取られ、入っているモデルもマシンごとにバラバラ。PAIRはそれを矯正せず、余力があるときだけ借りる(公式の言うelastic clients)。専用クラスタを組み上げるのではなく、日常の使われ方の隙間に推論を滑り込ませる設計です。信頼性や可用性を確保するための仕組みではなく、単純に余ったリソースを効果的に使うための仕組み——そう捉えるのが正確だと思います。

対象機器のリストを見ると、GeForce RTX 20シリーズ以降、RTX PROワークステーション、DGX Spark、そしてApple M4以降のMac。家庭に複数のGPUリソースがある前提、ってそんな家庭がどれくらいあるのか、とは思いますが、「ゲーミングPCとMacBook」の組み合わせならなくはない気もするけど。手持ちのマシンが束になって効くなら2台目を持つ価値も上がるわけで、個人・プロシューマー市場のローカルAI需要をさらに拡大するための施策、と読むのが自然な気はする。

もっとも日本で、より現実味があるのはGPU付きマシンが自然に複数台転がっている場所といえば、小規模オフィス、大学の研究室、専門学校といった、企業や教育機関のLAN内かもしれない。「落ちてたら使わないだけ」という割り切りは、クリティカルパスの外で並列ジョブの待ち行列を捌く使い方と相性がよく、夜間や長期休みにマシンが遊んでいる大学などはむしろ好条件です。どの業務データをどのマシンに流すかは考えどころですが、それも含めて検証して見極める価値のあるツールだと思います。

公式の構成図を見て引っかかったこと

公式ブログの構成図を見て一つ引っかかったことがあります。図ではエージェントがPAIRを直接呼んでいます。あれ、LiteLLMのようなゲートウェイや、モデルを選ぶルーターはどこに挟むんだろう、と。

この違和感を解くには、それぞれの「ルーター」が何をルーティングしているのかを先に整理する必要があります。

他の「ルーター」は何をルーティングしているのか

PAIR登場以前、ローカル・セルフホストLLMの「ルーティング」は概ね1台(または1クラスタ)の中の話でした。典型的にはこうです。

LiteLLMはOpenAI互換のゲートウェイで、本業は統制です。仮想キーの発行、チームごとの予算とレート制限、利用ログ、ガードレール連携。ルーティング機能も持ちますが、それは主にフォールバックや負荷分散という「運用のためのルーティング」です。

NVIDIA LLM Routerは「このプロンプトはどのモデル向きか」を判断する専門家でした——そして過去形で書いたのは、リポジトリに正式にdeprecation noticeが出たからです。後継はNeMo Switchyard。LLM Router v1/v2と同じパターンを実装しつつ、拡張性・性能・NeMoプラットフォームとの統合を深めた、とアナウンスされています。
「今このプロンプトに、どの賢さの・いくらのモデルを充てるか」というモデル選択のルーティングが、独立したOSSレイヤーとして整備されている現在の状況となる。

3つのルーターは競合ではなく、直交する層

ここまでを並べると、3つの「ルーター」が全く別の問いに答えていることが見えてきます。

層 問い 担当
モデル選択のルーティング このリクエストはどのモデルで処理すべきか Switchyard (旧LLM Router)
統制のルーティング このリクエストは送ってよいか、誰の予算で、記録はどうするか LiteLLM等のAI Gateway
物理のルーティング 選ばれた処理はどのマシンで動かすか PAIR

競合ではなくそれぞれの役割に応じて、組み合わせて使うことになります。では実際にどう繋げるのがよいのか。

SwitchyardのリポジトリにはLiteLLMのRouter/プロキシ用のルーティングプラグインが同梱されていて(examples/litellm)、READMEには「Switchyardはあなたが既に持っているゲートウェイの中で動く」と明記されています。設計も面白くて、埋め込み用ライブラリ(switchyard-libsy)は自分ではモデルを呼びません。アルゴリズムがターゲットを決めるだけで、実際の呼び出し・リトライ・認証情報はホストのゲートウェイ側が握ったまま。「どのモデルにすべきか」という判断だけを差し込み、「送ってよいか・どう送るか」という執行はゲートウェイが保持する——役割の分業が、プラグインの境界そのものに刻まれています。

なお構成を考えるときの補足として、3つのルーターはいずれも「判断と中継」が仕事なので、それ自体はGPUを必要としません(SwitchyardでLLM分類器を使う構成にした場合の判定用モデルだけが例外)。GPUが要るのは末端の実行ノードだけです。「層が3つあるからマシンが3台要る」わけではなく、小規模なら全部を1台に同居させて構いませんし、複数台構成でも判断側はCPUだけの常設マシン1台に集約できます。

引っかかりの答え:判断は、エージェントの設定に折り畳まれていた

答えはシンプルで、公式図のエージェントはPAIRをわかりやすく説明するために、モデル名もエンドポイントもエージェントの設定ファイルに書き込み済みの前提なのだと思う。モデル選択の層は消えたのではなく、エージェントの設定の中に入っている。統制も同じで、「使うのは自分だけ」という暗黙の前提(だから認証もクォータも要らない)が入っています。

だから、ゲートウェイやモデル選択の層を挟むとは、この設定に書かれた判断を外に出すことです。モデル名の決め打ちを外に出せばSwitchyard、「誰が使ってよいか」を外に出せばLiteLLMになる。並び順はアプリ→ゲートウェイ(中でSwitchyardがモデルを決める)→PAIR→各ノードのエンジン。PAIRはエンジンのふりをするプロキシなので、公式図で「エージェント」が座っていた席にゲートウェイが座るだけで済み、PAIRからは呼び出し元の違いは見えません。

この順序に選択肢はありません。Switchyardが「どのモデル名か」を決め、PAIRが「そのモデル名を持つノード」を探す——モデルの決定は配置より前にいないと成立しないからです。公式図の最小構成も、決定が「設定」という形で先に済んでいるだけで、同じ順序を守っています。
ちなみに、この組み合わせを実際に繋いだ公式の参照構成や公開された検証事例は、執筆時点では見当たりませんでした。PAIRはOpenAI互換のエンドポイントも提供するので互換性の上では成立しそうですが、まだ手を動かす余地が残っている部分です。検証環境を準備するのが大変そうだけども。

まとめ

  • PAIRは推論エンジンでもGPU束ねでもなく、マシンを選ぶルーター。マルチエージェントの並列リクエストをLAN上の空きマシンに配る
  • 対象機器と設計思想からみて、PAIRはデータセンター向けではなく個人・プロシューマーのローカルAI需要を広げる施策に見える(DC側にはDynamo等の別系譜がある)
  • LLM RouterはSwitchyardにdeprecatedされた。モデルを選ぶルーターは独立したOSSレイヤーとして急速に成熟中
  • LiteLLM等のゲートウェイは送ってよいかを決めるルーター。3つは競合ではなく直交する層で、統制層にモデル選択層を組み込むLiteLLMプラグインは公式提供済み。物理層(PAIR)との接続は互換性の上では成立しそうだが、公開された検証事例はまだ無い
  • 「パーソナル」と名乗ってはいるが、余剰マシンで並列ジョブを捌く用途なら、企業や教育機関のLAN内でも案外成立しそう

「ルーター」という同じ名前に惑わされず、モデル選択・統制・物理のどの層の話をしているのかを分けて考える——それが、この賑やかな領域で設計を見失わないための一番シンプルな指針だと思います。

参考リンク(一次情報)

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?