DGX Spark: 1,5 GB Speicher über UEFI zurückgewinnen

Was sich in UEFI genau ändert

Ich würde dies nicht als kleine Optimierung bezeichnen: Die DGX-Spark-Firmware reserviert standardmäßig 2 GB gemeinsamen Speicher für den Displaypuffer, auch wenn kein Monitor verwendet wird. Auf einem System ohne Display reduziert der Auto-Modus diese Reservierung auf 0,5 GB und gibt etwa 1,5 GB an Betriebssystem, CUDA und normale Anwendungen zurück.

In der öffentlichen NVIDIA-Dokumentation für DGX Spark wird die Variable NvidiaDispFrmSizeRequest zur Steuerung dieser Reservierung genannt. Sie ist eine einmalige Anfrage an die Firmware: Beim nächsten Start prüft sie den Wert, übernimmt ihn und entfernt die Variable. Die Unterstützung dieses Mechanismus ist ab OTA2610 dokumentiert; in der Ausgangskonfiguration wird außerdem UEFI 1.111.17 genannt.

Hier gibt es eine Falle auf Byte-Ebene. Der Auto-Code lautet 0x00, während 0x07 die Attribute der EFI-Variablen beschreibt: non-volatile, boot-service und runtime access. Die Sequenz 07 00 00 00 00 ist daher korrekt als vier Attribut-Bytes und ein Daten-Byte, aber 0x07 darf nicht als Auto-Code gelesen werden.

Die Variable NvidiaDispFrmStatus dient ausschließlich zum Auslesen des Ergebnisses. Nach dem vier Byte langen efivarfs-Header folgen der Code des gewählten Modus und die Größe der Reservierung in MiB. Für Auto ohne angeschlossenen Monitor werden die Daten 00 00 02 00 00 erwartet: Modus 0x00 und 512 MiB im Little-Endian-Format.

Nach dem Schreiben der Request-Variablen ist ein Neustart nötig. Das Ergebnis lässt sich über NvidiaDispFrmStatus und MemTotal in /proc/meminfo prüfen. Der tatsächliche Gewinn kann wegen weiterer reservierter Bereiche und der Speicherbilanzierung des Kernels leicht von den theoretischen 1536 MiB abweichen.

Wo der Gewinn liegt — und wo Risiken entstehen

Der Vorteil ist real, besonders für lokale Modelle, denen die letzten paar hundert Megabyte fehlen. DGX Spark verwendet gemeinsamen CPU- und GPU-Speicher; die Display-Reservierung reduziert daher direkt die Kapazität, die dem System und Rechenlasten zur Verfügung steht.

Auto bedeutet jedoch keine dynamische Neuverteilung im laufenden Betrieb. Die Firmware bewertet angeschlossene Displays beim Booten; ein später angeschlossener Monitor erhöht die Reservierung nicht automatisch.

• Bei mehreren Displays oder hohen Auflösungen können 0,5 GB zu wenig sein und Treiberfehler oder fehlenden Display-Speicher verursachen.
• Geändert werden muss die Request-Variable, nicht der von der Firmware erzeugte Status.
• Bei der Arbeit mit efivarfs sollte das Risiko eines fehlerhaften Schreibvorgangs berücksichtigt und ein Weg zur Wiederherstellung der UEFI-Einstellungen vorbereitet werden.

Die wichtigste Ressource bei diesem Trick ist nicht Speicher, sondern Präzision: Ein Byte wählt den Modus, und eine falsche Deutung benachbarter Bytes macht aus nützlichen 1,5 GB ein Firmware-Experiment.

Wir haben zuvor Rust LocalGPT vorgestellt: einen lokalen Assistenten in einer einzigen Binärdatei mit persistentem Speicher und HTTP-API. Dieses Beispiel zeigt, warum die Optimierung des Ressourcenverbrauchs besonders beim lokalen Betrieb von KI-Workloads wichtig ist.