NVIDIA DGX Spark · 9 September 2026

DGX Spark en cluster : les LLM open-source qui tournent vraiment en 2026

Depuis l’annonce du DGX Spark au GTC 2025, l’idée de coupler deux de ces mini-supercalculateurs pour faire tourner localement des LLM de 70 milliards de paramètres fait rêver les passionnés d’IA. Un an plus tard, la promesse est tenue, et même amplifiée : un cluster de deux Spark fait tourner DeepSeek V4 Flash-0731 (284B, 13B actifs) à 30-40 token/s, des modèles comme Laguna S 2.1 (118B) ou Ant Ling-3.0-Flash (124B-A5B) tiennent sur une seule machine, et Qwen3.8-27B atteint 48 tok/s. Le prix, vérifiable, est descendu à 2 760 € pour l’Asus Ascent GX10. Plongeons dans les entrailles de cette configuration pour en démêler le vrai du faux, en nous appuyant sur les retours d’expérience de production et les tests indépendants les plus récents.

Le rêve du LLM 70B local à deux têtes

Quand NVIDIA a dévoilé le Project DIGITS en mars 2025, rebaptisé depuis DGX Spark, l’enthousiasme a été immédiat. Ce petit boîtier de 150×150×50,5 mm – à peine plus grand qu’un Mac Mini – embarque un superchip Grace-Blackwell (GB10), 128 Go de mémoire unifiée LPDDR5x, et promet jusqu’à 1 pétaflop en calcul FP4. Commercialisé le 15 octobre 2025, le DGX Spark a immédiatement connu des ruptures de stock, confirmant l’appétit pour une station de travail IA locale.

Mais très vite, une idée a germé dans la communauté : et si on en mettait deux en cluster ? Avec 256 Go de mémoire unifiée cumulée, on pourrait théoriquement charger des modèles de 70B paramètres en FP8, voire 140B avec une quantification agressive. Les forums r/LocalLLaMA et les discussions NVIDIA se sont enflammés. « On pourrait fine-tuner Llama 3 70B à la maison pour le prix d’un bon PC gaming », lisait-on. Le rêve d’une alternative aux H100 à 30 000 $ était né.

Un an plus tard, le paysage a radicalement changé. Les modèles open source ont évolué : DeepSeek V4 Flash-0731 (284B paramètres, 13B actifs) tourne sur deux Sparks, Laguna S 2.1 (118B) et Ant Ling-3.0-Flash (124B-A5B) tiennent sur une seule machine. Le support natif de vLLM depuis juin 2026, l’arrivée de moteurs optimisés comme TensorRT-LLM et la baisse des prix – l’Asus Ascent GX10 est passé de 4 000 € à 2 760 € – ont transformé l’écosystème. Plongeons dans les entrailles de cette configuration pour en démêler le vrai du faux, en nous appuyant sur les retours d’expérience de production et les tests indépendants les plus récents.

Anatomie d’un cluster DGX Spark : ce que dit la fiche technique

Avant de parler cluster, il faut comprendre ce qui relie deux Sparks. Chaque unité intègre une carte réseau intelligente NVIDIA ConnectX-7 avec deux baies QSFP56, offrant jusqu’à 200 Gb/s de bande passante Ethernet. Attention : contrairement à ce que certains espéraient, le NVLink-C2C (900 Go/s) est une interconnexion intra-nœud entre le CPU Grace et le GPU Blackwell, pas entre deux Sparks. L’interconnexion inter-nœud repose donc exclusivement sur Ethernet haute performance.

Spécification	DGX Spark Founders Edition	Asus Ascent GX10	AMD Ryzen AI Halo (comparaison)
Prix France (2025)	3 689 €	4 000 €	–
Prix France (2026)	~4 679 $ (≈ 4 300 €)	2 760 €	$3 999 (2 To SSD, juin 2026)
Stockage NVMe	4 To	1 To	2 To
Mémoire unifiée	128 Go LPDDR5x (273 Go/s)	128 Go LPDDR5x	128 Go LPDDR5X (256 Go/s)
Réseau	2× QSFP56 (200 Gb/s via ConnectX-7)	idem	–
Consommation annoncée	170 W (140 W en pratique)	170 W	55 W nominal / 120 W boost
CPU	Grace (ARM)	Grace (ARM)	16 cœurs Zen 5 / 32 threads
GPU	Blackwell GB10	Blackwell GB10	Radeon 8060S (40 CUs RDNA 3.5)
NPU	–	–	50 TOPS (XDNA 2)

Note : les prix 2026 proviennent des sources récentes (explainx.ai pour le Founders Edition, faits datés pour l’Asus et l’AMD). Les prix des vendeurs tiers peuvent varier de 5 800 à 6 700 € selon les disponibilités.

StorageReview, qui a publié un test pratique du cluster, identifie trois topologies possibles :

Liaison directe 200 Gb entre les deux Sparks (le plus simple).
Double 100 Gb en anneau sans commutateur (pour plus de redondance).
Rôles partagés : un Spark dédié au calcul, l’autre au stockage NVMe-oF.

Le choix de la topologie impacte directement la configuration réseau. Mais dans tous les cas, la bande passante inter-nœud plafonne à 200 Gb/s, soit environ 25 Go/s – bien loin des 900 Go/s du NVLink interne. Ce goulet d’étranglement sera crucial pour les performances.

Piège du câblage : Charles Jefferies (PCMag) a découvert à ses dépens qu’il faut utiliser le port le plus à droite des deux QSFP56, et non celui de gauche, comme l’indiquent les guides officiels de NVIDIA. Une fois le câble branché, il faut configurer des comptes utilisateurs et autoriser la communication via SSH.

Mise à jour CES 2026 : lors du CES 2026, NVIDIA a annoncé une mise à jour logicielle qui multiplie par 2,5 les performances du DGX Spark et par 8 la vitesse de traitement vidéo, selon StorageReview. Cette mise à jour, déployée via la pile logicielle NVIDIA, améliore significativement l’inférence et le fine-tuning sans changement matériel.

La mise en œuvre : recettes MiaAI, correctifs DSpark et vision

Les premiers retours de clusteristes viennent principalement d’un fil de discussion sur les forums NVIDIA intitulé « Container-native multi-node NCCL on 2x DGX Spark – no host build required ». L’utilisateur y décrit une configuration fonctionnelle utilisant Docker avec l’image NGC nvcr.io/nvidia/pytorch:25.09-py3, CUDA 13.0 (via CUDA_HOME=/usr/local/cuda-13.0/), et NCCL 2.23. L’astuce : éviter la compilation sur l’hôte en passant par des conteneurs pré-build.

Aujourd’hui, la mise en place est simple. Les bugs initiaux (comme le port 22 bloqué sur l’interface NVLink) ont été résolus par des correctifs et une documentation claire. La procédure typique :

Installer Docker et les drivers NVIDIA Container Toolkit.
Tirer l’image NGC PyTorch 25.09 (ou plus récente).
Configurer les interfaces réseau (ex. ip addr add 192.168.100.1/24 dev eth1).
Lancer les conteneurs avec --gpus all --network host et les variables NCCL.
Exécuter un test de communication (nccl-tests) pour valider la bande passante.

Le verdict : c’est simple et accessible à tout utilisateur motivé. NVIDIA a publié un guide officiel pour le clustering multi-Spark, et la communauté a affiné les procédures.

La recette MiaAI : le gold standard de DeepSeek V4 Flash sur 2× DGX Spark

Le laboratoire MiaAI a publié une recette complète, désormais considérée comme la référence pour faire tourner DeepSeek V4 Flash-0731 sur deux nœuds. Elle repose sur :

vLLM TP=2 (tensor parallelism) avec speculative decoding DSpark
Plafond de 1M tokens de contexte
KV cache en NVFP4 (nvfp4_ds_mla)
Une image Docker dédiée : ghcr.io/anemll/dspark-vllm-gx10:0.1.1

La configuration requiert deux DGX Spark avec RoCE/NCCL fonctionnels, et la même image + cache Hugging Face sur les deux nœuds. Les variables d’environnement clés sont WORKER_HOST, MASTER_ADDR, NCCL_IB_HCA, NCCL_SOCKET_IFNAME, VLLM_HOST_IP et WORKER_VLLM_HOST_IP. La recette inclut un script de préparation du cache modèle (prepare-dspark-model-cache.sh) et un script de démarrage (start-deepseek-v4-flash-dspark.sh). Les résultats sont documentés dans RESULTS-2026-08-14.md.

Poids du modèle : selon QDNA (mis à jour le 2 septembre 2026), les poids publiés de V4 Flash 0731 pèsent 167 Go (48 fichiers safetensors sur Hugging Face), et non 83,4 Go comme certaines rumeurs l’affirmaient. Le modèle est un MoE de 284 milliards de paramètres avec 13 milliards actifs par token, contexte d’un million de tokens, poids mixtes FP4 + FP8 et module DSpark fusionné.

Les correctifs DSpark : pourquoi 14-18 tok/s au lieu de 30+

Un post détaillé sur les forums NVIDIA révèle un problème critique : la recette originale est stable mais lente (14-18 tok/s en non-streaming, ~10 tok/s en streaming). La cause racine : l’héritage de la configuration de quantification du draft DSpark. Le checkpoint DeepSeek-V4-Flash-0731-NVFP4 est hybride :

Le tronc cible utilise des experts NVFP4 ModelOpt (format ModelOpt, nécessitant flashinfer_b12x et ModelOptNvFp4FusedMoE)
Les étapes MTP/draft utilisent des experts natifs FP8/MXFP4 (poids int8, tenseurs d’échelle UE8M0)

Sans correctif, le draft MoE est construit avec ModelOptNvFp4FusedMoE alors que ses poids ne sont pas au format ModelOpt. Les symptômes : l’acceptance du draft chute à ~1,0-1,15 tokens par étape, et le débit plafonne à 14-18 tok/s. Le patch (disponible dans recipe/apply_experiment_patches.py) consiste à retirer les clés ModelOpt du quantization_config du draft avant que son quant_config ne soit dérivé. Après application, l’acceptance remonte et le débit atteint 30 tok/s par défaut, voire plus avec des ajustements.

La vision arrive sur DeepSeek V4 Flash

Un autre post des forums NVIDIA décrit comment ajouter la vision à DeepSeek-V4-Flash-0731 sur un cluster 2× DGX Spark, sans rebuild d’image ni sacrifice du speculative decoding. La solution repose sur :

FlyCockpit DeepEncoderV2 : un encodeur de 865 Mo (tour gelée) + un projecteur adaptateur de 40 Mo
Un plugin vLLM (dsv4_vision_vllm) qui enregistre un modèle wrapper DeepseekV4VisionForCausalLM
Un simple changement dans config.json (remplacement de architectures via des symlinks)

Après redémarrage, la vitesse atteint ~50 tps (au lieu des 55-60 habituels sans vision). Le guide complet est disponible sur GitHub FlyCockpit.

Les leçons de trois mois en production (Talki-App)

L’équipe de Talki-App a partagé son retour d’expérience après 90 jours d’utilisation du DGX Spark en production. Voici les trois leçons les plus coûteuses :

Mémoire unifiée : un piège pour les workloads Python
Sur un H100, vous êtes limité à 80 Go de VRAM. Sur le GB10, nvidia-smi affiche 95 Go de « free », mais c’est la même mémoire physique que la RAM système. Un workload Python qui charge un dataset Parquet de 40 Go consomme 40 Go de la même piscine. « Toute votre intuition sur « ça tient dans la VRAM » est à reconstruire », prévient l’équipe.
PyTorch : attention aux wheels officielles
Les wheels PyTorch standards de pip ne contiennent pas les kernels SM_100 compilés pour Blackwell. Il faut utiliser les builds NGC ou compiler soi-même. L’équipe recommande d’utiliser les images Docker NVIDIA PyTorch.
Stabilité des NIM containers
Les NIM containers de NVIDIA ne sont pas tous stables sur le GB10. Certains plantent après quelques heures. Talki-App a dû passer à des conteneurs personnalisés avec vLLM pour assurer la fiabilité.

Malgré ces difficultés, le Spark tient les SLA pour leur agent « long-reviewer » (Qwen3.6-35B-A3B quantizé en PrismaQuant 4.75bit). « Le chemin pour y arriver a été beaucoup plus accidenté que ce que la documentation laisse penser », concluent-ils.

L’expérience PCMag : un cluster dans le salon

Charles Jefferies a assemblé deux stations Dell Pro Max équipées du GB10 pour former un cluster. Il a choisi le modèle Qwen 3.6-35B-A3B, un modèle ouvert de 35 milliards de paramètres, et utilisé vLLM dans un conteneur Docker. La configuration initiale a été un calvaire : « Je me suis retrouvé à parcourir des issues GitHub à 2 heures du matin, à copier des messages d’erreur dans des IA pour qu’elles m’aident à les résoudre. » Une fois le câblage correct et les comptes SSH configurés, le cluster a fonctionné, mais les performances n’étaient pas à la hauteur des attentes pour l’inférence d’un seul modèle.

Benchmarks : que valent vraiment deux DGX Spark en cluster ?

Les chiffres de performance sont la clé pour juger de l’intérêt du cluster. Voici ce que nous avons pu glaner à partir des sources disponibles, avec les données les plus récentes (juillet-septembre 2026).

DeepSeek V4 Flash-0731 sur 2× DGX Spark : selon la recette MiaAI et les retours des forums NVIDIA, le débit atteint 30-40 tok/s en génération avec le correctif DSpark appliqué. En préfill, un utilisateur rapporte 1 000 tok/s sur un seul Spark (post du 1er août 2026), et 59 tok/s en multi-agent serving sur un seul nœud. Ces chiffres sont cohérents avec les tests de QDNA.

Qwen3.8-27B sur un seul DGX Spark : selon le blog OpenZeka (26 août 2026), ce modèle de 27 milliards de paramètres, sorti en août 2026, atteint 48 tok/s sur un DGX Spark. Avec un score de 52 sur l’Artificial Analysis Intelligence Index, il se classe premier de sa catégorie parmi les modèles open-weight. C’est le nouveau champion du rapport qualité/performance pour une seule machine.

Qwen3.6-27B (version précédente) : les faits datés indiquent une vitesse de génération de 28-33 tok/s en session unique, 136 tok/s avec 10 agents, et un pic de 163 tok/s en decode. La version NVFP4 est sortie le 26 juin 2026.

Laguna S 2.1 (118B) : ce modèle de codage de Poolside, sorti le 23 juillet 2026, tourne sur un seul DGX Spark. Les benchmarks de codage le placent au niveau de modèles 10 fois plus gros. Selon les tests de la communauté, il atteint environ 20-25 tok/s sur une seule machine.

Ant Ling-3.0-Flash (124B-A5B) : ce challenger chinois tourne également sur un seul Spark, avec des performances comparables à Laguna S 2.1.

AMD Ryzen AI Halo (comparaison) : pour situer le Spark, le Ryzen AI Halo (128 Go LPDDR5X, 256 Go/s) atteint 34-39 tok/s sur des modèles 120B, selon les tests de juin-septembre 2026. Le Spark reste compétitif grâce à sa bande passante légèrement supérieure (273 Go/s) et à son écosystème CUDA.

Inférence d’un modèle 70B (Llama 3) sur un seul DGX Spark : selon l’analyse de QDNA, le débit est limité par la bande passante mémoire de 273 Go/s. En mode decode (génération token par token), on obtient « quelques jetons par seconde ». En FP8, on peut estimer 5-10 tok/s, mais cela reste une extrapolation. Les benchmarks récents d’explainx.ai confirment que le Spark n’est pas fait pour les modèles denses de 70B en inférence mono-utilisateur ; il excelle sur les MoE à activation clairsemée.

Fine-tuning sur DGX Spark : Unsloth, LoRA, QLoRA et full fine-tune en BF16

Le DGX Spark n’est pas qu’une machine d’inférence : c’est aussi une plateforme de fine-tuning. La documentation DeepWiki (12 août 2026) détaille les workflows de fine-tuning sur le GB10 (sm121) avec ses 128 Go de mémoire unifiée.

LoRA et QLoRA : les méthodes de fine-tuning paramétrique efficace sont les plus populaires sur le Spark. Unsloth, la bibliothèque optimisée, supporte nativement le GB10 et permet de fine-tuner des modèles comme Qwen3.8-27B ou DeepSeek V4 Flash avec des adaptateurs LoRA. Les utilisateurs rapportent des vitesses d’entraînement de 2 à 5× supérieures à celles d’un Mac Studio M5 Ultra, grâce aux kernels SM_100 optimisés.

Full fine-tune en BF16 : avec 128 Go de mémoire unifiée, il est possible de fine-tuner en full precision des modèles jusqu’à environ 30-40B paramètres en BF16, à condition de gérer soigneusement l’utilisation mémoire. Pour les modèles plus gros, le full fine-tune nécessite un cluster de plusieurs Sparks ou une quantification.

Fine-tuning distribué : sur un cluster de 2 ou 4 Sparks, le fine-tuning distribué avec DeepSpeed ou FSDP est possible. Les tests de la communauté montrent un scaling quasi linéaire pour les modèles MoE, grâce à la bande passante 200 Gb/s inter-nœuds. Un utilisateur rapporte avoir fine-tuné Qwen3.6-27B sur 2 Sparks en 6 heures avec LoRA, contre 14 heures sur une seule machine.

Recommandations pratiques :

Utiliser les images Docker NVIDIA PyTorch (NGC) pour avoir les kernels SM_100.
Privilégier LoRA/QLoRA pour les modèles > 30B.
Surveiller la mémoire unifiée : le fine-tuning consomme plus que l’inférence.
Pour le RL (reinforcement learning), des frameworks comme TRL fonctionnent, mais nécessitent des ajustements mémoire.

Gestion d’entreprise : Progress Chef Enterprise Management

Alors que les DGX Spark se déploient en flottes dans les entreprises, la gestion à l’échelle devient un enjeu. Le 30 juin 2026, Progress Software a annoncé Progress Chef Enterprise Management pour NVIDIA DGX Spark. Cette solution apporte une gestion de configuration et une gouvernance de niveau entreprise pour les flottes de « supercalculateurs IA de bureau ».

NVIDIA a mis en avant le rôle de Progress Chef dans son blog développeur. La solution permet aux équipes IT de provisionner, surveiller et gérer les DGX Spark à grande échelle, avec les mêmes exigences de sécurité et de conformité que pour les infrastructures critiques. C’est un signe clair que le Spark n’est plus un jouet de passionné, mais un outil d’entreprise à part entière.

Conclusion : le cluster DGX Spark, un an après

Un an après les premières expérimentations, le cluster de deux DGX Spark est devenu une réalité concrète et documentée. Les modèles open-source ont évolué plus vite que le matériel : DeepSeek V4 Flash-0731 (284B, 13B actifs) tourne à 30-40 tok/s sur deux nœuds, Qwen3.8-27B atteint 48 tok/s sur un seul, et les modèles de codage comme Laguna S 2.1 ou Ant Ling-3.0-Flash tiennent dans 128 Go. Le fine-tuning LoRA/QLoRA est mature, la gestion d’entreprise arrive avec Progress Chef, et les prix ont baissé (2 760 € pour l’Asus Ascent GX10).

Reste le goulet d’étranglement de la bande passante inter-nœuds (200 Gb/s Ethernet, contre 900 Go/s NVLink interne). Pour les modèles denses de 70B, le cluster reste décevant ; pour les MoE à activation clairsemée, il est transformateur. Le DGX Spark n’est pas une H100 de bureau, mais c’est la première machine qui rend le LLM open-source local vraiment utile – et le cluster le rend vraiment puissant.

Sources

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

📬 Restez à la pointe

Recevez chaque semaine les nouveautés de ce magazine par email.

💬 Une remarque, une correction ?

Aidez-nous à améliorer cet article. Nous prenons en compte vos retours.

Deux DGX Spark en cluster : mythe ou réalité ? Décryptage des premiers retours d’expérience