The Short Answer
NVIDIA open-sourced PAIR, the Personal AI Router, under Apache 2.0 on September 3, 2026. It is a router, not a cluster: it sends each independent request to one eligible node and never shards a model or pools VRAM. Nodes need an RTX 20-series GPU or newer, a DGX Spark, or Apple M4 silicon. With ibl.ai you own all the code and the data.
The distinction between routing and clustering is the whole engineering story, and it decides what you can and cannot run.
What exactly did NVIDIA release when it open-sourced PAIR?
A local inference router, released in beta and announced at IFA on September 3, 2026.
PAIR stands for Personal AI Router. The source is on GitHub under Apache 2.0, with graphical and terminal interfaces for Windows, macOS and Linux.
What it actually does is narrow and well-scoped. It discovers participating machines on the same network, tracks which inference engines and models each one has loaded, and presents a single Ollama-compatible and OpenAI-compatible endpoint to your applications and agents.
At launch it drives two engines: Ollama and LM Studio. Your agent harness points at one address and does not need to know how many machines are behind it.
That is a genuinely useful piece of plumbing. It is not a new inference runtime, and it is not a distributed one.
Does PAIR turn idle machines into a local AI inference cluster?
No, and NVIDIA says so directly. The widely-shared framing is marketing compression, and it inverts the part that determines whether the thing works for you.
The repository states that PAIR "routes each independent request to one node" and 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.
The NVIDIA technical blog repeats the point: it does not merge GPUs or pool VRAM into one larger accelerator.
A cluster in the sense people mean — tensor parallelism, a model too large for one card split across several — is a different technology with different requirements, usually a fast interconnect and identical hardware.
PAIR is the opposite design. It assumes machines are heterogeneous and intermittently available, and it wins by running many requests concurrently, not by running one request faster.
So the binding constraint is unchanged: every model must still fit on a single node's memory. Three machines that each hold a 12B model give you three 12B workers, not one 36B model.
Which machines can actually join a PAIR network?
Far fewer than "every idle machine on your network."
NVIDIA's system requirements list GeForce RTX GPUs from the 20 Series onward, RTX PRO workstation GPUs on Turing or newer, DGX Spark, or Apple M4 silicon and later, with at least 8 GB of system RAM and 20 GB or more of storage per node.
The operating system is gated too: Windows 11 or macOS Tahoe.
There is no CPU-only path. A five-year-old office desktop with integrated graphics is not a node, and neither is an Intel-era MacBook. Nor is a Windows 10 box, whatever GPU is in it.
| The claim | What NVIDIA documents |
|---|---|
| Turns machines into a cluster | Routes each independent request to one node; no VRAM pooling, no model sharding |
| Every idle machine | RTX 20 Series or newer, RTX PRO (Turing+), DGX Spark, or Apple M4+; at least 8 GB system RAM, 20 GB or more storage; Windows 11 or macOS Tahoe |
| No cloud | Accurate — no network access required to operate, only to download models |
| No per-seat license | Accurate — Apache 2.0, free |
Two of the four claims survive contact with the documentation. The two that do not are the two that decide your hardware budget.
What is PAIR genuinely good for, and what is it not good for?
It is good at concurrency for agentic workloads, and NVIDIA's own published example is the honest version of the pitch.
Running a five-subagent workload on Qwen 3.6 35B A3B, a single RTX Spark laptop averaged 18 minutes.
A three-device group — that laptop plus a DGX Spark and an RTX 5090 — averaged 8 minutes 48 seconds.
NVIDIA labels this an unofficial, configuration-specific demo rather than a general benchmark or a promise of linear scaling, which is the right caveat.
Notice the shape of that result. Roughly a 2x improvement from three machines, on a workload that was already five parallel subagents. The gain comes from parallelism, so it exists only when you have independent requests in flight.
Where it helps: multi-agent harnesses, batch document processing, evaluation runs, a small team sharing inference capacity, and anything where latency per request matters less than throughput across requests.
Where it does not help: a single long generation, a model larger than any one node can load, and anything needing predictable latency. Routing adds a hop and a scheduling decision, and a node that is "available" is one someone may be about to use for their actual job.
That last point is the unglamorous limit on idle capacity generally.
Idle machines are real, but they are idle on someone else's schedule, which is why office desktops make a poor foundation for a service other people depend on.
For a production serving tier the self-hosted LLM serving stack — vLLM or TGI on dedicated hardware — remains the answer, and PAIR is not competing with it.
One more thing worth saying plainly: local is not automatically isolated. Machines sharing a host or a network still share hardware, and cache side-channel work on local LLMs shows that co-residency has a threat model of its own.
Why does this matter for enterprise AI pricing?
Because the free, Apache-2.0, no-license-key part of the story is the part that generalizes, and it is an argument about pricing shape rather than about NVIDIA.
Per-seat AI licensing bills headcount, not use. Microsoft 365 Copilot is listed at $30 per user per month on an annual commitment. At 2,000 employees that is $720,000 a year whether those seats generate one request a day or none.
Local inference has no seat count in it at all. The cost is the hardware you already own plus electricity, and it does not move when you hire. That is the structural point: per-seat is the wrong shape for AI at scale, not one pricing option among several.
PAIR makes that visible at the scale of one office. The same arithmetic applies to a platform.
How does ibl.ai handle local and on-device inference?
With ibl.ai you own all the code and the data.
The platform runs on your own infrastructure with full source code access, is model-agnostic across any LLM so you can switch providers without rewriting anything, is usage-based with no per-seat pricing, and can deploy anywhere — your own cloud, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity.
On-device inference is part of that picture rather than a separate product.
The September 4, 2026 platform update shipped an on-device LLM provider picker: the LLM tab and provider modal now surface on-device providers and models alongside hosted ones, so an operator selects where a given agent's inference runs.
That is the same architectural property PAIR is reaching for, applied to the whole stack instead of the routing layer. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
ibl.ai is family-owned and operated from New York, NY.
Related reading: self-hosted LLM providers: Ollama vs vLLM vs TGI vs LocalAI — what each runtime is actually for, and the hardware each one needs.
Sources: the Apache 2.0 licence and the explicit "does not pool GPU memory, shard one model across machines" statement from the NVIDIA/Personal-AI-Router repository; the September 3, 2026 IFA announcement from the NVIDIA blog; the Qwen 3.6 35B A3B timings and the no-VRAM-pooling statement from the NVIDIA technical blog; system requirements from the NVIDIA PAIR product page; Copilot pricing from Microsoft.