本記事はAIを利用して作成した技術解説・実装例です。掲載するコードや手順は一次情報を基に構成していますが、筆者による実機での動作確認は行っていません。環境やバージョンによって動作が異なる場合があります。
NVIDIA Personal AI Router（PAIR）は、ローカルネットワーク上の互換システム間で独立した推論リクエストを分散させ、マルチエージェント環境におけるボトルネックを緩和するための仮想推論ルーターです。OllamaやLM Studioといった既存のインターフェースと連携し、エージェント側やハーネス側の変更を必要としない点が特徴です。本記事では、公式技術ブログの一次情報を基に、NVIDIA PAIRの構成要素や動作の仕組みを整理して解説します。
flowchart TD
Agent["AI Agent / Harness"] -->|Ollama/LM Studio API Request| PAIR["NVIDIA PAIR Proxy"]
PAIR -->|mDNS Discovery & mTLS Routing| NodeA["Local Node 1: Ollama"]
PAIR -->|mDNS Discovery & mTLS Routing| NodeB["Local Node 2: LM Studio"]
NodeA -->|Inference Execution| PAIR
NodeB -->|Inference Execution| PAIR
PAIR -->|Stream Response| Agent
NVIDIA PAIRとは何か
NVIDIA PAIRは、家庭内やローカル環境にあるAIの計算リソースを最大限に活用するための仮想推論ルーターです。新しい推論エンジンそのものではなく、OllamaやLM Studioといった既存のエンジンが選択されたマシン上で実行される仕組みを前提としています。
参加しているシステムの発見、各システムがリクエストを受け入れる準備ができているかの追跡、独立したジョブのスケジュール、そして生成された応答を元のアプリケーションへ返却する役割を担います。エージェントはこれまで通りのローカルインターフェースを通じてリクエストを送信し、PAIRがプロキシ経由でエンジンやモデルの要件を識別し、適切なノードを1つ選定します。そのノードが最初から最後までリクエストを実行し、応答をPAIR経由で返します。
特徴として、以下の3点が挙げられます。
新しいAPIの不要: すべてのエージェントハーネスに新しいクラスタAPIの統合を求めるのではなく、互換性のあるOllamaおよびLM Studioのインターフェースをプロキシします。
弾力的なクライアント: 互換性のあるシステムは、利用可能なときに容量を提供し、電源を切ったり休止状態にしたりするなどして必要に応じて離脱できます。
ローカル制御: プロンプト、データ、推論トラフィックをユーザーの既存のローカルネットワーク内に保持するように設計されています。
マルチエージェントのローカル推論における課題と解決アプローチ
AIプロシューマーが主要なNVIDIA RTX AI PC上でローカルエージェントを実行している場面を想定します。エージェントがリサーチ、コーディング、その他のタスクを受け取ると、それを複数のサブエージェントに分割します。
各ワーカーが問題の一部を探索し、他のワーカーが証拠の検証や結果の組み立てを行います。ユーザーの視点では1つのタスクですが、推論レイヤーでは数十件の独立したモデル呼び出しに発展する場合があります。もしこれらすべてが1つのローカルエンジンをターゲットにすると、同じ実行スロットを奪い合い、キューが膨れ上がります。
PAIRは、エージェントの拡張に合わせて推論レイヤーを広げることを可能にします。サブエージェントからのリクエストの一部はプライマリPCで実行し、別の部分はネットワーク上の別のペアリング済みノードで実行できます。ワークロードに十分な並列性がある場合、準備の整ったシステムを増やすことで、キューイングの発生を抑えてエンドツーエンドの完了時間を短縮できます。
なお、PAIRは1つの推論リクエストを複数のGPUにまたがって分割実行するわけではありません。すべてのリクエストは1つの適格なノードに割り当てられ、そのライフサイクルを通じてそのノードに留まります。
ホームAIクラスターの弾力性管理
家庭内のAIクラスターは、専用のデータセンターとは異なります。ゲーミングPCはゲームのプレイで忙しくなることがあり、ノートPCはスリープ状態になるかネットワークから離れることがあります。ワークステーションには特定のモデルが存在しても、別のマシンには存在しない場合もあります。
PAIRは、こうした変動する条件を前提に設計されています。ローカルシステムをmDNSで発見し、プライベートネットワーク上で対応デバイスをペアリングし、どのノードが新しい作業を受け入れられるかのライブビューを維持します。クライアントノードは、準備ができたときに利用可能なプールに参加し、必要に応じて離脱できます。
リクエストごとのスケジューリングでは、以下の要素が考慮されます。
ペアリングされたノードがオンラインかつ準備完了状態であるか
サポートされている推論エンジンが有効になっているか
要求された正確なモデルが存在しているか
アクティブなジョブを含む、現在のノードおよびエンジンのワークロード
グラフィックス集約型のアプリやツールが実行されているかといった既存のGPU利用率
デモ事例に見る処理の流れ
一次情報では、Hermes DesktopとOllamaを用いた5つのサブエージェントによるデモンストレーション事例が紹介されています。タスクでは、Hermesが合成された家庭の受信トレイを分析し、日曜日のリセット計画を作成します。
Hermesは分解、委任、統合を担当し、PAIRは推論ルーティングを制御し、OllamaはPAIRが選択したノード上で各リクエストを実行します。
Qwen 3.6 35B A3Bモデルを用いた検証では、1台のNVIDIA RTX SparkノートPC単体で実行した場合に平均18分かかったワークロードが、RTX SparkノートPC、DGX Spark、RTX 5090を含む3デバイスのPAIRクラスター構成では平均8分48秒で完了したことが示されています。ただしこれは非公式かつ特定の構成におけるデモであり、一般的なベンチマークや線形スケーリングを約束するものではありません。
NVIDIA PAIRの内部動作ステップ
NVIDIA PAIRの動作は、複数のステップを経て行われます。
1. ローカルネットワーク発見による近隣システムの検出
対応するWindows、MacOS、またはLinuxシステムにPAIRをインストールした後、mDNSを使用して近隣システムを自動的に検出します。必要に応じてIPアドレスでノードを追加することも可能です。ユーザーが安全なペアリング要求を承認することで、信頼されたローカルノードのセットが構成されます。
すべてのノード間の通信は、安全な接続とペアリングが確立されるまでブロックされます。接続が確立されると、通信はmTLSと生成された証明書によって暗号化されます。
2. 推論エンジンとモデルの準備
参加する各ノードは、OllamaまたはLM Studioといったサポート対象のローカル推論エンジンを実行します。PAIRは、エンジンのインストール支援やモデルのダウンロードを支援し、複数マシンの準備作業を軽減します。必要なエンジンが有効であり、要求された正確なモデルが利用可能な状態にあるノードのみが、リクエストの適格ノードとなります。
3. 互換ローカルインターフェースのプロキシ
互換性のあるアプリケーションは、PAIRによってプロキシされたローカルエンドポイントを通じてリクエストを送信します。エージェントハーネスは、個別のマシンを個別に検出して統合するのではなく、使い慣れたインターフェースをそのまま利用できます。
4. 適格ノードのスケジューリングと応答返却
スケジューラーは、準備状況、サポートされているエンジンの状態、要求されたモデルの存在、ジョブ負荷などの最新情報に基づいてペアリングされたシステムをフィルタリングします。適格なノードを1つ選定し、そのシステムのPAIRルーターがリクエストをローカル推論エンジンへ渡します。
選択されたエンジンがリクエストを実行し、応答は同じローカルインターフェースを経由して元のアプリケーションへストリーミングされます。ジョブおよびメトリクスビューでは、どのノードがどのルーティングされたリクエストを処理したかを確認できます。
利用時の注意点と向き不向きのワークロード
PAIRは、複数の独立したリクエストを同時に処理するマルチエージェントアプリケーションや、並行して動作するローカルAIツールにおいて高い効果を発揮します。
一方で、GPUの結合やVRAMのプールによる単一アクセラレータ化、1つのモデルのシャーディングや単一の推論リクエストの分割実行は行いません。高度に順序化されたタスクや、1つの長いモデル呼び出しに依存するワークロードでは恩恵が小さくなる場合があります。
コメント