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 Operationen (wie All-Reduce und Broadcast) in verteilten Trainingsprozessen ermöglichen. Herkömmliche NCCL- und Gloo-Initialisierungen können jedoch zu Engpässen bei der Fehlerbehebung führen.
Beim standardmäßigen Wiederherstellungsprozess müssen alle Prozesse eine Verbindung zu einem zentralen Prozess herstellen TCPStore und über einen Stammprozess koordiniert werden, was zu einem teuren Overhead führt, der bei Neustarts besonders problematisch wird. Dieser zentralisierte Aufbau führt zu drei kritischen Problemen: Koordinationsaufwand aufgrund obligatorischer TCPStore Verbindungen, Verzögerungen bei der Wiederherstellung, da bei jedem Neustart die gesamte Initialisierungssequenz wiederholt werden muss, und eine einzelne Fehlerquelle im Stammprozess selbst. Dies führt bei jeder Initialisierung oder jedem Neustart der Schulung zu teuren, zentralen Koordinationsschritten.
HyperPod Das Training ohne Checkpoint beseitigt diese Koordinationsengpässe und ermöglicht eine schnellere Behebung von Fehlern, da die Initialisierung ohne Wurzeln und „“ erfolgt. TCPStoreless
Konfigurationen ohne Wurzeln
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.
Rootless
HyperPod Das Checkpointless-Training bietet neuartige Initialisierungsmethoden, Rootless und, für NCCL- und TCPStoreless Gloo-Prozessgruppen.
Die Implementierung dieser Optimierungen beinhaltet die Modifikation von NCCL, Gloo und: PyTorch
Erweiterung der Drittanbieterbibliothek APIs , um Rootless- und Storeless NCCL- und Gloo-Optimierungen zu ermöglichen und gleichzeitig die Abwärtskompatibilität aufrechtzuerhalten
Aktualisierung der Prozessgruppen-Backends, um optimierte Pfade unter bestimmten Bedingungen zu verwenden und Probleme bei der Wiederherstellung während des Prozesses zu lösen
Umgehung der teuren TCPStore Erstellung auf PyTorch verteilter Ebene bei gleichzeitiger Beibehaltung symmetrischer Adressmuster durch globale Gruppenzähler
Die folgende Grafik 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 stellen Schlüssel APIs wie ncclCommInit Rank bereit, 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 (überspringen z. B. die Verbindung zum). TCPStore Sie können flexibel zwischen der Verwendung der ursprünglichen Codepfade und der optimierten Codepfade wechseln.
PyTorch Prozessgruppen-Backend
Die Prozessgruppen-Backends, insbesondere ProcessGroup NCCL und ProcessGroupGloo, implementieren das, ProcessGroup APIs indem sie die entsprechenden zugrunde liegenden APIs Bibliotheken aufrufen. Da wir die Bibliotheken von Drittanbietern erweitern APIs, müssen wir sie ordnungsgemäß aufrufen und Codepfadwechsel auf der Grundlage der Kundenkonfigurationen vornehmen.
Zusätzlich zu den Optimierungscodepfaden ändern wir auch das Prozessgruppen-Backend, um die Wiederherstellung während des Prozesses zu unterstützen.
