TL;DR: NVIDIA PAIR (Personal AI Router, beta v0.1.1, free, Apache 2.0) turns every Ollama or LM Studio machine on your home network into one cluster behind a single http://127.0.0.1:11434 endpoint. It routes requests, not layers — it will not pool VRAM or run a model too big for any one machine. The quieter IFA news matters more for most readers: llama.cpp is now up to 1.9× faster on RTX cards, no new hardware required.

	NVIDIA PAIR	EXO / Shard-style sharding	llama.cpp router mode
Best for	Many small requests across 2+ PCs	Running one model too big for one GPU	Many models on one machine
What’s distributed	Whole requests, one node each	One model’s layers, across nodes	Nothing — local model switching
The catch	Scheduler ignores GPU speed and VRAM	Slow interconnects tank tok/s	Single point of hardware

Honest take: If you have exactly one GPU, skip PAIR and just update llama.cpp — the free speedup is the real story. Install PAIR when a second machine with a real GPU is already sitting on your LAN; it’s the first genuinely zero-config way to make two Ollama boxes act like one.

NVIDIA announced PAIR at IFA on September 3, 2026, alongside RTX Spark desktop PCs coming in October and a set of llama.cpp optimizations that are already live. The launch coverage blurred those three things together, and Reddit promptly filled with people expecting to “combine” a 3090 and a 3060 into 36GB of VRAM. That is not what PAIR does. Here’s what it actually is, verified against the GitHub repo and docs rather than the press release — the setup that works, the scheduler’s blind spot, and who should bother during the beta.

What PAIR actually is

PAIR is a local inference router. Every machine that runs it advertises itself on your LAN, reports which models its Ollama or LM Studio install can serve, and accepts requests forwarded from other nodes. Your chat UI, IDE plugin, or script talks to one endpoint on your own machine, and PAIR decides which computer answers.

The part most coverage got wrong: PAIR’s own README states it does not pool GPU memory, combine GPUs, shard one model across machines, or split an in-flight request. Each request lands on exactly one node, whole. A model that doesn’t fit on any single machine in the cluster stays unrunnable, PAIR or not. If layer-sharding is what you’re after, that’s EXO or Shard territory, with all the interconnect pain those articles document — or Mesh LLM over iroh if you want P2P without port forwarding.

What PAIR is good at is the boring, common case those tools ignore: you have a gaming PC with an RTX 4070 upstairs, a Mac Mini in the living room, and everything in the house wants to talk to “the AI server” without you managing IP addresses and port maps per device.

The hard facts, from the repo and NVIDIA’s own pages:

• License and price: Apache 2.0, free, full source on GitHub. Signed installers for Windows 11 (.exe), Linux (.deb), and macOS (.dmg), x64 and arm64. Windows on ARM is flagged experimental.
• Version: beta v0.1.1, released August 28, 2026 (v0.1.0 landed August 26 — the point release only fixed build tooling).
• Supported hardware (per NVIDIA’s PAIR page): GeForce RTX 20-series and newer, RTX PRO from Turing on, DGX Spark / GB10 systems, and Macs on Apple M4 or newer, with 8GB RAM minimum and 20GB+ disk recommended. Notably, a node with no GPU at all can still join and route — it just can’t serve inference.
• Backends: Ollama and LM Studio at launch. PAIR finds existing installs and “adopts” running instances rather than spawning duplicates.

Setup: two machines in about ten minutes

We’ll assume the common case — a Windows gaming PC with the GPU and a second machine (laptop, Mac, mini PC) that wants to use it.

Install on both machines. Windows and macOS are double-click installers; on Linux:

sudo apt install ./NVPAIR-Setup-*.deb
# then launch "NVIDIA Personal AI Router" from the app menu

Pairing works like a Bluetooth speaker: on machine A, hit Add node in the toolbar, pick the discovered machine (or type its IP if discovery fails — more on that below). Machine A displays a six-digit PIN; type it into the accept dialog on machine B. That PIN bootstraps mutual TLS with pinned certificates, so after pairing, all inference traffic between nodes is encrypted and strangers on your Wi-Fi can’t join silently.

On the GPU machine, expand Engine settings, let PAIR install Ollama if it isn’t there already (or adopt your existing install), and pull a model. Then point any app at the local proxy:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-oss:20b", "messages": [{"role": "user", "content": "Which machine are you running on?"}]}'

That request returns a normal OpenAI-format completion — served by whichever node PAIR picked. The clever part is the port arrangement: PAIR’s proxy takes over Ollama’s default port 11434 and moves the real Ollama to 11435 (LM Studio: proxy on 1234, engine to 1235). Every app you already configured for localhost:11434 — Open WebUI, Continue.dev, a cron script — gains cluster routing without a single config change. If you use local models as a BYOK backend for coding tools like Cursor or Cline, the same trick applies; see aicoderscope.com’s Continue.dev + Ollama setup for the editor side.

One real gotcha from that port move: if you had scripts talking directly to Ollama and you want them to bypass PAIR (say, for ollama pull automation against the local instance only), they’re now talking to the proxy. The engine itself answers on 11435, bound to loopback only.

How it decides where your request goes

Under the hood (architecture docs), discovery is mDNS with a custom responder — each node broadcasts a _nvpair-node._tcp record every advertisement cycle, and the scanner sweeps every 5 seconds, evicting a node only after 3 consecutive misses plus a liveness double-check. Routing is a failover list: nodes that actually have the requested model, ranked by pending workload count plus a coarse GPU-pressure score (utilization bucketed at 40%, 70%, and 85% thresholds), reconciled on a 1-second timer.

Read that ranking description again, because it contains the beta’s biggest limitation, and NVIDIA’s own known-issues page is refreshingly blunt about it: the scheduler counts jobs. It does not consider GPU model, available memory, whether the model is already loaded, or how expensive a request looks. On a mixed cluster, work distributes essentially randomly between your fastest and slowest cards.

With site-canon llama.cpp numbers: a used RTX 3090 generates around 161 tok/s on gpt-oss-20b and an RTX 5090 around 282 tok/s (llama.cpp benchmark thread #15396). Put both in a PAIR cluster and an idle-ish 3090 will happily take requests while the 5090 sits at 30% — the scheduler sees two eligible nodes with similar queue depth and doesn’t know one is 75% faster. You can pin a node manually per the docs, but that defeats the point of a router.

This has a practical buying implication: PAIR does not turn a drawer of old 8GB cards into a good cluster. Every node still serves whole requests alone, so each node is only as useful as its own VRAM ceiling — run your models through the VRAM calculator per machine, not summed. One strong card plus one modest card beats four weak ones here; if you’re speccing the “strong card” node, the math in our GPU buyer’s guide by budget still points at the used RTX 3090 (~$1,000–$1,050 on eBay sold listings, September 2026) as the anchor.

Problems you’ll actually hit

Discovery finds nothing. mDNS is multicast, and plenty of routers (and most mesh systems’ guest/IoT SSIDs) block it. Fix: PAIR supports manual entry — Add node → enter IP address — which the docs explicitly provide for multicast-blocking networks. Put both machines on the same SSID/VLAN first; pairing across subnets adds firewall work the beta doesn’t document.

macOS node goes deaf. A listed known issue: a Mac left running PAIR unclustered for a while can stop answering LAN connections. Restart PAIR on the Mac before assuming your network broke.

Unified-memory machines report near-zero GPU memory. On Windows iGPU/unified-memory boxes, PAIR counts only dedicated VRAM, so a Ryzen AI Max machine can display almost none. Display-only bug — routing doesn’t use VRAM anyway (see above, for better and worse).

The part single-GPU owners should care about: llama.cpp got up to 1.9× faster

Buried under the PAIR headlines, NVIDIA’s IFA announcement included the number that affects the most readers: llama.cpp throughput on RTX is up to 1.9× faster from kernel optimizations, enhanced speculative decoding, and faster prefill — with the 1.9× measured on an RTX 5090, per NVIDIA, and roughly +50% on Qwen3.6-27B and +90% on Qwen3.6-35B-class models. The multi-token prediction work behind part of it (a model drafts several tokens per forward pass, no separate draft model) landed through NVIDIA’s collaboration with the llama.cpp community and is in current builds — we covered the mechanism in the mid-2026 speedup explainer and the hands-on numbers in the speculative decoding setup guide.

Treat “1.9×” the way you treat every vendor multiplier: it’s the best case on the flagship card with a favorable model/workload combination. The honest expectation on a 3090/4090 running a 27B dense model is the +50% class, and only when the optimized code path applies. It is still the best free upgrade of the quarter — git pull && cmake --build (or update Ollama/LM Studio, which vendor these kernels downstream) costs you nothing.

RTX Spark desktops: the October context

The third leg of the IFA announcement: RTX Spark Windows PCs ship in October from Acer, Lenovo (Yoga Pro 9n and Yoga 9n 2-in-1), and other OEMs — around 1 petaflop of Blackwell compute, up to 128GB unified memory, and a 20-core Grace CPU in the top configuration, with a cut-down laptop chip (24/32GB, 18 CPU cores, 5,120 GPU cores) expected near $2,000. These are the desktop siblings of the laptop-class Spark we covered in June; PAIR is transparently the software story that makes a Spark box, your existing RTX tower, and a MacBook read as one system. We’ll do the buy/skip math when real prices and memory-bandwidth numbers exist — history with the DGX Spark’s bandwidth ceiling says wait for measurements, not TOPS.

Verdict: who should install the beta

Install it now if you have two or more machines with usable inference hardware (any RTX 20-series+, or an M4+ Mac). Adoption of existing Ollama installs plus the port-takeover trick means the migration cost is nearly zero, and mutual-TLS pairing is a real security upgrade over the OLLAMA_HOST=0.0.0.0 exposure most multi-machine setups run today.

Skip it if you have one GPU (update llama.cpp instead — that’s where the free performance is), if you need one big model across multiple cards (that’s EXO/Shard, not PAIR), or if you need multi-model juggling on a single box (llama.cpp router mode already does that locally). And if your second “machine” doesn’t exist yet, an hour of rented GPU on RunPod is still the cheapest way to find out whether your workload even needs more concurrency before you buy anything.

It’s a v0.1 beta and it shows — job-count-only scheduling, a TUI that can’t manage models, .deb-only Linux packaging. But it’s Apache 2.0, the architecture docs are honest about every one of those limits, and it solves the actual problem multi-machine home labs have. That’s more than most 1.0s ship with.

FAQ

Does PAIR combine the VRAM of my GPUs? No. Each request runs entirely on one node. A 3090 (24GB) plus a 3060 (12GB) cluster can serve a ~20GB model only on the 3090; the 3060 handles requests for models that fit in 12GB. Nothing about PAIR changes which models you can run — only how many requests you can serve at once.

Do I need an NVIDIA GPU on every machine? No. Macs with M4 or newer chips are supported nodes, and a machine with no GPU at all can still join the cluster, route requests, and act as a client. It just won’t serve inference.

Does my data leave my network? Inference requests travel directly between your machines over mutual TLS with certificates pinned at pairing time. Loopback clients connect in plaintext but non-loopback plaintext connections get a 403. One caveat from the architecture docs: telemetry between nodes is deliberately unauthenticated plaintext on the LAN.

Which apps work with it? Anything that speaks the Ollama API or the OpenAI API. PAIR sits on Ollama’s default port (11434) and LM Studio’s (1234), so existing apps typically need zero reconfiguration.

Is the llama.cpp 1.9× speedup part of PAIR? No — separate announcement, same event. The kernel and speculative-decoding improvements are in llama.cpp itself (and flow downstream into Ollama and LM Studio builds), and they apply on a single machine with no PAIR involved.

Sources

• NVIDIA Personal AI Router — GitHub repository, README, and releases (v0.1.0/v0.1.1)
• PAIR architecture documentation — discovery, scheduling, ports, security
• PAIR getting-started documentation — setup flow and endpoints
• PAIR known issues — scheduling and platform limitations
• Sparks Fly: NVIDIA Accelerates Local AI at IFA 2026 — NVIDIA Blog
• NVIDIA Personal AI Router product page and FAQ — supported hardware
• NVIDIA local AI optimizations: llama.cpp/vLLM up to 1.9× — Wccftech
• NVIDIA RTX Spark PCs land in October — HotHardware
• RTX Spark available in October with PCs from Acer and Lenovo — Aroged
• gpt-oss-20b benchmark thread — llama.cpp discussion #15396
• Used RTX 3090 sold prices, September 2026 — BestValueGPU

Last updated September 9, 2026. PAIR is beta software and prices/specs change; verify current requirements on the GitHub repo before deploying.