La formation Amazon EKS NVRx réduit la récupération après panne GPU de quelques minutes à quelques secondes

Amazon EKS a intégré NVIDIA NVRx dans une pile d’entraînement reproductible qui a récupéré des pannes GPU injectées en environ 10 à 17 secondes. La conception d’entraînement Amazon EKS NVRx a également maintenu une efficacité des points de contrôle supérieure à 99 % dans certains tests couvrant 16 à 64 GPU H100. Ces résultats remettent en cause une hypothèse coûteuse : une récupération fiable doit nécessairement commencer par le redémarrage des conteneurs ou la reconstruction de l’intégralité du job Kubernetes.

Le système associe PyTorch Fully Sharded Data Parallel, ou FSDP, à trois capacités distinctes de NVRx. Les points de contrôle asynchrones déplacent les écritures de stockage hors de la boucle d’entraînement. Le redémarrage dans le processus reconstruit l’état distribué sans remplacer le processus Python. Le composant ft_launcher démarre de nouveaux workers au sein du job existant après des défaillances plus graves.

L’enjeu important n’oppose donc pas AWS à un autre fournisseur cloud. Il oppose une récupération consciente de l’application à une récupération reposant uniquement sur l’infrastructure. Kubernetes reste responsable de l’ordonnancement et des défaillances au niveau des nœuds, mais NVRx traite les pannes plus près du processus d’entraînement. AWS affirme que cette séparation réduit fortement le temps pendant lequel des GPU coûteux et sains attendent un pair défaillant.

La formation Amazon EKS NVRx déplace la récupération à l’intérieur du job

Le changement central est qu’une défaillance de worker n’a plus besoin de devenir un événement complet du cycle de vie d’un conteneur.

AWS et NVIDIA ont construit l’environnement de référence autour d’Amazon EKS, de groupes de nœuds GPU autogérés et de PyTorch FSDP. Leur benchmark publié utilisait des instances p5.48xlarge, contenant chacune huit GPU NVIDIA H100 avec 80 Go de mémoire.

Le cluster testé est passé de deux à huit nœuds, soit de 16 à 64 GPU. Chaque instance exposait également 32 interfaces Elastic Fabric Adapter pour les communications à haut débit. Amazon FSx for Lustre fournissait un stockage partagé des points de contrôle entre les pods d’entraînement.

NVRx, abréviation de NVIDIA Resiliency Extension, est un package Python qui ajoute des composants de récupération et de point de contrôle aux charges de travail PyTorch. Il ne nécessite ni fork de PyTorch, ni kernels personnalisés, ni recompilation. Les équipes peuvent ajouter ses capacités indépendamment, sans remplacer leur framework d’entraînement complet.

Cette conception modulaire compte, car les performances des points de contrôle et la récupération après panne sont des problèmes distincts. Une charge de travail peut nécessiter des sauvegardes plus rapides sans récupération de processus. Une autre peut avoir besoin d’être protégée contre les plantages de processus tout en conservant son implémentation existante de points de contrôle.

L’architecture de référence traite chaque couche selon l’étendue de sa défaillance. Le redémarrage dans le processus gère les exceptions et les blocages de communication qui laissent l’interpréteur Python actif. ft_launcher gère des événements tels que SIGKILL, les terminaisons par manque de mémoire et certains blocages au niveau du système d’exploitation.

Kubernetes reste la couche externe pour les défaillances qui retirent un nœud entier. Cette approche ressemble à un ensemble de zones de récupération imbriquées. Chaque mécanisme n’intervient que lorsque la défaillance franchit la frontière de la couche située en dessous.

Les pods d’entraînement utilisent des Services Kubernetes headless pour la découverte des pairs. Les workers se trouvent via DNS plutôt que par des adresses IP fixes. Cette organisation aide les workers de remplacement à revenir sans exiger des opérateurs qu’ils réécrivent la configuration du job.

AWS avait précédemment décrit l’entraînement distribué élastique sur EKS avec les outils PyTorch. Le travail autour de NVRx resserre encore la boucle de récupération. Il vise à maintenir un job actif productif lorsque des rangs individuels échouent, se bloquent ou disparaissent.

Cette distinction crée la tension centrale de l’article. Kubernetes peut restaurer l’infrastructure, mais la récupération d’infrastructure ne dispose pas d’une connaissance détaillée de l’état du modèle, des groupes de processus et du calendrier des points de contrôle. NVRx intègre ces décisions dans l’application d’entraînement.

Les points de contrôle bloquants consommaient environ 40 % du temps total

Le premier problème de performance n’était pas le calcul GPU. C’était le temps que chaque rang passait à attendre que les données de point de contrôle atteignent le stockage.

Un point de contrôle synchrone suspend l’entraînement jusqu’à ce que l’état requis du modèle et de l’optimiseur soit écrit. Dans un job FSDP distribué, cette pause affecte chaque rang participant. Les GPU sains restent alloués, mais n’exécutent aucun calcul de propagation avant ou arrière pendant l’écriture.

AWS a indiqué que les points de contrôle synchrones ne produisaient que 57 % à 61 % d’efficacité d’entraînement dans ses tests de mise à l’échelle. Les écritures de stockage prenaient environ 275 secondes, et cette durée est restée globalement constante entre 16 et 64 GPU. L’ajout de capacité de calcul n’a donc pas supprimé cette pause limitée par le stockage.

Les points de contrôle asynchrones de NVRx modifient le chemin d’écriture. Le processus d’entraînement prépare l’état sur le CPU et transmet le travail à un processus d’arrière-plan persistant. Le processus principal retourne ensuite à l’étape d’entraînement suivante tandis que les E/S de stockage se poursuivent.

L’implémentation utilise TorchAsyncCheckpoint et sa méthode async_save(). Avant de lancer une autre sauvegarde, ou avant de quitter, l’application finalise l’opération en attente. Cette coordination empêche qu’un point de contrôle inachevé entre silencieusement en conflit avec le suivant.

Les dictionnaires d’état locaux FSDP renforcent la conception. Chaque rang écrit son propre fragment, évitant une opération all-gather et le goulot d’étranglement d’une écriture unique du rang zéro. La documentation FSDP de PyTorch décrit le modèle de partitionnement plus large qui répartit les paramètres entre les workers participants.

Avec un intervalle de point de contrôle de 1 000 étapes, AWS affirme que les points de contrôle asynchrones NVRx ont atteint 99,2 % d’efficacité d’entraînement sur deux nœuds. L’efficacité a atteint 99,8 % sur huit nœuds. La comparaison synchrone a atteint 60,3 % sur huit nœuds.

Ces chiffres sont des résultats de benchmark communiqués par le fournisseur, et non des garanties pour tous les modèles ou toutes les configurations de stockage. Pourtant, le mécanisme qui les explique est simple. Si le calcul dure plus longtemps que l’écriture de stockage, l’opération d’arrière-plan peut être presque entièrement masquée par un travail d’entraînement utile.

La limite est devenue claire lorsque AWS a augmenté la fréquence des points de contrôle. Sur huit nœuds, avec un point de contrôle toutes les 100 étapes, l’efficacité synchrone est tombée à 14,7 %. L’efficacité asynchrone a également baissé, mais est restée plus élevée, à 29,6 %.

La raison relevait du timing. Cent étapes d’entraînement prenaient environ 280 secondes, tandis que l’écriture du point de contrôle prenait environ 275 secondes. Il ne restait presque aucune fenêtre de calcul disponible pour masquer l’opération de stockage suivante.

C’est la véritable limite des points de contrôle asynchrones NVRx. Les E/S asynchrones peuvent masquer une écriture derrière le calcul, mais elles ne peuvent pas rendre le stockage infiniment rapide. Lorsque les sauvegardes arrivent aussi vite que le système de fichiers peut les terminer, la file d’attente finit par exercer une pression.

Même avec cette contrainte, cette capacité modifie la manière dont les équipes peuvent choisir les intervalles de point de contrôle. Les systèmes synchrones encouragent des points de contrôle moins fréquents, car chaque sauvegarde impose un temps d’inactivité visible. Des sauvegardes peu fréquentes augmentent alors la quantité d’entraînement perdue après une panne.

Les points de contrôle asynchrones atténuent ce compromis. Les équipes peuvent sauvegarder plus souvent lorsqu’un calcul suffisant existe entre les écritures. Un intervalle plus court réduit la distance de retour en arrière, tandis que les E/S chevauchées préservent une plus grande part de l’investissement GPU.

Le résultat n’est pas simplement une API de point de contrôle plus rapide. C’est un équilibre différent entre l’efficacité en régime permanent et la progression récupérable. Cet équilibre gagne en valeur à mesure que les jobs s’allongent et impliquent davantage de composants susceptibles de tomber en panne.

Le redémarrage dans le processus remet en cause le modèle de récupération uniquement par Kubernetes

Le chemin de récupération le plus rapide préserve le processus Python et ne reconstruit que les ressources distribuées endommagées par la panne.

Dans l’implémentation de référence, NVRx enveloppe la fonction principale d’entraînement avec un contrôleur de redémarrage dans le processus. Si une exception prise en charge survient, l’enveloppe interrompt la tentative active et prépare un nouvel appel. Le processus Python externe reste actif tout au long de cette séquence.

NVRx interrompt d’abord le groupe de processus distribué PyTorch endommagé. Il peut collecter des traces de l’enregistreur de vol, arrêter les backends NCCL et détruire le groupe invalide. NCCL est la bibliothèque de communication de NVIDIA pour les opérations collectives entre GPU.

Des contrôles de santé examinent ensuite les ressources associées à chaque rang. Ces contrôles peuvent couvrir le GPU, les connexions NVLink, les interfaces réseau et les échecs répétés d’un rang. Un contrôleur de nouvelles tentatives limite les tentatives de redémarrage et détermine combien de rangs actifs doivent survivre.

Le système réaffecte les rangs survivants dans un groupe contigu et lance un nouveau rendez-vous. La fonction d’entraînement enveloppée recrée son modèle FSDP, charge le dernier point de contrôle et reprend le travail. L’interpréteur Python et les objets situés hors de la fonction enveloppée restent disponibles.

Cette technique vise les défaillances légères. Parmi les exemples figurent les exceptions applicatives non gérées et les blocages NCCL que le watchdog peut détecter. Elle ne suppose pas qu’une exception Python émergera de manière fiable de chaque appel natif bloqué.

À la place, un watchdog de progression enregistre l’activité entre les opérations de bytecode Python. Un thread de surveillance distinct vérifie l’état partagé et peut demander un redémarrage lorsqu’un rang cesse de progresser. Le système coordonne alors l’interruption entre les workers participants.

AWS a comparé cette approche à ft_launcher et à la récupération Kubernetes de base. L’expérience utilisait deux nœuds p5.48xlarge, 16 GPU H100 et Llama 3.1 8B sous FSDP. Le job s’est exécuté pendant 2 000 étapes et a sauvegardé toutes les 500 étapes.

Les chercheurs ont injecté cinq pannes déterministes dans chaque exécution selon le même calendrier. Le redémarrage dans le processus NVRx a récupéré en environ 10 secondes par panne sans redémarrer les conteneurs. AWS a mesuré 31 % de goodput d’entraînement et 87 % de goodput d’infrastructure.

Le goodput d’entraînement mesure le temps qui produit une progression valide de l’entraînement. Le goodput d’infrastructure mesure le temps pendant lequel l’infrastructure allouée reste opérationnelle et disponible. L’écart entre les deux comprend le travail qui ne fait pas avancer le modèle, notamment le retour en arrière et le chargement des points de contrôle.

La récupération Kubernetes de base a pris environ 270 secondes par panne injectée. Elle a produit 11,5 % de goodput d’entraînement et 35,8 % de goodput d’infrastructure dans l’expérience rapportée. Cette comparaison dépasse donc la simple optimisation du démarrage des conteneurs.

Selon AWS, un rang défaillant a déclenché des délais d’expiration de communication sur les rangs survivants. Les pods ont alors redémarré de manière désynchronisée, provoquant des cycles répétés de délais d’expiration et un comportement CrashLoopBackOff. L’orchestrateur a restauré les conteneurs sans comprendre comment le groupe d’entraînement distribué devait récupérer de façon coordonnée.

La récupération consciente de l’application dispose de ce contexte manquant. Elle sait quand la progression s’est arrêtée, quel groupe de processus est devenu invalide et quel point de contrôle peut redémarrer l’entraînement. Kubernetes voit l’état des pods et la santé des nœuds, mais pas la sémantique complète d’une étape d’entraînement FSDP.

Cela ne rend pas la récupération Kubernetes inutile. Un nœud hors service ne peut pas préserver son interpréteur, son état CUDA ou ses processus locaux. Le remplacement des nœuds appartient toujours à la couche cluster, et les workers récupérés nécessitent toujours des données de point de contrôle persistantes.

La pression s’exerce sur les équipes qui comptent sur les redémarrages de pods comme seule politique de tolérance aux pannes. Cette approche reste simple, mais sa fenêtre de récupération peut gaspiller un temps considérable d’accélérateurs. Les clusters plus grands amplifient le coût, car une panne peut immobiliser de nombreux workers par ailleurs sains.

La tolérance aux pannes NVRx sépare les défaillances légères et graves

Aucun mécanisme de redémarrage unique ne couvre toutes les défaillances ; la tolérance aux pannes NVRx sépare donc la récupération qui préserve le processus du remplacement des workers.

Le composant ft_launcher gère les pannes auxquelles un redémarrage dans le processus ne peut pas survivre. Cela inclut les SIGKILL, les arrêts pour manque de mémoire et les échecs qui ne laissent aucun interpréteur Python utilisable. Il remplace torchrun tout en conservant des concepts familiers de rendez-vous.

Chaque rang d’entraînement crée un RankMonitorClient après l’initialisation distribuée. Le client envoie des signaux de vie pendant l’entraînement. Des serveurs de supervision par rang comparent ces signaux aux délais d’expiration configurés pour les conditions normales et le démarrage initial.

La configuration AWS utilisait un délai d’expiration de signal de vie de rang de 900 secondes. Son délai pour le premier signal était de 1 200 secondes, afin d’accorder davantage de temps au chargement initial du modèle. Un intervalle de supervision de cinq secondes déterminait la fréquence à laquelle le lanceur vérifiait l’état des workers.

Ces valeurs sont des exemples de configuration, et non des recommandations universelles. Un délai de signal de vie doit dépasser le plus long retard légitime entre deux signaux. S’il est trop court, des checkpoints lents ou l’initialisation du modèle peuvent être interprétés comme des workers défaillants.

Lorsqu’un worker meurt ou cesse de répondre, ft_launcher termine les workers restants. Il récupère la mémoire GPU, effectue un nouveau rendez-vous et lance de nouveaux processus dans le même job. Les nouveaux workers restaurent l’état depuis le checkpoint le plus récent.

Le guide du lanceur présente le même schéma général dans la stack NeMo RL de NVIDIA. Cette intégration plus large suggère que NVRx est conçu comme une couche de résilience réutilisable, et non comme un utilitaire réservé à EKS.

AWS a mesuré environ 17 secondes de récupération par panne injectée avec ft_launcher. L’exécution rapportée a atteint 25,5 % de goodput d’entraînement et 85,9 % de goodput d’infrastructure. C’était plus lent que la récupération dans le processus, mais bien plus rapide que la référence Kubernetes de 270 secondes.

La différence reflète la quantité d’état préservée par chaque méthode. Le redémarrage dans le processus conserve l’interpréteur et le processus externe actifs. ft_launcher doit créer de nouveaux workers, initialiser l’état distribué, reconstruire le modèle et recharger un checkpoint.

Le chargement des checkpoints peut dominer le délai de récupération à plus grande échelle. Une création de processus plus rapide n’élimine pas la nécessité de lire les fragments du modèle et de l’optimiseur. Le débit du système de fichiers partagé reste donc un élément de la conception de la tolérance aux pannes.

L’architecture d’entraînement NVRx sur Amazon EKS utilisait un système de fichiers FSx for Lustre SCRATCH_2 dans la même zone de disponibilité que ses nœuds GPU. Ce positionnement visait à réduire la latence de lecture des checkpoints. Tous les workers pouvaient accéder au même état persisté après récupération.

Le checkpointing asynchrone NVRx est indépendant des deux chemins de redémarrage. Il réduit le temps d’inactivité lié aux écritures et limite la quantité de progrès exposée au risque. La couche de redémarrage détermine la rapidité avec laquelle les workers reviennent après une panne.

Cette séparation offre davantage de choix aux opérateurs, mais ajoute aussi du travail de définition des politiques. Ils doivent décider quelles exceptions peuvent déclencher une récupération dans le processus, combien de tentatives sont sûres et quels contrôles de santé doivent retirer un rang. Ils doivent également définir les délais de signal de vie et de rendez-vous.

NVIDIA qualifie le projet NVRx d’expérimental et en développement actif. Sa documentation avertit que les fonctionnalités et interfaces peuvent évoluer. Les équipes de production doivent considérer le choix de version et les tests de mise à niveau comme faisant partie du plan de résilience.

AWS a utilisé NVRx 0.4.1 pour reproduire son benchmark. L’article recommande la version 0.6.0 avec une configuration de lanceur actualisée pour un déploiement actuel. Cette distinction de version importe, car les systèmes de tolérance aux pannes se situent directement sur des chemins critiques de démarrage et de récupération.

Un mécanisme de récupération défaillant peut être pire que l’absence d’automatisation s’il redémarre à répétition un job irrécupérable. Les limites de tentatives, la taille minimale du monde et les compteurs de pannes empêchent les boucles illimitées. Les opérateurs ont néanmoins besoin d’alertes distinguant une récupération réussie d’un échec récurrent.

Le résultat de 99 % présente des limites importantes

Le benchmark étaye un mécanisme solide, mais il n’établit pas une efficacité de 99 % pour toutes les charges d’entraînement distribué.

AWS a testé une configuration de modèle principale, Llama 3.1 8B avec PyTorch FSDP, sur des instances p5 basées sur H100. Elle utilisait le réseau EFA et le stockage FSx for Lustre. Des tailles de modèles, chemins de stockage, formats de checkpoints et durées d’étapes différents modifieront la fenêtre de chevauchement.

Le chiffre de 99 % s’applique à l’efficacité du checkpointing asynchrone à des intervalles sélectionnés. Il ne décrit pas le goodput de bout en bout en présence de pannes répétées. Dans les tests de pannes injectées, le goodput d’entraînement restait de 31 % pour la récupération dans le processus et de 25,5 % pour ft_launcher.

Ces résultats inférieurs ne contredisent pas les mesures de checkpointing. Ils répondent à une question différente. L’efficacité asynchrone mesure la surcharge des checkpoints pendant l’entraînement normal, tandis que le goodput inclut l’injection de pannes, le rollback, le chargement et les autres tâches de récupération.

La fréquence des checkpoints présente aussi une limite inévitable. À raison d’un checkpoint toutes les 100 étapes, l’entraînement asynchrone a atteint 29,6 % d’efficacité plutôt que 99 %. Le système de stockage était presque continuellement occupé, car les durées de calcul et d’écriture étaient similaires.

La pression mémoire mérite également une attention particulière. Le checkpointing asynchrone prépare les données en dehors de l’opération GPU immédiate et confie les écritures à un processus d’arrière-plan. Les équipes devraient mesurer la mémoire CPU, la profondeur de file d’attente et l’arriéré de stockage avec leurs dictionnaires d’état réels.

La couverture de récupération constitue une autre limite. Le redémarrage dans le processus ne peut rien faire lorsque le système d’exploitation tue le worker ou que le nœud disparaît. ft_launcher peut remplacer un processus mort, mais dépend toujours du job, du réseau du cluster, du service de rendez-vous et du stockage des checkpoints.

La perte de nœud reste une préoccupation Kubernetes. Une interruption régionale du stockage ou un checkpoint corrompu peut mettre simultanément en échec toutes les couches de récupération. L’architecture réduit le coût de plusieurs pannes courantes, mais ne supprime pas les dépendances partagées.

La détection des pannes peut aussi générer des faux positifs. Une longue phase de compilation, une pause de chargement des données ou un blocage du système de fichiers peut dépasser un délai de signal de vie trop agressif. Le lanceur redémarrerait alors des workers sains et abandonnerait des progrès valides.

Les équipes ont besoin de données de délai spécifiques à leur charge avant d’activer la récupération automatique. Elles devraient capturer les intervalles les plus longs d’initialisation du modèle, de checkpointing, de validation et d’entrée de données. Les tests devraient inclure des pannes durant ces phases, et pas seulement durant une étape d’entraînement régulière.

Le benchmark AWS utilisait des pannes injectées de façon déterministe. Cette approche permet des comparaisons reproductibles, mais les pannes en production sont moins ordonnées. Les clusters réels peuvent connaître simultanément une dégradation réseau, un ralentissement du stockage, des problèmes thermiques et des plantages de processus.

L’implémentation de référence offre aux équipes un point de départ utile pour reproduire la configuration. La reproduction sur d’autres familles d’instances et à d’autres échelles de modèles déterminera dans quelle mesure les avantages rapportés sont transférables.

La complexité opérationnelle est le dernier compromis. La stack comprend des Kubernetes Jobs, la découverte de pairs basée sur DNS, des ressources EFA, du stockage partagé, des wrappers NVRx, des clients de supervision et plusieurs couches de délais d’expiration. Chaque composant crée une nouvelle surface de configuration.

Cette complexité peut rester justifiée lorsqu’une importante flotte de GPU passe des minutes inactive après l’échec d’un seul rang. Des jobs plus modestes peuvent toutefois accepter une stratégie de redémarrage de pod plus simple. Le calcul pertinent est le coût de récupération multiplié par la fréquence des pannes, et non le prestige du benchmark.

Les équipes qui évaluent cette conception devraient suivre à la fois le goodput d’entraînement et celui de l’infrastructure. L’utilisation GPU seule peut sembler saine tandis que le modèle recharge à répétition d’anciens checkpoints. Un tableau de bord utile doit afficher les étapes terminées, la distance de rollback, la fraîcheur des checkpoints et la cause des redémarrages.

Les organisations d’ingénierie ont également besoin d’archives durables de ces expériences. Une base de connaissances d’ingénierie consultable peut relier les modifications de délais, les traces de pannes et les résultats de benchmarks. Ce contexte aide les équipes à éviter de répéter des configurations de récupération qui ont échoué.

Ce qu’il faut surveiller après le benchmark Amazon EKS NVRx

Les prochaines preuves devront montrer si la conception conserve son avantage avec des modèles plus grands, des pannes réelles et les évolutions des versions de NVRx.

Le premier signal sera une reproduction indépendante au-delà de 64 GPU H100. AWS a testé une montée en charge de deux à huit nœuds, mais la fréquence des pannes et les coûts de coordination augmentent avec la taille du cluster. Des résultats sur plusieurs centaines d’accélérateurs révéleraient mieux les limites des rendez-vous et du chargement des checkpoints.

Un test plus vaste devrait rapporter davantage que le temps de récupération moyen. La distribution importe, car de rares récupérations de cinq minutes peuvent dominer l’économie d’une longue exécution. Les rapports devraient inclure la latence de queue, les tentatives de redémarrage échouées et les progrès perdus par incident.

Le deuxième signal est l’adoption au sein des principaux frameworks d’entraînement. NVRx est déjà connecté à des charges PyTorch et apparaît dans la stack logicielle plus large de NVIDIA. Davantage d’intégrations natives réduiraient le volume de code personnalisé de wrappers et de lanceurs que les équipes doivent maintenir.

L’adoption par les frameworks renforcerait l’idée que la tolérance aux pannes NVRx peut devenir une couche applicative standard. Des intégrations fragmentées l’affaibliraient, surtout si chaque framework exige une logique différente pour les délais, les checkpoints et les rendez-vous.

Le troisième signal est constitué de preuves issues de pannes de production non contrôlées. L’injection déterministe de pannes est nécessaire pour comparer, mais les incidents sur le terrain testent des combinaisons que les laboratoires reproduisent rarement. Les opérateurs devraient publier séparément les taux de récupération pour les erreurs GPU, les blocages NCCL, les arrêts OOM et les pertes de nœuds.

Une récupération réussie doit signifier davantage que le redémarrage d’un processus. Le job doit restaurer un état valide, continuer à produire des mises à jour correctes et éviter toute corruption silencieuse des checkpoints. La convergence du modèle après des récupérations répétées mérite le même niveau d’examen que la vitesse de récupération.

Pour les équipes qui envisagent l’entraînement Amazon EKS NVRx dès maintenant, la première étape pratique consiste en un benchmark parallèle contrôlé. Utilisez le modèle réel, la taille de checkpoint, le système de fichiers et la durée d’étape effectifs. Comparez les sauvegardes synchrones, les sauvegardes asynchrones, la récupération par lanceur et la récupération Kubernetes seule selon un même calendrier de pannes.

Ajustez ensuite les intervalles de checkpointing à partir des temps de calcul et de stockage observés. Si un checkpoint prend presque autant de temps que l’intervalle entre deux sauvegardes, le chevauchement asynchrone restera incomplet. Si le calcul offre une fenêtre plus large, l’efficacité rapportée de 99 % devient plus plausible.

Les politiques de récupération devraient commencer par des limites de tentatives prudentes. Enregistrez chaque raison de redémarrage et conservez les traces de diagnostic. Un job qui échoue à répétition sur le même rang ou le même checkpoint nécessite une escalade, et non une boucle de récupération sans fin.

Le travail d’AWS et de NVIDIA rend une conclusion difficile à ignorer. La fiabilité de l’entraînement distribué ne peut pas rester une préoccupation uniquement liée à l’infrastructure. L’application comprend la progression, la validité des checkpoints et l’état du groupe de processus d’une manière qu’un orchestrateur ne possède pas.

Amazon EKS fournit toujours la base essentielle de planification et de remplacement des nœuds. NVRx ajoute une réponse plus rapide à l’intérieur de cette limite. Ensemble, ils proposent une voie crédible pour passer de cycles de récupération de quatre minutes à des redémarrages à l’échelle de la seconde pour plusieurs classes importantes de pannes.

La question ouverte est désormais opérationnelle plutôt que conceptuelle. Les équipes peuvent-elles reproduire ces gains avec leurs propres modèles, systèmes de stockage et schémas de pannes réels ? C’est ce test qui devrait guider le prochain déploiement d’entraînement Amazon EKS NVRx.