Spark Memory & Thermal Ops

O chip GB10 do DGX Spark possui um pool de memória unificada (UMA) de 128GB compartilhado por CPU e GPU, e um limite de energia sustentado bem abaixo de seu valor nominal. Ambos quebram as suposições de GPUs discretas: o espaço livre não é o que nvidia-smi relata, e uma execução que começa rápido desacelerará no meio do trabalho sem nada mal configurado. Esta habilidade cobre o planejamento do espaço livre de memória, o trabalho com um OOM real e a observação das temperaturas em um trabalho longo. Para modos de falha no momento do lançamento (incompatibilidades de ABI, flash-attn, quebra de playbook), veja spark-training-gotchas — esta habilidade assume que o trabalho começa.

Referência Rápida de Problemas Comuns

Quando Usar Esta Habilidade

• Dimensionar uma execução de treinamento contra o pool de 128GB antes do lançamento — se este modelo, método e combinação de batch/pack caberão.
• Uma execução OOMs no meio do carregamento ou no meio do passo e a ordem de remediação importa — o que tentar primeiro, segundo, terceiro.
• Observar a temperatura e a energia durante um trabalho de várias horas, decidindo se uma desaceleração é limitação térmica ou algo mais.
• Planejar executar um treinador ao lado de um servidor de inferência (vLLM, Ollama) na mesma máquina.

Modelo de Memória UMA

Spark não tem VRAM de GPU separada — a GPU e a CPU compartilham um pool de 128GB. Duas consequências:

• nvidia-smi e cudaMemGetInfo subestimam a pressão — ou não relatam nada. Ambos relatam memória visível pelo alocador CUDA, não o estado real do pool — uma máquina pode mostrar espaço livre em nvidia-smi e ainda assim OOM, porque o cache de página e as páginas mmap'd que o alocador não vê consomem o mesmo pool. Em alguns drivers/configurações, a consulta de memória retorna [N/A], [N/A] diretamente em vez de um número — um script que busca um valor numérico lá não obtém nada, não uma subcontagem enganosa (veja a pegadinha G3 de spark-training-gotchas).

• O carregamento do modelo é um pico transitório, não o estado estável. Carregar pesos safetensors mmap'a o arquivo, depois copia para tensores CUDA — por uma janela durante o carregamento, tanto as páginas mmap'd quanto a cópia CUDA contam contra o pool ao mesmo tempo. Um modelo que cabe durante o treinamento ainda pode OOM durante o carregamento se o espaço livre foi dimensionado para a pegada pós-carregamento em vez desta duplicação transitória.

Planeje e diagnostique com free -g, não nvidia-smi:

free -g | awk 'NR==2 {print "free:", $4, "GB"}'

Regra geral: pegue esse valor livre, subtraia alguns GB para sobrecarga do sistema operacional/driver e orce contra o resultado — não o número da especificação de 128GB. A planilha em references/uma-accounting.md aceita contagem de parâmetros, dtype e método como entrada, e retorna uma estimativa de memória para comparar com âncoras conhecidas.

Sequência de Planejamento

Antes do lançamento, trabalhe nestes em ordem:

1. Leia free -g; subtraia a sobrecarga do sistema operacional/driver para o orçamento.
2. Estime pesos + otimizador + gradientes + ativações de references/uma-accounting.md.
3. Compare com a âncora mais próxima (70B QLoRA, 27B LoRA, 9B FT completo), não apenas a estimativa.
4. Se a estimativa estiver próxima do orçamento, comece com um packing mais curto ou um batch menor — mais barato do que atingir a Escada OOM no meio da execução.

Exemplo: Dimensionando uma Execução QLoRA de 70B

Uma verificação de sanidade da fórmula da planilha contra a âncora de ≈40GB:

params = 70e9
weights_gb = params * 0.5 / 1e9      # NF4, step 1
adapter_gb = 0.5                     # step 5, negligible
total_gb = weights_gb + adapter_gb   # + activations
print(f"{total_gb:.0f}GB before activations")

Apenas os pesos ficam perto da âncora de ≈40GB — um plano que estima muito acima disso para a mesma classe de modelo é um sinal para verificar novamente o dtype e o método.

A Escada OOM

Quando um trabalho OOMs na memória unificada, trabalhe nesta escada em ordem. Cada passo é mais disruptivo que o anterior — não pule etapas: reduzir o tamanho do batch nunca é o passo 1.

1. Limpe o cache do buffer. O cache de página de uma execução anterior ou a leitura de um grande conjunto de dados geralmente responde por GB do espaço livre "faltando". Isso não custa nada além de uma nova execução e não mexe na configuração do trabalho:

   sync; echo 3 > /proc/sys/vm/drop_caches
   

   Precisa de root; um reset entre execuções, não um