NVIDIAは2026年9月3日、家庭内の複数のPCへAI推論を振り分ける「Personal AI Router（PAIR）」のベータ版を公開した。OllamaやLM Studioを使うアプリからの要求を受け取り、同じネットワーク上の対応機器へ処理を回す。Windows、Linux、macOSをまたいで利用できる。

普段使っているPCのほかに、空いているゲーム用PCやMacがあれば、AIエージェントの仕事を分担させられる。ただし、各機器のGPUメモリを合算して巨大なモデルを動かす機能ではない。PAIRが増やすのは、独立した推論を同時に処理できる台数である。

NVIDIAの技術ブログは、特定の構成で作業時間が約半分になったデモを紹介している。一方、公開リポジトリの設計文書やコードまで読むと、どの仕事で効果が出るか、異なる性能のPCを混ぜると何が起きるかが見えてくる。

AD

モデルを分割せず、要求を分担する

PAIRは新しい推論エンジンではない。選ばれたPCでモデルを実行するのは、従来どおりOllamaかLM Studioだ。PAIRはその手前で要求を受け、実行先を選び、回答を元のアプリへ返す。

例えば、調査を行うエージェントが、資料の収集結果を読む担当、内容を検証する担当、文章を組み立てる担当へ仕事を分けたとする。それぞれが独立してモデルを呼び出せる局面なら、異なるPCで並行処理できる。仕事の分解と結果の統合はエージェント側が行い、PAIRは推論要求の行き先を決める。

この方式では、モデルをどこに置くかが、そのまま分散できる範囲を決める。要求されたモデルが特定のPCにしかなければ、その要求はそこへ集まる。同じモデルを複数台へ配置して初めて、振り分け先を増やせる。モデルのファイルを共有するのではなく、各ノードが独立したコピーを持つ構造だ。

使い方 PAIRで期待できること 残る制約
同じモデルを複数台に置き、独立した要求を同時に送る 対応するノードへ処理を分配 各台にモデルを実行できるメモリが必要
異なるモデルを別々のPCに置く 要求されたモデルを持つPCへ振り分け 特定モデルの配置先が増えなければ、そのモデルの処理先は増えない
長い回答を単独で生成する 選ばれたPCで要求を処理 その要求を複数台へ分割しない
手元の機器に収まらないモデルを動かす メモリ不足を統合によって解消する機能はない GPUメモリは合算されない

したがって、恩恵を受けやすいのは、複数のエージェントやアプリが同時に推論を求める使い方だ。前の回答が終わらないと次へ進めない処理では、PCを追加しても並列にできる部分が少ない。

デモは約半分の時間に、ただし構成固有の結果

NVIDIAのデモでは、Hermes Desktopが架空の家庭用メールを分析し、今夜や今週に何をすべきかという行動計画を作る。5つのサブエージェントが証拠を読み、食い違いを整理し、結果を統合する課題で、推論にはOllamaと「Qwen 3.6 35B A3B」を使った。

同社が示した平均所要時間は次のとおりだ。

構成 平均所要時間
RTX SparkノートPC単体 18分
RTX SparkノートPC、DGX Spark、RTX 5090の3台 8分48秒

秒に換算すると1,080秒と528秒で、差は552秒、すなわち9分12秒だ。短縮率を「差÷単体の時間」、速度比を「単体の時間÷3台の時間」で計算すると、所要時間は約51.1%短縮、完了までの速さは約2.05倍となる。

ただし、NVIDIA自身が非公式かつ構成固有のデモと明記している。これは同じPCを増やした比較でも、PAIRの有無だけを変えた比較でもない。計算に参加するハードウェアが変わっており、台数に比例して速くなることを示す結果ではない。

また、デモの説明からは試行回数やばらつき、量子化などの設定一式までは確認できない。単独の回答が速くなったと読むのも誤りである。測ったのは複数の推論を含む仕事全体の完了時間であり、サブエージェント数とPAIRの推論ジョブ数も一致するとは限らない。

AD

公開コードが選ぶのは、負荷の小さいノード

では、速いGPUを持つPCに仕事が多く回るのだろうか。現在の公開実装は、そこまで踏み込んだ性能評価を行っていない。

9月4日に確認したスケジューラーのコードは、待機中と実行中のジョブ数に、GPU使用率から作った大まかな負荷段階を足して、値の小さいノードを優先する。GPU使用率は平滑化され、短時間の変動で順序が頻繁に入れ替わらないようになっている。

一方、設計文書が明記する未対応項目には、GPUの型番、空きVRAM、実測した応答時間がある。さらに、要求されたモデルがすでにメモリへ読み込まれているかも、優先順位に使わない。モデルを保存していることと、すぐ推論を始められることは別なのだ。

そのため、同じように空いている高性能PCと低性能PCがあっても、性能差に応じて最適に配分するとは限らない。モデルを読み込み済みのPCより、これから読み込むPCが選ばれる可能性もある。短い要求も長い要求もジョブ数としては同じように数えるため、処理件数が少ないことが、仕事量の少なさを正確に表すわけではない。

なお、リポジトリの既知の問題一覧には「ジョブ数のみを数える」という説明が残り、READMEや設計文書、公開コードとの不一致がある。公開コードにはGPU使用率を順位に反映する処理が実装されているが、配布済みバイナリでの挙動は実機検証が必要だ。

異なる世代のPCを組み合わせる際は、台数を増やすだけで判断せず、遅い機器を加えたときに仕事全体が早く終わるかを確かめる必要がある。

推論通信と機器情報で異なる保護範囲

PAIRはローカル推論を想定し、ペアリング済みノード間の推論通信には、双方の証明書を確認する相互TLS（mTLS）を使う。しかし、LAN上のすべての通信が暗号化されるわけではない。

設計文書とセキュリティ方針を突き合わせると、通信の扱いは次のように分かれる。

通信・情報 公開文書上の扱い
ペアリング後のノード間推論 相互TLSで保護
同じPC上のアプリからPAIRへの要求 ローカル接続に限定した平文HTTP
初回ペアリング 平文の通信と6桁PINで信頼関係を作る
ホスト名、ハードウェア情報、使用率 認証なしの平文HTTPで取得可能

この区別から、PAIRの「ローカルでプライベート」という説明は、信頼できる家庭内ネットワークで使う設計として理解すべきだ。設計文書によれば、同じサブネットの機器はホスト情報などを読み出せる。共有ネットワークへ導入する場合には、推論内容の暗号化とは別に、その公開範囲を判断する必要がある。

アプリの接続方法にも制約がある。別のPCからPAIRのURLを指定して、平文の推論窓口へ接続する使い方は受け付けない。アプリを動かすPCにもPAIRを入れ、そのPC自身のローカル窓口を使う。そこからペアリング済みの計算担当ノードへ要求が渡るため、アプリ側PCにGPUや推論エンジンがなくてもよい。

また、推論をLAN内で行う設計は、外部への通信をすべて遮断する保証ではない。公式のセキュリティ方針は、アプリや推論エンジン、更新システムなどが外部サービスに接続し得ると明記している。モデル取得後も含めて完全な閉域運用を求めるなら、PAIR以外の構成要素も確認する必要がある。

AD

対応PCでも、モデルが動くとは限らない

NVIDIAの技術ブログは、GeForce RTX 20シリーズ以降、Turing世代以降のRTX PRO、DGX Sparkを対応対象に挙げている。Apple M4以降も対象だ。公開READMEではWindows 11、Linux、macOSを扱い、Windows on ARMは実験的対応としている。

ここで分けたいのは、PAIR自体が動作する条件と、選んだモデルを実行できる条件である。製品ページにはRAM 8GB以上、ディスク容量は20GB以上を推奨するとあるが、これは任意のモデルを動かせるという保証ではない。推論エンジンごとの対応OSやドライバー条件に加え、モデルが要求するメモリを各ノードで満たす必要がある。

導入時には、参加させるPCへPAIRを入れてペアリングし、計算を担うPCでエンジンとモデルを準備する。既存のOllamaやLM Studio向けインターフェースを中継する設計なので、エージェントの処理そのものを書き換える必要はない。ただし、自分で起動した既存エンジンをPAIRが移動・停止できない場合もあるため、使用ポートや起動方法は確認したい。

PAIRのソースコードはApache License 2.0で公開されている。組み合わせるエンジンやモデルには別の利用条件がある。

試す際は、普段の仕事で完了時間を測り、PAIRのJobs画面で実際に複数のノードが使われているかを確認するのがよい。モデルの配置、各PCの性能差、出力の品質まで含めて改善が見られるなら、空いている手元の機器をローカルAIの処理能力へ変えられる。