Wie beeinflussen RDMA, RoCE, InfiniBand, Netzwerk-Paketverlust und Storage-Performance die Leistung beim KI-Training?

RDMA, RoCE, InfiniBand, Netzwerkqualität und Storage-Performance beeinflussen das KI-Training, weil verteiltes Training genauso sehr ein Datenbewegungsproblem wie ein Rechenproblem ist. GPUs können gesund und verfügbar sein und trotzdem einen erheblichen Teil der Zeit damit verbringen, auf andere Worker oder auf Daten aus dem Storage zu warten.

Die praktische Regel lautet, Compute, Netzwerk und Storage auf derselben Zeitachse zu analysieren. Eine fallende GPU-Auslastungskurve beweist kein GPU-Problem. Sie kann das sichtbare Symptom von Paketverlust, Kommunikationsverzögerung, Storage-Latenz oder verzögerter Datenzustellung an anderer Stelle in der Trainingskette sein.

Was ist RDMA?

Remote Direct Memory Access, kurz RDMA, ist ein Datenübertragungsmodell, das Speicher-zu-Speicher-Kommunikation mit reduzierter CPU- und Kernel-Netzwerkbeteiligung ermöglicht.

Die Dokumentation von NVIDIAs Network Operator beschreibt RDMA als Speicher-zu-Speicher-Übertragung, die CPU und Kernel-Netzwerk-Stack umgeht, mit Unterstützung für InfiniBand- und RoCE-Umgebungen.

Das ist wichtig, weil verteiltes Training wiederholt Daten zwischen Workern bewegt.

Wenn die CPU jeden Teil dieser Bewegung über einen herkömmlichen Netzwerk-Stack abwickeln muss, kann der Kommunikations-Overhead im großen Maßstab erheblich werden.

RDMA hilft dabei, den Kommunikationspfad direkter zu gestalten.

Es macht das Netzwerk aber nicht immun gegen Überlastung, Fehlkonfiguration, physische Fehler oder Topologieprobleme.

RDMA ist daher eine Transportfähigkeit, keine Garantie dafür, dass das Training schnell sein wird.

Was ist InfiniBand?

InfiniBand ist eine leistungsstarke, latenzarme, RDMA-fähige Netzwerktechnologie, die in HPC- und großangelegten KI-Umgebungen eingesetzt wird.

Die Referenzdokumentation zu NVIDIAs DGX SuperPOD beschreibt InfiniBand als leistungsstarke, latenzarme, RDMA-fähige Netzwerktechnologie für Compute-Umgebungen.

In einem KI-Cluster kann InfiniBand das Scale-out-Fabric bereitstellen, das die am verteilten Training beteiligten Nodes verbindet.

Das Netzwerk braucht mehr als eine hohe nominelle Bandbreite.

Das Betriebsteam muss weiterhin Ports, Verbindungsstatus, Fehler, Überlastung, Latenz, Durchsatz, Topologie und den Zusammenhang zwischen Fabric-Ereignissen und Jobs überwachen.

Ein Netzwerk kann „oben“ sein und das Training trotzdem verlangsamen.

Dieser Unterschied zwischen Verfügbarkeit und Performance ist entscheidend.

Was ist RoCE?

RDMA over Converged Ethernet, kurz RoCE, transportiert RDMA-Verkehr über Ethernet.

Das erlaubt es Organisationen, RDMA-fähige KI-Fabrics auf Ethernet-Infrastruktur aufzubauen, wenn Design, Adapter, Switches, Konfiguration und Betrieb das erforderliche Verhalten unterstützen.

RoCE und InfiniBand sollten nicht auf eine einfache „Ethernet versus Nicht-Ethernet“-Kaufentscheidung reduziert werden.

Die eigentlichen betrieblichen Fragen sind:

Kann das Fabric die vom Workload benötigte Bandbreite liefern?

Kann es Überlastung kontrollieren?

Kann es Paketverlust so vermeiden oder sich davon erholen, wie es der Einsatz erwartet?

Können Betreiber die relevante NIC- und Switch-Telemetrie einsehen?

Kann die Topologie die Platzierungsentscheidungen des Schedulers unterstützen?

Kann das Team das Fabric während einer Trainingsverlangsamung diagnostizieren?

Die Antworten zählen mehr als das Akronym.

Was leistet NCCL beim verteilten Training?

Die NVIDIA Collective Communications Library, kurz NCCL, stellt optimierte kollektive Kommunikationsprimitive für Multi-GPU- und Multi-Node-Workloads bereit.

NCCL umfasst Operationen wie All-Reduce, All-Gather, Reduce-Scatter, Broadcast und Punkt-zu-Punkt-Kommunikationsmuster.

Diese kollektiven Operationen sind für viele Formen des verteilten Deep Learning zentral.

Beim datenparallelen Training müssen Worker zum Beispiel häufig Gradienten austauschen oder reduzieren.

Das bedeutet, dass der langsamste Kommunikationspfad den Trainingsschritt aufhalten kann.

Die GPU kann ihre lokale Berechnung abschließen und dann auf den Abschluss der kollektiven Operation warten.

Im GPU-Diagramm kann diese Wartezeit als geringere Auslastung erscheinen.

Im Netzwerkdiagramm kann sie als Überlastung, Neuübertragung oder Ungleichgewicht zwischen Links erscheinen.

Die beiden Ansichten müssen zusammengeführt werden.

Wie wirkt sich Netzwerk-Paketverlust auf das Training aus?

Paketverlust kann die Kommunikationszeit erhöhen und verteilte Worker länger aufeinander warten lassen.

Der genaue Effekt hängt von Netzwerktechnologie, Transport, kollektiver Bibliothek, Überlastungskontrolle und Workload ab.

Betrieblich ist der wichtige Punkt, dass ein kleines Netzwerkproblem eine viel größere Anzahl von GPUs betreffen kann.

Wenn ein Node an einem Acht-Node-Kollektiv beteiligt ist und sein Netzwerkpfad langsam wird, können die anderen Worker an Synchronisationspunkten warten.

Das erzeugt einen Multiplikatoreffekt.

Ein schlechter Pfad kann Rechenleistung auf gesunden Nodes verschwenden.

Überwachen Sie Verlust- und Fehlerzähler auf NIC- und Switch-Ebene, wo verfügbar.

Überwachen Sie auch Neuübertragungs- oder Überlastungsindikatoren, die zum jeweiligen Fabric passen.

Bilden Sie dann die betroffenen Ports auf die physischen Nodes und den Trainingsjob ab.

Ein Paketverlust-Alarm ohne Job-Kontext sagt dem Netzwerkteam, dass etwas passiert ist.

Ein Paketverlust-Alarm, der mit einem 256-GPU-Trainingsjob verknüpft ist, sagt dem Betriebsteam, warum das wichtig ist.

Wie wirkt sich Latenz auf das KI-Training aus?

Latenz wirkt sich auf das Training aus, wenn Workloads häufige Kommunikations- oder Synchronisationsoperationen durchführen, die sich nicht hinter nützlicher Berechnung verbergen lassen.

Hohe Bandbreite ist wichtig, um große Datenmengen zu bewegen.

Niedrige und gleichmäßige Latenz ist wichtig für häufige Koordination.

Das Gleichgewicht hängt von der Form des Workloads ab.

Große All-Reduce-Operationen betonen möglicherweise die Bandbreite.

Kleinere, häufige Operationen können latenzempfindlicher sein.

Auch die Tail-Latenz ist wichtig.

Wenn die meisten Nodes schnell kommunizieren, aber ein Pfad regelmäßig deutlich langsamer wird, können verteilte Schritte auf diesen langsamen Teilnehmer warten.

Deshalb können Perzentil- und Ausreißerverhalten mehr zählen als ein einfacher Durchschnitt.

Dieselbe Idee gilt für Storage-Latenz.

Durchschnittswerte verbergen die Pausen, die GPUs warten lassen.

Wie wirkt sich Storage-Performance auf das Training aus?

Storage beeinflusst das Training über Dataset-Lesevorgänge, Metadatenzugriffe, Modell-Ladevorgänge, Checkpoint-Schreibvorgänge und Checkpoint-Wiederherstellungen.

Die nützlichen Storage-Metriken sind nicht nur die Kapazität.

Verfolgen Sie Durchsatz, IOPS, Latenz, Queue-Verhalten, sofern verfügbar, und die Lese- oder Schreibaktivität auf Job-Ebene.

Ein Workload mit einem großen sequenziellen Dataset kann stark vom Durchsatz abhängen.

Ein Workload, der viele kleine Dateien berührt, kann empfindlich auf Metadaten und IOPS reagieren.

Checkpointing kann große Schreib-Bursts erzeugen.

Wiederherstellung kann große Lesevorgänge erzeugen.

Wenn mehrere Jobs gleichzeitig Checkpoints erstellen, kann das Storage-System insgesamt gesund sein und trotzdem genug Konkurrenz erzeugen, um das Training zu verlangsamen.

Deshalb sollten Storage- und Scheduler-Verhalten ebenfalls verbunden sein.

Das System kann die Konkurrenz manchmal reduzieren, indem es Checkpoint-Aktivitäten zeitlich staffelt oder versteht, welche Workloads sich einen Storage-Pool teilen.

Kann Storage niedrige GPU-Auslastung verursachen?

Ja. Langsamer Storage kann GPUs auf den nächsten Batch warten lassen.

Der einfachste Weg, die Hypothese zu testen, ist Korrelation.

Stellen Sie GPU-Auslastung und Trainingsschrittzeit grafisch dar.

Fügen Sie Storage-Durchsatz und Latenz hinzu.

Fügen Sie CPU-seitiges Data-Loading hinzu, sofern verfügbar.

Wenn die GPU-Auslastung fällt, während die Storage-Latenz steigt und der nächste Batch später ankommt, wird Storage zu einem starken Kandidaten.

Wenn die Storage-Metriken normal bleiben, aber die Netzwerkkommunikationszeit steigt, schauen Sie sich das Fabric an.

Wenn beides normal ist und die CPU-seitige Datenvorbereitung ausgelastet ist, schauen Sie sich das Data-Loading an.

Diese domänenübergreifende Methode wird auch in warum die GPU-Auslastung niedrig sein kann erklärt.

Der Punkt ist, keine GPU-Einstellungen zu ändern, bevor bewiesen ist, dass der Beschleuniger die Einschränkung ist.

Warum sollten Compute, Netzwerk und Storage dieselbe Zeitachse nutzen?

Eine gemeinsame Zeitachse lässt Betreiber die Abfolge erkennen.

Angenommen, ein Job wird um 11:42:15 langsamer.

Um 11:42:10 beginnt ein Switch-Port, Fehler zu melden.

Um 11:42:12 steigt die Dauer der kollektiven Kommunikation.

Um 11:42:15 fällt die GPU-Auslastung.

Um 11:42:18 verdoppelt sich die Trainingsschrittzeit.

Diese Abfolge ist ein viel stärkerer Beweis als vier separate Dashboards.

Dieselbe Methode funktioniert für Storage.

Ein Anstieg der Storage-Latenz, gefolgt von einer Verzögerung im Data-Loader, gefolgt von GPU-Leerlaufzeit, ergibt eine nachvollziehbare Kette.

Zeitsynchronisation wird damit zu einer betrieblichen Anforderung.

Switches, NICs, Server, Storage-Systeme, Scheduler und Anwendungsmetriken brauchen Zeitstempel, die genau genug verglichen werden können, um die Diagnose zu stützen.

Was sollte im Trainingsnetzwerk überwacht werden?

Überwachen Sie die Signale, die Verfügbarkeit, Kapazität und Verschlechterung erklären können.

Nützliche Bereiche sind:

Verbindungsstatus und -geschwindigkeit
Durchsatz
Paket- oder Symbolfehler, wo sichtbar
Verlustindikatoren
Neuübertragungs- oder Wiederholungsverhalten
Überlastungstelemetrie
Latenz
NIC-Zustand
Optik-Zustand, wo relevant
Port-Auslastung
Topologie
Dauer der kollektiven Kommunikation, wo verfügbar

Die genauen Zähler unterscheiden sich je nach Fabric.

Erstellen Sie keine einzige fest kodierte Metrikliste in der Annahme, dass sie sowohl für InfiniBand als auch für RoCE funktioniert.

Normalisieren Sie die betriebliche Bedeutung, während Sie fabric-spezifische Details bewahren.

Zum Beispiel brauchen beide Fabrics ein Konzept von Verbindungszustand, aber die zugrunde liegenden Zähler können sich unterscheiden.

Wie sollte die Topologie das Scheduling beeinflussen?

Topologie sollte die Platzierung beeinflussen, wenn Kommunikationskosten eine Rolle spielen.

Acht GPUs auf einem Server sind nicht gleichwertig mit acht GPUs, die über weit entfernte Nodes verteilt sind, wenn der Workload enge Kommunikation erwartet.

Ebenso kann eine Gruppe von Nodes, die sich eine schnelle Fabric-Domäne teilen, eine bessere Platzierung sein als dieselbe Anzahl von Nodes, die über einen weniger günstigen Pfad erreicht werden.

Der Scheduler sollte Topologie als Einschränkung hinter der Ressourcenanfrage verwenden.

Nutzer sollten sich keine Switch-Namen merken müssen.

Sie sollten eine Trainingsressourcenklasse anfordern können, und die Plattform sollte deren Topologieanforderungen erfüllen.

Das wird ausführlicher in GPU-Ressourcen-Pooling und Scheduling in Kubernetes behandelt.

Wie unterscheidet man einen Netzwerkengpass von einem Storage-Engpass?

Nutzen Sie die Workload-Phase und korrelierte Metriken.

Wenn die Verlangsamung während der Modellsynchronisation oder kollektiver Operationen auftritt und sich die Netzwerkindikatoren zur gleichen Zeit ändern, untersuchen Sie das Netzwerk.

Wenn die Verlangsamung beim Lesen von Daten oder Schreiben von Checkpoints auftritt und sich die Storage-Latenz ändert, untersuchen Sie den Storage.

Wenn sich beides gleichzeitig ändert, prüfen Sie, ob der Storage-Pfad dasselbe Netzwerk-Fabric oder dieselben Switches nutzt.

Ein Storage-Problem kann tatsächlich ein Netzwerkproblem sein, wenn der Storage remote liegt.

Halten Sie sich nicht an organisatorischen Grenzen auf.

Das Storage-Team besitzt vielleicht das Array, während das Netzwerkteam den Pfad besitzt, aber der Trainingsjob erlebt eine einzige Datenversorgungskette.

Wie sieht guter Betrieb aus?

Guter Betrieb kann schnell von einem langsamen Trainingsjob zur eingeschränkten Domäne gelangen und die Beweise zeigen.

Der Betreiber sollte beantworten können:

Welche GPUs sind am Job beteiligt?

Welche Nodes hosten sie?

Welche Netzwerkpfade verbinden sie?

Welches Storage-System liefert die Daten?

Was hat sich geändert, als die Performance sank?

Ist der Engpass Compute, Netzwerk, Storage oder Data-Loading?

Was ist nach dem Tuning passiert?

Ein Plattformbeispiel, das diese Domänen korreliert, ist Sensaka.

Wenn ich eine Verlangsamung beim verteilten Training diagnostizieren würde, würde ich nicht damit anfangen zu fragen, welches Infrastrukturteam für das Problem zuständig ist. Ich würde mit einer synchronisierten Zeitachse über GPU-Aktivität, kollektive Kommunikation, NIC- und Switch-Telemetrie, Storage-Durchsatz, Storage-Latenz und Trainingsschrittzeit beginnen. Die erste Domäne, deren Verhalten sich vor der Verlangsamung ändert, ist die, die ich zuerst untersuchen würde.