Nvidia a présenté un outil de regroupement local permettant d'utiliser des Mac et des PC inutilisés pour faire tourner des modèles d'IA. L'idée de mutualiser des machines dormantes est vieille de vingt-cinq ans. Ce qui la rend pertinente aujourd'hui, c'est la convergence de trois choses que nous documentons séparément depuis des mois.
Nous avons couvert l'IA locale et les modèles qui tiennent sur une seule carte. Voici l'étape suivante : plusieurs machines qui travaillent ensemble.
Le principe
Beaucoup d'organisations disposent de machines sous-utilisées : des postes de travail éteints la nuit, une salle d'ordinateurs inoccupée, du matériel de génération précédente qu'on n'a pas jeté.
Un outil de regroupement les fait apparaître comme une ressource unique. Selon la tâche, on peut soit répartir des requêtes indépendantes sur plusieurs machines, soit découper un modèle trop gros pour tenir sur une seule.
Ces deux modes sont très différents en pratique, et il faut le savoir. Répartir des requêtes fonctionne très bien : chaque machine travaille seule, la liaison entre elles importe peu. Découper un modèle est beaucoup plus exigeant, parce que les machines doivent échanger en permanence, et un réseau domestique ou de bureau est très lent comparé aux liaisons internes d'un serveur.
Pourquoi maintenant
Trois évolutions se rejoignent, et c'est leur conjonction qui rend cet outil intéressant plutôt que nostalgique.
Les modèles utiles sont devenus petits. Nous l'avons documenté toute l'année, de Qwen 3.8 en 27 milliards aux modèles distillés. Un modèle qui tient sur une carte grand public change ce que vaut une machine ordinaire.
La confidentialité est devenue un critère d'achat. Nous rapportions que la moitié du Fortune 500 privilégierait l'hébergement interne. Une organisation qui refuse d'envoyer ses données ailleurs a besoin de calcul chez elle.
Les agents consomment énormément. Un agent qui tourne en boucle produit une facture continue. Le faire tourner sur du matériel déjà amorti change complètement le calcul, comme nous l'expliquions à propos des puces dédiées à l'inférence.
Le réseau est le goulot. Pour tout ce qui exige un vrai travail collectif entre machines, un réseau local ordinaire est cent fois plus lent que ce qu'un serveur utilise en interne. Les gains restent donc limités aux tâches parallélisables.
L'électricité n'est pas gratuite. Des machines qui tournent en permanence consomment, et le coût peut dépasser celui d'une API selon les tarifs locaux.
La surface d'attaque augmente. Nous en parlions vendredi : les outils qui donnent aux modèles un accès aux machines sont devenus une cible. Multiplier les machines multiplie les portes.
Pour qui c'est réellement intéressant
Trois profils, et pas les autres.
Une petite structure avec du matériel. Un cabinet, un laboratoire, une école qui possède des postes de travail et veut traiter des documents sensibles sans les faire sortir.
Un développeur qui expérimente. Faire tourner des agents en boucle pendant des heures sans compter, sur du matériel déjà payé.
Un usage à volume prévisible. Une tâche répétitive et continue, où l'amortissement d'un matériel bat l'abonnement.
Pour un usage occasionnel, une API reste plus simple et moins chère. Personne ne devrait acheter des machines pour cela.
Ce qu'il faut retenir
Cet outil est intéressant moins pour ce qu'il permet que pour ce qu'il signale : le calcul cesse d'être exclusivement centralisé.
Pendant deux ans, la trajectoire allait dans un seul sens — des modèles toujours plus gros dans des data centers toujours plus grands. Ce que nous observons depuis quelques mois est une seconde branche : des modèles compacts, du matériel accessible, et maintenant des outils pour mutualiser ce qu'on a déjà.
Cette seconde branche ne remplacera pas la première. Elle détermine en revanche qui peut faire quoi sans demander la permission à personne, et c'est une question qui dépasse largement la performance.