On September 3, 2026, NVIDIA released a beta version of "Personal AI Router (PAIR)," which distributes AI inference tasks across multiple PCs in a household. It receives requests from apps that use Ollama or LM Studio and routes the processing to compatible devices on the same network. It works across Windows, Linux, and macOS.
If you have an idle gaming PC or Mac in addition to your regular machine, you can share the workload of an AI agent's tasks between them. However, this isn't a feature that pools GPU memory across devices to run a single massive model. What PAIR increases is the number of independent inference tasks that can be processed simultaneously.
NVIDIA's technical blog showcases a demo in which task completion time was roughly cut in half under a specific configuration. However, reading through the design documents and code in the public repository reveals which kinds of tasks actually benefit, and what happens when you mix PCs of differing performance levels.
Splitting Requests, Not Models
PAIR is not a new inference engine. The PC selected to run the model still does so via the same Ollama or LM Studio as before. PAIR sits in front of this process, receiving requests, choosing where they should run, and returning the response to the original app.
For example, imagine a research agent that divides its work among roles: one that reads gathered materials, one that verifies content, and one that composes the final text. If each role can independently call the model, they can run in parallel on different PCs. The agent itself handles breaking down the work and integrating the results; PAIR simply decides where each inference request goes.
With this approach, where the model is placed directly determines how much work can be distributed. If the requested model exists on only one PC, all requests for it will pile up there. Only once the same model is deployed across multiple machines can the number of possible destinations increase. Rather than sharing a single model file, each node holds its own independent copy.
| Use case | What PAIR can deliver | Remaining constraints |
|---|---|---|
| Placing the same model on multiple machines and sending independent requests simultaneously | Distributes processing to compatible nodes | Each machine needs enough memory to run the model |
| Placing different models on separate PCs | Routes requests to the PC holding the requested model | If a specific model isn't deployed to more machines, its processing capacity doesn't increase |
| Generating a single long response | The chosen PC processes the request | That single request is not split across multiple machines |
| Running a model too large for a single device | No feature pools memory to solve memory shortages | GPU memory is not combined across devices |
Accordingly, the biggest beneficiaries are setups where multiple agents or apps request inference simultaneously. For workflows where each step must wait for the previous response before proceeding, adding more PCs offers little room for parallelization.
The Demo Cut Time Roughly in Half—But It Was a Specific Configuration
In NVIDIA's demo, Hermes Desktop analyzes a fictional household's emails and creates an action plan for what needs to be done tonight and this week. In this task, five sub-agents read evidence, reconcile discrepancies, and integrate the results, using Ollama with "Qwen 3.6 35B A3B" for inference.
The company presented the following average completion times:
| Configuration | Average time |
|---|---|
| RTX Spark laptop alone | 18 minutes |
| Three machines: RTX Spark laptop, DGX Spark, and RTX 5090 | 8 minutes 48 seconds |
Converted to seconds, that's 1,080 seconds versus 528 seconds—a difference of 552 seconds, or 9 minutes 12 seconds. Calculating the reduction as (difference ÷ solo time) and the speedup as (solo time ÷ three-machine time) gives roughly a 51.1% reduction in completion time, or about 2.05 times faster.
However, NVIDIA itself explicitly labels this as an unofficial, configuration-specific demo. It is neither a comparison of the same PC scaled up, nor one that isolates PAIR as the only variable. The hardware participating in the calculation changed entirely, so this result does not demonstrate that speed scales proportionally with the number of machines.
The demo's description also doesn't reveal details such as the number of trials, variance, or quantization settings. It would also be a mistake to read this as a single response becoming faster. What was measured was the completion time for an entire task involving multiple inference calls, and there's no guarantee that the number of sub-agents matches the number of PAIR inference jobs.
The Public Code Prioritizes Lightly Loaded Nodes
Does this mean tasks get routed more heavily to PCs with faster GPUs? The current public implementation doesn't go that far in evaluating performance.
As of the scheduler code checked on September 4, the system prioritizes nodes with lower combined values of pending and running job counts plus a rough load tier derived from GPU utilization. GPU utilization is smoothed so that short-term fluctuations don't cause the ranking to swap frequently.
On the other hand, the design documents explicitly list unsupported items: GPU model, available VRAM, and measured response times. Furthermore, whether the requested model is already loaded into memory is also not factored into prioritization. Having the model stored and being able to immediately start inference are two different things.
As a result, even if you have equally idle high-performance and low-performance PCs, allocation won't necessarily be optimized according to their performance difference. It's possible that a PC that still needs to load the model gets selected over one that already has it loaded. Since both short and long requests are counted equally as "jobs," a lower job count doesn't necessarily reflect a lighter workload accurately.
Notably, the repository's known issues list still contains a note stating that "only job count is considered," which is inconsistent with the README, design documents, and the public code. While the public code does implement logic that factors GPU utilization into ranking, verifying the actual behavior of distributed binaries requires hands-on testing.
When combining PCs from different generations, don't simply judge based on the number of machines added—you need to verify whether adding a slower device actually speeds up completion of the overall task.
Different Levels of Protection for Inference Traffic and Device Information
PAIR is designed for local inference, and uses mutual TLS (mTLS)—which verifies certificates from both sides—for inference traffic between paired nodes. However, not all traffic on the LAN is encrypted.
Cross-referencing the design documents with the security policy reveals the following breakdown of how different types of communication are handled:
| Communication / Information | Handling per public documentation |
|---|---|
| Inference between paired nodes | Protected by mutual TLS |
| Requests from an app to PAIR on the same PC | Plaintext HTTP restricted to local connections |
| Initial pairing | Establishes trust via plaintext communication plus a 6-digit PIN |
| Hostname, hardware info, utilization | Retrievable via unauthenticated plaintext HTTP |
This distinction means PAIR's description of being "local and private" should be understood as a design intended for use on a trusted home network. According to the design documents, devices on the same subnet can read host information and similar data. If deploying on a shared network, you need to separately assess this level of exposure, in addition to considering encryption of the inference content itself.
There are also constraints on how apps connect. Specifying PAIR's URL from another PC to connect directly to a plaintext inference endpoint is not supported. You must install PAIR on the PC running the app as well, and use that PC's own local endpoint. From there, requests get passed on to paired compute nodes, meaning the app-side PC doesn't need a GPU or inference engine of its own.
Also, the design that keeps inference within the LAN doesn't guarantee that all external communication is blocked. The official security policy explicitly states that apps, inference engines, and update systems, among other components, may connect to external services. If you require fully air-gapped operation—including after model acquisition—you'll need to check components beyond PAIR itself.
Compatible PCs Don't Guarantee Every Model Will Run
NVIDIA's technical blog lists GeForce RTX 20 series and later, Turing-generation RTX PRO and later, and DGX Spark as supported hardware. Apple M4 and later are also supported. The public README covers Windows 11, Linux, and macOS, listing Windows on ARM as experimental support.
Here it's important to separate the conditions for PAIR itself to run from the conditions needed to run a chosen model. The product page recommends at least 8GB of RAM and 20GB of disk space, but this isn't a guarantee that any model can run. In addition to OS and driver requirements specific to each inference engine, each node must also satisfy the memory requirements of the model itself.
Setting it up involves installing PAIR on each participating PC and pairing them, then preparing the engine and model on whichever PC will handle computation. Since it's designed to route through existing Ollama or LM Studio interfaces, there's no need to rewrite the agent's processing logic itself. That said, PAIR may not be able to move or stop an engine you've already launched yourself, so it's worth checking the ports being used and how the engine was started.
PAIR's source code is released under the Apache License 2.0. The engines and models you combine it with come with their own separate usage terms.
When trying it out, it's a good idea to measure completion times for your usual workloads and check PAIR's Jobs screen to confirm that multiple nodes are actually being used. If you see genuine improvement—accounting for model placement, performance differences between machines, and output quality—you can turn your spare hardware into local AI processing power.