---

Un an et demi après : le DGX Spark est-il devenu la référence de l’IA locale ?

Dévoilé au CES 2025 sous le nom de code Project DIGITS, le DGX Spark a fait couler beaucoup d’encre avant même d’arriver sur les bureaux. NVIDIA promettait une machine de bureau capable de faire tourner des modèles de langage jusqu’à 200 milliards de paramètres en inférence et d’en fine-tuner jusqu’à 70 milliards, le tout pour un prix initial de 3 999 $. Le lancement effectif a eu lieu en octobre 2025, mais dès février 2026, le prix grimpait à 4 699 $, soit une hausse de 18 % qui a laissé un goût amer à certains acheteurs potentiels. Aujourd’hui, le prix oscille autour de 4 679–4 699 $ selon les revendeurs, et le Asus Ascent GX10 (la version d’Asus) est descendu à 2 760 € en France, ce qui en fait une option nettement plus abordable. L’Acer DGX, autre clone OEM, se positionne 500 à 1 000 $ sous le prix NVIDIA, avec une disponibilité européenne encore limitée.

Sous le capot, le DGX Spark embarque le superchip GB10 Grace Blackwell, combinant un CPU ARM Grace (20 cœurs ARMv9 : 10 Cortex-X925 + 10 Cortex-A725) et un GPU Blackwell (6 144 cœurs CUDA, Tensor Cores 5e génération avec support natif FP4) reliés par NVLink-C2C, avec 128 Go de mémoire unifiée LPDDR5X à 273 Go/s et une performance annoncée de 1 pétaflop en FP4. Sur le papier, c’est une station de travail IA compacte et silencieuse, taillée pour le développement local sans dépendre du cloud. Le tout tourne sous DGX OS, un Ubuntu Server 24.04 ARM customisé avec la stack NVIDIA AI Enterprise pré-installée : CUDA 13.0, cuDNN, NCCL, drivers Blackwell et Docker NVIDIA Container Toolkit.

Mais un an et demi plus tard, le décalage entre les promesses marketing et la réalité terrain mérite d’être examiné. Les premiers benchmarks indépendants, comme ceux de LMSYS en octobre 2025, ont montré que le DGX Spark pouvait atteindre 10 256 tokens/s en prefill sur Llama 3.1 8B – un chiffre impressionnant, au niveau d’un RTX Pro 6000 Blackwell. Pourtant, des voix s’élèvent : certains utilisateurs rapportent que le format NVFP4, pourtant vanté comme un atout majeur, n’est pas systématiquement plus rapide que le FP8, et que des bugs logiciels comme le split CPU d’Ollama continuent de gâcher l’expérience. Ce dossier de fond dresse un bilan complet, sans concession, pour vous aider à décider si le DGX Spark est fait pour vous – et comment l’exploiter au mieux en cette fin 2026.

---

Mises à jour 2026 : les correctifs qui changent la donne (et ceux qui manquent encore)

NVIDIA n’a pas laissé sa machine sans soin. Depuis le lancement, plusieurs mises à jour logicielles et firmware ont été déployées, avec des effets parfois spectaculaires.

Les grands gagnants : TensorRT-LLM, NVFP4 et la gestion mémoire

En avril 2026, une mise à jour majeure a apporté un gain de performance allant jusqu’à 2,6× sur le modèle Qwen-235B, grâce à l’intégration poussée de TensorRT-LLM et du nouveau format de données NVFP4, avec décodage spéculatif. Concrètement, cela signifie qu’un modèle de 235 milliards de paramètres, qui aurait été impensable à faire tourner en local il y a encore un an, devient utilisable – certes à des vitesses modestes, mais utilisable. La même mise à jour a introduit le décodage spéculatif, qui réduit le temps de première réponse, et a permis à Nsight CUDA Copilot de fonctionner entièrement en local sur la machine, un atout pour le débogage. Selon le blog officiel de NVIDIA, cette optimisation est particulièrement visible sur une configuration double DGX Spark : avec FP8, le modèle sature la mémoire combinée des deux systèmes ; en NVFP4, la mémoire utilisée chute d’environ 40 % tout en maintenant une précision élevée, libérant de la place pour exécuter d’autres charges de travail simultanément.

En juillet 2026, une nouvelle mise à jour a ciblé la gestion mémoire, améliorant la stabilité lors de l’exécution de modèles lourds. Les notes de version officielles (disponibles sur les forums développeurs NVIDIA) mentionnent également des correctifs pour les fuites mémoire sous certaines charges. Selon l’analyse d’ai-muninn (partie 38 de leur série DGX Spark), cette mise à jour a enfin dompté les OOM (out-of-memory) qui frappaient les utilisateurs de modèles volumineux, notamment en réduisant la fragmentation du cache KV. Les retours terrain de septembre 2026 confirment que les plantages liés à la mémoire sont devenus rares, même sur des modèles de 100 Go+.

CUDA 13.4 : le Windows on Arm entre en jeu

Le 21 juillet 2026, NVIDIA a publié la première developer preview de CUDA Toolkit 13.4 pour Windows on Arm (Arm64). C’est une étape majeure : les développeurs peuvent désormais préparer leurs applications pour la future plateforme RTX Spark (le cousin grand public du DGX Spark, dévoilé au Computex 2026) sans même posséder le matériel. SEGA l’a déjà adoptée. Cela signifie que l’écosystème logiciel du GB10 s’étend au-delà de Linux, même si DGX OS (la distribution Linux de NVIDIA) reste la plateforme de référence pour le Spark.

Septembre 2026 : NVIDIA simplifie l’IA locale et optimise vLLM & llama.cpp

Le 3 septembre 2026, NVIDIA a annoncé une simplification du support IA local pour ses GPU équipés de 24 Go+ de VRAM, avec des optimisations ciblées pour vLLM et llama.cpp (source : wccftech.com). Si cette annonce vise d’abord les RTX, elle confirme la direction prise par NVIDIA : faire de l’inférence locale une expérience fluide sur l’ensemble de sa gamme, du DGX Spark aux stations de travail. Les optimisations vLLM et llama.cpp profitent directement au GB10, qui partage la même pile logicielle.

Speculative decoding : Uzu et Qwen3.8-Flash-Next

Le 3 septembre 2026, l’équipe de Uzu (moteur d’inférence émergent) a publié son implémentation de décodage spéculatif, initialement pour Qwen3.6 27B, avec le support de Qwen3.8 27B et Muse Glimmer annoncé prochainement. Sur les puces Apple M5, Uzu surpasse MTPLX, mais l’intérêt pour le DGX Spark est ailleurs : le décodage spéculatif est l’un des leviers les plus efficaces pour compenser la bande passante limitée de 273 Go/s.

Parallèlement, le 2 septembre 2026, le support MTP (Multi-Token Prediction) est arrivé pour Qwen3.8-Flash-Next en GGUF, avec un speedup de 1,67× et zéro perte de qualité : le débit passe de 83 à 138 tok/s (source : banandre.com). C’est une avancée significative pour les utilisateurs de llama.cpp sur le Spark.

Les bugs qui résistent

Malgré ces progrès, la communauté (notamment via le blog indépendant ai-muninn) pointe plusieurs irritants persistants :

• Ollama et le split CPU : Ollama a tendance à répartir la charge entre CPU et GPU de manière sous-optimale, ce qui dégrade les performances sur les modèles de taille moyenne. Un contournement manuel est possible, mais pas trivial.
• NVFP4 vs FP8 : Contre-intuitivement, le format NVFP4 n’est pas toujours plus rapide que le FP8 sur le GB10. Pour certains modèles, la conversion et la gestion mémoire annulent le gain de bande passante. Il faut tester au cas par cas.
• Chemin de quantification communautaire obsolète : L’ancien script gemma4_patched.py utilisé par la communauté pour quantifier les modèles Gemma 4 ne fonctionne plus avec les dernières versions de TensorRT-LLM. Les utilisateurs doivent migrer vers les outils officiels NVIDIA, ce qui réduit la flexibilité.

Mise à jour	Date	Principaux apports	Source
Lancement	Octobre 2025	DGX OS, CUDA, TensorRT, NeMo, llama.cpp	NVIDIA
Avril 2026	Avril 2026	Gain 2,6× sur Qwen-235B (TensorRT-LLM + NVFP4 + décodage spéculatif), Nsight local	developer.nvidia.com
Juillet 2026	Juillet 2026	Amélioration gestion mémoire, correctifs stabilité	forums.developer.nvidia.com
CUDA 13.4 Preview	21 juillet 2026	Support Windows on Arm (Arm64) pour RTX Spark	igorslab.de, techtimes.com
Septembre 2026	3 septembre 2026	Simplification IA locale GPU 24+ Go, optimisations vLLM & llama.cpp	wccftech.com
Uzu speculative decoding	3 septembre 2026	Décodage spéculatif pour Qwen3.6/3.8 27B	trymirai.com
Qwen3.8-Flash-Next MTP	2 septembre 2026	MTP GGUF : 1,67× speedup, 83→138 tok/s	banandre.com

Au total, le DGX Spark a bien évolué, mais certains défauts logiciels hérités des premiers mois n’ont pas été entièrement résolus. La prudence reste de mise avant de se lancer dans des déploiements critiques.

---

Benchmarks réels : ce que valent vraiment les modèles open-source sur le GB10

Les chiffres parlent. Voici les performances mesurées par des sources tierces, avec les modèles qui tournent réellement bien sur le GB10 en septembre 2026.

Les chiffres clés

• Llama 3.1 8B : 10 500 tokens/s en prefill (benchmark LMSYS, octobre 2025, rapporté par syskb.com). C’est un score remarquable, comparable à une carte graphique professionnelle haut de gamme.
• Gemma 4 26B-A4B (modèle MoE avec 4B actifs) : 108 tokens/s en utilisant vLLM avec multi-token prediction (MTP) et quantification NVFP4 (source : ai-muninn.com, 2026). C’est le meilleur débit rapporté pour un modèle de cette taille. Le chemin officiel (NVFP4 + vLLM stock) est désormais recommandé, l’ancien script communautaire étant obsolète.
• Qwen3-Next-80B : 82 tokens/s avec le moteur Atlas (source : ai-muninn.com, été 2026). Un résultat impressionnant pour un modèle de 80B, qui montre que le choix du moteur d’inférence est crucial.
• GPT-OSS-120B : 35–80+ tokens/s selon la quantification et la longueur de prompt (source : explainx.ai, 2026). Le mythe du « tout puissant » s’effondre : c’est fiable mais lent en haut de fourchette.
• Modèle dense 31B : 7 tokens/s (ai-muninn.com). La chute est brutale : les modèles denses de taille moyenne peinent sur le GB10, faute de bande passante mémoire suffisante (273 Go/s, un chiffre qui plafonne tout).
• Ant Ling-3.0-Flash 124B-A5B (MoE, 5B actifs, sorti le 23 juillet 2026) : 15-20 tokens/s estimés (non officiel, forums développeurs NVIDIA, juillet 2026). Ce modèle, qui bat leur précédent modèle 1T sur presque tous les benchmarks, montre le potentiel des architectures hybrides (attention linéaire KDA + MLA) pour le Spark.
• DeepSeek V4 Flash 0731 (sorti le 31 juillet 2026) : 284 milliards de paramètres totaux, 13 milliards actifs par token, contexte d’un million de tokens, poids mixtes FP4+FP8 (167 Go sur Hugging Face) et module DSpark fusionné. Sur un cluster de 2 DGX Spark, il atteint 30 tok/s en configuration par défaut, mais avec un petit changement de config, l’acceptance remonte (source : forums.developer.nvidia.com). En Q8 (UD-Q8_K_XL), le modèle pèse 162 Go, ce qui nécessite 2 nœuds ; en Q4, il tient sur un seul Spark avec 128 Go. Sur un seul Spark, le prefill atteint 1 000 tok/s et le serving multi-agent 59 tok/s (source : forums.developer.nvidia.com, 1er août 2026). Le dual DGX Spark avec 13B actifs change la donne pour les agents IA privés (source : flowtivity.ai).
• Qwen-235B : aucun chiffre de débit précis n’a été publié, mais la mise à jour d’avril 2026 revendique un gain 2,6×, ce qui suggère une utilisation possible, même lente.
• Qwen3.8-27B (nouveau, août 2026) : le meilleur choix polyvalent selon Tokenstead, avec 88/89/94 en coding/reasoning/tool-calling, 262K contexte, et seulement ~21 Go en UD-Q4_K_XL. Il tourne sur le chemin Ollama facile. Mesuré à 48 tok/s sur DGX Spark (source : blog.openzeka.com, 26 août 2026) et 34-38 tok/s selon un test du 20 août 2026. C’est le modèle star de la rentrée.
• Qwen3.6-27B (sorti le 22 avril 2026, NVFP4 le 26 juin 2026) : 163 tok/s en pic de décodage, 136 tok/s en multi-agents (10 agents), 28-33 tok/s en session unique, score MMLU NVFP4 de 0,8446, contexte 256K. Un excellent choix pour les charges multi-agents.
• Qwen 3.6 35B-A3B (optimisé NVFP4) : plus de 200 tok/s avec un tool-calling parfait, selon Tokenstead.
• Qwen3.8-Flash-Next : 83 à 138 tok/s avec MTP en GGUF (source : banandre.com, 2 septembre 2026).

Comparaison avec les promesses initiales

NVIDIA avait annoncé que le DGX Spark pourrait exécuter des modèles jusqu’à 200 milliards de paramètres. Les benchmarks confirment que c’est techniquement possible, mais à des vitesses très faibles (quelques tokens par seconde) pour les modèles denses. Les modèles MoE (comme Gemma 4 26B, Ant Ling, DeepSeek V4 Flash) tirent bien mieux parti de l’architecture grâce à leur faible nombre de paramètres actifs. En revanche, aucun benchmark indépendant n’a été publié pour Mistral ou Kimi sur le Spark, ce qui laisse un angle mort.

Modèle	Taille	Framework	Débit (tok/s)	Source
Llama 3.1 8B	8B	llama.cpp (prefill)	10 500	LMSYS (oct. 2025) via syskb.com
Gemma 4 26B-A4B	26B (4B actifs)	vLLM + MTP + NVFP4	108	ai-muninn.com (2026)
Qwen3-Next-80B	80B	Atlas	82	ai-muninn.com (été 2026)
GPT-OSS-120B	120B	vLLM/llama.cpp	35-80+	explainx.ai (2026)
Modèle dense 31B	31B	Non précisé	7	ai-muninn.com (2026)
Ant Ling-3.0-Flash 124B-A5B	124B (5B actifs)	Non précisé (estimation)	15-20	forums.developer.nvidia.com (juillet 2026)
DeepSeek V4 Flash 0731 (2× Spark)	284B (13B actifs)	vLLM 0.25+	~30 (défaut), plus avec config	forums.developer.nvidia.com (juillet 2026)
DeepSeek V4 Flash 0731 (1× Spark)	284B (13B actifs)	vLLM/llama.cpp	1 000 prefill, 59 multi-agent	forums.developer.nvidia.com (août 2026)
Qwen3.8-27B	27B	Ollama (UD-Q4_K_XL)	48	blog.openzeka.com (août 2026)
Qwen3.6-27B	27B	NVFP4	163 pic, 136 multi-agent	tokenstead.ai (2026)
Qwen 3.6 35B-A3B	35B (3B actifs)	NVFP4 optimisé	200+	tokenstead.ai (août 2026)
Qwen3.8-Flash-Next	~20B	GGUF + MTP	83-138	banandre.com (sept. 2026)

Verdict : le DGX Spark excelle sur les petits modèles et les MoE récents, mais déçoit sur les modèles denses de taille moyenne. Pour les très gros modèles (100B+), il faut accepter des débits très faibles, sauf à utiliser des formats ultra-compressés comme NVFP4 ou à passer en cluster.

---

Fine-tuning : l’exploit BF16 d’un 35B sur un seul Spark

La grande révélation de 2026 est la démonstration de fine-tuning en pleine précision BF16 d’un modèle de 35 milliards de paramètres sur un seul DGX Spark, sans quantification. C’est un exploit rendu possible par la mémoire unifiée de 128 Go et la pile logicielle NVIDIA. Le guide pratique d’outilsia.fr (mai 2026) confirme que le fine-tuning 70B FP16 sans quantization est la « killer feature » de la machine, à condition de suivre la bonne séquence d’installation.

Le piège du mmap : pourquoi le chargement par défaut fait planter

Le piège le plus vicieux du fine-tuning sur DGX Spark est le chargement par défaut via mmap. Les fichiers de poids sont mappés en mémoire de manière paresseuse, ce qui provoque des OOM (out-of-memory) lorsque le système tente de charger plusieurs fichiers simultanément. La parade est simple mais cruciale : forcer le chargement séquentiel des poids dans la RAM avant de lancer l’entraînement, en désactivant le mmap ou en utilisant un script de pré-chargement. Cette astuce, documentée par ai-muninn et reprise dans le guide DeepWiki (12 août 2026), évite la quantification forcée et permet de conserver la pleine précision BF16.

Les outils : Unsloth, Axolotl et la maturité logicielle

Le fine-tuning sur GB10 (architecture sm121) est désormais bien supporté par les frameworks populaires. Unsloth et Axolotl comblent le vide laissé par Atlas, qui ne propose pas encore de fine-tuning natif. Le guide DeepWiki « Fine-tuning | bidual/awesome-dgx-spark » (12 août 2026) documente les workflows techniques complets : exploitation du GB10 Grace Blackwell Superchip (sm121) et de ses 128 Go de mémoire unifiée, gestion des conteneurs NVIDIA NGC arm64, et intégration avec vLLM pour le serving post-entraînement.

La séquence typique recommandée par la communauté :

1. Préparer l’environnement Docker avec le conteneur NVIDIA NGC arm64 (PyTorch + CUDA 13.0)
2. Charger les poids en mémoire avec un script de pré-chargement (éviter le mmap)
3. Lancer le fine-tuning en BF16 avec Unsloth ou Axolotl
4. Exporter le modèle en NVFP4 ou FP8 pour l’inférence
5. Servir avec vLLM ou TensorRT-LLM

Le tout prend environ 3 heures pour la séquence complète sur un 35B, selon le retour d’expérience d’outilsia.fr.

---

Clusters DGX Spark : 2 nœuds pour 284B, 4 nœuds pour 700B

La mise en cluster est l’autre grand chantier de 2026. NVIDIA a officialisé le support de configurations multi-nœuds, et la communauté a poussé les tests bien au-delà des promesses initiales.

DeepSeek V4 Flash 0731 : le cas d’école du dual Spark

DeepSeek V4 Flash 0731, sorti le 31 juillet 2026, est le modèle qui a tout changé. Avec 284 milliards de paramètres totaux mais seulement 13 milliards actifs par token, il est taillé pour le DGX Spark. Le dépôt officiel deepseek-ai/DeepSeek-V4-Flash-0731 existe sur Hugging Face depuis le 31 juillet 2026, et l’alias API deepseek-v4-flash pointe dessus depuis le 1er août 2026. Les poids publiés pèsent 167 Go (48 fichiers safetensors, relevé du 2 septembre 2026), ce qui nécessite 2 nœuds en Q8 (162 Go) mais tient sur un seul Spark en Q4 (155 Go).

Sur un cluster de 2 DGX Spark (256 Go agrégés, lien QSFP 200 Gb/s), le modèle atteint 30 tok/s en configuration par défaut, mais un petit changement de config (ajustement de l’acceptance) ramène les performances à un niveau bien supérieur (source : forums.developer.nvidia.com, 31 juillet 2026). Le post d’Agent Serving sur 2× DGX Spark (2 août 2026) documente les découvertes sur le KV-cache, le scheduling et l’UMA (Unified Memory Architecture) : les chiffres de decode-share ont été corrigés après re-vérification, mais la conclusion principale tient — le dual Spark est viable pour du serving d’agents.

Sur un seul Spark, le prefill atteint 1 000 tok/s et le serving multi-agent 59 tok/s (source : forums.developer.nvidia.com, 1er août 2026), grâce à un fork CUDA du moteur MLX d’antirez. C’est la preuve que l’optimisation logicielle peut compenser la bande passante limitée.

Le cluster dual pour Qwen3.5-397B-A17B

L’ingénieur Dre Dyson a passé six mois à faire tourner Qwen3.5-397B-A17B (397 milliards de paramètres) sur un cluster de deux DGX Spark. Son retour d’expérience, documenté dans notre précédent dossier, liste les 7 plaies du cluster : câblage réseau, latence NVLink, fragmentation mémoire, gestion du cache KV, équilibrage de charge, stabilité thermique et débogage distribué. Les solutions durement gagnées sont désormais partagées dans la communauté, et le guide DeepWiki (12 août 2026) en fait la synthèse.

4 nœuds pour 700B : les limites de l’exercice

Avec 4 nœuds (512 Go de mémoire agrégée), la communauté rapporte des configurations capables de charger des modèles de 700 milliards de paramètres en Q4. Mais les débits chutent drastiquement : la bande passante inter-nœuds (10GbE théorique à 1,25 Go/s, ou QSFP 200 Gb/s sur les configurations récentes) devient le goulot d’étranglement. Les benchmarks publiés montrent que l’inférence multi-nœuds ne devient intéressante que pour les modèles MoE avec peu de paramètres actifs, comme DeepSeek V4 Flash (13B actifs) ou Qwen3.5-397B-A17B (17B actifs).

---

Quel framework pour quel usage ? vLLM, Atlas, Uzu, llama.cpp, Ollama passés au crible

Le choix du framework est crucial pour exploiter au mieux le GB10. Voici un guide pratique basé sur les retours d’expérience de la communauté en septembre 2026.

vLLM : le choix par défaut

Selon ai-muninn, vLLM est désormais le framework à privilégier par défaut. La fonctionnalité MTP (multi-token prediction) est native et tire parti du NVFP4. C’est le meilleur choix pour les modèles MoE de taille moyenne (20-50B), avec le record de 108 tok/s sur Gemma 4 26B. Attention cependant : vLLM ne tourne pas « out of the box » sur le GB10 — il faut des wheels custom et une compilation adaptée à l’architecture sm121. La version 0.25+ est requise pour DeepSeek V4 Flash 0731, avec les conteneurs NVIDIA NGC arm64.

Atlas : le moteur Rust qui monte

Atlas, le moteur d’inférence écrit en Rust, s’est imposé comme une alternative sérieuse. Il atteint 82 tok/s sur Qwen3-Next-80B, un score remarquable. Son installation en deux minutes et sa simplicité d’utilisation en font un choix attractif, mais le fine-tuning reste le grand absent de son catalogue — Unsloth et Axolotl comblent le vide.

Uzu : le nouveau venu au décodage spéculatif

Uzu a publié son implémentation de décodage spéculatif le 3 septembre 2026, initialement pour Qwen3.6 27B, avec Qwen3.8 27B et Muse Glimmer en préparation. Sur Apple M5, Uzu surpasse MTPLX, mais son intérêt pour le DGX Spark est dans la réduction de la latence — un levier crucial quand la bande passante est limitée.

llama.cpp : la valeur sûre pour les gros modèles

llama.cpp reste le choix pour les très gros modèles en quantification agressive. Le format UD-Q8_K_XL (162 Go pour DeepSeek V4 Flash 0731) est le standard pour une précision quasi-lossless. Le support MTP est arrivé pour Qwen3.8-Flash-Next en GGUF le 2 septembre 2026, avec un speedup de 1,67× (83→138 tok/s).

Ollama : pratique mais bugué

Ollama reste le plus simple pour démarrer, notamment avec Qwen3.8-27B en UD-Q4_K_XL (~21 Go). Mais le bug du split CPU persiste : Ollama répartit la charge entre CPU et GPU de manière sous-optimale, dégradant les performances sur les modèles de taille moyenne. Le contournement manuel est documenté mais pas trivial.

LiteLLM et llama-swap : le duo multiplexeur

Pour les charges de travail variées, LiteLLM et llama-swap transforment les 128 Go en multiplexeur de modèles : plusieurs petits modèles chargés en mémoire, servis à la demande. C’est la solution recommandée