Votre GPU travaille, l’autre machine attend
Vous lancez un agent pour analyser un dépôt de code. Il doit examiner plusieurs fichiers avant de préparer une synthèse. Votre GPU est occupé, alors qu’un autre ordinateur du réseau pourrait prendre une partie du travail. Comment lui envoyer des demandes sans modifier toute votre application ?
C’est ce que propose NVIDIA Personal AI Router, ou PAIR, présenté le 3 septembre 2026. Le logiciel se place entre votre application et les moteurs Ollama ou LM Studio. Il repère les machines disponibles et choisit où envoyer chaque demande.
L’idée paraît simple, mais le résultat dépend de ce choix. Si l’agent attend toutes les analyses avant de rédiger sa synthèse, une requête confiée à un ordinateur lent peut retarder l’ensemble. Pour comprendre quand PAIR aide, il faut donc regarder comment il répartit le travail.
Cette analyse porte sur la version 0.1.1, son code et la documentation consultée le 8 septembre 2026. Les benchmarks cités viennent de NVIDIA et d’un autre auteur ; LeCompute n’a pas réalisé de mesures matérielles pour cet article.
Ce que PAIR fait d’une demande
Ollama et LM Studio sont des moteurs d’inférence : ils chargent le modèle en mémoire et lui font produire une réponse, morceau de texte après morceau de texte. Ces morceaux sont les tokens. PAIR choisit la machine à laquelle confier ce travail, puis transmet la réponse à votre application.
Prenons deux ordinateurs qui possèdent chacun une copie du même modèle. PAIR peut envoyer une demande au premier et une autre au second. Chacun effectue tout le calcul de sa demande avec ses propres ressources. Le projet NVIDIA décrit cette répartition à l’échelle des requêtes.
Les mémoires des deux ordinateurs restent donc séparées. Si aucun ne peut exécuter le modèle à lui seul, PAIR ne permet pas de les réunir pour le faire tenir. Un moteur peut éventuellement répartir un modèle entre plusieurs GPU dans une même machine, mais cette fonction lui appartient.
Cette organisation explique aussi le rôle du réseau. Celui-ci transporte la demande et le texte produit. PAIR n’organise pas d’échanges entre GPU à chaque étape du calcul du modèle. La taille des entrées et la qualité de la connexion peuvent ralentir le trajet, mais une interconnexion spécialisée entre accélérateurs n’est pas un préalable à toute utilisation.
Si votre objectif est de faire tenir un gros modèle, la question est celle de la capacité mémoire. Si vous voulez traiter plusieurs demandes ensemble, la réplication du modèle devient pertinente. Le comparatif entre une RTX PRO 6000 et plusieurs RTX 5090 approfondit cette différence.
Le même modèle doit être disponible au bon endroit
Vous demandez un modèle à Ollama. PAIR cherche les machines qui annoncent ce modèle dans leur inventaire Ollama, puis choisit une destination parmi elles. Une machine qui possède seulement un autre modèle ne peut pas recevoir cette demande.
Copier le modèle sur votre second ordinateur lui permet donc de participer. Y installer un petit modèle spécialisé peut servir à d’autres tâches, à condition que votre application le demande explicitement. PAIR ne lit pas la question pour décider qu’un modèle plus petit suffirait.
Si aucune machine ne peut recevoir la demande, le proxy, c’est-à-dire la passerelle locale par laquelle elle transite, renvoie une erreur 502. Il ne substitue pas un autre modèle. La documentation d’architecture décrit ces règles de sélection.
Pour comparer les machines, vérifiez aussi ce qui se cache derrière le nom du modèle : la version des poids, leur quantification, la longueur du contexte et les réglages de génération. Vous pourriez sinon attribuer au matériel un écart qui vient de modèles ou de paramètres différents.
La mémoire doit être suffisante sur chaque ordinateur. Aux poids du modèle s’ajoutent ses espaces de travail et le KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire , qui conserve des résultats intermédiaires du contexte pour éviter de les recalculer pendant la génération. Notre article sur le budget mémoire d’un LLM détaille ce calcul.
Comment PAIR choisit entre deux machines
Lorsque plusieurs ordinateurs proposent le modèle, PAIR doit déterminer lequel recevra la prochaine requête. Son ordonnanceur, le composant chargé de ce choix, regarde combien de travaux attendent ou s’exécutent sur chaque machine. Il tient aussi compte de l’utilisation du GPU.
Dans la version étudiée, cette utilisation est ramenée à un score de 0 à 3. PAIR additionne ce score au nombre de travaux, puis privilégie les machines dont le total est le plus faible. En cas d’égalité, il compare le score GPU, puis l’identifiant de la machine. Les travaux Ollama et LM Studio sont comptés ensemble pour ce classement, comme le montre le code de l’ordonnanceur.
Le score monte lorsque l’utilisation GPU lissée franchit 40, 70 puis 85 %. Il redescend à des seuils plus bas, pour éviter de changer à chaque petite fluctuation. Si la mesure manque ou date de plus de dix secondes, PAIR attribue un score de 1. Il traite ainsi l’absence d’information sans supposer que le GPU est libre. Ces détails figurent dans le traitement de la télémétrie.
Ce choix renseigne PAIR sur l’activité des machines. Il lui manque cependant une information pour prévoir quand une réponse arrivera : la vitesse à laquelle chaque ordinateur peut terminer le travail demandé.
Deux GPU peuvent afficher la même utilisation et produire des quantités de texte très différentes par seconde. De même, une courte extraction et une longue rédaction comptent chacune comme un travail. Leur durée peut pourtant être très éloignée.
NVIDIA indique dans les limites connues que le choix ne prend pas en compte le modèle de GPU, la mémoire disponible, la latence mesurée, le coût estimé de la demande ou la présence du modèle déjà chargé en mémoire. Ces limites expliquent pourquoi l’ajout d’une machine mérite un essai sur vos propres tâches.
Deux machines peuvent-elles être plus lentes qu’une seule ?
Imaginons douze requêtes identiques, prêtes à partir ensemble. La machine A traite chacune en deux secondes. La machine B met six secondes. Pour cet exemple hypothétique, chaque machine exécute une seule requête à la fois, les modèles sont déjà chargés, les durées restent constantes et le temps réseau est négligé.
Avec A seule, le travail prend 24 secondes : douze requêtes de deux secondes.
Si un répartiteur donne six requêtes à chaque machine, A termine en douze secondes. B met trente-six secondes à traiter les siennes. Vous attendez donc 36 secondes pour disposer du lot complet. C’est douze secondes de plus qu’avec A seule.
La machine B pourrait pourtant être utile. En donnant neuf demandes à A et trois à B, chacune termine en dix-huit secondes. Le même matériel finit alors le lot 25 % plus tôt qu’avec A seule. Le gain dépend de la répartition du travail entre les deux vitesses.
Les premiers benchmarks donnent deux résultats très différents
Dans sa démonstration de lancement, NVIDIA utilise Hermes Desktop avec cinq sous-agents, Ollama et Qwen 3.6 35B A3B. La tâche prend en moyenne 18 minutes sur un portable RTX Spark, puis 8 minutes 48 secondes avec ce portable, un DGX Spark et une RTX 5090.
Le travail se termine environ 2,05 fois plus vite dans cette configuration. Ce résultat porte sur la tâche complète réalisée par les agents. Il ne signifie pas que chaque génération est accélérée dans la même proportion.
NVIDIA présente elle-même cet essai comme une démonstration non officielle. Il manque notamment le temps obtenu par la meilleure des trois machines seule sur le même travail, ainsi qu’une dispersion détaillée des résultats. Le chiffre montre un gain par rapport au portable ; il laisse ouverte la comparaison avec les autres ordinateurs utilisés séparément.
Un essai de Mark Bartlett publié le 4 septembre prend justement une autre référence. L’auteur compare une RTX 3090 seule à cette même carte accompagnée d’une RTX 3060 via PAIR. Avec vingt requêtes, le même modèle quantifié et une seule requête exécutée à la fois par moteur, il rapporte 47,09 secondes contre 44,10 secondes. Cela représente environ 6,3 % de temps en moins, soit une vitesse multipliée par 1,07.
Ce test décrit une configuration précise, et son auteur développe aussi un routeur concurrent. Son explication du résultat demande également une réserve : il décrit un ordonnanceur fondé seulement sur le nombre de travaux, alors que le code examiné tient aussi compte de l’activité GPU. Les temps qu’il rapporte restent une observation à reproduire ; cette description ne permet pas d’en attribuer la cause avec certitude.
Conversation, équipe ou agent : le gain change avec l’usage
Si vous discutez avec un modèle, vous envoyez une question, attendez sa réponse, puis posez la suivante. Chaque génération utilise une seule machine. PAIR peut vous diriger vers un autre ordinateur lorsque le premier est occupé, mais il ne fait pas travailler tous vos GPU ensemble sur cette réponse.
Avec plusieurs utilisateurs, davantage de demandes peuvent avancer en parallèle. C’est là que la présence d’autres machines devient utile : elles peuvent prendre des requêtes qui auraient attendu leur tour. Il faut toutefois comparer ce résultat à un moteur local correctement réglé. Ollama sait déjà traiter des requêtes en parallèle, lorsque la mémoire le permet, avec notamment le réglage OLLAMA_NUM_PARALLEL.
L’agent qui analyse votre dépôt se situe entre ces deux cas. Il peut examiner plusieurs fichiers en même temps, puis attendre ces analyses avant de rédiger sa synthèse. PAIR distribue les demandes que l’application lui envoie. C’est à l’application de produire ces demandes indépendantes : le routeur ne transforme pas une suite d’étapes en travail parallèle.
Pour cet usage, chronométrez la tâche jusqu’à son résultat final et vérifiez sa qualité. Un agent qui multiplie les appels peut occuper davantage les GPU tout en mettant plus longtemps à produire une synthèse correcte. C’est aussi l’un des problèmes abordés dans notre article sur la mesure des agents de code.
Un modèle disponible n’est pas forcément prêt à répondre
Votre deuxième machine annonce le bon modèle et son GPU est libre. PAIR lui envoie une demande. Pourtant, la réponse tarde : le modèle est présent sur le disque, mais le moteur doit encore le charger en mémoire.
La gestion des moteurs dans PAIR ne précharge pas les modèles au démarrage. LM Studio propose aussi un chargement à la demande et un déchargement automatique, décrits dans ses paramètres de serveur. Selon ces réglages, deux demandes espacées peuvent chacune déclencher un chargement.
Avant de produire le premier token, la machine peut donc avoir à lire les poids, préparer ses espaces de travail et traiter le texte d’entrée. Garder le modèle chargé évite de refaire une partie de ce travail, mais réserve de la mémoire. Le bon réglage dépend du rythme de vos demandes et des autres applications qui utilisent l’ordinateur.
Ce délai peut aussi provoquer une erreur. Dans le proxy Ollama de PAIR 0.1.1, l’attente des en-têtes HTTP, qui marquent le début de la réponse du serveur, est limitée à 120 secondes. Une file d’attente ou un chargement suffisamment long peut faire échouer la tentative.
Cette limite concerne le début de la réponse. Elle ne coupe pas automatiquement une génération qui envoie déjà son texte depuis deux minutes. Distinguer les deux évite de chercher un problème de longueur de réponse lorsque le retard se produit avant son démarrage.
Avant de connecter vos machines
Commencez par lancer le modèle directement dans Ollama ou LM Studio sur chaque ordinateur. Vous saurez ainsi si le moteur, le pilote et la mémoire disponible permettent de traiter vos demandes avant d’ajouter PAIR.
Le guide NVIDIA cite les GeForce RTX série 20 et suivantes, les RTX PRO à partir de Turing et DGX Spark. Le billet de lancement mentionne aussi les Mac Apple M4 ou ultérieurs. Le dépôt indique que Windows sur Arm reste expérimental.
Pouvoir ouvrir PAIR sur un système et pouvoir y exécuter votre modèle sont deux vérifications distinctes. Pour un Mac plus ancien ou un GPU AMD, la compatibilité d’Ollama ou de LM Studio ne vaut pas à elle seule validation de l’ensemble par NVIDIA. Les comparatifs DGX Spark contre RTX 5090 et RTX Spark contre DGX Spark expliquent les différences matérielles ; l’essai direct vérifie votre configuration logicielle.
Une fois les machines prêtes, copiez l’adresse affichée dans Endpoints pour connecter votre application. Dans l’installation standard, PAIR occupe le port habituel du moteur et déplace celui-ci sur un autre port. Cette disposition peut changer en présence d’une installation existante ou d’un conflit. Le guide de démarrage précise les deux adresses : celle du proxy fait passer les demandes par PAIR, celle du moteur le contourne.
Enfin, gardez le même moteur tout au long du trajet. Une demande envoyée au proxy Ollama doit rejoindre Ollama. Même si Ollama et LM Studio proposent une API compatible OpenAI, par exemple /v1/chat/completions, PAIR ne convertit pas la demande pour passer de l’un à l’autre.
Quelles machines peuvent lire vos données ?
L’ordinateur choisi reçoit votre demande pour la traiter. Si elle contient du code privé ou un document sensible, cet ordinateur doit donc être digne de confiance.
PAIR chiffre les échanges d’inférence entre machines appairées avec le TLS mutuel : chaque extrémité vérifie l’identité de l’autre. L’application locale communique avec une interface HTTP accessible sur la machine elle-même. Le document de sécurité précise les limites de cette protection.
Certaines informations restent accessibles en HTTP sans authentification sur le sous-réseau, notamment le nom des machines, l’inventaire et l’utilisation matérielle. Le chiffrement des requêtes d’inférence ne protège donc pas toutes les informations de fonctionnement. Cela compte dans le choix du réseau et des ordinateurs que vous y autorisez.
Une exécution locale du modèle ne suffit pas non plus à exclure les connexions vers Internet. Les moteurs peuvent télécharger des modèles ou utiliser des fonctions cloud ; un agent peut appeler des outils distants. Ollama documente une option pour désactiver ses fonctions cloud. Pour garder un travail entièrement local, vérifiez aussi ces réglages et les outils de votre application.
Comment savoir si PAIR vous fait gagner du temps
Choisissez d’abord un travail représentatif de votre usage et exécutez-le sur chaque machine seule. Gardez les mêmes poids, quantification, longueur de contexte et paramètres de génération. Notez les versions des moteurs et leur réglage de traitement parallèle. La meilleure référence sera l’ordinateur le plus rapide sur ce travail précis.
Comparez ensuite trois situations : ce moteur utilisé directement, PAIR connecté à cette seule machine, puis PAIR avec les ordinateurs supplémentaires. L’étape intermédiaire aide à voir ce que coûte le passage par le proxy avant de mesurer l’apport des autres machines.
Répétez les essais en alternant leur ordre. Une machine qui chauffe, un modèle chargé lors du premier passage ou une application active en arrière-plan peuvent modifier les temps. Séparez aussi les démarrages à froid des essais où les modèles sont déjà en mémoire.
Vous pouvez commencer avec une, quatre puis huit demandes simultanées, en conservant leur contenu. Mesurez le temps avant le premier token, le temps de génération, le délai total et les erreurs. Vérifiez la quantité de texte réellement produite : fixer la même limite de sortie ne garantit pas que les réponses auront la même longueur.
Sur un nombre suffisant d’essais, la médiane décrit le milieu des temps observés. Le percentile 95, le délai sous lequel se trouvent 95 % des observations, aide à suivre les réponses les plus lentes. Publiez le nombre de mesures avec ces valeurs, car quelques essais donnent un percentile instable. L’article sur les latences d’inférence explique ce que chaque durée permet de comprendre.
Pour un lot, chronométrez jusqu’au dernier résultat et comptez les tâches réussies. Pour votre agent, vérifiez également la synthèse finale et les étapes accomplies. L’écran Jobs permet de voir quelles machines ont reçu les requêtes : leur présence dans l’inventaire ne prouve pas leur participation au travail.
Si vous cherchez aussi une économie d’énergie, mesurez la consommation à la prise de toutes les machines pendant le même travail. Finir plus vite avec plusieurs ordinateurs allumés ne garantit pas une consommation totale plus faible.
Faut-il réunir vos machines ?
PAIR mérite un essai si vous avez plusieurs demandes qui peuvent avancer ensemble et des ordinateurs capables d’exécuter les modèles concernés. Commencez avec deux machines, vérifiez qu’elles reçoivent du travail, puis comparez le temps total à votre meilleure machine seule.
Si votre attente vient d’une seule longue génération ou d’un modèle qui manque de mémoire, PAIR n’apporte pas le mécanisme nécessaire pour partager ce calcul entre ordinateurs. Le choix du modèle, de ses réglages ou d’un moteur adapté au calcul distribué sera alors plus pertinent.
L’évolution à surveiller est la manière dont PAIR choisira ses destinations. Tenir compte de la vitesse propre à chaque machine et du modèle déjà chargé pourrait l’aider à prévoir laquelle terminera une demande le plus tôt. C’est ce qui permettrait de mieux exploiter un ensemble où les ordinateurs ont des capacités très différentes.
Sources et méthode
Faits vérifiés dans les sources primaires. La date de présentation et la démonstration Hermes proviennent du billet technique NVIDIA du 3 septembre 2026. La release 0.1.1 identifie le commit étudié ; sa publication précède l’annonce du blog. Les temps de démonstration sont des résultats publiés par NVIDIA, sans reproduction LeCompute.
Le fonctionnement a été recoupé entre le README, l’architecture, les limites connues, la gestion des moteurs et le guide de démarrage. Les compatibilités annoncées sont celles du playbook NVIDIA et du billet de lancement, consultés le 8 septembre 2026.
La lecture du code porte sur schedule.go, telemetry.go et le proxy Ollama, à ce commit précis. La limite de 120 secondes décrite concerne l’attente des en-têtes dans ce transport, sans extrapolation à tous les délais de la pile. Les frontières de confiance sont recoupées avec SECURITY.md.
Les réglages d’exécution parallèle, de résidence et de cloud proviennent de la FAQ Ollama et des paramètres de serveur LM Studio. Les documentations évoluent ; une nouvelle version demande de revérifier les limites avant d’appliquer ce verdict.
Mesures tierces et calculs dérivés. Les 47,09 et 44,10 secondes sont rapportés par Mark Bartlett sur InsiderLLM, avec son protocole et son contexte déclarés. La réduction de durée vaut (47,09 − 44,10) / 47,09, soit environ 6,3 %. Le facteur de vitesse vaut 47,09 / 44,10, soit environ 1,07. Ces résultats ne sont pas des mesures LeCompute et ne valident pas toutes les interprétations de leur auteur.
Hypothèses et méthode proposée. Le lot de douze requêtes, les temps de deux et six secondes et les répartitions associées sont un exemple construit. Les vingt-quatre, trente-six et dix-huit secondes découlent de ces hypothèses, sans réseau, sans variation de durée et sans exécution parallèle dans un moteur. Le protocole de comparaison est une proposition de mesure, pas le récit d’un test effectué. Aucun gain universel de débit, d’énergie ou de coût n’est déduit de cette analyse.
