Configuration de l’infrastructure et scripts open source pour entraîner un modèle 70B sur du bare metal

 (imbue.com)
1 points par GN⁺ 2024-06-29 | 1 commentaires | Partager sur WhatsApp
  • Imbue a entraîné pendant plusieurs mois un modèle de 70B de paramètres à partir de zéro sur sa propre infrastructure bare metal avec une petite équipe, et a publié ses procédures opérationnelles et ses scripts, de la construction du cluster à la reprise après incident
  • Le cluster était composé de 4 088 GPU H100 et de 511 serveurs GPU, avec 8 GPU par serveur participant à un entraînement synchrone à grande échelle via InfiniBand
  • Dans la pratique, le déploiement a consisté en un cycle répété de provisioning machine par machine, de remise en état de la fabric InfiniBand, de vérification de l’état des hôtes, de diagnostic des erreurs d’entraînement et d’amélioration de l’automatisation, tout en devant gérer environ 10 % d’échecs de démarrage des machines et un grand volume d’alertes sur les ports
  • Les outils publiés incluent des vérifications d’état des hôtes, un patch de journalisation NCCL, un test de stress GPU, des tests réseau NVLink et InfiniBand, un parseur de journaux d’événements UFM, ainsi qu’un script de génération de workload de burn-in InfiniBand
  • Dans l’entraînement LLM à grande échelle, un seul hôte ou lien instable peut ralentir toute l’exécution ; les contrôles de santé automatisés, l’isolement des pannes, les redémarrages et la désactivation de ports deviennent donc essentiels à l’exploitation continue

Construire un cluster pour entraîner son propre modèle 70B

  • Imbue a entraîné pendant plusieurs mois un modèle de 70B de paramètres à partir de zéro sur sa propre infrastructure, et ce modèle dépasse GPT-4o zero-shot sur des tâches liées au raisonnement
  • Le périmètre de publication couvre une procédure d’infrastructure end-to-end, allant du premier démarrage du cluster et de l’installation de l’OS jusqu’à la récupération automatique des erreurs pendant l’entraînement
  • Les outils d’infrastructure publiés avec l’annonce sont les suivants
    • Host-level health checks : scripts qui vérifient si un hôte peut être mis en production pour l’entraînement sans erreur connue
    • Patch NCCL : améliore la journalisation pour laisser davantage de logs en cas d’erreurs et de blocages
    • GPU stress test : vérifie qu’un GPU peut allouer de gros tenseurs et exécuter des opérations standard
    • Networking tests : valide la communication NVLink entre GPU d’une même machine et la communication InfiniBand entre GPU de machines différentes
    • UFM event log parser : parse les journaux d’événements de Unified Fabric Manager pour déterminer quels ports réseau doivent être désactivés
    • InfiniBand burn-in workload generator : génère des workloads de burn-in InfiniBand qui stressent tous les liens disponibles

Configuration du cluster et du réseau

  • Le cluster principal répartissait 4 088 GPU H100 sur 511 serveurs GPU, avec 8 GPU par serveur
  • S’il y avait 511 serveurs GPU, c’est parce qu’une partie des connexions devait être réservée à des nœuds Unified Fabric Manager (UFM) dédiés à l’administration du réseau InfiniBand
  • Chaque GPU était directement relié à une carte ConnectX-7 et pouvait émettre et recevoir simultanément à 400 Gbit/s via sa propre carte ConnectX-7 avec d’autres GPU du réseau InfiniBand
  • La topologie InfiniBand était fully non-blocking, ce qui permettait en théorie à tous les GPU de communiquer simultanément à vitesse maximale avec d’autres GPU
    • Une architecture de commutateurs InfiniBand à 3 niveaux fournissait le débit total du réseau
    • Les communications d’entraînement passaient par InfiniBand, et non par Ethernet
  • Ethernet était utilisé pour les datasets, les checkpoints et les autres transferts de données
    • Envoyer les communications d’entraînement sur Ethernet serait bien plus lent, car elles devraient quitter le GPU vers le CPU avant de passer par une carte Ethernet à 100 Gbit/s
    • L’entraînement sur Ethernet via RoCE est aussi possible, mais demande beaucoup plus de travail côté matériel et logiciel, et reste généralement moins fiable qu’InfiniBand
  • Un réseau Ethernet de gestion distinct était utilisé pour accéder au BIOS, aux alimentations et aux contrôleurs d’interface machine de bas niveau
    • Sans ce réseau de gestion, il aurait fallu configurer manuellement des centaines de machines avec clé USB, clavier et moniteur
  • Dans l’entraînement haute performance à grande échelle, InfiniBand, Ethernet, GPU et nœuds doivent fonctionner presque parfaitement
    • Une seule connexion instable parmi plus de 12 000 peut suffire à ralentir tout un run d’entraînement

Provisioning machine par machine

  • Après avoir mis en place la connectivité Ethernet du cluster via le réseau de gestion initial, l’équipe a obtenu les identifiants d’accès au BMC (Baseboard Management Controller)
    • Le BMC est un processeur de service permettant de surveiller l’hôte à distance
    • Il fournit l’état matériel, les paramètres du BIOS et des API de gestion de l’alimentation
  • Le premier serveur a reçu Ubuntu 22.04 via iDRAC, le BMC de Dell, au moyen d’une installation manuelle
    • Il était possible de monter une image ISO depuis un ordinateur local pour démarrer, et l’outil offrait une console virtuelle dans le navigateur
    • L’objectif était de faire de cette installation manuelle la seule de tout le processus

  • MAAS et démarrage PXE

    • Une fois la première machine prête, Ubuntu MAAS (Metal-as-a-Service) a été installé pour provisionner le reste des serveurs
    • Grâce au démarrage PXE et à des outils iDRAC automatisés, chaque machine a été configurée pour démarrer depuis le réseau
    • Les serveurs obtenaient une IP depuis MAAS via DHCP, téléchargeaient un noyau initial, puis réalisaient automatiquement une installation persistante de l’OS, même si le disque local était vide
    • En pratique, l’intégration entre MAAS et BMC n’était pas assez stable, si bien que toutes les adresses MAC des machines ont été collectées à l’avance via l’API iDRAC
    • MAAS s’est montré globalement fiable pendant tout l’entraînement, mais a posé au début des problèmes très spécifiques à sa configuration
      • Des écarts d’horloge trop importants bloquaient les installations apt à cause d’échecs de validation des certificats HTTPS
      • Le serveur MAAS cumulait les rôles de DHCP, DNS, proxy HTTP, NTP, gestion de configuration cloud-init et base de référence pour les MAC, IP, noms d’hôte et métadonnées, ce qui rendait le diagnostic des causes difficile

  • Échecs de démarrage et observabilité de base

    • Comme c’est fréquent lors de la mise en place d’un grand cluster GPU, environ 10 % des machines n’ont pas démarré correctement, principalement à cause de problèmes matériels physiques sur les serveurs
      • Câbles Ethernet non branchés ou mal câblés
      • Problèmes matériels iDRAC
      • Pannes d’alimentation
      • SSD NVMe défectueux
      • Câblage interne manquant
      • Carte réseau ou GPU non détecté
    • Imbue a automatisé les vérifications liées à ces problèmes, a renvoyé certaines machines en réinspection chez Dell et a ouvert les tickets nécessaires auprès du personnel du datacenter
    • Le fait d’avoir assuré directement la configuration de l’infrastructure a permis d’utiliser immédiatement les machines saines pendant que les autres attendaient leur réparation
    • Tous les serveurs ont reçu Docker, les pilotes GPU du datacenter, Prometheus node exporter, NVIDIA DCGM exporter, ainsi qu’un pool ZFS RAIDZ sur l’ensemble des disques hors OS
    • ZFS a permis de maintenir une machine en service même en cas de perte d’un disque, et sa compression transparente a fortement réduit l’espace occupé par les datasets texte et les logs répétitifs
    • L’installation parallèle des packages logiciels sur 400 nœuds a provoqué des goulots d’étranglement de bande passante
    • Les premières alertes de surchauffe sont apparues dans plusieurs composants du déploiement au datacenter, et la plupart des problèmes thermiques initiaux ont été atténués par des mises à jour de firmware

  • Vérification de l’entraînement GPU sur un nœud unique

    • Chaque machine a été vérifiée pour s’assurer qu’elle pouvait, de manière autonome, exécuter de vraies charges GPU
    • Plusieurs machines ont échoué à l’entraînement GPU sur nœud unique pour les raisons suivantes
      • Les erreurs liées aux GPU ont été majoritairement résolues en réinsérant les cartes dans leur slot
      • Les logs Ubuntu du serveur montraient des liens PCIe avec limited width: x4 < x16
      • Même après mise à jour du firmware du bus du switch PCIe, il a fallu réinsérer les câbles PCIe internes sur environ un quart des hôtes du cluster
      • Certains SSD NVMe, non marqués comme défectueux, figeaient toute la machine lors d’un accès
      • Linux affichait parfois l’ordre des disques de façon aléatoire, ce qui amenait MAAS à installer l’OS sur le mauvais disque
      • Des lectures de température erronées faisaient tourner en permanence les ventilateurs à 100 %
      • Le scaling dynamique de fréquence CPU limitait les cœurs actifs à 2 GHz
      • L’application de GDR, c’est-à-dire GPUDirect RDMA Peer Memory Client, a échoué

Provisioning InfiniBand

  • InfiniBand disposait d’une autorité de contrôle unique sur l’ensemble du réseau grâce à son architecture centralisée, ce qui permettait de traiter 320 commutateurs réseau comme une seule fabric
  • La première tâche a consisté à déterminer quels commutateurs étaient connectés à quelles machines, puis à renommer les commutateurs selon leur emplacement physique en les comparant au schéma de câblage

  • Conception erronée de la fabric et recâblage

    • Au départ, UFM ne détectait pas les 320 commutateurs réseau et ne trouvait pas non plus les hôtes censés faire partie de la fabric
    • Après vérification avec le partenaire du datacenter, les commutateurs étaient allumés et câblés, mais n’étaient pas détectés
    • L’examen de la liste de câblage réseau a montré que la fabric supérieure n’était pas une fabric unifiée, mais composée de 8 réseaux séparés sans chemin de routage commun
    • Après le recâblage, un contrôle a été ajouté pour vérifier que toutes les connexions physiques correspondaient à la nouvelle conception

  • Alertes de température et erreurs de port

    • Après résolution des problèmes de câblage physique, UFM s’est connecté à tous les commutateurs InfiniBand, mais presque tous les ports des commutateurs signalaient une température excessivement élevée
    • Avant même les transferts réels de données, certains ports dépassaient 70 °C, car l’espace vide entre les commutateurs dans les racks réseau faisait recirculer l’air chaud vers l’avant
    • De nombreux ports affichaient un taux d’erreur élevé ou du link flapping, alternant entre état normal et panne, et ce problème ne se manifestait que lorsque les ports étaient réellement utilisés, ce qui le rendait difficile à détecter à l’avance
    • La fabric entière comptait 1000 liens et une forte redondance, mais dès lors qu’environ 10 % de la fabric présentait des problèmes, même des fonctionnalités comme l’adaptive routing ne parvenaient pas à contourner suffisamment les liens qui se coupaient de façon irrégulière
    • Le partenaire du datacenter a nettoyé et réinstallé les ports en alerte, tandis que les autres transceivers en alerte, en attente de remplacement, ont été désactivés
    • Durant cette période, l’entraînement multinœud a été effectué sur 100 à 200 machines afin d’identifier un sous-ensemble stable d’InfiniBand

  • Burn-in InfiniBand et GPUDirect RDMA

    • Pour diagnostiquer plus efficacement les problèmes InfiniBand, une charge de travail spéciale a été créée afin d’injecter simultanément autant de données que possible dans tous les ports de l’ensemble de la fabric
    • Cela différait de l’exécution d’un unique grand all-reduce à l’échelle du cluster
      • car NCCL optimise les communications à l’intérieur d’un même nœud via NVLink et le chemin de socket SXM
    • UFM a signalé, sur la plupart des ports, un débit de données supérieur à 97 % de la capacité théorique, et certains commutateurs ont temporairement planté
    • Les ports encore opérationnels à la fin de la journée ont été considérés comme suffisamment robustes, tandis que les autres ont été désactivés ou transmis pour réparation ultérieure
    • GPUDirect RDMA a été activé afin de permettre aux GPU de communiquer sans surcharge CPU

  • Ensemble de machines stables et maintenance

    • Une règle empirique issue de l’expérience avec les clusters GPU de dernière génération est qu’il faut s’attendre à ce qu’environ 3 % des machines tombent en panne chaque semaine
    • Toutes les machines n’ont pas une probabilité uniforme de 3 % de tomber en panne ; certaines machines problématiques tombent en panne à répétition de plusieurs façons
    • En plaçant de nombreuses machines dans la même fabric, il devient possible d’agrandir un ensemble de machines golden connues pour être stables, plutôt que de poursuivre sans fin des problèmes aléatoires sur des machines individuelles
    • La maintenance InfiniBand consistait principalement à traiter les alertes UFM, remplacer les câbles et transceivers, et diagnostiquer les commutateurs défectueux
    • Les régressions à grande échelle provenaient généralement de deux facteurs
      • Une mise à jour de firmware appliquée seulement à la moitié du cluster a corrompu l’état UFM, rendant nécessaire un redémarrage d’UFM sur tous les commutateurs InfiniBand
      • Le redémarrage massif et simultané des boîtiers GPU provoquait une avalanche de mises à jour d’état UFM, nécessitant le redémarrage du service UFM

Système de vérification de l’état des hôtes

  • Imbue a identifié diverses pannes sur une seule machine susceptibles de faire échouer ou ralentir l’exécution de l’entraînement, puis a écrit des checks pour déterminer quels hôtes étaient suffisamment sains pour l’entraînement
  • Le code est publié dans cluster-health
  • De nombreux checks sont spécifiques à l’environnement d’exécution d’Imbue, mais l’objectif était de renvoyer un yes/no depuis un point d’entrée unique sur l’état de préparation à l’entraînement

  • Checks de santé rapides

    • GPU Health Check : vérifie le nombre de GPU, l’activation de l’ECC, les erreurs ECC, ainsi que la topologie et les erreurs NVLink
    • Disk Space Health Check : vérifie que l’utilisation du disque de l’hôte ne dépasse pas 95 %
    • Docker Health Check : vérifie qu’un conteneur connecté au GPU est en cours d’exécution ainsi que les autorisations des conteneurs de monitoring et de profiling
    • Dmesg Health Check : recherche les erreurs Xid et SXid des GPU ou commutateurs NVIDIA, et vérifie que les lignes de log dmesg peuvent être classées dans une liste de logs attendus
    • iDRAC Health Check : vérifie les erreurs iDRAC sur les machines Dell et ignore les messages d’erreur non critiques
      • Ce check n’est pas concerné par la publication open source
    • Disk Health Check : vérifie les montages zpool, la connexion Docker, et si le CPU se bloque lors des accès disque
    • InfiniBand Health Check : vérifie l’augmentation du taux d’erreur InfiniBand et les firmwares de pilotes obsolètes
    • Nvlink Health Check : vérifie les erreurs NVLink sur la machine
      • D’après l’expérience, elles ne provoquent pas l’échec de l’entraînement, mais peuvent le ralentir
    • GDR Health Check : vérifie si le GDR est activé sur la machine
    • VBIOS Health Check : vérifie que la version du VBIOS GPU et le firmware de la carte mère H100 sont à jour
    • Flint Health Check : utilise flint et hca_self_test pour vérifier le pilote Mellanox OFED, le firmware de la carte, la version du firmware du transceiver et l’état de compilation du pilote NVIDIA
    • PSB Health Check : interroge les périphériques PCIe afin de vérifier que la vitesse et la largeur de connexion entre GPU, PSB et carte réseau correspondent aux attentes
      • Ce script a été développé par Dell et ne peut pas être partagé pour le moment

  • Checks de santé plus longs

    • Mesure la bande passante NVLink, la vitesse de calcul GPU et la mémoire en initialisant des calculs matriciels avec PyTorch
    • Définit le flag GDR pour tester à la fois InfiniBand et NVLink
    • Mesure la bande passante PCIe et de la carte InfiniBand en envoyant des données vers la carte IB avec ib_write_bw et --use_cuda
    • S’exécute pendant environ 15 minutes pour détecter les liens InfiniBand instables
    • Une exécution de diagnostic multinœud vérifie la possibilité d’initialiser NCCL et l’absence de blocages aléatoires
      • En cas de blocage, le code NCCL forké laisse des logs supplémentaires
    • Comme la détection des problèmes peut prendre de 12 à 24 heures, ces checks sont surtout lancés sur de nouveaux nœuds ou en cas de suspicion
    • Vérifie les événements de throttling d’horloge GPU dans les exports DCGM, en excluant toutefois les cas attendus gpu_idle et power_cap
    • Un entraînement multinœud utilisant simultanément tous les GPU, cartes InfiniBand, CPU et disques révèle le mieux les événements liés à l’alimentation

Diagnostic des erreurs courantes pendant l’entraînement

  • Crash juste après le démarrage

    • Les crashs juste après le démarrage étaient les erreurs les plus simples à traiter, car relativement faciles à reproduire et à répéter
    • Il fallait d’abord vérifier que la version du code, la configuration et les variables d’environnement étaient correctes
    • Des abstractions intermédiaires comme le cache des images Docker ou des paramètres secrets opaques pouvaient brouiller l’identification de la cause
    • Il fallait aussi vérifier que toutes les machines étaient en ligne et qu’il était facile d’agréger et d’inspecter les stack traces et les logs
      • Imbue utilise la pile Loki, Prometheus et Grafana
    • Dans les exécutions distribuées synchrones, la première erreur provoquait souvent une cascade d’erreurs sans rapport
    • En mettant en place un système de relance automatique, l’agrégation des logs et des erreurs est devenue encore plus importante pour éviter de mélanger les logs et erreurs de différentes relances
    • Les erreurs fréquentes étaient les suivantes
      • Forward order differs across ranks... : lié aux caractéristiques de l’implémentation PyTorch FSDP, pouvait être résolu par une relance
      • CUDA out of memory... : résolu en vérifiant la configuration et le code, puis en annulant les modifications récentes du code
      • CPU/RAM OOM : il était préférable de le détecter via l’appel de l’OOM Killer dans les logs dmesg de l’hôte, en dehors du conteneur

  • Crash en cours d’entraînement

    • Une fois le matériel en fonctionnement, la priorité était d’avoir un système qui relance automatiquement après avoir réexécuté tous les checks de santé de diagnostic et exclu les hôtes non sains
    • Des erreurs matérielles aléatoires comme Xid et SXid pouvaient faire planter une exécution sans stack trace Python exploitable
    • Certains cas, comme le row remapping, pouvaient être récupérés par redémarrage, mais les erreurs ECC non corrigeables nécessitaient généralement une maintenance matérielle ou un remplacement de composants
    • Des données d’entraînement particulièrement mal formées provoquaient aussi des crashs
      • Un document unique très volumineux dans le corpus pouvait provoquer un OOM GPU ou CPU
      • Un data loader entièrement déterministe permettait de relier facilement le numéro d’epoch ou de step au crash
      • Pour vérifier si les données étaient en cause, ils désactivaient le chargement des données ou le remplaçaient par de fausses données remplies de zéros
    • Des microcoupures Ethernet ou un manque d’espace disque pouvaient ne pas apparaître avec des messages d’erreur utiles ; ils enregistraient donc les métriques réseau et d’état des nœuds pour vérifier les corrélations

  • Blocage sans stack trace

    • Les erreurs qui se bloquaient ou expiraient sans stack trace étaient particulièrement difficiles à déboguer, car elles fournissaient peu d’informations et étaient difficiles à reproduire de manière fiable
    • Le message représentatif était de la forme Watchdog caught collective operation timeout...
    • Si un ou plusieurs hôtes ne terminaient pas une opération NCCL ou décrochaient d’une connexion NCCL ou InfiniBand, tous les autres hôtes restaient alors bloqués de manière synchrone sur cette opération tensorielle jusqu’à NCCL_TIMEOUT
    • En raison des caractéristiques de la bibliothèque NCCL, il était difficile de trouver quel hôte était à l’origine du problème
    • Imbue a ajouté des modifications de journalisation à un fork de NCCL afin de mieux faire ressortir les messages ou opérations in-flight au moment du crash et d’identifier l’hôte ou le GPU en cause
    • Pour trouver l’hôte défaillant, il fallait souvent repérer les hôtes qui n’avaient pas produit certains messages de log
    • Avec Py-Spy et GDB, ils déboguaient en direct les processus bloqués afin de distinguer les blocages NCCL, les blocages de pilote et les race conditions ou deadlocks du code Python

Dégradation de la vitesse d’entraînement vue par le MFU

  • Une baisse générale de performance ou un MFU (Model FLOPs Utilization) inférieur aux niveaux déjà observés pouvait venir de plusieurs causes
  • Recontrôler la configuration, le code et les variables d’environnement aidait d’abord
    • mauvais modèle
    • mauvaise taille de batch
    • mauvais réglages UFM ou NCCL
    • mauvaise valeur de CUDA_DEVICE_MAX_CONNECTIONS
  • Mesurer le MFU instantané batch par batch était plus utile pour diagnostiquer le type de problème qu’une moyenne lissée

  • Causes selon les motifs de MFU

    • Si le MFU restait stable à moins d’un dixième du niveau attendu juste après le démarrage, il s’agissait généralement d’un problème matériel InfiniBand, comme un switch mort au niveau T2 ou T3
      • Un problème matériel entre le GPU et le NIC pouvait aussi en être la cause, apparaissant dans dmesg sous la forme PCIe x16 lanes limited by ...
    • Si le MFU restait stable à 30 % de la valeur attendue juste après le démarrage, la configuration GDR ou les variables d’environnement GDR d’un hôte pouvaient être incorrectes
    • Si le MFU restait stable entre 60 et 80 % de la valeur attendue juste après le démarrage, la cause était généralement une liaison InfiniBand dégradée ou défectueuse
      • Si le NIC InfiniBand connecté à un GPU précis était défectueux, NCCL essayait alors d’utiliser le NIC d’un autre GPU du même hôte en passant par le NVLink local
      • Un throttling CPU pouvait aussi en être la cause, nécessitant l’ajustement des paramètres BIOS de certains hôtes
    • Si des chutes d’un facteur 10 se produisaient régulièrement sur un seul batch, elles étaient presque toujours liées au checkpointing ou à l’évaluation, ce qu’on pouvait vérifier en comparant avec les numéros d’epoch et de step
      • Déclencher des alertes automatiques uniquement à partir des anomalies de MFU entraînait beaucoup de faux positifs
    • Si des chutes d’un facteur 10 sur un batch unique survenaient rarement et aléatoirement, puis se résorbaient immédiatement, il était fréquent qu’une charge de travail gourmande en CPU ait été planifiée sur l’un des hôtes en cours d’exécution
      • Des problèmes réseau intermittents ou un goulot d’étranglement du data loader pouvaient aussi en être la cause
    • Si la courbe de MFU descendait progressivement au fil de l’exécution puis revenait à 100 % après redémarrage, les profileurs Python et NVIDIA permettaient de vérifier que le ramasse-miettes automatique en était la cause
      • En désactivant le ramasse-miettes automatique et en exécutant le garbage collection à intervalles définis sur tous les hôtes, la baisse de débit a disparu
    • Si les performances étaient bonnes au départ mais chutaient ensuite fréquemment à 70 % du niveau attendu, cela corrélait avec les NVIDIA GPU clock throttle reasons
      • Les causes étaient la température du GPU, une panne ou une dégradation des ventilateurs de refroidissement de l’hôte, ou une défaillance de l’alimentation électrique
    • Si les performances étaient bonnes mais qu’il y avait beaucoup de bruit haute fréquence entre 90 et 100 % du MFU attendu, il s’agissait généralement d’un problème matériel InfiniBand d’ampleur modérée dans les couches réseau supérieures, comme une liaison instable

  • Questions de vérification en cas de régression de débit

    • Vérifier si cela avait déjà fonctionné correctement auparavant
    • Vérifier s’il y avait eu un changement récent, comme une fusion de code ou une mise à jour de pilote
    • Vérifier si l’exécution se faisait sur des hôtes sains et si des services dépendants comme Docker Hub ou GitHub fonctionnaient
    • Vérifier si l’exécution utilisait le même code, le même environnement, la même configuration, les mêmes versions, la même liste d’hôtes, le même ordre des ranks et la même random seed que la dernière exécution correcte
    • Vérifier si le problème était reproductible
    • Vérifier s’il y avait une corrélation avec d’autres processus, le crontab quotidien, ou les métriques des hôtes, de DCGM ou d’UFM
    • Vérifier si l’outil de mesure des métriques était correct
    • Vérifier si le problème survenait aussi avec un modèle plus petit, de fausses données ou un code réduit sans sauvegarde/chargement de checkpoint

Outils d’automatisation et améliorations opérationnelles

  • Même si l’entraînement pouvait démarrer avec de bonnes performances, quelque chose finissait toujours par tomber en panne, d’où le besoin d’outils et de systèmes minimisant l’intervention humaine
  • Imbue étant une petite équipe, elle n’avait pas assez de personnel pour continuer les réparations manuelles, et a donc automatisé autant d’étapes que possible
  • La plupart des problèmes rencontrés lors des runs d’entraînement ont été ramenés à des machines défectueuses ou à des composants réseau

  • Exclusion automatique des machines défectueuses

    • Un système a été développé pour redémarrer automatiquement les runs plantés à partir du dernier checkpoint
    • Le processus de redémarrage exécute des vérifications de santé sur toutes les machines disponibles, puis classe leur état selon les résultats
    • Le job d’entraînement est ensuite relancé sur les machines les plus saines

  • Réponse automatisée aux composants réseau

    • Tous les échecs de composants réseau observés étaient détectés par UFM et enregistrés dans le journal d’événements UFM
    • En pratique, seuls certains événements parmi plusieurs dizaines posaient réellement problème, la plupart étant liés à des link down ou à un symbol error count élevé
    • Les scripts analysent le journal d’événements UFM, désactivent les liens et ports associés aux événements récents, créent des tickets de maintenance, puis les réactivent une fois la réparation terminée

  • Miroir de système de fichiers local

    • Les débits Ethernet à l’intérieur comme à l’extérieur du cluster pouvaient devenir un goulot d’étranglement pour l’entraînement distribué à grande échelle
    • Une connexion Ethernet partagée d’environ 10 Gbit/s se saturait rapidement lorsque des centaines de workers téléchargeaient simultanément les jeux de données et les checkpoints du modèle
    • Imbue a mis en place dans le cluster un système de fichiers local qui met en miroir le cloud storage afin de réduire le nombre de fichiers à récupérer depuis S3
    • Pour faire face au churn, avec des machines fréquemment désactivées ou remplacées, chaque fichier était répliqué en triple
    • Le consistent hashing a permis de répartir uniformément la charge et de minimiser les déplacements de fichiers pendant le churn
    • En raison de l’espace disque limité, des outils de suivi du cycle de vie des fichiers et de suppression des fichiers inutiles ont aussi été développés

  • Registry Docker distribué local

    • Kraken a été utilisé pour le transfert des images Docker
    • Kraken est un logiciel open source qui permet de transférer des images Docker en peer-to-peer, et Imbue indique n’avoir presque rencontré aucun problème avec lui

  • Supervision des performances et identification des hôtes défectueux

    • Torch profiler et NVIDIA Nsight Systems ont été configurés
    • Nsight Systems s’est révélé utile pour comprendre combien de temps prenaient les passes forward/backward et les communications NCCL
    • Il a aidé à déterminer si le goulot d’étranglement venait du calcul ou de la communication selon la taille du modèle et le nombre de workers
    • Son utilisation était toutefois un peu difficile, car elle exigeait le mode Docker privileged, la désactivation des contrôles de sécurité liés aux événements de monitoring de performance, ainsi qu’une interruption de l’entraînement pour enregistrer les profils
    • Des outils ont également été écrits pour détecter les batches d’entraînement lents et en identifier la cause
      • L’outil le plus utile surveillait le temps de chaque batch, puis dumpait les stack traces de tous les workers lorsqu’un batch était anormalement lent
      • Cela a facilité l’identification d’hôtes spécifiques présentant des problèmes matériels ou logiciels subtils
    • Avant que les health checks ne soient suffisamment matures, lorsqu’un entraînement échouait sur un ensemble donné de machines, il n’était pas clair quelle machine en était la cause
      • Par exemple, si un groupe de 48 machines échouait, ils lançaient de plus petits runs en 6 groupes de 8 machines, puis en 8 groupes de 6 machines
      • Une machine apparaissant dans les groupes en échec aux deux étapes était considérée, avec un haut degré de confiance, comme la machine problématique

Principes opérationnels tirés de la mise en place

  • Disposer de 10 à 20 % de machines en plus par rapport au besoin d’un run donné permet de relancer facilement en cas de panne d’une machine
  • Configurer le réseau du cluster pour que toutes les machines soient reliées de manière rapprochée permet d’utiliser n’importe quel sous-ensemble fonctionnel
  • Les pannes matérielles et logicielles rencontrées pendant l’entraînement se reproduisent, il vaut donc la peine d’écrire des tests et des solutions d’automatisation pour chaque type de panne
  • Pour chaque message d’erreur opaque, il est utile de créer des outils plus interprétables
  • Pour garantir la reproductibilité, la règle adoptée consistait à ne modifier qu’un seul élément, même minime, à la fois
  • Lors de l’introduction d’un outil externe ou de l’arrivée d’une nouvelle personne dans le processus, les affirmations étaient revérifiées, en particulier lorsque les étapes suivantes dépendaient de ces résultats
  • L’ensemble du processus a nécessité beaucoup de supervision et d’itérations, mais le fait d’avoir un contrôle complet sur l’infrastructure et de pouvoir déboguer les problèmes à tous les niveaux d’abstraction a joué un rôle décisif

À lire aussi

1 commentaires

 
GN⁺ 2024-06-29
Avis de Hacker News
  • Pendant plusieurs mois, une petite équipe de recherche et d’ingénierie a entraîné à partir de zéro un modèle de 70 milliards de paramètres sur sa propre infrastructure, et a dépassé GPT-4o en zero-shot sur des tâches liées au raisonnement.
    Pour utiliser son propre cluster pour un entraînement haute performance, tous les composants — InfiniBand, Ethernet, GPU, jusqu’aux nœuds — devaient fonctionner parfaitement ; une seule connexion instable parmi plus de 12 000 pouvait ralentir tout l’entraînement.
    Ils ont publié des scripts open source et un guide de bout en bout pour configurer l’infrastructure ; cela fait partie d’une trilogie d’outils pour entraîner un modèle de 70 milliards de paramètres. Les outils d’évaluation et d’optimisation des hyperparamètres CARBS sont disponibles ici : https://imbue.com/research/70b-intro/
    • Le niveau de détail était vraiment excellent, et c’est la première fois que je vois un billet montrant de l’intérieur, avec autant de précision, le travail d’ingénierie derrière de tels modèles.
      J’ai deux questions. D’abord, je me demande ce qui changerait si l’on entraînait un modèle de 400 milliards de paramètres. À l’échelle du cluster, il semble y avoir assez de mémoire vidéo, mais j’aimerais connaître le vrai raisonnement.
      Ensuite, je me demande si ce type d’architecture est considéré comme la forme finale de l’entraînement de modèles. Cela paraît très fragile ; j’aimerais savoir s’il existe de meilleurs mécanismes ou architectures d’entraînement partagé, ou de meilleures structures de cluster.
    • Je me demande ce qu’est devenu le monde 3D façon Minecraft que l’équipe construisait. Ont-ils changé de cap ?
    • La partie « a dépassé GPT-4o en zero-shot » est intéressante. Est-ce que ce modèle a été poussé jusqu’au RLHF, ou seulement pré-entraîné ?
      Si c’est la seconde option, j’aimerais savoir comment il a battu GPT-4.
    • La phrase disant qu’une seule connexion instable parmi plus de 12 000 pouvait ralentir tout l’entraînement m’a semblé assez particulière, au point de me dire : « j’ai déjà vu cette phrase quelque part ».
      En fait, cette phrase et une grande partie du texte semblent avoir été publiées presque mot pour mot sur Twitter, LinkedIn et Reddit ; c’est juste du spam ?
      https://x.com/imbue_ai/status/1805629547473518695
      https://reddit.com/r/learnmachinelearning/comments/1dobgbs/t...
      https://www.linkedin.com/posts/mattboulos_training-a-70b-mod...
  • Si je comprends bien, « 511 ordinateurs avec 4 092 GPU H100, 8 par ordinateur », ça fait plus de 100 millions de dollars rien qu’en GPU ?
    Je me demande quelle part de tout cela pourra, et à quel horizon, arriver dans le monde des développeurs amateurs avec un budget de PC gaming.
    • C’est intéressant de dépenser 100 millions de dollars en GPU tout en bricolant des boîtiers Dell avec des ports Ethernet défectueux.
      Les problèmes qu’ils ont rencontrés sont amusants à lire.
    • Ça semble exact. Ils ont levé 200 millions de dollars auprès de NVIDIA, probablement essentiellement sous forme de GPU : https://news.crunchbase.com/ai-robotics/new-ai-unicorn-imbue...
    • Si les GPU à eux seuls dépassent 100 millions de dollars, la plupart des lecteurs qui n’ont pas ce niveau de financement devraient sans doute passer au prochain article HN.
  • Vraiment impressionnant. Cisco a récemment collaboré avec NVIDIA pour sortir des équipements offrant 800G par port, mais je ne me souviens plus si c’était du RoCE.
    Ici, il semble que les GPU puissent accéder à InfiniBand, et c’est élégant. C’est l’un de ces articles directement utiles.
  • Le podcast Latent Space en a aussi parlé il y a quelques jours : https://www.latent.space/p/llm-training-2024
    C’était un bon épisode, et ça vaut le coup d’entendre les raisons derrière ces décisions.
    • Je ne suis pas habitué à ce type d’interview, donc je me suis senti hors de ma zone de compétence. S’il y a des questions qui auraient dû être posées mais qui ont été oubliées, je serais preneur de suggestions.
  • Je suis curieux de connaître la consommation électrique totale nécessaire pour créer le modèle. J’aimerais savoir s’il existe des chiffres incluant l’électricité et le refroidissement.
    Zuckerberg a dit dans un podcast qu’il préparait le prochain modèle à 1 GW, ce qui revient en pratique à un datacenter adossé à une centrale électrique de taille moyenne, donc ça m’intrigue encore plus.
  • C’est un article vraiment précieux, et j’ai beaucoup appris en le lisant. Le code open source publié est également excellent.
    J’ai plusieurs questions. Pourquoi ont-ils construit leur propre cluster, et comment s’est passée l’expérience avec le partenaire cloud pour gérer du matériel ou des switches défectueux ?
    J’aimerais aussi savoir, au-delà de la communication all-to-all, ce qu’ils ont le plus privilégié au moment de choisir l’architecture du cluster et ce qui s’est révélé le plus utile en pratique ; à quoi ressemblait l’infrastructure de logs, au-delà du fait qu’elle reposait sur Loki ; pourquoi un registre Docker local était nécessaire ; et s’ils ont utilisé d’autres images en plus de nvidia-container-runtime.
  • Question sincère : pourquoi y a-t-il autant de matériel PC dans tout ça ?
    Je me demande s’il ne serait pas possible de raccorder les GPU à un backend PCI et InfiniBand, avec seulement un tout petit contrôleur de coordination ARM, puis de les faire se coordonner entre eux. Je ne sais pas si c’est l’inertie d’anciens designs, ou bien un manque de marché pour des contrôleurs GPU spécialisés.
    • Si la question porte sur la raison de payer un surcoût pour le CPU et la RAM : on ne peut pas tout faire sur GPU. Par exemple, il y a la décompression .png.
      Si l’on analyse vraiment le code d’entraînement et que l’on prétraite beaucoup les données, on peut peut-être s’en sortir avec des ressources CPU/RAM très légères ; mais comme les GPU sont chers, le CPU et la RAM ne représentent qu’une petite part du coût total du système, donc il n’est pas forcément nécessaire de consacrer du temps de développement à ce niveau d’optimisation.

Les très grands fournisseurs de cloud sont susceptibles de courir après ce genre d’efficacité des coûts de 0,x %. Par exemple, on pourrait vouloir prétraiter des .png en .webp (sans perte multithread) ou en .jpeg (avec perte), mais les convertir dans un format que le GPU peut décompresser risque de ne pas être adapté : cela réduit le coût CPU pendant l’entraînement, mais peut augmenter les coûts de stockage et de transfert
Plus précisément, si le travail CPU est le goulot d’étranglement de l’entraînement, il faut optimiser autant que possible le prétraitement des données et les ajustements du script d’entraînement. Ce dont il est question ici, c’est l’écart entre « assez rapide » et « plus rapide » : CPU pas assez rapide pour l’entraînement < CPU tout juste assez rapide pour l’entraînement < CPU plus rapide que nécessaire pour l’entraînement

  • Si chaque machine contient pour 250 000 dollars de GPU, il est absurde de se demander comment économiser quelques milliers de dollars sur le matériel de contrôle. Le risque lié à l’utilisation d’une nouvelle configuration matérielle est trop élevé
    Un autre problème est que tout le matériel, les pilotes et l’expérience opérationnelle liés aux GPU se trouvent du côté PC. Pour faire tourner cela sur ARM, il faudrait quasiment repartir de zéro, et il faudrait beaucoup de travail supplémentaire pour stabiliser l’ensemble. Au final, on paierait très cher pour économiser un peu sur le coût du processeur
  • Alimenter en continu les GPU en données est une tâche assez délicate dans l’entraînement de deep learning
    Je n’ai pas d’expérience en LLM/NLP, mais sur des charges de travail image et audio, il arrive qu’un CPU classique à 4–8 cœurs ait du mal à exploiter pleinement même des GPU RTX 2/3/4xxx. Il n’est pas si difficile de se retrouver avec le CPU ou les entrées/sorties comme goulot d’étranglement
  • 4 092 GPU H100, c’est une grosse échelle
    Ils disent faire du « self-coding », et je me demande si cela se rapproche plutôt de solutions no-code ou low-code
    Il y a aussi pas mal d’articles intéressants sur leur site : https://imbue.com/our-work/
  • Je me demande combien cela a coûté. En partant de rien jusqu’à un fichier de modèle utilisable, à combien cela revient-il en additionnant le coût du matériel, le temps de développement, l’électricité et le refroidissement ?
  • Je me demande si de nombreux développeurs amateurs pourraient entraîner ensemble un modèle de façon distribuée, comme avec seti@home ou folding@home
    Ces projets avaient la particularité de pouvoir découper le travail en paquets de tâches assez indépendants, mais je ne sais pas vraiment si l’entraînement de modèles peut être découpé de cette manière
    • Il y a de fortes chances que cela fonctionne mal. Parmi les développeurs amateurs, il doit y en avoir très peu, voire aucun, capables d’assurer un débit réseau de 400 Gbit/s entre leurs GPU