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.

In der Praxis heißt das, 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 weniger Beteiligung von CPU und Kernel-Netzwerk 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.

Für verteiltes Training ist das relevant, weil ständig Daten zwischen Workern hin- und hergehen. Muss die CPU jeden Teil davon über einen herkömmlichen Netzwerk-Stack abwickeln, kann der Kommunikations-Overhead im großen Maßstab erheblich werden. RDMA macht den Kommunikationspfad direkter.

Gegen Überlastung, Fehlkonfiguration, physische Fehler oder Topologieprobleme schützt RDMA das Netzwerk allerdings nicht. Es ist eine Transportfähigkeit und keine Garantie für schnelles Training.

Was ist InfiniBand?

InfiniBand ist eine leistungsstarke, latenzarme, RDMA-fähige Netzwerktechnologie, die in HPC- und großen KI-Umgebungen eingesetzt wird. So beschreibt es auch die Referenzdokumentation zu NVIDIAs DGX SuperPOD für Compute-Umgebungen. In einem KI-Cluster kann InfiniBand das Scale-out-Fabric stellen, das die am verteilten Training beteiligten Nodes verbindet.

Eine hohe nominelle Bandbreite reicht dafür nicht. 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, und diesen Unterschied zwischen Verfügbarkeit und Performance sollte man im Blick behalten.

Was ist RoCE?

RDMA over Converged Ethernet, kurz RoCE, transportiert RDMA-Verkehr über Ethernet. Organisationen können damit RDMA-fähige KI-Fabrics auf Ethernet-Infrastruktur aufbauen, sofern Design, Adapter, Switches, Konfiguration und Betrieb das nötige Verhalten mitbringen.

RoCE gegen InfiniBand lässt sich nicht auf eine einfache Kaufentscheidung „Ethernet versus Nicht-Ethernet“ reduzieren. Im Betrieb zählen andere Fragen. Liefert das Fabric die Bandbreite, die der Workload braucht, und kann es Überlastung kontrollieren? Vermeidet es Paketverlust so, wie der Einsatz es erwartet, oder erholt es sich entsprechend davon? Sehen Betreiber die relevante NIC- und Switch-Telemetrie? Passt die Topologie zu den Platzierungsentscheidungen des Schedulers, und kann das Team das Fabric während einer Trainingsverlangsamung diagnostizieren?

Die Antworten darauf sagen 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. Dazu gehören Operationen wie All-Reduce, All-Gather, Reduce-Scatter, Broadcast und Punkt-zu-Punkt-Kommunikationsmuster, die für viele Formen des verteilten Deep Learning zentral sind.

Beim datenparallelen Training müssen Worker zum Beispiel häufig Gradienten austauschen oder reduzieren. Der langsamste Kommunikationspfad kann deshalb den ganzen Trainingsschritt aufhalten. Die GPU schließt ihre lokale Berechnung ab und wartet dann, bis die kollektive Operation fertig ist.

Im GPU-Diagramm sieht diese Wartezeit wie geringere Auslastung aus, im Netzwerkdiagramm wie Überlastung, Neuübertragung oder ein Ungleichgewicht zwischen Links. Erst zusammen ergeben beide Ansichten ein Bild.

Wie wirkt sich Netzwerk-Paketverlust auf das Training aus?

Paketverlust kann die Kommunikationszeit erhöhen, sodass verteilte Worker länger aufeinander warten. Wie stark, hängt von Netzwerktechnologie, Transport, kollektiver Bibliothek, Überlastungskontrolle und Workload ab.

Für den Betrieb zählt vor allem, dass ein kleines Netzwerkproblem sehr viele GPUs treffen kann. Ist ein Node an einem Acht-Node-Kollektiv beteiligt und wird sein Netzwerkpfad langsam, warten die anderen Worker an den Synchronisationspunkten. Ein einziger schlechter Pfad verschwendet so Rechenleistung auf gesunden Nodes.

Überwachen Sie Verlust- und Fehlerzähler auf NIC- und Switch-Ebene, soweit verfügbar, und zusätzlich die Neuübertragungs- oder Überlastungsindikatoren, die zum jeweiligen Fabric passen. Ordnen Sie die betroffenen Ports dann den physischen Nodes und dem Trainingsjob zu. Ein Paketverlust-Alarm ohne Job-Kontext sagt dem Netzwerkteam, dass etwas passiert ist. Ist derselbe Alarm mit einem 256-GPU-Trainingsjob verknüpft, weiß das Betriebsteam auch, warum er wichtig ist.

Wie wirkt sich Latenz auf das KI-Training aus?

Latenz bremst das Training, wenn Workloads häufig kommunizieren oder synchronisieren und sich diese Operationen nicht hinter nützlicher Berechnung verstecken lassen. Hohe Bandbreite braucht man, um große Datenmengen zu bewegen, niedrige und gleichmäßige Latenz für häufige Koordination. Wie sich das gewichtet, hängt von der Form des Workloads ab. Große All-Reduce-Operationen fordern womöglich vor allem Bandbreite, kleinere, häufige Operationen reagieren eher empfindlich auf Latenz.

Auch die Tail-Latenz spielt eine Rolle. Kommunizieren die meisten Nodes schnell, wird aber ein Pfad regelmäßig deutlich langsamer, warten verteilte Schritte auf diesen einen langsamen Teilnehmer. Perzentile und Ausreißer sagen deshalb oft mehr als ein einfacher Durchschnitt. Das gilt genauso für Storage-Latenz, wo Durchschnittswerte die Pausen verbergen, in denen GPUs warten.

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 Kapazität allein sagt darüber wenig. Verfolgen Sie Durchsatz, IOPS, Latenz, soweit verfügbar das Queue-Verhalten und die Lese- oder Schreibaktivität auf Job-Ebene.

Ein Workload mit einem großen sequenziellen Dataset hängt oft stark vom Durchsatz ab, während einer, der viele kleine Dateien anfasst, empfindlich auf Metadaten und IOPS reagiert. Checkpointing kann große Schreib-Bursts erzeugen, eine Wiederherstellung große Lesevorgänge.

Erstellen mehrere Jobs gleichzeitig Checkpoints, kann das Storage-System insgesamt gesund sein und trotzdem so viel Konkurrenz erzeugen, dass das Training langsamer wird. Storage- und Scheduler-Verhalten sollten deshalb ebenfalls verbunden sein. Manchmal lässt sich die Konkurrenz verringern, indem das System Checkpoints zeitlich staffelt oder weiß, 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.

Am einfachsten prüft man das über Korrelation. Legen Sie GPU-Auslastung und Trainingsschrittzeit in ein Diagramm und ergänzen Sie Storage-Durchsatz, Storage-Latenz und, falls verfügbar, das CPU-seitige Data-Loading. Fällt die GPU-Auslastung, während die Storage-Latenz steigt und der nächste Batch später ankommt, ist Storage ein starker Kandidat. Bleiben die Storage-Metriken normal, steigt aber die Netzwerkkommunikationszeit, gehört das Fabric auf den Prüfstand. Ist beides normal und die CPU-seitige Datenvorbereitung ausgelastet, liegt es eher am Data-Loading.

Diese domänenübergreifende Methode wird auch in warum die GPU-Auslastung niedrig sein kann erklärt. Ändern Sie keine GPU-Einstellungen, bevor feststeht, dass der Beschleuniger tatsächlich der Engpass ist.

Warum sollten Compute, Netzwerk und Storage dieselbe Zeitachse nutzen?

Auf einer gemeinsamen Zeitachse sehen Betreiber die Abfolge der Ereignisse. 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, und um 11:42:18 verdoppelt sich die Trainingsschrittzeit. Diese Abfolge ist ein viel stärkerer Beweis als vier separate Dashboards.

Für Storage funktioniert das genauso. Steigt die Storage-Latenz, verzögert sich danach der Data-Loader und folgt darauf GPU-Leerlaufzeit, ergibt das eine nachvollziehbare Kette.

Zeitsynchronisation wird damit zur betrieblichen Anforderung. Switches, NICs, Server, Storage-Systeme, Scheduler und Anwendungsmetriken brauchen Zeitstempel, die sich genau genug vergleichen lassen, um die Diagnose zu tragen.

Was sollte im Trainingsnetzwerk überwacht werden?

Überwachen Sie die Signale, mit denen sich Verfügbarkeit, Kapazität und Verschlechterung erklären lassen. Nützlich sind vor allem:

• 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. Eine einzige fest kodierte Metrikliste, die für InfiniBand und RoCE gleichermaßen gelten soll, funktioniert deshalb nicht. Normalisieren Sie die betriebliche Bedeutung und bewahren Sie die fabric-spezifischen Details. Beide Fabrics brauchen zum Beispiel ein Konzept von Verbindungszustand, die zugrunde liegenden Zähler können aber verschieden sein.

Wie sollte die Topologie das Scheduling beeinflussen?

Wenn Kommunikation etwas kostet, sollte die Topologie die Platzierung mitbestimmen. Erwartet der Workload enge Kommunikation, sind acht GPUs in einem Server etwas anderes als acht GPUs auf weit entfernten Nodes. Ebenso kann eine Gruppe von Nodes in derselben schnellen Fabric-Domäne besser geeignet sein als dieselbe Anzahl Nodes hinter einem ungünstigeren Pfad.

Der Scheduler sollte die Topologie als Einschränkung hinter der Ressourcenanfrage behandeln. Nutzer sollten sich keine Switch-Namen merken müssen. Sie sollten eine Trainingsressourcenklasse anfordern können, und die Plattform sollte deren Topologieanforderungen erfüllen.

Ausführlicher behandelt das GPU-Ressourcen-Pooling und Scheduling in Kubernetes.

Wie unterscheidet man einen Netzwerkengpass von einem Storage-Engpass?

Schauen Sie auf die Phase des Workloads und auf korrelierte Metriken. Tritt die Verlangsamung während der Modellsynchronisation oder kollektiver Operationen auf und ändern sich gleichzeitig die Netzwerkindikatoren, untersuchen Sie das Netzwerk. Tritt sie beim Lesen von Daten oder Schreiben von Checkpoints auf und ändert sich die Storage-Latenz, untersuchen Sie den Storage. Ändert sich beides gleichzeitig, prüfen Sie, ob der Storage-Pfad dasselbe Netzwerk-Fabric oder dieselben Switches nutzt, denn bei Remote-Storage kann ein Storage-Problem tatsächlich ein Netzwerkproblem sein.

Organisatorische Grenzen helfen dabei wenig. Dem Storage-Team gehört vielleicht das Array und dem Netzwerkteam der Pfad, der Trainingsjob erlebt aber eine einzige Datenversorgungskette.

Wie sieht guter Betrieb aus?

Guter Betrieb kommt von einem langsamen Trainingsjob schnell zur eingeschränkten Domäne und kann die Belege dafür zeigen. Der Betreiber sollte beantworten können, welche GPUs am Job beteiligt sind, auf welchen Nodes sie laufen, welche Netzwerkpfade sie verbinden und welches Storage-System die Daten liefert. Außerdem sollte er wissen, was sich geändert hat, als die Performance sank, ob der Engpass bei Compute, Netzwerk, Storage oder Data-Loading liegt und was nach dem Tuning passiert ist.

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.