DGX Spark: reclaim 1.5 GB of memory through UEFI

What changes in UEFI

I would not call this a minor tweak: by default, DGX Spark firmware reserves 2 GB of unified memory for the display buffer, even when no monitor is in use. On a headless system, Auto mode lowers that reservation to 0.5 GB and returns about 1.5 GB to the operating system, CUDA, and regular applications.

NVIDIA's public DGX Spark documentation identifies NvidiaDispFrmSizeRequest as the variable used to manage this reservation. It is a one-time request to the firmware: at the next boot, the firmware checks the value, applies it, and removes the variable. Support for this mechanism is documented from OTA2610 onward; the baseline configuration also lists UEFI version 1.111.17.

There is a byte-level trap here. The Auto code is 0x00, while 0x07 represents the EFI variable attributes: non-volatile, boot-service, and runtime access. Therefore, the sequence 07 00 00 00 00 is valid as four attribute bytes followed by one data byte, but 0x07 must not be mistaken for the Auto code.

The NvidiaDispFrmStatus variable is only for reading the result. After the four-byte efivarfs header come the selected mode code and the reservation size in MiB. For Auto with no monitor connected, the expected data is 00 00 02 00 00: mode 0x00 and 512 MiB in little-endian format.

After writing the request variable, reboot the system. Verify the result through NvidiaDispFrmStatus and MemTotal in /proc/meminfo. The real gain can differ slightly from the theoretical 1536 MiB because of other reserved regions and how the kernel accounts for memory.

Where the benefit is real — and where it can backfire

The gain is tangible, especially for local models that are short by the last few hundred megabytes. DGX Spark uses unified CPU and GPU memory, so the display reservation directly reduces the capacity available to the system and compute workloads.

However, Auto does not dynamically reallocate memory while the system is running. Firmware evaluates connected displays during boot; attaching a monitor later will not automatically increase the reservation.

• For multiple displays or high resolutions, 0.5 GB may be insufficient and can cause driver errors or a lack of display memory.
• Change the request variable, not the status generated by the firmware.
• When working with efivarfs, account for the risk of an incorrect write and keep a way to restore UEFI settings.

The key resource in this trick is not memory but precision: one byte selects the mode, and misreading nearby bytes turns a useful 1.5 GB recovery into a firmware experiment.

We previously explored Rust LocalGPT, a local assistant in a single binary with persistent memory and an HTTP API. This example shows why optimizing resource usage matters especially when running AI workloads locally.