---

DGX Spark : la machine qui se met à jour comme un service

Il y a une différence de nature entre un serveur d’entreprise classique et une DGX Spark. Le premier vit sur un cycle de mise à jour trimestriel, parfois annuel, souvent gelé pendant des années par un service informatique prudent. La seconde a été conçue par NVIDIA comme une plateforme à cadence soutenue : des releases logicielles mensuelles, documentées, annoncées sur le forum développeur NVIDIA et consignées dans les release notes officielles. Juin 2026, juillet 2026 : deux vagues documentées, chacune avec son fil d’annonce, ses correctifs et ses surprises.

Pour un possesseur de GB10 — la puce Grace Blackwell qui équipe la machine — cela change tout. Vous n’achetez plus un boîtier figé, vous adoptez une plateforme qui évolue sous vos pieds. Chaque mois, un lot de correctifs peut modifier la gestion mémoire de votre architecture unifiée, la façon dont votre système d’exploitation se déploie, ou même la manière dont votre machine négocie l’alimentation via USB Power Delivery. C’est une promesse de fraîcheur, mais aussi une source de fragilité si l’on n’y met pas de méthode.

Et le vrai sujet, celui qui a fait couler le plus d’encre sur les forums, n’est pas CUDA. C’est le firmware. Parce qu’un noyau Linux se remplace, un pilote se réinstalle, un conteneur NGC se retélécharge — mais un firmware UEFI ou un microcontrôleur embarqué (EC), quand il réserve des surprises, ne se contente pas de planter : il peut rendre une machine difficile à démarrer, ou faire disparaître une configuration réseau. Plusieurs retours de terrain, dont celui de Petronella Tech sur huit unités GB10, documentent précisément ce type de friction.

Cet article prend le problème par le concret. Nous allons décomposer une vague type, décrypter les releases de juin et juillet 2026, apprendre à lire une release note sans se tromper, puis poser une méthode de mise à jour reproductible — sauvegardes, ordre des opérations, rollback, vérification post-update — applicable sur une machine en production comme sur un cluster multi-Spark.

---

Anatomie d’une vague : ce qui bouge vraiment entre noyau, CUDA et firmware

Une release DGX Spark n’est pas un bloc monolithique. C’est un empilement de couches qui ne se mettent pas à jour au même rythme. Voici l’état des versions actuellement documenté par NVIDIA pour la Founders Edition :

Couche	Composant	Version actuelle
OS	DGX OS	7.5.0
Noyau	Canonical Kernel	6.17
Pilote GPU	NVIDIA GPU Driver	580.159.03
Calcul	CUDA Toolkit	13.0.2
Firmware	UEFI	1.110.13
Firmware	Embedded Controller (EC)	3.5.8
Firmware	USB Power Delivery (USB PD)	0.5.22
Firmware	TPM	7.516.1
Firmware	SoC (GB10)	2.155.11

Ce tableau mérite qu’on s’y arrête, parce qu’il révèle une réalité que beaucoup d’utilisateurs découvrent trop tard : sur neuf briques listées, cinq sont du firmware. Autrement dit, plus de la moitié de ce qui constitue « votre version actuelle » n’est pas remplaçable par un simple apt upgrade. Le noyau 6.17, le pilote 580.159.03 et CUDA 13.0.2 vivent dans l’espace logiciel classique — on les met à jour, on les versionne, on peut revenir en arrière. L’UEFI 1.110.13, l’EC 3.5.8, l’USB PD 0.5.22, le TPM 7.516.1 et le SoC 2.155.11 vivent dans des puces. Leur mise à jour est plus rare, plus risquée, et souvent irréversible sans procédure de récupération.

C’est là que se joue la vraie difficulté. Un utilisateur qui lit « version actuelle : 7.5.0 » peut croire qu’il suffit de faire évoluer DGX OS pour être à jour. En réalité, il peut très bien avoir un DGX OS 7.5.0 avec un firmware UEFI plus ancien, parce que les firmwares sont distribués séparément, parfois via le BIOS, parfois via une image de récupération. La documentation NVIDIA distingue d’ailleurs explicitement la mise à jour OS et composants dans son guide dédié.

Checklist — inventorier avant de toucher à quoi que ce soit :

1. Relever la version DGX OS (cat /etc/os-release ou l’équivalent DGX).
2. Relever le noyau actif (uname -r) et vérifier qu’il correspond bien à 6.17.
3. Relever la version du pilote GPU (nvidia-smi).
4. Relever la version CUDA (nvcc --version).
5. Relever les versions firmware (UEFI, EC, USB PD, TPM, SoC) — soit via le BIOS, soit via les outils de gestion fournis.
6. Consigner tout cela dans un fichier horodaté, avec la date de la dernière mise à jour.

Ce dernier point n’est pas de la maniaquerie : c’est ce qui vous permettra, en cas d’incident, de savoir exactement d’où vous venez.

---

Juin 2026 : l’OOBE, les OTA et le playbook NemoClaw

La release de juin 2026, annoncée sur le forum développeur, a un parfum de mise au point opérationnelle. Trois changements ressortent des notes officielles.

D’abord, l’amélioration de l’OOBE — l’expérience de premier démarrage. NVIDIA a travaillé à rendre le setup initial plus rapide. C’est un détail pour un utilisateur isolé, mais un enjeu réel pour qui déploie une flotte : chaque minute gagnée sur le premier boot se multiplie par le nombre de machines.

Ensuite, et c’est le point le plus contre-intuitif : les mises à jour OTA (over-the-air) ne sont plus installées par défaut lors du setup initial. NVIDIA a choisi de ne pas pousser automatiquement les mises à jour au premier démarrage. Pourquoi ? Parce qu’une machine fraîchement déballée est dans un état connu, testé, validé en usine. Y injecter une vague de correctifs avant même que l’utilisateur ait pu vérifier le fonctionnement de base, c’est prendre le risque de mélanger deux sources d’instabilité : le matériel neuf et le logiciel neuf.

Ce choix a une conséquence pratique directe : au premier boot, vous décidez. Accepter les OTA tout de suite, c’est partir sur la version la plus récente mais renoncer à un état de référence. Les refuser, c’est garder une base stable et maîtriser le moment de la bascule. Pour un déploiement en flotte, la seconde option est presque toujours la bonne : on valide une machine pilote, on documente, puis on propage.

Troisième élément : la mise en avant du playbook NemoClaw pour configurer un agent IA local sandboxé. C’est un signal de positionnement. NVIDIA ne vend plus seulement du calcul brut, elle vend un scénario d’usage : faire tourner un agent local, isolé, sur sa propre machine. Le sandboxing n’est pas un détail — c’est la condition pour qu’un agent qui exécute du code ne compromette pas l’hôte.

Procédure — premier démarrage reproductible :

1. Booter sur l’état d’usine, sans accepter les OTA.
2. Vérifier le fonctionnement de base : réseau, stockage, GPU (nvidia-smi), accès aux conteneurs.
3. Consigner l’inventaire des versions (voir checklist précédente).
4. Si déploiement en flotte : appliquer la même séquence sur une machine pilote, valider, puis reproduire.
5. Décider ensuite, en connaissance de cause, d’appliquer ou non les OTA.

---

Juillet 2026 : OOM, mémoire d’affichage et cloud-init

La release de juillet 2026 est plus dense techniquement. Elle touche à l’un des points les plus sensibles de l’architecture GB10 : la mémoire unifiée.

Premier changement : l’amélioration de la gestion mémoire, et notamment du comportement en cas d’OOM (Out Of Memory). Sur une machine à mémoire unifiée — où CPU et GPU partagent le même pool — la frontière entre « mémoire système » et « mémoire GPU » est floue. Un modèle qui gonfle, un cache KV qui explose, et c’est toute la machine qui vacille, pas seulement le processus d’inférence. Une meilleure gestion de l’OOM, c’est moins de crashs brutaux et un comportement plus prévisible quand on approche de la limite.

Deuxième changement, très concret : la mémoire réservée à l’affichage devient ajustable. Par défaut, 2 Go sont réservés ; via le BIOS, on peut passer à 4 Go. Pourquoi est-ce important ? Parce que ces gigaoctets sont pris sur le pool unifié. Sur une machine qui fait tourner de l’inférence LLM, chaque gigaoctet compte : c’est de la fenêtre de contexte, du cache KV, de la marge avant l’OOM. Mais à l’inverse, si vous pilotez plusieurs écrans haute résolution — et la release corrige justement une instabilité au hot-plug d’écrans — 2 Go peuvent être insuffisants.

Le bon réglage dépend donc entièrement de l’usage. Une machine serveur, sans écran, en inférence pure : rester à 2 Go, voire chercher à minimiser. Un poste de développement avec deux écrans 4K branchés à chaud : 4 Go est plus sûr. C’est un arbitrage, pas une vérité universelle.

Troisième changement : l’extension de cloud-init, qui supporte désormais DHCP, HTTP et TFTP en plus de l’USB direct. C’est une brique de gestion d’entreprise. Concrètement, cela signifie qu’on peut provisionner une Spark via le réseau, sans clé USB, en récupérant sa configuration par DHCP, HTTP ou TFTP. Pour un déploiement de plusieurs machines, c’est la différence entre brancher une clé sur chaque boîtier et laisser le réseau faire le travail.

Quatrième changement : la personnalisation de l’image de récupération FastOS. Nous y reviendrons, car c’est précisément l’outil qui rend le rollback possible.

Procédure — quand basculer la mémoire d’affichage à 4 Go :

1. Évaluer le nombre et la résolution des écrans réellement utilisés.
2. Si un seul écran, ou aucun (usage serveur) : rester à 2 Go par défaut, maximiser la mémoire disponible pour l’inférence.
3. Si plusieurs écrans haute résolution ou hot-plug fréquent : passer à 4 Go via le BIOS.
4. Après bascule, vérifier la mémoire réellement disponible pour le GPU et relancer un test d’inférence pour confirmer l’absence de régression.
5. Documenter le choix dans l’inventaire de la machine.

---

Lire une release note sans se tromper : la grille de tri

Une release note NVIDIA n’est pas un roman : c’est une liste. Et dans cette liste, tout n’a pas la même urgence. Le piège classique consiste à traiter un correctif cosmétique et une mise à jour de sécurité avec la même priorité — ou l’inverse.

La première distinction à faire est celle de la nature du changement. Quatre catégories se dégagent des releases 2026 :

• Sécurité : à appliquer vite, sans attendre. Un firmware TPM ou une brique réseau concernée par une faille ne se négocie pas.
• Correctif de bug : à appliquer si vous êtes concerné. L’instabilité au hot-plug d’écrans corrigée en juillet 2026 ne vous concerne pas si vous n’avez jamais branché d’écran à chaud.
• Optimisation de performance : à évaluer. Une meilleure gestion de l’OOM change le comportement en charge, pas la compatibilité.
• Nouvelle fonctionnalité : à tester en pilote avant de généraliser. cloud-init étendu à DHCP/HTTP/TFTP ne sert à rien si vous ne provisionnez pas par le réseau.

La seconde distinction, plus subtile, est celle du périmètre. Les notes NVIDIA précisent explicitement que les versions de release ne s’appliquent qu’à la DGX Spark Founders Edition. Les systèmes partenaires basés sur GB10 — et ils sont nombreux en 2026, d’Acer à ASUS en passant par les mini-PC RTX Spark — peuvent ne pas recevoir les mises à jour en même temps. Autrement dit : lire « disponible » dans une release note ne garantit pas que votre machine y a droit au même moment. C’est une source de confusion majeure pour qui gère un parc hétérogène.

Checklist — les cinq questions avant d’appliquer une mise à jour :

1. Nature : sécurité, bug, perf ou fonctionnalité ?
2. Périmètre : Founders Edition ou système partenaire ? Ma machine est-elle concernée ?
3. Impact : est-ce que cela touche une brique que j’utilise réellement (affichage, réseau, mémoire) ?
4. Réversibilité : puis-je revenir en arrière si ça se passe mal ?
5. Moment : ai-je une fenêtre de maintenance, une sauvegarde récente, et personne qui dépend de cette machine dans l’heure qui suit ?

Si l’une de ces cinq réponses est floue, on attend.

---

Quand la mise à jour casse : firmware, stockage, réseau et les surprises du terrain

Il faut le dire sans détour : certaines mises à jour ont cassé des configurations. Le cas le mieux documenté concerne le firmware. Le retour d’expérience de Petronella Tech sur huit unités GB10 montre que la mise à jour firmware n’est pas une formalité : sur un parc de machines, le comportement peut varier, et il faut prévoir du temps, une alimentation stable, et une procédure de secours.

Le point de vigilance numéro un est donc le firmware. Contrairement à un paquet logiciel, un firmware interrompu en cours d’écriture peut laisser une machine dans un état difficile à récupérer. La règle est simple : jamais de mise à jour firmware sur batterie, jamais sans sauvegarde préalable, jamais sur plusieurs machines simultanément si l’on n’a pas validé sur une seule.

Le point numéro deux est l’affichage. L’instabilité au hot-plug d’écrans n’a été corrigée qu’en juillet 2026 — ce qui signifie que pendant un temps, brancher un écran à chaud pouvait déstabiliser le système. Si vous avez vécu ce genre de comportement avant juillet, ce n’était pas votre imagination.

Le point numéro trois concerne le stockage et le réseau. Les sources disponibles ne documentent pas de mise à jour firmware BMC, microcode, stockage ou réseau spécifique pour la DGX Spark. Il faut donc rester prudent : sur ces briques, l’absence d’information n’est pas une garantie d’absence de changement. C’est précisément le genre de zone d’ombre qu’une release note ne comble pas.

Enfin, il faut distinguer les cas documentés des rumeurs de forum. Un fil de discussion qui rapporte un plantage n’est pas une preuve de régression généralisée. À l’inverse, un correctif listé dans une release note officielle est un fait. La discipline consiste à ne jamais traiter les deux au même niveau.

Procédure — rollback sans perdre ses données :

1. Avant : sauvegarder les données utilisateur, les configurations réseau, les modèles et les jeux de données de fine-tuning sur un support externe.
2. Avant : vérifier que l’image FastOS recovery est disponible et à jour — c’est elle qui permet de revenir à un état fonctionnel.
3. Avant : noter l’inventaire complet des versions (OS, noyau, pilote, CUDA, firmwares).
4. Pendant : ne jamais interrompre une écriture firmware.
5. Après un échec : restaurer via FastOS recovery, puis réappliquer les données sauvegardées.
6. Après un succès : comparer l’inventaire post-update à l’inventaire pré-update pour confirmer que tout a bien basculé.

---

Suivre le rythme mensuel ou rester sur une version stable : l’arbitrage

Toutes les machines n’ont pas vocation à suivre chaque vague. La bonne stratégie dépend du profil d’usage.

Stratégie	Stabilité	Sécurité	Support	Compatibilité fine-tuning / cluster
Cycle mensuel officiel	Plus faible (chaque vague apporte son lot)	Maximale (correctifs rapides)	Officielle	À revalider à chaque vague
Version stable conservée	Élevée	Dépend des correctifs de sécurité appliqués	Officielle	Stable tant qu’on ne bouge pas
Conteneurs NGC figés	Élevée sur la pile applicative	Dépend de l’hôte	Officielle (NGC)	Bonne, si l’hôte reste cohérent
Stacks tierces	Variable	Variable	Communautaire	À valider au cas par cas

Le cycle mensuel officiel est le bon choix pour un développeur qui explore, teste des modèles récents, a besoin des derniers correctifs. Il est en revanche risqué pour une machine de production qui sert des jobs de fine-tuning en continu : chaque vague est une variable.

Conserver une version stable plus longtemps est défendable, à condition de ne pas négliger la sécurité. Une machine figée sur une version ancienne accumule les vulnérabilités non corrigées.

Les conteneurs NGC figés offrent un compromis élégant : on gèle la pile applicative — CUDA, bibliothèques, frameworks — tout en laissant l’hôte évoluer prudemment. C’est souvent la meilleure approche pour un cluster.

Arbre de décision rapide :

• Dev / exploration : suivre le cycle mensuel, sur une machine dédiée, jamais la machine de production.
• Prod mono-machine : version stable, correctifs de sécurité appliqués, fonctionnalités testées en pilote.
• Cluster multi-Spark : conteneurs NGC figés + hôte mis à jour nœud par nœud, avec validation entre chaque.

---

Mettre à jour un cluster de DGX Spark sans tout casser

Un cluster change la nature du problème. Sur une machine seule, une mise à jour ratée coûte du temps. Sur un cluster, une mise à jour ratée peut casser la cohérence des versions entre nœuds — et un job de fine-tuning distribué qui tourne sur des nœuds désynchronisés ne produit pas des résultats faux : il plante.

La règle d’or est simple : jamais tous les nœuds en même temps. On met à jour un nœud, on vérifie, on passe au suivant. Et avant de lancer quoi que ce soit, on vérifie la cohérence des versions entre machines — un nœud en DGX OS 7.5.0 et un autre en version antérieure, c’est une source d’incompatibilités silencieuses.

Procédure pas à pas — cluster en production :

1. Pré-update : sauvegarder les données et configurations de chaque nœud ; vérifier que les conteneurs NGC partagés sont bien versionnés et accessibles ; suspendre les jobs de fine-tuning distribués.
2. Inventaire : relever les versions de tous les nœuds et identifier les écarts.
3. Pilote : mettre à jour un seul nœud, valider le fonctionnement (réseau, GPU, accès aux conteneurs, test d’inférence).
4. Propagation : mettre à jour les nœuds restants un par un, en vérifiant après chacun.
5. Cohérence : comparer les inventaires de tous les nœuds — ils doivent être identiques.
6. Post-update : relancer un job de fine-tuning de test, vérifier les débits et la stabilité avant de réouvrir la production.
7. Conteneurs : si la pile NGC est figée, vérifier qu’elle fonctionne toujours sur l’hôte mis à jour.

Le point de contrôle le plus souvent oublié est le cinquième. On met à jour, tout a l’air de marcher, et l’on ne remarque qu’un mois plus tard qu’un nœud est resté en arrière.

---

Ce que le calendrier 2026 annonce pour la suite

Il faut être honnête sur les limites de ce que l’on sait. Le calendrier officiel complet de 2026 n’est pas documenté : seules les releases de juin et juillet 2026 sont établies par les sources. Les autres mois ne sont pas mentionnés. Et les versions listées — DGX OS 7.5.0, pilote 580.159.03, CUDA 13.0.2, noyau 6.17, UEFI 1.110.13, EC 3.5.8, USB PD 0.5.22, TPM 7.516.1, SoC 2.155.11 — sont les versions actuelles, pas nécessairement celles introduites par chaque release. C’est une nuance capitale : une version peut avoir été introduite en mai et simplement figurer dans le tableau de juillet.

Autre zone d’ombre : le cycle de support de DGX OS. Aucune information disponible ne précise la durée de support ni la date de fin de vie des versions. Pour une machine de production, c’est une donnée manquante qui complique la planification à long terme.

Ce que l’on peut dire, en revanche, c’est que la cadence mensuelle impose d’acquérir des réflexes de gestion de flotte. Inventorier, versionner, sauvegarder, tester en pilote, propager nœud par nœud : ce sont les gestes qu’on applique à des serveurs, et qu’il faut désormais appliquer à des Sparks. La différence, c’est l’échelle — et le fait que le firmware, sur cette plateforme, est devenu un composant de plein droit, avec ses risques propres.

Pour la suite, un possesseur de GB10 doit surveiller trois choses dans les prochaines vagues : l’évolution du firmware (UEFI, EC, SoC), les changements touchant la mémoire unifiée — puisque c’est là que se joue la frontière entre stabilité et OOM — et le rythme réel des releases, pour vérifier si la cadence mensuelle se maintient ou si elle s’assouplit. Ce dernier point n’est pas anodin : une plateforme qui promet du mensuel et livre du trimestriel change complètement la stratégie de maintenance.

La DGX Spark est devenue, en 2026, une machine qu’on administre. C’est une bonne nouvelle — à condition d’accepter d’en faire le travail.

---

Sources

• DGX Spark Software Updates – July 2026 Release (forum développeur NVIDIA)
• DGX Spark Software Updates – June 2026 Release (forum développeur NVIDIA)
• DGX Spark Release Notes — DGX Spark User Guide (NVIDIA Documentation Hub)
• OS and Component Update Guide — DGX Spark User Guide (NVIDIA Documentation Hub)
• DGX Spark Firmware Update: What We Learned on 8 GB10 Units (Petronella Tech)
• DGX Spark Release Notes Digest — NVIDIA DGX Spark Agent Wikis
• NVIDIA DGX Spark 64GB Launched and Big 128GB GB10 Price Increases (ServeTheHome)
• NVIDIA Announces DGX Spark 64GB (MarkTechPost)