The Pulse

AWS descrive controlli per gli errori silenti delle GPU nell’addestramento dell’IA

AWS ha pubblicato un metodo per rilevare la corruzione silente dei dati nei job di addestramento su SageMaker HyperPod. I test hanno utilizzato errori introdotti via software e individuato limiti nella capacità dei controlli di rilevarli.

AI.info Team · · verificato · su 1 fonte ↓ · Pubblicato 12 nov 2026

Tre controlli aggiunti a un ciclo di addestramento dell’IA possono segnalare alcuni errori silenti delle GPU e aiutare a individuare un nodo sospetto da sostituire, secondo un articolo tecnico di Amazon Web Services. AWS ha descritto il metodo per SageMaker HyperPod l’11 novembre, riportando test con errori introdotti via software.

La corruzione silente dei dati si verifica quando l’hardware restituisce un numero plausibile ma errato senza segnalare un errore. Nell’addestramento distribuito, quel valore può finire nei gradienti e nei pesi delle repliche del modello, mentre la funzione di perdita dell’addestramento può continuare ad apparire normale.

HyperPod dispone già di monitoraggio dello stato di salute, controlli approfonditi dello stato di salute e ripristino automatico dei nodi per l’hardware che segnala guasti.

Controlli all’interno del job di addestramento

Il nuovo metodo inserisce tre controlli in un ciclo di addestramento PyTorch DistributedDataParallel, nel quale le repliche si addestrano su porzioni diverse di un batch e condividono i gradienti. È un metodo che i team di addestramento devono implementare, non un’affermazione secondo cui i controlli siano stati abilitati automaticamente per ogni job HyperPod.

Un controllo dei gradienti cerca valori non finiti e overflow, mentre una verifica ad anello mediante riesecuzione fa sì che ogni GPU ricalcoli un piccolo batch proveniente da un altro nodo e ne confronti la perdita e, con kernel deterministici, le impronte dei gradienti. Un confronto delle impronte dei pesi verifica se, dopo un aggiornamento, vi siano differenze nei pesi memorizzati dalle repliche.

La distinzione è importante perché un gradiente errato può essere condiviso tra le repliche: tutte possono applicare lo stesso aggiornamento sbagliato e avere comunque pesi coincidenti. La verifica mediante riesecuzione serve a rilevare valori finiti errati che modificano la perdita o, quando si usano kernel deterministici, un gradiente, in un passaggio di verifica.

Individuare e sostituire un nodo

La procedura di ripristino proposta associa un rank di addestramento sospetto al relativo nodo, interrompe il job e impedisce che nuovi lavori vengano assegnati a quel nodo mentre viene esaminato. Un allarme ambiguo può indurre a effettuare ulteriori controlli prima che un nodo venga sostituito e l’addestramento riprenda da un checkpoint salvato prima dell’intervallo sospetto.

AWS descrive anche un controller che un cliente potrebbe eseguire nel proprio cluster e nel proprio account per automatizzare parti di questa procedura. Per la sostituzione, il controller chiederebbe l’approvazione di una persona prima di chiamare l’API di sostituzione, oppure userebbe un’etichetta sullo stato di salute del nodo se il ripristino automatico dei nodi è abilitato.

Test e limiti

I test hanno utilizzato errori introdotti via software su un cluster HyperPod con quattro istanze ml.p5.48xlarge, per un totale di 32 GPU NVIDIA H100, e hanno ripetuto gli scenari con tre istanze, il minimo richiesto dai controlli. Il modello era un decoder sullo stile di Llama con 953 milioni di parametri, addestrato su dati sintetici.

In uno scenario, un errore persistente introdotto artificialmente è iniziato al passaggio 23; AWS ha riferito che i passaggi da 23 a 29 sono stati applicati prima che una verifica al passaggio 30 identificasse il rank sospetto e interrompesse quel passaggio. Secondo l’articolo, le esecuzioni senza errori non hanno prodotto allarmi in 15.320 passaggi di verifica e 3.080 controlli dei pesi.

I controlli hanno comportato un aumento dei tempi in una misurazione effettuata usando lo stesso modello e 32 GPU. In quella configurazione, le verifiche deterministiche ogni 10 passaggi hanno aumentato del 34,7% il tempo medio per passaggio rispetto a un ciclo di addestramento semplice, con controlli dei pesi anch’essi eseguiti ogni 10 passaggi. Le verifiche con kernel predefiniti allo stesso intervallo lo hanno aumentato del 12,5%, hanno riferito gli autori.

Gli autori hanno riferito che un errore nel gradiente dei pesi limitato alla fase backward non ha prodotto alcun allarme in 50 passaggi con verifiche basate su kernel predefiniti. Un errore finito che si verifica una sola volta in un passaggio senza verifica e non si ripete non viene rilevato dalla verifica mediante riesecuzione. Le verifiche deterministiche possono inoltre non rilevare un errore confinato ai kernel predefiniti usati negli altri passaggi.

L’articolo elenca l’accumulo dei gradienti, BatchNorm, i parametri inutilizzati e i forward hook con effetti collaterali tra i casi non testati nell’esempio. Precisa che il ciclo di addestramento e i controlli sono stati testati solo con DistributedDataParallel.