Gotchas de Treinamento Spark

O chip GB10 do DGX Spark (Grace Blackwell, SM121, 128GB de memória unificada, aarch64) tem dez modos de falha recorrentes em lançamento, memória, térmicas, largura de banda e precisão. Cada um é nomeado G1–G10 para que possa ser verificado por número — a numeração é crucial para ferramentas que executam essas verificações. Leia isto antes de uma execução longa, não depois da sexta hora.

Quando Usar Esta Habilidade

• Uma execução de treinamento falha ao iniciar, com um erro de importação ou um segfault que não aponta para a causa real.
• Uma execução OOM (Out Of Memory) enquanto nvidia-smi ainda mostra espaço livre.
• A taxa de transferência degrada no meio de uma execução que começou bem.
• Antes de qualquer job de várias horas ou várias épocas no GB10.
• Conectando dois Sparks, antes de escolher uma estratégia de paralelismo.
• Escolhendo entre FP8 e NVFP4 para uma execução hospedada no Spark.

Referência Rápida de Problemas Comuns

Os Dez Gotchas

G1: Incompatibilidade ABI CUDA 12/13

• SINTOMA: ImportError: undefined symbol nomeando uma função CUDA, ou um segfault na primeira chamada .cuda().
• CAUSA: a maioria das rodas PyPI linka libcudart.so.12; Spark envia CUDA 13. pip nunca verifica ABI CUDA, então isso só aparece na importação ou no primeiro lançamento do kernel.
• VERIFICAÇÃO: references/gotcha-checks.md G1 — a tag de build CUDA da roda.
• CORREÇÃO: reinstalar de download.pytorch.org/whl/cu130 ou usar um container compatível.

G2: flash-attn — Pule o Build Pip, Observe a Autodetecção do Unsloth

• SINTOMA: pip install flash-attn ainda falha/trava. Unsloth também pode treinar silenciosamente flash-attn sobre um SDPA explicitamente solicitado.
• CAUSA: não há roda aarch64/sm_121 para pip puro — mas containers NGC enviam um flash-attn SM121 funcional, e Unsloth o prefere automaticamente, descartando attn_implementation="sdpa".
• VERIFICAÇÃO: references/gotcha-checks.md G1 — se flash-attn já está presente e funcionando.
• CORREÇÃO: pip puro — pule flash-attn, use SDPA (inalterado). No NGC — a única substituição confiável é o monkeypatch em references/gotcha-checks.md G2.

G3: OOM UMA Abaixo de 128GB

• SINTOMA: OOM durante o carregamento/treinamento do modelo enquanto nvidia-smi ainda relata memória livre abaixo do limite de 128GB — ou, em algumas configurações, [N/A] diretamente em vez de um número.
• CAUSA: mmap e o alocador CUDA contam páginas em dobro durante o carregamento safetensors; QLoRA pode OOM mais cedo que bf16, pois a desquantização adiciona alocações transitórias.
• VERIFICAÇÃO: references/gotcha-checks.md G3 — leia free -g e /proc/meminfo, não nvidia-smi.
• CORREÇÃO: liberar o cache de página com sync; echo 3 > /proc/sys/vm/drop_caches — precisa de root, um reset entre execuções, não um passo no meio do treinamento.

G4: Limitação Térmica

• SINTOMA: a taxa de transferência cai no meio de uma execução de várias horas, ou a caixa reinicia espontaneamente sob carga sustentada.
• CAUSA: o consumo de energia sustentado é limitado em torno de 100W versus o valor nominal de 240W; execuções longas atingem esse teto e limitam ou, às vezes, reiniciam.
• VERIFICAÇÃO: references/gotcha-checks.md G4 — amostre nvidia-smi --query-gpu=temperature.gpu,power.draw.
• CORREÇÃO: se a energia se estabiliza abaixo de 240W enquanto a temperatura sobe, trate a limitação como a causa; melhore o resfriamento ou limite a duração da execução.

G5: Teto de Largura de Banda

• SINTOMA: workloads limitados por memória, especialmente loops de RL com decodificação pesada, atingem um platô bem abaixo da taxa de transferência esperada.
• CAUSA: 273 GB/s é um teto de especificação, não sustentado; a largura de banda medida opera em 180–192 GB/s.
• VERIFICAÇÃO: references/gotcha-checks.md G5 — tempo de passo observado versus a faixa medida, não a especificação.
• CORREÇÃO: orçar a taxa de transferência de 180–192 GB/s; revise um plano construído sobre o valor de 273 GB/s.

G6: Contenção Global de Recursos UMA

• SINTOMA: o cache KV/pesos de um processo são evictados no meio da execução silenciosamente, sem OOM em seus próprios logs.
• CAUSA: memória unificada é um pool global único; um processo sem limite ou próximo da capacidade compete com qualquer outra coisa e pode evictá-la. Um pequeno,

…