NVIDIA DGX Spark · 7 November 2026

Firmware DGX Spark : ce que 8 GB10 nous ont appris sur la couche que NVIDIA ne documente pas

On met à jour CUDA, on surveille les release notes, on compare les tokens/s — et puis un jour une Spark ne redémarre plus après un flash, et l’on découvre qu’on ne sait presque rien de la couche qui décide si la machine tient debout. Retour de terrain sur huit unités GB10, trois vagues de releases 2026, et un protocole pour ne pas transformer une mise à jour en après-midi perdu.

Le jour où la Spark a cessé de démarrer (et pourquoi personne n’en parle)

Il y a une scène que tout possesseur de DGX Spark redoute sans vraiment la nommer. Elle commence par une commande anodine, se poursuit par un redémarrage, et se termine sur un écran noir. Pas de noyau qui panique, pas de message d’erreur lisible : juste une LED de diagnostic qui clignote dans un code que personne n’a documenté publiquement, et un cluster qui, soudain, ne compte plus qu’un nœud de moins.

Le retour d’expérience compilé par Petronella Technology Group sur huit unités GB10 raconte exactement cela : une flotte de Sparks, des mises à jour firmware appliquées avec la meilleure volonté du monde, et des comportements que rien dans la documentation officielle n’avait anticipés. Il faut être clair d’emblée sur ce que l’on peut affirmer et ce que l’on ne peut pas : le contenu détaillé de ce retour de terrain n’est pas intégralement accessible, et aucune source tierce indépendante ne vient corroborer les chiffres précis qu’il contiendrait. Ce que l’on sait de source sûre, en revanche, c’est que la couche firmware de la Spark existe, qu’elle est versionnée, qu’elle est mise à jour — et qu’elle est documentée à un niveau de détail sans commune mesure avec celui dont bénéficie CUDA.

C’est le paradoxe central de cette machine. NVIDIA publie, pour le DGX Spark, des release notes qui listent avec une précision chirurgicale les versions de DGX OS, de driver GPU, de CUDA, de TensorRT, de noyau. On y lit noir sur blanc : DGX OS 7.6.0, driver 580.178.04, CUDA 13.0.3, TensorRT 10.14.1, noyau Canonical 7.0.0-1019. Et, à côté de ces numéros que tout le monde cite, une poignée d’autres qui passent inaperçus : UEFI 1.111.17, EC 3.13.7, USB PD 0.5.25, TPM 7.516.1, SoC 2.158.15. Ces cinq-là, c’est la pile firmware. C’est-à-dire, littéralement, ce qui se passe avant que le noyau ne prenne la main.

La question que pose cet article n’est donc pas « faut-il mettre à jour sa Spark » — la réponse est oui, évidemment, pour les correctifs de sécurité et la compatibilité noyau. La question est : que met-on réellement à jour quand on flashe une Spark, et pourquoi cette couche est-elle le point aveugle de la machine ? Pour y répondre, on dispose de trois matériaux : les numéros de version publiés par NVIDIA, la release d’octobre 2026 et son fil de discussion sur les forums développeurs, et le retour d’expérience des huit unités GB10. C’est mince. C’est précisément le sujet.

UEFI 1.111.17, EC 3.13.7 : anatomie d’une pile firmware que NVIDIA ne dessine pas

Commençons par cartographier ce dont on parle. Une DGX Spark, comme tout système GB10, empile plusieurs firmwares distincts, chacun avec son propre cycle de vie :

• L’UEFI (ici 1.111.17) : le micrologiciel de démarrage, celui qui initialise le matériel, entraîne la mémoire et passe la main au bootloader. C’est le BIOS moderne.
• L’Embedded Controller (EC 3.13.7) : le microcontrôleur qui gère l’alimentation, la thermal, les boutons, les LED. Sur un mini-PC, c’est lui qui décide si la machine accepte de s’allumer.
• Le microcode SoC (2.158.15) : les correctifs matériels du GB10 Grace Blackwell lui-même, appliqués au silicium au démarrage.
• Le firmware USB PD (0.5.25) : la négociation d’alimentation via USB-C. Sur une machine qui peut se nourrir d’un bloc externe, ce n’est pas un détail.
• Le TPM (7.516.1) : le module de plateforme de confiance, qui conditionne le chiffrement disque et l’attestation.

Ce que ces numéros révèlent, c’est l’existence de la pile. Ce qu’ils cachent, c’est qui fournit quoi. NVIDIA ne le dit pas. On peut raisonner par analogie : les UEFI de PC sont historiquement l’œuvre d’AMI ou d’Insyde, personnalisés par l’ODM qui assemble la carte. Pour un système Founders Edition comme la Spark, c’est NVIDIA qui porte la responsabilité de bout en bout — mais sur les systèmes partenaires GB10 (ASUS Ascent GX10, Acer, etc.), la chaîne passe par l’ODM, avec les délais et les priorités que cela implique.

Cette opacité n’est pas un accident. C’est une conséquence directe du modèle économique de la plateforme. NVIDIA précise d’ailleurs explicitement que les versions listées dans ses release notes ne s’appliquent qu’à la DGX Spark Founders Edition, et que les systèmes partenaires basés sur GB10 « peuvent ne pas recevoir les mises à jour en même temps ». Traduction : deux machines au même silicium, achetées le même mois, peuvent tourner sur deux piles firmware différentes. Pour un cluster, c’est une variable cachée de première importance — on y reviendra.

Comparez un instant avec la transparence CUDA. Pour un driver, vous avez des release notes détaillées, des known issues, des numéros de build, des canaux. Pour l’UEFI, vous avez un numéro dans un tableau. C’est tout. La couche qui décide si la machine démarre est celle sur laquelle on a le moins d’informations.

Juin, juillet, octobre : ce que les trois releases 2026 ont vraiment changé (et ce qu’elles ont cassé)

La chronologie documentée des releases firmware 2026 est trouée, et c’est en soi une information. On dispose d’un fil officiel pour la release de juin 2026, d’un autre pour octobre, et — c’est le problème — de très peu de chose d’exploitable sur ce qui a réellement changé entre les deux, notamment pour juillet. Les numéros de version antérieurs à UEFI 1.111.17 et EC 3.13.7 ne sont pas publics dans notre corpus. Impossible, donc, de faire un diff propre entre juin, juillet et octobre. C’est exactement le genre de lacune qui transforme une mise à jour en pari.

Ce que la release d’octobre 2026 expose, en revanche, est documenté noir sur blanc. La note officielle liste notamment :

Le point le plus intéressant pour notre propos est Dynamic Display Reserved Memory. Derrière ce nom barbare se cache une option UEFI qui réserve une portion de la mémoire unifiée pour l’affichage, avec un carveout minimum de 512 Mo lorsqu’aucun écran n’est connecté. Sur une machine dont toute la valeur tient à la quantité de mémoire unifiée disponible pour les modèles, c’est loin d’être cosmétique : c’est un paramètre qui touche directement à ce que vous pouvez charger. Et c’est une option UEFI — donc du firmware, pas du driver.

Voilà comment distinguer le correctif cosmétique du changement de socle. Un Wi-Fi Assistant dans le Dashboard, c’est cosmétique. Un carveout mémoire paramétrable en UEFI, c’est structurel. Un passage de noyau 6.17 à 7.0, c’est structurel aussi — et c’est précisément le genre de saut qui révèle les fragilités d’une pile firmware, parce que les modules DKMS doivent suivre. Le correctif DKMS d’octobre (échecs de build après installation via nvidia-installer) est d’ailleurs la preuve que la release précédente avait laissé des plumes.

Ce que la note d’octobre ne dit pas, en revanche, est tout aussi instructif : rien sur les interactions entre mémoire unifiée, carveout et stabilité en cluster. Rien sur ce que le saut de noyau implique pour les firmwares EC et PCIe. Rien, surtout, sur le décalage Founders Edition vs partenaires, qui reste la variable cachée de toute flotte hétérogène.

Ce qui se passe vraiment pendant le flash : séquencement, durées, et le moment où tout peut basculer

Reconstituons le déroulé. Une mise à jour firmware sur GB10 n’est pas un événement atomique : c’est une séquence. L’ordre logique est UEFI → EC → microcode SoC → firmware PCIe, chaque étage devant être cohérent avec le précédent pour que la machine redémarre dans un état valide. L’UEFI initialise le matériel ; l’EC doit accepter de rendre la main ; le microcode corrige le silicium ; le firmware PCIe négocie les liens.

C’est dans cet enchaînement que se situent les fenêtres de risque. Un EC qui ne se resynchronise pas après un flash UEFI, et la machine ne s’allume plus — ou s’allume dans un état dégradé. Un firmware PCIe qui négocie mal après flash, et c’est le lien entre le GB10 et le GPU Blackwell qui se retrouve en Gen inférieure, avec un impact direct sur les débits. Sur une Spark unique, c’est gênant. Sur un cluster, c’est un nœud qui décroche.

Un point mérite d’être souligné avec prudence : les durées par phase ne sont documentées nulle part. On ne sait pas officiellement combien de temps dure un flash UEFI sur GB10, ni combien de temps l’EC met à se resynchroniser. C’est en soi un risque opérationnel : sans référence de durée, impossible de distinguer un flash lent d’un flash bloqué, et donc de savoir quand couper l’alimentation — ou surtout quand ne pas la couper.

Sur les scénarios de brick observés, il faut être honnête : la prémisse des « 8 unités » n’est corroborée par aucune source indépendante dans notre corpus, et le détail des incidents n’est pas accessible. Ce que l’on peut affirmer raisonnablement, c’est que la combinaison (a) d’une pile firmware multi-étages, (b) d’une absence de documentation des durées et (c) d’un carveout mémoire paramétrable en UEFI constitue un terrain propice aux mauvaises surprises. Ce que l’on ne peut pas affirmer, c’est le nombre exact de bricks, leur cause précise, ou le taux d’échec. Prudence, donc — mais vigilance.

Rollback, recovery, jumper : la boîte à outils réelle (et ses limites)

C’est ici que le bât blesse le plus. Sur un serveur HGX ou GB200, la procédure de recovery firmware est documentée, souvent avec redondance A/B, accès BMC, et parfois jumper physique. Sur un mini-PC Strix Halo, les communautés ont depuis longtemps documenté les chemins de récupération, parce que les utilisateurs les ont pratiqués et partagés.

Sur la DGX Spark, la documentation publique du rollback est, à notre connaissance, inexistante. On ne sait pas officiellement si les partitions UEFI sont en A/B, si un mode recovery existe, s’il y a un jumper, ni quelle est la procédure de reflash EC en cas d’échec. Le guide de mise à jour OS et composants existe et couvre la procédure de mise à jour — mais pas, dans ce que l’on peut en lire, les chemins de retour arrière.

Cela transforme chaque mise à jour en pari. Pas parce que les mises à jour échouent systématiquement — elles réussissent probablement dans l’immense majorité des cas — mais parce que le coût d’un échec est inconnu à l’avance. Sur une machine à plusieurs milliers de dollars qui sert de nœud de calcul, l’incertitude sur la récupération est un risque opérationnel à part entière.

La comparaison avec les pratiques serveur est éclairante, à condition de ne pas la forcer. Sur HGX/GB200, la gestion firmware est industrialisée : BMC, redondance, procédures signées. Sur Strix Halo, c’est la communauté qui a documenté ce que les fabricants ne documentaient pas. La Spark est entre les deux : assez « serveur » pour qu’on attende une procédure de recovery, assez « produit Founders Edition » pour que cette procédure ne soit pas publiée. C’est un angle mort, et il faut le traiter comme tel.

Avant/après : les chiffres qu’on peut réellement mesurer (et ceux qu’on ne peut pas)

Voici la partie où il faut résister à la tentation. On aimerait vous donner un tableau « bande passante mémoire avant/après firmware » avec des GB/s précis. Nous ne pouvons pas, parce qu’aucune donnée de ce type n’est disponible dans notre corpus, et qu’inventer un chiffre sur une machine à mémoire unifiée serait irresponsable.

Ce que l’on peut faire, en revanche, c’est poser une grille de mesure rigoureuse, et surtout rappeler la règle d’or : ne pas attribuer au firmware ce qui relève du kernel 7.0 ou du driver 580.178.04. La release d’octobre change simultanément le noyau (6.17 → 7.0), le driver, et le firmware. Si vous mesurez une différence après mise à jour, vous ne savez pas d’où elle vient — sauf si vous isolez les variables.

La grille de mesure utile, pour un protocole avant/après :

Pour les débits LLM, on dispose heureusement de repères publics utiles, à condition de les utiliser comme références de stabilité, pas comme preuves d’un effet firmware. Sur une Spark unique en llama.cpp, les débits observés sur des modèles de type 35B-A3B montent jusqu’à environ 67 tok/s. En configuration 2× Spark avec vLLM en tensor parallel, on voit environ 41 tok/s en single-stream et environ 350 tok/s agrégés à concurrence 32, avec un prefill autour de 1 785 tok/s. Ces chiffres viennent de mesures publiées en 2026 et servent de point d’ancrage : si votre cluster s’écarte significativement de ces ordres de grandeur après un flash, vous avez un signal. Mais le signal ne dit pas pourquoi.

La méthode propre : flasher une seule variable à la fois. Si vous pouvez, faites la mise à jour firmware sans changer le noyau ni le driver (impossible avec la release d’octobre, mais faisable sur des correctifs intermédiaires). Sinon, faites une mesure avant, une mesure après, et documentez les trois versions (firmware, noyau, driver) dans le même tableau. C’est la seule façon de ne pas se raconter d’histoires.

Huit Sparks, un cluster : ce que la mise à jour en flotte change à la donne

Passons au cas qui nous intéresse vraiment : le cluster. Deux, quatre, huit nœuds. C’est là que le firmware cesse d’être un détail pour devenir un facteur de cohésion — ou de divergence.

Trois phénomènes sont à surveiller, et le retour d’expérience des huit unités les met en lumière même si l’on n’en connaît pas tous les détails :

1. La dérive de version. Si vous mettez à jour les nœuds un par un sans contrôle, vous vous retrouvez avec des Sparks en UEFI 1.111.17 et d’autres en version antérieure. Sur un cluster NCCL, ce n’est pas anodin : les jobs distribués peuvent échouer de façon intermittente, et le diagnostic est cauchemardesque parce que le symptôme (un job qui hang) n’a aucun rapport apparent avec la cause (un nœud en retard de firmware).

2. L’EC qui ne se resynchronise pas. C’est le scénario le plus vicieux : le nœud redémarre, le noyau boote, mais l’EC est dans un état incohérent. La machine fonctionne… jusqu’à ce qu’elle ne fonctionne plus, souvent sous charge. Sur un cluster, cela se traduit par un nœud qui décroche au bout de quelques heures.

3. La négociation PCIe post-flash. Le lien entre GB10 et Blackwell, et a fortiori les liens inter-Spark via QSFP, peuvent négocier en retrait après un flash. Le cluster « tient », mais les débits ne sont plus ceux d’avant. Sans mesure, on ne le voit pas.

La recommandation pour un cluster 2, 4 ou 8 nœuds est simple dans son principe : un nœud pilote, puis des vagues. On met à jour une unité, on la teste sous charge, on vérifie les débits, et seulement ensuite on passe à la vague suivante. Pour un possesseur d’une Spark unique, la même logique s’applique en miniature : on ne flashe pas la veille d’une deadline.

Le protocole de terrain : pré-vol, sauvegardes, ordre de mise à jour, critères d’arrêt

Voici le livrable opérationnel. Il n’est pas exhaustif — il ne peut pas l’être sans documentation officielle du rollback — mais il est reproductible.

1. Pré-vol. Inventoriez les versions avant de toucher à quoi que ce soit : UEFI, EC, SoC, TPM, USB PD, noyau, driver, CUDA. Notez-les dans un fichier versionné. Vérifiez l’alimentation (on ne flashe pas sur onduleur douteux ni sur batterie de portable). Sauvegardez la configuration système, pas seulement les données.

2. Sauvegardes. Ce qu’il faut vraiment sauvegarder : la configuration réseau, les environnements CUDA/conda, les modèles téléchargés (ou au moins leurs identifiants), les scripts de déploiement. Ce qu’on ne peut pas sauvegarder : l’état de l’EC, les partitions UEFI. C’est précisément ce qui rend le rollback incertain.

3. Ordre de mise à jour en flotte. Un nœud pilote d’abord. Test sous charge pendant plusieurs heures. Mesures de débit et de stabilité. Puis vague par vague, avec un point de contrôle entre chaque vague : versions cohérentes ? jobs distribués stables ? débits conformes ?

4. Critères d’arrêt. On stoppe la vague si : un nœud ne redémarre pas dans un délai raisonnable (mais lequel ? c’est le problème), un nœud redémarre mais l’EC semble incohérent, les débits chutent significativement, ou un job distribué échoue de façon reproductible. On rollback si un chemin existe — sinon, on appelle NVIDIA. Et on documente tout, parce que le prochain qui tentera la même mise à jour mérite de savoir.

Encadré : les cinq erreurs qui coûtent un après-midi

1. Flasher tous les nœuds en parallèle « pour gagner du temps ».
2. Ne pas noter les versions avant, et ne plus savoir ce qui a changé après.
3. Attribuer une régression de tokens/s au firmware alors qu’elle vient du driver.
4. Flasher la veille d’une démo ou d’une deadline.
5. Ignorer un nœud qui « boote mais se comporte bizarrement » — c’est souvent l’EC.

Ce que la release d’octobre annonce pour la suite — et ce qu’il faut exiger de NVIDIA

Terminons par le tableau d’ensemble. La release d’octobre 2026 dessine une machine plus mûre : DGX Dashboard Wi-Fi Assistant, DGX Spark Skills, Cloud-init natif, support 64 et 128 Go, noyau 7.0. Sur le papier, la Spark devient un produit fini, industrialisable. Et c’est vrai — sauf sur un point : la couche firmware reste le parent pauvre de la documentation.

Pour les acheteurs de systèmes partenaires GB10 (ASUS Ascent GX10, Acer, etc.), la question est encore plus aiguë : si les mises à jour firmware arrivent en décalage, et si le rollback n’est pas documenté, l’écart de prix avec la Founders Edition (Acer annonce 500 à 1 000 $ sous le prix NVIDIA officiel, avec des livraisons depuis le 8 septembre 2026) se paie en incertitude opérationnelle. Pour les équipes qui industrialisent des clusters Spark, c’est un facteur de risque à intégrer dans le budget. Et face aux Mac Studio et aux Strix Halo, la crédibilité de la plateforme sur le long terme passe par là : une machine qu’on ne peut pas récupérer après un flash raté n’est pas une machine de production.

Trois demandes concrètes, donc, à formuler à NVIDIA :

1. Des release notes firmware détaillées, avec les numéros UEFI/EC/SoC/PCIe, les correctifs, les known issues, et les durées de flash par phase.
2. Une documentation du rollback : partitions A/B ? mode recovery ? jumper ? procédure de reflash EC ? Peu importe la réponse — il faut qu’elle existe.
3. Un canal de distribution stable/beta clair, et une politique explicite pour les systèmes partenaires GB10, avec un engagement de délai.

Ce que les huit GB10 nous ont appris, en fin de compte, c’est que la Spark est une excellente machine dont le talon d’Achille n’est pas le silicium, ni CUDA, ni la mémoire unifiée — c’est la couche qui se trouve en dessous, celle qu’on ne voit pas, celle qu’on met à jour en espérant que tout se passe bien. Tant que cette couche restera un point aveugle, chaque mise à jour firmware sera un acte de foi. Et un acte de foi, en production, ce n’est pas un protocole.

Sources

• DGX Spark Release Notes — NVIDIA Documentation Hub
• DGX Spark Software Updates — October 2026 Release (forums développeurs NVIDIA)
• DGX Spark Software Updates — June 2026 Release (forums développeurs NVIDIA)
• OS and Component Update Guide — DGX Spark User Guide
• New firmware available — DGX Spark / GB10 (forums développeurs NVIDIA)
• DGX Spark Firmware Update: What We Learned on 8 GB10 Units — Petronella Technology Group
• NVIDIA details edge AI workflow for DGX Spark and TensorRT Edge-LLM — blockchain.news
• Best Local LLM Deployment Guide for DGX Spark, GB10 & 96-128 GB Edge AI
• Spark Arena — LLM Leaderboard

Article recherché et rédigé automatiquement · Magazine Electrosens