AIリクエストは詰まっているのに、隣のPCのGPUは遊んでいる
メインPCでコーディングエージェントとドキュメント要約を同時に動かすと、一方のリクエストが終わるまで、もう一方は待つことになります。机の横に以前使っていたゲーミングPCやノートPCが起動していても、アプリケーションごとに接続先アドレスとモデルを別々に管理するのは手間がかかります。
NVIDIA PAIRは、このような状況で複数のコンピューターを1つのローカル推論窓口の背後に接続します。アプリは現在のコンピューター上の1つのエンドポイントにリクエストを送り、PAIRは要求されたモデルを実行できるノードを1台選んでジョブを送ります。現在はOllamaとLM Studioに対応しています。
ただし、PCを2台接続しても巨大なGPUが1枚できるわけではありません。PAIRが減らすのは、複数の独立したリクエストが1つのGPUの前で待つ時間です。以下では、まずモデルを2台目のPCだけに用意してリモート実行を確認し、その後1台目のPCにも同じモデルを追加して同時リクエストを分散します。
先に確認すること: VRAMは結合されません
PAIRでは、1つのリクエストは選択された1台のノードで最初から最後まで処理されます。GPUメモリのプーリング、複数GPUを論理的に1枚にする機能、モデルシャーディング、進行中リクエストのノード間分割には対応していません。
| やりたいこと | PAIRとの適合性 | 理由 |
|---|---|---|
| コーディング・検索・要約エージェントの独立したリクエストを同時に処理する | 適している | 各リクエストを実行可能な別々のノードに配置できる |
| 複数のローカルアプリの推論キューを減らす | 適している | OllamaおよびOpenAI互換のプロキシ経路を提供する |
| 24GB GPU 2枚で48GBモデルを実行する | 不適 | VRAMを結合せず、モデルをノードに分割してロードしない |
| 1つのリクエストの生成速度をPC台数分だけ上げる | 不適 | 単一リクエストは1台のノードだけで実行される |
NVIDIAの公開デモでは、Qwen 3.6 35B A3Bを使う5つのサブエージェントは、RTX SparkノートPC 1台では平均18分、そのノートPCとDGX Spark・RTX 5090を組み合わせた3台では平均8分48秒でした。ただしNVIDIAも、これを特定構成での非公式デモとして説明しています。繰り返し回数と時間のばらつきも公開されていないため、一般的な2倍高速化の約束として受け取るべきではありません。
両方のPCではなく、実行候補に同じモデルが必要です
コンピューターがリクエストを受け取るには、オンラインであり、OllamaまたはLM Studioが実行中で、リクエストに記載された正確なモデルを持っている必要があります。同じモデルを複数の実行ノードに複製すると、そのモデルのリクエストを受け取れる候補が増えます。
反対に、クラスター内のすべてのコンピューターにエンジンとモデルが必要なわけではありません。アプリを実行するコンピューターはPAIRクラスターに参加してローカルプロキシを提供するだけでよく、GPUや独自の推論エンジンがなくても構いません。エンジンとモデルは、リクエストを実際に処理するノードに用意します。
最初の実験は、近い仕様の2台と小さな共通モデルから始めてください。
現在のスケジューラーは主に待機中のジョブと緩やかに補正されたGPU使用率を見ますが、GPUモデル、利用可能メモリ、レイテンシー、モデルがメモリにロード済みか、リクエストのコストは考慮しません。仕様差の大きいPCを混在させると遅いノードが選ばれ、かえって原因を追いにくくなる場合があります。
PAIR自体はWindows 11、Linux、macOSでx64とarm64のノードを混在させられ、Windows on ARMのサポートは実験的です。配布ファイルはWindows向けの.exe、Debian系Linux向けの.deb、macOS向けの.dmgとして提供されています。ただし、各ノードでエンジンと選択したモデルが実際に動くかは、そのOS、GPU、ドライバー、メモリ条件で別途確認する必要があります。
公式ダウンロードで2台を接続してみます
必要なものは、同じ信頼できるローカルネットワークに接続されたコンピューター2台、モデル保存用の空き容量、ダウンロード用のインターネット接続です。リクエストを実行するPCには、選択したエンジンとモデルを動かせるメモリが必要です。画面のないサーバーではターミナルインターフェースを使えますが、実行ノード表示など一部機能に制限があるため、最初の検証にはデスクトップアプリが便利です。
- NVIDIA PAIR公式ページから各OS用のファイルをダウンロードします。 Windowsではインストーラーを実行し、macOSでは
.dmg内のアプリをApplicationsへ移動します。Debian系Linuxではダウンロードディレクトリでsudo apt install./NVPAIR-Setup-*.debを実行します。その他のLinux系ではソースビルドが必要になる場合があります。 - 各コンピューターでPAIRを開きます。 初回起動時の設定では、OllamaまたはLM Studioをインストール・起動するか、すでに実行中のエンジンを選択できます。1台目のPCはリクエストを送るクライアントとしてだけ使えるため、自前のエンジンは不要です。2台目のPCでは、実際にリクエストを処理するエンジンを起動し、Overviewにそのノードとエンジン状態が表示されることを確認してください。
- 1台目のPCから2台目のPCを招待します。 Add nodeまたはSettings → Cluster → Available nodesを開き、相手のPCを選びます。1台目のPCに表示された6桁のPINを、招待されたPCに入力します。自動検出に失敗した場合は、IPアドレスで直接追加できます。制限の厳しいファイアウォールを使っている場合は、ローカルLANでmDNS検出用のUDP 5353とノード間サービス用のTCP 14318~14323を許可し、使用するエンジンのEndpointsまたはEngine settingsに表示されるプロキシポートにも、ペアリング済みノード間で到達できるよう設定してください。既定のポートはOllamaが11434、LM Studioが1234ですが、画面に表示された実際の値を基準にします。IPで直接追加する場合、mDNS検出には依存しませんが、TCP 14318~14323とエンジンのプロキシポートは依然として必要です。接続後は、Connected nodesまたはOverviewに両方のデバイスが表示されるはずです。
- 最初の検証用モデルは2台目のPCだけに用意します。 Overviewで2台目のPCを選択し、Engine settings → Add modelへ移動して、そのPCのメモリに余裕を持って収まる小さなモデルをダウンロードします。エンジンが明示的なロードを必要とする場合は、Loadもクリックします。実行先を2台目のPCに限定するため、まだ1台目のPCには同じモデルをインストールしないでください。
- アプリを実行する1台目のPCのEndpointsから、実際のアドレスをコピーします。 Ollamaプロキシは通常
http://127.0.0.1:11434、LM Studioプロキシは通常http://127.0.0.1:1234を使いますが、ポート競合や設定変更の可能性があります。既定値を直接入力せず、Endpoints画面に表示されたアドレスを使ってください。 - まずモデル一覧を確認してから、チャットリクエストを送ります。 コピーしたアドレスの
/v1/modelsを呼び出し、2台目のPCに用意したモデルが見えるか確認します。続いて、OllamaとLM Studioが共通して対応するOpenAI互換の/v1/chat/completionsリクエストを送ります。curl <PAIR_BASE_URL>/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"<MODEL_NAME>","messages":[{"role":"user","content":"ルーターの役割を一文で説明してください。"}]}' - OverviewのJobsで2台目のPCが実行したことを確認します。 ジョブカードのRan onまたはRunning onに2台目のPCが表示されれば、1台目のPCのループバックエンドポイントへ送ったリクエストが別ノードで実行されたことになります。すでに同じモデルを両方にインストールしている場合は、1台目のPCからそのモデルを削除するか、1台目のPCを実行候補から外してから再度リクエストし、実行先を確実に検証してください。
- リモート実行を確認した後、1台目のPCにも同じモデルを追加します。 これで1台目のPCが実行条件を満たすなら、同じエンジンに完全に同じモデルタグをインストールし、必要に応じてLoadします。独立したリクエストを複数同時に送った後、Jobsで1台目と2台目のPCの両方が実行ノードとして記録されているか確認すれば、負荷分散の実験まで進められます。
別のPCのポートへ直接接続してはいけません
PAIRの平文HTTP推論エンドポイントは、そのコンピューターのループバック、つまり127.0.0.1でのみリクエストを受け付けます。別のLANコンピューターから、そのPCの11434や1234ポートへ直接接続する構成ではありません。アプリを実行するコンピューターにもPAIRをインストールし、そのコンピューターのローカルエンドポイントを使う必要があります。
ペアリング済みノード間の主要な通信には、認証済みチャネルと相互TLSが使われます。ただし、6桁のPINは初期信頼設定用の一時コードであり、一部のノード検出補助(discovery enrichment)およびノード情報トラフィックでは平文HTTPが使われる可能性があります。共有オフィスネットワークや公衆Wi-Fiではなく、信頼できる家庭または個人オフィスのネットワークで接続し、PAIRやエンジンのポートをインターネットに公開しないでください。
画面が止まった場合は、まずサービスとポートを確認してください。
OverviewがLoading...のままなら、Settings → Serviceで状態とログを確認してからサービスを再起動します。EndpointsにNo engines are runningと表示される場合は、実行候補ノードのエンジンを先に起動してください。別のプロセスがプロキシポートを使用している場合は、同じ画面でPAIRポートを変更するか、競合するプロセスを終了する必要があります。
成功基準は最高速度ではなく、重なったリクエストの待ち時間です
検証時に1リクエストの毎秒トークン数だけを測ると、PAIRの効果を見逃します。同じ独立プロンプトのセットを1ノードと複数ノードでそれぞれ同時に送り、総完了時間・各リクエストの待ち時間・失敗数・結果の品質を比較してください。実際の分散と単純な速度変化を区別するために、Jobsの実行ノード記録も一緒に残す必要があります。
ノートPCのスリープ、エンジン停止、ゲーム起動のようにノード状態が変わるケースも一度入れてみてください。PAIRの価値は、大きなモデル1つを無理に動かすことではありません。コーディングエージェントの複数サブタスクのように、互いに独立したリクエストが同時に到着したとき、遊休PCを候補に加えることが核心です。
さらに深く知りたい場合
Getting Started with NVIDIA Personal AI Router — インストール、PINペアリング、ファイアウォールポート、モデル準備、エンドポイント呼び出し、Jobsでの検証を実際のメニューに沿って確認できます。 docs.nvidia.com
Managing Engines in NVIDIA Personal AI Router — PAIRがインストールしたエンジンと既存の実行中エンジンをどのように検出・管理するかを詳しく説明します。 docs.nvidia.com
Known issues — スケジューラーがまだ考慮していないGPU性能・メモリ・モデルロード状態と現在の制限を確認できます。 docs.nvidia.com
Security: NVIDIA/Personal-AI-Router — ループバック専用エンドポイント、相互TLS、信頼できるLANの境界を説明します。 github.com
