NVIDIA DGX Spark · 29 October 2026Combien de DGX Spark pour quel modèle ? La carte 2026 des LLM open source qui tiennent vraiment sur 1, 2, 4 ou 8 machines
À l’automne 2026, le DGX Spark n’est plus une curiosité de développeur : c’est une brique d’infrastructure locale qu’on empile par deux, quatre, parfois huit. Mais entre les 128 Go annoncés sur la boîte, la mémoire réellement disponible pour les poids et le cache KV, et un catalogue de modèles open source qui explose, la vraie question n’est plus « est-ce que ça tourne ? » mais « combien d’unités pour quel modèle, à quelle quantification, avec quel débit ? ». Voici la carte de décision — avec ses zones d’ombre.
La question a changé de nature
Il y a un an et demi, posséder un DGX Spark relevait encore du pari de développeur curieux. En cet automne 2026, la donne a basculé. La machine est devenue une référence : constructeurs partenaires (Acer, ASUS, Dell, Gigabyte, HP, Lenovo, MSI), écosystème logiciel mature, et surtout une communauté qui publie ses mesures. Le problème n’est plus la compatibilité — vLLM et llama.cpp tournent, point — mais le dimensionnement.
Rappelons le socle, car tout le reste en découle. Le DGX Spark embarque une puce GB10 Grace Blackwell (20 cœurs Arm), 128 Go de mémoire LPDDR5X unifiée, une bande passante de 273 Go/s, 1 PFLOP FP4 avec sparsité (1 000 TOPS), une carte ConnectX-7 à 200 Gb/s (deux ports QSFP), un TDP puce de 140 W pour une alimentation de 240 W. Côté prix, la trajectoire est moins réjouissante : parti à 3 999 $ au lancement, le Spark 128 Go est passé à 4 699 $ en février 2026 (+18 %, pénurie de mémoire oblige), et les relevés européens d’octobre 2026 donnent 5 083 € HT chez LDLC.pro (26 septembre 2026, PNY) ou 5 290 € HT chez Nelpx — soit un ordre de grandeur de 7 000 € HT par nœud une fois le marché français consolidé.
Et depuis le 2 octobre 2026, une nouvelle variable est entrée dans l’équation : NVIDIA décline son Spark en version 64 Go, commercialisée à partir du 23 octobre, à 4 999 $ — plus cher que l’ancien prix du 128 Go. La logique est contre-intuitive, mais elle a une vertu : elle rend la question du dimensionnement encore plus aiguë. Un Spark 64 Go, deux Spark 64 Go, un Spark 128 Go : les arbitrages changent du tout au tout.
NVIDIA, de son côté, avance des plafonds : 200 milliards de paramètres quantifiés sur un nœud, 405 milliards sur deux reliés en QSFP direct, 700 milliards sur quatre via commutateur Ethernet. Ce sont des revendications constructeur, pas des mesures indépendantes — et c’est précisément là que les benchmarks communautaires (spark-bench, LLM Benchmark v4, Spark Arena) entrent en scène, avec leurs chiffres partiels mais précieux.
128 Go annoncés, 128 Go moins tout le reste
Voici le piège numéro un, celui qui fait acheter une machine de trop ou de trop peu : la mémoire unifiée n’est pas un bloc de VRAM. Sur un GPU classique, on raisonne en gigaoctets dédiés aux poids. Sur le Spark, les 128 Go sont partagés entre le CPU Arm, le GPU Blackwell, l’OS, le runtime CUDA, les buffers d’inférence et la fragmentation. La mémoire réellement mobilisable pour les poids et le cache KV se situe plutôt dans une fourchette de 100 à 110 Go selon la configuration — un ordre de grandeur, pas une garantie, car aucune source publique ne détaille la répartition exacte.
Prenons la formule canonique du cache KV, celle que tout le monde devrait avoir en tête avant d’acheter :
Cache KV (octets) = 2 × n_couches × n_kv_heads × d_head × n_tokens × octets_par_élément
Le facteur 2 vient des clés et des valeurs. En FP16, chaque élément pèse 2 octets ; en FP8, 1 octet ; en INT4, 0,5 octet. Et c’est là que le basculement se joue. Un modèle de 70 milliards de paramètres en INT4 occupe environ 35 Go de poids — confortable sur un seul Spark à 4k de contexte. Mais à 32k de contexte, le cache KV s’invite : sur une architecture à 80 couches avec 8 têtes KV et une dimension de tête de 128, on parle de plusieurs gigaoctets par requête longue, et la marge fond. À 128k de contexte, le même modèle « qui tenait » devient un casse-tête. La règle est simple : un 70B en INT4 tient à 4k, tient mal à 32k, ne tient plus à 128k une fois le cache compté.
Deuxième piège, plus subtil : la bande passante de 273 Go/s, et non la capacité, devient le facteur limitant du décodage. Générer un token, c’est lire tous les poids du modèle. À 273 Go/s, un modèle de 70B en INT4 (35 Go) plafonne théoriquement autour de 7-8 tokens/s en single-stream — et la réalité mesurée est en dessous. C’est pour cela qu’un modèle « qui rentre » peut être inutilisable en interactif.
1 Spark : la zone de confort des 7B–32B, et la falaise des 70B
Un seul nœud, c’est le royaume du raisonnable. Les chiffres communautaires (llama.cpp GGUF suite, août 2026) donnent un débit maximal de jusqu’à 67 tok/s sur un modèle de 35B en architecture A3B — comprenez un MoE léger qui active peu de paramètres par token. Sur les denses de 7B à 14B en FP16/FP8, on reste dans une zone de confort absolue. Les 32B en INT4 ou FP8 passent avec un contexte modéré.
La falaise commence aux 70B. Un Llama 3.3 70B ou un Qwen2.5 72B en INT4 rentre, mais avec un cache KV réduit et un débit de décodage plombé par la bande passante. Les mesures les plus parlantes viennent du cas DeepSeek-V4-Flash en IQ2_XXS (quantification très agressive) : ~14 tok/s en single-stream et 410 tok/s en prefill sur un seul Spark (antirez ds4, août 2026). C’est utilisable pour du batch, pénible pour du chat.
Ce qui ne rentre pas, en revanche, est tout aussi instructif : les MoE de grande taille (Mixtral 8x22B, Qwen3 235B-A22B) et les modèles 120B+ en précision utile. Le plafond NVIDIA de 200 milliards de paramètres sur un nœud est ambigu : 200 Md en paramètres totaux quantifiés ne signifie pas 200 Md avec un contexte utilisable. Un Qwen3 235B-A22B dépasse déjà ce plafond en paramètres totaux — la question de sa tenue sur un seul nœud n’est pas tranchée publiquement.
| Palier 1 Spark (128 Go) | Tient confortablement | Tient mais rame | Ne rentre pas |
|---|---|---|---|
| Dense 7B–14B | ✅ FP16/FP8 | — | — |
| Dense 32B | ✅ INT4/FP8, contexte modéré | ⚠️ contexte long | — |
| Dense 70B | — | ⚠️ INT4, KV réduit, ~14 tok/s (cas IQ2_XXS mesuré) | ❌ contexte long |
| MoE léger (35B-A3B) | ✅ jusqu’à 67 tok/s | — | — |
| MoE massif (Mixtral 8x22B, Qwen3 235B-A22B) | — | — | ❌ |
| 120B+ en précision utile | — | — | ❌ |
2 Spark : le point d’équilibre — et le curieux « 2 plus rapide que 3 »
Deux Spark, c’est le palier le plus intéressant du marché, et probablement celui que devrait viser la majorité des acheteurs sérieux. La raison est matérielle : la liaison QSFP directe via ConnectX-7 à 200 Gb/s entre deux nœuds permet un tensor parallel (TP=2) propre, sans commutateur. Et les chiffres sont là. Sur DeepSeek-V4-Flash en FP8 avec vLLM en TP=2 (août 2026) : ~41 tok/s en single-stream, ~350 tok/s en agrégé à concurrence 32, et ~1 785 tok/s en prefill. Le saut par rapport à un seul nœud est net — on triple le single-stream et on multiplie le prefill par plus de quatre.
Autre atout : le cache KV partagé entre les deux nœuds atteint 1 105 096 tokens sur cette configuration. C’est ce qui permet d’envisager des contextes sérieux et du serving multi-utilisateurs. Deux Spark couvrent ainsi la classe 70B–120B en FP8/INT4 avec un contexte crédible, et NVIDIA annonce 405 Md de paramètres sur ce palier.
Vient alors le paradoxe qui circule dans la communauté : « 2 Spark plus rapides que 3 ». L’explication tient à la topologie. À trois nœuds, il n’existe pas de maillage symétrique : le tensor parallel se dégrade en pipeline parallel déséquilibré, la communication inter-nœuds explose et le scaling efficiency s’effondre. Deux nœuds, c’est un lien point-à-point propre ; trois, c’est un réseau bancal où chaque token doit traverser des hops asymétriques. En prefill comme en décodage, la latence inter-token souffre. Conseil d’achat : deux plutôt que trois, sauf besoin mémoire absolu — et dans ce cas, mieux vaut sauter directement à quatre.
4 Spark : le royaume des MoE et des 400B
Le passage à quatre nœuds change de régime : on quitte la liaison directe pour un commutateur Ethernet, et NVIDIA pousse son plafond annoncé à 405 Md (QSFP) puis 700 Md (Ethernet). C’est le palier des MoE massifs : Mixtral 8x22B, Qwen3 235B-A22B, les gros Llama 4, DeepSeek en quantification agressive. On quitte le tensor parallel serré pour du pipeline parallel et de l’expert parallel — chaque nœud héberge un sous-ensemble d’experts, ce qui est naturellement adapté aux architectures MoE.
Les limites sont claires : les denses 120B+ avec grand contexte rament, et les modèles frontière non quantifiés ne rentrent toujours pas. Le scaling efficiency se dégrade (on n’est plus dans le régime linéaire), et le coût réel devient significatif : 4 × ~7 000 € HT, plus le commutateur Ethernet, plus l’électricité (60 à 200 W mesurés en charge par ServeTheHome, soit jusqu’à 800 W pour quatre nœuds en pointe). C’est un investissement d’infrastructure, pas un achat impulsif.
8 Spark : le cluster qui existe surtout sur le papier
Huit nœuds, c’est le palier le plus flou. NVIDIA ne le documente pas dans les mêmes termes que 1/2/4 — le plafond officiel s’arrête à 700 Md sur quatre nœuds. Le cluster à huit existe dans les labos et chez quelques chercheurs, mais les mesures publiques manquent. Les problèmes sont connus : RoCE, latence, goulot d’étranglement du commutateur, difficulté du tensor parallel au-delà de quatre nœuds. L’intérêt se déplace vers le pipeline parallel, le data parallel et le fine-tuning distribué — pas le serving interactif.
Les cas d’usage réalistes sont le serving multi-modèles (plusieurs petits modèles sur des nœuds séparés), la recherche et l’entraînement distribué. La mise en garde est simple : n’achetez pas huit Spark « au cas où ». C’est un projet d’infrastructure avec son lot d’ingénierie réseau.
| Palier | Plafond NVIDIA annoncé | Topologie | Modèles typiques | Débit mesuré (indicatif) |
|---|---|---|---|---|
| 1 Spark | 200 Md | — | 7B–32B, 70B en INT4 | jusqu’à 67 tok/s (35B-A3B) ; ~14 tok/s (70B IQ2_XXS) |
| 2 Spark | 405 Md | QSFP direct, TP=2 | 70B–120B FP8/INT4, DeepSeek-V4-Flash | ~41 tok/s single, ~350 tok/s @c=32, ~1 785 tok/s prefill |
| 4 Spark | 700 Md | Ethernet, PP/EP | MoE massifs (Mixtral 8x22B, Qwen3 235B-A22B) | non mesuré publiquement |
| 8 Spark | non documenté | RoCE, PP/DP | fine-tuning distribué, multi-modèles | non mesuré publiquement |
Fine-tuning local : ce que le Spark encaisse vraiment
Le fine-tuning est l’autre grand usage du Spark, et là aussi le dimensionnement prime. Distinguons trois régimes.
LoRA/QLoRA est le plus accessible : sur un seul Spark, on fine-tune des 7B–32B sans difficulté, et sur deux nœuds on attaque les 70B. La mémoire nécessaire combine poids + gradients + états d’optimiseur + activations ; en QLoRA, la base quantifiée en 4 bits réduit drastiquement l’empreinte, et le offload CPU/GPU sur mémoire unifiée change la donne — au prix du débit. Les outils sont matures : NeMo, TRL, Unsloth, llama.cpp.
Le full fine-tuning, en revanche, reste hors de portée sauf pour de petits modèles : les états d’optimiseur (Adam) triplent l’empreinte mémoire des poids, et même un 7B devient serré. C’est un point que les benchmarks publics couvrent mal — les chiffres de temps d’entraînement par palier manquent cruellement.
Recettes concrètes : rang LoRA 16–64 selon la tâche, base quantifiée 4 bits pour QLoRA, batch size modeste (1–4) avec accumulation de gradients, et surtout surveillance de la mémoire réelle via les outils système. Sur deux Spark, le tensor parallel accélère l’entraînement mais ajoute de la communication — à réserver aux modèles qui ne tiennent pas sur un nœud.
Logiciels et pièges de déploiement
Côté logiciel, l’écosystème est désormais solide : vLLM pour le serving haut débit (avec PagedAttention et quantification KV), llama.cpp pour la flexibilité et les quantifications agressives (GGUF), et l’option NVIDIA AI Enterprise (NIM, NeMo, Triton) pour les déploiements industrialisés. GPUDirect Storage avec ConnectX complète le tableau pour les charges I/O-intensives.
Les pièges, eux, restent les mêmes qu’au premier jour. Tensor parallel mal dimensionné : TP=2 sur deux nœuds, TP=4 sur quatre, jamais TP=3. Offload mal réglé : sur mémoire unifiée, l’offload CPU/GPU est tentant mais coûte en débit — à utiliser quand la mémoire manque, pas par défaut. Quantification qui casse la qualité : l’INT4 agressif (IQ2_XXS) fait tenir un 70B mais dégrade la sortie ; le FP8 est le bon compromis sur GB10. Cache KV surestimé : c’est la cause numéro un des OOM en production. Contexte trop ambitieux : 128k sur un 70B en INT4 ne tient pas.
Check-list d’achat : un Spark pour découvrir et servir du 7B–32B ; deux Spark pour la classe 70B–120B en production locale ; quatre Spark pour les MoE massifs, avec budget réseau ; huit Spark pour un projet de recherche structuré. Et une ouverture : les mises à jour logicielles de 2026 — vLLM, llama.cpp, les outils NVIDIA — continuent d’améliorer les débits sans changer le matériel. Le Spark 64 Go lancé le 23 octobre rebat les cartes à la baisse pour les petits budgets, mais confirme la règle : c’est la mémoire utile, pas la mémoire annoncée, qui décide.
Sources
- NVIDIA DGX Spark 64GB Gives Developers More Ways to Build and Scale Local AI — blogs.nvidia.com, 2 octobre 2026
- NVIDIA Announces DGX Spark 64GB: A 1-PetaFLOP Grace Blackwell Desktop for Local AI Agents, Fine-Tuning, and Inference — marktechpost.com, 2 octobre 2026
- NVIDIA DGX Spark 64GB Rolls Out Friday With New Local AI Tools — technobezz.com, octobre 2026
- Nvidia lance le DGX Spark en 64 Go : faut-il acheter deux petits plutôt qu’un gros ? — frandroid.com, 2 octobre 2026
- The Best DGX Spark for Local AI in 2026: LLM Speed, Model Sizes, and Clusters, With Sources — pyshine.com, 1er octobre 2026
- GitHub – Weschera/spark-bench: Mixed-capability LLM benchmark for DGX
- LLM Benchmark v4: the open source verdict (as of Oct 2026) — akitaonrails.com, 22 octobre 2026
- AA-AgentPerf-Local: Benchmarking local AI agents on laptops and workstations — artificialanalysis.ai, 29 septembre 2026
- NVIDIA DGX Platform — nvidia.com
- Systèmes DGX : conçus pour répondre aux demandes uniques de l’IA — nvidia.com
Article recherché et rédigé automatiquement · Magazine Electrosens