Deux DGX Spark suffisent pour des agents IA de développement en local

Deux NVIDIA DGX Spark, des machines de bureau conçues pour l’IA, peuvent faire tourner localement de grands modèles ouverts pour l’assistance au développement logiciel. Dans le test décrit par la source, l’intérêt principal n’est pas un gain de vitesse spectaculaire, mais la capacité à garder le code source et les prompts sur du matériel contrôlé en interne. Le sujet compte pour les équipes qui manipulent du code sensible, car les agents de programmation envoient souvent bien plus de contexte que de texte généré. Et, dans ce cadre, la mémoire disponible pèse souvent plus lourd que le simple débit affiché au compteur.

Ce que change vraiment un duo de DGX Spark

Un DGX Spark est une machine de bureau, pas un serveur de centre de données. NVIDIA annonce 4 699 dollars pour la Founders Edition, avec une puce GB10 Grace-Blackwell et 128 Go de mémoire unifiée partagée entre CPU et GPU. Cette architecture évite de buter sur une VRAM séparée trop vite, ce qui permet d’exécuter des modèles massifs sous un bureau plutôt qu’au fond d’une baie. Deux machines peuvent être reliées via un réseau ConnectX-7, mais la source montre que le lien reste loin d’être saturé dans l’usage testé.

Le premier enseignement tient en une idée simple : doubler le matériel n’a pas doublé les performances. Sur un flux unique, le système à deux nœuds atteint 21,11 tokens par seconde en sortie, contre 12,36 sur un seul nœud, soit 1,71×. À 32 requêtes en concurrence, le gain retombe à 1,50×. En revanche, la latence baisse, avec un temps moyen jusqu’au premier token qui passe de 426,75 ms à 350,63 ms. Le second nœud sert aussi à élargir la capacité mémoire, avec un cache KV qui passe de 2 040 430 à 4 645 007 tokens. C’est là que se joue l’intérêt réel du montage. Pas dans les gros chiffres qu’on montre en réunion.

Pourquoi la mémoire compte plus que le débit

Dans la configuration testée, chaque Spark dispose d’environ 121 GiB de mémoire LPDDR5X unifiée, partagée entre le système et le GPU. Résultat : chaque allocation par l’OS, Ray ou le pilote rogne directement l’espace disponible pour le modèle. La source indique aussi que le réseau n’est pas le maillon faible : le lien mesuré tourne autour de 104 Gbps, tandis que le sous-ensemble réseau reste largement sous-utilisé. Autrement dit, accélérer encore l’interconnexion ne changerait pas grand-chose tant que le vrai goulot se situe ailleurs.

Cette observation compte pour les achats informatiques. Le réflexe “plus de réseau, donc plus de performance” n’est pas le bon ici. Pour faire tourner des modèles ouverts de grande taille en local, la contrainte majeure reste la capacité à loger poids et contexte dans une mémoire suffisante. Le duo de DGX Spark donne donc d’abord de la marge, puis de la souplesse de fonctionnement. Le câble n’est pas le héros de l’histoire, même s’il aime parfois se prendre pour un personnage principal.

Les modèles testés se valent sur la justesse, pas sur le style

La source compare trois modèles ouverts gardés en cache sur les deux nœuds : gpt-oss-120b, Nemotron 3.5 Lightning 30B-A3B et Qwen3.8-27B. Tous les trois passent les cinq prompts retenus, et un test de 30 tâches vérifiées par machine aboutit à 30/30 pour chacun. Cela ne prouve pas qu’ils sont équivalents. En revanche, cela montre que les écarts utiles se déplacent ailleurs : dans la manière de répondre, de raisonner et de gérer l’ambiguïté.

Sur ce terrain, les différences deviennent plus nettes. gpt-oss raisonne moins et produit plus de texte visible, Nemotron déroule des chaînes de pensée bien plus longues, tandis que Qwen reste le plus concis. Face à une consigne volontairement contradictoire — “write a Python script to produce prime numbers in Node.js” — Qwen et Nemotron demandent une clarification, quand gpt-oss résout l’ambiguïté sans la signaler. Ce choix peut paraître astucieux. Il peut aussi être risqué dans une boucle d’agent, où une hypothèse non dite se propage vite. Dans ce contexte, les modèles qui lèvent la confusion ont l’avantage.

Le vrai test, c’est le travail de l’agent

La mesure la plus parlante vient des sessions d’agent de codage, pas des benchmarks synthétiques. Sur un cas Claude Code, la source indique 252 173 tokens d’invite pour 2 012 tokens de sortie, soit un ratio d’environ 170:1. Le point clé est là : les agents de développement sont surtout limités par le préremplissage, c’est-à-dire la phase où le modèle ingère et traite le contexte, bien plus que par la génération finale. Autrement dit, le chiffre qui fait briller les fiches techniques n’est pas celui qui décide du confort quotidien.

Sur la même tâche, Nemotron fait tomber le temps d’exécution de 163 secondes à 19 secondes, soit environ 8,6× de mieux selon la source. Trois sessions simultanées ne coûtent rien de mesurable, car les agents se retrouvent souvent dans des phases d’attente différentes. À six sessions, le temps par session augmente de 1,5 à 1,7×. La conclusion pratique est claire : ce type de configuration peut servir trois ou quatre ingénieurs en parallèle, avec les données qui restent sur des machines contrôlées en interne. Pour les équipes où la traçabilité du code compte autant que la vitesse, ce n’est plus un bricolage de laboratoire. C’est une option d’architecture.