Überlastungsregelung für KI-Ethernet: eine Korrektur, die in der Simulation hilft, und ein Fall, in dem sie weiterhin schlechter abschneidet

Beim Training eines großen KI-Modells fließen riesige Datenschübe gleichzeitig zwischen Tausenden von Chips. Wenn das Netzwerk verstopft, bestimmt die langsamste Übertragung das Tempo des gesamten Jobs. Netzwerkhersteller entwerfen dafür neue Überlastungsregelungn. Wir haben in einem öffentlichen Simulator des Ultra-Ethernet-Designs (uet-htsim) gearbeitet, mit der bereits veröffentlichten Methode MNSCC als Ausgangspunkt. Wir haben keine Verbindung zu Cisco oder einem anderen Hersteller.

Eine Änderung in einer einzigen Codezeile verkürzte die typische Abschlusszeit in fünf simulierten Verkehrsszenarien um 3 bis 37 Prozent. Bei Incast schnitt sie leicht schlechter ab. Es handelt sich um ein Simulationsergebnis; die Neuartigkeit wurde nicht geprüft.

Vor dem Messen haben wir die Hypothesen und die Erfolgskriterien aufgeschrieben. Unsere erste Idee - anzupassen, wie stark der Regler sein Verzögerungssignal glättet - scheiterte in zwei Entwürfen. Keiner funktionierte beim Incast-Muster, bei dem viele Sender auf einen Empfänger treffen. Wir haben das als negatives Ergebnis festgehalten.

In Runde drei untersuchten wir, warum ein Entwurf auf einem einzelnen Seed manchmal deutlich verlor. In einem Fall lag der langsamste Fluss unter der Zielverzögerung, doch 72 % seiner Pakete waren als überlastet markiert. Die Markierungsschwelle (40 KB Warteschlange) liegt unter der Zielwarteschlange (etwa 100 KB), eine Markierung sagt also nur, dass die Warteschlange über 40 KB liegt. Der Regler kürzte sein Fenster dann pro Roundtrip um etwa 36 %. Das erklärt diesen Fall aus den Traces. Es ist kein Beweis für alle Fälle.

Die Korrektur, vor dem Test auf frischen Seeds eingefroren: Fenster nur kürzen, wenn auch die Median-Verzögerung auf oder über dem Ziel liegt. Nichts anderes wurde geändert.

Quelle: REPORT3.md, Validierung auf Seeds, die nicht im Design verwendet wurden. Die Bezeichnungen sind die eigenen Szenarionamen des Simulators (ele = Cross-Traffic-Szenarien mit 16 und 8 Pfaden, failed8 = mit ausgefallenen Links); ihre vollständigen Definitionen stehen im ursprünglichen Bericht. Insgesamt 20 gepaarte Seeds: 5, 5, 3, 3 und 2 pro Szenario. In diesen Cross-Traffic-Szenarien verlor kein einziger Seed. Das gilt nur für diese 20 Seeds.

Incast (3 Seeds)

Die mittlere Abschlusszeit lag bei lokaler Platzierung bei 2530 gegenüber 2455 für das adaptive Referenzverfahren (+3,1 %), bei verteilter Platzierung bei 2507 gegenüber 2450 (+2,3 %). Die maximalen Abschlusszeiten waren ungefähr gleich (+0,3 % und +0,4 %). Die einfache NSCC-Methode erzielt bei Incast weiterhin die besten Mittelwerte (2382 und 2444). Unser vorab festgelegtes Kriterium war eine Abweichung von höchstens plus/minus 2 %. Dieser Test ist daher GESCHEITERT.

Schlechtester einzelner Seed bei Incast

+11,8 %, vor der Korrektur +18 %.

• Nur Simulation: ein idealisierter Fat-Tree mit 128 oder 1024 Knoten und 2 bis 5 Seeds pro Szenario.
• MNSCC ist eine veröffentlichte Methode, nicht unsere. Ob unsere Variante neu ist, ist ungeprüft. Die nächstliegenden veröffentlichten Ideen, die wir fanden, sind APSCC und STrack.
• Der verbleibende Incast-Verlust könnte von der Größe der Kürzungen kommen. Das ist eine Hypothese aus den Traces.
• Kein Durchbruch. Ohne Hardware und ohne Herstellerbeteiligung.