ローカルLLMを動かすPCを増やしても、1本の推論がその台数分だけ速くなるわけではない。
NVIDIA PAIRが減らすのは、複数の独立したリクエストが1台のGPUの前で並ぶ待ち時間だ。
公式デモでは処理時間が18分から8分48秒へ短縮されたが、その数字を正しく読むには「何を分散していないか」を理解する必要がある。

NVIDIAは2026年9月3日、Personal AI Router（PAIR）のベータ版とソースコードを公開した。Windows、Linux、macOSが混在する家庭内ネットワークでOllamaやLM Studioへのリクエストを振り分ける、Apache License 2.0のローカル推論ルーターである。

これは新しい推論エンジンでも、複数GPUを1つに見せる仕組みでもない。本稿では公式ブログだけでなく公開されたアーキテクチャ文書を読み、プロキシ、モデル適格性判定、スケジューラ、mTLSという4層に分けて設計を追う。

PAIRが解くのは「計算不足」より「待ち行列」

ローカルで単発のチャットを使うだけなら、PAIRを入れても大きな利点は出にくい。1つのリクエストは開始から終了まで1台のノードで処理され、途中で別のGPUへ分割されないからだ。

一方、複数のエージェントやサブエージェントが同時に推論を要求すると、問題の形が変わる。1台のOllamaへ10件が集中すれば、GPUが高速でも後続リクエストにはキュー待ちが発生する。別室のPCがアイドルでも、アプリケーションがその存在を知らなければ使われない。

PAIRは、アプリケーションから見える接続先を1つに保ったまま、独立したリクエストを処理可能なノードへ配置する。

AIアプリ / エージェント
          │ Ollama互換 / OpenAI互換HTTP
          ▼
  localhost上のPAIRプロキシ
          │
          ├─ エンジンとモデルの適格性を判定
          ├─ ジョブ数とGPU負荷で候補を順位付け
          │
          ├─ ローカルのOllama / LM Studio
          │
          └─ mTLS ─ 別ノードのPAIRプロキシ
                            │
                            └─ そのノードの推論エンジン

重要なのは、分散の単位がモデルではなくリクエストであることだ。

方式	分散する単位	1リクエストで複数VRAMを使うか	得意な負荷	アプリ側の変更
単一のOllama / LM Studio	なし	いいえ	単発・逐次処理	なし
NVIDIA PAIR	独立リクエスト	いいえ	マルチエージェント、同時利用	互換endpointを使える場合は最小限
Tensor / Pipeline Parallel	1モデル内の演算	モデルを分割して利用	1台に載らない大規模モデル	専用runtimeや構成が必要
バッチ推論サーバー	複数入力の演算batch	通常はいいえ	同型の大量リクエスト	server側のbatch設計が必要

PAIRは3台分のVRAMを足して巨大モデルをロードする製品ではない。70Bモデルが1台に載らないなら、PAIRを導入しても載らない。反対に、同じモデルを複数ノードへ配置すれば、それぞれが独立したリクエストを並行処理できる。

4段階で決まるリクエストの行き先

1. mDNSで見つけ、PINで信頼関係を作る

各マシンは対等なノードで、中央の管理ノードは存在しない。PAIRはmDNSで同一ネットワーク上の候補を発見し、利用者が6桁のPINを確認してペアリングする。クラスタ参加後は、各ノードがリクエストの送信側にも実行側にもなれる。

クラスタへ参加しただけでは推論可能にならない。ノード上でOllamaまたはLM Studioが稼働し、要求されたモデルがそのエンジンに存在するときだけ候補になる。モデルは共有ストレージ上の1コピーではなく、各エンジンが持つ独立したコピーだ。

2. 既存endpointの手前へプロキシを置く

PAIRはOllama互換とOpenAI互換のHTTP endpointを公開する。既存アプリが接続先URLを変更できれば、エージェント側に新しいクラスタAPIを実装する必要はない。

標準構成では、PAIRのプロキシがOllamaの既定portである11434を引き受け、PAIR自身が起動したOllamaを別portへ移す。ローカルアプリからの平文HTTPはloopbackだけに制限し、別マシンからの平文アクセスは拒否する設計だ。

ただし、既に起動しているOllamaなど、PAIRが所有していないprocessを強制終了したり移動したりはしない。既定portを他のprocessが保持しているとプロキシは別portへ退避するため、「インストールしたのに分散されない」場合は実際の接続先を確認する必要がある。

3. モデルを持つノードだけを残す

リクエストにモデル名があれば、プロキシは各ノードのinventoryを参照し、そのモデルを提供できるノードだけを候補に残す。ここはhard gateであり、負荷が低いという理由だけでモデルを持たないノードへ送ることはない。

この設計では、モデル配置がそのままルーティング能力になる。

1台だけがモデルを持つ: そのモデルの負荷分散はできない
複数台が同じモデルを持つ: その集合内で負荷分散できる
各ノードが別モデルを持つ: モデル名に応じた振り分けはできるが、同一モデルの並列capacityは増えない

inventoryが古く、選ばれたノードから「モデルなし」に相当する404が返った場合は、次の適格ノードへfailoverする。一方、400や422のように別ノードでも同じ結果になるclient errorは再試行しない。

4. ジョブ数とGPU圧力で順位を付ける

現在のschedulerは、モデルの種類を意識せず全ノードを順位付けする。モデル適格性はプロキシ側が後から適用するため、責務は次のように分かれる。

scheduler: 全ノードの混雑順を作る
proxy:     要求モデルを持つノードだけに絞り、その順番を使う

公式アーキテクチャ文書に記載された通常時のscoreは、概念的には次の形だ。

score = pending_jobs + gpu_pressure

pending_jobsはqueue中または実行中のジョブ数である。gpu_pressureは最も忙しいGPUの利用率を、係数alpha = 0.35の指数移動平均（EWMA）で平滑化し、40%、70%、85%の閾値で0から3の段階へ変換する。値が下がるときは35%、65%、80%を使い、境界付近で順位が頻繁に反転するのを防ぐ。

telemetryが欠落、不正、または10秒より古い場合、圧力は「idle」ではなく中立値の1として扱う。候補はscore、GPU圧力、安定したnode IDの順で並ぶ。順位は状態変化時に再計算され、1秒ごとにも整合される。

同時に到着したリクエストが全て同じidle nodeを選ぶ競合もある。そこで各プロキシは、今まさに転送したリクエストをローカルに予約として加算する。workload reportが全体へ伝播する前でも、自分が発生させたburstを複数ノードへ広げられる。

公式文書には不整合がある。known-issues.mdxはschedulerがcurrent utilizationを考慮しないと説明する一方、詳細なarchitecture、scheduler専用README、2026年9月5日に確認したmain commit 13b6811のschedule.goとtelemetry.goは、上記のGPU pressureを実装している。本稿はsource codeを優先した。利用中のbinaryがどのversionかは別途確認が必要である。

18分から8分48秒をどう読むか

NVIDIAのデモは、Hermes Desktopが5つのsubagentを動かし、Ollama上のQwen 3.6 35B A3Bを使う構成だった。

構成	平均完了時間	秒換算	1台構成との比較
RTX Spark laptop 1台	18分00秒	1,080秒	基準
RTX Spark laptop + DGX Spark + RTX 5090	8分48秒	528秒	約2.05倍、時間は約51.1%減

2.05倍と51.1%は、公表時間から本稿で算出した値である。3台だから3倍になったのではない。タスク分解と最終統合は逐次部分になり得るうえ、3台は異種hardwareで、network転送とschedulerにもoverheadがある。

さらに、これはNVIDIA自身が「非公式かつ構成依存」と明記するデモであり、一般benchmarkではない。試行回数、各ノードに流れたjob内訳、token throughput、消費電力、回答品質の差は公開記事からは分からない。

したがって、この結果が示すのは「PAIRなら常に2倍速い」ではない。正確な読み方は、独立性の高い5-subagent workloadでは、異種3ノードへのrequest-level routingがend-to-endの待ち時間を半分近くまで削減した例がある、である。

「ローカルだから安全」の境界

PAIRは、cluster内部の推論trafficをmTLSで保護する。各ノードはself-signed certificateを持ち、ペアリング時に相手のUUIDとcertificateをpinningする。未参加の端末がnetwork portへ到達しても、model inventoryの取得やremote engineの操作はできない。

ただし、全surfaceが暗号化・認証されるわけではない。

通信面	保護	注意点
local application → proxy	loopback上の平文HTTP	同一machine内だけを許可
paired node間の推論	mTLS	pinning済みcluster memberのみ
model inventory / remote engine制御	mTLS	cluster membershipが必要
初回pairing	平文 + 6桁PIN	信頼確立前なのでTLS certificateは未共有
host / GPU telemetry	平文・認証なし	同一subnetからhostname、hardware、利用率を読める

最後のtelemetryは見落としやすい。公式設計文書も、これを許容できないnetworkではPAIRを動かさないよう明記している。家庭内LANでも、来客用Wi-Fi、IoT機器、業務端末を同一subnetへ混在させているなら、VLANやnetwork分離を先に検討すべきだ。

また「local」はPAIR単体の性質ではなく、構成全体の性質である。PAIRはoperation中にinternetを必須としないが、model downloadには接続が必要になる。アプリ、tool、model sourceのいずれかがcloudへ送信する設計なら、PAIRを通しただけでdata localityが保証されるわけではない。

PAIRのmTLSは、ペアリング済みノードを信頼する設計である。感染済みのcluster member、local application自身のdata送信、modelやtoolのsupply chain riskまで自動的に解決するものではない。

導入前に測るべきもの

PAIRが効くかどうかはGPU台数より、同時に実行可能なリクエスト数で決まる。導入評価は次の順序が分かりやすい。

同じmodel、同じengine、同じtaskで1台構成のbaselineを取る
taskを独立して走れる部分と、前の結果を待つ逐次部分へ分ける
対象modelを2台以上へ複製し、Jobs画面で実際に複数nodeへ流れたことを確認する
end-to-endのp50 / p95、queue時間、失敗率、出力品質を比較する
nodeのsleep、engine停止、model削除、port競合を意図的に起こして回復を確認する
同一subnetから見えるtelemetryを許容できるかsecurity reviewする

token per secondだけでは不十分だ。PAIRの価値は1リクエストの生成速度ではなく、workload全体の完了時間と、primary PCを別用途へ戻せることにある。逆に、1本の長い推論しかないなら、測定結果が「変わらない」ことも正常である。

現在のschedulerが苦手な構成

公開された実装文書は、ベータ版の限界をかなり率直に列挙している。

GPU model、利用可能VRAM、実測latencyを順位付けに使わない
modelがmemoryへload済みかどうかを考慮しない
3 tokenの短い応答も長時間generationも、pending jobとしては同じ1件
multi-GPU nodeでは最も高いGPU利用率だけを見る
OllamaとLM Studioの負荷をnode単位で合算する
各nodeがeventually consistentな自分のviewで順位を作るため、別nodeからの同時dispatchが同じpeerへ重なる場合がある
processが終了すれば再起動するが、processが生存したまま応答不能になるhangは自動検知しない

特に異種clusterでは、「空いている遅いGPU」が「少し忙しい速いGPU」より上位になることがある。model warmnessも見ないため、load済みnodeを差し置いてcold loadが必要なnodeを選ぶ可能性もある。

これは単なる欠陥一覧ではなく、PAIRの狙いを示している。現段階の最適化対象はdata center級の精密なcapacity schedulingではなく、日常的にsleepや離脱をする家庭内PCへ、低い導入コストで並列jobを逃がすことだ。

実務への含意

PAIRの面白さは、家庭内GPUをcluster化したことより、既存APIの手前へ薄いrouting layerを置いたことにある。agent frameworkがOllamaやOpenAI互換endpointを使っていれば、orchestration layerとinference placementを分離できる。

この分離は次の設計原則につながる。

agentは「何を依頼するか」を決め、routerは「どこで実行するか」を決める
model inventoryをcapacity planningの一部として管理する
並列化できるtaskだけを広げ、逐次taskへ無理な分散を持ち込まない
routing結果を推測せず、Jobs telemetryで観測する
local-firstという主張をnetwork、application、model sourceまで含むend-to-end propertyとして検証する

自宅の余っているPCを使う話に見えるが、構造はproduction inferenceにも通じる。model-aware eligibility、load-based ordering、local reservation、failover、observabilityを別々の責務にした点は、小規模なrouterを設計する際のよい教材になる。

限界と未確認事項

本稿は2026年9月5日時点のベータ版、公式blog、公開repository、公式設計文書を基にしている。今後scheduler policyや対応engineは変わり得る。
18分と8分48秒はNVIDIAによる構成依存のdemonstrationであり、第三者benchmarkではない。本稿は実機で再現していない。
公開値から約2.05倍と約51.1%を算出したが、改善の内訳をhardware、queue削減、network overheadへ分離するdataはない。
PAIRはsingle requestを分割せず、VRAMもpoolしない。巨大modelのmemory問題を解くものではない。
「promptやfileがlocalに残る」という性質は、利用するapplication、tool、model source、network構成もlocalである場合に限る。
現行schedulerはrequest costやhardware capacityを深くmodel化しないため、本番導入では自分のworkloadによる測定が必要である。
known-issues.mdxとscheduler実装でGPU utilizationに関する記述が食い違う。本稿はcommit 13b6811のsourceを確認したが、配布binaryとの同一性までは検証していない。

まとめ

NVIDIA PAIRは、家庭内のGPUを1枚の巨大GPUへ変えるsoftwareではない。Ollama / LM Studio互換proxyの背後で、独立した推論requestをmodel適格性と混雑度に応じて1台ずつ配置するrouterだ。

公式デモの約2.05倍という改善は、multi-agent workloadの並列性を待ち行列の削減へ変換できた一例である。同時に、capacityを見ない単純なscheduler、平文telemetry、hang検知の欠如、VRAM非共有という境界も明確だ。

導入判断で問うべきなのは「PCが何台あるか」ではない。同時に独立実行できるrequestがいくつあり、そのmodelを何台が実際にserveできるかである。その2つをJobs telemetryとend-to-end latencyで測れたとき、PAIRは余剰hardwareを実用的なlocal inference capacityへ変える。

参考リンク

NVIDIA PAIR Virtual Inference Router Expands Available Compute on Your Local Network（2026-09-03）

NVIDIA Personal AI Router (PAIR)

NVIDIA Personal AI Router - GitHub Repository

NVIDIA Personal AI Router Architecture

Getting Started with NVIDIA Personal AI Router

NVIDIA Personal AI Router Known Issues

NVIDIA Personal AI Router Job Scheduler Source

NVIDIA Personal AI Router GPU Telemetry Source