DGX Spark : une limite GPU à 1800 MHz fait passer deux nœuds de 330 à 242–252 W

Le DGX Spark est un ordinateur d'IA compact de NVIDIA, bâti sur la puce GB10 avec 128 Go de mémoire unifiée. Beaucoup l'achètent pour faire tourner de grands modèles de langage chez eux ou dans une petite équipe. Le problème : « out of the box », il consomme plus que nécessaire, chauffe et, chez certains propriétaires, s'éteint soudainement la nuit.

L'auteur d'une analyse publiée sur Habr a expérimenté pendant six mois et en conclut que la vitesse de génération de texte est limitée par la bande passante mémoire, et non par la fréquence du GPU. Résultat : en plafonnant le GPU à 1800 MHz, deux boîtiers reliés consomment 242–252 W au lieu de 330 W, sans changement du nombre de tokens par seconde. Image parlante : c'est comme rouler sur l'autoroute à 110 km/h plutôt qu'à 140.

On brûle moins d'essence, et on arrive à destination en même temps. Voici la recette complète, qui convient, selon l'auteur, à n'importe quel moteur d'inférence et à n'importe quel nombre de nœuds.

Supprimer le superflu sans casser le système

L'auteur rend hommage aux modèles chinois DeepSeek, Qwen, GLM et Kimi : c'est grâce à eux que cette petite boîte est devenue réellement utile. La première étape consiste à passer le Spark en mode headless avec la commande sudo systemctl set-default multi-user.target, afin que l'interface graphique ne démarre pas. On désactive ensuite les services inutiles : bluetooth, cups, cups-browsed, avahi-daemon, ModemManager, apport, dgx-dashboard, dgx-dashboard-admin, multipathd, rsyslog. Les services snapd, packagekit, nvidia-dgx-telemetry, nvidia-dgx-sol et udisks2 doivent être masqués (mask) : udisks2 se réveille via D-Bus, et un simple disable ne le retient pas. PipeWire est coupé par systemctl --user mask, appliqué aux services eux-mêmes et à leurs sockets.

Deux pièges sont à éviter. Premièrement, les mises à jour OTA du firmware réactivent en silence une partie des services désactivés : mieux vaut revérifier la liste après chaque mise à jour. Deuxièmement, il ne faut pas supprimer l'environnement de bureau avec apt purge --auto-remove : le paquet nvidia-system-station-core est étroitement lié à ubuntu-desktop. Lors d'un essai à blanc (dry-run), le système a proposé de supprimer 1078 paquets, y compris les configurations fstab, la console série et GRUB. Avec multi-user.target, le bureau ne se charge de toute façon pas ; mieux vaut donc le laisser tranquille et retirer au cas par cas les programmes inutiles, comme la suite bureautique ou les jeux de solitaire, sans l'option de suppression automatique.

Fréquences GPU et CPU : des mégahertz qui ne font que chauffer la pièce

Le décodage est limité par la mémoire, donc tout ce qui dépasse 1800 MHz sur le GPU ne fait que réchauffer l'air. Descendre beaucoup plus bas n'est pas souhaitable non plus : le prefill, c'est-à-dire le traitement du prompt d'entrée, ralentirait. L'auteur juge 1800 MHz optimal : deux nœuds consomment 242–252 W au lieu de 330 W, sans perte de tokens par seconde.

Le processeur suit une logique comparable. Les moteurs d'inférence maintiennent 2 à 3 threads sur les P-cores rapides Cortex-X925 en attente active (spin-wait) : au lieu de dormir, le cœur interroge le GPU en permanence. Limiter les P-cores à 3000 MHz préserve le débit, réduit la consommation de 8–12 %, et la zone la plus chaude refroidit de 17–18 °C. Il ne faut pas descendre sous 2808 MHz, la fréquence maximale des E-cores A725 : l'ordonnanceur commencerait à déplacer les threads chargés vers les cœurs lents, et les performances chuteraient.

Les deux limites sont mises en place sous forme d'unités systemd de type oneshot. L'unité GPU appelle nvidia-smi -pm 1 et nvidia-smi -lgc 0,1800 (la valeur est lue dans /etc/default/gpu-clock-cap), puis lève la limite avec -rgc à l'arrêt. L'unité CPU fixe via cpupower un maximum de 3000 MHz sur les cœurs 5-9 et 15-19, et rétablit 3900 MHz à l'arrêt.

Mémoire : 1,5 Gio offerts et le piège des pages de 64K

Depuis le firmware OTA 2610+, la mémoire réservée à l'affichage se règle dans l'UEFI directement depuis le système d'exploitation. Au lieu des 2 Go par défaut, on peut choisir le mode Auto, soit 512 Mio en mode headless, et les 1,5 Gio libérés reviennent au système.

Un noyau à pages de 64K est censé économiser de la mémoire : la surcharge de Linux pour ses structures passe de ~2 Go à ~128 Mo. Mais le pilote NVIDIA UVM réserve une page entière de 64 Ko pour chaque minuscule table de pages de 256 octets de la puce graphique, ce qui représente une perte d'environ 3,25 Go. Le patch memory-saver regroupe ces tables et apporte +1,8 Gio par rapport à un noyau classique à pages de 4K. Le piège : il est incompatible avec Secure Boot. L'auteur déconseille donc pour l'instant de passer à un noyau prêt à l'emploi de type nvidia-64k.

Consommation au repos et bus mémoire étroit

Un Spark avec un modèle chargé et un lien réseau ConnectX-7 actif consomme environ 50 W au repos, dont environ 20 W pour la seule carte réseau. L'ASPM est désactivé dans le firmware, il n'existe pas d'économie d'énergie pour le 200G et Wake-on-LAN n'est pas implémenté. À titre de comparaison, un Mac Studio en veille consomme environ 10 W. La seule solution qui fonctionne consiste à éteindre le Spark avec poweroff et à le rallumer via une prise connectée.

L'auteur désigne le bus mémoire comme la principale limite de la plateforme : celui du GB10 fait 256 bits, pour une bande passante de 273 Go/s. Le Mac Studio M3 Ultra atteint 819 Go/s, la RTX 5090 environ 1,8 To/s, le Strix Halo 256 Go/s. Pour cette raison, le décodage d'un modèle MoE avec 10B de poids actifs en FP4 plafonne autour de 50 tokens/s, et les propriétaires associent plusieurs boîtiers via le réseau ConnectX-7 (TP2 ou TP3) pour additionner la bande passante.

L'idée selon laquelle le bus aurait été bridé volontairement, pour que le Spark ne vole pas de ventes au DGX Station et aux RTX Pro, est l'opinion de l'auteur, et non un fait confirmé. Les chiffres de consommation ont été obtenus sur sa configuration et peuvent différer sur une autre.

En pratique : si le Spark est installé chez soi ou dans un petit bureau, le mode headless, les limites de fréquence GPU et CPU et l'alimentation pilotée à distance font économiser un nombre notable de watts, sans perte de vitesse.