NVIDIA has open-sourced Personal AI Router (PAIR), a project that lets you group several computers on a local network and spread independent AI inference requests across them. Comparing it to a small “Kubernetes for home AI” helps get the idea across, though it comes with an important limit: PAIR doesn’t pool GPU memory, doesn’t split a model across multiple machines, and doesn’t turn several graphics cards into a single virtual GPU.
NVIDIA PAIR in 30 seconds
- PAIR spreads independent inference requests across computers connected to the same local network.
- The project is open source under the Apache 2.0 license and has installers for Windows, Linux, and macOS.
- It offers Ollama- and OpenAI-compatible endpoints to avoid major changes to existing applications.
- Each full request runs on a single node; PAIR doesn’t aggregate VRAM or shard models across machines.
- Its current scheduler has limitations with highly heterogeneous hardware, an area NVIDIA acknowledges it wants to improve.
NVIDIA’s official repository went public in late August and already has packaged releases. The release branch shows PAIR 0.1.x, which makes clear this is still a young project. The idea, however, tackles a problem that’s becoming common among developers running models locally: having several computers capable of running AI, but managing them as completely separate resources.
One PC might have a dedicated GPU. Another machine might have plenty of memory. A laptop sits idle for part of the day. A Mac might be running a different model.
PAIR tries to place a common layer in front of those machines.
How PAIR works, and why it doesn’t pool GPUs
The architecture is considerably simpler than the Kubernetes comparison might suggest.
Every computer where PAIR is installed becomes a node. Several paired nodes form a cluster and can run Windows 11, Linux, or macOS, on both x64 and arm64 architectures. Windows on ARM currently ships as experimental.
There’s no permanent central controller. NVIDIA’s documentation specifies that every node runs the same software.
PAIR discovers the machines available on the local network, checks which engines and models they have ready, and presents client software with a local endpoint. It currently works mainly with engines like Ollama and LM Studio, while the documentation also mentions limited integration with llama.cpp in certain scenarios.
An application can send a request compatible with the OpenAI API:
curl http://127.0.0.1:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{"model":"qwen4:12b","messages":[{"role":"user","content":"Hello"}]}'The application doesn’t need to decide which computer will run that inference.
PAIR receives the request, identifies the nodes able to handle it, picks one, and forwards the job there. The response later comes back through the proxy.
Simplified:
Agent / application
↓
PAIR endpoint
↓
┌─────┼─────┐
↓ ↓ ↓
Node A Node B Node C
GPU A GPU B GPU CThis is where the key difference shows up, and why PAIR shouldn’t be read as some kind of distributed GPU.
A single request is assigned to a single node in full.
If there are five agents running five simultaneous inferences, PAIR can spread those jobs across different machines. But if you try to load a model that needs 100 GB of memory and no single computer individually has that much, having four machines with 32 GB each doesn’t automatically create a combined 128 GB pool.
NVIDIA’s documentation is explicit: PAIR doesn’t combine GPUs, doesn’t aggregate memory, doesn’t shard a model across machines, and doesn’t split an inference that’s already running.
That’s why its usefulness shows up mainly with concurrent workloads.
An environment with several AI agents is a good example. Instead of having five subagents wait in line to use the same GPU, different requests can end up running simultaneously across several computers.
A scheduler for local AI that still has plenty of room to grow
The technically most interesting part is how PAIR decides where to send each request.
A node can only become a candidate once it’s reachable, has a compatible engine running, and has the requested model available.
After that, the scheduler kicks in.
The current documentation explains that the scheduler mainly factors in pending work and a smoothed signal of GPU utilization. Proxies also track the requests they’ve just sent, to keep a burst of traffic from piling up on a single machine before the metrics catch up with the new load.
It’s a first pass at the problem, but NVIDIA acknowledges significant limitations.
The project itself notes that the algorithm currently doesn’t account for the specific GPU model, available memory, whether the model is already warm in memory, or the estimated cost of a request. That’s why PAIR initially fits better with groups of fairly similar machines than with clusters built from radically different hardware.
The company says it plans to improve that part in future versions and possibly allow choosing between different scheduling policies, though it stresses those are development ideas, not product commitments.
This limitation also helps explain one of the community’s first reactions.
The post that drew attention to PAIR points out the lack of proper support for a machine running AMD Strix Halo with ROCm 10 and explains that its author has asked a coding agent to modify the project to add it — the same ROCm 10 platform AMD launched to let AI agents help manage its Instinct GPUs.
That adaptation isn’t currently part of NVIDIA’s official project and can’t be considered supported until working code exists and, if applicable, gets accepted by the maintainers.
But the case illustrates a direct consequence of releasing PAIR under the Apache License 2.0: developers can study the code, modify it, and propose changes through pull requests.
The governance NVIDIA published spells out exactly that process. Maintainers review contributions and decide which ones get merged into the project.
Local AI, local network, and compatibility with existing applications
PAIR also tries to minimize the changes needed in software that already uses local models.
It exposes proxies compatible with Ollama and with OpenAI-formatted APIs. An application can keep sending requests to a local address while PAIR decides which machine ends up running them.
The documentation explains that node discovery uses mDNS, while the model inventory is later pulled from the corresponding engines.
Pairing requires a six-digit PIN. Once that trust relationship is established, traffic between nodes uses mutual TLS (mTLS), and machines that don’t belong to the cluster are rejected.
NVIDIA warns, even so, that the PIN is a temporary mechanism for initially establishing trust and not a high-entropy credential. The recommendation is to pair only machines and networks considered trustworthy.
Local privacy also needs a caveat.
PAIR is designed so that requests and responses stay on the local network when every component involved is also local. That includes the client, models, engines, and nodes. Installing PAIR doesn’t automatically make any external service an application might use “local.”
That model can be appealing for home labs, developers, small distributed workstations, and environments where several agents compete for inference resources.
It also slightly shifts how people think about personal AI hardware.
Until now, the usual way to add capacity was to buy a bigger GPU or move the workload to the cloud. PAIR introduces a third option for certain scenarios: making better use of several machines you already own.
It doesn’t replace distributed training, tensor parallelism, or technologies capable of sharding giant models across accelerators. Nor does it turn three modest computers into one big AI workstation.
Its goal is narrower: if there are several independent inferences and several machines able to run them, keep them from all ending up waiting behind the same resource.
For developers starting to work with multi-agent systems, that distinction may well be the most interesting part of PAIR.
Frequently asked questions
What is NVIDIA Personal AI Router?
PAIR is an open source project that spreads independent inference requests across compatible computers connected to the same local network. Applications can reach it through Ollama- and OpenAI-compatible endpoints.
Does PAIR pool the memory of multiple GPUs?
No. Each request runs entirely on a single node. PAIR doesn’t aggregate VRAM, doesn’t create a larger logical GPU, and doesn’t split a model across multiple computers.
Does PAIR work on Windows, Linux, and macOS?
Yes. NVIDIA supports Windows 11, Linux, and macOS, on both x64 and arm64 architectures. Actual inference compatibility also depends on the engine, the GPU, its drivers, and the model used.
Does NVIDIA PAIR support AMD ROCm?
PAIR can run on different systems, but that doesn’t automatically mean any GPU or inference engine is compatible. The AMD Strix Halo and ROCm 10 adaptation mentioned above comes from an outside developer and isn’t currently official support from the project.