DGX Spark : récupérer 1,5 Go de mémoire via UEFI

Ce qui change réellement dans l’UEFI

Je ne qualifierais pas cela de simple ajustement : par défaut, le firmware du DGX Spark réserve 2 Go de mémoire unifiée pour le tampon d’affichage, même lorsqu’aucun écran n’est utilisé. Sur une machine sans écran, le mode Auto ramène cette réserve à 0,5 Go et restitue environ 1,5 Go au système d’exploitation, à CUDA et aux applications classiques.

La documentation publique de NVIDIA pour DGX Spark désigne la variable NvidiaDispFrmSizeRequest pour gérer cette réserve. Il s’agit d’une requête à usage unique destinée au firmware : au démarrage suivant, il vérifie la valeur, l’applique, puis supprime la variable. La prise en charge de ce mécanisme est documentée à partir d’OTA2610 ; la configuration de référence mentionne également UEFI 1.111.17.

Il existe ici un piège au niveau des octets. Le code Auto est 0x00, tandis que 0x07 correspond aux attributs de la variable EFI : non-volatile, boot-service et runtime access. La séquence 07 00 00 00 00 est donc correcte en tant que quatre octets d’attributs suivis d’un octet de données, mais 0x07 ne doit pas être interprété comme le code Auto.

La variable NvidiaDispFrmStatus sert uniquement à lire le résultat. Après l’en-tête efivarfs de quatre octets viennent le code du mode choisi et la taille de la réserve en Mio. Pour Auto sans écran connecté, les données attendues sont 00 00 02 00 00 : mode 0x00 et 512 Mio en little-endian.

Après l’écriture de la variable de requête, un redémarrage est nécessaire. Vérifiez le résultat avec NvidiaDispFrmStatus et MemTotal dans /proc/meminfo. Le gain réel peut légèrement différer des 1536 Mio théoriques en raison d’autres zones réservées et de la façon dont le noyau comptabilise la mémoire.

Où se trouve le gain, et où sont les risques

Le bénéfice est réel, surtout pour les modèles locaux auxquels il manque quelques centaines de mégaoctets. DGX Spark utilise une mémoire unifiée pour le CPU et le GPU : la réserve d’affichage réduit donc directement la capacité visible par le système et les charges de calcul.

Toutefois, Auto ne réalloue pas dynamiquement la mémoire pendant le fonctionnement. Le firmware évalue les écrans connectés au démarrage ; brancher un écran plus tard n’augmentera pas automatiquement la réserve.

• Avec plusieurs écrans ou une haute résolution, 0,5 Go peut être insuffisant et provoquer des erreurs de pilote ou un manque de mémoire d’affichage.
• Il faut modifier la variable de requête, et non l’état généré par le firmware.
• Avec efivarfs, tenez compte du risque d’écriture incorrecte et prévoyez un moyen de restaurer les réglages UEFI.

Dans cette astuce, la ressource principale n’est pas la mémoire mais la précision : un seul octet choisit le mode, et une mauvaise interprétation des octets voisins transforme 1,5 Go utiles en expérience avec le firmware.

Nous avons déjà présenté Rust LocalGPT, un assistant local dans un unique binaire avec mémoire persistante et API HTTP. Cet exemple montre pourquoi l’optimisation des ressources est particulièrement importante lors de l’exécution locale de charges d’IA.