NVIDIA PAIR répartit les tâches de votre agent IA entre les PC de la maison

Votre PC gaming lance un jeu, votre portable se réveille et une autre machine de la maison prend en charge une partie du travail de votre agent IA. NVIDIA PAIR veut rendre ce scénario presque transparent : l’application continue d’appeler une seule adresse locale, tandis qu’un routeur choisit le PC disponible pour chaque requête. La promesse est séduisante, mais elle doit être comprise correctement : PAIR ne fusionne pas les cartes graphiques et ne transforme pas plusieurs petites VRAM en une grande.

Présenté à l’IFA 2026, NVIDIA Personal AI Router est disponible en bêta gratuite et open source. Le logiciel fonctionne avec Ollama et LM Studio sur des machines compatibles Windows, Linux ou macOS. Son intérêt apparaît surtout lorsque plusieurs agents, sous-agents ou applications envoient des demandes indépendantes en même temps.

NVIDIA PAIR ne crée pas un GPU géant dans votre maison

Le mot « cluster » peut prêter à confusion. La documentation de prise en main de PAIR l’écrit explicitement : une requête est envoyée à un seul nœud. Le logiciel ne combine pas la mémoire des GPU, ne crée pas une carte graphique logique plus grande et ne répartit pas un même modèle entre plusieurs ordinateurs.

Deux PC équipés chacun de 8 Go de VRAM ne deviennent donc pas une machine capable de charger comme par magie un modèle exigeant 16 Go. Chaque ordinateur doit pouvoir accueillir seul le modèle demandé. Si le même modèle est installé sur plusieurs nœuds, PAIR dispose simplement de plusieurs destinations possibles pour les requêtes suivantes.

La différence ressemble à celle qui sépare une autoroute plus large d’une voiture plus rapide. Ajouter des machines permet de faire circuler davantage de demandes simultanément. Cela ne rend pas nécessairement une demande individuelle plus rapide. Le bénéfice dépend donc de la capacité du logiciel ou de l’agent à produire plusieurs travaux réellement indépendants.

Le vrai scénario : un agent principal et plusieurs sous-agents

Imaginez un agent chargé de préparer le lancement d’une application. Il délègue la vérification des tests à un premier sous-agent, la documentation à un deuxième et l’analyse de sécurité à un troisième. Sans PAIR, leurs appels peuvent s’empiler devant le même moteur local et se disputer le même GPU.

Avec PAIR, chaque appel arrive sur un proxy local. Le routeur vérifie quelles machines sont joignables, quel moteur y fonctionne, si le modèle exact est installé et combien de travaux sont déjà actifs. Il peut alors envoyer les requêtes indépendantes vers des nœuds différents. La machine principale continue de voir une seule connexion et reçoit les réponses en streaming.

Cette architecture correspond particulièrement bien à Hermes Agent, que nous avons déjà installé sur un serveur dédié avec Plesk. NVIDIA utilise justement Hermes dans sa démonstration : l’agent organise le travail et crée les sous-agents, tandis que PAIR décide uniquement où chaque inférence doit tourner. PAIR n’est ni l’agent ni le moteur d’inférence.

18 minutes contre 8 minutes 48 : ce que montre réellement la démo NVIDIA

Dans son article technique consacré à PAIR, NVIDIA décrit une mission confiée à Hermes Desktop. Cinq sous-agents analysent différentes parties d’une boîte de réception synthétique, rapprochent leurs conclusions puis produisent un plan consolidé.

Avec Qwen 3.6 35B A3B sur un seul portable RTX Spark, NVIDIA annonce une moyenne de 18 minutes. Un cluster composé d’un portable RTX Spark, d’un DGX Spark et d’une RTX 5090 termine la même démonstration en 8 minutes et 48 secondes en moyenne.

Ce résultat ne constitue pas un benchmark universel. NVIDIA le qualifie elle-même de démonstration non officielle et dépendante de la configuration. Trois machines très différentes ne permettent pas de prédire le gain obtenu avec deux PC domestiques. Le résultat dépend du modèle, de la parallélisation réelle, de la charge des nœuds, du moteur, du réseau et du temps nécessaire à l’agent pour consolider les réponses.

Il faut aussi distinguer cette démonstration de l’annonce « jusqu’à 1,9× ». Ce chiffre concerne des optimisations de llama.cpp mesurées par NVIDIA sur une GeForce RTX 5090, notamment les noyaux, le décodage spéculatif et le prefill. Il ne mesure pas le gain apporté par PAIR et ne doit pas être appliqué à n’importe quel PC.

Quels ordinateurs peuvent participer au cluster PAIR ?

La bêta annoncée prend en charge les GeForce RTX série 20 et plus récentes, les GPU professionnels RTX à partir de l’architecture Turing, DGX Spark et les Mac équipés d’une puce Apple M4 ou plus récente. Le logiciel propose une interface graphique et une interface terminal pour les machines sans bureau.

Les nœuds n’ont pas besoin d’être identiques. Un ordinateur peut héberger un modèle compact, un autre un modèle plus exigeant et un troisième la même référence pour absorber davantage de requêtes. PAIR ne route cependant un appel que vers une machine qui possède déjà le modèle exact et un moteur compatible en fonctionnement.

Cette souplesse ne signifie pas que tout ancien portable devient utile. Une machine sans accélération compatible peut éventuellement exécuter le proxy local, mais elle ne devient pas pour autant un bon serveur d’inférence. Avant tout achat, il faut mesurer la VRAM réellement disponible, la compatibilité du modèle, la vitesse et la consommation des appareils déjà possédés.

Installer PAIR : le parcours en cinq étapes

1. Installer PAIR sur chaque machine participante. NVIDIA fournit actuellement des installateurs Windows, Debian et macOS, ainsi qu’une interface terminal.
2. Associer les ordinateurs sur un réseau de confiance. Une invitation et un code à six chiffres établissent l’appairage entre les nœuds.
3. Activer Ollama ou LM Studio. PAIR peut aider à installer le moteur ou détecter une installation existante.
4. Télécharger les modèles nécessaires sur chaque nœud. Pour qu’une requête puisse basculer entre deux machines, le même modèle doit être prêt sur les deux.
5. Pointer l’agent vers l’adresse locale de PAIR. Une application configurable utilise l’endpoint Ollama ou compatible OpenAI exposé sur 127.0.0.1.

La vue « Jobs » sert ensuite de preuve. Le nombre de sous-agents ne suffit pas à démontrer une exécution multinœud : un agent peut effectuer plusieurs appels et le routeur peut malgré tout les envoyer au même PC. Il faut vérifier dans la télémétrie PAIR quel nœud a réellement traité chaque travail.

Les données restent locales, mais le réseau doit être digne de confiance

PAIR découvre les machines avec mDNS, mais la découverte n’accorde aucun accès. L’utilisateur doit approuver l’association et saisir le code affiché sur l’autre appareil. Après l’appairage, les échanges entre nœuds utilisent une authentification TLS mutuelle et des certificats générés pour le cluster.

NVIDIA rappelle cependant que le code à six chiffres sert à amorcer la relation, pas à protéger durablement un réseau hostile. Il faut associer les appareils uniquement sur un LAN de confiance. L’endpoint utilisé par l’application écoute en local sur la machine de travail ; les communications intermachines passent ensuite par les services PAIR.

« Local » ne signifie pas automatiquement « sûr ». Le modèle, le moteur, les fichiers et les outils de l’agent restent soumis à leurs propres risques. Notre analyse des SKILL.md malveillants montre pourquoi un agent local peut encore exécuter une instruction dangereuse. PAIR réduit la dépendance au cloud pour l’inférence ; il ne remplace ni l’isolation, ni le contrôle des permissions, ni l’audit des extensions.

Le protocole Okibata pour savoir si un deuxième PC apporte vraiment quelque chose

Le benchmark utile doit conserver le même modèle, la même quantification, les mêmes prompts et les mêmes critères de réussite. Il faut comparer au moins trois configurations : un PC seul, deux machines associées avec PAIR, puis l’API cloud choisie pour la même catégorie de tâche. Une mission parfaitement séquentielle favorisera peu PAIR ; un workflow de cinq sous-agents indépendants lui donnera davantage d’occasions de répartir la charge.

Relevez pour chaque essai :

• le délai avant le premier token et la durée totale de la mission ;
• le débit moyen en tokens par seconde pour chaque nœud ;
• le nombre de requêtes réellement réparties entre plusieurs machines ;
• la consommation à la prise de chaque PC, y compris au repos ;
• les erreurs, chargements de modèles et reprises nécessaires ;
• la qualité du résultat final et le temps humain de correction ;
• la gêne ressentie lorsqu’un PC sert en même temps au jeu ou au travail.

Testez aussi le retrait d’un nœud : mettez le portable en veille ou lancez un jeu sur la machine principale, puis observez si les nouvelles requêtes sont routées vers un autre appareil éligible. Une tâche déjà lancée ne migre pas en cours d’exécution.

IA locale ou API : le calcul qui évite les faux comparatifs

Comparer uniquement « zéro token facturé » à un prix d’API oublie l’électricité, l’achat du matériel, son amortissement et le temps de maintenance. À l’inverse, imputer le prix entier d’un PC gaming déjà utilisé pour jouer surestime le coût marginal de l’IA locale.

Pour une machine déjà possédée, commencez par cette formule :

Coût local mensuel =
(puissance moyenne en kW × heures d'inférence × prix du kWh)
+ maintenance
+ part d'amortissement réellement attribuable à l'IA

Pour le cloud :

Coût API mensuel =
(millions de tokens d'entrée × tarif d'entrée)
+ (millions de tokens de sortie × tarif de sortie)
+ appels d'outils éventuels

Ajoutez enfin le coût des échecs. Un modèle local moins cher qui exige trois corrections humaines n’est pas forcément plus économique qu’une API plus performante. Notre article sur les nouveaux prix de GPT‑5.6 permet de comparer le coût des modèles API avant de décider s’il vaut mieux payer les tokens ou utiliser son propre matériel.

Le seuil de rentabilité doit donc être calculé avec les appareils disponibles aujourd’hui, puis recalculé si un achat devient nécessaire. Nous ne recommandons pour l’instant ni GPU, ni mini-PC, ni carte réseau : PAIR route des requêtes, et sa valeur dépend trop du modèle et du parallélisme pour déduire une configuration idéale de la seule annonce.

RTX Spark arrive en octobre, mais ce n’est pas une condition pour utiliser PAIR

NVIDIA a également annoncé l’arrivée en octobre 2026 de PC Windows RTX Spark. L’entreprise évoque un GPU Blackwell annoncé à un pétaflop, jusqu’à 128 Go de mémoire unifiée et un processeur Grace à 20 cœurs. Ces machines visent notamment les agents toujours actifs, mais aucun prix ne permet encore d’établir leur rentabilité dans ce scénario.

PAIR est une annonce distincte et sa bêta est déjà proposée sur d’autres systèmes compatibles. Associer les deux nouveautés ne doit pas laisser croire qu’il faut attendre RTX Spark ou acheter un nouvel ordinateur. Le premier test raisonnable consiste précisément à utiliser les machines que l’on possède déjà.

NVIDIA PAIR ne rend pas un modèle trop gros compatible avec plusieurs petits GPU. Son ambition est plus concrète : empêcher plusieurs demandes d’attendre devant la même carte graphique lorsque d’autres machines du foyer peuvent les traiter. Pour un chat local utilisé par une seule personne, le gain peut rester faible. Pour un agent qui délègue réellement cinq tâches indépendantes, le routeur peut changer l’expérience — à condition de mesurer les nœuds qui travaillent, l’électricité consommée et la qualité obtenue avant de transformer la maison en mini-datacenter.