Verificações de saúde de GPU da Databricks detectam falhas silenciosas em menos de cinco minutos

Executar um trabalho de treinamento com 1.024 GPUs por 30 dias traz 57% de chance de encontrar pelo menos uma falha de hardware. Com 256 GPUs cai para 19%. A Databricks publicou um detalhamento detalhado de sua pilha de confiabilidade de GPU esta semana — o primeiro de uma série — cobrindo classificação de falhas, teste de estresse e verificações de saúde em múltiplos estágios em toda a frota que serve 125 trilhões de tokens por mês.

A Databricks divide falhas de GPU em três categorias. Trabalhos travados são os mais fáceis: um timeout do watchdog NCCL mata a execução imediatamente e o treinamento reinicia do checkpoint. O timeout em si não revela nada sobre a causa subjacente — o diagnóstico requer rastreamento de camadas de hardware, fabric, filesystem e software. Desacelerações silenciosas são mais difíceis. Uma GPU degradada mantém o progresso de treinamento se movendo e a perda tendendo para baixo, mas a taxa de transferência fica limitada no nó mais lento. Os sintomas aparecem em sinais de hardware: razões de throttle DCGM para eventos térmicos, métricas de saúde de link InfiniBand para degradação, contadores de largura de banda de memória enquanto falhas ECC se acumulam. Corrupção numérica é a mais difícil. O ECC captura e corrige muitas falhas transitórias transparentemente, mas quando falha, o treinamento continua com valores incorretos — manifestando-se como perda NaN, convergência instável ou regressões de qualidade de modelo apenas visíveis no tempo de avaliação.

A matemática impulsiona a prioridade. A Databricks modela cada GPU com taxa de falha anualizada de 1%. Em 30 dias, 256 GPUs enfrentam ~19% de chances de pelo menos uma falha; 1.024 GPUs enfrentam ~57%. Estes não são riscos de cauda — são realidade operacional de base. A infraestrutura de treinamento deve ser tolerante a falhas por design, não por exceção.

A Databricks expõe falhas cedo executando cargas de trabalho exigentes no hardware do cliente: aprendizado por reforço para KARL (seu modelo de codificação agêntica), pipelines de avaliação agêntica e sistemas de inteligência de documentos. Cargas de trabalho RL estressam a pilha combinando treinamento, inferência e computação de recompensa em loops apertados em muitas GPUs, atingindo casos extremos de fabric, térmicos e de comunicação coletiva que cargas de trabalho mais leves perdem. Um exemplo recente: uma execução de treinamento falhou com um timeout NCCL após sete horas. A investigação rastreou até uma única porta InfiniBand que havia degradado após uma recuperação — mas não produziu erros registrados. Apenas a queda de taxa de transferência acionou o timeout.

Capturar essas falhas requer investigação em todas as fases do ciclo de vida do nó. A verificação de saúde em múltiplos estágios da Databricks valida o hardware de GPU antes dos trabalhos começarem, monitora degradação silenciosa sob carga e investiga a saúde do fabric NCCL entre nós entre trabalhos. No lado da inferência — roteando tráfego para endpoints Kimi, Qwen, OpenAI, Gemini e Claude — as próprias verificações de saúde falham sob carga pesada: as verificações expiram, matando servidores saudáveis via sondas de vivacidade falsas. A correção: atribuir tráfego de verificação de saúde a prioridade de agendamento mais alta. A recuperação então executa em menos de cinco minutos: detectar travamento, matar servidor não saudável, reiniciar. As mortes falsas caíram de várias por semana para zero.

A figura de 80% do título precisa de precisão. Refere-se a economias de custo de GPU de autoscaling baseado em unidade de modelo versus provisionamento estático, não para MTTR. A alocação de pico estática é insustentável; alocação dinâmica mantém contagens de réplica próximas à demanda real para cargas de trabalho bursty. O ganho de latência real é o ciclo de recuperação sub-cinco-minutos. Ambos os números vêm da mesma plataforma mas resolvem problemas diferentes: eficiência de custo e tolerância a falhas estão vinculadas apenas em que o sobreprovisioning estático não compra confiabilidade.

Equipes de plataforma executando clusters com centenas de GPUs precisam de monitoramento de sinais de hardware — métricas DCGM, saúde de link, largura de banda de memória — não apenas observabilidade de nível de trabalho. Throttling térmico parece um trabalho lento. Uma porta InfiniBand degradada parece barulho. Falhas corrigidas por ECC parecem nada até que se importem. Verificações de saúde são tão boas quanto sua prioridade de agendamento e amplitude de investigação.