NVIDIA a publié la version bêta de Personal AI Router (PAIR), un logiciel libre qui répartit des requêtes d'inférence indépendantes entre plusieurs ordinateurs compatibles d'un même réseau local, derrière un point d'accès unique. PAIR ne transforme pas ces machines en un GPU virtuel plus vaste : il répartit les requêtes, sans mutualiser la mémoire graphique ni distribuer un même modèle sur plusieurs nœuds.
Le logiciel fonctionne actuellement avec Ollama et LM Studio et accepte des nœuds Windows, Linux et macOS, notamment des PC RTX, DGX Spark et des Mac équipés d'une puce M4 ou plus récente. Les machines peuvent devenir disponibles ou se retirer du groupe en fonction de leur état, tandis que PAIR choisit une destination pour chaque nouvelle requête.
Pour les développeurs qui exécutent plusieurs agents ou applications d'IA en local, cette approche peut augmenter le débit sans basculer vers une infrastructure distante. Mais sa limite structurelle doit être comprise dès le départ : PAIR élargit la capacité à traiter des requêtes simultanées, pas la mémoire disponible pour charger un modèle plus volumineux.
Un répartiteur de requêtes, pas un modèle distribué
PAIR se place devant les moteurs d'inférence locaux et sert de mandataire. Une application peut continuer à envoyer des requêtes compatibles avec Ollama ou avec l'interface de type OpenAI vers une adresse locale familière. PAIR identifie le moteur et le modèle demandés, retient les machines capables de servir la requête, en choisit une et y maintient l'exécution jusqu'à la fin.
La documentation du projet précise explicitement ce que le logiciel ne fait pas. Il ne regroupe pas la mémoire des GPU, ne fragmente pas un modèle entre plusieurs machines et ne partage pas une requête en cours d'exécution entre plusieurs nœuds. Chaque ordinateur doit donc pouvoir charger et exécuter seul le modèle demandé.
Cette distinction est essentielle, car l'expression « groupe de machines » peut laisser croire à une mémoire cumulée ou à un calcul distribué. PAIR ressemble davantage à un répartiteur local pour l'inférence. Son intérêt apparaît lorsque plusieurs requêtes indépendantes sont prêtes à être exécutées au même moment.
Les systèmes multi-agents s'y prêtent bien. Un agent coordinateur peut lancer plusieurs tâches de recherche, de programmation ou de vérification qui appellent le modèle indépendamment. Au lieu de faire patienter toutes ces requêtes derrière un seul moteur local, PAIR peut les envoyer vers plusieurs machines disponibles.
Le gain présenté par NVIDIA reste propre à une configuration
NVIDIA montre PAIR avec une tâche Hermes Desktop composée de cinq sous-agents, exécutée par Ollama avec Qwen 3.6 35B A3B. L'entreprise indique un temps moyen de 18 minutes sur un seul ordinateur portable RTX Spark, contre 8 minutes et 48 secondes sur un ensemble de trois machines réunissant ce portable, un DGX Spark et une RTX 5090.
Dans cette démonstration, le temps écoulé baisse d'environ 51 %, soit un rythme d'achèvement proche de 2,05 fois celui de la machine seule. Ce résultat ne constitue pas un banc d'essai général. NVIDIA le qualifie elle-même de démonstration non officielle, liée à une configuration particulière, et la comparaison modifie aussi les ressources matérielles disponibles. Le degré de parallélisme, l'emplacement des modèles, les réglages du moteur, le réseau et la disponibilité des nœuds peuvent tous modifier le résultat.
The Verge confirme indépendamment le lancement de la bêta, la publication du code source et l'objectif d'utiliser des machines locales inoccupées pour des tâches parallèles. Le média ne reproduit toutefois pas la mesure de temps annoncée par NVIDIA.
L'affirmation la plus solide est donc architecturale : lorsqu'une charge produit suffisamment de requêtes indépendantes et que plusieurs machines possèdent le modèle nécessaire, PAIR peut réduire l'attente devant un seul moteur.
Une exécution locale suppose que toute la chaîne le soit
PAIR découvre les machines sur le réseau local, utilise un code à six chiffres pour l'association initiale et chiffre les échanges entre nœuds associés avec TLS mutuel. NVIDIA indique que les requêtes, fichiers et données de contexte peuvent rester sur le réseau lorsque l'application, la source du modèle, le moteur d'inférence et les ordinateurs participants sont eux-mêmes locaux.
Cette condition est déterminante. Installer PAIR ne rend pas locale une application dont un autre composant continue à contacter un service externe. La confidentialité doit donc être évaluée sur l'ensemble du chemin suivi par les données.
Le dépôt de code rend également visible une frontière de sécurité concrète : PAIR expose des services HTTP locaux, découvre des machines sur le réseau et gère une identité de groupe ainsi que des certificats. Sur un réseau domestique ou de studio maîtrisé, ce compromis peut être acceptable. Sur un réseau partagé ou hostile, il faut traiter PAIR comme tout autre service accessible sur le réseau, et non comme intrinsèquement sûr parce que le modèle s'exécute sur place.
La capacité dépend surtout du nombre de copies disponibles de chaque modèle
La conséquence pratique pour l'architecture locale est simple : additionner la mémoire de toutes les cartes graphiques donne une vision trompeuse de la capacité.
Si le même modèle est installé sur trois machines capables de l'exécuter, PAIR dispose d'un ensemble plus large pour ses requêtes simultanées. Si le modèle n'existe que sur une machine, toutes les requêtes correspondantes continueront à converger vers elle. Si le modèle est trop volumineux pour chacune des machines prises séparément, ajouter des nœuds PAIR ne le fera pas tenir en mémoire, puisque celle-ci n'est pas mutualisée.
Une mesure plus pertinente consiste donc à compter, pour chaque modèle, le nombre de machines réellement capables de le servir, puis à regarder combien de travaux indépendants l'application peut produire. Pour les concepteurs d'agents, cette contrainte influence la façon de découper les tâches. Des sous-agents indépendants peuvent profiter du routage, alors qu'une longue chaîne séquentielle dominée par un seul appel ne gagnera pas automatiquement en vitesse.
Le placement des modèles devient lui aussi un choix de capacité. Un modèle souvent sollicité peut devoir être répliqué sur plusieurs machines ; un modèle spécialisé et rarement appelé peut rester sur un nombre réduit de nœuds.
Une bêta utile pour le débit, pas pour contourner les limites matérielles
PAIR intéressera surtout les développeurs qui disposent déjà de plusieurs machines compatibles et souhaitent faire tourner plusieurs agents ou applications d'IA simultanément en local. Le fait de conserver des interfaces familières avec Ollama et LM Studio réduit le coût d'intégration dans les outils existants.
Ses limites font pourtant partie de l'information essentielle. PAIR ne résout pas le problème des modèles trop volumineux pour la mémoire d'une machine, n'accélère pas par magie une charge strictement séquentielle et reste une bêta. Le dépôt indique aussi que l'ordonnanceur actuel se fonde sur une combinaison relativement simple de travaux en attente et d'utilisation lissée du GPU ; il ne tient pas encore compte du modèle précis de GPU, de la mémoire disponible, de la présence du modèle déjà chargé ou du coût estimé d'une requête.
Pour une équipe, le bon test n'est donc pas de comparer le nombre de machines, mais d'exécuter sa propre charge de bout en bout et de mesurer l'attente, le temps total, la qualité des résultats et le placement réellement observé.
PAIR est intéressant parce qu'il transpose à l'inférence locale une idée éprouvée : répartir des requêtes vers des ressources disponibles sans obliger les applications à connaître chaque machine. Sa valeur est la plus claire quand sa frontière l'est aussi : il distribue les appels, mais ne fusionne pas les ordinateurs en un GPU géant.