NVIDIA Personal AI Router (PAIR) is a virtual inference router that uses the compute available on a user’s local network to alleviate bottlenecks caused by multi‑agent and subagent workflows. It is not an inference engine itself: Ollama or LM Studio still runs the model on the selected machine. PAIR discovers participating systems, monitors their readiness, schedules independent inference jobs, and returns responses to the originating application.
The PAIR beta is available for supported Windows, macOS and Linux systems via graphical and terminal interfaces. Supported hardware includes NVIDIA GeForce RTX 20 Series and newer GPUs, NVIDIA RTX PRO workstation GPUs (Turing architecture and newer), NVIDIA DGX Spark, and Apple M4+ silicon.
Why is this needed?
Modern AI agents often decompose complex tasks into smaller jobs and assign those to specialized subagents. That breadth‑first approach can speed up task completion and improve result quality, but at the inference layer it creates many independent model calls. If all those calls target a single local engine, they queue for the same execution slots and slow the system, even if other compatible machines on the network have available capacity.
How PAIR works
-
Local network discovery: After installation on compatible Windows, macOS or Linux systems, PAIR uses mDNS to automatically find nearby systems; nodes can also be added by IP address. The user approves secure pairing, and node‑to‑node communication is blocked until the pairing is established. Communications are secured with mTLS and generated certificates to keep traffic private on the local network.
-
Preparing engines and models: Each participating node runs a supported local inference engine (Ollama or LM Studio). PAIR can assist with engine installation and model downloads. A node becomes eligible for a request only when the required engine is enabled and the exact requested model is present there.
-
Proxying the local interface: PAIR proxies the Ollama‑compatible or LM Studio‑compatible local endpoints so agent harnesses do not need to integrate with every machine. PAIR takes over the default ports used by those services (configurable if an agent uses a different port), inspects engine and model requirements and passes them to the router. The agent decides what work to request; PAIR decides where eligible work should run.
-
Scheduling one eligible node: The scheduler filters paired systems using current readiness, engine state, requested‑model presence, active jobs and GPU utilization, then selects one eligible node. The router on that node passes the request to the local inference engine. Other independent calls can be assigned to other ready nodes at the same time.
-
Returning the response and visibility: The selected engine executes the request and PAIR streams the response back through the same local interface. The Jobs and metrics views show which node handled each routed request, making placement observable.
PAIR assigns each request to a single eligible node and does not run one inference across multiple GPUs or machines.
Which workloads benefit most?
PAIR is most useful when multiple independent requests occur simultaneously, such as multi‑agent applications and concurrent local AI tools. For those workloads PAIR can:
- Route independent jobs across ready systems on the local network.
- Reduce queueing that would occur if all requests targeted one local engine.
- Improve end‑to‑end completion time for suitably parallel workloads in compatible configurations.
- Free the primary PC for gaming, creative work, or other interactive tasks.
- Preserve the familiar, local‑first application workflow.
PAIR does not merge GPUs or pool VRAM, nor does it shard a single inference request across machines. Highly sequential workloads or cases where only one node hosts the required model will see less benefit.
Demo: Hermes five‑subagent scenario
In a demonstration, Hermes Desktop created five specialist subagents, Ollama executed models on nodes selected by PAIR, and the task was to analyze a synthetic household inbox and produce a "Sunday Reset" plan with evidence.
In that configuration‑specific demo, running the five‑subagent workload with Qwen 3.6 35B A3B on one NVIDIA RTX Spark laptop averaged 18 minutes. The same workload on a three‑node PAIR cluster (RTX Spark laptop, DGX Spark, and RTX 5090) averaged 8 minutes 48 seconds. The demonstration is noted as unofficial and dependent on workload parallelism, model, engine settings, hardware, network, and node availability.
PAIR’s Jobs view is the ground truth for where inference ran; agent counts and PAIR job counts differ because one agent can generate multiple model requests.
Leveraging home AI cluster elasticity
PAIR is designed for dynamic home hardware rather than always‑on data center clusters. It accounts for systems that may sleep, power down, change workload, or host different models. Client nodes can join the available pool when ready and drop away as needed without requiring a dedicated always‑on installation. For each request PAIR considers:
- Whether a paired node is online and ready.
- Whether a supported inference engine is enabled.
- Whether the exact requested model is present.
- Current node and engine workload and GPU utilization.
Getting started with PAIR
Steps to use PAIR:
- Download the NVIDIA PAIR beta for a supported Windows, macOS or Linux system.
- Install PAIR on the NVIDIA RTX PCs, NVIDIA RTX PRO workstations, or NVIDIA DGX Spark systems to include.
- Discover and securely pair the systems on the local network.
- Enable Ollama or LM Studio and download or place the required models on eligible nodes.
- Run a compatible agent on a PAIR‑installed system that uses Ollama or LM Studio.
The NVIDIA PAIR project is open source; developers can inspect the code, report issues, and contribute to discovery, pairing, routing, engine integration, models, endpoints and the user experience.
Summary
PAIR brings a cluster‑like experience to dynamic home NVIDIA systems while keeping local inference workflows intact. It helps distribute independent inferencing jobs across ready devices on the local network, reducing queuing and potentially shortening completion time for parallel workloads, without requiring changes to the agent harness or a new cluster API.
