NVIDIA PAIR Explained: Run Ollama and LM Studio Across Multiple PCs
NVIDIA Personal AI Router (PAIR) gives local AI applications one familiar endpoint while routing independent inference requests to compatible computers on your local network. It is useful when several agents or users compete for local inference capacity, but it is not distributed model execution: every request still runs from start to finish on one machine.
PAIR is an open-source beta released by NVIDIA on September 3, 2026. It works with Ollama and LM Studio rather than replacing either inference engine.
NVIDIA PAIR in one minute
| Question | Answer |
|---|---|
| What does PAIR do? | Routes separate inference requests among eligible computers on a trusted LAN |
| Which engines does it support? | Ollama and LM Studio |
| Which interfaces can clients use? | Ollama-compatible and OpenAI-compatible local endpoints, depending on the engine |
| Does it pool VRAM? | No |
| Can it split one model or request across machines? | No |
| What improves? | Concurrent throughput when multiple independent requests can use multiple prepared nodes |
| Is it open source? | Yes, under Apache License 2.0 |
How PAIR works
You install PAIR on every computer that will participate. The machines discover one another over the local network, but discovery alone does not grant access. A user pairs nodes explicitly with an invitation and six-digit PIN, creating a cluster of trusted systems.
Each node can run Ollama, LM Studio, or both. PAIR tracks:
- whether a node is online;
- which inference engine is running;
- which models are installed on that node;
- pending work and coarse GPU-utilization information;
- whether the node can serve the requested model.
An application sends a normal request to a loopback endpoint on its own machine. PAIR selects one eligible node, forwards the complete request, and streams the response back. The application continues to see an Ollama- or OpenAI-compatible interface and does not need a separate cluster API.
Request routing is not distributed inference
This distinction matters more than any benchmark.
PAIR does not:
- combine memory from several GPUs;
- make two 12 GB GPUs behave like one 24 GB GPU;
- shard model weights across computers;
- split a single prompt or generation between nodes;
- move an in-progress request to another computer;
- make one individual generation inherently faster.
The requested model must already be present on the machine that receives the job. If you want several nodes to be interchangeable, prepare the same model on each of them.
PAIR increases the number of independent requests a local setup can process concurrently. It does not let a model fit when that model is too large for every individual node.
Ollama and LM Studio endpoints
PAIR exposes local proxy endpoints that mirror the engines applications already support.
| Engine behind PAIR | Compatible request styles |
|---|---|
| Ollama | Ollama API plus supported OpenAI-compatible paths |
| LM Studio | OpenAI-compatible paths |
For Ollama-native clients, use the Ollama-style base URL shown in PAIR. For AI SDKs and tools designed around OpenAI’s API shape, use the /v1 base URL documented by PAIR. Copy the endpoint displayed by the application instead of assuming a fixed port, because configuration can move it.
Endpoints listen on loopback. PAIR is designed to run on the computer where the client application runs; it is not a general unauthenticated inference server for other devices on the LAN.
Supported systems and hardware
At launch, NVIDIA documents beta support for compatible Windows, macOS, and Linux systems. The announced hardware coverage includes:
- NVIDIA GeForce RTX 20 Series GPUs and newer;
- NVIDIA RTX PRO workstation GPUs based on Turing or newer architectures;
- NVIDIA DGX Spark;
- Apple M4 and newer silicon.
Compatibility depends on the operating system, inference engine, model, drivers, and network. Treat the current PAIR release documentation—not a generic GPU list—as the final check before installing.
Scheduling and failure behavior
A node is eligible only when it is reachable, has a compatible engine running, and advertises the requested model. PAIR prioritizes manual selection when configured, then uses its scheduling order and a deterministic fallback.
The current scheduler considers pending work and a smoothed GPU-utilization signal. NVIDIA notes that it does not yet fully account for factors such as model warmness, free memory, request cost, or every difference between mixed hardware. Similar machines with the same prepared models are therefore a simpler fit than a highly heterogeneous cluster.
If no eligible node owns the requested model, the proxy returns a local 502 rather than silently choosing an incompatible system.
Pairing and security model
PAIR separates discovery from trust. Devices can discover candidates on the LAN, but cluster membership requires an explicit invitation and PIN entry. After pairing, request and control traffic between cluster members uses mutual TLS and unpaired machines are refused.
There are still important boundaries:
- the six-digit PIN is a bootstrap convenience, not a high-entropy long-term credential;
- only pair systems on a network you trust;
- NVIDIA documents some node telemetry as readable over plaintext HTTP on the local subnet;
- local applications can access the proxy through loopback, so local machine security still matters;
- models, inference engines, and their licences remain separate from PAIR.
PAIR is a local routing layer, not a substitute for the controls in our AI application security guide or for sandboxing untrusted agents.
Why PAIR matters for agents
Single-user chat rarely creates enough concurrency to justify a cluster. Agent workflows can. A lead agent may launch several subagents, evaluators, or background jobs at once, causing independent prompts to queue behind one GPU even when another computer is idle.
PAIR can spread those separate jobs across prepared nodes without changing an agent framework that already supports an Ollama or OpenAI-compatible base URL. Useful scenarios include:
- several coding agents working in parallel;
- batch evaluation of prompts or model outputs;
- a local RAG pipeline with concurrent retrieval and generation jobs;
- multiple developers sharing trusted local inference capacity;
- keeping a desktop and a dedicated local-AI server available to the same workflow.
NVIDIA demonstrated five subagents completing a workload in 8 minutes 48 seconds across three devices versus 18 minutes on one RTX Spark laptop. That is a vendor demonstration, not an independent benchmark, and it measures a concurrent workload—not acceleration of one inference request.
PAIR versus plain Ollama or LM Studio networking
| Setup | Best for | Trade-off |
|---|---|---|
| One Ollama or LM Studio server | One predictable host and simple administration | Requests queue on that machine |
| Manually configured servers | Applications that already implement their own routing | You own discovery, health checks and placement |
| NVIDIA PAIR | Multiple trusted local nodes serving independent requests through familiar endpoints | Beta software; models must be prepared per node; no VRAM pooling |
If you only need remote access to one Ollama server, PAIR may add unnecessary complexity. If you already operate a production gateway, Kubernetes inference stack, or model server with mature scheduling, PAIR is not a replacement for that infrastructure.
Who should use NVIDIA PAIR?
PAIR is worth testing when you already own two or more compatible computers, run Ollama or LM Studio, and regularly create concurrent inference work. It is especially relevant for local coding agents and multi-agent experiments where the bottleneck is queued requests.
Skip it when your goal is to run a model larger than any one machine can hold, accelerate one generation, expose a public inference endpoint, or combine unrelated GPUs into one logical device.
For a simpler single-machine starting point, use the Ollama guide or LM Studio guide. For broader trade-offs, see self-hosted versus cloud AI agents and the local AI hub.