NVIDIA DGX Spark · 2 November 2026

Huit DGX Spark, 1 To de mémoire : la fin du mythe du « gros GPU » pour les LLM open source ?

Nvidia a discrètement ouvert la porte à des clusters de huit DGX Spark, faisant passer son mini-supercalculateur d’un boîtier « bon pour du 70B » à une plateforme capable d’héberger des modèles de plusieurs centaines de milliards de paramètres. Mais entre la promesse d’un téraoctet de mémoire unifiée et la réalité des tokens par seconde, il y a un gouffre que cet article entend mesurer, chiffres et architecture à l’appui.

1 To sous le bureau : pourquoi huit Spark ne font pas « juste » huit fois plus

Il faut se souvenir d’où l’on part. À sa sortie, le DGX Spark, c’était un boîtier de la taille d’un livre un peu épais, avec sa puce GB10 Grace Blackwell, ses 128 Go de mémoire unifiée LPDDR5X et sa bande passante de 273 Go/s. Un objet fascinant, mais dont le plafond était vite apparu : dès qu’on dépassait les modèles de 70 milliards de paramètres en quantization raisonnable, il fallait ruser. Puis Nvidia a décliné une version 64 Go à 4 999 dollars (disponible depuis le 23 octobre 2026), pendant que la version 128 Go grimpait au-delà des 6 000 dollars sur le marché — une inversion de prix qui en dit long sur la tension du marché de la mémoire.

Le vrai changement, celui qui déplace la catégorie de l’appareil, c’est le clustering. La possibilité de réunir jusqu’à huit Spark pour atteindre 1 To de mémoire unifiée agrégée transforme l’équation : là où un seul nœud plafonne sur du 70B, un cluster de huit ouvre la porte à des modèles de 400 milliards de paramètres et plus en quantization. Ce n’est pas une addition de mémoire, c’est un changement de nature du problème : les goulots d’étranglement migrent du compute vers l’interconnexion.

Car c’est là que réside toute la subtilité. Huit boîtiers reliés par un réseau, ce n’est pas un seul gros serveur avec 1 To de RAM. C’est huit espaces mémoire distincts que les frameworks doivent apprendre à faire dialoguer. Et ce dialogue, c’est le sujet de cet article : comment il fonctionne techniquement, où il coince, et jusqu’où il vaut la peine d’investir avant d’acheter le boîtier suivant.

ConnectX-7, RDMA et NCCL : ce qui circule vraiment entre deux Spark

L’anatomie de l’interconnexion mérite qu’on s’y attarde, parce que c’est elle qui décide de tout. Chaque DGX Spark embarque une carte réseau ConnectX-7 capable de pousser 200 Gb/s par lien. Ce débit, rapporté à la bande passante mémoire interne du GB10 (273 Go/s, soit environ 2 184 Gb/s), donne immédiatement la mesure de l’écart : un lien inter-nœuds est grosso modo dix fois plus lent qu’un accès à la mémoire locale. C’est cette asymétrie qui structure toute la réflexion sur le parallélisme.

Le RDMA (Remote Direct Memory Access) est la brique qui rend ce réseau exploitable. En contournant le CPU et en permettant à une carte réseau d’écrire directement dans la mémoire d’une machine distante, il élimine les copies intermédiaires et la latence logicielle. C’est ce qui permet à NCCL — la bibliothèque de communication collective de Nvidia — de faire circuler efficacement les tenseurs entre nœuds. NCCL orchestre les opérations classiques du calcul distribué : all-reduce (sommer les gradients ou les activations partielles de tous les nœuds), all-gather (rassembler les fragments), broadcast (diffuser un tenseur).

Ce qui circule concrètement pendant une inférence dépend de la phase. En prefill, c’est-à-dire le traitement du prompt, le modèle calcule en parallèle sur des milliers de tokens : les échanges sont massifs mais peuvent être regroupés en gros transferts, ce qui tolère bien la latence. En decode, en revanche, chaque token généré déclenche un cycle complet de communication pour un seul token par nœud : les messages sont minuscules mais la latence inter-nœuds devient le facteur limitant. C’est précisément pour cela que les chiffres de prefill et de decode divergent tant sur ces machines, et que le decode est le moment de vérité du scaling.

Anneau ou étoile : la topologie qui décide de votre débit agrégé

Deux grandes façons de câbler un cluster de Spark via switch QSFP : l’anneau et l’étoile. L’anneau relie chaque nœud à ses deux voisins, ce qui est simple et économique en câbles, mais impose que le trafic d’un nœud à l’autre traverse les nœuds intermédiaires à chaque saut. Chaque saut ajoute de la latence et consomme de la bande passante sur les liens traversés. L’étoile, à l’inverse, fait converger tous les liens vers un switch central : les chemins sont uniformes, la latence prévisible, mais le switch devient un point unique de coût et de défaillance.

L’effet sur les all-reduce est direct. Dans un all-reduce en anneau, chaque nœud envoie et reçoit en continu, et le temps total dépend du nombre de sauts. Dans une étoile, le switch agrège et rediffuse, ce qui est généralement plus efficace à mesure que le nombre de nœuds grandit. C’est pour cette raison que la bande passante agrégée ne suit jamais linéairement le nombre de nœuds : à deux nœuds, on profite pleinement du lien ; à quatre, les collisions et la contention commencent ; à huit, l’efficacité de scaling plafonne nettement en dessous de la linéarité. Les ordres de grandeur communément observés sur ce type de cluster tournent autour de ×1,7 pour deux nœuds, avec une dégradation progressive au-delà — un chiffre qu’il faut lire comme un ordre de grandeur, non comme une garantie.

Le mythe du « pool unifié » : ce que CUDA voit, ce que vLLM, SGLang et llama.cpp RPC en font

Il faut tordre le cou à une idée reçue tenace : le « 1 To de mémoire unifiée » n’est pas un espace d’adressage unique. Côté CUDA, chaque nœud reste un espace mémoire distinct, avec son propre contexte GPU. Ce sont les frameworks qui découpent le modèle et orchestrent les échanges. Le téraoctet est un budget mémoire à répartir, pas une RAM partagée magique.

Le comportement diffère selon l’outil. vLLM propose deux stratégies : le tensor parallelism (TP), qui découpe chaque couche du modèle entre les nœuds — chaque nœud calcule une tranche de chaque matrice — et le pipeline parallelism (PP), qui découpe le modèle par blocs de couches, chaque nœud traitant une portion séquentielle. Le TP maximise l’usage de la bande passante mais exige une communication intense à chaque couche ; le PP réduit la communication mais introduit des bulles d’inactivité. Le placement de la frontière entre TP et PP est l’un des arbitrages les plus délicats du déploiement. Les mesures publiées sur deux Spark en TP=2 avec vLLM et DeepSeek-V4-Flash en FP8 donnent une idée de l’ordre de grandeur : environ 41 tok/s en single-stream, ~350 tok/s en agrégé à concurrence 32, et un prefill autour de 1 785 tok/s.

SGLang apporte sa propre philosophie avec la radix attention, qui mutualise les préfixes communs entre requêtes via une structure arborescente de cache. Sur un cluster, cela devient un enjeu de gestion du cache distribué : où stocker les préfixes partagés, comment les invalider, comment éviter la duplication entre nœuds. llama.cpp RPC, enfin, adopte une approche plus simple : découpage par couches, chaque nœud traitant un bloc, avec une latence par token qui dépend directement du nombre de nœuds traversés. C’est le plus accessible pour l’expérimentation, mais rarement le plus rapide à grande échelle.

KV cache distribué, latence et bande passante : les trois pièges qui plombent le scaling

Le premier piège, c’est le KV cache. Pendant la génération, chaque requête active maintient un cache de clés et de valeurs qui croît avec la longueur du contexte. Sur un cluster, ce cache se répartit — ou se duplique — entre nœuds selon la stratégie de parallélisme. Une requête longue peut ainsi générer un trafic inter-nœuds considérable, car chaque token doit accéder aux caches répartis. Les mesures publiées sur deux Spark avec cache KV partagé évoquent un pool d’environ 1 105 096 tokens — un chiffre qui montre l’ambition, mais aussi le volume de données à faire circuler.

Le deuxième piège, c’est la latence inter-nœuds. En decode, chaque token nécessite un aller-retour de communication. Si la latence par saut est de quelques dizaines de microsecondes, multipliée par le nombre de couches et de sauts, elle finit par dominer le temps de calcul. C’est pourquoi le débit single-stream stagne souvent autour de quelques dizaines de tok/s même sur un cluster, alors que le débit agrégé explose.

Le troisième piège, c’est la bande passante agrégée qui plafonne avant le compute. À mesure qu’on ajoute des nœuds, la contention sur le switch et les collisions finissent par saturer les liens avant que les GPU ne soient pleinement utilisés. Le point de rendement décroissant se situe typiquement entre quatre et huit nœuds pour les charges d’inférence interactives : au-delà, on gagne en capacité mémoire (pouvoir charger un modèle plus gros) mais de moins en moins en débit par dollar investi.

Recette pas à pas : monter un cluster de 2, puis 4, puis 8 Spark chez soi

La procédure concrète commence par le choix du switch. Pour deux nœuds, un lien direct suffit souvent ; pour quatre et huit, un switch QSFP central (200 ou 400 Gb/s selon les modèles disponibles chez MikroTik ou Nvidia) devient indispensable. Le câblage peut se faire en DAC (cuivre, moins cher, pour les courtes distances) ou en fibre (plus cher, pour les longues distances et une meilleure immunité). La configuration réseau exige ensuite un adressage IP cohérent, l’activation du RDMA sur les interfaces, et l’alignement des variables d’environnement NCCL (choix de l’interface, du protocole, des timeouts). Il faut également veiller à aligner les versions de DGX OS et de firmware sur tous les nœuds — un décalage de version est une source classique d’échecs de communication.

Vient ensuite le déploiement du modèle. Un 235B en MoE quantifié (FP4, FP8, AWQ ou GGUF Q4 selon les contraintes) se lance sur vLLM ou SGLang avec une configuration de parallélisme adaptée au nombre de nœuds. À chaque palier — 2, 4, 8 — la mesure à faire est double : tokens/s en prefill et tokens/s en decode, à concurrence 1 et à concurrence élevée. Le tableau de bord à tenir doit inclure le débit, la latence, l’usage mémoire par nœud et le taux d’occupation des liens réseau. C’est ce tableau qui dira si l’achat du nœud suivant se justifie.

70B, 235B, 405B : ce que disent les chiffres à 1, 2, 4 et 8 nœuds

Les chiffres publiés, qu’il faut lire avec prudence car tous ne sont pas recoupés par une source officielle, dessinent une progression parlante. Sur un seul Spark, un modèle de 35B en GGUF atteint jusqu’à 67 tok/s, tandis qu’un DeepSeek-V4-Flash en IQ2_XXS plafonne autour de 14 tok/s en single-stream, avec un prefill de 410 tok/s. À deux nœuds, la taille maximale de modèle supportée grimpe à 405 milliards de paramètres, et les débits agrégés changent d’échelle : ~350 tok/s à concurrence 32 sur DeepSeek-V4-Flash FP8 en TP=2, avec un prefill autour de 1 785 tok/s.

Ce qu’il faut retenir, c’est que le scaling efficiency réel reste en dessous de la linéarité : deux nœuds donnent souvent un facteur autour de ×1,7 plutôt que ×2, et la dégradation s’accentue à quatre et huit. Les benchmarks de fine-tuning distribué (LoRA/QLoRA, FSDP, DeepSpeed) existent mais restent moins documentés publiquement, avec des temps par epoch et une mémoire par nœud qui varient fortement selon la stratégie choisie. Il convient de signaler explicitement que plusieurs de ces chiffres proviennent de sources communautaires et non d’une documentation officielle Nvidia.

32 000 $ de Spark ou un seul gros serveur : l’arbitrage honnête

Le calcul économique mérite d’être posé franchement. Huit Spark à environ 4 000 dollars pièce — un ordre de grandeur, le prix ayant évolué avec la version 64 Go à 4 999 dollars et la version 128 Go au-delà de 6 000 dollars — représentent un investissement de l’ordre de 32 000 dollars, sans compter le switch et le câblage. Face à cela, un serveur unique avec une RTX 6000 Ada ou Blackwell, un H100/H200, un Mac Studio M3 Ultra 512 Go ou un AMD Strix Halo (le Ryzen AI Halo 192 Go est lancé à 7 299,99 dollars chez Micro Center) offrent des profils très différents. Le cluster gagne sur la capacité mémoire totale et la souveraineté des données ; il perd sur le débit pur, la simplicité et la consommation (huit fois 240 W, sans compter le bruit et l’encombrement de huit boîtiers). Le cloud (A100/H100 à l’heure chez Lambda ou RunPod) reste imbattable pour l’expérimentation ponctuelle, mais coûteux sur trois ans pour un usage continu. Le cluster n’a de sens que pour ceux qui veulent faire tourner des modèles de 400B+ en local, garder leurs données chez eux, et expérimenter sans limite de facturation.

Jusqu’où pousser sa machine avant d’acheter la suivante

La règle de décision est simple à énoncer : le deuxième Spark se justifie dès qu’un modèle dépasse la capacité d’un seul nœud ou que le débit agrégé devient critique pour du serving multi-utilisateurs. Le quatrième devient discutable : on gagne en capacité mémoire mais le rendement par dollar chute. Le huitième n’a de sens que pour des modèles qu’aucun nœud seul ne peut charger — c’est-à-dire les 400B+ quantifiés. Ce que le déverrouillage du clustering change pour l’écosystème local, c’est la possibilité de faire du fine-tuning distribué et du serving souverain à une échelle jusqu’ici réservée au cloud. Mais les limites resteront : la bande passante inter-nœuds, la complexité de configuration, et le fait que « 1 To » est un budget à répartir, pas une RAM partagée. Les signaux à surveiller dans les prochaines versions de DGX OS et des frameworks : l’amélioration de la gestion du KV cache distribué, l’optimisation des collectifs NCCL pour les topologies en étoile, et l’arrivée de stratégies de parallélisme hybrides plus matures. C’est là que se jouera la prochaine étape.

Sources

• Nvidia’s DGX Spark can now join forces with seven others to deliver 1 TB of memory — Notebookcheck
• NVIDIA DGX Spark 64GB Gives Developers More Ways to Build and Scale Local AI — blogs.nvidia.com
• NVIDIA Announces DGX Spark 64GB: A 1-PetaFLOP Grace Blackwell Desktop — MarkTechPost
• Nvidia DGX Spark 64GB Launches at $4,999: Is It Worth It? — TechRepublic
• NVIDIA expands local AI hardware lineup with RTX Spark, DGX updates — blockchain.news
• The Best DGX Spark for Local AI in 2026: LLM Speed, Model Sizes, and Clusters, With Sources — pyshine.com
• Nvidia lance le DGX Spark en 64 Go : faut-il acheter deux petits plutôt qu’un gros ? — Frandroid
• AMD Ryzen AI Halo 192GB Loads Models No Rival Can: DGX Spark Still Wins on Speed — TechTimes

Article recherché et rédigé automatiquement · Magazine Electrosens