Como a Databricks garante a confiabilidade de GPUs em larga escala para IA

A Databricks não está apenas monitorando GPUs, está redefinindo como infraestrutura de IA lida com falhas de baixo nível. O cerne técnico dessa operação é o NCCL_IB_TIMEOUT, um parâmetro crítico do transporte RDMA no NCCL que atua muito antes do watchdog do PyTorch. Enquanto a maioria dos times configura só init_process_group(timeout=...), a Databricks descobriu que o NCCL_IB_TIMEOUT tem um comportamento implícito: por padrão, ele desliga conexões após cerca de sete segundos de inatividade em uma porta InfiniBand, mesmo que o port-down seja único e breve. Isso mata coletivos antes que o timeout do PyTorch sequer entre em cena. A solução não foi aumentar o valor cegamente, mas modelar o tempo de recuperação real da rede e alinhar o NCCL_IB_TIMEOUT com o comportamento observado em hardware de produção.

O sistema gpu-monitor não é um mero dashboard: é um ciclo fechado de detecção, decisão e ação. Ele executa três camadas de verificação, na inicialização (bootstrap), durante a carga (passiva contínua) e entre cargas (multi-nó). Cada camada testa algo distinto: a primeira garante que nenhum nó defeituoso entra em produção; a segunda captura lentidões silenciosas como HW_THERMAL_SLOWDOWN ou degradação de link via DCGM; a terceira valida a integridade do tecido interconectado com probes NCCL em múltiplos tamanhos de payload, porque falhas em mensagens de 8 bytes não aparecem em mensagens de 2 GiB, e vice-versa.

A cobertura anterior de 28/05 sobre 'model units' tratava de abstração de recursos para inference, uma camada de orquestração acima do hardware. Agora, a Databricks desce até o nível do firmware e do driver: o NCCL_IB_TIMEOUT não era mencionado em nenhuma das notícias anteriores, nem sua influência direta em crashes de treinamento distribuído. Também não havia menção ao gpu-monitor como serviço com três estágios de validação, nem à diferenciação entre AlgBW (vista do workload) e BusBW (pressão real sobre o barramento). Isso mostra uma evolução clara: da gestão de unidades lógicas para a engenharia de confiabilidade física de GPU, do que *aloca* para o que *funciona*.

Se você opera treinamento distribuído em escala, o NCCL_IB_TIMEOUT é tão relevante quanto o learning rate: um valor mal ajustado não gera erro visível, mas derruba jobs com falsos positivos de deadlock. Isso impacta diretamente MTTR, custo de compute desperdiçado e confiança nas métricas de convergência. A abordagem da Databricks mostra que confiabilidade em IA não começa com logs ou métricas de aplicação, começa com a leitura correta dos sinais do hardware (DCGM, flapping de portas, throttle reasons) e com a tradução desses sinais em decisões de escalonamento e reinício automático. É menos sobre 'detectar falha' e mais sobre 'evitar que ela se torne incidente'.