Comment nous maintenons la fiabilité des GPU au sein de Databricks AI

L'entraînement distribué sur GPU est devenu une pratique courante dans l'industrie. Les équipes entraînent désormais des modèles de fondation, affinent des modèles à très grande échelle, conçoivent de grands systèmes de vision et exécutent des réseaux de recommandation profonds à des échelles qui étaient autrefois réservées aux seuls laboratoires de pointe.

Bâtir une infrastructure GPU capable de répondre aux exigences d'échelle actuelles nécessite de maîtriser de nombreux aspects : détecter les pannes qui interrompent une exécution, identifier les dégradations lentes qui ne se manifestent jamais d'elles-mêmes, valider l'état du réseau d'interconnexion (fabric) sur des milliers de liaisons, planifier les tâches en tenant compte du matériel qui finira par tomber en panne, et assurer une récupération propre lorsque cela se produit. Beaucoup de ces aspects sont fondamentaux, et les problèmes plus complexes situés plus haut dans la pile en dépendent.

Chez Databricks AI, nous exécutons chaque semaine des charges de travail d'entraînement à une échelle massive, où les pannes surviennent continuellement au niveau du matériel, du réseau d'interconnexion et des logiciels. Cette série d'articles présente ce qu'il faut mettre en œuvre pour garantir la fiabilité des GPU à cette échelle, en commençant par les bases dans ce premier article : les modes de défaillance rencontrés lors de l'utilisation de GPU, les diverses charges de travail qui les mettent en évidence et le système de vérification d'état (health check) en plusieurs étapes qui les détecte. L'entraînement est la catégorie de charge de travail la plus exigeante et constitue le sujet principal ici, bien que la même ingénierie serve à l'inférence et à d'autres charges de travail GPU chez Databricks.

Comment les GPU tombent en panne sous une charge d'entraînement

La plupart des pannes de GPU à grande échelle entrent dans trois catégories : les échecs de tâches (crashed jobs), les ralentissements silencieux et la corruption numérique. Les échecs de tâches sont le cas le plus simple, dans la mesure où l'on sait immédiatement quand ils se produisent. Les pannes les plus complexes concernent les charges de travail qui se terminent avec des valeurs erronées dans le modèle, ou qui s'exécutent avec des performances dégradées pendant des heures sans que personne ne s'en aperçoive.

Échecs de tâches. Les tâches d'entraînement distribué échouent pour de nombreuses raisons : un GPU qui se dégrade ou se déconnecte du bus, des problèmes de réseau d'interconnexion RDMA, un blocage du système d'E/S (I/O), ou un rang côté CPU qui diverge des autres. Du point de vue de la charge de travail, presque toutes ces pannes se manifestent de la même manière : l'échec de la tâche avec le redoutable message NCCL watchdog timeout dans les journaux (logs). Chaque rang se bloque sur la même opération collective, le watchdog finit par tuer la tâche, et vous redémarrez à partir du dernier checkpoint. Mais le timeout lui-même ne dit presque rien sur la cause racine. Diagnostiquer ce qui s'est réellement passé implique souvent de remonter à travers les couches matérielles, réseau, système de fichiers et logicielles à partir d'une trace d'appel (stack trace) qui ne montre que le symptôme.

Ralentissements silencieux. Un GPU silencieusement dégradé peut continuer à faire progresser l'entraînement, avec des journaux corrects et une perte (loss) qui continue de diminuer. Cependant, le débit global est limité par le GPU le plus lent, ce qui gaspille de la puissance de calcul et de l'argent. Ces ralentissements proviennent d'un matériel fonctionnant en mode dégradé, où les capteurs thermiques se déclenchent sous une charge prolongée, les liaisons d'interconnexion se dégradent après des erreurs persistantes, ou la bande passante mémoire chute à mesure que les défauts s'accumulent. Chacun de ces phénomènes se manifeste par différents signaux au niveau matériel, par exemple les motifs de limitation (throttle) DCGM comme HW_SLOWDOWN ou HW_THERMAL_SLOWDOWN pour les aspects thermiques, ou l'état des liaisons pour les interconnexions.

Corruption numérique. Les GPU modernes utilisent un code de correction d'erreurs (ECC) pour détecter et corriger automatiquement de nombreux défauts de mémoire transitoires sans interrompre l'entraînement. Cependant, tous les défauts ne peuvent pas être récupérés. La corruption peut provenir de la mémoire, des interconnexions, des noyaux (kernels) ou des couches logicielles, et peut se propager avant d'être détectée ou contenue. Dans ces cas, l'entraînement peut s'arrêter immédiatement ou se poursuivre avec des valeurs incorrectes. Les défaillances peuvent se manifester sous forme de pertes NaN, d'une convergence instable ou de régressions de la qualité du modèle qui ne sont découvertes que plus tard.

Notre approche de la fiabilité des GPU

Le taux de défaillance du matériel GPU peut être supérieur d'un ordre de grandeur à celui des CPU. Selon une estimation prudente et rapide, on peut supposer que chaque GPU présente un taux de défaillance annualisé de 1 %. Pour une tâche utilisant N GPU sur T jours, la probabilité d'au moins un incident est d'environ :

Une tâche utilisant 256 GPU et s'exécutant pendant 30 jours a environ 19 % de chances de subir une défaillance. Avec 1 024 GPU, ce risque grimpe à 57 %. À cette échelle, les pannes en cours d'exécution sont attendues et non exceptionnelles. Pour y faire face, deux investissements techniques majeurs garantissent la fiabilité de l'entraînement : des tests de charge (stress testing) avec des charges de travail diverses et de pointe qui font remonter les pannes rapidement, et un système de contrôle d'intégrité (health check) multi-étape qui les détecte sur l'ensemble du parc de machines.

Tester la plateforme sous charge avec des charges de travail de pointe

Databricks AI exécute une gamme de charges de travail d'entraînement exigeantes sur la même plateforme que celle utilisée par ses clients : l'entraînement par apprentissage par renforcement pour des modèles comme KARL, des modèles de codage agentiels, des systèmes d'intelligence documentaire comme celui derrière PDFs en production, et bien plus encore. Il ne s'agit pas de tâches d'entraînement classiques. Les charges de travail d'apprentissage par renforcement (RL) combinent l'entraînement, l'inférence et le calcul de récompense dans des boucles serrées sur de nombreux GPU. Les modèles de codage agentiels effectuent des évaluations gourmandes en inférence parallèlement à l'entraînement. Les pipelines d'intelligence documentaire combinent l'entraînement de modèles avec un chargement intensif de données d'images.

Chacune d'elles sollicite la plateforme de manière distincte, ce qui permet de mettre en évidence des problèmes opérationnels tels que l'instabilité du réseau d'interconnexion (fabric), les points chauds thermiques et les cas limites dans les communications collectives avant qu'ils n'affectent les charges de travail de production plus larges.

Voici à quoi ressemblait un problème récent. Une exécution d'entraînement a échoué avec un timeout NCCL après sept heures d'exécution. L'investigation a montré qu'un seul port InfiniBand utilisé pour les opérations collectives RDMA NCCL s'était déconnecté une fois avant de se rétablir. Il n'a plus jamais oscillé (flapped). Nos contrôles d'intégrité continus surveillent l'oscillation (flapping) des ports IB, mais une seule oscillation isolée n'indique généralement pas un port défaillant, elle ne franchirait donc pas le seuil à elle seule.

L'échec s'expliquait par celui des deux timeouts NCCL qui se déclenche en premier. La plupart des discussions sur la configuration de NCCL se concentrent sur le timeout du watchdog NCCL de PyTorch, configurable via init_process_group(timeout=...), qui interrompt une opération collective bloquée après une durée configurable (généralement 10 minutes). Un second timeout se situe plus bas dans la pile et se déclenche bien avant lui : NCCL_IB_TIMEOUT, au niveau de la couche de transport InfiniBand, contrôle le temps pendant lequel une connexion attend qu'un port déconnecté se rétablisse avant de couper la connexion. Sa valeur par défaut effective est d'environ sept secondes en tenant compte des tentatives de reconnexion, ce qui est bien plus court que ce que la plupart des équipes imaginent. Dès qu'une interruption de port dépasse cette durée, la connexion est perdue et l'opération collective est déjà interrompue, quelle que soit la configuration du timeout du watchdog PyTorch. Le temps que le watchdog remarque le blocage, l'exécution est déjà condamnée à échouer.

Le signal important pour l'impact sur l'entraînement est le temps d'arrêt cumulé, et non le nombre d'oscillations. Une seule oscillation suffisamment longue peut faire échouer une exécution d'entraînement de plusieurs jours, tout comme des oscillations répétées sur plusieurs heures. Nous avons ajusté nos valeurs par défaut pour NCCL_IB_TIMEOUT afin d'être plus résilients, et ce même signal de port déconnecté nous permet d'interrompre et de redémarrer la tâche à partir d'un checkpoint sans laisser les GPU inactifs en attendant que le watchdog ne se déclenche. Cette investigation fait partie des nombreuses recherches qui alimentent le système de contrôle d'intégrité décrit dans la suite de cet article.

Contrôles d'intégrité tout au long du cycle de vie des nœuds

Nous avons conçu gpu-monitor comme un service d'observabilité et de contrôle d'intégrité multi-étape qui s'exécute sur chaque nœud GPU, couvrant l'ensemble de son cycle de vie. Différentes catégories de contrôles s'exécutent à différentes étapes, car les différents modes de défaillance sont détectables dans des conditions distinctes.

Les contrôles d'initialisation actifs (bootstrap checks) s'exécutent lors de la première mise en service d'un nœud, puis à chaque fois qu'il est nettoyé entre les charges de travail des clients. Chaque charge de travail démarre sur un nœud qui vient de passer avec succès l'ensemble de la suite de tests. Ceux-ci détectent les pannes déterministes, c'est-à-dire les problèmes qui peuvent être mis en évidence de manière fiable par un test ciblé préalable. Voici un échantillon représentatif de ce que gpu-monitor exécute :

• Validation de la vitesse de calcul et du rodage (burn-in) des GPU
• Vérification de la connectivité directe (peer-to-peer) de GPU à GPU pour chaque paire (état de NVLink et NVSwitch)
• Exactitude et bande passante du NCCL all-reduce intra-nœud
• Bande passante de la carte réseau (NIC) RDMA via le bouclage local de l'hôte (loopback)
• Intégrité de la mémoire ECC et HBM, y compris la marge de remappage de lignes (row-remap)
• Topologie PCIe et intégrité des liaisons
• Diagnostics NVIDIA DCGM de niveau 2

Tout nœud échouant à un contrôle actif est immédiatement retiré du parc avant qu'une charge de travail n'y soit exécutée. Les nœuds défaillants sont mis en quarantaine, puis soumis à des réinitialisations et à des tests approfondis avant de réintégrer le parc ou d'être définitivement retirés.

Les contrôles continus passifs surveillent les modes de défaillance non déterministes des sections précédentes, des défaillances qui n'apparaissent que sous une pression de charge de travail soutenue. Pour cela, gpu-monitor exécute une deuxième couche de contrôles sur chaque nœud actif, tels que :

• L'état des voies NVLink (toute interruption de voie est signalée)
• Les motifs de limitation de l'horloge GPU (HW_SLOWDOWN, HW_THERMAL_SLOWDOWN, HW_POWER_BRAKE)
• La détection de panne de port de la matrice RDMA (basée sur un seuil de temps d'arrêt cumulé, et non sur le nombre d'oscillations)
• Les erreurs XID critiques issues des journaux du noyau
• Les erreurs PCIe AER non corrigibles
• Le gradient thermique entre le cœur du GPU et la HBM
• Les états d'erreur NVSwitch

Les nœuds présentant des défaillances lors des contrôles continus sont isolés, vidés et soumis au même processus de quarantaine que ceux qui échouent aux contrôles d'amorçage actifs.

Les contrôles actifs périodiques multi-nœuds valident le comportement de la matrice inter-nœuds qu'aucun nœud individuel ne peut détecter seul. Ils s'exécutent périodiquement sur des nœuds inactifs entre les charges de travail des clients afin d'isoler les problèmes de matrice inter-nœuds de la dégradation d'un nœud unique, déjà détectée par la couche d'amorçage. Comme ces contrôles s'exécutent sur des nœuds inactifs et peuvent être interrompus lorsque les charges de travail des clients ont besoin de ces nœuds, ils peuvent être plus coûteux que ce qui est possible lors d'un contrôle actif au moment du provisionnement.

Les tests eux-mêmes incluent des sondes de bande passante collective NCCL à travers des groupes de nœuds, balayant des tailles de charge utile allant de 8 octets à 2 GiB. Les différentes tailles de charge utile sont importantes car NCCL déclenche des chemins de code différents. Les petits messages de l'ordre du KB passent par des protocoles à faible latence comme LL et LL128 et sont dominés par la latence, ce qui fait de la latence p95 le critère de réussite utile. Les messages moyens de l'ordre du MB franchissent des seuils où NCCL change d'algorithme, passant de l'arborescence à l'anneau. Les grands messages sollicitent le fractionnement et le pipeline à mesure que les limites de bande passante sont atteintes, faisant de la BusBW (bande passante du bus) le critère de réussite utile. Les problèmes matériels ne se manifestent souvent que dans l'un de ces chemins de code. Voici un exemple représentatif des conditions que nous vérifions pour la bande passante all-reduce dans notre contrôle de santé :

L'AlgBW (bande passante de l'algorithme) mesure le débit tel qu'il est perçu par la charge de travail. La BusBW (bande passante du bus) tient compte du fait qu'une opération collective comme all-reduce déplace chaque octet plusieurs fois à travers la matrice, reflétant ainsi mieux l'utilisation réelle des liaisons et la santé du matériel.

Ensemble, ces trois couches vérifient le matériel avant le démarrage des charges de travail, le surveillent pendant leur exécution et valident la matrice globale entre-temps. À mesure que de nouveaux modes de défaillance apparaissent, nous intégrons de nouveaux contrôles de santé et déployons gpu-monitor sur l'ensemble du parc.

Conclusion

La fiabilité des GPU est un système cumulatif. Les nouvelles générations de matériel et les profils de charge de travail font constamment apparaître de nouveaux modes de défaillance qui doivent être intégrés aux contrôles, et chacun d'eux renforce le système. Cet article a présenté les fondations sur lesquelles repose tout le reste. Les prochains articles de cette série s'appuieront sur ces bases pour aborder les travaux qui garantissent la fiabilité de l'entraînement à mesure que les exécutions s'intensifient, que les architectures évoluent et que les charges de travail de RL combinent entraînement et inférence dans la même boucle.

Une infrastructure GPU fiable à cette échelle est ce qui rend possible la prochaine génération de produits d'AI. Si la fiabilité des GPU à grande échelle est le genre de défi que vous souhaitez relever, nous recrutons !

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original