DGX Spark: limite de 1800 MHz na GPU reduz o consumo de dois nós de 330 W para 242–252 W

O DGX Spark é um computador compacto de IA da NVIDIA, baseado no chip GB10 e com 128 GB de memória unificada. Muita gente o compra para rodar grandes modelos de linguagem em casa ou em uma equipe pequena. O problema é que, "de fábrica", ele consome mais do que o necessário, esquenta e, para alguns donos, desliga de repente durante a noite.

O autor da análise no Habr passou meio ano fazendo experimentos e concluiu que a velocidade de geração de texto depende da largura de banda da memória, não do clock da GPU. Por isso, ao limitar a GPU a 1800 MHz, duas unidades conectadas passam a consumir 242–252 W em vez de 330 W, sem mudança no número de tokens por segundo. Em termos de analogia, é como percorrer uma rodovia a 110 km/h em vez de 140 km/h: gasta-se menos combustível e você chega ao destino no mesmo horário.

A seguir, a receita completa, que, segundo o autor, serve para qualquer engine de inferência e qualquer número de nós.

Remover o supérfluo sem quebrar o sistema

O autor faz questão de reconhecer os modelos chineses DeepSeek, Qwen, GLM e Kimi: foi graças a eles que essa pequena caixa se tornou realmente útil. O primeiro passo da configuração é colocar o Spark em modo headless com o comando sudo systemctl set-default multi-user.target, para que a interface gráfica não inicie. Em seguida, desativam-se os serviços desnecessários: bluetooth, cups, cups-browsed, avahi-daemon, ModemManager, apport, dgx-dashboard, dgx-dashboard-admin, multipathd e rsyslog. Já os serviços snapd, packagekit, nvidia-dgx-telemetry, nvidia-dgx-sol e udisks2 precisam ser mascarados (mask): o udisks2 é reativado via D-Bus, e um disable comum não o mantém desligado. O PipeWire é silenciado com systemctl --user mask, aplicado aos serviços e aos respectivos sockets.

Há duas armadilhas. A primeira: as atualizações OTA de firmware reativam, sem aviso, parte dos serviços desligados, então vale reconferir a lista após cada atualização. A segunda: não se deve remover o desktop com apt purge --auto-remove, porque o pacote nvidia-system-station-core está fortemente atrelado ao ubuntu-desktop. Em um teste (dry-run), o sistema propôs remover 1078 pacotes, incluindo as configurações do fstab, o console serial e o GRUB. Com o multi-user.target, o desktop não carrega de qualquer forma, então o melhor é deixá-lo em paz e remover pontualmente os programas desnecessários, como suíte de escritório e jogos de paciência, sem a flag de remoção automática.

Clocks de GPU e CPU: megahertz que só esquentam a sala

A decodificação (decode) é limitada pela memória, então qualquer clock de GPU acima de 1800 MHz só esquenta o ar. Também não convém baixar muito além disso: o prefill, que processa o prompt de entrada, perde desempenho. O autor considera 1800 MHz o ponto ideal: dois nós consomem 242–252 W em vez de 330 W, sem perda de tokens por segundo.

Com o processador, a história é parecida. As engines de inferência mantêm de 2 a 3 threads nos núcleos P rápidos Cortex-X925 em um ciclo de espera ativa (spin-wait): em vez de dormir, o núcleo consulta a GPU o tempo todo. Limitar os núcleos P a 3000 MHz preserva a vazão, reduz o consumo em 8–12%, e a zona mais quente esfria de 17 °C a 18 °C. Não se deve ir abaixo de 2808 MHz, o clock máximo dos núcleos E A725: o escalonador passaria a mover threads carregadas para núcleos lentos, e o desempenho cairia.

Os dois limites são definidos como units do systemd do tipo oneshot. A unit da GPU executa nvidia-smi -pm 1 e nvidia-smi -lgc 0,1800 (o valor vem de /etc/default/gpu-clock-cap) e, ao ser parada, remove a restrição com -rgc. A unit da CPU usa o cpupower para fixar o máximo de 3000 MHz nos núcleos 5-9 e 15-19 e, ao ser parada, restaura 3900 MHz.

Memória: 1,5 GiB de brinde e a pegadinha das páginas de 64K

A partir do firmware OTA 2610+, a memória reservada para o display pode ser configurada na UEFI diretamente pelo sistema operacional. Em vez dos 2 GB padrão, é possível escolher o modo Auto, que reserva 512 MiB em modo headless, e os 1,5 GiB liberados ficam para o sistema.

Um kernel com páginas de 64K deveria economizar memória: o overhead do Linux com as próprias estruturas cai de ~2 GB para ~128 MB. Mas o driver NVIDIA UVM ocupa uma página inteira de 64 KB para cada minúscula tabela de páginas de 256 bytes da GPU, o que resulta em uma perda de cerca de 3,25 GB. O patch memory-saver empacota essas tabelas e rende +1,8 GiB em relação a um kernel comum com páginas de 4K. A pegadinha: ele é incompatível com o Secure Boot. Por isso, o autor ainda não recomenda migrar para um kernel pronto do tipo nvidia-64k.

Ociosidade e o barramento de memória estreito

Um Spark com um modelo carregado e o link de rede ConnectX-7 ativo consome cerca de 50 W em ociosidade, e aproximadamente 20 W disso vêm da própria placa de rede. No firmware, o ASPM está desativado, não há economia de energia para o 200G e o Wake-on-LAN não foi implementado. Para comparação, um Mac Studio em repouso consome cerca de 10 W. A única solução que funciona é desligar o Spark com poweroff e ligá-lo por meio de uma tomada inteligente.

O autor aponta o barramento de memória como a principal limitação da plataforma: no GB10, ele é de 256 bits, com largura de banda de 273 GB/s. No Mac Studio M3 Ultra, são 819 GB/s; na RTX 5090, cerca de 1,8 TB/s; no Strix Halo, 256 GB/s. Por isso, a decodificação de um modelo MoE com 10B de pesos ativos em FP4 fica em cerca de 50 tokens/s, e os donos conectam várias unidades pela rede ConnectX-7 (TP2 ou TP3) para somar a largura de banda.

A tese de que o barramento foi reduzido de propósito, para que o Spark não tirasse vendas do DGX Station e da RTX Pro, é opinião do autor, não um fato confirmado. Os números de consumo foram obtidos na configuração dele e podem ser diferentes em outra.

A conclusão prática: se o Spark fica em casa ou em um escritório pequeno, o modo headless, os limites de clock de GPU e CPU e a alimentação remota geram uma economia expressiva de watts sem perda de velocidade.