NVIDIA PAIRとは？複数PCでOllama・LM Studioを使う仕組みと注意点

先に結論：PAIRは複数PCへの振り分けで、VRAM合算ではない

PAIRの中心は、アプリが接続する入口を一つにして、各リクエストを対応できるノードへ振り分けることです。NVIDIA公式は、PAIRが独立したリクエストを1台のノードへ送り、GPUメモリのプール、GPUの合算、1モデルのsharding、実行中リクエストの分割はしないと説明しています。

「ローカルAIを複数PCで使う」という検索結果だけを見ると、分散学習や巨大GPUのように見えます。実際には、同じモデルを使えるノードを複数用意し、別々の仕事を並行して処理するためのルーターとして考えると理解しやすいです。

• OllamaをWindowsのLANから使う - 1台のOllamaを別端末から公開する話とは分ける
• ローカルAI agentのPC負荷 - 並列要求・context・KV cacheの測り方を見る
• ローカルAIをAPIで使う - client・server・endpointの層を確認する

PAIRの構造：cluster・node・engine・modelを分ける

PAIRを理解するには、ソフト、PC、実行runtime、モデルを同じものとして扱わないことが重要です。PAIR自身はモデルを推論するengineではなく、対応engineの前にproxyとcluster管理を置きます。

同じモデルを2台で使いたい場合、モデルが「clusterにある」のではなく、各nodeのengineにそれぞれ用意されます。PAIRはノードをつないでも、engineのOS・GPU・driver条件やモデルのメモリ要件を肩代わりしません。

• PAIRを入れたPCが、そのままモデルを実行できるとは限らない。
• ノードがonlineでも、対応engineが起動していなければリクエスト候補にならない。
• モデルが存在しても、指定したAPI形式やengineが対応しなければ実行できない。
• Windows ARMはPAIRの対応表でexperimental扱いのため、PAIRとengineの両方の公式条件を確認する。

• WindowsでローカルAIを始める前の確認 - OS・architecture・権限・空き容量を先に確認する
• ローカルAIのモデルサイズ - モデル容量と実行時メモリを分けて考える
• LM StudioとOllamaの違い - engineの操作・API・用途の違いを見る

Windowsで最初に試す最小構成

最初から複数PCを同時に設定すると、PAIR、engine、model、Firewallのどこで失敗したか分からなくなります。まずWindows 11の1台でendpointと短い推論を確認し、次に2台目を追加する順番が切り分けやすいです。PAIRは1台でローカルendpointを作る使い方もできます。

1. 利用時点の公式ReleasesからWindows installerを確認し、対応OS・architecture・ライセンス・リリースを記録する。
2. PAIRを1台のWindows PCへ入れて起動し、OverviewとSettingsでサービス状態を確認する。
3. そのnodeでOllamaまたはLM Studioを用意する。PAIRが管理するengineを入れるか、既存のengineをadoptするかを選ぶ。
4. engine側で短いテスト用モデルを用意し、必要ならloadする。PAIRのclusterではなく、対象nodeのengineにモデルがあることを確認する。
5. Endpointsに表示されたproxy URLをコピーし、OpenAI互換またはOllama APIのclientへ設定する。ポートを記憶で入力しない。
6. 1台で成功したら、信頼できる同一LANの2台目へPAIRを入れ、Settings > ClusterでPINを照合してpairする。
7. 2台目でも同じmodelをengine側へ用意し、複数の独立した短いリクエストを送り、Jobsで実行nodeを確認する。

PAIRを入れただけでは、OllamaやLM Studioのモデルが自動で共有されるわけではありません。各nodeのengine、model、利用可能なメモリ、実行状態を別々に確認します。

• PAIR公式のGetting Started - 公式のインストール・pair・endpoint手順を見る
• LM Studioで最初のモデルを選ぶ - engine側の最初のモデル選びを確認する
• OllamaをWindowsにインストール - Ollama単体の起動・更新・保存を確認する

OllamaとLM Studioのendpoint・APIは同じではない

PAIRはエンジンに応じたproxy endpointを出します。アプリが接続する先は、実際のengineそのものではなくPAIRのproxyです。ただしAPIのpathはengine側の対応範囲を引き継ぐため、Ollama用の`/api/chat`をLM Studio endpointへ送る、といった混同は避けます。

PAIR公式のGetting Startedでは、OpenAIの`/v1/chat/completions`形式はOllamaとLM Studioのどちらでも使える一方、Ollamaの`/api/chat`はLM Studioでは使えないと整理されています。実際のURLはEndpointsからコピーし、変更したproxy portや`/v1`の有無をclientの仕様と合わせます。

# OpenAI互換clientへ設定する値の例。実際のURLとmodel名はPAIRのEndpoints・engine側を確認する
$pairBaseUrl = "http://127.0.0.1:11434/v1"
$modelName = "<model-name>"

# Ollama API clientの場合は、通常host側のbase URLを使い、/v1を重ねない
$ollamaBaseUrl = "http://127.0.0.1:11434"

• Ollamaのproxy portを使うと、clusterが提供できるモデルの見え方になることがある。
• ローカルnodeのengineを直接CLIで確認したい場合は、PAIRがengineを移動させたServer portを確認する。
• PAIRのproxy portとengineのserver portを同じものだと思わない。
• 「接続できた」だけで、意図したnode・model・API形式が確認できたとは扱わない。

• OllamaのOpenAI互換API - Ollamaの`/v1`とnative APIを確認する
• LM StudioのAPIサーバー - LM Studio・Ollama・clientのendpoint層を整理する
• PAIR公式のendpoint説明 - proxy portとengine portの差を見る

どのnodeへ送られるか：モデル・engine・負荷で決まる

PAIRのnode選択は、PCのGPU名だけを比べて決める単純なベンチマークではありません。公式docsでは、nodeがonlineで、対応engineが起動し、指定modelがそのengineにあり、現在の状態で処理可能なことが候補の条件になります。

複数nodeの効果を見るなら、同じ短いリクエストを同時に投げて速度だけを比べるのではなく、Jobsのserving node、model、engine、入力、出力、同時要求数を記録します。PAIRがリクエストを振り分けても、各nodeのモデルロード時間やLAN・GPU・context条件が同じになるわけではありません。

1. 同じmodel名が、各nodeの対象engineで利用可能か確認する。
2. 同じAPI形式で、短い非機密テストを一つずつ送る。
3. PAIRのOverviewやJobsで、どのnodeが処理したかを記録する。
4. 複数requestを送る場合は、同時要求数・modelのload状態・入力長・出力長を固定する。
5. 結果をそのまま「2台だから2倍速い」と一般化せず、用途に対して負荷分散が必要か判断する。

• ローカルAIの速度を測る - load・prompt・generation・完了状態を分けて記録する
• ローカルAIのモデルID確認 - model名と実行能力の取り違えを防ぐ
• PAIR公式Architecture - node・engine・modelの選定条件を見る

LAN・Firewall・プライバシーは「localだから安全」と一括りにしない

PAIRはLAN-firstの設計ですが、local-firstは「どの構成でも外部通信がない」「LANなら安全」という意味ではありません。NVIDIAのSecurity docsは、PAIRのloopback endpoint、ペアリング後のnode間通信、LAN上のmetadata、engine・model catalog・update・clientの通信を別の境界として扱っています。

• PAIRのproxy portをルーターのport forwardingで公開しない。
• 「LANだけ」「local model」という言葉だけで、入力・ファイル・ログ・model downloadの経路を確定しない。
• ペアリング前に、PC名・hardware inventory・接続先ネットワークを確認する。
• 共有PCや組織管理PCでは、Windows Firewallとネットワーク規則を管理者方針に合わせる。
• 最初の疎通確認には秘密情報や未公開ファイルを使わない。

• PAIR公式Security - trust boundary・PIN・loopbackの詳細を見る
• ローカルAIのプライバシー - 推論・通信・保存・providerを分ける
• OllamaのLAN公開前の確認 - OLLAMA_HOST・Firewall・CORSの層を見る

PAIRではなく既存構成でよいケース

PAIRは新しいソフトを増やすための一般的な高速化スイッチではありません。目的が1台のPCでのモデル選び、単純なAPI接続、別端末から1台のOllamaを使うことなら、既存のengine・API・LAN記事で足りる場合があります。

PAIRで解決できる問題と、engineやネットワークの設定で解決する問題を分けると、不要なインストールや公開範囲の拡大を避けられます。まずは1台のlocalhostでmodelとclientを確認し、複数の独立した処理を分散する必要が出たときだけPAIRを候補にします。

• WindowsでローカルAIを始める - 全体の開始順へ戻る
• Ollamaのlocalとcloud - 推論場所と通信経路を分ける
• ローカルLLMの安全性 - local server・履歴・ログ・外部接続を確認する

最初の失敗は「PAIR・engine・model・network」の順に切り分ける

PAIRの導入後に返答がない場合、いきなり再インストールやFirewall無効化へ進まないでください。どの層まで動いているかを一つずつ確定します。

1. PAIRのOverviewとServiceで、PAIR自体がreadyか確認する。
2. 対象nodeでengineがrunningか、指定modelがあるかを確認する。
3. EndpointsのURL、API path、model名をclient設定と照合する。
4. host内の短い非機密requestを一つ送り、responseとJobsを確認する。
5. 最後に2台目へ同じ条件を用意し、独立requestのroutingだけを追加確認する。

• ローカルAIのトラブルシューティング - 起動・load・API・GPUの共通入口を見る
• OllamaがWindowsで起動しない - Ollama単体のlocalhostとログを確認する
• LM StudioがWindowsで起動しない - LM Studio単体の起動とserverを確認する