NVIDIA DGX Spark · 9 November 2026Fine-tuning sur NVIDIA DGX Spark : la recette complète, les chiffres vérifiés et les pièges (mise à jour novembre 2026)
Le DGX Spark a été vendu comme une machine d’inférence et d’agents locaux. Mais en 2026, une autre pratique s’y est installée sans tambour ni trompette : le post-entraînement. LoRA, QLoRA, RL, diffusion — les retours terrain se multiplient, et la machine à 3 999 $ (désormais 6 950 $ en 128 Go, 4 999 $ en 64 Go) commence à ressembler à une vraie station de fine-tuning personnel. Voici la recette, les chiffres, et les pièges — avec, cette fois, les mises à jour logicielles d’octobre 2026 et les benchmarks qui tranchent.
La Spark n’est plus seulement une machine d’inférence : anatomie d’un basculement
Il faut se souvenir de ce pour quoi le DGX Spark a été présenté. Le SoC GB10 — Grace-Blackwell, co-développé avec MediaTek — embarque un CPU ARMv9.2 à 20 cœurs et un GPU Blackwell reliés en NVLink-C2C, avec 128 Go de LPDDR5x en mémoire unifiée et une carte ConnectX-7 à 200 Gb/s. La promesse constructeur, relayée par ChannelNews : jusqu’à 1 pétaflop en FP4, l’inférence locale de LLM jusqu’à 200 milliards de paramètres, et — c’est la ligne qui nous intéresse — le fine-tuning local de modèles jusqu’à 70 milliards de paramètres. Deux unités couplées via QSFP étendent l’inférence à 405 milliards de paramètres et la mémoire à 256 Go.
Pendant des mois, cette dernière promesse est restée lettre morte dans les usages. La Spark était une machine à faire tourner des modèles, pas à les transformer. Puis 2026 a changé la donne, et le basculement s’est joué sur trois fronts simultanés.
Le premier, c’est l’outillage. Unsloth — l’une des bibliothèques de fine-tuning les plus populaires — a officiellement porté son support sur la plateforme GB10, avec une image Docker dédiée, Dockerfile_DGX_Spark, disponible sur le dépôt GitHub unslothai/notebooks. Le détail qui compte : les notebooks Unsloth, y compris celui du 120B, fonctionnent sur la Spark en supprimant simplement les cellules d’installation. Lakshmi Ramesh et Barath Anandan, côté NVIDIA, ont accompagné ce portage et la construction de l’image. Le deuxième front, c’est la maturation des recettes : les guides PEFT/TRL, les notebooks « sans code » et les pipelines de post-entraînement sont devenus reproductibles sur la machine — le guide d’Enverge, les playbooks officiels NVIDIA/dgx-spark-playbooks (dont le chapitre PyTorch fine-tuning) et plusieurs dépôts communautaires (waybarrios/dgx-spark-finetune-llm, bhaweshkrsingh-in/dgxsparkfinetune) en témoignent. Le troisième, c’est la demande : à mesure que les modèles ouverts se multiplient, la question « comment j’adapte ce modèle à mon domaine ? » se pose au développeur solo, pas seulement à l’entreprise.
Les retours terrain qui ont marqué ce basculement sont désormais cités en référence : un fine-tuning LoRA de Nemotron 3.5 Lightning pour un classifieur métier, un Dreambooth LoRA sur FLUX.1-dev 12B, et — le plus spectaculaire — un gpt-oss-20b entraîné par RL sur la Spark, présenté à l’OpenAI DevDay, qui apprend à gagner automatiquement à 2048 après 1000 étapes et 4 heures d’entraînement, surpassant l’original.
Reste à séparer le solide du communiqué. Les 70B de fine-tuning et les 200B d’inférence sont des chiffres constructeur. Le guide d’Enverge les recoupe partiellement — il confirme qu’on peut charger un modèle 70B en pleine précision sur les 128 Go, et qu’un LoRA/QLoRA sur 70B+ tient sur un seul GPU sans sharding — mais il s’agit d’une estimation de capacité mémoire, pas d’un run d’entraînement publié avec courbes de loss et débit. Le titre « le DGX Spark fait tourner un modèle de 200 milliards » circule, mais sans transcription exploitable permettant de vérifier le modèle exact, la quantification, ou s’il s’agit d’inférence ou d’entraînement. Il faut donc lire la suite avec cette prudence : ce qui est documenté, ce sont des runs réels sur des modèles de taille moyenne à grande ; ce qui relève du marketing, ce sont les plafonds.
128 Go unifiés : ce que la mémoire partagée change vraiment au fine-tuning
L’argument technique central de la Spark, c’est l’architecture mémoire. Sur une carte graphique classique, la VRAM est un mur : au-delà, le run s’arrête net. Sur le GB10, CPU et GPU partagent un pool LPDDR5x unifié de 128 Go, relié en NVLink-C2C. Il n’y a plus de frontière stricte entre « mémoire GPU » et « mémoire système » — un modèle peut déborder d’un côté ou de l’autre sans provoquer l’OOM brutal qu’on connaît sur une RTX.
Concrètement, cela se traduit par des seuils pratiques que la communauté a observés. Unsloth documente un fine-tuning QLoRA 4 bits de gpt-oss-120b tenant dans environ 68 Go de mémoire unifiée — soit à peu près la moitié du pool total, avec de la marge pour les activations, les optimiseurs et le cache. C’est précisément ce genre de run qui était impossible sur une carte consumer : un 120B en QLoRA sur une RTX 4090, avec ses 24 Go de VRAM, n’existe pas.
Le guide d’Enverge apporte une grille de lecture complémentaire, modèle par modèle, qu’il faut citer avec ses réserves (ce sont des estimations de besoin mémoire, pas des runs publiés) :
| Taille du modèle | Full fine-tuning (FP16) | LoRA | Tient sur Spark ? |
|---|---|---|---|
| 8B | ~45 Go | ~20 Go | Oui (full et LoRA) |
| 13B | ~65 Go | ~30 Go | Oui (full serré, LoRA confortable) |
| 30B | ~120 Go | ~60 Go | Oui (full très serré, LoRA confortable) |
| 70B | ~280 Go | ~140 Go (QLoRA ~70 Go) | Non en full ; oui en QLoRA |
Le chiffre à retenir : un Llama 3.1 8B avec une fenêtre de contexte de 16K demande environ 45 Go en full fine-tuning. Sur une H100 (80 Go), c’est tendu ; sur une Spark (128 Go), il reste environ 83 Go de marge pour de plus gros batchs, des contextes plus longs ou des modèles plus gros. C’est exactement l’argument de vente de la machine — et il est, cette fois, arithmétiquement vérifiable.
La comparaison avec les alternatives est instructive. Un Mac Studio ou une machine Strix Halo jouent aussi la carte de la mémoire unifiée. Mais l’actualité d’octobre 2026 a rebattu les cartes : le Ryzen AI Halo 192 Go est arrivé chez Micro Center à 7 299,99 $, présenté comme le premier desktop compact capable de charger des modèles open weight de 300 milliards de paramètres — mais les benchmarks indépendants cités par TechTimes concluent que le DGX Spark garde l’avantage en vitesse. Le Halo 192 Go charge plus gros, la Spark calcule plus vite : deux philosophies, deux usages. Pour l’entraînement, le GPU Blackwell dédié et le pétaflop FP4 changent la donne sur le débit de calcul matriciel, là où les APU AMD s’appuient sur un GPU intégré Radeon.
Un point de vigilance, en revanche : la « configuration 64 Go » qui a fait couler beaucoup d’encre. NVIDIA a officialisé le 2 octobre 2026 une DGX Spark à 64 Go de mémoire unifiée, en vente depuis le 23 octobre à partir de 4 999 $ — soit, ironie de l’histoire, 1 000 $ de plus que le prix de lancement de la version 128 Go en 2025 (3 999 $), dans un contexte de tension sur la mémoire, et alors que la 128 Go est désormais affichée à 6 950 $. Cette version divise par deux le pool unifié, ce qui rebat les cartes pour le fine-tuning : les runs 120B en QLoRA à 68 Go deviennent impossibles, et il faut redescendre d’un cran dans la taille des modèles de base. La question « que change le 64 Go pour le fine-tuning ? » n’a donc pas de réponse unique : elle dépend entièrement du modèle visé. Côté écosystème, ASUS a de son côté annoncé son Ascent GX10 64 Go (GB10, 1 pétaflop, positionné pour les modèles 30–35B et les agents locaux) — un signe que le segment 64 Go se structure autour du petit et du moyen modèle, pas du 120B.
Du dataset brut à l’adaptateur : la chaîne complète, étape par étape
Voici l’anatomie d’un pipeline LoRA sur Spark, du fichier brut au serveur qui répond.
1. Le dataset. Le format de référence est le JSONL, une ligne par exemple, avec les champs instruction, input, output (ou messages pour un format conversationnel). La règle empirique qui revient partout : 500 à 1 000 exemples de haute qualité suffisent pour un LoRA utile ; au-delà de 10 000 exemples, on commence à justifier un full fine-tuning. Le blog mikihands va jusqu’à affirmer que le dataset détermine 80 % du résultat d’un fine-tuning LoRA — un chiffre non vérifié, mais qui traduit une intuition juste : un adaptateur ne compense jamais des données médiocres.
2. Le chat template et l’alignement du tokenizer. C’est le piège numéro un, et celui qui ne prévient pas. Chaque famille de modèles a son propre format de conversation — balises spéciales, rôles, séparateurs. Si le template utilisé à l’entraînement ne correspond pas exactement à celui utilisé à l’inférence, le modèle apprend un format que le serveur ne lui présentera jamais. Le symptôme est déroutant : la loss descend, l’éval semble correcte, et pourtant le modèle se comporte mal en production. Il faut vérifier explicitement que le tokenizer du modèle de base est bien celui chargé par la bibliothèque, et que le template de chat est appliqué de façon identique des deux côtés.
3. Les bibliothèques. Trois options principales. PEFT (Hugging Face) pour un contrôle fin des adaptateurs ; TRL pour les boucles d’entraînement SFT et RL (DPO, GRPO) ; Unsloth pour les optimisations mémoire et vitesse, avec ses notebooks prêts à l’emploi et son image Docker dédiée à la Spark. Les recettes NVIDIA Build complètent l’écosystème, notamment pour la diffusion, et les playbooks officiels NVIDIA/dgx-spark-playbooks fournissent un chemin PyTorch de référence.
4. Le lancement. Un script type charge le modèle de base en 4 bits (QLoRA), configure un LoraConfig (rang, alpha, dropout, modules cibles), puis lance l’entraînement avec SFTTrainer de TRL ou l’équivalent Unsloth. Les hyperparamètres par défaut raisonnables : rang 16-32, learning rate 2e-4, batch size modeste avec accumulation de gradient.
5. La surveillance. Sur la Spark, il faut suivre la mémoire unifiée pendant les steps, pas seulement au démarrage. Les fuites de cache — activations non libérées, fragmentation — se manifestent par une consommation qui grimpe lentement avant un OOM tardif. Un monitoring régulier permet de repérer la dérive avant la chute.
6. La fusion et le serving. Une fois l’adaptateur entraîné, on le fusionne avec le modèle de base (merge_and_unload), puis on sert le résultat via vLLM ou Ollama sur la même machine. C’est là que la Spark boucle la boucle : entraîner et servir sur le même boîtier, sans transfert de fichiers ni coût cloud.
Un mot sur l’économie du cloud, souvent invoquée : Enverge avance un accès cloud à 0,85 $/h, soit environ 4,7× moins cher à l’heure qu’une H100 louée (~3,99 $/h) pour le même travail. C’est un argument de comparaison à prendre pour ce qu’il est — un tarif d’accès, pas un coût total de possession — mais il rappelle que la Spark se juge aussi sur son coût d’usage, pas seulement sur son prix d’achat.
LoRA, QLoRA, DoRA : le match des trois méthodes sur GB10
Le choix de la méthode dépend d’abord de la taille du modèle de base et de la mémoire disponible.
LoRA entraîne 1 à 5 % des poids — environ 0,4 % pour un adaptateur 13B typique d’une cinquantaine de millions de paramètres. C’est la méthode la plus rapide et la plus simple, mais elle exige de charger le modèle de base en précision raisonnable. Enverge la crédite de 90 à 95 % de la qualité d’un full fine-tuning.
QLoRA combine LoRA avec une quantification 4 bits du modèle de base, l’adaptateur restant entraîné en 16 bits. Le gain est net : environ 50 % de VRAM en moins selon PromptQuorum, 75 % selon Unsloth, au prix d’une perte de qualité d’environ 2 % par rapport à un LoRA complet. C’est la méthode qui rend possibles les gros modèles sur la Spark — le run gpt-oss-120b à 68 Go en est l’illustration.
DoRA (Weight-Decomposed Low-Rank Adaptation) décompose les poids en magnitude et direction pour gagner en expressivité. Sur la Spark, la documentation publique reste mince : on sait que la méthode existe et qu’elle est discutée dans les comparatifs LoRA/QLoRA/DoRA, mais les retours terrain spécifiques au GB10 manquent. C’est un angle mort à assumer, pas à combler par des chiffres inventés.
| Méthode | Principe | Gain mémoire | Perte qualité | Statut sur Spark |
|---|---|---|---|---|
| LoRA | Adaptateurs bas rang, 1–5 % des poids | Référence | 5–10 % vs full (Enverge) | Documenté (Unsloth, PEFT) |
| QLoRA | LoRA + quantisation 4 bits | ~50 % (PromptQuorum) à 75 % (Unsloth) | ~2 % | Documenté (gpt-oss-120b, 68 Go) |
| DoRA | Décomposition magnitude/direction | Non précisé | Non précisé | Peu documenté |
Côté VRAM indicative pour un fine-tuning complet, PromptQuorum donne 28 Go pour un 7B et 52 Go pour un 13B ; en LoRA 16 bits, 16 Go pour un 7B et 30 Go pour un 13B. Enverge, de son côté, table sur ~45 Go (full) et ~20 Go (LoRA) pour un 8B, ~65 Go et ~30 Go pour un 13B, ~120 Go et ~60 Go pour un 30B. Les deux jeux de chiffres ne sont pas contradictoires — ils portent sur des fenêtres de contexte et des configurations différentes — mais ils illustrent la prudence nécessaire : un « besoin mémoire » n’a de sens qu’avec son contexte et sa longueur de séquence. Pour le 70B, les données manquent — et c’est précisément le point sensible : la limite « 70B fine-tuning » annoncée par NVIDIA reste un chiffre constructeur, seulement recoupé par des estimations de capacité, pas par un run indépendant publié.
Rang, alpha, learning rate, séquence : les réglages qui font ou cassent un run
Les hyperparamètres ne sont pas un rituel : ce sont les leviers qui déterminent si un run converge ou gaspille quatre heures de calcul.
Le rang (r). La recommandation par défaut est r=16-32. r=8 est plus petit et plus rapide — utile pour un premier essai ou un dataset simple. r=64 augmente la capacité de l’adaptateur, au prix de la mémoire et du risque de surapprentissage sur un petit dataset. Pour un classifieur métier sur 1 000 exemples, r=16 suffit souvent ; pour capturer un style complexe, monter à 32 ou 64 se justifie.
Le learning rate. Unsloth recommande 2e-4 pour un LoRA/QLoRA standard, et 5e-6 pour l’entraînement par RL (DPO, GRPO). La plage typique va de 2e-4 à 5e-6 selon la méthode. Un learning rate trop élevé sur un petit dataset est la cause la plus fréquente de divergence.
Séquence, batch et accumulation. La longueur de séquence doit couvrir les exemples les plus longs du dataset, sans surdimensionner — chaque token de contexte supplémentaire coûte de la mémoire. Le batch size dépend directement de l’espace disponible ; quand il est trop petit, l’accumulation de gradient simule un batch plus grand en moyennant les gradients sur plusieurs steps.
Les pièges qui ne préviennent pas. L’OOM silencieux — un run qui échoue tardivement après une lente montée de consommation. Les fuites de cache, qui grignotent la mémoire unifiée step après step. Le tokenizer mal aligné, qui produit un modèle qui « a l’air » entraîné mais se comporte mal. Et l’éval qui ment : une loss de validation qui descend ne garantit pas que le modèle fait ce qu’on veut, surtout si le jeu d’évaluation partage des similarités avec l’entraînement.
Ce qu’octobre 2026 a changé côté logiciel (et pourquoi ça compte pour le fine-tuning)
On ne peut plus parler de la Spark sans parler de sa pile logicielle, parce que c’est elle qui a fait basculer la machine de « prometteuse » à « utilisable ». Le 21 octobre 2026, NVIDIA a déployé sa mise à jour logicielle d’octobre 2026 pour DGX Spark, avec de nouvelles fonctionnalités et la promesse que les systèmes partenaires GB10 Grace Blackwell recevront les mêmes mises à jour. C’est un point important pour les acheteurs de machines tierces (Acer, ASUS) : l’écosystème logiciel n’est plus réservé à la marque NVIDIA.
Cette release s’inscrit dans une séquence 2026 qui a aussi touché le firmware — UEFI 1.111.17, EC 3.13.7 — avec son lot de corrections et, parfois, de régressions (une Spark qui ne redémarre plus après un flash, c’est arrivé). La leçon pour le fine-tuning : avant de lancer un run de quatre heures, vérifiez que votre pile est à jour et que le dernier flash n’a rien cassé. Un run qui plante à la 900e étape à cause d’un firmware instable, c’est quatre heures perdues.
Côté inférence — et donc côté serving d’un adaptateur fusionné —, le 27 octobre 2026, NVIDIA a publié trois techniques d’optimisation de l’inférence MoE sur DGX Spark, mesurées sur Ling-3.0-flash (124 milliards de paramètres totaux, 5,1 milliards actifs par token, 42 couches, contexte natif 256K extensible à 1M). Les trois leviers : les kernels Humming MXFP4 pour le calcul des experts routés, la quantification FP8 en ligne de la couche de sortie (LM head), et le décodage spéculatif multi-token (MTP) avec NEXTN. Le gain agrégé annoncé atteint 42,5 % de débit, avec un temps par token de sortie ramené de 27,71 ms à 9,72 ms — mais l’article de NVIDIA lui-même prévient qu’un problème d’intégration peut rendre la configuration combinée plus lente que la baseline. Autrement dit : le chiffre est réel, mais conditionnel à une configuration correcte. Pour le fine-tuning, l’intérêt est indirect mais réel : un modèle MoE fine-tuné puis servi avec ces optimisations coûte moins cher en latence, ce qui rend le cycle « entraîner sur la Spark, servir sur la Spark » plus crédible.
Clusters : quand deux Spark changent l’équation du fine-tuning
Le fine-tuning sur une seule Spark a ses limites — la 64 Go les rend plus visibles encore. Le cluster à deux nœuds, lui, change la donne, mais pas nécessairement là où on l’attend.
Côté mémoire, deux Spark couplées via QSFP portent le pool à 256 Go et l’inférence à 405 milliards de paramètres. Côté débit, les chiffres vérifiés d’un cluster à deux nœuds en tensor parallel (TP=2) avec vLLM et DeepSeek-V4-Flash en FP8 sont parlants : environ 41 tokens/s en single-stream, ~350 tokens/s agrégés à une concurrence de 32, et un prefill d’environ 1 785 tokens/s. À titre de comparaison, une seule Spark sur le même modèle en IQ2_XXS (antirez ds4) tourne autour de 14 tokens/s en single-stream avec un prefill de 410 t/s — et jusqu’à 67 tokens/s sur un 35B-A3B en GGUF via llama.cpp.
Pour le fine-tuning spécifiquement, le cluster apporte deux choses : la possibilité de charger des modèles de base plus gros (au-delà de ce que permet une seule machine en QLoRA), et le parallélisme de données pour accélérer l’entraînement sur un dataset volumineux. Mais le coût est réel : deux Spark 128 Go à 6 950 $ pièce, c’est près de 14 000 $ — sans compter le câblage QSFP et la complexité opérationnelle. Le pari de Dre Dyson, faire tourner Qwen3.5-397B-A17B sur deux Spark, illustre à la fois la faisabilité et le prix : un projet à 12 000 $ pour un résultat qui reste, en débit, en dessous de ce qu’offrirait un accélérateur unique de datacenter. Le cluster Spark n’est pas une alternative à un H100 ; c’est une alternative à « pas de machine du tout », ou à une facture cloud qui s’accumule.
Ce qu’il faut retenir
La Spark de 2026 n’est plus la machine de 2025. La pile logicielle d’octobre 2026 a mûri, les recettes de fine-tuning sont reproductibles, et les retours terrain — du classifieur Nemotron au gpt-oss-20b entraîné par RL — prouvent que le post-entraînement local y est une pratique réelle, pas une démo. Mais il faut garder la tête froide sur trois points : les plafonds constructeur (70B en fine-tuning, 200B en inférence) restent des estimations de capacité, pas des runs indépendants publiés ; la version 64 Go à 4 999 $ redéfinit le terrain de jeu vers le modèle moyen ; et le cluster à deux nœuds, s’il élargit l’horizon, coûte désormais près de 14 000 $ en 128 Go. La bonne question n’est donc pas « jusqu’où la Spark peut-elle aller ? » mais « quel modèle, pour quel usage, à quel coût ? » — et c’est précisément la question à laquelle ce guide, chiffres en main, permet de répondre.
Sources
- ChannelNews — NVIDIA lance DGX Spark, une station de travail pour l’IA
- NVIDIA Developer Forums — DGX Spark Software Updates, October 2026 Release (21 octobre 2026)
- NVIDIA Technical Blog — 3 Ways to Boost MoE Inference on NVIDIA DGX Spark (27 octobre 2026)
- Enverge — How to Fine-Tune an LLM on NVIDIA DGX Spark
- NVIDIA/dgx-spark-playbooks — PyTorch Fine-tuning (DeepWiki)
- waybarrios/dgx-spark-finetune-llm — LLM fine-tuning with LoRA (GitHub)
- bhaweshkrsingh-in/dgxsparkfinetune — DGX Spark Fine-tuning (GitHub)
- TechTimes — AMD Ryzen AI Halo 192GB Loads Models No Rival Can: DGX Spark Still Wins on Speed (14 octobre 2026)
- ASUS — Ascent GX10 64GB: Compact Agentic AI Supercomputer (5 octobre 2026)
- ServeTheHome — NVIDIA Updates Rubin GPU Specs as First Production Hardware Arrives (1er novembre 2026)
- Blog NeticsLabs — Three MoE Inference Optimizations on DGX Spark (31 octobre 2026)
- Blockchain.news — NVIDIA details edge AI workflow for DGX Spark and TensorRT Edge-LLM (30 octobre 2026)
- Fellow.news — Trois leviers pour accélérer l’inférence MoE sur NVIDIA DGX Spark (27 octobre 2026)
Article recherché et rédigé automatiquement · Magazine Electrosens