Como mantemos as GPUs confiáveis em todo o Databricks AI

O treinamento distribuído de GPU tornou-se rotina em todo o setor. Agora, as equipes treinam modelos de fundação, realizam o ajuste fino (fine-tuning) de modelos em escala de fronteira, constroem grandes sistemas de visão e executam redes de recomendação profundas em escalas que antes eram de domínio exclusivo dos laboratórios de ponta.

Construir uma infraestrutura de GPU que atenda à escala atual exige acertar em muitos aspectos: detectar as falhas que interrompem uma execução, identificar as degradações lentas que nunca se anunciam, validar a integridade da rede (fabric) em milhares de conexões, programar tarefas considerando hardwares que eventualmente falharão e recuperar-se de forma limpa quando isso acontecer. Muitos desses aspectos são fundamentais, e os problemas mais complexos no topo da pilha dependem deles.

Na Databricks AI, executamos cargas de trabalho de treinamento em escala massiva toda semana, onde falhas surgem continuamente em hardware, rede (fabric) e software. Esta série aborda o que é necessário para manter as GPUs confiáveis nessa escala, começando com a base neste primeiro post: os modos de falha que você encontra ao executar GPUs, as diversas cargas de trabalho que os revelam e o sistema de verificação de integridade (health check) em vários estágios que os detecta. O treinamento é a classe de carga de trabalho mais exigente e o foco aqui, embora a mesma engenharia atenda à inferência e a outras cargas de trabalho de GPU na Databricks.

Como as GPUs falham sob carga de treinamento

A maioria das falhas de GPU em escala se enquadra em três categorias: jobs interrompidos (crashed), lentidões silenciosas e corrupção numérica. Os jobs interrompidos são o caso mais simples, no sentido de que você sabe imediatamente quando ocorrem. As falhas mais difíceis são as cargas de trabalho que terminam com números incorretos no modelo ou que são executadas com desempenho degradado por horas sem que ninguém perceba.

Jobs interrompidos. Os jobs de treinamento distribuído falham por vários motivos: uma GPU se degradando ou desconectando do barramento, problemas na rede (fabric) RDMA, travamento do sistema de E/S (I/O), um rank do lado da CPU divergindo dos outros. Do ponto de vista da carga de trabalho, quase todos esses problemas se manifestam da mesma forma: o job falha com a temida mensagem de NCCL watchdog timeout nos logs. Cada rank bloqueia na mesma coletiva, o watchdog eventualmente encerra o job e você reinicia a partir do último checkpoint. Mas o timeout em si não diz quase nada sobre a causa raiz. Diagnosticar o que realmente deu errado geralmente significa rastrear as camadas de hardware, rede (fabric), sistema de arquivos e software a partir de um rastreamento de pilha (stack trace) que mostra apenas o sintoma.

Lentidões silenciosas. Uma GPU silenciosamente degradada pode continuar progredindo no treinamento, com logs normais e a perda (loss) ainda diminuindo. No entanto, o rendimento (throughput) fica gargalado na GPU mais lenta, desperdiçando computação e dinheiro. Essas lentidões ocorrem devido ao hardware rodando em estado degradado, onde sensores térmicos são acionados sob carga contínua, links de interconexão sofrem downgrade após erros persistentes ou a largura de banda da memória cai à medida que as falhas se acumulam. Cada uma delas se manifestam em diferentes sinais de nível de hardware, por exemplo, motivos de limitação (throttle) do DCGM como HW_SLOWDOWN ou HW_THERMAL_SLOWDOWN para questões térmicas, ou integridade do link para interconexões.

Corrupção numérica. As GPUs modernas usam o Código de Correção de Erros (ECC) para detectar e corrigir automaticamente muitas falhas temporárias de memória sem interromper o treinamento. No entanto, nem todas as falhas podem ser recuperadas. A corrupção pode ter origem na memória, nas interconexões, nos kernels ou nas camadas de software e pode se propagar antes de ser detectada ou contida. Nesses casos, o treinamento pode parar imediatamente ou continuar com valores incorretos. As falhas podem aparecer como perdas (losses) NaN, convergência instável ou regressões na qualidade do modelo que só são descobertas mais tarde.

Nossa abordagem para a confiabilidade de GPUs

As taxas de eventos de falha de hardware de GPU podem ser uma ordem de magnitude maiores do que as de CPUs. Como uma suposição conservadora e simplificada, considere que cada GPU tem uma taxa anualizada de eventos de falha de 1%. Para um job que usa N GPUs ao longo de T dias, a probabilidade de pelo menos um evento é de aproximadamente:

Um job de 256 GPUs executado por 30 dias tem cerca de 19% de chance de apresentar uma falha. Com 1.024 GPUs, essa chance sobe para 57%. Nessa escala, falhas durante uma execução são esperadas, não excepcionais. Como base, dois investimentos de engenharia mantêm o treinamento confiável apesar delas: testes de estresse com cargas de trabalho diversas e de ponta que revelam falhas precocemente, e um sistema de verificação de integridade (health check) em vários estágios que as detecta em toda a frota.

Testando o estresse da plataforma com cargas de trabalho de ponta

A Databricks AI executa uma variedade de cargas de trabalho de treinamento exigentes na mesma plataforma que os clientes usam: treinamento de aprendizado por reforço (RL) para modelos como o KARL, modelos de codificação agentes (agentic coding), sistemas de inteligência de documentos como o que está por trás de PDFs em produção e muito mais. Esses não são jobs de treinamento comuns. As cargas de trabalho de RL combinam treinamento, inferência e cálculo de recompensa em loops estreitos em várias GPUs. Os modelos de codificação agentes realizam avaliações intensivas de inferência junto com o treinamento. Os pipelines de inteligência de documentos combinam o treinamento de modelos com carregamento pesado de dados baseados em imagens.

Cada um deles estressa a plataforma de maneiras distintas, o que os torna eficazes em revelar problemas operacionais, como instabilidade na rede (fabric), pontos quentes térmicos (hotspots) e casos extremos (edge cases) na comunicação coletiva antes que atinjam cargas de trabalho de produção mais amplas.

Veja como foi um problema recente. Uma execução de treinamento falhou com um timeout de NCCL após sete horas de execução. A investigação mostrou que uma única porta InfiniBand usada para coletivas RDMA NCCL caiu uma vez e se recuperou. Ela nunca mais oscilou (flapped). Nossas verificações contínuas de integridade monitoram a oscilação (flapping) de portas IB, mas uma única oscilação isolada normalmente não indica uma porta instável, portanto não ultrapassaria o limite por si só.

A falha ocorreu devido a qual dos dois timeouts do NCCL é acionado primeiro. A maioria das discussões sobre a configuração do NCCL foca no timeout do PyTorch NCCL watchdog, configurável via init_process_group(timeout=...), que encerra uma coletiva travada após uma duração configurável (normalmente 10 minutos). Um segundo timeout fica mais abaixo na pilha e é acionado muito antes dele: o NCCL_IB_TIMEOUT, na camada de transporte InfiniBand, controla quanto tempo uma conexão espera para que uma porta caída se recupere antes de derrubar a conexão. Seu padrão efetivo é de aproximadamente sete segundos, considerando as tentativas, muito mais curto do que a maioria das equipes imagina. Assim que uma única janela de porta caída excede esse tempo, a conexão é perdida e a coletiva já está morta, independentemente de como o timeout do watchdog do PyTorch esteja configurado. Quando o watchdog percebe o travamento, a execução já está destinada a falhar.

O sinal que importa para o impacto no treinamento é o tempo de inatividade (downtime) cumulativo, não a contagem de oscilações (flaps). Uma única oscilação suficientemente longa pode interromper uma execução de treinamento de vários dias, assim como oscilações repetidas ao longo de horas. Ajustamos nossos padrões de NCCL_IB_TIMEOUT para serem mais resilientes, e o mesmo sinal de porta caída nos permite interromper e reiniciar o job a partir de um checkpoint sem deixar as GPUs ociosas até que o watchdog seja acionado. Esta investigação é uma das muitas que alimentam o sistema de verificação de integridade (health check) descrito no restante deste post.

Verificações de integridade (health checks) ao longo do ciclo de vida do nó

Criamos o gpu-monitor as um serviço de observabilidade e verificação de integridade (health check) em vários estágios que roda em cada nó de GPU, cobrindo todo o ciclo de vida do nó. Diferentes categorias de verificação são executadas em diferentes estágios, pois diferentes modos de falha podem ser detectados em condições distintas.

Verificações ativas de inicialização (bootstrap) são executadas quando um nó é provisionado pela primeira vez e novamente toda vez que ele é limpo entre as cargas de trabalho dos clientes. Cada carga de trabalho começa em um nó que acabou de passar pelo conjunto completo de verificações. Elas detectam falhas determinísticas, ou seja, problemas que podem ser revelados de forma confiável por um teste direcionado logo no início. Uma amostra representativa do que o gpu-monitor executa:

• Validação de velocidade de computação e burn-in da GPU
• Conectividade direta (peer-to-peer) de GPU para GPU verificada em cada par (integridade de NVLink e NVSwitch)
• Largura de banda e correção do NCCL all-reduce interno do nó (intra-node)
• Largura de banda da NIC RDMA via loopback local do host
• Integridade das memórias ECC e HBM, incluindo margem (headroom) de remapeamento de linha (row-remap)
• Topologia PCIe e integridade do link
• Diagnósticos do NVIDIA DCGM no nível 2

Qualquer nó que falhar em uma verificação ativa é removido imediatamente da frota antes que qualquer carga de trabalho seja executada nele. Nós com problemas são colocados em quarentena e, em seguida, passam por redefinições e testes rigorosos antes de retornarem à frota ou serem removidos permanentemente.

Verificações contínuas passivas monitoram modos de falha não determinísticos das seções anteriores, falhas que só surgem sob pressão contínua de carga de trabalho. Para isso, o gpu-monitor executa uma segunda camada de verificações em cada nó ativo, como:

• Status da via NVLink (qualquer via que caia é sinalizada)
• Motivos de limitação de clock da GPU (HW_SLOWDOWN, HW_THERMAL_SLOWDOWN, HW_POWER_BRAKE)
• Detecção de porta inativa na malha RDMA (com limite baseado no tempo de inatividade cumulativo, não na contagem de oscilações)
• Erros críticos de XID nos logs do kernel
• Erros não corrigíveis de PCIe AER
• Gradiente térmico entre o núcleo da GPU e a HBM
• Estados de erro do NVSwitch

Os nós que apresentam falhas nas verificações contínuas são isolados, drenados e passam pelo mesmo processo de quarentena que as falhas de verificação de bootstrap ativas.

Verificações ativas periódicas de múltiplos nós validam o comportamento da malha entre nós que nenhum nó individual consegue detectar sozinho. Elas são executadas periodicamente em nós ociosos entre as cargas de trabalho dos clientes para isolar problemas na malha entre nós da degradação de nó único que a camada de bootstrap já detecta. Como essas verificações rodam em nós ociosos e podem sofrer preempção quando as cargas de trabalho dos clientes precisam dos nós, elas podem ser mais custosas do que o que cabe em uma verificação ativa no momento do provisionamento.

Os testes em si incluem sondagens de largura de banda coletiva do NCCL em grupos de nós, varrendo tamanhos de payload de 8 bytes a 2 GiB. Diferentes tamanhos de payload são importantes porque o NCCL aciona diferentes caminhos de código. Mensagens pequenas na faixa de KB passam por protocolos de baixa latência como LL e LL128 e são dominadas pela latência, tornando a latência p95 o critério de aprovação útil. Mensagens médias na faixa de MB cruzam limites onde o NCCL muda os algoritmos de árvore para anel. Mensagens grandes exercitam o particionamento e o pipeline à medida que os limites de largura de banda são atingidos, tornando a BusBW (largura de banda do barramento) o critério de aprovação útil. Problemas de hardware geralmente surgem em apenas um desses caminhos de código. Um resultado representativo das condições que verificamos para a largura de banda de all-reduce em nossa verificação de integridade:

A AlgBW (largura de banda do algoritmo) mede o throughput conforme a carga de trabalho o vê. A BusBW (largura de banda do barramento) considera o fato de que uma operação coletiva como all-reduce move cada byte pela malha várias vezes, refletindo melhor a utilização real do link e a integridade do hardware.

Juntas, as três camadas verificam o hardware antes do início das cargas de trabalho, monitoram-no enquanto elas são executadas e validam a malha mais ampla nos intervalos. À medida que novos modos de falha surgem, incorporamos novas verificações de integridade e distribuímos gpu-monitor para toda a frota.

Conclusão

A confiabilidade da GPU é um sistema cumulativo. Novas gerações de hardware e padrões de carga de trabalho continuam revelando modos de falha que precisam ser integrados de volta às verificações, e cada um deles torna o sistema mais forte. Este post cobriu a base sobre a qual todo o resto se apoia. Os próximos posts desta série partirão dela, abordando o trabalho que mantém o treinamento confiável à medida que as execuções aumentam, as arquiteturas mudam e as cargas de trabalho de RL combinam treinamento e inferência no mesmo loop.

Uma infraestrutura de GPU confiável nessa escala é o que torna possível a próxima geração de produtos de IA. Se a confiabilidade de GPUs em escala é o tipo de problema no qual você deseja trabalhar, estamos contratando!

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original