NVIDIA Personal AI Router (PAIR): a LAN router for Ollama and LM Studio nodes
Router that virtually distributes inference across connected devices in the home.
At a glance
- What is it?
- PAIR discovers machines on your network, manages Ollama and LM Studio on them, and exposes one OpenAI-compatible endpoint that dispatches each independent request to a node. It routes requests; it does not pool VRAM or split a model.
- Who is it for?
- Adopt PAIR if you run several local machines with Ollama or LM Studio and want one OpenAI-compatible endpoint that picks a node per request, especially for concurrent agent workloads. Skip it if you need one model larger than a single machine's memory, or if you expect it to combine GPUs.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 19, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What PAIR solves for a home or lab full of machines
The README frames PAIR as a local inference router for a group of compatible computers on the same network. The problem it addresses is not model quality but placement. When you have more than one machine that can run an engine, deciding which one should serve a given request is manual work, and it gets worse when several agents are asking at once. PAIR discovers participating nodes, manages supported inference engines, and presents Ollama-compatible and OpenAI-compatible proxy endpoints to applications and agents. Independent requests can be routed to eligible nodes according to engine availability, model availability, and current workload.
The intended audience is narrow and specific. The README names concurrent local workloads such as multi-agent applications. If you run a single machine and a single model, PAIR adds a service layer for no routing benefit. If you run several machines and want prompts and responses to stay on the local network, the README states that this holds when every configured client, model source, engine, and node is local. That sentence is a conditional, not a guarantee: the privacy property follows from every component being local, and PAIR cannot enforce it if a client points somewhere else.
The most important sentence in the README is the disclaimer. PAIR routes each independent request to one node. It does not pool GPU memory, combine GPUs into a larger logical GPU, shard one model across machines, or split an in-flight inference request between nodes. Anyone arriving from the phrase "AI powered router" expecting a distributed inference engine should read that twice. PAIR is a dispatcher, not a parallelism layer.
How routing works: nodes, engines, models, and one request per node
The mechanism visible in the documentation has four moving parts. Nodes are machines on the same network that have been paired. Engines are Ollama or LM Studio, and PAIR manages them: the desktop UI can install an engine on a node, and the README says PAIR downloads and sets the engine up for you. Models are pulled per node, and PAIR prefers the nodes it already knows hold the model. Workload is the current state of each node, which the Overview screen reports as live GPU and memory use.
A request arrives at a proxy endpoint, PAIR selects an eligible node from the set that is running a compatible engine and already holds the model, and the request runs there. The README's demo description matches this: requests arrive on one machine, run on whichever node suits each one, and both report live GPU and memory use throughout. There is no queueing semantics described, no retry policy, and no partial execution. One request, one node, start to finish.
That design has a direct consequence. The README states that PAIR running on a machine does not mean an engine will, because each engine sets its own requirements for operating system, GPU, and drivers, and each model needs enough memory to load. A node only becomes a candidate for a request once it is actually running a compatible engine. So the routing table is not a static list of your hardware; it is whatever subset of your hardware currently has a working engine and the right model on disk. A machine with a great GPU but no engine installed is invisible to the router. This is honest scoping, but it also means capacity planning happens outside PAIR, in each engine's own compatibility matrix.
Installing PAIR and sending a first request across two machines
The README recommends the released desktop build and says the rest of the guide assumes it. Released installers are signed, set up the background services and the desktop application together, and add the firewall rules PAIR needs on Windows. They also check an update feed and install newer releases on your say-so from Settings, Service. A build you make yourself is unsigned and checks no update feed, so you would upgrade it by pulling and rebuilding.
Downloads come from the GitHub releases page and include a Windows installer, a Debian package for Linux, and a macOS disk image. On Windows and macOS you double-click and follow the installer prompts; on macOS that means dragging NVIDIA Personal AI Router to your Applications folder. On Linux, install the package from the directory you downloaded it into:
sudo apt install ./NVPAIR-Setup-*.debThe README notes that if you have kept more than one PAIR package in that directory, you should install the one you want by its full filename instead, because the wildcard will not disambiguate for you.
Open PAIR the way you would any application. Overview shows this machine once the services are up; if it stays on Loading..., the README points you to Settings, Service to read the status there. Then get an engine running: on the node's card, open Engine settings and select Install next to Ollama or LM Studio. PAIR downloads and sets the engine up, so nothing needs to be in place beforehand. If PAIR already found an engine you installed yourself, start that one instead.
Add a model from the same card. The README uses qwen4:12b for the example and says it can be replaced with a model of your choice. To send a request, there are two paths. Settings, Service has a Test button that sends a minute of inference through the same path, which is the fastest way to see jobs appear. Or send one yourself. With Ollama on its default port, this runs as written:
curl http://127.0.0.1:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"qwen4:12b","messages":[{"role":"user","content":"In one sentence, what does a router do?"}]}'The reply is ordinary OpenAI-shaped JSON, with an object field of chat.completion, the model name, a choices array, and a finish_reason of stop. The job then appears under Jobs, naming the node that served it. If you changed a port, or you are using LM Studio rather than Ollama, the README says to copy the URL from Endpoints, API endpoints instead of assuming the one above. To route across machines, pair a second one from Settings, Cluster and repeat the engine and model steps there: the inviting machine shows a six-digit PIN, and you enter that PIN on the machine you are adding.
The limits: no sharding, no pooling, and a narrow engine list
The wrong-tool case is stated by the project itself. If your goal is to run a model that does not fit on one machine, PAIR will not help, because it does not shard a model across machines or split an in-flight request. You would need a different class of tool, and no amount of pairing changes the memory ceiling of the smallest node you route to.
The engine list is two entries: Ollama and LM Studio. If your inference stack is something else, PAIR cannot manage it, and the routing eligibility described in the README is defined in terms of compatible engines. There is no documented generic backend interface.
Platform support has an explicit caveat: Windows 11, Linux, and macOS on x64 and arm64, with Windows on ARM marked experimental. Mixing nodes across the three operating systems is supported, which is the more useful property for a home network where machines accumulate over years.
Installation coverage is uneven. The README lists a Windows .exe, a Linux .deb, and a macOS .dmg, and directs other Linux distributions to build from source. That is a real constraint for Fedora, Arch, or container-first users, and building from source is explicitly described as not the ordinary path. The Makefile confirms the developer route is Linux and macOS only, with Windows development using the desktop npm scripts and services build script directly, and it records minimum versions of Go 1.25 and Node 25.5.0. Those are recent toolchain floors, not incidental ones.
Finally, the update story differs by install method. A released installer checks an update feed and installs newer releases on your say-so. A self-built binary checks nothing. If you build from source for an unsupported distribution, you own the upgrade loop.
How PAIR differs from a single Ollama server and from vLLM
The obvious alternative is running Ollama on one machine and pointing every client at that machine's port. That works, and it is simpler. The difference is what happens under concurrency: with one Ollama instance, every request competes for the same GPU. PAIR's contribution is that independent requests can be routed to eligible nodes according to engine availability, model availability, and current workload, so a second machine becomes usable capacity rather than a spare. If your workload is one interactive chat at a time, a single Ollama install gives you the same result with fewer services and no pairing step.
The other comparison worth drawing is with tensor-parallel serving stacks such as vLLM. Those take the opposite approach: they split one model or one batch across multiple GPUs so that a single large model can be served with higher throughput. PAIR explicitly does not do that. The two are not substitutes. If your problem is one model too large for one card, vLLM-style sharding is the relevant tool. If your problem is many small independent requests and several modest machines, PAIR's per-request dispatch fits, and a sharding stack would be overkill. The README's own framing, that PAIR is useful for concurrent local workloads such as multi-agent applications, points at the second case.
Maintenance, licence, and what upgrading actually costs
The repository is not archived and the last push was on 2026-09-15, two days before this writing, so the project is being worked on rather than parked. Releases are early: v0.1.0 on 2026-08-26 and v0.1.1 on 2026-08-28. At 0.1.x, expect interface churn in the desktop UI and in configuration, and treat the documentation as the current source of truth rather than a stable contract.
Upgrade cost depends on how you installed it. The README says a released installer tells you when a newer release exists and installs it on your say-so from Settings, Service. A build you make yourself is unsigned and checks no update feed, so you would upgrade it by pulling and rebuilding. For the source route, the Makefile exposes developer entry points and pins minimum Go and Node versions, so an upgrade can require a toolchain bump before it requires anything else. There is no documented rollback procedure in the README.
The licence is Apache-2.0, declared in the README badge and in the SPDX headers at the top of the README and the Makefile. That is a permissive licence with an explicit patent grant, and it is the same licence NVIDIA uses across many of its open source repositories. Two practical notes, not legal advice: the repository ships a THIRD_PARTY_NOTICES.md, which matters if you redistribute a build, and it ships a SECURITY.md, which tells you where to report issues rather than how they are triaged. If you plan to redistribute PAIR inside a product, read those two files and the LICENSE itself before relying on the badge.
Editorial conclusion
Adopt PAIR if you run several local machines with Ollama or LM Studio and want one OpenAI-compatible endpoint that picks a node per request, especially for concurrent agent workloads. Skip it if you need one model larger than a single machine's memory, or if you expect it to combine GPUs. Before pairing anything, verify that each node actually runs an engine and holds the model, that the firewall rules the installer adds are acceptable on Windows, and that your clients can point at the endpoint listed under Endpoints, since a changed port breaks the default curl example.
Frequently asked questions
What is an AI powered router, and is NVIDIA Personal AI Router one?
In PAIR's case the term means a router for inference requests, not for network packets. The README describes it as a local inference router that discovers participating nodes, manages Ollama and LM Studio, and exposes Ollama-compatible and OpenAI-compatible proxy endpoints so independent requests can be routed to eligible nodes.
How do AI routers like NVIDIA Personal AI Router work?
PAIR pairs machines on the same network, installs or detects an engine on each node, and pulls models per node. Each independent request is then sent to one eligible node based on engine availability, model availability, and current workload, and the job is listed under Jobs with the node that served it.
Is there any AI hardware requirement for NVIDIA Personal AI Router?
PAIR itself runs on supported Windows 11, Linux, or macOS machines on x64 and arm64, with Windows on ARM marked experimental. The README states that PAIR running on a machine does not mean an engine will, because each engine sets its own operating system, GPU, and driver requirements and each model needs enough memory to load.
Does NVIDIA Personal AI Router need a GPU, and what does an AI GPU cost?
The README does not document GPU requirements for PAIR itself; it defers to each engine's own documentation for operating system, GPU, and driver requirements. It also gives no pricing information for GPUs or any other hardware, so cost is outside what the repository states.
Community notes