Von Bare-Metal bis hin zu einem großen Modell mit 70 Milliarden Parametern finden Sie hier ein Tutorial und gebrauchsfertige Skripte

Wir wissen, dass LLM auf großen Computerclustern unter Verwendung riesiger Datenmengen trainiert wird. Auf dieser Website wurden viele Methoden und Technologien vorgestellt, die den LLM-Trainingsprozess unterstützen und verbessern. Was wir heute teilen möchten, ist ein Artikel, der tief in die zugrunde liegende Technologie eintaucht und vorstellt, wie man einen Haufen „Bare-Metals“ ohne Betriebssystem in einen Computercluster für das LLM-Training verwandelt. Dieser Artikel stammt von Imbue, einem KI-Startup, das daran arbeitet, allgemeine Intelligenz zu erreichen, indem es versteht, wie Maschinen denken. Natürlich ist es kein einfacher Prozess, einen Haufen „Bare Metal“ ohne Betriebssystem in einen Computercluster für das Training von LLM zu verwandeln, aber Imbue hat schließlich erfolgreich einen LLM mit 70 Milliarden Parametern trainiert viele nützliche Erfahrungen dabei. Dieser Artikel bietet einen detaillierten Einblick in den Prozess des Teams beim Aufbau seiner eigenen LLM-Schulungsinfrastruktur und stellt die vielen Tools und Skripte vor, die es geschrieben hat, um die Überwachung, Inspektion und Fehlerbehebung zu erleichtern. Wenn Sie daran interessiert sind, Ihre eigene LLM-Schulungsinfrastruktur aufzubauen, oder neugierig sind, wie LLM aufgebaut ist, dann lohnt es sich, diesen Artikel zu lesen und zu sammeln. Das Folgende ist der Originalartikel des Imbue-Teams. Einleitung Unser kleines Team aus Forschern und Ingenieuren hat mehrere Monate damit verbracht, ein 70-Milliarden-Parameter-Modell von Grund auf auf unserer eigenen Infrastruktur zu trainieren, und das Modell war bei inferenzbezogenen Aufgaben besser als das Modell ohne Stichprobe. Heute teilen wir den Prozess der Einrichtung der erforderlichen Infrastruktur: von der Zusammenstellung des ersten Clusters und der Installation des Betriebssystems bis hin zur Einrichtung der automatischen Wiederherstellung, wenn während des Trainings Fehler auftreten. Wir beschreiben detailliert die aufgetretenen Herausforderungen und Lösungen für jeden Schritt. Zusätzlich zu diesen Erkenntnissen werden wir auch viele der Skripte veröffentlichen, die wir im Laufe der Zeit entwickelt haben, um es anderen Teams zu erleichtern, eine stabile Infrastruktur für ihr eigenes Modelltraining zu schaffen. Während des gesamten Prozesses arbeitete unser Ingenieurteam mit Voltage Park zusammen, um Computercluster vorzubereiten und die Grundlage für Produktionsanwendungen zu schaffen. Dieser gesamte Prozess umfasst: 1. Konfigurieren jeder Maschine 2. Konfigurieren von InfiniBand 3. Sicherstellen, dass die Maschinen vollständig fehlerfrei sind 4. Diagnostizieren häufiger Trainingsprobleme 5. Verbessern der Infrastrukturtools Jeder Schritt wird im Folgenden detailliert beschrieben. Hintergrund: Wie es funktioniert Unser Ziel bei der Durchführung von Berechnungen besteht darin, sicherzustellen, dass wir schnell mit großen Sprachmodellen experimentieren können. Dazu benötigen wir eine große Anzahl an Hochgeschwindigkeits-GPUs, die mit hoher Geschwindigkeit miteinander kommunizieren können. Dieser Artikel konzentriert sich auf einen Cluster mit 4088 H100-GPUs, verteilt auf 511 Maschinen, oder 8 GPUs pro Maschine. Der Grund dafür, dass es 511 Computer mit GPUs gibt, liegt darin, dass einige Verbindungen für den Unified Fabric Manager-Knoten reserviert werden müssen, dessen Aufgabe darin besteht, das InfiniBand-Netzwerk zu verwalten. Auf den 511-Hosts mit GPUs ist jede GPU direkt mit einer ConnectX-7-Netzwerkkarte verbunden, die Daten mit 400 Gbit/s an jede GPU im InfiniBand-Netzwerk übertragen kann. Unsere InfiniBand-Netzwerktopologie ist „völlig nicht blockierend“, was es GPUs theoretisch ermöglicht, mit maximaler Geschwindigkeit miteinander zu kommunizieren. Dazu verwenden wir eine dreischichtige InfiniBand-Netzwerkarchitektur: dreischichtige InfiniBand-Switches. Mit den richtigen Verbindungen kann dieser hohe Durchsatz im gesamten Netzwerk erreicht werden. Das Bild unten zeigt einen Überblick über dieses InfiniBand-Netzwerk:

Bitte beachten Sie, dass die Kommunikation beim Training des Netzwerks über InfiniBand und nicht über Ethernet erfolgt. Obwohl diese Maschinen auch mit Ethernet verbunden sind, besteht die Rolle dieses Netzwerks darin, Daten wie Datensätze und Kontrollpunkte zu transportieren. Wenn Sie Ethernet zum Senden von Daten verwenden, ist die Übertragung viel langsamer, da die Daten von der GPU zur CPU und dann mit einer Geschwindigkeit von 100 Gbit/s über die Ethernet-Karte übertragen werden. Es ist zwar möglich, über Ethernet mit einer Technologie namens RDMA over Converged Ethernet (RoCE) zu trainieren, dies erfordert jedoch viel zusätzlichen Aufwand sowohl auf der Hardware- als auch auf der Softwareseite und ist im Allgemeinen weniger zuverlässig als InfiniBand. Details finden Sie in diesem Dokument: https://arxiv.org/pdf/2402.15627
Es gibt auch ein sekundäres Ethernet, das nur für die Konfiguration und Verwaltung verwendet wird und den Zugriff auf das BIOS (Basic Input Output System), die Stromversorgung und andere Low-Level-Geräte ermöglicht -Ebenenmaschinen Die Steuerschnittstelle der Schnittstelle. Ohne dieses Verwaltungsnetzwerk müssten wir jeden Knoten manuell über einen USB-Treiber, eine Tastatur und einen Monitor einrichten. Für Situationen mit Hunderten von Maschinen ist dies kein nachhaltiger Ansatz.
Um ein Hochleistungstraining auf diesem Cluster zu erreichen, müssen alle Komponenten (InfiniBand, Ethernet, GPU und die Knoten selbst) nahezu perfekt funktionieren. Wenn eine dieser über 12.000 Verbindungen etwas instabil ist, kann dies den gesamten Trainingslauf verlangsamen.
Der nächste Inhalt dieses Artikels besteht darin, vorzustellen, wie alles perfekt und stabil läuft.
Vorgehensweise: So verwandeln Sie Bare-Metal in einen voll funktionsfähigen Cluster
Konfigurieren jeder Maschine
Nachdem die erste Ethernet-Verbindung zum Cluster über das Verwaltungsnetzwerk hergestellt wurde, wird ein Zertifikat für den Zugriff auf den Baseboard-Management-Controller (BMC/Baseboard-Management-Controller) erhalten. Ein BMC ist ein dedizierter Serviceprozessor, der Hostsysteme aus der Ferne überwacht und normalerweise mit einem separaten Netzwerk verbunden ist. Es ermöglicht uns, die Maschine so zu bedienen, als ob wir physisch anwesend wären, und stellt darüber hinaus APIs für den Hardwarezustand, BIOS-Einstellungen und Energieverwaltung bereit.
Nachdem wir diese Komponenten bestückt haben, können wir die Ärmel hochkrempeln und mit dem Aufbau des Clusters beginnen.
Schritt 0: Zuerst eine Maschine konfigurieren
Wir begannen mit der Installation von Ubuntu 22.04 auf einem Server mithilfe von iDRAC (Dells Baseboard-Management-Controller) und richteten dann alles andere auf Basis dieses Betriebssystems ein. Eine der Funktionen von iDRAC besteht darin, die Installation und das Booten von ISO-Images vom lokalen Computer zu ermöglichen und über den Browser eine virtuelle Konsole bereitzustellen. Im Idealfall ist dies der einzige manuelle Installationsschritt im Prozess.
Schritt 1: Installieren Sie das Betriebssystem auf jeder Maschine.
Nachdem Sie die erste Maschine konfiguriert haben, fahren Sie mit der Installation der Metal-as-a-Service (MAAS)-Software von Ubuntu fort, um die Konfiguration der verbleibenden Server zu unterstützen. Verwenden Sie das Preboot Execution Environment Protocol (PXE)-Start- und Automatisierungs-iDRAC-Tool, um jede Maschine anzuweisen, über das Netzwerk zu starten und MAAS so zu konfigurieren, dass es auf PXE-Startanforderungen reagiert. Beim ersten Netzwerkstart erhält der Server eine IP und einen ersten Kernel von MAAS über das Dynamic IP Allocation Protocol DHCP, ohne dass etwas auf dem lokalen Laufwerk installiert werden muss. Dies ist die grundlegende Umgebung zur Automatisierung wiederholbarer Betriebssysteminstallationen. Theoretisch müssen wir nur auf den ersten Start warten und schon ist alles erledigt. In der Praxis ist die MAAS-Integration mit BMC jedoch unzuverlässig. Daher verwenden wir die iDRAC-API, um vorab die MAC-Adresse (eine eindeutige physische Hardware-ID) jeder Maschine zu erfassen.
Während dieses gesamten Trainingsprozesses ist MAAS in der Regel die zuverlässigere Komponente des Wirbelstapels. Am Anfang stießen wir jedoch auf einige Probleme, die nur bei unserem Setup auftraten. Als ich beispielsweise die ersten Maschinen konfigurierte, konnte ich nichts über apt installieren, weil es Probleme bei der Überprüfung des HTTPS-Zertifikats gab, weil die Uhren so weit voneinander entfernt waren. Damit verbunden, da der MAAS-Server für viele Dinge verantwortlich sein muss (DHCP-Server, DNS-Server zum Auflösen von Hostnamen in IPs, HTTP-Proxy zwischen dem Host und dem offiziellen Ubuntu-Paketserver, NTP-Server, Cloud-Init-Konfigurationsverwaltung, ein Boden). Daher ist es für uns schwierig, diese Probleme von der Grundursache her zu lösen. Darüber hinaus besteht das Problem der Lernkurve des MAAS-Konfigurationslebenszyklus, da das Entwurfsziel darin besteht, die Komplexität der Verwaltung von Greenfield-Bereitstellungen und der schrittweisen Migration von Knoten und verschiedenen Debug-/fehlerhaften Zwischenzuständen zu bewältigen.
Schritt 2: Defekte Maschinen diagnostizieren
Wir haben festgestellt, dass etwa 10 % der Maschinen nicht booten konnten, hauptsächlich aufgrund physischer Probleme mit dem Server. Dies ist ein häufiges Szenario für die Einrichtung großer GPU-Cluster. Zu den Situationen, auf die wir gestoßen sind, gehören: fehlende oder falsche Netzwerkkabel, Hardwareprobleme im iDRAC, beschädigte Netzteile, beschädigte NVME-Treiber (nichtflüchtiger schneller Speicher), fehlende interne Verkabelung, Netzwerkkarten oder GPUs werden nicht angezeigt. Wir haben diese Probleme automatisch überprüft, einige Maschinen zum erneuten Testen an Dell zurückgegeben und entsprechende Arbeitsaufträge für das Personal des Rechenzentrums übermittelt. Ein Vorteil der Konfiguration des Clusters selbst besteht darin, dass wir sofort fehlerfreie Maschinen verwenden können, während wir auf die Wartung einiger Maschinen warten.
Schritt 3: Minimum Viable Observable Machine
Wir richten auf jedem Server Folgendes ein:
1.Docker (um die Ausführung von Diensten und Schulungsjobs zu vereinfachen)

2. Rechenzentrums-GPU-Treiber
   3. Prometheus-Knoten-Exporttool (wird zum Exportieren eines stabilen Hardware-/Betriebssystem-Indikatordatenflusses verwendet)
   4. DCGM-Exporttool (wird zum Exportieren zusätzlicher Indikatordaten von der NVIDIA-GPU verwendet, wie GPU-Status, Uhr, Auslastung)
3. Alle nicht vom Betriebssystem gesteuerten RAIDZ ZFS-Pools, die es Maschinen ermöglichen, auch bei einem Treiberausfall weiterzuarbeiten und gleichzeitig transparente Komprimierung kostenlos bereitzustellen (insbesondere für Nur-Text-Datensätze und sich wiederholende Protokolle). Nützlich – die Verwendung dieses Tools erhöht sich normalerweise
   Wir führen dann eine grundlegende GPU-Diagnose durch, um festzustellen, ob die GPU im Allgemeinen funktioniert. Wenn nicht, geschieht dies normalerweise innerhalb weniger Sekunden. Hardwareprobleme treten innerhalb von Stunden auf.
   Während dieser Zeit stießen wir auf Bandbreitenengpässe, als wir versuchten, Pakete auf allen 400 Knoten gleichzeitig zu installieren. Dies ist das erste Mal, dass wir Warnungen vor Überhitzung mehrerer Komponenten in unserem Rechenzentrum erhalten. Diese ersten Heizprobleme wurden größtenteils durch Firmware-Updates behoben.
   Schritt 4: Einzelknoten-GPU-Training
   Der nächste Schritt besteht darin, sicherzustellen, dass jede Maschine echte GPU-Arbeitslasten alleine bewältigen kann. Zu den Problemen gehören:
   GPU-bezogene Fehler können grundsätzlich durch erneutes Einsetzen der GPU-Karte in den Kartensteckplatz behoben werden: Schieben Sie den 200-Pfund-Server aus dem Rack und entfernen Sie alle Kabel dazwischen Entfernen Sie die Gehäuseabdeckung und die GPU, entfernen Sie dann die GPU, installieren Sie die GPU erneut, schließen Sie dann die Kabel wieder an und schieben Sie den Server zurück in das Rack.
   Laut Ubuntu-Serverprotokollen gaben viele Kabel zwischen der GPU und dem PCIe-Bus oder der Netzwerkkarte diesen Fehler aus: „begrenzte Breite: x4 Es gibt auch einige verschiedene Störungen, die mehrere Hosts betreffen. Dell hat uns mit einem Firmware-Upgrade bei der Lösung einiger Probleme geholfen:
   Das NVMe-Laufwerk zeigte keine Störungen, blockierte jedoch bei Berührung die gesamte Maschine.
   Festplatten werden unter Linux in zufälliger Reihenfolge angezeigt, was zu Verwirrung bei MAAS führt und dazu führt, dass das Betriebssystem auf dem falschen Laufwerk installiert wird.
   Falsche Temperaturanzeige, die dazu führt, dass der Lüfter ständig auf Hochtouren läuft. Der Grund könnte ein Problem mit dem NVIDIA-Treiber sein, das durch ein Downgrade der Treiberversion behoben wird.
   Die dynamische Skalierung der CPU ist außer Kontrolle und begrenzt die Arbeitskerne auf 2 GHz.
   Die direkte GPU-GPU-Kommunikation (GDR oder GPUDirect RDMA Peer Memory Client) kann nicht erfolgreich angewendet werden.
   InfiniBand konfigurieren
   Schritt 0: UFM installieren
   Einer der Vorteile von InfiniBand ist sein zentralisiertes Design, sodass das gesamte Netzwerk über ein Gehirn verfügt. Daher müssen wir uns nur mit einer Instanz der 320 Netzwerk-Switches in der gesamten Netzwerkstruktur befassen. Unsere erste Aufgabe bestand darin, herauszufinden, welcher Schalter welche Maschinen verband, dies dann mit dem Schaltplan zu verknüpfen und sie basierend auf der physischen Position des Schalters umzubenennen.
   Schritt 1: Neuverkabelung
   Anfangs war UFM nicht in der Lage, diese 320 Switches zu erkennen, geschweige denn die Hosts, die eigentlich in der Fabric vorhanden sein sollten. Nach Rücksprache mit unseren Rechenzentrumspartnern haben wir bestätigt, dass die Switches eingeschaltet und verkabelt waren, konnten sie aber immer noch nicht erkennen. Nach Prüfung der Netzwerkverkabelungsliste stellten wir fest, dass das Top-Level-Design der Netzwerkstruktur falsch war: Anstatt einheitlich zu sein, war die Struktur in acht getrennte Netzwerke ohne gemeinsamen Routing-Pfad unterteilt. Nach der Neuverkabelung haben wir einen Prüfschritt hinzugefügt, um zu überprüfen, ob alle physischen Verbindungen mit dem neuen Design übereinstimmen.
   Schritt 2: Zehntausend Temperaturalarme (Alarm)
   Nach der Lösung des physischen Verkabelungsproblems stellte InfiniBand erfolgreich Verbindungen mit allen InfiniBand-Switches in der Netzwerkstruktur her. Allerdings meldeten fast alle Switch-Ports überhöhte Temperaturen, teilweise über 70 °C, obwohl sie keine Daten übermittelten. Wir haben festgestellt, dass das Problem auf den offenen Raum zwischen den Switches im selben Rack zurückzuführen ist, der dazu führte, dass heiße Luft zurück nach vorne strömte. Unser Rechenzentrumspartner hat uns geholfen, das Problem schnell zu diagnostizieren und eine geeignete Lösung zu entwickeln.
   Schritt 3: 1800 Alarme
   Viele Häfen weisen außerdem hohe Fehlerraten auf oder schwanken zwischen Normal- und Schadenszustand hin und her, was als „Flattern“ bezeichnet wird. Diese Probleme treten nur dann auf, wenn die Ports tatsächlich genutzt werden, sodass sie im Voraus schwer zu erkennen sind, da unsere gesamte Struktur aus 10.000 hochredundanten Links besteht. Unser Rechenzentrumspartner half bei der Reinigung und Neuinstallation der Alarmanschlüsse und wir deaktivierten die verbleibenden Alarm-Transceiver, während wir auf den Austausch warteten.
   Obwohl InfiniBand gegenüber Hardwareausfällen resistent ist, funktionieren Funktionen wie adaptives Routing nicht mehr zuverlässig, um den gelegentlichen Verbindungsverlust auszugleichen, sobald etwa 10 % der Fabric ausfallen.
   Während dieser Zeit haben wir erfolgreich ein Multi-Node-Training mit 100 bis 200 Maschinen durchgeführt. Unser Prozess ist etwas improvisiert: Manchmal starten wir eine zufällige Gruppe von Knoten, beobachten ihre Leistung und versuchen dann, so viele wie möglich davon am Laufen zu halten.Mit dieser Methode können wir eine zuverlässige Teilmenge der InfiniBand-Netzwerkstruktur finden. Dies ist jedoch sehr schwierig, da wir jedes Mal den für das Training verwendeten Knotensatz und damit die standardmäßigen InfiniBand-Links ändern müssen.
   Schritt 4: InfiniBand Burning
   Um InfiniBand-Probleme effizienter zu diagnostizieren, haben wir eine Arbeitslast für den gesamten Cluster entworfen, die so viele Daten wie möglich gleichzeitig über jeden Port in der gesamten Fabric überträgt. Dies unterscheidet sich von der Ausführung einer großen Gesamtlast im gesamten Cluster, die den Einsatz von NCCL erfordert, um die Kommunikation zwischen einzelnen Knoten zu optimieren, indem NVLink für die GPU-Kommunikation über Server-PCIe-Module (SXM)-Steckplätze verwendet wird.
   Stattdessen haben wir uns für einen Brute-Force-Ansatz entschieden und hatten mit Leichtigkeit Erfolg. UFM beginnt mit der Ausgabe von Warnmeldungen, wenn das Datenübertragungsvolumen an den meisten Ports 97 % der theoretischen Kapazität überschreitet und einige Switches vorübergehend ausfallen. Jeder Port, von dem wir dachten, dass er bis zum Ende des Tages überstanden hat, war robust genug, und der Rest wurde deaktiviert oder bis zur Reparatur entfernt.
   Schritt 5: GPUDirect RDMA
   Um GPU-Kommunikation ohne CPU-Rechenaufwand zu ermöglichen, aktivieren wir eine Funktion namens GPUDirect RDMA, die eine direkte Kommunikation zwischen InfiniBand-Netzwerkkarten ermöglicht. Dies umfasst zwei wichtige Schritte:
4. Starten Sie ein zusätzliches Kernmodul.
5. Stellen Sie sicher, dass der PCIe Access Control Service (ACS) deaktiviert ist, um ein sofortiges Einfrieren zu verhindern.
   Schritt 6: Verstärken Sie den „goldenen“ Server.
   Zu verwenden beim Aufbau eines GPU-Clusters mit Wenn Sie die neueste Hardware verwenden, gilt als Faustregel: Ungefähr 3 % der Maschinen werden jede Woche Probleme haben. Seien Sie also vorbereitet.
   Allerdings muss man es erklären: Nicht jede Maschine hat ein einheitliches Ausfallrisiko von 3 %, aber bei einer kleinen Anzahl unbehandelter Maschinen treten immer wieder verschiedene Probleme auf, bis sie ordnungsgemäß repariert werden. Dies unterstreicht die Vorteile einer großen Anzahl von Maschinen in derselben Netzwerkstruktur. Anstatt also einfach zufällige Maschinen zu finden, auf denen wir groß angelegte Schulungen durchführen können, um zu sehen, was kaputt geht, konzentrieren wir uns auf die Skalierung von Servern, die als zuverlässig gelten, die „goldenen“ Server.
   Schritt 7: Wartung
   Die Wartung von InfiniBand umfasst in erster Linie die Reaktion auf UFM-Alarme, den Austausch fehlerhafter Kabel und Transceiver sowie gelegentlich die Diagnose schwierigerer Fehler (z. B. Schalterausfälle). Es gibt normalerweise zwei Faktoren, die zu umfangreichen Wartungsarbeiten führen:
6. Firmware-Updates, insbesondere wenn nur die Hälfte des Clusters das Update abgeschlossen hat, kann dies zu einer Beschädigung des UFM-Status führen und einen UFM-Neustart auf allen InfiniBand-Switches erforderlich machen.
   2. Gleichzeitiger massiver Neustart von GPU-Boxen, der den UFM-Status mit einer großen Anzahl von Updates überfluten kann und auch einen Neustart des UFM-Dienstes erfordert.
   Sicherstellen, dass die Maschine völlig funktionsfähig ist
   Während dieses Prozesses haben wir mehrere Möglichkeiten entdeckt, wie einzelne Maschinen fehlerhaft funktionieren oder das Training verlangsamen können. Viele dieser Fehlermodi sind nicht sofort erkennbar, daher haben wir eine Reihe von Gesundheitsprüfungsskripten geschrieben, um zu überprüfen, ob der Host fehlerfrei genug ist. Wir haben den Code hier veröffentlicht: https://github.com/imbue-ai/cluster-health
   Bitte beachten Sie, dass viele dieser Gesundheitsprüfungen spezifisch für unsere Laufzeitumgebung sind und nicht unbedingt mit der zugrunde liegenden Hardware zusammenhängen. Dies ist auch nicht unbedingt der Fall einfach zu reparieren oder zu automatisieren. Dies war beabsichtigt: Um das Gesamtziel zu erreichen, unsere Maschinen für die Schulung vorzubereiten, wollten wir einen einzigen Einstiegspunkt, der eine klare Frage mit „Ja“ oder „Nein“ beantwortet und eine beliebige Anzahl feiner Details zusammenfasst.
   GPU-Gesundheitscheck
   Wir prüfen, ob die Anzahl der GPUs korrekt ist, die ECC-Prüfung (Error Correction Code) aktiviert ist und keine ECC-Fehler vorliegen. Wir haben außerdem überprüft, ob die NVLink-Topologie (die GPUs miteinander verbindet) aktiv und fehlerfrei ist.
   Disk Space Health Check
   Wir prüfen, ob die Speicherplatzauslastung des Hosts 95 % überschreitet.
   Docker Health Check
   Wir haben überprüft, ob Docker den Container mit angeschlossener GPU ausführen kann (d. h. ob die NVIDIA Container Runtime ordnungsgemäß funktioniert) und außerdem überprüft, ob der Docker-Container für die Überwachung/Analyse aktiviert wurde und die richtigen Hostberechtigungen erhalten hat .
   Dmesg Health Check
   Wir haben dmesg auf Hardware-Xids- oder SXid-Fehler überprüft (Fehler, die durch NVIDIA-GPUs oder NVIDIA-Switches zwischen GPUs verursacht werden). Wir lesen auch alle dmesg-Protokollzeilen, um zu überprüfen, ob sie alle in die Liste „gemeinsame/erwartete Protokollzeilen“ eingeordnet werden können.
   iDRAC-Gesundheitsprüfung
   Wir haben die Maschine auf iDRAC-Fehler überprüft und dabei nicht schwerwiegende Fehlermeldungen ignoriert. Dies ist eine spezielle Prüfung für Dell-Computer und daher nicht in unserem Open-Source-Code enthalten.
   Disk Health Check
   Wir haben überprüft, ob zpool installiert ist, dass Docker ordnungsgemäß damit verbunden ist und dass es tatsächlich darauf zugreifen kann, ohne die CPU zu blockieren.
   InfiniBand Health Check
   Wir prüfen, ob die InfiniBand-Fehlerraten steigen und/oder die Treiber-Firmware veraltet ist.
   Nvlink Health Check
   Wir prüfen, ob auf dem Computer NVLink-Fehler vorliegen. In der Praxis scheint dies nicht zu Trainingsausfällen zu führen, kann aber zu einer Verlangsamung des Trainings führen.
   GDR-Gesundheitscheck
   Wir haben überprüft, ob GDR auf dem Computer aktiviert ist.
   VBIOS-Gesundheitscheck
   Wir haben überprüft, ob die VBIOS-Version der GPU und die H100-Baseboard-Firmware auf dem neuesten Stand sind.
   Flint Health Check
   Wir haben flint und hca_self_test verwendet, um zu überprüfen, ob der Mellanox OFED-Treiber, die Netzwerkkarten-Firmware und die Transceiver-Firmware die richtigen Versionen haben und dass sie für den NVIDIA-Treiber korrekt kompiliert sind.
   PSB-Gesundheitscheck
   Wir haben die PCIe-Geräte abgefragt, um zu überprüfen, ob die Geschwindigkeit und Breite der Verbindung zwischen GPU, PSB (PCIe Switch Bus) und Netzwerkkarte unseren Erwartungen entsprach. Wir haben auch überprüft, ob die Switch-Firmware auf dem neuesten Stand ist. Dieses Skript wurde von Dell und nicht von Imbue entwickelt, daher können wir es derzeit nicht weitergeben.
   Zusätzlich zu diesen schnellen Gesundheitsprüfungen führen wir auch einige komplexere Gesundheitsprüfungen durch, darunter:
   Initialisierung von Matrixberechnungen über PyTorch und Messung der NVLink-Bandbreite sowie der GPU-Rechengeschwindigkeit und des Speichers. Wir setzen die entsprechenden GDR-Flags, um InfiniBand und NVLink zu testen.
   Verwenden Sie ib_write_bw und –use_cuda, um Daten über die IB-Karte zu senden und die Bandbreite der PCIe- und InfiniBand-Karte zu messen. Dieser Vorgang dauerte über einen längeren Zeitraum (ca. 15 Minuten), um sicherzustellen, dass die flatternde InfiniBand-Verbindung identifiziert wurde.
   Führen Sie einen Multi-Node-Diagnoselauf durch, um die NCCL-Initialisierungsfähigkeiten zu überprüfen und festzustellen, ob es zufällig zum Stillstand kommt. Wenn es zu Verzögerungen kommt, fügt unser gespaltener NCCL-Code eine zusätzliche Protokollierung hinzu. Es dauert 12 bis 24 Stunden, bis ein Problem erkannt wird. Daher führen wir dies normalerweise nur auf neuen Knoten aus oder wenn wir ein Problem vermuten.
   Überprüfen Sie den DCGM-Export auf GPU-Taktdrosselungsereignisse (mit Ausnahme erwarteter gpu_idle und power_cap). Um diese Stromereignisse zu überprüfen, besteht die beste Möglichkeit darin, ein Training mit mehreren Knoten durchzuführen, bei dem alle GPUs, InfiniBand-Karten sowie CPUs und Festplatten gleichzeitig überprüft werden.
   Diagnose häufiger Trainingsprobleme
   Sobald die Hardware ordnungsgemäß funktioniert, können Sie mit dem Training beginnen.
   In diesem Abschnitt werden einige spezifische Debugging-Schritte und Erkenntnisse vorgestellt, die auf unseren Erfahrungen bei der Durchführung großer Sprachmodellschulungen auf unserem Cluster basieren.
   Absturz beim Start
   In gewisser Weise ist dies der beste Fehler, dem Sie begegnen können, da er (theoretisch) einfach zu reproduzieren und zu iterieren ist.
   Wir haben zunächst überprüft, ob unser Code mit der richtigen Version, Konfiguration und den richtigen Umgebungsvariablen ausgeführt wurde. Obwohl dies grundlegend ist, fanden wir dies von entscheidender Bedeutung: sicherzustellen, dass der Startup-Schulungsprozess reproduzierbar und leicht zu überprüfen ist. Ein wichtiger Grund ist, dass Zwischenabstraktionen wie Docker-Image-Caching oder undurchsichtige geheime Konfigurationen Verwirrung stiften können.
   Eine weitere grundlegende Überprüfung, die wir durchführen, besteht darin, sicherzustellen, dass alle Maschinen online sind und die ausgegebenen Stack-Traces oder Protokolle einfach aggregiert und überprüft werden können. Wir haben die Software-Stacks Loki, Prometheus und Grafana verwendet, aber jedes geeignete SaaS-Tool zur Protokollaggregation oder -verfolgung reicht aus. Da diese Trainingsläufe synchron und verteilt sind, führt der erste Fehler häufig zu einer Kaskade unabhängiger Fehler. Auch hier können Health Checks dabei helfen, Fehler wie eine beschädigte Festplatte oder eine fehlende oder ungültige GPU sofort zu erkennen.
   Wir haben ein System entwickelt, das im Falle eines Fehlers automatisch neu startet, wodurch die Protokoll- und Fehlerzusammenfassung noch wichtiger wird, um verwirrende Fehler aus verschiedenen Neustarts zu vermeiden. Zu den häufigsten Fehlern, auf die wir stoßen, gehören:
   1. „Die Vorwärtsreihenfolge ist je nach Rang unterschiedlich: Rang 0 erfasst alle 43 Parameter, während Rang 1228 alle Parameter erfasst.“ Wir fanden, dass dies eine seltsame Funktion der Fully Sharded Data Parallel (FSDP)-Implementierung von PyTorch war, die mit einem Neustart behoben wurde.
   2. GPU-Out-of-Memory-Fehler (OOM), der so aussieht: „CUDA nicht genügend Speicher. Versucht zuzuordnen …“ Durch mehrmaliges Überprüfen unserer Konfiguration und unseres Codes und Rückgängigmachen kürzlicher Codeänderungen (aufgrund inkonsistenter PyTorch-Gerätespezifikationen). während des Startvorgangs (was korrekterweise zu einer übermäßigen Auslastung der GPU Nr. 0 führt) haben wir diese Probleme behoben.
   3.CPU/RAM Out of Memory (OOM)-Fehler Diese Fehler sind in Fehlerprotokollen nicht leicht zu finden und können normalerweise über das Dmesg-Protokoll des Hosts außerhalb des Docker-Containers erkannt werden. Wenn OOM Killer aufgerufen wird, um einen gespaltenen Prozess oder Netzwerk-Peer zu stoppen, können wir sehen, dass sie sich hauptsächlich als CalledProcessError oder ConnectionError manifestieren. Wenn ein OOM-Killer-Aufruf von dmesg erkannt wird, brechen wir lieber einfach die Gesundheitsprüfung ab und starten die Box neu. Wir haben auch unsere Codepfade auf eine angemessene manuelle Speicherbereinigung überprüft (weiter unten finden Sie einen Abschnitt zum Deaktivieren dieser Funktion) und auch auf unerwartete Versuche, Tensoren zu berechnen oder auf die CPU zu verschieben.
   Absturz während des Trainings
   Die erste Aufgabe besteht darin, den automatischen Betrieb des Systems zu aktivieren, sodass alle Gesundheitsprüfungen automatisch erneut durchgeführt und dann neu gestartet werden können, wenn keine fehlerhaften Hosts gefunden werden. Wir sind auf einige zufällige Hardwarefehler gestoßen, darunter Xid- und SXid-Fehler; diese konnten den Lauf abstürzen lassen, ohne dass ein sinnvoller Python-Stack-Trace ausgegeben wurde. Einige Probleme, wie z. B. die Neuzuordnung von Zeilen, können durch einen Neustart behoben werden. Andere, wie z. B. nicht korrigierbare ECC-Fehler, erfordern häufig eine Wartung der Hardware oder den Austausch von Teilen.
   Darüber hinaus haben wir festgestellt, dass auch fehlerhafte Trainingsdaten zu Abstürzen führen können. Wenn sich beispielsweise ein sehr großes einzelnes Dokument im Korpus befindet, kann dies zu einem Fehler wegen unzureichendem Arbeitsspeicher auf der GPU oder CPU führen.Um dieses Problem zu vermeiden, haben wir einen vollständig deterministischen Datenlader implementiert, der jeden Absturz durch die Verknüpfung mit einer Epoche oder Schrittnummer leicht reproduzierbar macht. Wir haben festgestellt, dass das Deaktivieren des Datenladens oder das Ersetzen gefälschter Daten (z. B. Nulldaten) dabei hilft, zu bestätigen, ob die Daten die Ursache des Fehlers sind.
   Schließlich ist es auch hilfreich, Netzwerk- und allgemeine Knotenzustandsstatistiken über metrische Aggregationsmethoden aufzuzeichnen. Probleme wie eine kurze Ethernet-Verbindungsunterbrechung oder ein geringer Speicherplatz auf der Festplatte erscheinen möglicherweise nicht als nützliche Fehlermeldung, können aber leicht mit den erfassten Daten in Zusammenhang gebracht werden.
   Hängt ohne Stack-Traces (und möglicherweise spätere Zeitüberschreitungen)
   Das Debuggen dieser Art von Fehlern kann aufgrund des Mangels an hilfreichen Informationen und der Schwierigkeit, sie zuverlässig zu reproduzieren, frustrierend sein.
   Einer der einprägsamsten Fehlertypen wird von einer Fehlermeldung wie dieser begleitet:
   

   Watchdog caught collective operation timeout:WorkNCCL (SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout (ms)=600000) ran for 600351 milliseconds before timing out

   Nach dem Login kopieren
   
   und diese Fehlermeldung wird von allen GPU-Workern im Trainingslauf ausgegeben.

Das bedeutet, dass ein oder mehrere Hosts den NCCL-Vorgang nicht abschließen konnten oder die NCCL- und InfiniBand-Verbindungen abgestürzt sind, was dazu führte, dass alle anderen Hosts gleichzeitig bei einem Tensor-Vorgang hängen blieben, bis das NCCL_TIMEOUT-Timeout erreicht wurde. Aufgrund der Art der NCCL-Softwarebibliothek ist es leider schwierig herauszufinden, welcher Host das Problem verursacht.

Wir haben einige Änderungen an der Protokollierung der NCCL-Softwarebibliothek vorgenommen, siehe unsere gespaltene Version: https://github.com/boweiliu/nccl. Dies kann die Nachrichten oder Vorgänge, die bei einem Absturz ausgeführt werden, möglicherweise besser erkennen lassen und so feststellen, welcher Host oder welche GPU möglicherweise die Ausführung blockiert.

Bitte beachten Sie, dass wir zur Identifizierung von Hosts, die sich schlecht verhalten, häufig herausfinden müssen, welche Hosts bestimmte Protokollmeldungen nicht generieren. Das Fehlen solcher Meldungen weist darauf hin, dass der Worker auf diesem Host in Verzug geraten ist oder abgestürzt ist.

Andere nicht reagierende Situationen ohne verfügbare Fehlermeldungen hängen normalerweise mit Hardwareproblemen zusammen, wie z. B. den zuvor erwähnten Xid/SXid/ECC-Fehlern, die dazu führen, dass der NVIDIA-Treiber oder der NVIDIA Docker-Kommunikationstreiber abstürzt. Um NCCL-Hänge von Treiber-Hängen und Rennbedingungen oder Deadlocks im Python-Code zu unterscheiden, verwenden wir Tools wie Py-Spy und den GNU Project Debugger (GDB), um festgestellte blockierte Prozesse in Echtzeit zu debuggen. Bei diesem Ansatz wurde ein spezifisches Problem entdeckt: Aufgrund eines Konfigurationsfehlers in den Python-Thread-Einstellungen konnten wir auf einigen Hosts, die in der Phase des Initialisierungscodes vor PyTorch auf eine Race Condition stießen, acht Multithread-NCCL-GPU-Prozesse nicht korrekt starten.

• Trainingsverlangsamung (gemessen durch MFU)

Der Mangel an Werkzeugen macht diese Art von Problem noch frustrierender als das vorherige. Zusätzlich zur Verwendung von Py-Spy, Stack-Trace-Inspektion und GDB haben wir auch NVIDIA Nsight und Profiling-Tools eingesetzt, von denen einige in stark verteilten Umgebungen schwierig zu verwenden sind.

Leider gibt es viele Gründe für eine allgemeine Verlangsamung oder langsamere Geschwindigkeit als die zuvor gezeigte Modell-Gleitkomma-Nutzung (MFU).

Zunächst erweist es sich als sinnvoll, Konfigurations-, Code- und Umgebungsvariablen mehrfach zu überprüfen. Zu den aufgetretenen Fehlern gehören die Ausführung des falschen Modells, die falsche Stapelgröße, falsche UFM- oder NCCL-Einstellungen sowie CUDA_DEVICE_MAX_CONNECTIONS-Fehler. Dies führt zu einer suboptimalen Leistung.

Wir finden es auch nützlich, die momentane MFU (d. h. pro Charge) zu messen (anstelle geglätteter oder gefensterter Durchschnittswerte), da ungeglättete MFU-Kurven oft bei der Diagnose von Problemklassen helfen. Zu den Problemen, die zu einer Verlangsamung des Trainings führen, gehören:

• Sofortiges Starten des Trainings bei einem sehr niedrigen MFU (weniger als ein Zehntel des erwarteten Werts) und stabiles Bleiben

Dies ist höchstwahrscheinlich ein Hardwareproblem mit der InfiniBand-Netzwerkverbindung, wie z die T2- oder T3-Schicht Der Switch stürzt ab. Auch Hardwareprobleme zwischen der GPU und der Netzwerkkarte können diese Situation verursachen, für die dmesg einen Fehler wie diesen meldet: PCIe x16-Lanes begrenzt durch…

• Starten Sie das Training sofort ab 30 % der erwarteten MFU und bleiben Sie stabil

Der Grund Möglicherweise hat der Host falsche GDR-Einstellungen (NVIDIA-Peer-Speicher) oder falsche GDR-Umgebungsvariablen.

• Beginnen Sie das Training sofort bei etwa 60–80 % der erwarteten MFU und bleiben Sie stabil

Der häufigste Grund ist eine schlechte InfiniBand-Verbindungsqualität oder ein Ausfall, insbesondere ein einzelner GPU-Ausfall im Zusammenhang mit der InfiniBand-NIC, was zu NCCL Try Routing führt Datenverkehr über lokalen NVLink und Verwendung der Netzwerkkarte auf einer anderen GPU auf demselben Host. Dieses Problem kann auch durch CPU-Drosselung verursacht werden, was auf einigen Hosts eine Anpassung der BIOS-Einstellungen erfordert.

• Plötzliche enorme Verlangsamung (Verlangsamung um das 10-fache) bei der Verarbeitung bestimmter Datenmengen, und das passiert ziemlich oft

Hier geht es im Grunde nur um Checkpointing oder Auswertung – dies kann durch Überprüfen der Anzahl der Epochen oder Schritte überprüft werden. Wenn Sie automatische Benachrichtigungen einrichten, wenn die MFU abnormal ist, kommt es ärgerlicherweise zu vielen Fehlalarmen.

...

Die häufigste Ursache scheint zu sein, dass andere CPU-intensive Arbeitslasten für einen laufenden Host geplant sind. Wir haben festgestellt, dass es einfacher ist, die CPU anhand der PID grob zu überwachen, anstatt Profilierungstools zur Identifizierung bestimmter Hosts zu erstellen. Die Ursache können gelegentliche Netzwerkkonnektivitätsprobleme sein, beispielsweise Engpässe beim Datenladeprogramm. Wir haben Metrikdaten für Datenlasten, Prüfpunkte und jeglichen Nicht-NCCL-Code überwacht und Python-Code-Timing-Protokolle hinzugefügt, die sich als sehr zuverlässig erwiesen haben.

• MFU wird während des Betriebs allmählich langsamer, geht aber nach jedem Neustart wieder auf 100 % zurück

Theoretisch könnte die Ursache ein Hitzestau am Schalter sein, aber wir haben so etwas noch nie erlebt. Mithilfe von Python- und NVIDIA-Profilern haben wir jedoch festgestellt, dass die Ursache für den Leistungsabfall offenbar in der automatischen Speicherbereinigung liegt.



Debug-Durchsatz sinkt

Beim Debuggen zur Behebung dieser Verlangsamungen stellten wir fest, dass der Durchsatz fast zwangsläufig regelmäßig sinken würde. Mit fortschreitender Ausbildung wird sich dieser Rückgang zunehmend auf das verteilte Rechnen auswirken. Dies veranlasste uns zu der Vermutung, dass die Ursache des Absturzes mit der automatischen Speicherbereinigung zusammenhängen könnte – ein Verdacht, den wir durch Analysen und Tests bestätigten. Als wir die automatische Garbage Collection deaktivierten und die Garbage Collection auf allen Hosts nur in bestimmten Intervallen einstellten, verschwand dieser Durchsatzabfall.

Wir verwenden FSDP, einen synchronen verteilten Trainingsalgorithmus basierend auf ZeRO-3. Während eines Blockierungsvorgangs kann ein einzelner Workerprozess, der die Garbage Collection ausführt, alle anderen Worker verlangsamen. Wenn Sie Hunderte von Arbeitsprozessen haben, kann dies zu erheblichen Verlangsamungen führen.

Die Leistung ist zunächst gut, fällt dann plötzlich ab (bis zu 70 % des erwarteten Werts) und setzt sich mit hoher Frequenz fort (alle 15 Sekunden).

Wir haben beobachtet, dass dies mit dem „Taktdrosselungsgrund“ der NVIDIA-GPU zusammenhängt, der dazu führen kann NVIDIA DCGM löst dieses Problem mit entsprechenden Einstellungen. Dieses Problem kann durch thermische Probleme (hohe GPU-Temperatur oder Ausfall/reduzierte Wirksamkeit des Konsolenlüfters) oder einen Ausfall der Stromversorgung verursacht werden. Wenn wir außerdem alle 8 GPU-Auslastungen und 8x NIC-InfiniBand-Auslastungen zusammen mit CPU/RAM/Festplatte maximieren, haben einige unserer Hosts mit spezifischer Stromversorgungshardware Spannungsprobleme, nutzen sie aber nur alle (normalerweise nur). eigentlicher Trainingslauf).

Korrelation der Leistungsprobleme

• Gute Leistung, aber mehr Rauschen als üblich (Hochfrequenzvariation des weißen Rauschens zwischen 90 % und 100 % der erwarteten MFU)

Dies hängt auch mit der InfiniBand-Hardware zusammen, aber normalerweise gibt es ein gewisses Maß Es kommt zu Leistungseinbußen oder Jitter aufgrund der Verbindungen auf höheren Schichten im Netzwerk und nicht aufgrund der weniger redundanten Hosts zur T2-Schicht.

Leider lassen sich viele dieser Probleme nur schwer einem bestimmten Host zuordnen, und InfiniBand-bezogene Probleme sind aufgrund der topologiebewussten Natur der InfiniBand-Switch-Technologie besonders schwer zu lokalisieren. InfiniBand scheint benachbarte Hosts im InfiniBand-Fat-Tree-Design zu bevorzugen, während UFM Pakete mit asymmetrischen Verbindungsgeschwindigkeiten weiterleiten kann.

Vollständigkeitscheckliste zum Debuggen von Durchsatzproblemen

Das Folgende ist eine einfache Zusammenfassung/ein Flussdiagramm/eine Vollständigkeitscheckliste zum Debuggen von Durchsatzproblemen:

• Hat dieses System zuvor ordnungsgemäß funktioniert?
• Welche Änderungen haben Sie kürzlich vorgenommen (z. B. Code zusammenführen, Treiber aktualisieren)?
• Ist der Host, den Sie betreiben, gesund? Laufen alle Ihre abhängigen Dienste ordnungsgemäß, einschließlich SaaS von Drittanbietern wie Docker Hub, GitHub usw.?
• Sind Sie sicher, dass der jetzt ausgeführte Code, die Umgebung, die Konfiguration, die Version, die Hostliste, die Rangfolge und der zufällige Startwert genau mit dem letzten Mal identisch sind? (Wenn eine solche Prüfung durchgeführt werden kann.)
• Kann das Problem reproduziert werden? In welcher Beziehung steht
• zu anderen Dingen? Andere Prozesse? Täglich geplante Crontab-Aufgaben? Host oder DCGM- oder UFM-Indikator?
• Misst Ihr Tool diese Kennzahlen korrekt?
• Besteht das Problem weiterhin, wenn eine reduzierte Version des Codes ausgeführt wird (Verwendung eines kleineren Modells, gefälschte Daten, keine Prüfpunkte zum Speichern oder Laden)?

Verbesserte Infrastruktur-Tools

Nach Abschluss der oben genannten Schritte können Sie beim Training Ihres Modells eine gute Leistung erzielen ... zumindest bis etwas kaputt geht.

In diesem Abschnitt werden einige Tools und Systeme vorgestellt, die ein konsistentes und stabiles Training gewährleisten und dabei idealerweise so wenig menschliches Eingreifen wie möglich erfordern. Da unser Team klein ist, verfügen wir nicht über genügend Arbeitskräfte, um manuelle Reparaturen durchzuführen. Deshalb möchten wir auch diesen Prozess so weit wie möglich automatisieren.

Fast alle Probleme, auf die wir während dieses Prozesses gestoßen sind, sind auf den Ausfall von Maschinen oder Netzwerkkomponenten zurückzuführen. Diese Art von Ausfällen kommt in großen Clustern häufig vor. Daher besteht unser Ansatz darin, die ausgefallenen Maschinen- und Netzwerkkomponenten automatisch zu deaktivieren und eine Reparaturanfrage zu senden.

Maschinenausfall

Wir haben ein System entwickelt, das automatisch vom letzten Kontrollpunkt neu startet, wenn ein Lauf abstürzt. Bei diesem Neustartprozess wird zunächst jede verfügbare Maschine auf ihren Zustand überprüft und dann wird jede Maschine basierend auf den Ergebnissen der Gesundheitsprüfung, die sie besteht, klassifiziert. Anschließend wird versucht, das Training auf der fehlerfreisten Maschine neu zu starten.

Netzwerkkomponentenfehler

Alle von uns beobachteten Netzwerkfehler waren von UFM erkennbar und wurden im UFM-Ereignisprotokoll protokolliert. Daher war die Antwort einfach: Analysieren Sie das UFM-Protokoll und ergreifen Sie die entsprechenden Maßnahmen.

Das UFM-Ereignissystem ist sehr komplex und enthält Dutzende von Ereignistypen. In der Praxis stellten wir jedoch fest, dass nur wenige Ereignisse problematisch waren, meist im Zusammenhang mit Verbindungsausfällen oder Techniken mit hohem Symbolfehler. Nachdem wir diese Ereignisse identifiziert haben, können wir Skripte schreiben, um die UFM-Ereignisprotokolle zu analysieren, die mit den jüngsten Ereignissen verbundenen Links und Ports zu deaktivieren, Wartungsaufträge für diese Netzwerkkomponenten anzufordern und diese Komponenten nach Abschluss der Wartung wieder zu aktivieren.

Lokales Bilddateisystem

Bei diesen groß angelegten verteilten Schulungen wurde seit langem festgestellt, dass die Datenaustauschgeschwindigkeit zwischen dem Cluster und Ethernet einen großen Engpass darstellt. Die Bandbreite einer gemeinsam genutzten Ethernet-Verbindung beträgt etwa 10 Gbit/s; diese kann schnell ausgelastet sein, wenn Hunderte von Mitarbeitern gleichzeitig Datensätze herunterladen und Prüfpunkte modellieren.

Zu diesem Zweck haben wir beschlossen, ein lokales Dateisystem in unserem Cluster als Spiegel des Cloud-Speichers aufzubauen, bei dem es sich im Wesentlichen um einen Cache-Speicherplatz handelt, der die Menge der aus S3 gelesenen Dateien reduzieren kann. Um die Cluster-Abwanderung zu berücksichtigen (d. h. wenn eine Maschine aus Wartungsgründen deaktiviert oder ersetzt wird), verfügen wir über drei Kopien jeder Datei und verwenden konsistentes Hashing, um die Last gleichmäßig zu verteilen und die Leistung während der Cluster-Abwanderung zu maximieren. Reduzieren Sie die Dateibewegung erheblich. Da der Cluster nur über begrenzten Speicherplatz verfügt, mussten wir Tools entwickeln, um den Lebenszyklus von Dateien zu verfolgen und Dateien zu löschen, die nicht mehr nützlich waren.

Lokale verteilte Docker-Registrierung

Wir haben Kraken verwendet, eine großartige Open-Source-Software für die Peer-to-Peer-Übertragung von Docker-Images. Wir hatten nahezu keine Probleme mit der Software, was für uns angesichts der Komplexität unserer Aufgaben und Umsetzung durchaus überraschend war. Tool-Adresse: https://github.com/uber/kraken

Verschiedene Tools zur Leistungsüberwachung

Wir haben den Standard-Torch-Analysator und NVIDIAs Nsight Systems eingerichtet. Letzteres hilft uns, die genaue Zeit zu verstehen, die für Vorwärts-/Rückwärtsdurchläufe und die NCCL-Kommunikation erforderlich ist, und hilft uns darüber hinaus zu bestimmen, ob eine bestimmte Modellgröße und Anzahl von Arbeitern zu einem Engpass werden. Allerdings ist die Verwendung von Nsight Systems etwas schwierig, da es die Ausführung von Docker im privilegierten Modus erfordert, was das Deaktivieren von Sicherheitsüberprüfungen im Zusammenhang mit Leistungsüberwachungsereignissen erfordert, und das Speichern seiner Konfiguration erfordert oft das Stoppen des gesamten Trainingsprozesses.

Darüber hinaus haben wir Tools geschrieben, um langsame Trainingsdaten-Batches zu erkennen und deren mögliche Ursachen zu verstehen. Wir fanden das nützlich. Eines der nützlichsten Tools überwacht, wie lange jeder Stapel dauert, und verwirft den Stack-Trace des Workers, wenn ein Stapel zu langsam ist. Dies erleichtert das Auffinden von Hosts mit geringfügigen Hardware- oder Softwareproblemen.

Teilen Sie Maschinen in verschiedene Gruppen ein, um fehlerhafte Hosts zu lokalisieren.

In den ersten Monaten der Verwendung dieses Clusters (als die Gesundheitsprüfungen noch nicht so gründlich waren wie jetzt) ​​stießen wir oft auf diese Situation: In einer Gruppe A trat eine Fehlfunktion auf Beim Training an der Maschine war jedoch nicht klar, bei welcher Maschine das Problem aufgetreten ist. Um fehlerhafte Hosts zu finden, haben wir Tools entwickelt, die es einfach machen, eine Reihe von Maschinen in verschiedene Gruppen aufzuteilen und auf jeder Maschinengruppe kleinere Schulungen durchzuführen.

Wenn zum Beispiel ein Trainingslauf auf 48 Maschinen fehlschlägt, dann führen Sie ein kleineres Training auf 6 Gruppen mit jeweils 8 Maschinen und dann ein kleineres Training mit 8 Gruppen mit jeweils 6 Maschinen durch. In der Regel schlägt nur ein Durchlauf der beiden Phasen fehl, was uns die Gewissheit gibt, zu dem Schluss zu kommen, dass eine Maschine, die in beiden Phasen ausfällt, fehlerhaft ist.

Reflexion und gewonnene Erkenntnisse

Beim Aufbau und der Wartung der Infrastruktur haben wir einige nützliche Lektionen gelernt:

• Eine nützliche Übung besteht darin, die Position der Maschine zu tauschen. Zur Laufzeit kann es hilfreich sein, 10–20 % mehr Maschinen als erforderlich zu nutzen, damit das Training bei einem Maschinenausfall problemlos wieder aufgenommen werden kann. Durch die Einrichtung eines Cluster-Netzwerks, bei dem jede Maschine eng mit jeder anderen Maschine verbunden ist, können wir jede funktionierende Teilmenge dieser Maschinen nutzen.
• Es lohnt sich, für jeden Hardware- oder Softwarefehler, auf den Sie stoßen, Tests und automatisierte Lösungen zu schreiben, da jedes im Training aufgetretene Problem erneut auftritt. Ebenso lohnt es sich, für jede mehrdeutige Fehlermeldung ein Tool zu schreiben, das den Fehler besser erklärt.
• Reproduzierbarkeit ist der Schlüssel zu exzellenter wissenschaftlicher Forschung. Einer der Grundsätze, die wir sofort übernommen haben, war: „Ändere immer nur eine Sache“, selbst in den einfachsten Dingen.
• Vertrauen, aber auch überprüfen. Wann immer wir externe Tools einsetzen oder neue Leute einstellen (sei es innerhalb oder außerhalb des Unternehmens), überprüfen wir noch einmal, was sie behaupten, insbesondere wenn nachfolgende Schritte von diesen Behauptungen abhängen.

Zusammenfassung

Das Training großer Sprachmodelle erfordert von Anfang an eine komplexe Infrastruktur. Wir befassen uns intensiv mit den Details der Einrichtung unserer Infrastruktur, weil wir glauben, dass es wichtig ist, die von uns betriebenen Systeme vollständig zu verstehen, und weil wir glauben, dass dies effizienter ist.

Nachdem wir den Prozess nun durchlaufen haben, sind wir froh, dass wir diesen Ansatz gewählt haben – die vollständige Kontrolle über unsere Infrastruktur und die Möglichkeit, problemlos auf jeder Abstraktionsebene zu debuggen, haben sich als von entscheidendem Wert erwiesen. Obwohl dieser Prozess viel Überwachung und Iteration erforderte, ermöglichte er uns, ein tiefes Verständnis des zugrunde liegenden Arbeitsablaufs zu erlangen, eine Reihe von Tools zur Gewährleistung der Host-Gesundheit zu erstellen, zu lernen, wie das System automatisiert werden kann, um ein kontinuierliches, reibungsloses Training sicherzustellen, und letztendlich ein System zu erstellen Eine Reihe von Infrastrukturen, die es uns ermöglichen, schnell und iterativ modernste Sprachmodelle zu trainieren.

Dieser Infrastrukturaufbauprozess spiegelt unsere grundlegende Methodik für die Erforschung und Entwicklung von KI-Agenten wider: die Erkundung der Details,

Das obige ist der detaillierte Inhalt vonVon Bare-Metal bis hin zu einem großen Modell mit 70 Milliarden Parametern finden Sie hier ein Tutorial und gebrauchsfertige Skripte. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!