AWS adiciona 3 verificações ao treinamento de modelos para detectar erros silenciosos de GPU

O treinamento segue, o gráfico de erro parece normal, as GPUs não reclamam. Mas um acelerador já calculou um número errado, e as demais cópias do modelo o aceitaram na atualização comum. A equipe continua gastando tempo de computação, embora o resultado do treinamento possa ter sido corrompido. A AWS descreveu como procurar essas falhas diretamente no ciclo do PyTorch DDP: repetir parte dos cálculos em outro nó e comparar os resultados.

É uma análise de engenharia útil para equipes que treinam modelos em vários nós com GPU. Ela inclui o código das verificações e o procedimento de recuperação via SageMaker HyperPod. A ideia central vale além de uma nuvem específica: a ausência de alertas de hardware não significa que os cálculos estejam corretos.

Como um erro se torna coletivo

No treinamento com paralelismo de dados, várias cópias do modelo processam diferentes porções de exemplos. Depois, o sistema calcula a média dos gradientes delas — os valores usados para atualizar os pesos. Cada cópia recebe o mesmo valor médio e executa a mesma atualização.

Suponha que três GPUs tenham calculado gradientes de 0,20, 0,40 e 0,30. A média é 0,30. Mas se o segundo acelerador, por causa de uma falha, devolver 4,00 em vez de 0,40, as três cópias receberão uma média já incorreta. Após a atualização, seus pesos continuarão idênticos. Uma simples conferência entre as cópias mostrará que está tudo em ordem, embora o erro já tenha se propagado.

As verificações habituais protegem outras partes do sistema. O controle de memória ajuda a detectar corrupção de dados na memória, e as verificações de rede detectam erros de transmissão. O checksum do modelo salvo confirma a integridade do arquivo. No entanto, um arquivo gravado corretamente pode perfeitamente conter pesos corrompidos por um cálculo anterior.

Como dimensão do problema, a AWS cita dados do treinamento do Llama 3 405B: em 54 dias, a Meta associou seis de 419 interrupções inesperadas à corrupção silenciosa de dados. Essa estatística considera os casos detectados que puderam ser ligados a uma falha e não mostra a frequência de todos os erros imperceptíveis.

Três verificações no ciclo de treinamento

A primeira verificação procura NaN e Inf nos gradientes locais antes da média e, em seguida, confere o resultado da média antes da atualização dos pesos. Assim, é possível interromper o passo antes que um valor claramente incorreto passe a fazer parte do modelo. Mas o número 4,00 parece perfeitamente válido e passará por essa verificação.

Para ele é necessária a segunda verificação: em passos selecionados, cada GPU reprocessa o microbatch de outro nó. Se os mesmos dados e as mesmas condições produzem resultados diferentes, há motivo para investigação. São comparados o valor da função de perda e impressões digitais compactas dos gradientes. Para resolver comparações ambíguas, o esquema exige um terceiro nó.

A terceira verificação atua após a atualização: compara as impressões digitais dos pesos de diferentes cópias do modelo. Se uma cópia diverge de uma maioria estrita, é possível apontar a instância suspeita. A verificação é feita periodicamente e antes de salvar o checkpoint, para não consolidar uma corrupção detectada em mais um salvamento.

Quando há um alerta, a equipe interrompe o treinamento, associa o processo suspeito a um nó e proíbe a alocação de novas tarefas nele. Depois, analisa as métricas, executa diagnósticos se necessário e, após a verificação, substitui o nó. Recomenda-se retomar o treinamento a partir do checkpoint salvo antes do intervalo suspeito.

O que considerar antes de adotar

A AWS testou a solução em quatro nós com 32 NVIDIA H100, injetando erros por software. Os testes também foram repetidos em três nós, o mínimo para o esquema proposto. Esses testes mostram o comportamento das verificações em cenários definidos, mas não provam a detecção de qualquer falha de hardware.

Há também pontos cegos concretos. Um número finito errado dentro da operação de média pode passar por todas as verificações. O recálculo verifica apenas passos selecionados e exige dados reproduzíveis; a comparação de gradientes também depende de cálculos determinísticos. A coincidência de impressões digitais compactas é uma forte evidência de igualdade dos tensores, mas não uma prova matemática.

Conclusão prática: em execuções distribuídas caras, vale verificar os próprios resultados dos cálculos e preparar a recuperação com antecedência. É possível começar verificando NaN e Inf antes da atualização e do salvamento. Depois, medir o custo dos recálculos na sua própria carga e definir a frequência da auditoria. Os checkpoints devem ser guardados fora do nó substituível: seus discos locais são destruídos na substituição.