Infrastruktur-Setup und Open-Source-Skripte zum Trainieren eines 70B-Modells auf Bare Metal

 (imbue.com)
1 Punkte von GN⁺ 2024-06-29 | 1 Kommentare | Auf WhatsApp teilen
  • Imbue hat mit einem kleinen Team ein 70B-Parameter-Modell von Grund auf auf eigener Bare-Metal-Infrastruktur trainiert und veröffentlicht die Betriebsabläufe und Skripte vom Cluster-Aufbau bis zur Fehlerbehebung
  • Der Cluster bestand aus 4.088 H100-GPUs und 511 GPU-Servern; pro Server nahmen 8 GPUs über InfiniBand am groß angelegten synchronen Training teil
  • Der tatsächliche Aufbau war ein iterativer Prozess aus Provisionierung einzelner Maschinen, Instandsetzung des InfiniBand-Fabrics, Host-Health-Checks, Diagnose von Trainingsfehlern und Verbesserungen der Automatisierung; dabei mussten etwa 10 % Boot-Fehler bei Maschinen und zahlreiche Port-Warnungen behandelt werden
  • Zu den veröffentlichten Tools gehören Host-Health-Checks, ein NCCL-Logging-Patch, GPU-Stresstests, NVLink- und InfiniBand-Netzwerktests, ein Parser für UFM-Event-Logs sowie ein Skript zum Erzeugen von InfiniBand-Burn-in-Workloads
  • Beim Training großer LLMs kann schon ein einzelner instabiler Host oder Link den gesamten Lauf ausbremsen; daher werden automatische Health-Checks, Fehlerisolierung, Neustarts und Port-Deaktivierung zum Kern eines kontinuierlichen Betriebs

Cluster-Aufbau für das Training eines eigenen 70B-Modells

  • Imbue trainierte über mehrere Monate ein 70B-Parameter-Modell von Grund auf auf eigener Infrastruktur; dieses Modell übertraf zero-shot GPT-4o bei Aufgaben im Bereich Schlussfolgern
  • Der veröffentlichte Umfang umfasst End-to-End-Infrastrukturprozesse vom initialen Booten des Clusters über die OS-Installation bis zur automatischen Fehlerbehebung während des Trainings
  • Die mitveröffentlichten Infrastruktur-Tools sind:
    • Host-level health checks: Skripte, die prüfen, ob ein Host ohne bekannte Fehler für das Training eingesetzt werden kann
    • NCCL-Patch: verbessert, um bei Fehlern und Hängern mehr Logs zu erzeugen
    • GPU stress test: prüft, ob GPUs große Tensoren allozieren und Standardoperationen ausführen können
    • Networking tests: prüfen die NVLink-Kommunikation zwischen GPUs derselben Maschine und die InfiniBand-Kommunikation zwischen GPUs auf unterschiedlichen Maschinen
    • UFM event log parser: parst Event-Logs des Unified Fabric Manager, um zu entscheiden, welche Netzwerkports deaktiviert werden sollen
    • InfiniBand burn-in workload generator: erzeugt InfiniBand-Burn-in-Workloads, die alle verfügbaren Links stressen

Cluster- und Netzwerkkonfiguration

  • Der Kern-Cluster verteilte 4.088 H100-GPUs auf 511 GPU-Server; jeder Server war mit 8 GPUs ausgestattet
  • Der Grund für 511 GPU-Server war, dass einige Verbindungen für Knoten des Unified Fabric Manager (UFM) zur Verwaltung des InfiniBand-Netzwerks reserviert werden mussten
  • Jede GPU war direkt mit einer ConnectX-7-Karte verbunden und konnte über ihre eigene ConnectX-7-Karte gleichzeitig mit 400 Gbit/s an andere GPUs im InfiniBand-Netzwerk senden und von ihnen empfangen
  • Die InfiniBand-Topologie war fully non-blocking aufgebaut, sodass theoretisch alle GPUs gleichzeitig mit maximaler Geschwindigkeit mit anderen GPUs kommunizieren konnten
    • Eine dreistufige InfiniBand-Switch-Architektur stellte den gesamten Netzwerkdurchsatz bereit
    • Die Trainingskommunikation lief über InfiniBand, nicht über Ethernet
  • Ethernet wurde für Datasets, Checkpoints und sonstige Datentransfers genutzt
    • Würde Trainingskommunikation über Ethernet laufen, müsste sie von der GPU zur CPU wandern und dann über eine 100-Gbit/s-Ethernet-Karte hinausgehen, was deutlich langsamer wäre
    • Training über Ethernet ist mit RoCE zwar möglich, erfordert aber viel zusätzliche Arbeit sowohl auf Hardware- als auch auf Softwareseite und ist im Allgemeinen weniger zuverlässig als InfiniBand
  • Ein separates Management-Ethernet-Netzwerk wurde für den Zugriff auf BIOS, Netzteile und Low-Level-Maschinen-Interface-Controller genutzt
    • Ohne dieses Management-Netzwerk hätten Hunderte Maschinen manuell mit USB-Laufwerk, Tastatur und Monitor eingerichtet werden müssen
  • Bei groß angelegtem Hochleistungstraining müssen InfiniBand, Ethernet, GPUs und Nodes nahezu perfekt funktionieren
    • Schon eine einzige instabile Verbindung unter mehr als 12.000 Verbindungen kann den gesamten Trainingslauf verlangsamen

Provisionierung einzelner Maschinen

  • Nachdem über das initiale Management-Netzwerk Ethernet-Verbindungen zum Cluster hergestellt waren, wurden Zugangsdaten für den BMC (Baseboard Management Controller) beschafft
    • Ein BMC ist ein Service-Prozessor zur Remote-Überwachung eines Hosts
    • Er stellt Hardwarestatus, BIOS-Einstellungen und Power-Management-APIs bereit
  • Der erste Server wurde manuell über iDRAC, Dells BMC, mit Ubuntu 22.04 installiert
    • Ein ISO-Image vom lokalen Computer konnte zum Booten gemountet werden; außerdem stand eine browserbasierte virtuelle Konsole bereit
    • Ziel war es, diese manuelle Installation zur einzigen manuellen Installation im gesamten Prozess zu machen

  • MAAS und PXE-Boot

    • Nachdem die erste Maschine vorbereitet war, wurde Ubuntu MAAS (Metal-as-a-Service) installiert, um die übrigen Server zu provisionieren
    • Per PXE-Boot und automatisierten iDRAC-Tools wurde jede Maschine angewiesen, über das Netzwerk zu booten
    • Die Server erhielten per DHCP eine IP von MAAS, luden einen initialen Kernel herunter und führten anschließend automatisch eine dauerhafte OS-Installation aus, selbst wenn das lokale Laufwerk leer war
    • In der Praxis war die Integration von MAAS und BMC nicht stabil genug, daher wurden die MAC-Adressen aller Maschinen vorab über die iDRAC-API gesammelt
    • MAAS war während des gesamten Trainingsprozesses weitgehend zuverlässig, hatte anfangs aber konfigurationsspezifische Probleme
      • Große Uhrzeitabweichungen führten dazu, dass HTTPS-Zertifikatsprüfungen fehlschlugen und apt-Installationen blockiert wurden
      • Der MAAS-Server fungierte gleichzeitig als DHCP, DNS, HTTP-Proxy, NTP, Verwaltung für cloud-init-Konfigurationen sowie als zentrale Datenbank für MACs, IPs, Hostnamen und Metadaten, was die Ursachenanalyse erschwerte

  • Boot-Fehler und grundlegende Beobachtbarkeit

    • Wie bei der Einrichtung großer GPU-Cluster üblich, schlugen etwa 10 % der Maschinen beim Booten fehl; Hauptursache waren physische Probleme an den Servern
      • Ethernet-Kabel nicht angeschlossen oder falsch verkabelt
      • iDRAC-Hardwareprobleme
      • Defekte Netzteile
      • Defekte NVMe-Laufwerke
      • Fehlende interne Verkabelung
      • Netzwerkkarten oder GPUs wurden nicht erkannt
    • Imbue automatisierte Checks für diese Probleme, gab einige Maschinen zur erneuten Prüfung an Dell weiter und eröffnete die nötigen Tickets für das Rechenzentrumspersonal
    • Da Imbue die Infrastruktureinrichtung selbst durchführte, konnten funktionsfähige Maschinen auch während der Wartezeit auf Reparaturen sofort genutzt werden
    • Auf allen Servern wurden Docker, die GPU-Treiber des Rechenzentrums, Prometheus node exporter, NVIDIA DCGM exporter sowie ein RAIDZ-ZFS-Pool über alle Nicht-OS-Laufwerke installiert
    • ZFS hielt die Maschine auch beim Ausfall eines Laufwerks weiter lauffähig, und transparente Kompression reduzierte den Speicherbedarf für Klartext-Datasets und wiederholte Logs erheblich
    • Bei der parallelen Installation von Softwarepaketen auf 400 Nodes entstand ein Bandbreitenengpass
    • In mehreren Komponenten der Rechenzentrumsbereitstellung traten zunächst Hochtemperaturwarnungen auf; die anfänglichen thermischen Probleme wurden größtenteils durch Firmware-Updates entschärft

  • Überprüfung des GPU-Trainings auf einem einzelnen Node

    • Es wurde geprüft, ob jede Maschine unabhängig reale GPU-Workloads verarbeiten kann
    • Mehrere Maschinen scheiterten beim Single-Node-GPU-Training aufgrund folgender Probleme
      • GPU-bezogene Fehler wurden meist durch erneutes Einsetzen der Karten in die Slots behoben
      • In den Ubuntu-Serverlogs erschien die PCIe-Verbindung als limited width: x4 < x16
      • Selbst nach Firmware-Updates für den PCIe-Switch-Bus mussten bei etwa einem Viertel der Hosts im Cluster interne PCIe-Kabel neu gesteckt werden
      • Es gab NVMe-Laufwerke, die nicht als defekt markiert wurden, beim Zugriff aber die gesamte Maschine blockierten
      • Unter Linux wurde die Reihenfolge der Festplatten zufällig angezeigt, sodass MAAS das OS auf dem falschen Laufwerk installierte
      • Fehlerhafte Temperaturmesswerte ließen die Lüfter dauerhaft mit 100 % laufen
      • Dynamische CPU-Frequenzskalierung begrenzte aktive Kerne auf 2 GHz
      • Die Anwendung von GDR, also des GPUDirect RDMA Peer Memory Client, schlug fehl

InfiniBand-Provisionierung

  • Dank seines zentralisierten Designs hatte InfiniBand eine einzige Kontrollinstanz für das gesamte Netzwerk und konnte 320 Netzwerk-Switches als ein Fabric behandeln.
  • Die erste Aufgabe bestand darin, herauszufinden, welcher Switch mit welcher Maschine verbunden war, und die Switches anhand ihrer physischen Position gemäß Verkabelungsplan umzubenennen.

  • Fehlerhaftes Fabric-Design und Neuverkabelung

    • Anfangs erkannte UFM die 320 Netzwerk-Switches nicht und fand auch die Hosts nicht, die im Fabric vorhanden sein sollten.
    • Eine Prüfung mit dem Rechenzentrumspartner ergab, dass die Switches eingeschaltet und verkabelt waren, aber nicht erkannt wurden.
    • Bei der Untersuchung der Netzwerk-Verkabelungsliste stellte sich heraus, dass das übergeordnete Fabric nicht aus einem einheitlichen Fabric bestand, sondern aus 8 getrennten Netzwerken ohne gemeinsame Routing-Pfade.
    • Nach der Neuverkabelung wurde eine Prüfung ergänzt, ob alle physischen Verbindungen dem neuen Design entsprachen.

  • Temperaturwarnungen und Port-Fehler

    • Nachdem die physischen Verkabelungsprobleme behoben waren, war UFM mit allen InfiniBand-Switches verbunden, doch fast alle Switch-Ports meldeten übermäßig hohe Temperaturen.
    • Einige Ports überschritten bereits vor der eigentlichen Datenübertragung 70 Grad Celsius; die Ursache war eine Konstruktion, bei der heiße Luft durch leere Zwischenräume zwischen den Switches in den Netzwerk-Racks wieder nach vorne zirkulierte.
    • Viele Ports zeigten hohe Fehlerraten oder Link-Flapping, also ein Hin- und Herwechseln zwischen normalem und fehlerhaftem Zustand. Dieses Problem trat nur auf, wenn der Port tatsächlich genutzt wurde, und war daher schwer im Voraus zu erkennen.
    • Das gesamte Fabric hatte 10.000 Links und eine hohe Redundanz, doch als etwa 10 % des Fabrics Probleme zeigten, konnten selbst Funktionen wie Adaptive Routing die unregelmäßig ausfallenden Links nicht ausreichend umgehen.
    • Der Rechenzentrumspartner reinigte die Ports mit Warnmeldungen und setzte sie neu ein; die übrigen auffälligen Transceiver, die auf Austausch warteten, wurden deaktiviert.
    • In dieser Phase wurden Multi-Node-Trainingsläufe mit 100 bis 200 Maschinen durchgeführt, um eine stabile Teilmenge des InfiniBand zu finden.

  • InfiniBand-Burn-in und GPUDirect RDMA

    • Um InfiniBand-Probleme effizienter zu diagnostizieren, wurde eine spezielle Workload erstellt, die gleichzeitig so viele Daten wie möglich über alle Ports des gesamten Fabrics schiebt.
    • Das unterschied sich von der Ausführung eines großen All-Reduce über den gesamten Cluster.
      • Denn NCCL optimiert die Kommunikation innerhalb eines einzelnen Nodes über NVLink und SXM-Socket-Pfade.
    • UFM meldete auf den meisten Ports Datentransfers von mehr als 97 % der theoretischen Kapazität, und einige Switches stürzten vorübergehend ab.
    • Ports, die bis zum Ende des Tages überlebten, wurden als ausreichend robust angesehen; die übrigen wurden deaktiviert oder für spätere Reparaturen eingeplant.
    • GPUDirect RDMA wurde aktiviert, damit GPUs ohne CPU-Overhead kommunizieren können.

  • Stabile Maschinenmenge und Wartung

    • Als Faustregel für moderne GPU-Cluster mit aktueller Hardware sollte man erwarten, dass pro Woche etwa 3 % der Maschinen ausfallen.
    • Dabei fällt nicht jede Maschine gleichmäßig mit 3 % Wahrscheinlichkeit aus; vielmehr fallen einige problematische Maschinen wiederholt auf verschiedene Arten aus.
    • Wenn viele Maschinen im selben Fabric liegen, kann man eine Menge bekanntermaßen stabiler golden Maschinen aufbauen, statt ständig zufälligen Maschinenproblemen hinterherzujagen.
    • Die InfiniBand-Wartung bestand hauptsächlich aus dem Reagieren auf UFM-Warnungen, dem Austausch von Kabeln und Transceivern sowie der Diagnose fehlerhafter Switches.
    • Größere Regressionen entstanden meist aus zwei Gründen:
      • Ein nur auf die Hälfte des Clusters angewendetes Firmware-Upgrade beschädigte den UFM-Zustand, sodass ein UFM-Neustart auf allen InfiniBand-Switches erforderlich wurde.
      • Wenn viele GPU-Boxen gleichzeitig neu gestartet wurden, explodierten die UFM-Statusupdates, sodass ein Neustart des UFM-Dienstes nötig wurde.

Host-Health-Check-System

  • Imbue entdeckte verschiedene Einzelmaschinenfehler, die Trainingsläufe zum Scheitern brachten oder verlangsamten, und schrieb Health Checks, um Hosts zu identifizieren, die für Training ausreichend gesund waren.
  • Der Code wurde unter cluster-health veröffentlicht.
  • Viele Checks sind spezifisch für die Laufzeitumgebung von Imbue, aber das Ziel war, über einen einzigen Einstiegspunkt ein Ja/Nein zur Trainingsbereitschaft zurückzugeben.

  • Schnelle Health Checks

    • GPU Health Check: Prüft die Anzahl der GPUs, ob ECC aktiviert ist, ECC-Fehler sowie NVLink-Topologie und -Fehler.
    • Disk Space Health Check: Prüft, ob die Auslastung der Host-Festplatte nicht über 95 % liegt.
    • Docker Health Check: Prüft, ob Container mit GPU-Anbindung laufen und ob Monitoring- und Profiling-Container die richtigen Berechtigungen haben.
    • Dmesg Health Check: Sucht nach Xid- und SXid-Fehlern von NVIDIA-GPUs oder NVIDIA-Switches und prüft, ob dmesg-Logzeilen einer Liste erwartbarer Logs zugeordnet werden können.
    • iDRAC Health Check: Prüft iDRAC-Fehler auf Dell-Maschinen und ignoriert nicht kritische Fehlermeldungen.
      • Dieser Check ist nicht für die Open-Source-Veröffentlichung vorgesehen.
    • Disk Health Check: Prüft zpool-Mounts, Docker-Anbindung und ob die CPU beim Zugriff auf die Festplatte hängen bleibt.
    • InfiniBand Health Check: Prüft auf steigende InfiniBand-Fehlerraten und veraltete Treiber-Firmware.
    • Nvlink Health Check: Prüft NVLink-Fehler der Maschine.
      • Erfahrungsgemäß verursachten sie keine Trainingsfehler, konnten aber Verlangsamungen auslösen.
    • GDR Health Check: Prüft, ob GDR auf der Maschine aktiviert ist.
    • VBIOS Health Check: Prüft, ob die GPU-VBIOS-Version und die H100-Baseboard-Firmware aktuell sind.
    • Flint Health Check: Prüft mit flint und hca_self_test die Versionen des Mellanox-OFED-Treibers, der Karten-Firmware und der Transceiver-Firmware sowie den Kompilierungsstatus des NVIDIA-Treibers.
    • PSB Health Check: Fragt PCIe-Geräte ab und prüft, ob Verbindungsgeschwindigkeit und -breite zwischen GPU, PSB und Netzwerkkarte den Erwartungen entsprechen.
      • Da es sich um ein von Dell entwickeltes Skript handelt, kann es derzeit nicht geteilt werden.

  • Längere Health Checks

    • Initialisiert Matrixberechnungen mit PyTorch, um NVLink-Bandbreite, GPU-Rechengeschwindigkeit und Speicher zu messen.
    • Setzt GDR-Flags, um sowohl InfiniBand als auch NVLink zu testen.
    • Sendet mit ib_write_bw und --use_cuda Daten an die IB-Karte, um die Bandbreite von PCIe und InfiniBand-Karten zu messen.
    • Läuft etwa 15 Minuten, um flappende InfiniBand-Links zu erfassen.
    • Prüft mit einem Multi-Node-Diagnoselauf, ob NCCL initialisiert werden kann und ob zufällige Hänger auftreten.
      • Wenn es hängt, schreibt der geforkte NCCL-Code zusätzliche Logs.
    • Da die Erkennung von Problemen 12 bis 24 Stunden dauern kann, wird dies vor allem bei neuen Nodes oder in Verdachtsfällen ausgeführt.
    • Prüft in DCGM-Exports auf GPU-Clock-Throttling-Events, nimmt aber die erwarteten gpu_idle und power_cap aus.
    • Multi-Node-Training, das alle GPUs, InfiniBand-Karten, CPUs und Festplatten gleichzeitig nutzt, legt Stromversorgungsereignisse am besten offen.

Diagnose häufiger Fehler während des Trainings

  • Absturz direkt nach dem Start

    • Abstürze direkt nach dem Start waren am einfachsten zu behandeln, da sie sich relativ leicht reproduzieren und wiederholen ließen
    • Zuerst wurde geprüft, ob Codeversion, Konfiguration und Umgebungsvariablen korrekt waren
    • Zwischenschichten wie Docker-Image-Caching oder intransparente Secrets-Konfigurationen konnten die Ursachenanalyse erschweren
    • Außerdem wurde geprüft, ob alle Maschinen online waren und ob Stack Traces und Logs leicht aggregiert und untersucht werden konnten
      • Imbue verwendet einen Stack aus Loki, Prometheus und Grafana
    • Bei synchroner verteilter Ausführung führte der erste Fehler häufig zu einer Kaskade nicht zusammenhängender Folgefehler
    • Mit dem Aufbau eines Systems für automatische erneute Ausführungen wurde die Log- und Fehleraggregation noch wichtiger, damit Logs und Fehler verschiedener Re-Runs nicht vermischt wurden
    • Häufig beobachtete Fehler waren:
      • Forward order differs across ranks...: ließ sich aufgrund von Eigenschaften der PyTorch-FSDP-Implementierung durch erneutes Ausführen beheben
      • CUDA out of memory...: wurde durch Prüfen von Konfiguration und Code sowie durch Rollback jüngster Codeänderungen behoben
      • CPU/RAM-OOM: ließ sich am besten außerhalb des Containers in den dmesg-Logs des Hosts über Aufrufe des OOM Killer erkennen

  • Abstürze mitten im Training

    • Nachdem die Hardware zu arbeiten begonnen hatte, war zunächst ein System nötig, das alle diagnostischen Health Checks erneut ausführt und automatisch neu startet, während ungesunde Hosts ausgeschlossen werden
    • Zufällige Hardwarefehler wie Xid oder SXid konnten eine Ausführung ohne aussagekräftigen Python-Stack-Trace zum Absturz bringen
    • Einige Fälle wie Row Remapping ließen sich durch einen Neustart beheben, uncorrectable ECC errors erforderten jedoch in der Regel Hardwarewartung oder den Austausch von Komponenten
    • Auch besonders schlecht formatierte Trainingsdaten verursachten Abstürze
      • Sehr große Einzeldokumente im Korpus konnten GPU- oder CPU-OOM auslösen
      • Ein vollständig deterministischer Data Loader wurde verwendet, um Epoch- oder Step-Nummer leicht mit dem Absturz zu verknüpfen
      • Um zu prüfen, ob die Daten die Ursache waren, wurde das Laden von Daten deaktiviert oder durch Fake-Daten ersetzt, die nur aus Nullen bestanden
    • Kurzzeitige Ethernet-Ausfälle oder fehlender Speicherplatz konnten ohne hilfreiche Fehlermeldungen auftreten; daher wurden Netzwerk- und Node-Statusmetriken aufgezeichnet, um Korrelationen zu prüfen

  • Hänger ohne Stack Trace

    • Fehler, die ohne Stack Trace hängen blieben oder in Timeouts liefen, waren besonders schwierig zu debuggen, da es wenig Informationen gab und sie sich nur schwer zuverlässig reproduzieren ließen
    • Eine typische Meldung hatte die Form Watchdog caught collective operation timeout...
    • Wenn ein oder mehrere Hosts eine NCCL-Operation nicht abschließen konnten oder aus einer NCCL- bzw. InfiniBand-Verbindung herausfielen, blockierten alle anderen Hosts synchron bei dieser Tensor-Operation bis zum NCCL_TIMEOUT
    • Aufgrund der Eigenschaften der NCCL-Bibliothek war es schwierig herauszufinden, welcher Host die Ursache war
    • Imbue ergänzte einen NCCL-Fork um Logging-Änderungen, um in-flight Messages oder Operationen zum Absturzzeitpunkt besser sichtbar zu machen und den problematischen Host oder die problematische GPU zu identifizieren
    • Um einen fehlerhaft arbeitenden Host zu finden, musste häufig geprüft werden, welcher Host bestimmte Logmeldungen nicht erzeugt hatte
    • Mit Py-Spy und GDB wurden angehaltene Prozesse live debuggt, um zwischen NCCL-Hängern, Treiber-Hängern sowie Race Conditions oder Deadlocks im Python-Code zu unterscheiden

Verlangsamung des Trainings anhand von MFU

  • Allgemeine Verlangsamungen oder eine niedrigere MFU (Model FLOPs Utilization) als zuvor beobachtet können viele Ursachen haben
  • Zunächst hilft es, Konfiguration, Code und Umgebungsvariablen erneut zu prüfen
    • Falsches Modell
    • Falsche Batch-Größe
    • Falsche UFM- oder NCCL-Einstellungen
    • Falsches CUDA_DEVICE_MAX_CONNECTIONS
  • Für die Diagnose des Problemtyps war es hilfreicher, die unmittelbare MFU pro Batch zu messen als einen geglätteten Durchschnitt

  • Ursachen nach MFU-Mustern

    • Wenn sich die MFU direkt nach Trainingsstart stabil bei weniger als 1/10 des erwarteten Werts hielt, war meist ein InfiniBand-Hardwareproblem die Ursache, etwa ein ausgefallener Switch auf T2- oder T3-Ebene
      • Auch ein Hardwareproblem zwischen GPU und NIC konnte die Ursache sein und erschien in dmesg als PCIe x16 lanes limited by ...
    • Wenn sich die MFU direkt nach dem Start stabil bei 30 % des erwarteten Werts hielt, konnten die GDR-Konfiguration oder GDR-Umgebungsvariablen eines Hosts falsch sein
    • Wenn sich die MFU direkt nach dem Start stabil bei 60–80 % des erwarteten Werts hielt, war meist ein degradierter oder defekter InfiniBand-Link die Ursache
      • Wenn die mit einer bestimmten GPU verbundene InfiniBand-NIC defekt war, versuchte NCCL, über lokales NVLink eine andere GPU-NIC im selben Host zu verwenden
      • Auch CPU-Throttling konnte die Ursache sein und erforderte eine Anpassung der BIOS-Einstellungen auf einem bestimmten Host
    • Wenn bei einzelnen Batches regelmäßig ein 10-facher Einbruch auftrat, hing das fast immer mit Checkpointing oder Evaluation zusammen und ließ sich durch Abgleich mit Epoch- und Step-Zahlen bestätigen
      • Automatische Alerts nur auf Basis von MFU-Anomalien erzeugen viele False Positives
    • Wenn ein 10-facher Einbruch bei einzelnen Batches selten und zufällig auftrat und sich sofort wieder erholte, war häufig auf einem der laufenden Hosts ein CPU-intensiver Workload eingeplant
      • Auch sporadische Netzwerkprobleme oder ein Bottleneck im Data Loader konnten die Ursache sein
    • Wenn die MFU-Grafik im Verlauf der Ausführung allmählich abfiel und nach einem Neustart wieder auf 100 % zurückkehrte, wurde mit Python- und NVIDIA-Profilern bestätigt, dass automatische Garbage Collection die Ursache war
      • Nachdem die automatische Garbage Collection deaktiviert und auf allen Hosts in festen Intervallen Garbage Collection durchgeführt wurde, verschwand der Durchsatzrückgang
    • Wenn die Anfangsperformance gut war, später aber häufig auf 70 % des erwarteten Werts einbrach, korrelierte dies mit den NVIDIA GPU clock throttle reasons
      • Ursachen waren GPU-Temperatur, ausgefallene oder degradierte Kühlungslüfter des Hosts oder Ausfälle der Stromversorgung
    • Wenn die Performance gut war, aber zwischen 90 und 100 % der erwarteten MFU starkes hochfrequentes Rauschen auftrat, war meist ein InfiniBand-Hardwareproblem die Ursache, etwa eine mittlere Degradation in höheren Netzwerkschichten oder flapping Links

  • Prüffragen bei Durchsatz-Regressionen

    • Prüfen, ob es zuvor schon einmal korrekt funktioniert hat
    • Prüfen, ob es Änderungen gab, etwa kürzlich gemergten Code oder Treiber-Updates
    • Prüfen, ob die Ausführung auf gesunden Hosts läuft und ob abhängige Dienste wie Docker Hub oder GitHub funktionieren
    • Prüfen, ob mit demselben Code, derselben Umgebung, Konfiguration, Version, Hostliste, Rank-Reihenfolge und demselben Random Seed wie bei der letzten erfolgreichen Ausführung gestartet wurde
    • Prüfen, ob das Problem reproduzierbar ist
    • Prüfen, ob es Korrelationen mit anderen Prozessen, täglichen crontabs sowie Host-, DCGM- oder UFM-Metriken gibt
    • Prüfen, ob die Tools zur Metrikmessung korrekt sind
    • Prüfen, ob das Problem auch in reduziertem Code auftritt, etwa mit kleinerem Modell, Fake-Daten oder ohne Speichern und Laden von Checkpoints

Automatisierungstools und operative Verbesserungen

  • Selbst wenn das Training mit guter Performance starten konnte, ging irgendwann zwangsläufig etwas kaputt; daher waren Tools und Systeme nötig, die menschliche Eingriffe minimieren
  • Da Imbue ein kleines Team ist, gab es nicht genügend Personal für fortlaufende manuelle Reparaturen; deshalb wurde so viel wie möglich automatisiert
  • Die meisten Probleme bei Trainingsläufen ließen sich auf defekte Maschinen oder Netzwerkkomponenten eingrenzen

  • Defekte Maschinen automatisch ausschließen

    • Es wurde ein System entwickelt, das abgestürzte Läufe automatisch vom neuesten Checkpoint neu startet
    • Beim Neustart werden auf allen verfügbaren Maschinen Health Checks ausgeführt, und der Gesundheitszustand der Maschinen wird anhand der bestandenen Checks klassifiziert
    • Anschließend wird der Trainingsjob auf den gesündesten Maschinen erneut ausgeführt

  • Automatische Reaktion auf Netzwerkkomponenten

    • Alle beobachteten Ausfälle von Netzwerkkomponenten wurden von UFM erkannt und im UFM-Event-Log registriert
    • Tatsächlich problematisch waren nur einige von Dutzenden Event-Typen, meist im Zusammenhang mit Link Down oder einem hohen Symbol Error Count
    • Ein Skript parst das UFM-Event-Log, deaktiviert Links und Ports, die mit aktuellen Events zusammenhängen, erstellt Wartungstickets und aktiviert sie nach abgeschlossener Reparatur wieder

  • Spiegelung im lokalen Dateisystem

    • Die Ethernet-Geschwindigkeit innerhalb und außerhalb des Clusters konnte bei groß angelegtem verteiltem Training zum Flaschenhals werden
    • Eine gemeinsam genutzte Ethernet-Verbindung mit etwa 10 Gbit/s ist schnell gesättigt, wenn Hunderte Worker gleichzeitig Datensätze und Modell-Checkpoints herunterladen
    • Imbue baute innerhalb des Clusters ein lokales Dateisystem auf, das Cloud Storage spiegelt, um die Zahl der Dateien zu reduzieren, die aus S3 geholt werden müssen
    • Um Churn zu bewältigen, bei dem Maschinen häufig deaktiviert oder ersetzt werden, wurde jede Datei dreifach repliziert
    • Mit consistent hashing wurde die Last gleichmäßig verteilt und Dateiverschiebungen während Churn minimiert
    • Wegen des begrenzten Speicherplatzes wurden außerdem Tools zum Nachverfolgen des Dateilebenszyklus und zum Löschen nicht mehr benötigter Dateien entwickelt

  • Lokale verteilte Docker registry

    • Für die Übertragung von Docker-Images wurde Kraken verwendet
    • Kraken ist Open-Source-Software, mit der Docker-Images peer-to-peer übertragen werden können; Imbue gab an, damit kaum Probleme gehabt zu haben

  • Performance-Monitoring und Identifizierung fehlerhafter Hosts

    • Torch profiler und NVIDIA Nsight Systems wurden eingerichtet
    • Nsight Systems war nützlich, um zu verstehen, wie lange Forward/Backward Pass und NCCL-Kommunikation dauern
    • Es half dabei, je nach Modellgröße und Anzahl der Worker zu beurteilen, ob Kommunikation oder Berechnung der Flaschenhals ist
    • Der Einsatz war etwas umständlich, da Docker privileged mode erforderlich war, Sicherheitsprüfungen für Performance-Monitoring-Events deaktiviert werden mussten und das Training zum Speichern von Profilen unterbrochen werden musste
    • Außerdem wurden Tools geschrieben, um langsame Trainings-Batches zu erkennen und ihre Ursache zu ermitteln
      • Das nützlichste Tool überwachte die Dauer jedes Batches und dumpte bei ungewöhnlich langsamen Batches die Stacktraces aller Worker
      • Dadurch wurde es einfacher, bestimmte Hosts mit subtilen Hardware- oder Softwareproblemen zu identifizieren
    • Bevor die Health Checks ausreichend ausgereift waren, war bei Trainingsfehlern auf einer bestimmten Maschinengruppe oft unklar, welche Maschine die Ursache war
      • Wenn beispielsweise eine Gruppe von 48 Maschinen fehlschlug, wurden kleinere Läufe mit 6 Gruppen zu je 8 Maschinen und 8 Gruppen zu je 6 Maschinen gestartet
      • Maschinen, die in beiden Schritten jeweils in einer fehlschlagenden Gruppe enthalten waren, wurden mit hoher Sicherheit als problematisch eingestuft

Operative Prinzipien aus dem Aufbauprozess

  • Wenn man 10–20 % mehr Maschinen vorhält, als für einen bestimmten Trainingslauf nötig sind, kann man bei Maschinenausfällen leicht erneut starten
  • Wird das Cluster-Netzwerk so aufgebaut, dass alle Maschinen eng miteinander verbunden sind, kann eine beliebige funktionierende Teilmenge genutzt werden
  • Hardware- und Softwarefehler, die während des Trainings auftreten, werden wieder auftreten; daher lohnt es sich, für jeden Fehlertyp Tests und Automatisierungslösungen zu schreiben
  • Für jede undurchsichtige Fehlermeldung ist es hilfreich, besser interpretierbare Tools zu bauen
  • Für Reproduzierbarkeit wurde die Regel übernommen, selbst die einfachste Änderung immer nur einzeln vorzunehmen
  • Beim Einführen externer Tools oder wenn eine neue Person in den Prozess einsteigt, sollten Behauptungen erneut überprüft werden, insbesondere wenn nachfolgende Schritte von deren Ergebnis abhängen
  • Der gesamte Prozess erforderte viel Aufsicht und Iteration, doch entscheidend war, die Infrastruktur vollständig kontrollieren und Probleme auf allen Abstraktionsebenen debuggen zu können

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-06-29
Kommentare auf Hacker News
  • Ein kleines Forschungs- und Engineering-Team hat über mehrere Monate auf eigener Infrastruktur ein 70-Milliarden-Parameter-Modell von Grund auf trainiert und bei Aufgaben zum Schlussfolgern zero-shot GPT-4o übertroffen.
    Um für Hochleistungstraining einen eigenen Cluster zu nutzen, mussten alle Komponenten – InfiniBand, Ethernet, GPUs und Nodes – einwandfrei funktionieren; schon eine einzige instabile Verbindung unter mehr als 12.000 Verbindungen konnte das gesamte Training verlangsamen.
    Es wurden Open-Source-Skripte und ein End-to-End-Leitfaden für das Infrastruktur-Setup veröffentlicht; das ist einer von drei Teilen des Toolkits zum Training eines 70-Milliarden-Modells. Evaluierung sowie das Tool CARBS zur Hyperparameter-Optimierung gibt es hier: https://imbue.com/research/70b-intro/
    • Die Details waren wirklich gut, und ich habe noch nie einen Beitrag gesehen, der die Engineering-Arbeit hinter solchen Modellen intern so ausführlich zeigt.
      Ich habe zwei Fragen. Erstens würde mich interessieren, was sich ändern würde, wenn man ein 400-Milliarden-Parameter-Modell trainiert. Über den gesamten Cluster hinweg scheint genug Videospeicher vorhanden zu sein, aber mich interessiert die tatsächliche Einschätzung.
      Zweitens würde mich interessieren, ob man so eine Architektur als Endzustand des Modelltrainings sieht. Sie wirkt sehr fragil; ich wüsste gern, ob es bessere Mechanismen oder Architekturen für gemeinsames Training oder bessere Cluster-Strukturen gibt.
    • Ich frage mich, was aus der Minecraft-ähnlichen 3D-Welt geworden ist, an der das Team gearbeitet hat. Haben sie die Richtung geändert?
    • Der Teil „zero-shot GPT-4o übertroffen“ ist interessant. Wurde dieses Modell auch mit RLHF trainiert, oder nur vortrainiert?
      Falls Letzteres, würde ich gern wissen, wie es GPT-4 geschlagen hat.
    • Der Satz, dass schon eine einzige instabile Verbindung unter mehr als 12.000 Verbindungen das gesamte Training verlangsamen kann, war ziemlich auffällig, sodass ich dachte: „Den Satz habe ich doch schon mal gesehen.“
      Tatsächlich scheinen dieser Satz und ein Großteil des Beitrags fast wortgleich auf Twitter, LinkedIn und Reddit gepostet worden zu sein – ist das einfach Spam?
      https://x.com/imbue_ai/status/1805629547473518695
      https://reddit.com/r/learnmachinelearning/comments/1dobgbs/t...
      https://www.linkedin.com/posts/mattboulos_training-a-70b-mod...
  • Wenn es heißt „511 Rechner mit 4.092 H100-GPUs, 8 pro Rechner“, verstehe ich das richtig, dass allein die GPUs über 100 Mio. Dollar kosten?
    Ich frage mich, wie viel davon und wann in den Bereich von Hobbyentwicklern mit Gaming-PC-Budget kommen könnte.
    • Interessant, dass man 100 Mio. Dollar für GPUs ausgibt und dann an Dell-Kisten mit defekten Ethernet-Ports herumfummelt.
      Die Probleme, auf die sie gestoßen sind, klingen unterhaltsam.
    • Scheint zu stimmen. Sie haben 200 Mio. Dollar von NVIDIA eingesammelt, vermutlich im Wesentlichen in GPU-Form: https://news.crunchbase.com/ai-robotics/new-ai-unicorn-imbue...
    • Wenn allein die GPUs über 100 Mio. Dollar kosten, sollten die meisten Leser ohne Finanzierung in dieser Größenordnung wohl zum nächsten HN-Artikel weitergehen.
  • Wirklich cool. Cisco hat kürzlich in Zusammenarbeit mit NVIDIA neue Geräte herausgebracht, die 800G pro Port liefern; ich erinnere mich nicht, ob es RoCE war.
    Hier scheint die Struktur so zu sein, dass die GPUs Zugriff auf InfiniBand haben, und das ist schön. Einer der direkt nützlichen Beiträge.
  • Vor ein paar Tagen wurde das auch im Latent-Space-Podcast behandelt: https://www.latent.space/p/llm-training-2024
    Eine gute Folge, und es lohnt sich, die Begründungen dafür zu hören, warum solche Entscheidungen getroffen wurden.
    • Ich bin solche Interviews nicht gewohnt und hatte das Gefühl, dass das außerhalb meiner Kompetenz liegt. Wenn es Fragen gibt, die ich hätte stellen sollen, aber ausgelassen habe, schlagt sie gern vor.
  • Mich würde der gesamte Stromverbrauch für den Bau des Modells interessieren. Ich wüsste gern, ob es Zahlen inklusive Strom und Kühlung gibt.
    Zuckerberg sagte in einem Podcast, dass man das nächste 1-GW-Modell plane; das bedeutet im Grunde ein Rechenzentrum mit angeschlossenem mittelgroßem Kraftwerk, deshalb interessiert mich das noch mehr.
  • Ein wirklich wertvoller Beitrag, und ich habe beim Lesen viel gelernt. Auch der veröffentlichte Open-Source-Code ist großartig.
    Ich habe ein paar Fragen. Warum haben sie einen eigenen Cluster aufgebaut, und wie war die Erfahrung mit dem Cloud-Partner beim Umgang mit defekter Hardware oder Switches?
    Außerdem wüsste ich gern, worauf sie bei der Wahl der Cluster-Architektur neben All-to-all-Kommunikation am meisten geachtet haben und was sich tatsächlich als am wertvollsten erwiesen hat; wie die Logging-Infrastruktur abgesehen davon aussah, dass sie auf Loki basierte; warum ein lokales Docker-Registry nötig war; und ob sie außer nvidia-container-runtime auch andere Images verwendet haben.
  • Ehrliche Frage: Warum ist hier so viel PC-Hardware im Spiel?
    Könnte man die GPUs nicht an ein PCI- und InfiniBand-Backend hängen, nur einen sehr kleinen ARM-Koordinationscontroller danebenstellen und sie sich untereinander abstimmen lassen? Ich weiß nicht, ob das Trägheit früherer Designs ist oder daran liegt, dass es zu wenig Markt für spezielle GPU-Controller gibt.
    • Falls du fragst, warum man zusätzliche Kosten für CPU und RAM bezahlt: Nicht alles lässt sich auf der GPU erledigen. Zum Beispiel .png-Dekomprimierung.
      Wenn man den Trainingscode wirklich analysiert und die Daten stark vorverarbeitet, kommt man vielleicht auch mit sehr leichten CPU/RAM-Ressourcen aus. Da GPUs aber teuer sind und CPU/RAM am Gesamtsystempreis nur einen kleinen Anteil haben, ist es nicht unbedingt nötig, Entwicklungszeit in diese Optimierung zu stecken.

Wenn es sich um einen Hyperscaler handelt, ist es sehr wahrscheinlich, dass er auch solchen 0,x-%-Kosteneffizienzgewinnen nachjagt. Zum Beispiel könnte man .png nach .webp (mehrthreadig, verlustfrei) oder .jpeg (verlustbehaftet) vorverarbeiten wollen; es dürfte aber kaum passen, das in ein Format umzuwandeln, das die GPU dekomprimieren kann, weil das zwar die CPU-Kosten während des Trainings senkt, aber mehr Speicher- und Übertragungskosten verursacht.
Genauer gesagt: Wenn CPU-Arbeit der Trainings-Flaschenhals ist, sollte man durch Datenvorverarbeitung und Anpassungen am Trainingsskript so weit wie möglich optimieren. Gemeint ist hier die Lücke zwischen „schnell genug“ und „schneller“: CPU ist nicht schnell genug fürs Training < CPU ist gerade schnell genug fürs Training < CPU ist schneller als für das Training erforderlich

  • Wenn in jeder Maschine GPUs im Wert von 250.000 Dollar stecken, ist es töricht, darüber nachzudenken, ein paar tausend Dollar bei der Steuerungshardware zu sparen. Das Risiko durch eine neue Hardwarekonfiguration ist zu groß.
    Ein weiteres Problem ist, dass sich GPU-bezogene Hardware, Treiber und Betriebserfahrung sämtlich auf der PC-Seite befinden. Wenn man das auf ARM betreiben will, muss man praktisch bei null anfangen, und für die Stabilisierung ist ebenfalls viel zusätzliche Arbeit nötig. Am Ende zahlt man einen hohen Preis dafür, ein wenig Prozessorkosten zu sparen.
  • GPUs kontinuierlich mit Daten zu versorgen, ist beim Deep-Learning-Training eine ziemlich knifflige Aufgabe.
    Ich habe keine Erfahrung mit LLM/NLP, aber bei Bild- und Audio-Workloads ist es manchmal schwierig, selbst RTX-2/3/4xxx-GPUs mit einer üblichen 4- bis 8-Core-CPU vollständig auszulasten. Dass CPU oder I/O zum Flaschenhals werden, ist nicht besonders schwer.
  • 4.092 H100-GPUs – das ist eine große Größenordnung.
    Sie sagen, sie machten „self-coding“; ich frage mich, ob das eher in Richtung No-Code- oder Low-Code-Lösung geht.
    Auf der Website gibt es auch einige Beiträge, die interessant sein könnten: https://imbue.com/our-work/
  • Ich frage mich, wie viel das gekostet hat. Wie viel war es insgesamt – Hardwarekosten, Entwicklungszeit, Strom- und Kühlkosten –, um von null bis zu einer nutzbaren Modelldatei zu kommen?
  • Ich frage mich, ob zahlreiche Hobbyentwickler gemeinsam verteilt ein Modell trainieren könnten, ähnlich wie bei seti@home oder folding@home.
    Diese Projekte zeichneten sich dadurch aus, dass sich die Arbeit in ziemlich unabhängige Arbeitspakete aufteilen ließ; ich bin mir nicht sicher, ob sich Modelltraining ebenfalls so aufteilen lässt.
    • Wahrscheinlich wird das nicht gut funktionieren. Unter Hobbyentwicklern dürfte es kaum oder gar niemanden geben, der zwischen den eigenen GPUs einen Netzwerkdurchsatz von 400 Gbps bereitstellen kann.