L’addestramento NVRx su Amazon EKS riduce il recupero dai guasti GPU da minuti a secondi

Amazon EKS ha integrato NVIDIA NVRx in uno stack di addestramento riproducibile che ha recuperato guasti GPU iniettati in circa 10-17 secondi. Il design dell’addestramento Amazon EKS NVRx ha inoltre mantenuto l’efficienza dei checkpoint sopra il 99% in test selezionati da 16 a 64 GPU H100. Questi risultati mettono in discussione un presupposto costoso: un recupero affidabile debba iniziare riavviando i container o ricostruendo l’intero job Kubernetes.

Il sistema combina PyTorch Fully Sharded Data Parallel, o FSDP, con tre funzionalità distinte di NVRx. Il checkpointing asincrono sposta le scritture sullo storage fuori dal ciclo di addestramento. Il riavvio in-process ricostruisce lo stato distribuito senza sostituire il processo Python. Il componente ft_launcher avvia nuovi worker all’interno del job esistente dopo guasti più gravi.

La sfida importante, quindi, non è AWS contro un altro provider cloud. È il recupero consapevole dell’applicazione contro il recupero basato esclusivamente sull’infrastruttura. Kubernetes resta responsabile della pianificazione e dei guasti a livello di nodo, ma NVRx gestisce i problemi più vicini al processo di addestramento. AWS afferma che questa separazione riduce drasticamente il tempo in cui GPU sane e costose restano in attesa di un peer guasto.

L’addestramento NVRx su Amazon EKS porta il recupero all’interno del job

Il cambiamento centrale è che il guasto di un worker non deve più trasformarsi in un evento completo del ciclo di vita del container.

AWS e NVIDIA hanno costruito l’ambiente di riferimento attorno ad Amazon EKS, gruppi di nodi GPU autogestiti e PyTorch FSDP. Il loro benchmark pubblicato ha utilizzato istanze p5.48xlarge, ciascuna con otto GPU NVIDIA H100 dotate di 80 GB di memoria.

Il cluster testato è passato da due a otto nodi, ovvero da 16 a 64 GPU. Ogni istanza esponeva inoltre 32 interfacce Elastic Fabric Adapter per comunicazioni ad alta larghezza di banda. Amazon FSx for Lustre forniva storage condiviso per i checkpoint tra i pod di addestramento.

NVRx, abbreviazione di NVIDIA Resiliency Extension, è un pacchetto Python che aggiunge componenti di recupero e checkpointing ai carichi di lavoro PyTorch. Non richiede un fork di PyTorch, kernel personalizzati o ricompilazione. I team possono adottarne le funzionalità in modo indipendente, senza sostituire l’intero framework di addestramento.

Questo design modulare è importante perché le prestazioni dei checkpoint e il recupero dai guasti sono problemi diversi. Un carico di lavoro può richiedere salvataggi più rapidi senza recupero del processo. Un altro può avere bisogno di protezione dai crash del processo mantenendo l’implementazione dei checkpoint esistente.

L’architettura di riferimento tratta ogni livello in base all’ambito del guasto. Il riavvio in-process gestisce eccezioni e blocchi della comunicazione che lasciano attivo l’interprete Python. ft_launcher gestisce eventi quali SIGKILL, terminazioni per memoria esaurita e alcuni blocchi a livello di sistema operativo.

Kubernetes rimane il livello esterno per i guasti che eliminano un intero nodo. Questo approccio ricorda una serie di zone di recupero annidate. Ogni meccanismo interviene solo quando il guasto supera il confine del livello sottostante.

I pod di addestramento usano Kubernetes Services headless per la scoperta dei peer. I worker si trovano tramite DNS anziché tramite indirizzi IP fissi. Questa configurazione aiuta i worker sostitutivi a rientrare senza richiedere agli operatori di riscrivere la configurazione del job.

AWS aveva già descritto l’addestramento distribuito elastico su EKS utilizzando strumenti PyTorch. Il lavoro su NVRx restringe ulteriormente il ciclo di recupero. Si concentra sul mantenere produttivo un job attivo quando singoli rank falliscono, si bloccano o scompaiono.

Questa distinzione crea la tensione centrale dell’articolo. Kubernetes può ripristinare l’infrastruttura, ma il recupero dell’infrastruttura non conosce in dettaglio lo stato del modello, i gruppi di processi e la tempistica dei checkpoint. NVRx porta queste decisioni nell’applicazione di addestramento.

I checkpoint bloccanti consumavano circa il 40% del tempo totale

Il primo problema di prestazioni non era il calcolo GPU. Era il tempo che ogni rank trascorreva aspettando che i dati del checkpoint raggiungessero lo storage.

Un checkpoint sincrono mette in pausa l’addestramento finché lo stato richiesto del modello e dell’ottimizzatore non è stato scritto. In un job FSDP distribuito, quella pausa coinvolge ogni rank partecipante. Le GPU sane rimangono allocate, ma non eseguono calcoli forward o backward durante la scrittura.

AWS ha riferito che il checkpointing sincrono ha prodotto solo dal 57% al 61% di efficienza di addestramento nei suoi test di scalabilità. Le scritture sullo storage richiedevano circa 275 secondi e questa durata è rimasta sostanzialmente costante tra 16 e 64 GPU. Aggiungere capacità di calcolo non eliminava quindi la pausa vincolata allo storage.

Il checkpointing asincrono NVRx modifica il percorso di scrittura. Il processo di addestramento prepara lo stato sulla CPU e passa il lavoro a un processo persistente in background. Il processo principale torna quindi al passaggio di addestramento successivo mentre l’I/O dello storage continua.

L’implementazione utilizza TorchAsyncCheckpoint e il relativo metodo async_save(). Prima di avviare un altro salvataggio, o prima dell’uscita, l’applicazione finalizza l’operazione in sospeso. Questo coordinamento impedisce che un checkpoint non completato entri silenziosamente in conflitto con il successivo.

I dizionari di stato locali FSDP rafforzano il design. Ogni rank scrive il proprio shard, evitando un’operazione all-gather e il collo di bottiglia di una singola scrittura dal rank zero. La documentazione FSDP di PyTorch descrive il più ampio modello di sharding che distribuisce i parametri tra i worker partecipanti.

Con un intervallo di checkpoint di 1.000 passaggi, AWS afferma che il checkpointing asincrono NVRx ha raggiunto il 99,2% di efficienza di addestramento su due nodi. L’efficienza ha raggiunto il 99,8% su otto nodi. Il confronto sincrono ha raggiunto il 60,3% su otto nodi.

Queste cifre sono risultati di benchmark riportati dal fornitore, non garanzie per ogni modello o configurazione di storage. Tuttavia, il meccanismo alla base è semplice. Se il calcolo dura più della scrittura sullo storage, l’operazione in background può essere quasi interamente nascosta dietro un lavoro di addestramento utile.

Il limite è diventato chiaro quando AWS ha aumentato la frequenza dei checkpoint. Su otto nodi e con un checkpoint ogni 100 passaggi, l’efficienza sincrona è scesa al 14,7%. Anche l’efficienza asincrona è diminuita, ma è rimasta superiore, al 29,6%.

Il motivo era la tempistica. Cento passaggi di addestramento richiedevano circa 280 secondi, mentre la scrittura del checkpoint ne richiedeva circa 275. Rimaneva quasi nessuna finestra di calcolo disponibile per nascondere la successiva operazione sullo storage.

Questo è il vero limite del checkpointing asincrono NVRx. L’I/O asincrono può nascondere una scrittura dietro il calcolo, ma non può rendere lo storage infinitamente veloce. Quando i salvataggi arrivano con la stessa rapidità con cui il filesystem riesce a completarli, la coda finisce per esercitare pressione.

Anche con questo vincolo, la funzionalità cambia il modo in cui i team possono scegliere gli intervalli dei checkpoint. I sistemi sincroni incoraggiano checkpoint meno frequenti perché ogni salvataggio impone un tempo di inattività visibile. Salvataggi poco frequenti aumentano poi la quantità di addestramento persa dopo un guasto.

Il checkpointing asincrono attenua questo compromesso. I team possono salvare più spesso quando esiste calcolo sufficiente tra una scrittura e l’altra. Un intervallo più breve riduce la distanza di rollback, mentre l’I/O sovrapposto preserva una quota maggiore dell’investimento nelle GPU.

Il risultato non è semplicemente un’API di checkpoint più veloce. È un diverso equilibrio tra efficienza a regime e avanzamento recuperabile. Questo equilibrio diventa più prezioso man mano che i job si allungano e coinvolgono più componenti soggetti a guasti.

Il riavvio in-process mette in discussione il modello di recupero basato solo su Kubernetes

Il percorso di recupero più rapido preserva il processo Python e ricostruisce soltanto le risorse distribuite danneggiate dal guasto.

Nell’implementazione di riferimento, NVRx avvolge la funzione principale di addestramento con un controller di riavvio in-process. Se si verifica un’eccezione supportata, il wrapper interrompe il tentativo attivo e prepara un’altra chiamata. Il processo Python esterno rimane attivo per tutta la sequenza.

NVRx interrompe innanzitutto il gruppo di processi distribuito PyTorch danneggiato. Può raccogliere tracce del flight recorder, arrestare i backend NCCL e distruggere il gruppo non valido. NCCL è la libreria di comunicazione NVIDIA per operazioni collettive tra GPU.

I controlli di integrità esaminano quindi le risorse associate a ciascun rank. Questi controlli possono includere GPU, connessioni NVLink, interfacce di rete e guasti ripetuti dei rank. Un controller di retry limita i tentativi di riavvio e determina quanti rank attivi devono sopravvivere.

Il sistema riassegna i rank sopravvissuti a un gruppo contiguo e avvia un nuovo rendezvous. La funzione di addestramento avvolta ricrea il proprio modello FSDP, carica il checkpoint più recente e riprende il lavoro. L’interprete Python e gli oggetti al di fuori della funzione avvolta restano disponibili.

Questa tecnica punta ai guasti soft. Gli esempi includono eccezioni applicative non gestite e blocchi NCCL che il watchdog può rilevare. Non presume che un’eccezione Python emerga in modo affidabile da ogni chiamata nativa bloccata.

Invece, un watchdog di avanzamento registra l’attività tra le operazioni di bytecode Python. Un thread di monitoraggio separato verifica lo stato condiviso e può richiedere un riavvio quando un rank smette di progredire. Il sistema coordina quindi l’interruzione tra i worker partecipanti.

AWS ha confrontato questo approccio con ft_launcher e con il recupero Kubernetes di base. L’esperimento ha utilizzato due nodi p5.48xlarge, 16 GPU H100 e Llama 3.1 8B con FSDP. Il job è stato eseguito per 2.000 passaggi e ha salvato ogni 500 passaggi.

I ricercatori hanno iniettato cinque guasti deterministici in ogni esecuzione usando la stessa pianificazione. Il riavvio in-process NVRx ha recuperato in circa 10 secondi per guasto senza riavviare i container. AWS ha misurato il 31% di training goodput e l’87% di infrastructure goodput.

Il training goodput misura il tempo che produce validi progressi di addestramento. L’infrastructure goodput misura il tempo in cui l’infrastruttura allocata rimane operativa e disponibile. Il divario tra i due include il lavoro che non fa avanzare il modello, compresi rollback e caricamento dei checkpoint.

Il recupero Kubernetes di base ha richiesto circa 270 secondi per ogni guasto iniettato. Ha prodotto l’11,5% di training goodput e il 35,8% di infrastructure goodput nell’esperimento riportato. Il confronto va quindi oltre un’ottimizzazione dell’avvio dei container.

Secondo AWS, il guasto di un rank ha attivato timeout di comunicazione sui rank sopravvissuti. I pod si sono poi riavviati in modo non sincronizzato, causando cicli ripetuti di timeout e comportamento CrashLoopBackOff. L’orchestratore ha ripristinato i container senza comprendere come il gruppo di addestramento distribuito dovesse recuperare nel suo insieme.

Il recupero consapevole dell’applicazione ha accesso a questo contesto mancante. Sa quando l’avanzamento si è fermato, quale gruppo di processi è diventato non valido e quale checkpoint può riavviare l’addestramento. Kubernetes vede lo stato dei pod e l’integrità dei nodi, ma non la semantica completa di un passaggio di addestramento FSDP.

Questo non rende superfluo il recupero Kubernetes. Un nodo morto non può preservare il proprio interprete, lo stato CUDA o i processi locali. La sostituzione dei nodi resta di competenza del livello cluster e i worker recuperati richiedono comunque dati di checkpoint persistenti.

La pressione ricade sui team che si affidano ai riavvii dei pod come unica politica di tolleranza ai guasti. Questo approccio resta semplice, ma la sua finestra di recupero può sprecare molto tempo degli acceleratori. I cluster più grandi amplificano il costo perché un singolo guasto può lasciare inattivi molti worker altrimenti sani.

La tolleranza ai guasti NVRx separa guasti soft e hard

Nessun singolo meccanismo di riavvio copre ogni guasto, quindi la tolleranza ai guasti NVRx separa il recupero che preserva il processo dalla sostituzione dei worker.

Il componente ft_launcher gestisce i guasti a cui il riavvio in-process non può sopravvivere. Tra questi rientrano SIGKILL, terminazioni per memoria insufficiente e malfunzionamenti che non lasciano alcun interprete Python utilizzabile. Sostituisce torchrun mantenendo al contempo concetti di rendezvous familiari.

Ogni rank di training crea un RankMonitorClient dopo l'inizializzazione distribuita. Il client invia heartbeat durante l'addestramento. I server di monitoraggio per rank confrontano tali segnali con timeout configurati per le condizioni normali e di avvio iniziale.

La configurazione AWS utilizzava un timeout heartbeat del rank di 900 secondi. Il timeout per l'heartbeat iniziale era di 1.200 secondi, concedendo più tempo al primo caricamento del modello. Un intervallo di monitoraggio di cinque secondi regolava la frequenza con cui il launcher controllava lo stato dei worker.

Questi valori sono esempi di configurazione, non raccomandazioni universali. Un timeout heartbeat deve superare il ritardo legittimo più lungo tra i segnali. Se è troppo breve, checkpoint lenti o l'inizializzazione del modello possono sembrare worker guasti.

Quando un worker termina o smette di rispondere, ft_launcher arresta i worker rimanenti. Recupera la memoria GPU, esegue un altro rendezvous e avvia nuovi processi nello stesso job. I nuovi worker ripristinano lo stato dal checkpoint più recente.

La guida al launcher mostra lo stesso schema generale nello stack NeMo RL di NVIDIA. Questa integrazione più ampia suggerisce che NVRx sia pensato come livello di resilienza riutilizzabile, non come utility esclusiva di EKS.

AWS ha misurato circa 17 secondi di ripristino per ogni guasto iniettato con ft_launcher. L'esecuzione riportata ha raggiunto un goodput di training del 25,5% e un goodput dell'infrastruttura dell'85,9%. Era più lento del ripristino in-process, ma molto più rapido del riferimento Kubernetes di 270 secondi.

La differenza riflette quanta parte dello stato ciascun metodo preserva. Il riavvio in-process mantiene attivi l'interprete e il processo esterno. ft_launcher deve creare nuovi worker, inizializzare lo stato distribuito, ricostruire il modello e ricaricare un checkpoint.

Il caricamento dei checkpoint può dominare l'intervallo di ripristino su scale maggiori. Una creazione più rapida dei processi non elimina la necessità di leggere gli shard del modello e dell'ottimizzatore. Il throughput del filesystem condiviso resta quindi parte integrante della progettazione della tolleranza ai guasti.

L'architettura di training NVRx su Amazon EKS utilizzava un filesystem FSx for Lustre SCRATCH_2 nella stessa Availability Zone dei nodi GPU. Questa collocazione mirava a ridurre la latenza di lettura dei checkpoint. Dopo il ripristino, tutti i worker potevano accedere allo stesso stato persistente.

Il checkpointing asincrono NVRx è indipendente da entrambi i percorsi di riavvio. Riduce il tempo inattivo legato alle scritture e controlla quanta parte dei progressi è a rischio. Il livello di riavvio determina la rapidità con cui i worker tornano operativi dopo un guasto.

Questa separazione offre agli operatori più opzioni, ma aggiunge anche lavoro sulle policy. Devono decidere quali eccezioni possono attivare il ripristino in-process, quanti tentativi siano sicuri e quali controlli di integrità debbano rimuovere un rank. Devono inoltre impostare i timeout di heartbeat e rendezvous.

NVIDIA definisce il progetto NVRx sperimentale e in sviluppo attivo. La sua documentazione avverte che funzionalità e interfacce possono cambiare. I team di produzione dovrebbero considerare la scelta della versione e i test di aggiornamento parte del piano di resilienza.

AWS ha utilizzato NVRx 0.4.1 per riprodurre il proprio benchmark. Il post raccomanda la versione 0.6.0 con una configurazione del launcher aggiornata per un deployment attuale. Questa distinzione tra versioni è importante perché i sistemi di tolleranza ai guasti operano direttamente nei percorsi critici di avvio e ripristino.

Un meccanismo di ripristino fallito può essere peggiore dell'assenza di automazione se riavvia ripetutamente un job irrecuperabile. Limiti ai tentativi, dimensione minima del world e contatori dei guasti impediscono cicli illimitati. Gli operatori necessitano comunque di avvisi che distinguano un ripristino riuscito da un errore ricorrente.

Il risultato del 99% ha limiti importanti

Il benchmark supporta un meccanismo solido, ma non dimostra un'efficienza del 99% per ogni workload di training distribuito.

AWS ha testato una configurazione principale del modello, Llama 3.1 8B con PyTorch FSDP, su istanze p5 basate su H100. Ha utilizzato networking EFA e storage FSx for Lustre. Dimensioni di modello, percorsi di storage, formati dei checkpoint e durate degli step differenti modificheranno la finestra di sovrapposizione.

Il valore del 99% si applica all'efficienza del checkpoint asincrono a intervalli selezionati. Non descrive il goodput end-to-end in presenza di guasti ripetuti. Nei test con guasti iniettati, il goodput di training è rimasto al 31% per il ripristino in-process e al 25,5% per ft_launcher.

Questi risultati inferiori non contraddicono le misurazioni dei checkpoint. Rispondono a una domanda diversa. L'efficienza asincrona misura l'overhead dei checkpoint durante il training ordinario, mentre il goodput include iniezione di guasti, rollback, caricamento e altre attività di ripristino.

Anche la frequenza dei checkpoint ha un limite inevitabile. Con un checkpoint ogni 100 step, il training asincrono ha raggiunto un'efficienza del 29,6% anziché del 99%. Il sistema di storage era occupato quasi continuamente perché le durate di calcolo e scrittura erano simili.

Anche la pressione sulla memoria merita attenzione. Il checkpointing asincrono prepara i dati al di fuori dell'operazione GPU immediata e affida a un processo in background le scritture. I team dovrebbero misurare memoria CPU, profondità della coda e backlog dello storage sui propri dizionari di stato reali.

La copertura del ripristino è un altro limite. Il riavvio in-process non può aiutare quando il sistema operativo termina il worker o il nodo scompare. ft_launcher può sostituire un processo terminato, ma dipende comunque dal job, dalla rete del cluster, dal servizio di rendezvous e dall'archivio dei checkpoint.

La perdita di nodi resta una preoccupazione di Kubernetes. Un'interruzione dello storage regionale o un checkpoint corrotto possono compromettere contemporaneamente ogni livello di ripristino. L'architettura riduce i costi di diversi guasti comuni, ma non elimina le dipendenze condivise.

Il rilevamento dei guasti può anche generare falsi positivi. Una lunga fase di compilazione, una pausa nel caricamento dei dati o uno stallo del filesystem potrebbero superare un timeout heartbeat aggressivo. Il launcher riavvierebbe quindi worker sani e scarterebbe progressi validi.

I team necessitano di dati sui timeout specifici del workload prima di abilitare il ripristino automatico. Dovrebbero rilevare gli intervalli più lunghi per inizializzazione del modello, checkpoint, validazione e input dei dati. I test dovrebbero includere guasti durante queste fasi, non soltanto guasti all'interno di uno step di training regolare.

Il benchmark AWS ha utilizzato guasti deterministici iniettati. Questo approccio consente confronti ripetibili, ma i guasti in produzione sono meno ordinati. I cluster reali possono subire contemporaneamente degrado della rete, rallentamento dello storage, problemi termici e crash dei processi.

L'implementazione di riferimento offre ai team un punto di partenza utile per riprodurre la configurazione. La riproduzione su famiglie di istanze e scale di modello diverse determinerà quanto siano trasferibili i vantaggi riportati.

La complessità operativa è l'ultimo compromesso. Lo stack include Kubernetes Jobs, individuazione dei peer basata su DNS, risorse EFA, storage condiviso, wrapper NVRx, client di monitoraggio e più livelli di timeout. Ogni componente crea un'ulteriore superficie di configurazione.

Questa complessità può comunque essere giustificata quando una grande flotta di GPU rimane inattiva per minuti dopo il guasto di un rank. Tuttavia, job più piccoli potrebbero accettare una strategia più semplice di riavvio dei pod. Il calcolo rilevante è il costo di ripristino moltiplicato per la frequenza dei guasti, non il prestigio del benchmark.

I team che valutano il design dovrebbero monitorare sia il goodput di training sia quello dell'infrastruttura. Il solo utilizzo delle GPU può apparire sano mentre il modello ricarica ripetutamente checkpoint precedenti. Una dashboard utile deve mostrare step completati, distanza di rollback, aggiornamento dei checkpoint e causa del riavvio.

Le organizzazioni ingegneristiche necessitano inoltre di registri duraturi di questi esperimenti. Una base di conoscenza ingegneristica ricercabile può collegare modifiche ai timeout, tracce dei guasti e risultati dei benchmark. Questo contesto aiuta i team a evitare di ripetere configurazioni di ripristino non riuscite.

Cosa osservare dopo il benchmark Amazon EKS NVRx

Le prossime evidenze dovrebbero mostrare se il design conserva il proprio vantaggio con modelli più grandi, guasti reali e versioni NVRx in evoluzione.

Il primo segnale è una riproduzione indipendente oltre 64 GPU H100. AWS ha testato la scalabilità da due a otto nodi, ma la frequenza dei guasti e i costi di coordinamento crescono con la dimensione del cluster. Risultati su centinaia di acceleratori esporrebbero meglio i limiti del rendezvous e del caricamento dei checkpoint.

Un test più ampio dovrebbe riportare più del tempo medio di ripristino. La distribuzione è importante, perché rari ripristini di cinque minuti possono dominare l'economia di un'esecuzione lunga. I report dovrebbero includere latenza di coda, tentativi di riavvio falliti e progressi persi per incidente.

Il secondo segnale è l'adozione nei principali framework di training. NVRx si collega già a workload basati su PyTorch e compare nello stack software più ampio di NVIDIA. Più integrazioni native ridurrebbero la quantità di codice personalizzato per wrapper e launcher che i team devono mantenere.

L'adozione da parte dei framework rafforzerebbe l'ipotesi che la tolleranza ai guasti NVRx possa diventare un livello applicativo standard. Integrazioni frammentate la indebolirebbero, soprattutto se ogni framework richiedesse logiche diverse per timeout, checkpoint e rendezvous.

Il terzo segnale è costituito dalle evidenze di guasti in produzione non controllati. L'iniezione deterministica dei guasti è necessaria per il confronto, ma gli incidenti sul campo testano combinazioni che i laboratori raramente riproducono. Gli operatori dovrebbero pubblicare separatamente i tassi di ripristino per errori GPU, stalli NCCL, terminazioni OOM e perdita dei nodi.

Un ripristino riuscito dovrebbe significare più del semplice riavvio di un processo. Il job deve ripristinare uno stato valido, continuare a produrre aggiornamenti corretti ed evitare una corruzione silenziosa dei checkpoint. La convergenza del modello dopo ripristini ripetuti merita la stessa attenzione della velocità di ripristino.

Per i team che stanno considerando ora il training Amazon EKS NVRx, il primo passo pratico è un benchmark shadow controllato. Utilizzate il modello reale, la dimensione del checkpoint, il filesystem e la durata dello step. Confrontate salvataggi sincroni, salvataggi asincroni, ripristino tramite launcher e ripristino esclusivamente Kubernetes secondo un unico programma di guasti.

Quindi regolate gli intervalli dei checkpoint utilizzando i tempi di calcolo e storage osservati. Se un checkpoint richiede quasi quanto l'intervallo tra i salvataggi, la sovrapposizione asincrona rimarrà incompleta. Se il calcolo offre una finestra più ampia, l'efficienza riportata del 99% diventa più plausibile.

Le policy di ripristino dovrebbero iniziare con limiti prudenti ai tentativi. Registrate ogni motivo di riavvio e conservate le tracce diagnostiche. Un job che fallisce ripetutamente sullo stesso rank o checkpoint richiede escalation, non un ciclo di ripristino infinito.

Il lavoro di AWS e NVIDIA rende difficile ignorare una conclusione. L'affidabilità del training distribuito non può restare soltanto una questione infrastrutturale. L'applicazione comprende progressi, validità dei checkpoint e stato del gruppo di processi in modi che un orchestratore non possiede.

Amazon EKS fornisce comunque la base essenziale per scheduling e sostituzione dei nodi. NVRx aggiunge una risposta più rapida entro tale perimetro. Insieme, offrono un percorso credibile dai cicli di ripristino di quattro minuti ai riavvii nell'ordine dei secondi per diverse classi importanti di guasti.

La questione aperta è ora operativa, non concettuale. I team possono riprodurre questi vantaggi con i propri modelli, sistemi di storage e reali schemi di guasto? È questo il test che dovrebbe guidare il prossimo deployment di training Amazon EKS NVRx.