NVIDIA 於 2026 年 9 月 3 日在 IFA 2026 期間發布 Personal AI Router（PAIR）公開測試版。這是一款免費且採 Apache 2.0 授權的開源軟體，可將同一個區域網路內的相容電腦配對成叢集，再把彼此獨立的本地 AI 推論請求分派到有空閒資源的節點執行。NVIDIA 在官方部落格指出，美國超過半數家庭擁有兩台以上的 PC，而這些運算能力在一天之中大多處於閒置狀態，PAIR 的目標就是讓這些機器共同分擔本地 AI 工作，讓一般使用者不必把敏感資料上傳雲端，也能建立小型的私人推論環境。
為什麼需要 PAIR，多代理人工作流程的單卡壅塞問題
隨著 AI 代理人技術成熟，愈來愈多應用會由一個主代理人（lead agent）把複雜任務拆解成數個子任務，再交給專門的子代理人（subagent）處理，使用者也開始同時執行多個代理人工作階段。NVIDIA 技術部落格指出，這種「廣度優先」的做法能縮短完成時間並提升回應品質，但從推論層的角度來看，使用者眼中的一項任務可能變成數十次獨立的模型呼叫。當所有呼叫都指向同一個本地推論引擎時，它們會競爭同一批執行資源，佇列愈排愈長，主機的顯示卡持續忙碌，而網路上其他工作站、筆電或 DGX Spark 可能正好有相容的閒置算力。
PAIR 的角色就是讓推論層跟著代理人一起「變寬」。部分子代理人的請求留在主機執行，其餘則分派到已配對的其他節點。NVIDIA 特別強調，PAIR 不是新的推論引擎，模型仍由 Ollama 或 LM Studio 在被選中的那一台機器上執行。PAIR 負責的是找到參與的系統、追蹤每台機器是否準備好接收請求、排程獨立工作，然後把回應送回發出請求的應用程式。
這裡有一個必須釐清的觀念。PAIR 提供的是工作負載層級的並行處理。每一個推論請求只會被指派給一個符合條件的節點，並在該節點上從頭到尾執行完畢。官方文件明確列出 PAIR 不會做的事，包括不會把多張 GPU 合併成一張更大的加速器、不會彙整 VRAM、不會把單一模型切分到多台機器、也不會把進行中的單一推論請求拆分到不同節點。換句話說，它解決的問題與 Petals 或 Mesh LLM 這類把模型分層跨機執行的方案完全不同。後者的目的是讓單一 GPU 裝不下的大模型能跑起來，而 PAIR 的前提是每台節點本來就能獨立載入完整模型，它只決定下一個獨立請求交給誰。這也是 PAIR 能容忍一般家用 Wi-Fi 頻寬的原因，因為推論過程中沒有跨機器的張量傳輸。
運作流程，從節點發現到請求回傳
根據 NVIDIA 技術部落格與 GitHub 文件，PAIR 的完整流程可拆成五個階段。
節點發現與配對
在每台相容的 Windows、macOS 或 Linux 系統安裝 PAIR 後，軟體會透過 mDNS 自動發現區域網路上的其他 PAIR 節點，也可以手動輸入 IP 位址加入。配對時，發出邀請的機器會顯示一組六位數 PIN 碼，使用者在受邀機器上輸入後即完成配對。在配對完成前，所有節點間的通訊都會被封鎖。
準備推論引擎與模型
每個參與節點需執行 Ollama 或 LM Studio。PAIR 可以協助在已配對的系統上安裝引擎並下載模型，減少準備多台機器的工作量。各節點不需要載入相同的模型，PAIR 會依模型所在位置路由，不過只有當「完全相同的模型標籤」存在於某節點時，該節點才會成為候選。在更多節點載入同一個模型標籤，等於擴大該請求的可用節點池。
代理伺服器接管本地介面
應用程式或代理人透過 PAIR 代理的本地端點送出 Ollama 相容或 OpenAI 相容格式的請求。PAIR 的做法是直接接管 Ollama 與 LM Studio 的預設服務埠，因此既有的代理人框架（agent harness）不需要修改任何設定。若應用程式使用非預設埠，可在 PAIR 的引擎設定中調整代理埠。PAIR 會解析請求所需的引擎與模型，再交給路由器決定去向。這種分工是設計核心，代理人決定「要做什麼」，PAIR 決定「在哪裡做」。
排程到單一合格節點
排程器會依據節點是否上線且就緒、支援的引擎是否已啟用、請求指定的模型是否存在、目前的工作負載（含進行中的工作）等條件篩選，選出一個節點後，由該節點上的 PAIR 路由器把請求交給本地推論引擎。來自其他子代理人的獨立請求可同時分派到其他就緒節點。
回傳回應並呈現路由結果
被選中的引擎執行請求後，PAIR 透過原本的本地介面把回應串流回發出請求的應用程式。PAIR 介面中的 Jobs 與指標檢視會顯示每一個請求實際由哪個節點處理。NVIDIA 特別提醒，只有當 PAIR 遙測顯示工作在多個節點上執行時，才能宣稱達成了多節點執行，因為一個代理人可能產生多次模型請求，代理人數量與 PAIR 工作數量並不相同。
關於「GPU 使用率是否納入排程判斷」這一點，NVIDIA 的說法在不同文件間存在落差，待查。技術部落格與 README 均表示排程會考量 GPU 使用率，例如節點正在執行高負載遊戲時會影響分派，README 的描述是排程政策結合了佇列中的工作量與一個粗略、經過平滑處理的 GPU 使用率訊號。但同一儲存庫的 Known Issues 頁面卻寫明目前唯一的排程政策只計算節點上排隊的工作數量，不考慮 GPU 型號、可用記憶體、目前使用率、量測延遲、模型是否已載入或請求成本高低。實際行為建議以架構文件中的 Scheduler Limitations 章節為準，並以自身環境的 Jobs 檢視驗證。
官方示範數據與應保留的解讀空間
NVIDIA 以 Hermes Desktop 搭配 Ollama 做了一個五子代理人的示範。任務是分析一個合成的家庭收件匣，產出一份附帶證據的「週日整理計畫」。Hermes 負責任務拆解、委派與整合，PAIR 負責推論路由，Ollama 在被選中的節點上執行模型。使用 Qwen 3.6 35B A3B 模型時，同一份工作在單一台 RTX Spark 筆電上平均需要 18 分鐘，而在由 RTX Spark 筆電、DGX Spark 與 RTX 5090 組成的三節點 PAIR 叢集上平均為 8 分 48 秒。
這組數字需要謹慎解讀。NVIDIA 自己就註明這是非官方、特定組態的展示，並非通用基準測試，也不代表效能會線性擴充。結果取決於工作負載的並行程度、模型、引擎設定、硬體、網路與節點可用性。值得注意的是，示範叢集中的 DGX Spark 與 RTX 5090 都遠比單一 RTX Spark 筆電強大，因此這個對照組某種程度上比較的是「一台筆電」與「一台筆電加兩台高階設備」的總算力，PAIR 排程本身帶來的效率仍需另行量測。讀者若想評估 PAIR 在自身環境的價值，NVIDIA 建議直接量測端對端完成時間、佇列狀況、輸出品質，並觀察實際路由分布。
支援平台與安裝方式
根據 GitHub README 與 NVIDIA Playbook 文件，PAIR 目前的支援範圍如下。
Windows 11、Linux 與 macOS，三者的節點可以互相配對。
三種作業系統皆支援 x64 與 arm64，Windows on ARM 屬實驗性支援。
Windows 提供 .exe，Linux 提供 .deb，macOS 提供 .dmg。RPM 系發行版需自行從原始碼建置。
GeForce RTX 20 系列及更新的顯示卡、RTX PRO 工作站顯示卡（Turing 架構及更新）、DGX Spark（128 GB 統一記憶體，執行 DGX OS）。
Apple 硬體搭載 M4 或更新晶片的 Mac。
推論引擎則支援 Ollama 與 LM Studio。
有幾個安裝細節值得留意。第一，PAIR 只接受來自本機的請求，因此必須安裝在執行代理人應用程式的那台機器上，不過該機器可以使用叢集中其他節點的引擎，本身不需要有 GPU 或推論引擎。
第二，PAIR 能在某台機器上執行，不代表推論引擎也能在那台機器上執行，各引擎有自己的作業系統、GPU 與驅動程式需求，每個模型也需要足夠記憶體才能載入。
第三，PAIR 提供桌面應用程式與終端介面（nvpair-tui）兩種操作方式，但同一台機器只能擇一使用，兩者同時執行會導致服務互相競爭埠與設定。NVIDIA Playbook 估計整體安裝時間約 10 分鐘，不含引擎與模型下載。
安全與隱私設計
PAIR 的安全設計建立在幾個機制上。配對階段使用六位數 PIN 碼，NVIDIA 文件說明這是短效的設定用代碼，並非長期憑證。配對完成後，節點間通訊以 mTLS（雙向 TLS）與自動產生的憑證加密，確保網路上的流量維持私密。在配對建立之前，所有節點間通訊都會被封鎖。PAIR 的設計目標是當應用程式、模型來源、引擎與所有配對電腦皆位於本地時，提示詞與回應都留在使用者自己的區域網路內，不會經過雲端推論服務，也沒有 API 金鑰或用量計費。
不過 NVIDIA 在 README 與 Playbook 都提醒，PAIR 包含本地 HTTP 端點、區域網路探索、以 PIN 為基礎的信任建立機制與叢集網路功能，在共用或不受信任的網路上部署前，應先閱讀專案的 SECURITY.md。這意味著 PAIR 的威脅模型是以「受信任的家庭網路」為前提設計的。此外，Windows 版安裝程式會自動新增 PAIR 所需的防火牆規則，macOS 版會註冊特權輔助程式（privileged helper），解除安裝時需使用官方提供的解除安裝工具才能完整移除。
實務上的優點
從實際部署的角度來看，PAIR 有幾項明顯的優勢。
零程式碼修改
PAIR 直接接管 Ollama 與 LM Studio 的預設埠並提供相容端點，既有的代理人框架與應用程式不需要改寫，也不需要學習新的叢集 API。對於已經在本地跑 Ollama 的使用者，導入門檻極低。
整合了原本要自己處理的基礎設施
過去要把多台電腦的本地推論服務整合成單一入口，通常得自行處理節點發現、請求路由與安全連線。PAIR 把 mDNS 探索、PIN 配對、mTLS 加密與排程整合在一套工具中，也能協助在遠端節點安裝引擎與下載模型。
跨平台與混合硬體
Windows、Linux、macOS 節點可以互相配對，NVIDIA GPU 與 Apple M4 以上的 Mac 都能參與。NVIDIA 願意支援 Apple 硬體，顯示它看重混合硬體環境的實際需求。
彈性節點
節點可以隨時加入或離開叢集，筆電休眠、桌機被拿去玩遊戲、引擎被關閉，都不會讓整個叢集失效。家用環境不必變成永遠開機的專用推論設施。
可觀測性
Jobs 與指標檢視能顯示每個請求實際由哪個節點處理，方便驗證叢集是否真的發揮作用。
完整開源
Apache 2.0 授權，儲存庫附有架構文件、開發者指南、治理文件與安全政策，開發者可以檢視程式碼、回報問題或貢獻改進。
資料留在本地
對於需要處理法律文件、醫療紀錄或個人通訊等敏感內容的代理人工作，資料不出區域網路的特性比效能數字更重要。
實務上的限制與缺點
同樣從部署角度，PAIR 目前也有不少值得注意的限制，其中多數由 NVIDIA 自己在文件中揭露。
只適合並行度高的工作負載
PAIR 的效益完全來自工作負載層級的並行。高度循序的任務、由單一長時間模型呼叫主導的工作、或只有一個節點擁有所需模型的組態，幾乎得不到好處。單人單代理人的對話式使用情境不會因為 PAIR 變快。
不能突破單機記憶體限制
由於不彙整 VRAM 也不切分模型，一個 70B 級模型如果單機跑不動，PAIR 不會讓它跑起來。想跑更大的模型仍需換更大的機器。
模型需在各節點重複儲存
排程只會把請求送到已有「完全相同模型標籤」的節點，要讓多台機器分擔同一個模型的請求，每台都必須各自下載並儲存一份模型權重，磁碟空間與模型管理成本隨節點數線性增加。
排程器仍屬初期版本
Known Issues 頁面說明目前唯一的排程政策只依排隊工作數量排序節點，不考慮 GPU 型號、可用記憶體、使用率、延遲、模型是否已載入或請求成本。在硬體相近的叢集上表現合理，但在混合叢集中，工作落在慢節點與快節點的機率大致相同。NVIDIA 已將改進排程與提供可選政策列入規劃，但沒有時程承諾。
記憶體顯示可能失真
在 Windows 的整合式或統一記憶體 GPU 上，PAIR 顯示的 GPU 記憶體會被低估。在沒有 NVIDIA 驅動程式的 Linux（AMD 或 Intel 顯示晶片）上則完全不顯示記憶體與使用率。這不影響路由，但會誤導使用者判斷哪個節點適合放大模型。
測試版的穩定性問題
已知問題包括背景服務卡住時不會被自動偵測、macOS 節點閒置未配對一段時間後可能停止回應區域網路連線、終端介面無法列出或刪除模型、無法變更引擎埠、無法控制其他節點的引擎、也無法顯示工作由哪個節點處理。這些對真正無頭（headless）部署的影響最大。
沒有服務品質保證
當原本負責的機器 GPU 被遊戲或影片輸出佔用時，PAIR 只是把新工作改派到其他可用節點，沒有優先權、配額或延遲保證機制。
信任模型以家庭網路為前提
mDNS 探索與 PIN 配對適合受信任的區域網路，但在企業共用網段或有訪客裝置的環境中，需先審視 SECURITY.md 並評估風險。對於受 ITGC 或類似合規框架約束的組織，PAIR 目前缺乏存取控制、稽核日誌與集中管理等企業級功能（此為依公開文件推論，待查）。
引擎綁定
目前只支援 Ollama 與 LM Studio，使用 vLLM、llama.cpp server、SGLang 或其他引擎的使用者無法直接受益。README 也提醒引擎、模型與其他搭配軟體可能有各自的授權條款。
平台細節
Linux 僅提供 .deb 套件，Windows on ARM 為實驗性支援，PAIR 安裝的引擎不會加入 PATH。
適合那些人使用呢? 那些人不適合用呢?
綜合以上，PAIR 最適合的對象是已經在本地執行多代理人工作流程、家中或工作室有兩台以上相容機器、且這些機器硬體規格相近的進階使用者。在這種情境下，PAIR 能以極低的導入成本把閒置算力變成可用的推論容量，同時把資料留在自己的網路裡。
反過來說，只有一台機器的使用者、主要使用單一對話式應用的使用者、想跑超過單機記憶體的大模型的使用者、或需要企業級存取控制與稽核的組織，目前都不是 PAIR 的目標客群。
跨越單機本地 AI 與傳統託管推論叢集的優秀專案
PAIR 位於單機本地 AI 與傳統託管推論叢集之間。它把自動探索與工作負載放置能力帶進原本缺乏叢集工具的環境，同時緊貼 Ollama 與 LM Studio 這類消費級與工作站級軟體。從 NVIDIA 同時公布期的專案來看，包括針對 llama.cpp 與 vLLM 的最佳化、Nemotron 3.5 Lightning 模型與 10 月上市的 RTX Spark 筆電，PAIR 是 NVIDIA 降低在個人硬體上執行代理人摩擦力的一環。
當 AI 應用逐漸從單一模型對話走向多 AI 代理人自動化任務，本地 AI 硬體的運算壓力勢必增加。PAIR 展示了一種務實的解法，就是先把現有設備用好，再考慮添購新硬體。這個專案是否能從測試版成長為本地 AI 工具箱中的常備工具，取決於排程器的成熟速度，以及使用者拿真實工作負載測試後的回饋。對本地 AI 的關注者而言，這是一個值得持續追蹤的專案。
延伸閱讀
NVIDIA Blog「Sparks Fly: NVIDIA Accelerates Local AI at IFA 2026」 https://blogs.nvidia.com/blog/local-ai-ifa-next-gen-agents-nv-pair-rtx-spark/
NVIDIA Technical Blog「NVIDIA PAIR Virtual Inference Router Expands Available Compute on Your Local Network」 https://developer.nvidia.com/blog/nvidia-pair-virtual-inference-router-expands-available-compute-on-your-local-network/
GitHub 儲存庫 NVIDIA/Personal-AI-Router https://github.com/NVIDIA/Personal-AI-Router
