Nachricht

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Ausgewählt von imbue.com

Autor: Imbue-Team

Maschinenherz-Zusammenstellung

Herausgeber: Panda

Wir wissen, dass LLM auf großen Computerclustern unter Verwendung riesiger Datenmengen trainiert wird. Machine Heart hat viele Methoden und Technologien zur Unterstützung und Verbesserung des LLM-Trainingsprozesses eingeführt. 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“, die nicht einmal über ein Betriebssystem verfügen, in einen Computercluster für das LLM-Training verwandelt.

Dieser Artikel stammt von Imbue, einem KI-Startup, das sich zum Ziel gesetzt hat, 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 eine ausführliche Einführung in den gesamten Prozess des Teams zum Aufbau seiner eigenen LLM-Schulungsinfrastruktur und stellt die vielen Tools und Skripte vor, die es geschrieben hat, um die Überwachung, Inspektion und Fehlerkorrektur 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 Originaltext des Imbue-Teamartikels.

Einführung

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 übertraf Zero-Shot-Modelle bei inferenzbezogenen Aufgaben.

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 anderen Teams den Aufbau einer stabilen Infrastruktur für ihr eigenes Modelltraining zu erleichtern.

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 Sie jede Maschine

2. Konfigurieren Sie InfiniBand

3. Stellen Sie sicher, dass die Maschine vollkommen funktionsfähig ist

4. Diagnostizieren Sie häufige Trainingsprobleme

5. Verbessern Sie die Infrastrukturtools

Jeder Schritt wird im Folgenden ausführlich beschrieben.

Hintergrund: Wie es hergestellt wurde

Unser Ziel bei der Durchführung von Berechnungen ist es, ein schnelles Experimentieren mit großen Sprachmodellen sicherzustellen. Dazu benötigen wir eine große Anzahl von Hochgeschwindigkeits-GPUs und eine Hochgeschwindigkeitskommunikation zwischen diesen GPUs.

Dieser Artikel konzentriert sich auf einen Cluster mit 4088 H100-GPUs, verteilt auf 511 Computer, oder 8 GPUs pro Computer. 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 mit 511 GPUs ausgestatteten Hosts 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 blockierungsfrei“, sodass GPUs theoretisch mit maximaler Geschwindigkeit miteinander kommunizieren können. Dazu verwenden wir eine dreischichtige InfiniBand-Netzwerkarchitektur: dreischichtige InfiniBand-Switches. Mit den richtigen Verbindungen kann dieser hohe Durchsatz im gesamten Netzwerk erreicht werden. Die folgende Abbildung zeigt einen Überblick über dieses InfiniBand-Netzwerk:

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 Geschwindigkeit viel langsamer, da die Daten zuerst von der GPU zur CPU und dann über die 100-Gbit/s-Geschwindigkeits-Ethernet-Karte übertragen werden. Obwohl es auch möglich ist, über Ethernet mit einer Technologie namens RDMA over Converged Ethernet (RoCE) zu trainieren, erfordert dies sowohl auf der Hardware- als auch auf der Softwareseite viel zusätzliche Arbeit und ist im Allgemeinen weniger zuverlässig als InfiniBand. Einzelheiten finden Sie in diesem Dokument: https://arxiv.org/pdf/2402.15627

Außerdem gibt es ein sekundäres Ethernet, das nur der Konfiguration und Verwaltung dient und Zugriff auf das BIOS (Basic Input Output System), die Stromversorgung und andere Steuerschnittstellen für Maschinenschnittstellen auf niedriger Ebene bietet. 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.

Im Rest dieses Artikels geht es darum, wie man dafür sorgt, dass alles perfekt und stabil läuft.

Prozess: So verwandeln Sie Bare-Metal in einen voll funktionsfähigen Cluster

Konfigurieren Sie jede Maschine

Nach dem Herstellen der ersten Ethernet-Verbindung zum Cluster über das Verwaltungsnetzwerk werden Zugangsdaten zum Baseboard Management Controller (BMC) abgerufen. 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 zu bedienen, als ob wir persönlich vor Ort wären, und stellt darüber hinaus APIs für den Hardwarezustand, BIOS-Einstellungen und Energieverwaltung bereit.

Wenn diese Komponenten vorhanden sind, können wir die Ärmel hochkrempeln und mit dem Aufbau des Clusters beginnen.

Schritt 0: Konfigurieren Sie zunächst eine Maschine

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. Das iDRAC-Start- und Automatisierungstool verwendet Preboot Execution Environment Protocol (PXE), 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 des gesamten Trainingsprozesses ist das MAAS oft 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 paar Maschinen konfigurierte, konnte ich nichts über apt installieren, da es Probleme bei der Überprüfung des HTTPS-Zertifikats gab, weil die Uhren so unterschiedlich 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: Diagnostizieren Sie die defekte Maschine

Wir haben festgestellt, dass etwa 10 % der Maschinen nicht starteten, was hauptsächlich auf physische Probleme mit dem Server zurückzuführen war. 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 Leitungen, 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 fahren mit den folgenden Einstellungen auf jedem Server fort:

1.Docker (um die Ausführung von Diensten und Schulungsjobs zu vereinfachen)

2. GPU-Treiber für Rechenzentren

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, z. B. GPU-Status, Takt, Auslastung)

5. RAIDZ ZFS-Pool für alle Nicht-Betriebssystemtreiber, der es der Maschine ermöglicht, auch dann weiterzuarbeiten, wenn ein Treiber ausfällt, und gleichzeitig transparente Komprimierung kostenlos zur Verfügung stellt (dies ist besonders nützlich für Nur-Text-Datensätze und sich wiederholende Protokolle – relativ nützlich). Dieses Tool vergrößert den nutzbaren Platz typischerweise um das bis zu Zehnfache im Vergleich zur Nichtverwendung dieses Tools.)

Anschließend führen wir eine grundlegende GPU-Diagnose durch, um festzustellen, ob die GPU im Allgemeinen ordnungsgemäß funktioniert – alles, was nicht funktioniert, führt normalerweise innerhalb weniger Stunden zu Hardwareproblemen.

Während dieser Zeit kam es zu Bandbreitenengpässen, 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. Viele Maschinen sind dazu nicht in der Lage und es treten folgende Probleme auf:

GPU-bezogene Fehler, die im Allgemeinen durch erneutes Einsetzen der GPU-Karte in den Kartensteckplatz behoben werden können: Schieben Sie den 200-Pfund-Server aus dem Rack, entfernen Sie alle Kabel zwischen der Abdeckung und der GPU und entfernen Sie die GPU, installieren Sie dann die GPU neu Schließen Sie 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 < x16“. Nach der Aktualisierung der PCIe-Switch-Bus-Firmware stellten wir fest, dass bei etwa einem Viertel der Hosts die internen PCIe-Kabel neu angeschlossen werden mussten – vermutlich, weil die Kabel zwischen dem Gehäuse und der GPU recht empfindlich sind, was bedeutet, dass diese Kabel bei jeder Wartung der GPU beschädigt werden geschoben oder herausgezogen werden.

Es gab einige verschiedene Ausfälle, von denen auch mehrere Hosts betroffen waren. 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 in MAAS führt und dazu führt, dass das Betriebssystem auf dem falschen Laufwerk installiert wird.

Die Temperaturanzeige ist falsch, was 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 geriet außer Kontrolle und die Arbeitskerne wurden auf 2 GHz begrenzt.

Die direkte GPU-GPU-Kommunikation (GDR oder GPUDirect RDMA Peer Memory Client) kann nicht erfolgreich angewendet werden.

Konfigurieren Sie InfiniBand

Schritt 0: UFM installieren

Ein Vorteil 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)

Nachdem die physischen Verkabelungsprobleme behoben waren, stellte InfiniBand erfolgreich Verbindungen zu 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 herausgefunden, 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 Ports weisen außerdem hohe Fehlerraten auf oder wechseln zwischen normalen und beschädigten Zuständen hin und her, was als „Flapping“ bezeichnet wird. Da unsere gesamte Struktur aus 10.000 hochredundanten Links besteht, treten diese Probleme nur bei tatsächlicher Nutzung der Ports auf und sind daher im Vorfeld nur schwer zu erkennen. 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.

Während 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 führten wir erfolgreich ein Multi-Node-Training mit 100 bis 200 Maschinen durch. 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 die für das Training verwendete Gruppe von Knoten ändern müssen, wodurch sich auch die standardmäßige InfiniBand-Verbindung ändert.

Schritt 4: InfiniBand brennt wie verrückt

Um InfiniBand-Probleme effizienter zu diagnostizieren, haben wir eine Arbeitslast für den gesamten Cluster entwickelt, die so viele Daten wie möglich gleichzeitig über alle Ports in der 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 entschieden wir uns für einen Brute-Force-Ansatz und hatten mit Leichtigkeit Erfolg. UFM beginnt mit der Ausgabe von Warnmeldungen, wenn das Datenübertragungsvolumen auf den meisten Ports 97 % der theoretischen Kapazität überschreitet und einige Switches vorübergehend ausfallen. Jeder Port, von dem wir glaubten, 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 die GPU-Kommunikation ohne CPU-Rechenaufwand zu ermöglichen, haben wir eine Funktion namens GPUDirect RDMA aktiviert, die eine direkte Kommunikation zwischen InfiniBand-Netzwerkkarten ermöglicht. Dies umfasst zwei wichtige Schritte:

1. Starten Sie ein zusätzliches Kernelmodul

2. Stellen Sie sicher, dass der PCIe Access Control Service (ACS) deaktiviert ist, um sofortige Hänger (sofortige Hänger) zu verhindern.

Schritt 6: Erweitern Sie den „Gold“-Server

Um einen GPU-Cluster mit der neuesten Hardware aufzubauen, gilt als Faustregel, dass Sie damit rechnen müssen, dass jede Woche etwa 3 % Ihrer Maschinen ausfallen.

Allerdings ist zu beachten: Nicht jede Maschine hat ein einheitliches Ausfallrisiko von 3 %, sondern eine kleine Anzahl unbehandelter Maschinen hat immer wieder verschiedene Probleme, 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 in der Regel zwei Faktoren, die zu einer groß angelegten Wartung führen:

1. Firmware-Updates, insbesondere wenn nur die Hälfte des Clusters das Update abgeschlossen hat, können zu einem beschädigten UFM-Status führen und einen UFM-Neustart auf allen InfiniBand-Switches erforderlich machen.

2. GPU-Boxen werden gleichzeitig massiv neu gestartet, was möglicherweise eine große Anzahl von Aktualisierungen in den UFM-Status einfügt und auch einen Neustart des UFM-Dienstes erfordert.

Stellen Sie sicher, dass die Maschine vollkommen funktionsfähig ist

Dabei entdeckten wir mehrere Möglichkeiten, wie einzelne Maschinen versagen oder das Training verlangsamen könnten. 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

Beachten Sie, dass viele dieser Integritätsprüfungen spezifisch für unsere Laufzeitumgebung sind und nicht unbedingt mit der zugrunde liegenden Hardware zusammenhängen und auch nicht unbedingt einfach zu reparieren oder zu automatisieren sind. 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-Gesundheitsprüfung

Wir haben überprüft, ob die Anzahl der GPUs korrekt war, die ECC-Prüfung (Error Correction Code) aktiviert war und keine ECC-Fehler aufgetreten sind. Wir haben auch überprüft, dass die NVLink-Topologie (die GPUs miteinander verbindet) fehlerfrei funktioniert.

Überprüfung des Speicherplatzzustands

Wir haben überprüft, ob die Speicherplatzauslastung des Hosts 95 % überschreitet.

Docker-Gesundheitscheck

Wir haben überprüft, dass Docker Container mit angeschlossener GPU ausführen kann (d. h. die NVIDIA Container Runtime funktioniert ordnungsgemäß) und dass die Docker-Container für die Überwachung/Analyse aktiviert sind und über die richtigen Hostberechtigungen verfügen.

Dmesg-Gesundheitscheck

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 „Common/Expected Log Lines“ eingeordnet werden können.

iDRAC-Gesundheitscheck

Wir haben die Maschine auf iDRAC-Fehler überprüft und nicht schwerwiegende Fehlermeldungen ignoriert. Dies ist eine spezielle Prüfung für Dell-Computer und daher nicht in unserem Open-Source-Code enthalten.

Überprüfung des Festplattenzustands

Wir haben überprüft, dass zpool installiert ist, dass Docker ordnungsgemäß damit verbunden ist und dass es tatsächlich darauf zugreifen kann, ohne die CPU zu blockieren.

InfiniBand-Gesundheitscheck

Wir haben überprüft, ob die Fehlerrate von InfiniBand zunahm und/oder ob die Treiber-Firmware veraltet war.

Nvlink-Gesundheitscheck

Wir haben die Maschine auf NVLink-Fehler überprüft. In der Praxis scheint dies nicht zu Trainingsausfällen zu führen, kann aber zu einer Verlangsamung des Trainings führen.

DDR-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.

Gesundheitscheck für Feuerstein

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 wurden.

PSB-Gesundheitscheck

Wir haben die PCIe-Geräte abgefragt, um zu prüfen, ob die Verbindungsgeschwindigkeit und -breite 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 Gesundheitschecks führen wir auch einige komplexere Gesundheitschecks durch, darunter:

Initialisieren Sie Matrixberechnungen über PyTorch und messen Sie die NVLink-Bandbreite sowie die GPU-Berechnungsgeschwindigkeit und den Speicher. 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 lange (ca. 15 Minuten), um sicherzustellen, dass der flatternde InfiniBand-Link gefunden wurde.

Führen Sie einen Diagnoselauf mit mehreren Knoten durch, um die NCCL-Initialisierungsfähigkeit zu überprüfen und festzustellen, ob sie zufällig blockiert. Wenn es Pausen gibt, fügt unser gegabelter NCCL-Code 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 der erwarteten 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.

Diagnostizieren Sie häufig auftretende Trainingsprobleme

Sobald die Hardware ordnungsgemäß funktioniert, kann mit dem Training begonnen werden.

In diesem Abschnitt werden einige spezifische Debugging-Schritte und Erkenntnisse vorgestellt, die auf unseren Erfahrungen bei der Durchführung umfangreicher Sprachmodellschulungen in 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 Grund dafür ist, dass Zwischenabstraktionen wie Docker-Image-Caching oder undurchsichtige geheime Konfigurationen Verwirrung stiften können.

Eine weitere grundlegende Prüfung, die wir durchführen, besteht darin, sicherzustellen, dass alle Maschinen online sind und dass die ausgegebenen Stack-Traces oder Protokolle leicht 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 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 Fehleraggregation noch wichtiger wird, um verwirrende Fehler aus verschiedenen Neustarts zu vermeiden. Zu den häufigsten Fehlern, auf die wir stoßen, gehören:

1. Fehler wie „Die Vorwärtsreihenfolge unterscheidet sich je nach Rang: Rang 0 umfasst alle 43 Parameter, während Rang 1228 alle 1 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 (OOM)-Fehler, der wie folgt aussieht: „CUDA out of Memory. Versucht zuzuordnen …“ Durch mehrmaliges Überprüfen unserer Konfiguration und unseres Codes und Rückgängigmachen kürzlicher Codeänderungen (aufgrund falscher PyTorch-Gerätespezifikationen während). Wir haben diese Probleme behoben.

3. CPU/RAM Out of Memory (OOM)-Fehler Diese Fehler sind im Fehlerprotokoll nicht leicht zu finden und können normalerweise über das Dmesg-Protokoll des Hosts außerhalb des Docker-Containers erkannt werden. Wenn OOM Killer aufruft, 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, Berechnungen durchzuführen oder Tensoren auf die CPU zu verschieben.

Absturz während des Trainings

Die erste Priorität besteht darin, das System so zu automatisieren, dass es alle Integritätsprüfungen automatisch erneut durchführen und dann neu starten kann, wenn kein fehlerhafter Host gefunden wird. Wir sind auf einige zufällige Hardwarefehler gestoßen, darunter Xid- und SXid-Fehler; diese Fehler konnten dazu führen, dass der Lauf abstürzte, ohne dass ein aussagekräftiger Python-Stack-Trace ausgegeben wurde. Einige Probleme, wie z. B. die Neuzuordnung von Zeilen, können durch einen Neustart behoben werden. Andere Probleme, wie beispielsweise nicht korrigierbare ECC-Fehler, erfordern häufig eine Wartung der Hardware oder den Austausch von Teilen.

Darüber hinaus haben wir festgestellt, dass fehlerhafte Trainingsdaten ebenfalls 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, verwenden wir einen vollständig deterministischen Datenlader, der jeden Absturz leicht reproduzierbar macht, indem er an eine Epoche oder Schrittnummer gebunden ist. Wir haben festgestellt, dass das Deaktivieren des Datenladens oder das Ersetzen gefälschter Daten (z. B. reine Nulldaten) dabei hilft, zu bestätigen, ob die Ursache des Fehlers in den Daten liegt.

Schließlich kann es auch hilfreich sein, 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 gesammelten Daten in Zusammenhang gebracht werden.

Hängen ohne Stack-Trace (kann später zu Timeout-Problemen führen)

Aufgrund des Mangels an hilfreichen Informationen zu diesen Problemen und der Schwierigkeit, sie zuverlässig zu reproduzieren, kann das Debuggen dieser Art von Fehlern frustrierend sein.

Eine der einprägsamsten Fehlerarten wird von Fehlermeldungen wie dieser begleitet:

Watchdog hat ein Timeout für kollektive Operationen abgefangen: WorkNCCL (SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout (ms)=600000) lief 600351 Millisekunden lang, bevor es zu einem Timeout kam.

Und alle GPU-Worker im Trainingslauf gaben solche Fehlermeldungen aus.

Dies 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. Leider ist es aufgrund der Art der NCCL-Softwarebibliothek schwierig herauszufinden, auf welchem ​​Host das Problem auftritt.

Wir haben einige Änderungen an der Protokollierung der NCCL-Softwarebibliothek vorgenommen, siehe unsere gespaltene Version: https://github.com/boweiliu/nccl. Dadurch können die Meldungen oder Vorgänge, die bei einem Absturz ausgeführt werden, besser angezeigt werden und so ermittelt werden, welcher Host oder welche GPU möglicherweise die Ausführung verhindert.

Beachten Sie, dass wir zum Erkennen 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 anhand der 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 niedrigere Geschwindigkeit als die zuvor gezeigte Modell-Gleitkomma-Nutzung (MFU).

Erstens erweist es sich als nützlich, Konfigurations-, Code- und Umgebungsvariablen mehrmals 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:

Beginnen Sie sofort mit dem Training bei einem sehr niedrigen MFU (weniger als einem Zehntel des erwarteten Werts) und bleiben Sie stabil

Hierbei handelt es sich höchstwahrscheinlich um ein Hardwareproblem mit der InfiniBand-Netzwerkverbindung, z. B. einen Absturz eines T2- oder T3-Layer-Switches. Hardwareprobleme zwischen der GPU und der Netzwerkkarte können ebenfalls zu dieser Situation führen, für die dmesg einen Fehler wie diesen meldet: PCIe x16-Lanes begrenzt durch…

Beginnen Sie sofort mit dem Training bei 30 % der erwarteten MFU und halten Sie es konstant

Dies kann durch falsche GDR-Einstellungen auf einem Host (NVIDIA-Peer-Speicher) oder falsche GDR-Umgebungsvariablen verursacht werden.

Beginnen Sie sofort mit dem Training bei etwa 60–80 % der erwarteten MFU und halten Sie es konstant

Die häufigste Ursache ist eine schlechte oder fehlerhafte InfiniBand-Verbindungsqualität, insbesondere ein InfiniBand-NIC-bedingter Fehler auf einer einzelnen GPU, der dazu führt, dass NCCL versucht, den Datenverkehr über nativen NVLink zu leiten und die NIC auf einer anderen GPU auf demselben Host zu verwenden. 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 Zehnfache) bei der Verarbeitung bestimmter Datenmengen, was recht häufig vorkommt

Hier geht es im Grunde um Checkpointing oder Auswertung – dies kann durch Überprüfung der Anzahl der Epochen oder Schritte überprüft werden. Ärgerlicherweise werden viele Fehlalarme angezeigt, wenn Sie einen automatischen Alarm einrichten, wenn die MFU abnormal ist.

Plötzliche enorme Verlangsamung (10-facher Rückgang) bei der Verarbeitung bestimmter Datenmengen

Dies geschieht zufällig und ziemlich selten (ungefähr alle 15 Minuten) und wird sofort von einer vollständigen Rückkehr zur guten MFU gefolgt.

Die häufigste Ursache scheint darin zu liegen, 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 Datenlasten, Prüfpunkte und Metriken für jeden Nicht-NCCL-Code überwacht und Zeitprotokolle für Python-Code hinzugefügt, die sich als sehr zuverlässig erwiesen haben.

MFU wird während des Betriebs allmählich langsamer, kehrt jedoch nach jedem Neustart auf 100 % zurück

Theoretisch könnte die Ursache ein Hitzestau am Schalter sein, was wir aber noch nie erlebt haben. Wir haben jedoch Python- und NVIDIA-Profiler verwendet, um festzustellen, dass die Ursache für den Leistungsabfall offenbar in der automatischen Speicherbereinigung liegt.

Beim Debuggen 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 ließ uns vermuten, dass die Ursache des Absturzes mit der automatischen Speicherbereinigung zusammenhängen könnte – eine Vermutung, die wir durch Analysen und Tests bestätigt haben. Als wir die automatische Garbage Collection deaktivierten und die Garbage Collection auf allen Hosts nur in bestimmten Intervallen einstellten, verschwand dieser Durchsatzabfall.

Wir haben einen synchronen verteilten Trainingsalgorithmus FSDP basierend auf ZeRO-3 verwendet. 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 (auf 70 % des erwarteten Werts) und setzt sich mit hoher Frequenz fort (alle 15 Sekunden).

Wir haben beobachtet, dass dies mit „Gründen der Taktdrosselung“ auf NVIDIA-GPUs zusammenhängt, die mit entsprechenden Einstellungen für NVIDIA DCGM behoben werden können. Dieses Problem kann durch thermische Probleme (hohe GPU-Temperatur oder Ausfall/verringerte Wirksamkeit des Host-Lü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).

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

Dies hängt auch mit der InfiniBand-Hardware zusammen, ist jedoch in der Regel auf einen gewissen Leistungsabfall oder Jitter auf den weiter oben im Netzwerk liegenden Verbindungen zurückzuführen und nicht auf die 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.

Im Folgenden finden Sie eine einfache Zusammenfassung/ein Flussdiagramm/eine Vollständigkeitscheckliste zum Debuggen von Durchsatzproblemen:

Hat dieses System vorher ordnungsgemäß funktioniert?

Welche Änderungen haben Sie in letzter Zeit vorgenommen (z. B. Code zusammenführen, Treiber aktualisieren)?

Ist der Host, den Sie ausführen, fehlerfrei? Laufen alle Ihre abhängigen Dienste normal, einschließlich SaaS von Drittanbietern wie Docker Hub, GitHub usw.?

Können Sie sicher sein, dass der Code, die Umgebung, die Konfiguration, die Version, die Hostliste, die Rangfolge und der Zufallsstartwert, den Sie jetzt ausführen, genau mit dem letzten Mal identisch sind? (Wenn eine solche Prüfung implementiert werden könnte.)

Ist das Problem reproduzierbar?

Wie hängt es mit anderen Dingen zusammen? 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 abgespeckte Version des Codes ausgeführt wird (Verwendung kleinerer Modelle, gefälschte Daten, keine Prüfpunkte zum Speichern oder Laden)?

Verbessern Sie die Infrastrukturtools

Sobald Sie die oben genannten Schritte ausgeführt haben, sind Sie auf dem besten Weg, beim Training Ihres Modells eine gute Leistung zu erzielen – zumindest bis etwas kaputt geht.

In diesem Abschnitt werden einige der Tools und Systeme vorgestellt, die verwendet werden, um eine konsistente Schulung zu gewährleisten und dabei im Idealfall so wenig menschliches Eingreifen wie möglich zu erfordern. Da wir ein kleines Team sind, verfügen wir nicht über genügend Arbeitskräfte, um manuelle Reparaturen durchzuführen, daher möchten wir auch diesen Prozess so weit wie möglich automatisieren.

Fast alle Probleme, auf die wir während des Trainings stoßen, 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.

Fehlfunktion der Maschine

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.

Ausfall einer Netzwerkkomponente

Alle von uns beobachteten Netzwerkausfälle wurden von UFM erkannt und im UFM-Ereignisprotokoll protokolliert. Die Antwort war also 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, hauptsächlich im Zusammenhang mit Verbindungsausfällen oder Techniken mit hohem Symbolfehler. Nachdem wir diese Ereignisse identifiziert haben, können wir Skripte schreiben, um das UFM-Ereignisprotokoll 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 Spiegeldateisystem

Bei diesen großen verteilten Schulungen wurde seit langem festgestellt, dass die Geschwindigkeit des Datenaustauschs zwischen dem Cluster und Ethernet einen Engpass darstellt. Die Bandbreite einer gemeinsam genutzten Ethernet-Verbindung beträgt etwa 10 Gbit/s; diese Bandbreite 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 für den Cloud-Speicher 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.

Lokal verteilte Docker-Registrierung

Wir haben Kraken verwendet, eine großartige Open-Source-Software für die Punkt-zu-Punkt-Ü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-Systeme 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 Trainingschargen zu erkennen und deren mögliche Ursachen zu verstehen. Wir fanden das nützlich. Das nützlichste Tool ü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 ausgefallene Hosts zu finden

In den ersten Monaten der Verwendung des Clusters (als die Gesundheitsprüfungen noch nicht so gründlich waren wie jetzt) ​​kam es häufig zu einer Situation, in der beim Training auf einer Gruppe von Maschinen ein Fehler auftrat, aber nicht klar war, bei welcher Maschine das Problem auftrat . Frage. Um fehlerhafte Hosts zu finden, haben wir Tools entwickelt, die es einfach machen, eine Reihe von Maschinen in verschiedene Gruppen aufzuteilen und kleinere Schulungen für jede Maschinengruppe durchzuführen.

Wenn beispielsweise ein Trainingslauf auf 48 Maschinen fehlschlägt, führen Sie einen kleineren Trainingslauf auf 6 Gruppen mit jeweils 8 Maschinen durch und führen Sie dann den kleineren Trainingslauf auf 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

Während des Aufbaus und der Wartung der Infrastruktur haben wir einige nützliche Erkenntnisse gewonnen:

Ein sinnvoller Ansatz besteht darin, den Standort der Maschinen 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 guter wissenschaftlicher Forschung. Einer der großen 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 (ob innerhalb oder außerhalb des Unternehmens), überprüfen wir noch einmal, was sie behaupten, insbesondere wenn nachfolgende Schritte von diesen Behauptungen abhängen.

Zusammenfassen

Das Training großer Sprachmodelle erfordert von Anfang an eine komplexe Infrastruktur. Wir haben uns entschieden, uns intensiv mit den Details der Einrichtung der Infrastruktur zu befassen, 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 abgeschlossen 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 entscheidender Wert erwiesen. Während 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 entwickeln, 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: Erkundung der Details, kontinuierliche Verbesserung bestehender Prozesse und Entwicklung nützlicher Tools und Systeme, um unserem motivierten Team die Bewältigung größerer Herausforderungen zu ermöglichen.