A Netflix publicou detalhes de como mantém suas frotas de GPUs funcionando sob cargas de trabalho de treinamento e inferência de IA em larga escala, tratando falhas de hardware não como um incômodo de infraestrutura, mas como um problema de sistemas distribuídos a ser projetado para contornar. A empresa relata disponibilidade de nós de GPU superior a 99.95% e uma taxa de sucesso de jobs que subiu de aproximadamente 98% para mais de 99.5%, de acordo com o relato da InfoQ sobre o artigo técnico da Netflix.

O problema central, como a InfoQ o descreve, é que um grande job de treinamento pode rodar por semanas em centenas de GPUs com cada worker operando em sincronia — de modo que uma única GPU com falha, um adaptador de rede degradado ou uma máquina lenta pode travar ou arrastar o job inteiro para baixo. Uma verificação de saúde convencional na nuvem confirma que uma máquina virtual está em execução e acessível, mas a Netflix descobriu que isso não diz nada sobre se suas GPUs conseguem de fato sustentar uma carga de trabalho distribuída: uma GPU pode responder normalmente a uma consulta de status e ainda assim falhar assim que a memória é alocada ou um cálculo sustentado começa. Um adaptador de rede pode, da mesma forma, estar presente mas operando com menos links do que o esperado, permitindo que operações coletivas continuem com largura de banda severamente reduzida enquanto parece saudável visto de fora.

A Netflix construiu sua plataforma de computação em GPU sobre o Kubernetes, usando o NVIDIA DCGM para verificações em nível de dispositivo cobrindo erros de GPU, memória, interconexão e condições térmicas, além de verificações sobre o estado e a quantidade de interfaces Elastic Fabric Adapter de alta velocidade. Um agente de nó do Kubernetes traduz essas verificações em condições de nó sobre as quais os controladores podem agir. As verificações são construídas para falhar de forma fechada (fail closed) — se uma ferramenta de diagnóstico trava, o timeout resultante marca a máquina como não saudável em vez de permitir que uma verificação quebrada reporte sucesso silenciosamente — e a Netflix mantém caminhos alternativos via logs do kernel para os casos em que o próprio mecanismo normal de diagnóstico de GPU falha.

A detecção é apenas a primeira metade do design. Os controladores da Netflix respondem de forma progressiva em vez de substituir imediatamente uma máquina inteira: um problema transitório inicialmente apenas bloqueia novos trabalhos enquanto os jobs existentes continuam em execução; se a condição persistir, a máquina é drenada e suas cargas de trabalho são movidas para outro lugar. As opções de remediação vão desde matar um único job problemático ou resetar uma GPU até reiniciar ou substituir totalmente a máquina, e isso se integra com os recursos de auto-reparo de nós do Karpenter, com a Netflix adicionando camadas de políticas sobre quanto tempo tolerar um determinado tipo de falha e quanto do cluster pode ser interrompido de uma só vez.

Como falhas de hardware não podem ser eliminadas, a plataforma de treinamento da Netflix é construída para tornar a recuperação delas barata. Jobs grandes usam checkpointing e workers elásticos, de modo que o treinamento retoma a partir do último checkpoint saudável depois que uma máquina é perdida, com nova tentativa automática em caso de falha — enquanto falhas no nível da aplicação são classificadas separadamente para que o sistema não fique reiniciando cegamente jobs que estão falhando por causa de um bug genuíno de software, e não de hardware. A Netflix também trata o próprio job de treinamento como um sistema distribuído a ser monitorado, buscando não apenas máquinas mortas, mas um único rank lento que arrasta o restante de um job síncrono para baixo — uma GPU não precisa falhar completamente para derrubar o throughput.

No lado da inferência, a Netflix está usando o recurso Multi-Instance GPU da NVIDIA para permitir que cargas de trabalho menores compartilhem uma GPU com isolamento em nível de memória entre tenants, melhorando a utilização em comparação com dedicar uma GPU inteira por carga de trabalho, e a empresa afirma que está trabalhando em direção ao Kubernetes Dynamic Resource Allocation para um posicionamento mais expressivo e ciente de topologia de GPUs, adaptadores de rede e CPUs dentro de uma máquina. O relato da InfoQ também destaca o trabalho paralelo da Meta nessa área: a Meta usa seus próprios diagnósticos de hardware, remediação automatizada, checkpointing e recuperação rápida, com foco em detectar corrupção silenciosa de dados em clusters de IA muito grandes, e a Meta relata que falhas de hardware foram responsáveis por mais de 66% das interrupções de treinamento em sua experiência com o Llama 3 — um número que reforça por que as duas empresas estão investindo tão pesadamente em tratamento de falhas, em vez de apenas comprar mais capacidade.

O que está notavelmente ausente no relato da InfoQ é qualquer número de custo para essa camada de confiabilidade — nenhum dado sobre o tamanho da equipe de engenharia, a sobrecarga de infraestrutura, ou quanto a taxa de falha alternativa teria custado à Netflix em tempo de treinamento desperdiçado. O texto também não especifica o tamanho do cluster, a escala do modelo, ou quais cargas de trabalho (treinamento versus inferência) tiveram qual melhoria, deixando o salto de 98% para 99.5% um tanto indefinido quanto ao escopo.

Para equipes que operam seus próprios grandes clusters de GPU, a lição prática é que verificações de liveness não são verificações de saúde: uma máquina que responde a pings não é o mesmo que uma máquina capaz de sustentar comunicação coletiva em largura de banda total, e fechar essa lacuna exige diagnósticos em nível de dispositivo, timeouts fail-closed e remediação gradual construída diretamente no escalonador, em vez de adicionada posteriormente.