NVIDIA PAIR Routes Local AI Across PCs Without Pooling VRAM

What NVIDIA released

On September 3, 2026, NVIDIA published a beta of Personal AI Router, or PAIR. It is an Apache-2.0 open-source router for local inference. PAIR forms a cluster from computers already connected to the same local network and distributes independent model requests across Ollama or LM Studio instances running on those computers.

To an application, PAIR looks like a local endpoint compatible with the Ollama or OpenAI API. The application sends a request to `localhost`, and the router selects an eligible node. An existing agent framework or internal service can therefore often be connected by changing an endpoint rather than rewriting its application logic.

The documented platforms are Windows 11, Linux and macOS on x64 and arm64. NVIDIA lists GeForce RTX 20 Series and newer, RTX PRO, DGX Spark and Apple computers with M4 or newer processors. This does not mean that every model will run on every listed machine: engine support, weight format and actually available memory remain separate requirements.

How one request moves through the cluster

After installation, PAIR discovers nodes with mDNS or a manually supplied IP address. Initial pairing is approved with a six-digit PIN; the nodes then exchange certificates. Mutual TLS protects communications inside the cluster.

The scheduler considers node readiness, engine state, whether the requested model is present, the number of active jobs and a coarse GPU-utilisation signal. It then sends the complete request to one selected computer. The response returns to the application through the same local endpoint.

In practical terms, the path is:

• the application or agent connects to PAIR on the same computer;
• PAIR checks which nodes have the model and a ready inference engine;
• one node handles the whole request;
• several independent requests can be sent to different nodes in parallel.

The local endpoint intentionally accepts loopback connections only. PAIR must be installed on the machine where the application runs. If a company needs a shared network API for many workstations, exposing it, authenticating users, enforcing quotas and recording an audit trail are outside PAIR's scope and require a separate gateway.

What PAIR explicitly does not do

The central limitation is stated directly in the documentation: PAIR does not pool VRAM, combine multiple GPUs for one job, shard model weights or divide one request across multiple nodes.

If a model needs 24 GB of memory and each of three computers has only 12 GB available, the cluster does not create a virtual 36 GB device. The model must fit and run in full on at least one node. The same applies to long context: if the selected combination of model, quantisation and request length does not fit on a machine, the other cluster nodes do not solve that problem.

PAIR is useful when the bottleneck is a queue of independent jobs:

• several employees use the same local assistant at once;
• an agent launches independent research or classification subtasks;
• a batch of documents, support tickets or product records must be processed;
• developers share a limited pool of machines for testing;
• the same model is already installed on several nodes and can serve more concurrent requests.

It does not solve the problem of running one oversized model and is not a replacement for a distributed inference server that shards weights.

Why mixed hardware needs careful testing

PAIR's current scheduler is deliberately simple. Its architecture documentation warns that node selection does not account for GPU model, free VRAM, measured latency or the expected cost of a particular request. One short classification and one long report generation each look like one active job to the counter.

That may be acceptable in a uniform fleet. In a mixed cluster, fast and slow computers may receive work without a sufficient adjustment for real performance. Average throughput can improve while the tail latency of individual requests becomes worse.

The beta documentation lists further limitations. Shared GPU-memory figures may be inaccurate or unavailable, a stalled service is not always detected automatically, and the terminal interface does not provide complete control of models and remote engines. macOS nodes can also have availability quirks after leaving a cluster. These are reasonable caveats for an early release, but a production plan should not replace them with the assumption that the cluster will balance everything automatically.

Security: local does not automatically mean isolated

PAIR is designed for a trusted local network. The six-digit PIN protects only the bootstrap step and has low entropy; it is not a durable secret. After pairing, mTLS protects cluster channels, but it does not cover the entire surrounding stack.

Discovery metadata, the application's local HTTP endpoint and third-party inference-engine APIs are examples outside the mTLS boundary. A local request path also does not prove that the whole stack never connects to the internet: the application, model catalogue, installer, update service or inference engine may make external connections.

A practical business deployment should at least:

• place nodes in a managed network segment and restrict firewall rules;
• admit only inventoried machines and verify the PIN over a separate channel;
• run engines with minimal privileges and pin versions;
• inspect outbound connections from the application, engine and update mechanisms;
• avoid exposing the loopback endpoint without separate authentication and audit controls;
• use a sanitised test set before allowing production documents.

For trade secrets or regulated data, the design must follow the company's threat model and handling rules, not merely the word “local” in the product name.

Economics: measure accepted work, not connected GPUs

NVIDIA demonstrates five agent subtasks completing on three devices in 8 minutes 48 seconds, compared with 18 minutes on one laptop. It is a useful illustration of parallelism, but it is a vendor-run result on a specific configuration, not an independent forecast for another company's hardware.

PAIR can create value for a small business when suitable computers are already owned, sit idle for part of the day and receive concurrent jobs. The pilot then requires little new capital expenditure. “Free compute” still includes electricity, administration, disruption to workstation owners and human review of model outputs.

A model calculation can use:

`cost per accepted result = (energy + support + allocated depreciation + human review) / accepted results`.

The denominator should be accepted documents, answers or classifications per hour—not tokens or peak requests per second. Record median and p95 end-to-end latency, queue time, error rate, cold and warm starts, energy use and the impact on the person who normally uses each workstation.

If concurrent demand is rare, PAIR adds another service with little return. If demand is steady and operationally critical, a dedicated inference server may be simpler to operate than a heterogeneous collection of user workstations.

A one-to-two-week pilot

A safe first experiment fits into a small environment of two or three existing nodes. Use one or two appropriate models, the same engine version where possible, and a set of 100–300 sanitised real requests.

Compare three scenarios:

1. One node without PAIR as the baseline.
2. Two or three nodes with the same model to test a parallel queue.
3. Mixed hardware and different models to test eligibility rules and tail latency.

Run the pilot in shadow mode: the agent can produce an answer, but it cannot change a CRM record, accounting system or document without human approval. Beyond performance, test node loss, an unresponsive engine, request retry behaviour, logging and the procedure for removing a machine from the cluster.

Set the decision threshold in advance—for example, a target number of accepted results per hour with p95 below a business limit and no increase in manual review. Rollback is straightforward: return the application to its original endpoint, remove the nodes from the cluster and uninstall PAIR. Models and data remain in the existing inference engines.

The management takeaway

PAIR is worth evaluating when the company already owns several compatible machines and has genuinely parallel workloads: batch processing, concurrent users or agent subtasks. Inventory the nodes first, choose one measurable process and run a shadow comparison.

If the goal is to run one model that does not fit on any individual computer, this is the wrong tool. Recognising that distinction saves more time than an impressive utilisation chart: the router can shorten a queue, but it cannot remove the physical limits of each node.