DGX Spark: recupera 1,5 GB de memoria mediante UEFI

Qué cambia exactamente en UEFI

No lo llamaría un ajuste menor: de forma predeterminada, el firmware de DGX Spark reserva 2 GB de memoria unificada para el búfer de pantalla, incluso cuando no se utiliza ningún monitor. En un sistema sin pantalla, el modo Auto reduce esa reserva a 0,5 GB y devuelve aproximadamente 1,5 GB al sistema operativo, CUDA y las aplicaciones habituales.

La documentación pública de NVIDIA para DGX Spark indica la variable NvidiaDispFrmSizeRequest para gestionar esta reserva. Es una solicitud de un solo uso para el firmware: en el siguiente arranque comprueba el valor, lo aplica y elimina la variable. La compatibilidad con este mecanismo está documentada desde OTA2610; la configuración de referencia también indica UEFI 1.111.17.

Aquí hay una trampa a nivel de bytes. El código de Auto es 0x00, mientras que 0x07 representa los atributos de la variable EFI: non-volatile, boot-service y runtime access. Por tanto, la secuencia 07 00 00 00 00 es correcta como cuatro bytes de atributos y un byte de datos, pero 0x07 no debe interpretarse como el código Auto.

La variable NvidiaDispFrmStatus sirve únicamente para leer el resultado. Tras la cabecera de cuatro bytes de efivarfs aparecen el código del modo elegido y el tamaño de la reserva en MiB. Para Auto sin monitor conectado, se esperan los datos 00 00 02 00 00: modo 0x00 y 512 MiB en little-endian.

Después de escribir la variable de solicitud, hay que reiniciar. Comprueba el resultado mediante NvidiaDispFrmStatus y MemTotal en /proc/meminfo. La ganancia real puede variar ligeramente respecto a los 1536 MiB teóricos debido a otras regiones reservadas y a la contabilidad de memoria del kernel.

Dónde está la ganancia y dónde puede fallar

La mejora es real, especialmente para modelos locales a los que les faltan unos cientos de megabytes. DGX Spark utiliza memoria unificada para CPU y GPU, por lo que la reserva de pantalla reduce directamente la capacidad visible para el sistema y las cargas de cálculo.

Sin embargo, Auto no redistribuye la memoria dinámicamente mientras el sistema está en marcha. El firmware evalúa las pantallas conectadas durante el arranque; conectar un monitor después no aumentará la reserva automáticamente.

• Con varias pantallas o resoluciones altas, 0,5 GB puede no ser suficiente y provocar errores del controlador o falta de memoria de pantalla.
• Debes modificar la variable de solicitud, no el estado generado por el firmware.
• Al trabajar con efivarfs, considera el riesgo de una escritura incorrecta y mantén una vía para restaurar la configuración UEFI.

El recurso clave de este truco no es la memoria, sino la precisión: un byte selecciona el modo, y malinterpretar los bytes cercanos convierte una recuperación útil de 1,5 GB en un experimento con el firmware.

Anteriormente analizamos Rust LocalGPT, un asistente local en un único binario con memoria persistente y una API HTTP. Este ejemplo demuestra por qué optimizar el uso de recursos es especialmente importante al ejecutar cargas de IA de forma local.