PAIRがつなぐもの
PAIRは「Personal AI Router」の略称です。2026年9月3日にNVIDIAがベータ版を公開しました。役割は、アプリから届く推論リクエストを受け取り、必要なモデルを持ち、処理できる状態の端末へ転送することです。モデルを実際に動かすのは、各端末のOllamaまたはLM Studioです。
| 層 | 担当するもの | 主な役割 |
|---|---|---|
| アプリ・AIエージェント | Hermesなど | タスクの分解、依頼、結果の統合 |
| PAIR | ルーター | 端末の発見、状態監視、依頼先の選択、応答の中継 |
| Ollama・LM Studio | 推論エンジン | 指定されたモデルを読み込み、推論を実行 |
| Windows・Linux・Mac | ノード | GPUやユニファイドメモリを使って1件の依頼を処理 |
アプリから見る接続先は1つです。PAIRがOllama互換とOpenAI互換のエンドポイントを見せるため、ベースURLを指定できる既存ツールは、端末ごとの場所を意識せず使えます。新しいクラスタ用APIへ全面移行する必要はありません。
この分担は、前日に紹介したHydraFusionとも違います。HydraFusionが複数モデルの答え方を編成するのに対し、PAIRが扱うのはローカル環境で各リクエストをどの端末へ置くかです。モデル選択と計算資源の配置は、似て見えて別の問題です。
VRAMは合体しない
PAIRで最も誤解しやすいのは「複数台を1台の巨大GPUとして使える」という見方です。公式ドキュメントは、その使い方を明確に否定しています。1件の推論は、選ばれた1台の端末で開始から終了まで処理されます。途中で別のGPUへ分割されません。
| できること | できないこと |
|---|---|
| 独立した複数リクエストを別々の端末へ配る | 複数GPUのVRAMを1つの大容量VRAMとして束ねる |
| 同じモデルを持つ空き端末から実行先を選ぶ | 1つのモデルを複数端末へ分割して載せる |
| 端末ごとに異なるモデルを置き、場所に応じて転送する | 1件の長い推論を複数GPUで同時に計算する |
| PCが休止・離脱しても次の依頼先を選び直す | モデルが入らない端末へ無理に依頼を送る |
そのため、効果が出やすいのは複数のAIエージェントが同時に走る仕事です。主役のエージェントが調査、検証、要約を5つの担当へ分けるなら、5件以上のモデル呼び出しが並びます。PAIRは、それぞれを空いたノードへ振り分け、1台の待ち行列を短くします。
反対に、ひとつの巨大モデルが手元のどの端末にも載らない場合、PAIRを入れても解決しません。1件ずつ順番にしか進まない仕事や、同じモデルを1台にしか置いていない構成も恩恵は小さくなります。これは速度向上ソフトではなく、並列に発生した仕事の交通整理だからです。
対応環境を確かめる
NVIDIAの製品ページが示す検証済み構成は、Windows 11、Linux、macOSです。CPUアーキテクチャはx64とArm64に対応し、Windows on Armは実験的扱いです。異なるOSの端末を同じクラスタに混ぜられます。
| 項目 | 公開時点の条件 |
|---|---|
| 対応端末 | GeForce RTX 20シリーズ以降、RTX PRO、DGX Spark／GB10、Apple M4以降 |
| システムメモリ | 8GB以上 |
| ストレージ | 20GB以上を推奨。モデル本体の容量は別途必要 |
| 推論エンジン | Ollama、LM Studio |
| 配布形式 | Windows用インストーラー、Linux用Debianパッケージ、macOS用ディスクイメージ |
| ネット接続 | 動作中は不要。PAIRやモデルの取得時には必要 |
| ライセンス | Apache License 2.0 |
ただし「PAIRが動く」と「目的のモデルが動く」は同じではありません。各端末は、使う推論エンジンの要件を満たし、モデルを読み込めるメモリを持つ必要があります。公式READMEも、エンジンとモデルが特定端末で動くかは、それぞれの要件で確認するよう求めています。
導入前には、端末の台数より先に3点を見ます。
- 同時に複数の推論を投げるアプリやエージェントを使っているか
- 2台以上に同じモデルを置けるだけのメモリとストレージがあるか
- 使いたいアプリでOllamaまたはLM Studioの接続先を変更できるか
この3点が揃わないなら、PAIRよりも単体GPUの更新、量子化モデルへの変更、クラウドAPIの利用を先に比較したほうが合理的です。
導入は5段階
PAIRはグラフィカル画面とターミナル画面を用意しています。一般利用では、署名済みインストーラーを使う方法が公式の推奨です。自分でビルドした版は署名も自動更新確認もないため、まずはリリース版から始めるのが安全です。
- 参加させる端末すべてへPAIRをインストールする
- 同じローカルネットワーク上で端末を発見する
- 招待側に出る6桁のPINを相手側へ入力し、ペアリングを承認する
- 各端末でOllamaかLM Studioを有効にし、使うモデルを置く
- アプリの接続先をPAIRのローカルエンドポイントへ向け、Jobs画面で実行先を確認する
PAIRはmDNSで近くの端末を探しますが、発見しただけでは信頼しません。ユーザーがPINを使って承認するまで端末間通信は遮断され、ペアリング後の通信は生成した証明書と相互TLS（MTLS）で保護されます。ノードは同時にひとつのクラスタだけへ参加できます。
「ローカルだから何でも自動的に秘密になる」とは限りません。公式READMEは、設定したクライアント、モデルの取得元、推論エンジン、各ノードがすべてローカルである場合に、プロンプトと応答がネットワーク内へ留まると説明しています。外部APIを呼ぶアプリやクラウド上のモデルを混ぜれば、その通信までPAIRがローカル化するわけではありません。プロンプトインジェクション対策と同じく、通信経路、権限、ログの保存先を分けて確認する必要があります。
速度デモの読み方
NVIDIAは、5つのサブエージェントを動かす構成で完了時間を比較しています。Qwen 3.6 35B A3Bを1台のRTX SparkノートPCで動かした場合は平均18分でした。RTX SparkノートPC、DGX Spark、RTX 5090の3台をPAIRでつなぐと、平均8分48秒です。単純計算では完了時間が約51%短くなりました。
| 比較項目 | 1台構成 | 3台のPAIR構成 |
|---|---|---|
| 使用端末 | RTX SparkノートPC | RTX SparkノートPC、DGX Spark、RTX 5090 |
| タスク | 5サブエージェントによる同一ワークロード | 同左 |
| 平均完了時間 | 18分 | 8分48秒 |
| 読み取れること | 1台では独立リクエストが待つ | 並列性のある仕事では待ち時間を減らせる |
この数字を「3台なら常に約2倍」と一般化してはいけません。NVIDIA自身が、非公式かつ構成限定のデモであり、線形な性能向上を約束しないと注記しています。結果は、同時実行できる仕事の量、モデル、推論エンジン、ネットワーク、端末の空き状況に左右されます。
試すときはトークン毎秒だけで判断せず、同じ実務タスクの開始から終了までを測ります。確認する指標は、総完了時間、待ち時間、出力品質、PAIRのJobs画面に複数ノードの実行記録があるかです。エージェント数と推論ジョブ数も一致するとは限りません。1つのエージェントが複数回モデルを呼ぶためです。
向く人と向かない人
PAIRは、新しいGPUを買う前に、すでに持っている端末の空き時間を使いたい人に向きます。とりわけ、複数の調査役や検証役を同時に動かすAIエージェントの運用では、計算資源の待ち行列を観察できる点に意味があります。
| 状況 | PAIRを試す判断 |
|---|---|
| RTX搭載PCやM4以降のMacが2台以上あり、同時推論が多い | 試す価値が高い。まず同じモデルを2台へ置いて総完了時間を比較 |
| 1台だけでローカルAIを使う | ルーティング先がないため優先度は低い |
| 1つの巨大モデルを複数GPUへ分割したい | 目的に合わない。モデル並列化に対応する別の仕組みを検討 |
| 主にクラウドAPIを使う | PAIRの対象外。コスト上限やAPI側の並列制御を見直す |
| 機密データを扱う | ローカル構成は候補になるが、全クライアントとログの通信先を監査 |
現時点のPAIRはベータです。料金表のあるクラウドサービスではなく、Apache License 2.0でコードが公開されています。ただし、端末の購入費、電力、モデルの保存容量、運用の手間は残ります。手元の機材が異なるほど、NVIDIAのデモ値ではなく、自分の仕事を使った小さな検証が必要です。
PAIRが増やすのは、1台のVRAMではありません。独立した仕事を置ける場所です。AIエージェントを増やす前に、自分の作業は本当に並列化できるのか。そこを確かめることが、導入の最初の判断になります。
まとめ
- NVIDIA PAIRは、OllamaやLM Studioへの独立した推論リクエストを、同一ネットワーク上の空いた端末へ振り分けるオープンソースのルーターです。モデルを動かす推論エンジンそのものではありません。
- 複数GPUのVRAMを束ねたり、1件の推論を分割したりはできません。効果を左右するのは端末数より、同時に処理できる独立ジョブがどれだけあるかです。
- 導入判断では、対応端末、同じモデルを複数ノードへ置ける容量、アプリの接続先変更、通信とログがローカルに留まる条件を確認し、実務タスクの総完了時間で測るのが持ち帰りになります。
