Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Verbesserungen bei der Initialisierung der kollektiven Kommunikation
NCCL und Gloo sind grundlegende Kommunikationsbibliotheken, die kollektive Abläufe (wie All-Reduce und Broadcast) über verteilte Trainingsprozesse hinweg ermöglichen. Die herkömmliche NCCL- und Gloo-Initialisierung kann jedoch zu Engpässen bei der Fehlerbehebung führen.
Beim Standard-Wiederherstellungsprozess müssen alle Prozesse eine Verbindung zu einem zentralen TCPStore herstellen und über einen Root-Prozess koordinieren. Dies verursacht einen teuren Overhead, der bei Neustarts besonders problematisch wird. Dieses zentralisierte Design verursacht drei kritische Probleme: Koordinationsaufwand aufgrund der obligatorischen TCPStore-Verbindungen, Verzögerungen bei der Wiederherstellung, da bei jedem Neustart die gesamte Initialisierungssequenz wiederholt werden muss, und eine einzelne Fehlerstelle im Root-Prozess selbst. Dies erfordert teure, zentralisierte Koordinationsschritte jedes Mal, wenn das Training initialisiert oder neu gestartet wird.
HyperPod Durch Checkpointless-Training werden diese Koordinationsengpässe beseitigt und eine schnellere Wiederherstellung nach Fehlern ermöglicht, da die Initialisierung „rootless“ und „TCPStoreless“ erfolgt.
Konfigurationen ohne Root
Um Rootless zu aktivieren, kann man einfach die folgenden Umgebungsvariablen verfügbar machen.
export HPCT_USE_ROOTLESS=1 && \ sysctl -w net.ipv4.ip_local_port_range="20000 65535" && \
HPCT_USE_ROOTLESS: 0 oder 1. Wird verwendet, um Rootless ein- und auszuschalten
sysctl -w net.ipv4.ip_local_port_range="20000 65535": Legt den Portbereich des Systems fest
Sehen Sie sich das Beispiel für die Aktivierung von Rootless an.
Rootlos
HyperPod Checkpointless Training bietet neuartige Initialisierungsmethoden, Rootless und TCPStoreless, für NCCL- und Gloo-Prozessgruppen.
Die Implementierung dieser Optimierungen beinhaltet die Modifizierung von NCCL, Gloo und: PyTorch
Erweiterung der Bibliotheks-APIs von Drittanbietern, um Rootless- und Storeless-NCCL- und Gloo-Optimierungen zu ermöglichen und gleichzeitig die Abwärtskompatibilität aufrechtzuerhalten
Aktualisierung der Prozessgruppen-Backends, um unter bestimmten Bedingungen optimierte Pfade zu verwenden und Probleme bei der Wiederherstellung während des Prozesses zu lösen
Umgehung der teuren TCPStore-Erstellung auf der PyTorch verteilten Ebene bei gleichzeitiger Beibehaltung symmetrischer Adressmuster durch globale Gruppenzähler
Das folgende Diagramm zeigt die Architektur der verteilten Trainingsbibliotheken und die Änderungen, die beim Training ohne Checkpoints vorgenommen wurden.
NCCL und Gloo
Dies sind unabhängige Pakete, die die Kernfunktionen der kollektiven Kommunikation erfüllen. Sie bieten wichtige APIs wie ncclCommInitRank, um Kommunikationsnetzwerke zu initialisieren, die zugrunde liegenden Ressourcen zu verwalten und kollektive Kommunikation durchzuführen. Nachdem benutzerdefinierte Änderungen in NCCL und Gloo vorgenommen wurden, optimieren Rootless und Storeless die Initialisierung des Kommunikationsnetzwerks (z. B. überspringen Sie die Verbindung zum TCPStore). Sie können flexibel zwischen der Verwendung der ursprünglichen Codepfade und optimierten Codepfaden wechseln.
PyTorch Prozessgruppe (Backend)
Die Prozessgruppen-Backends, insbesondere ProcessGroup NCCL und ProcessGroupGloo, implementieren die ProcessGroup APIs, indem sie die APIs der entsprechenden zugrunde liegenden Bibliotheken aufrufen. Da wir die APIs der Bibliotheken von Drittanbietern erweitern, müssen wir sie ordnungsgemäß aufrufen und den Codepfad auf der Grundlage der Kundenkonfigurationen wechseln.
Zusätzlich zur Optimierung der Codepfade ändern wir auch das Prozessgruppen-Backend, um die prozessinterne Wiederherstellung zu unterstützen.
