---

64 Go sur la table : ce que NVIDIA a réellement changé (et ce qu’il n’a pas touché)

Commençons par la genèse, parce qu’elle est plus étrange qu’il n’y paraît. Le 2 octobre 2026, une salve de publications — NeoTeo, Clubic, Frandroid, Hardwareluxx Russia, PauseHardware — relaie la même information : NVIDIA décline son DGX Spark en une configuration à 64 Go de mémoire unifiée, commercialisée à partir du 23 octobre, distribuée par Acer, ASUS, Dell, Gigabyte, HP et MSI. Le billet officiel de NVIDIA, intitulé « NVIDIA DGX Spark 64GB Gives Developers More Ways to Build and… », confirme l’existence de la variante et liste ces six partenaires.

Le détail qui fâche arrive tout de suite : 4 999 dollars. C’est le prix annoncé par plusieurs sources, dont Frandroid et PauseHardware, qui précisent que la version 128 Go, elle, dépasse désormais les 6 000 dollars sur le marché. Autrement dit : vous payez aujourd’hui pour 64 Go ce que vous payiez hier pour 128 Go. La raison invoquée, relayée par Hardware & Co, est sans mystère : la flambée des cours de la LPDDR5. NVIDIA ne rogne pas sur la marge par plaisir — il rogne sur la mémoire parce que la mémoire coûte cher.

Ce qu’il faut comprendre, c’est ce qui reste strictement identique. Le DGX Spark 64 Go conserve le GB10 Grace Blackwell Superchip, le système d’exploitation DGX OS et l’intégralité de la pile logicielle NVIDIA AI. La liste de compatibilité annoncée est la même : NVIDIA Agent Toolkit, CUDA-X AI, modèles Nemotron, Ollama, vLLM, PyTorch avec CUDA. Chaque unité embarque toujours une NIC ConnectX-7 intégrée, et deux machines peuvent se connecter directement via câble QSFP. Blender doit recevoir un installeur précompilé « bientôt », sans date ferme.

Donc, pour être clair : ce n’est pas un produit différent. C’est le même ordinateur, amputé de la moitié de sa mémoire unifiée, vendu au prix d’hier. Toute la question — et elle est sérieuse — est de savoir si cette amputation est un handicap ou un levier. Parce que NVIDIA, dans le même communiqué, avance un chiffre qui mérite qu’on s’y arrête : jusqu’à 100 milliards de paramètres sur un seul nœud, et jusqu’à 200 milliards sur deux.

---

Un nœud, 100 milliards de paramètres : la vraie frontière du 64 Go

Le chiffre des 100B est un chiffre marketing, et il faut le traiter comme tel — c’est-à-dire avec respect mais sans naïveté. NVIDIA ne précise pas dans la matière disponible quel format de quantification permet de l’atteindre. C’est une lacune réelle, et elle change tout : entre un modèle servi en FP8 et le même en NVFP4, l’empreinte mémoire n’a rien à voir.

Ce qu’on peut dire avec les données dont on dispose, en revanche, est déjà très instructif. Le magazine a documenté qu’un seul DGX Spark fait tourner DeepSeek-V4-Flash en IQ2_XXS à environ 14 tok/s en single-stream, avec un prefill à 410 t/s, et qu’une suite llama.cpp en GGUF atteint jusqu’à 67 tok/s sur un modèle 35B-A3B. Sur Qwen3.8-27B, un nœud unique délivre 34 à 38 tok/s (donnée du 20 août 2026). Sur Qwen3.6-27B, on monte à 28-33 tok/s en session unique, avec un pic de décodage à 163 tok/s et 136 tok/s avec dix agents en parallèle.

Traduisons cela en frontière pratique. La règle empirique pour un modèle dense en 4 bits tourne autour de 0,55 à 0,6 Go par milliard de paramètres, auxquels s’ajoute le cache KV. Sur 64 Go, cela place le plafond confortable autour de 90 à 100 milliards de paramètres — exactement la fourchette annoncée. Un Qwen 2.5 72B en INT4 tient sans difficulté. Un Mixtral 8x22B, qui est un MoE, tient aussi, mais avec une nuance : un MoE n’active qu’une fraction de ses paramètres par token, ce qui aide le débit mais pas l’empreinte — tous les experts doivent résider en mémoire.

Là où ça se corse, c’est le haut du panier. DeepSeek V3, avec ses centaines de milliards de paramètres, ne rentre pas sur un nœud, même en quantification agressive. Et Llama 3.1 405B ? Il reste hors de portée sur un seul Spark 64 Go, quelle que soit la quantification — même en dessous de 2 bits, l’empreinte dépasse la capacité. C’est une frontière dure, pas une frontière marketing.

Le point de bascule entre quantifications mérite d’être explicité. En FP8, vous doublez grossièrement l’empreinte par rapport à l’INT4 : le plafond tombe alors autour de 45-50B de paramètres. En INT4, vous êtes dans la zone des 90-100B. En NVFP4 — le format 4 bits de NVIDIA, avec des échelles de bloc plus fines — vous restez dans la même enveloppe mémoire que l’INT4, avec un espoir de meilleure fidélité numérique. C’est précisément là que se joue l’arbitrage : le 64 Go n’est pas un nœud « petit », c’est un nœud 4 bits. Si votre usage exige du FP8, vous êtes sur un 40-50B, pas un 100B.

---

2x Spark 64 Go = 128 Go : le cluster qui promet 200B, mais à quel prix en bande passante

C’est ici que l’histoire devient intéressante, et c’est ici qu’il faut distinguer soigneusement le gain réel du gain marketing.

NVIDIA annonce que deux unités DGX Spark 64 Go en cluster via le Sync Cluster Assistant poolent 128 Go de mémoire, supportent jusqu’à 200 milliards de paramètres, avec 2x la bande passante mémoire et jusqu’à 1,7x la performance. Ce dernier chiffre provient d’un test interne NVIDIA sur Qwen 3.8 27B — un seul modèle, une seule charge, non reproduit indépendamment. Il faut donc le prendre pour ce qu’il est : un point de repère, pas une loi.

La topologie, en revanche, est documentée et elle est essentielle. Il n’y a pas de NVLink-C2C entre nœuds. Le lien se fait par la NIC ConnectX-7 intégrée, via câble QSFP en direct pour deux machines. C’est du réseau haute vitesse, pas de la cohérence mémoire matérielle au sens des superpuces Grace-Hopper. Cette distinction n’est pas sémantique : elle détermine la latence inter-nœuds, et donc la viabilité du tensor parallel sur de gros modèles.

Les chiffres du magazine sur le cluster 2x sont éloquents. En TP=2 avec vLLM sur DeepSeek-V4-Flash FP8, on obtient ~350 tok/s agrégés à concurrence 32 et ~41 tok/s en single-stream, avec un prefill à ~1 785 t/s. Le pool de cache KV partagé atteint 1 105 096 tokens. Et la taille maximale de modèle supportée sur 2x DGX Spark est documentée à 405 milliards de paramètres.

Ce dernier chiffre est le plus important de tout l’article, et il mérite d’être souligné : deux Spark, quelle que soit leur configuration mémoire, atteignent 405B. C’est la vraie promesse du clustering. Mais notez le contraste : le single-stream à 41 tok/s sur un modèle de la classe DeepSeek-V4-Flash est correct sans être spectaculaire. Le gain du cluster se voit surtout en agrégé, quand la concurrence monte — c’est-à-dire quand vous servez plusieurs agents ou plusieurs utilisateurs.

Le « 2x la bande passante mémoire » mérite une précision. Il ne s’agit pas de doubler la bande passante par nœud — chaque GB10 garde la sienne. Il s’agit du fait que deux nœuds accèdent à deux pools mémoire en parallèle, ce qui, pour un modèle réparti en tensor parallel, augmente effectivement le débit agrégé d’accès. Le gain est réel, mais il est conditionné à la qualité de la répartition : mal réparti, un cluster 2x n’est qu’une addition de deux nœuds isolés qui se parlent mal.

---

4x Spark 64 Go : le scénario DeepSeek V4.1-Flash et les limites du pooling mémoire

Passons à quatre nœuds, parce que c’est là que le DGX Spark 64 Go révèle sa vraie nature — et ses vraies limites.

Le cas d’usage canonique est un modèle de type DeepSeek V4.1-Flash, architecture MoE, servi en NVFP4. Sur quatre nœuds, on dispose théoriquement de 256 Go de mémoire unifiée agrégée. Mais « agrégée » est le mot piège. Il n’y a pas de cohérence mémoire matérielle entre les nœuds : chaque Spark voit sa propre mémoire, et le partage se fait par logiciel, au niveau du runtime d’inférence. Cela signifie que les contraintes de répartition sont rigides : chaque couche, chaque expert, chaque bloc de cache KV doit résider quelque part de précis, et le trafic inter-nœuds dépend directement de la topologie.

C’est là que la distinction étoile vs anneau devient décisive. En connexion directe QSFP, deux nœuds se parlent en un saut. À quatre, vous avez besoin soit d’un switch, soit d’une topologie maillée partielle. La latence inter-nœuds n’est pas la même selon le chemin, et un modèle MoE dont les experts sont répartis de façon sous-optimale peut passer l’essentiel de son temps à attendre le réseau plutôt qu’à calculer.

Le coût par token, dans ce scénario, est l’arbitrage central. Quatre Spark 64 Go représentent un investissement matériel de l’ordre de 20 000 dollars au prix public annoncé. Pour ce montant, vous obtenez une capacité mémoire agrégée de 256 Go — comparable, sur le papier, à ce que propose une station de travail haut de gamme, mais avec une architecture fondamentalement différente : distribuée plutôt que monolithique. Le débit agrégé peut être excellent en charge concurrente ; le single-stream, lui, sera toujours pénalisé par la latence inter-nœuds.

Et il y a un plafond dur : le nombre maximum de nœuds supportés. La matière disponible ne le précise pas explicitement, mais la documentation NVIDIA sur le clustering multi-nœuds du Spark, mise à jour en juin 2026, encadre les scénarios 2x et 4x. Au-delà, on sort du cadre supporté. C’est une contrainte à intégrer dès la conception : un cluster Spark n’est pas un cluster extensible à l’infini, c’est un cluster petit et contraint.

---

vLLM, NIM et compagnie : les réglages qui font ou défont un cluster Spark

Voici la partie que personne ne lit assez attentivement, et qui pourtant décide de tout.

Premier réglage : le choix du parallélisme. Sur un cluster Spark, le tensor parallel (TP) découpe chaque couche entre les nœuds — il exige beaucoup de communication inter-nœuds à chaque passe avant. Le pipeline parallel (PP) découpe le modèle par étages — il communique moins souvent mais introduit de la latence de bulle. Sur un lien ConnectX-7 sans NVLink-C2C, le TP est viable à 2 nœuds (les chiffres de ~350 tok/s agrégés le prouvent), mais devient nettement plus délicat à 4. La règle pratique : TP dans le nœud quand c’est possible, PP entre les nœuds quand le modèle est très profond.

Deuxième réglage : la quantification. Servir un modèle en FP8 sur un cluster 64 Go, c’est se priver de la moitié de la capacité utile. Le format NVFP4 est celui qui maximise le rapport performance/VRAM, et c’est celui que NVIDIA pousse via sa pile. Mais attention : tous les modèles ne se quantifient pas proprement en 4 bits. Un modèle distillé ou déjà très compressé peut perdre beaucoup en NVFP4.

Troisième réglage : le cache KV. C’est le levier le plus sous-estimé. Un pool de cache KV partagé de 1 105 096 tokens sur un cluster 2x, c’est ce qui permet de servir plusieurs agents simultanément sans recharger le contexte à chaque requête. Mal configuré — par exemple avec une taille de bloc inadaptée ou une politique d’éviction trop agressive — vous perdez tout le bénéfice du pooling. Sur vLLM, cela se joue sur les paramètres de block_size et de gpu_memory_utilization, qu’il faut calibrer en fonction du nombre de nœuds et de la longueur moyenne des contextes.

Quatrième réglage : le déploiement NIM. NVIDIA propose des conteneurs NIM prêts à l’emploi, qui embarquent les optimisations TensorRT-LLM. C’est le chemin le plus court vers la performance, mais c’est aussi le moins flexible : vous dépendez des modèles supportés et des versions publiées. Pour l’expérimentation, vLLM reste plus souple.

Le piège numéro un, celui qui transforme un cluster 2x en simple addition de nœuds isolés : oublier de vérifier que le modèle est effectivement réparti. Un tensor_parallel_size=2 mal configuré, ou un modèle chargé intégralement sur un seul nœud faute de support du sharding, et vous avez payé deux machines pour en utiliser une. Vérifiez toujours l’occupation mémoire des deux nœuds après le chargement.

---

Fine-tuning LoRA sur 64 Go : ce qui passe, ce qui coince

Le fine-tuning est l’autre grande promesse du Spark, et le 64 Go change la donne de façon mesurable.

Sur un seul nœud 64 Go, la fourchette réaliste va de 7B à 70B en quantification 4 bits. Un 7B se fine-tune confortablement avec un rank LoRA de 16 à 64 et une batch size de 4 à 8. Un 13B ou un 30B reste dans le domaine du faisable avec gradient checkpointing activé — qui échange de la VRAM contre du temps de calcul. Un 70B en 4 bits devient serré : il faut réduire la batch size à 1 ou 2, activer le checkpointing, et accepter des temps d’entraînement longs.

Les hyperparamètres critiques sont toujours les mêmes, mais leur pondération change sur 64 Go. Le rank LoRA : plus il est élevé, plus vous consommez de mémoire pour les adaptateurs, mais plus vous capturez de signal. Sur un nœud contraint, viser 16-32 plutôt que 64-128. La batch size : c’est le premier levier à sacrifier. Le gradient checkpointing : indispensable au-delà de 13B.

Sur un cluster 2x, vous doublez la mémoire disponible, ce qui ouvre la porte aux modèles de la classe 70B+ en 4 bits avec des batch sizes plus confortables, et raccourcit les temps d’entraînement par parallélisme de données. Mais le fine-tuning distribué ajoute sa propre complexité : synchronisation des gradients, gestion des checkpoints, et sensibilité à la latence réseau. Pour un LoRA sur un 13B, un seul nœud est plus simple et probablement plus rapide au total, une fois la complexité de mise en place comptée.

---

64 Go vs 128 Go vs RTX 5090 : le match des coûts par token

Critère	DGX Spark 64 Go	DGX Spark 128 Go	RTX 5090 (station)
Prix d’acquisition	4 999 $ (dès le 23/10/2026)	> 6 000 $	Non précisé
Mémoire unifiée	64 Go	128 Go	VRAM dédiée (non précisée)
Modèle max sur 1 nœud	~100B (annoncé NVIDIA)	~200B (annoncé NVIDIA)	Non précisé
Clustering multi-nœuds	Oui (ConnectX-7, QSFP)	Oui	Non
Débit 27B (référence)	34-38 tok/s (Qwen3.8-27B)	Non précisé	Testé dans AA-AgentPerf-Local
Benchmark agentique	Testé (AA-AgentPerf-Local)	Non précisé	Testé (AA-AgentPerf-Local)

Le tableau ci-dessus est volontairement honnête sur ses trous : la matière disponible ne fournit pas de chiffres de débit pour le Spark 128 Go sur les mêmes charges, ni de prix pour la RTX 5090. Ce qu’on sait, en revanche, c’est que la RTX 5090 a été testée aux côtés du DGX Spark dans le benchmark AA-AgentPerf-Local d’Artificial Analysis, publié le 29 septembre 2026, aux côtés du Ryzen AI Halo et du MacBook Pro M5 Pro, sur quatre modèles open weight.

Ce benchmark est précieux parce qu’il mesure exactement ce qui compte pour un cluster maison : la performance agentique locale. Et il met en évidence un point que les fiches techniques masquent : sur les charges d’agents, le débit agrégé compte plus que le débit single-stream. Un DGX Spark qui sert dix agents à 136 tok/s cumulés (Qwen3.6-27B) est plus utile, pour un usage agentique, qu’une carte unique très rapide en single-stream.

Le match des coûts par token, en réalité, se joue sur trois axes. L’acquisition : le Spark 64 Go est le point d’entrée le moins cher de la gamme DGX, mais il coûte le prix de l’ancien 128 Go. La consommation : le GB10 est un SoC économe comparé à une station multi-GPU — un avantage décisif pour un cluster maison, où le bruit et la chaleur comptent autant que les tok/s. Le refroidissement : un Spark est silencieux et compact ; une station RTX 5090 ne l’est pas.

Pour un usage d’inférence locale d’un modèle 122B en INT4, le calcul est simple : il faut soit un cluster 2x Spark 64 Go (128 Go agrégés, ~10 000 $), soit un Spark 128 Go seul (> 6 000 $). Le cluster gagne en capacité de montée en charge, le nœud unique gagne en simplicité et en latence.

---

Cluster maison : topologies, alimentation et pièges du multi-nœuds à petit budget

Le clustering maison sur Spark a une vertu rare : il est conçu pour ça. La NIC ConnectX-7 intégrée et le câble QSFP direct signifient qu’un cluster 2x se monte sans switch, sans infrastructure réseau dédiée. C’est une différence majeure avec un cluster GPU classique, où l’interconnexion coûte souvent plus cher que les cartes.

Pour deux nœuds : connexion QSFP directe, latence minimale, simplicité maximale. C’est le scénario idéal du Spark 64 Go. Vous obtenez 128 Go agrégés, jusqu’à 200B de paramètres annoncés, un pool de cache KV d’un million de tokens, et un débit agrégé qui monte à ~350 tok/s sur un modèle de classe DeepSeek-V4-Flash.

Pour quatre nœuds : la topologie change tout. En étoile via switch, vous centralisez le trafic mais ajoutez un point de défaillance et un coût. En anneau, vous réduisez le câblage mais augmentez le nombre de sauts moyens. La documentation NVIDIA encadre les scénarios multi-nœuds, mais la matière disponible ne précise pas le nombre maximum supporté au-delà de 4x.

Les contraintes physiques : alimentation stable (un cluster de quatre nœuds, c’est quatre blocs d’alimentation à gérer), refroidissement (les Spark sont compacts, mais quatre dans une pièce, ça chauffe), et bruit (avantage net au Spark face aux stations GPU).

Le piège principal : acheter un 64 Go en pensant « j’ajouterai un deuxième plus tard » sans vérifier que le modèle visé supporte effectivement le sharding multi-nœuds. Certains modèles, notamment les architectures exotiques ou les MoE mal supportés, ne se répartissent pas proprement. Un 64 Go seul qui ne peut pas monter en cluster est un cul-de-sac ; un 64 Go qui monte à 2x est une plateforme.

---

Ce que le 64 Go change vraiment : feuille de route pour les six prochains mois

Alors, verdict ?

Le DGX Spark 64 Go n’est pas un produit dégradé. C’est un produit repositionné. NVIDIA a compris que son marché n’est pas celui du nœud unique maximal, mais celui du cluster progressif : commencer à 4 999 $, ajouter un nœud quand le besoin monte, atteindre 200B de paramètres sans jamais acheter une station de travail à cinq chiffres.

Pour qui vise l’inférence locale pure sur un modèle de 70B ou moins, le 64 Go est un bon point d’entrée — à condition d’accepter la quantification 4 bits. Pour qui vise le fine-tuning LoRA sur du 7B à 30B, c’est confortable. Pour qui vise l’expérimentation multi-nœuds, c’est le meilleur rapport capacité/prix de la gamme, précisément parce que le clustering est natif.

Là où c’est un piège : si vous avez besoin de FP8 sur un gros modèle, si vous voulez servir un 405B sur un seul nœud (impossible, il faut 2x), ou si vous comptiez sur le prix pour compenser la perte de mémoire — ce qui n’est pas le cas, puisque le 64 Go coûte le prix de l’ancien 128 Go.

Les six prochains mois seront décisifs sur trois fronts. La pile logicielle : le NVFP4 et le Sync Cluster Assistant vont continuer de mûrir, et c’est là que se gagnera la performance réelle. La concurrence : Acer propose déjà un mini-PC à 128 Go de mémoire unifiée, livré depuis le 8 septembre 2026, positionné 500 à 1 000 dollars sous le prix NVIDIA. C’est une pression directe sur le positionnement du Spark 64 Go. L’écosystème : le benchmark AA-AgentPerf-Local d’Artificial Analysis, lancé le 29 septembre 2026, donne enfin un cadre de mesure indépendant pour comparer Spark, Ryzen AI Halo, MacBook M5 Pro et RTX 5090 sur des charges agentiques réelles.

La vraie question n’est donc pas « 64 Go ou 128 Go ». C’est : voulez-vous un nœud ou une plateforme ? Si la réponse est « une plateforme », le 64 Go est le bon choix — et le cluster, votre horizon.

---

Sources

• NVIDIA DGX Spark 64GB Gives Developers More Ways to Build and… — blog officiel NVIDIA
• NVIDIA Announces DGX Spark 64GB: A 1-PetaFLOP Grace Blackwell Desktop for Local AI Agents, Fine-Tuning, and Inference — MarkTechPost, 2 octobre 2026
• Nvidia launches DGX Spark 64GB configuration with hardware partners — CryptoBriefing
• DGX Spark 64 Go : NVIDIA annonce une configuration — NeoTeo, 3 octobre 2026
• NVIDIA lance un DGX Spark 64 Go : moins de mémoire, mais une drôle d’astuce pour dépasser le modèle 128 Go — Clubic, 2 octobre 2026
• Nvidia lance le DGX Spark en 64 Go : faut-il acheter deux petits plutôt qu’un gros ? — Frandroid, 2 octobre 2026
• Le DGX Spark Perd La Moitié De Sa Mémoire Mais Conserve Son Tarif De 4 999 Dollars — PauseHardware, 2 octobre 2026
• NVIDIA DGX Spark June 2026 Update: Multi-Node Clustering, NVFP4 — ChatForest
• Run Local AI Agents with Faster Models and Multi-Node Clustering on NVIDIA DGX Spark — NVIDIA Developer Blog
• AA-AgentPerf-Local: Benchmarking local AI agents on laptops and workstations — Artificial Analysis, 29 septembre 2026
• Nvidia DGX — Wikipedia
• Systèmes DGX : conçus pour répondre aux demandes uniques de l’IA — NVIDIA
• DGX Platform: Built for Enterprise AI — NVIDIA
• NVIDIA DGX Platform — Documentation — NVIDIA Docs