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.
Netzwerk
Tipp
Registrieren Sie sich
Erwägen Sie eine höhere Netzwerkbandbreite oder einen Elastic Fabric Adapter für Anwendungen mit hoher Inter-Node Kommunikationsstärke
Für verteilte Trainingsworkloads auf Amazon EKS mit hohen Anforderungen an die Kommunikation zwischen den Knoten sollten Sie in Betracht ziehen, Instances mit höherer Netzwerkbandbreite oder Elastic Fabric Adapter (EFA) auszuwählen. Eine unzureichende Netzwerkleistung kann zu Engpässen bei der Datenübertragung führen und maschinelle Lernaufgaben wie verteiltes Training mit mehreren GPUs verlangsamen. Beachten Sie, dass bei Inferenz-Workloads in der Regel keine intensive Kommunikation zwischen Knoten stattfindet.
Stellen Sie sicher, dass Ihr Container-Image NCCL und das aws-ofi-nccl-Plugin enthält (das es NCCL ermöglicht, EFA über libfabric zu verwenden).
Überlegungen zur Knotenbereitstellung für EFA-Workloads
Bei der Bereitstellung von EFA-capable Knoten müssen sich die Instances, die kommunizieren müssen, in derselben Availability Zone befinden (harte Anforderung). Darüber hinaus empfiehlt AWS, alle EFA-enabled Instances in einer Cluster-Placement-Gruppe zu starten, um die physische Entfernung zwischen ihnen innerhalb dieser einzelnen AZ zu minimieren und Ihnen so die niedrigstmögliche Latenz zu bieten. Eine Platzierungsgruppe ist für das Funktionieren von EFA nicht erforderlich, wird aber für eine optimale Leistung dringend empfohlen.
Die folgenden Überlegungen gelten für alle EFA-based verteilten Trainingsbereitstellungen auf EKS. Im Folgenden beziehen wir uns als Beispiel auf die Anmerkungen von Karpenter. Dieselben Überlegungen können jedoch auch auf die Implementierung von Managed Groups und Self-managed Node Groups angewendet werden.
-
An eine AZ anheften. EFA verlangt, dass sich alle miteinander kommunizierenden Knoten in derselben AZ befinden. Daher dürfen beispielsweise Knoten, die an derselben verteilten Trainingsaufgabe teilnehmen, nicht über mehrere Zonen verteilt sein. Sie können dies erzwingen, indem Sie den Pod mithilfe der Affinität A
nodeSelectoroder Pod an eine AZ anheften.topology.kubernetes.io/zoneWählen Sie die AZ aus, in der Ihr Ziel-Instance-Typ die beste Verfügbarkeit hat oder in der Ihr Kapazitätsblock reserviert ist. Beachten Sie, dass die Kollokation von Same-AZ zwar die Latenz zwischen den Knoten verbessert, aber auch den Blast-Radius eines Ausfalls erhöht. AZ-level Bei lang andauernden Trainingslasten kann ein einziger AZ-Ausfall oder ein Kapazitätsereignis stundenlangen Trainingsfortschritt zunichte machen — ein teurer Verlust. Berücksichtigen Sie dies in Ihrer Checkpoint-Strategie und bei der Planung der Auftragsdauer. -
Konfigurieren Sie die Cluster-Platzierungsgruppe (empfohlen). Geben Sie die Platzierungsgruppe in der an EC2NodeClass. Karpenter versorgt es automatisch. Dies wird für eine optimale Latenz empfohlen, ist aber nicht unbedingt erforderlich, damit EFA funktioniert. Bei Capacity Blocks for ML erfolgt die Platzierung automatisch über UltraClusters — es ist keine manuelle Platzierungsgruppe erforderlich. Beachten Sie, dass in diesem Fall die AZ bereits gesperrt ist und daher keine zusätzlichen Pod-level oder NodePool-level AZ-Einschränkungen erforderlich sind.
-
Verhindern Sie die Unterbrechung von Trainingsaufträgen mit mehreren Knoten. Verwenden Sie PDBs oder
karpenter.sh/do-not-disrupt: "true"Anmerkungen auf Trainings-Pods. Andernfalls versucht die Konsolidierung von Karpenter möglicherweise, EFA-Workloads während der Arbeit zu ersetzen oder zu verschieben, wodurch der gesamte verteilte Trainingslauf unterbrochen wird. Aktivieren Sie die, um eineconsolidationPolicy: WhenEmptyKonsolidierung der belegten Knoten NodePool zu verhindern. Sehen Sie sich die Interaktion zwischen diesen Bezeichnungen undterminationGracePeriodundexpireAfterhier an. -
Stellen Sie das entsprechende Ablaufdatum ein. Stellen Sie den Wert
expireAfterNodePool auf einen Wert ein, der länger ist als Ihr längster Trainingsjob, oder deaktivieren Sie ihn NodePools vollständig für das Training. Ein Knoten, der während des Trainings abläuft, beendet den Job. -
Verwenden Sie die richtige Version des EFA-Geräte-Plugins. Das EFA-Geräte-Plugin wird
vpc.amazonaws.com/efaalsplanbare Ressource verfügbar gemacht. -
Konfigurieren Sie Sicherheitsgruppen. Alle EFA-Instanzen müssen sich in derselben Sicherheitsgruppe befinden, wobei eine selbstreferenzierende Regel den GESAMTEN Datenverkehr selbst zulässt. to/from Andernfalls schlägt der EFA-Verkehr unbemerkt fehl.
Verstehen Sie die Risiken von Spot-Instances mithilfe der EFA-Colocation
Amazon EC2 Spot-Instances bieten erhebliche Kosteneinsparungen bei Schulungsworkloads (in diesem Abschnitt finden Sie allgemeine Best Practices für Spot-Anwendungen mit GPUs). EFA verlangt jedoch, dass sich alle kommunizierenden Knoten in derselben Availability Zone befinden, und AWS empfiehlt, sie für eine optimale Latenz in einer Cluster-Platzierungsgruppe zu platzieren. Diese Zusammenlegung birgt ein korreliertes Unterbrechungsrisiko: Instances teilen sich die zugrunde liegende physische Infrastruktur innerhalb derselben AZ (und noch mehr innerhalb einer Placement-Gruppe), sodass ein einziges Ereignis der Kapazitätsrückgewinnung mehrere Instances gleichzeitig betreffen kann — wodurch möglicherweise Ihr gesamter Trainingsjob mit mehreren Knoten auf einmal unterbrochen wird und nicht nur ein einziger Knoten.
Dies unterscheidet sich grundlegend von der Spot-Nutzung ohne EFA-Einschränkungen, bei der Knoten auf mehrere AZs verteilt werden können und Unterbrechungen statistisch unabhängig sind. Aufgrund der Same-AZ-Anforderung von EFA kann ein einzelnes Kapazitätsereignis in Ihrem Trainingscluster kaskadieren.
Wenn Sie Kosteneinsparungen für GPU-Trainingsworkloads anstreben, stellen Sie sicher, dass Sie alle verfügbaren Kaufoptionen geprüft haben, bevor Sie sich für Spot entscheiden. Reserved Instances, On-Demand Kapazitätsreservierungen (ODCRs), Sparpläne und Kapazitätsblöcke für ML können alle zu erheblichen Rabatten führen und gleichzeitig die Kapazitätsverfügbarkeit garantieren. So wird das korrelierte Unterbrechungsrisiko vermieden, das mit Spot und den Einschränkungen der EFA-Kolokation einhergeht.
Planung der IP-Adressnutzung auf großen GPU-Instances
Standardmäßig weist das Amazon VPC CNI-Plugin IP-Adressen im Voraus zu, um sicherzustellen, dass Pods schnell geplant werden können, wobei eine vollständige Ersatz-ENI angehängt und mit IP-Adressen gefüllt wird. Bei großen Instances kann dies dazu führen, dass Dutzende von IPs pro Knoten reserviert werden, selbst wenn nur wenige Pods laufen.
Diese Diskrepanz tritt häufig bei Trainings- und Inferenz-Workloads auf, bei denen die Pod-Dichte pro Knoten niedrig ist. Auf Clusterebene, insbesondere bei Autoscaling-Ereignissen, bei denen viele GPU-Knoten mit jeweils wenigen Pods hochgefahren werden, kann dies zu einer Erschöpfung der Subnetz-IP führen, obwohl die tatsächliche IP-Auslastung gering ist.
Um dem entgegenzuwirken, stimmen Sie die WARM_ENI_TARGET Variablen, und so WARM_IP_TARGET abMINIMUM_IP_TARGET, dass sie Ihrer tatsächlichen Pod-Dichte entsprechen. Weitere Informationen finden Sie unter ENI- und IP-Zieleinstellungen von VPC CNI.
Eine vollständige Anleitung zur Optimierung der IP-Nutzung finden Sie unter Optimieren der IP-Adressnutzung.
