Un routeur d’inférence, pas un GPU virtuel

NVIDIA PAIR, pour Personal AI Router, relie plusieurs machines d’un réseau local derrière une adresse unique et distribue des requêtes d’inférence indépendantes vers un nœud disponible. Il ne transforme donc pas trois cartes graphiques en accélérateur géant : il n’additionne pas leur VRAM, ne découpe pas un modèle entre plusieurs ordinateurs et ne partage pas une génération en cours. Chaque requête complète reste exécutée sur une seule machine. L’intérêt apparaît surtout avec des agents parallèles ou une file de tâches simultanées, pas avec un prompt isolé dont le modèle dépasse la mémoire de chaque nœud.

Plusieurs ordinateurs reliés par des câbles verts dans le visuel officiel de NVIDIA PAIR.
PAIR présente plusieurs machines locales derrière un point d’accès commun, sans les fusionner en un GPU virtuel.

Une bêta ouverte et déjà téléchargeable

NVIDIA a présenté PAIR le 3 septembre 2026 comme une bêta gratuite et open source sous licence Apache 2.0. Les premiers binaires publics avaient précédé l’annonce : version 0.1.0 le 26 août, puis 0.1.1 le 28 août. Des interfaces graphique et terminal sont proposées sur Windows, Linux et macOS. Les installateurs signés configurent l’application et ses services en arrière-plan ; sous Windows, ils ajoutent aussi les règles de pare-feu nécessaires. Le statut de bêta reste important : le dépôt publie déjà une liste de limites connues, et le comportement peut encore évoluer rapidement entre deux versions.

Schéma NVIDIA montrant des agents envoyant des requêtes vers trois nœuds par PAIR.
Chaque sous-agent peut produire plusieurs requêtes. PAIR les place séparément sur les nœuds éligibles du réseau local.

Quels systèmes peuvent participer ?

La page produit cite Windows 11, DGX OS, Linux et macOS, avec les GeForce RTX série 20 ou plus récentes, les RTX PRO depuis l’architecture Turing, DGX Spark ou GB10 et les Mac M4 ou ultérieurs. NVIDIA indique 8 Go de mémoire vive minimum, 20 Go d’espace recommandés et aucune connexion Internet nécessaire pendant le fonctionnement, une fois les modèles téléchargés. Le dépôt fournit des paquets x64 et Arm64 aux formats EXE, DEB et DMG ; Windows sur Arm reste expérimental, et les distributions Linux non compatibles avec le paquet Debian doivent passer par une compilation depuis les sources.

PAIR peut tourner comme routeur sur une machine prise en charge, mais un nœud ne servira une requête que si le moteur, les pilotes et sa mémoire permettent réellement de charger le modèle demandé. La documentation commerciale affiche curieusement « Ubuntu 14.04 », tandis que le dépôt parle plus largement de Linux : mieux vaut vérifier le paquet et les dépendances de la version téléchargée plutôt que traiter cette mention isolée comme une compatibilité garantie. Les exigences propres à Ollama, LM Studio et au modèle choisi continuent de s’appliquer.

Comment une requête trouve sa machine

PAIR agit comme proxy devant Ollama et LM Studio, sans imposer une nouvelle API aux applications qui permettent de choisir leur URL de base et leur modèle. Chaque nœud doit exécuter le moteur correspondant et posséder exactement le modèle demandé. Répliquer un modèle sur plusieurs machines offre donc davantage de destinations ; installer des modèles différents élargit le catalogue, sans accélérer une requête unique. Le proxy filtre d’abord les nœuds capables de servir ce modèle, puis applique l’ordre fourni par l’ordonnanceur aux candidats restants.

L’architecture actuelle combine le nombre de travaux en attente avec un signal grossier et lissé de l’utilisation du GPU. Elle ne tient pas compte du modèle exact de GPU, de la VRAM disponible, de la latence mesurée, du coût probable d’une requête ni du fait que le modèle soit déjà chargé en mémoire. Une page de limites du même dépôt décrit encore une politique fondée uniquement sur le nombre de tâches, signe que la documentation de cette bêta n’est pas entièrement synchronisée. Sur un parc très hétérogène, il faut donc mesurer le placement réel au lieu de supposer que le nœud le plus rapide sera toujours choisi.

Schéma d’architecture du proxy PAIR entre un agent, les routeurs et trois moteurs d’inférence.
L’application conserve son endpoint familier ; PAIR choisit un nœud éligible, dont le moteur exécute toute la requête.

Réseau local et sécurité

La découverte automatique repose sur mDNS, avec saisie manuelle de l’adresse IP en secours. Une machine invite l’autre et affiche un code à six chiffres, saisi sur le second appareil. Ce code amorce la confiance ; après l’appairage, les canaux du cluster utilisent des certificats et du TLS mutuel. Les proxys HTTP en clair n’acceptent normalement que la boucle locale, tandis que le trafic d’un membre appairé passe par l’entrée protégée. NVIDIA recommande néanmoins de ne jamais exposer ces ports à Internet et de considérer un Wi-Fi partagé ou un routeur compromis comme une frontière de confiance.

Le modèle de sécurité documente une réserve notable : certaines métadonnées de découverte, d’hôte et de GPU peuvent circuler en HTTP non authentifié. Un appareil présent sur le même sous-réseau pourrait ainsi lire le nom de machine, l’inventaire matériel et l’utilisation publiée par un nœud. Enfin, « local » décrit l’architecture de PAIR, pas nécessairement celle de tous les composants associés. Une application, un moteur, un catalogue de modèles ou un système de mise à jour peut encore contacter un service extérieur ; la confidentialité dépend de la chaîne réellement configurée.

Ce que démontre le test NVIDIA

La démonstration officielle utilise Hermes Desktop, cinq sous-agents, Ollama et le modèle Qwen 3.6 35B A3B pour classer une boîte de réception synthétique puis produire un plan consolidé. Sur un portable RTX Spark, l’exécution moyenne dure 18 minutes. Avec ce portable, un DGX Spark et un PC équipé d’une RTX 5090, le même scénario tombe à 8 minutes 48 secondes. Cela correspond à environ 2,05 fois plus vite, ou 51 % de temps en moins, parce que plusieurs appels indépendants peuvent progresser en parallèle.

Ce résultat illustre un gain de débit, pas une accélération linéaire d’un même modèle. NVIDIA le qualifie d’informel et propre à cette configuration. Le parallélisme du scénario, le modèle, les réglages du moteur, le matériel, le réseau et la disponibilité des nœuds influencent le résultat. Aucun protocole indépendant n’accompagne encore l’annonce. Pour évaluer PAIR chez soi, les bonnes mesures seront le temps de bout en bout, la longueur des files, la qualité obtenue et la télémétrie indiquant sur quels nœuds les requêtes ont réellement été exécutées.

Graphique NVIDIA comparant 18 minutes sur un portable RTX Spark à 8,8 minutes sur trois appareils.
NVIDIA présente cette moyenne comme une démonstration non officielle et spécifique à la configuration, pas comme une promesse universelle.

Les limites à connaître avant d’installer

L’ordonnanceur ne connaît pas encore la capacité fine de chaque GPU et une machine lente peut être préférée à une plus rapide. Un modèle présent sur un seul nœud ne bénéficie d’aucun équilibrage. PAIR redémarre un service qui s’arrête, mais ne détecte pas toujours un processus encore actif devenu inerte. Les chiffres de mémoire sont incomplets sur certains GPU à mémoire unifiée ou systèmes AMD et Intel, macOS peut cesser de répondre sur le réseau lorsqu’il reste hors cluster, et l’interface terminal ne couvre pas toutes les fonctions de l’application graphique.

PAIR peut déjà recycler plusieurs machines en capacité d’inférence concurrente, à condition de préparer les moteurs et modèles sur les bons nœuds et de garder le réseau digne de confiance. Son intérêt est concret pour les agents et outils qui produisent plusieurs appels simultanés, notamment lorsqu’un PC principal doit rester disponible pour le jeu ou la création. Ce n’est ni du calcul distribué généraliste, ni un moyen de faire entrer un grand modèle dans plusieurs petites VRAM, ni la garantie qu’une tâche essentiellement séquentielle finira plus vite.

Sources