DGX Spark: un límite de 1800 MHz en la GPU reduce el consumo de dos nodos de 330 a 242–252 W

DGX Spark es un ordenador compacto de NVIDIA para IA, basado en el chip GB10 y con 128 GB de memoria unificada. Muchos lo compran para ejecutar grandes modelos de lenguaje en casa o en un equipo pequeño. El problema es que, tal como sale de fábrica, consume más de lo necesario, se calienta y, a algunos propietarios, se les apaga de forma inesperada por las noches.

El autor de un análisis en Habr pasó seis meses experimentando y concluyó que la velocidad de generación de texto depende del ancho de banda de la memoria, no de la frecuencia de la GPU. Por eso, si se limita la GPU a 1800 MHz, dos equipos conectados consumen 242–252 W en lugar de 330 W, y el número de tokens por segundo no cambia. En sentido figurado, es como hacer un trayecto por autopista a 110 km/h en vez de a 140: se gasta menos combustible y se llega al destino a la misma hora.

A continuación, la receta completa que, según el autor, sirve para cualquier motor de inferencia y para cualquier número de nodos.

Quitar lo superfluo sin romper el sistema

El autor reconoce el mérito de los modelos chinos (DeepSeek, Qwen, GLM y Kimi): gracias a ellos, esta pequeña caja resultó ser realmente útil. El primer paso de la configuración es pasar el Spark a modo headless con el comando sudo systemctl set-default multi-user.target, para que no arranque el entorno gráfico. Después se desactivan los servicios innecesarios: bluetooth, cups, cups-browsed, avahi-daemon, ModemManager, apport, dgx-dashboard, dgx-dashboard-admin, multipathd y rsyslog. Los servicios snapd, packagekit, nvidia-dgx-telemetry, nvidia-dgx-sol y udisks2 hay que enmascararlos (mask): udisks2 se reactiva a través de D-Bus y un simple disable no lo mantiene apagado. PipeWire se silencia con systemctl --user mask, aplicado tanto a los servicios como a sus sockets.

Hay dos trampas. La primera: las actualizaciones OTA del firmware reactivan en silencio parte de los servicios desactivados, así que conviene revisar la lista tras cada actualización. La segunda: no se debe eliminar el escritorio con apt purge --auto-remove, porque el paquete nvidia-system-station-core está estrechamente vinculado a ubuntu-desktop. En una prueba (dry-run), el sistema propuso eliminar 1078 paquetes, entre ellos las configuraciones de fstab, la consola serie y GRUB. Con multi-user.target el escritorio no se carga de todos modos, así que es mejor dejarlo en paz y eliminar de forma selectiva, y sin la opción de eliminación automática, los programas que sobran, como la suite ofimática o los juegos de cartas.

Frecuencias de GPU y CPU: megahercios que solo calientan la habitación

La decodificación depende de la memoria, así que todo lo que supere los 1800 MHz en la GPU solo calienta el aire. Tampoco conviene bajar mucho más: se resentiría el prefill, es decir, el procesamiento del prompt de entrada. El autor considera que 1800 MHz es el valor óptimo: dos nodos consumen 242–252 W en lugar de 330 W sin perder tokens por segundo.

Con el procesador ocurre algo parecido. Los motores de inferencia mantienen 2–3 hilos en los rápidos núcleos P Cortex-X925 en un bucle de espera activa (spin-wait): en lugar de dormir, el núcleo consulta la GPU constantemente. Limitar los núcleos P a 3000 MHz conserva el rendimiento, reduce el consumo entre un 8 y un 12%, y la zona más caliente se enfría 17–18 °C. No se debe bajar de 2808 MHz, la frecuencia máxima de los núcleos E A725: el planificador empezaría a pasar hilos con carga a los núcleos lentos y el rendimiento caería.

Ambos límites se definen como unidades de systemd de tipo oneshot. La unidad de la GPU ejecuta nvidia-smi -pm 1 y nvidia-smi -lgc 0,1800 (el valor se toma de /etc/default/gpu-clock-cap) y, al detenerse, levanta la restricción con -rgc. La unidad de la CPU usa cpupower para fijar un máximo de 3000 MHz en los núcleos 5-9 y 15-19, y al detenerse restablece los 3900 MHz.

Memoria: 1,5 GiB de regalo y la trampa de las páginas de 64K

A partir del firmware OTA 2610+, la memoria reservada para la pantalla en UEFI se configura directamente desde el sistema operativo. En lugar de los 2 GB predeterminados, se puede elegir el modo Auto, que en headless equivale a 512 MiB, y los 1,5 GiB liberados pasan al sistema.

Un kernel con páginas de 64K debería ahorrar memoria: la sobrecarga de Linux en sus estructuras baja de ~2 GB a ~128 MB. Pero el controlador NVIDIA UVM ocupa una página completa de 64 KB por cada diminuta tabla de páginas de 256 bytes de la GPU, lo que supone una pérdida de unos 3,25 GB. El parche memory-saver empaqueta esas tablas y aporta +1,8 GiB respecto a un kernel normal con páginas de 4K. La trampa es que no es compatible con Secure Boot. Por eso, el autor no aconseja por ahora pasarse a un kernel ya preparado del tipo nvidia-64k.

Reposo y un bus de memoria estrecho

Un Spark con un modelo cargado y el enlace de red ConnectX-7 activo consume en reposo unos 50 W, de los cuales aproximadamente 20 W corresponden a la propia tarjeta de red. En el firmware está desactivado ASPM, no hay ahorro de energía para 200G y Wake-on-LAN no está implementado. Como referencia, un Mac Studio en suspensión consume unos 10 W. La única solución que funciona es apagar el Spark con poweroff y encenderlo mediante un enchufe inteligente.

El autor señala el bus de memoria como la principal limitación de la plataforma: el del GB10 es de 256 bits y ofrece un ancho de banda de 273 GB/s. El Mac Studio M3 Ultra llega a 819 GB/s, la RTX 5090 a cerca de 1,8 TB/s y Strix Halo a 256 GB/s. Por eso, la decodificación de un modelo MoE con 10B de pesos activos en FP4 se queda en torno a 50 tokens/s, y los propietarios conectan varios equipos por red ConnectX-7 (TP2 o TP3) para sumar ancho de banda.

La idea de que el bus se recortó a propósito para que el Spark no le quitara ventas a DGX Station y RTX Pro es una opinión del autor, no un hecho confirmado. Las cifras de consumo se obtuvieron con su configuración y pueden variar en otra.

Conclusión práctica: si el Spark está en una casa o en una oficina pequeña, el modo headless, los límites de frecuencia de GPU y CPU y la alimentación remota permiten un ahorro notable de vatios sin perder velocidad.