Meta hat am 24. August die Designdetails von MetaRoCE veröffentlicht, einem selbst entwickelten RDMA-Transportprotokoll als Ersatz für Standard-RoCE. Auf dem OCP Global Summit im Oktober sollen die vollständige Protokollspezifikation, eine Referenzimplementierung namens libsoftmetaroce und eine Testsuite für Produktionskonformität gemeinsam veröffentlicht werden.
Standard-RoCE stößt bei hunderttausenden Karten an seine Grenzen
RoCE geht davon aus, dass das Netzwerk jeden Frame in der richtigen Reihenfolge zustellt, abgesichert durch PFC (Priority Flow Control) auf den Switches, um Paketverlust zu vermeiden. Diese Annahme funktioniert in Clustern mit ein paar hundert Karten recht gut, beginnt aber bei Metas heutiger Größenordnung zu bröckeln.
Meta selbst formuliert es so: Standard-RoCE erwartet eine geordnete Zustellung jedes Frames, verlässt sich auf PFC und rät von Packet Spraying ab – ausgerechnet der Technik, mit der sich die Leistung in großen Multi-Plane-Netzwerken steigern lässt. Genau hier liegt der Konflikt: Pakete eines Flows gleichzeitig über mehrere Pfade zu verteilen, widerspricht direkt der "geordneten Zustellung". PFC arbeitet zudem als Hop-by-Hop-Backpressure – ein Stau an einer Stelle drückt sich durch das ganze Netz zurück und kann bei sehr großem Maßstab Kaskadeneffekte auslösen. Kollektive Kommunikationsmuster wie All-Reduce müssen Tausende Beschleuniger synchronisieren, und die langsamste Übertragung bestimmt das Tempo des gesamten Jobs.
Das von Meta genannte Zielszenario sind "mehrere hunderttausend GPUs, verteilt über mehrere Rechenzentren und Regionen". Bei dieser Größenordnung ist es bereits ein Glücksspiel, ein verlustfreies Netzwerk allein über Switches aufrechtzuerhalten.
Die Intelligenz wandert auf die Netzwerkkarte
Metas Designprinzip für MetaRoCE lässt sich in einem Satz zusammenfassen:
"The fabric sees packets, but the NIC sees intent."
Das Netz sieht nur Pakete, die Netzwerkkarte kennt die Absicht.
Konkret wird das in sechs Punkten: native Zustellung außer der Reihe, Pakete werden absichtlich über mehrere Pfade verteilt und Daten direkt in die Zieladresse im Speicher geschrieben, ohne Reorder-Puffer; native Mehrwegfähigkeit, jede Verbindung hält mehrere logische Pfade, die jeweils eigene Round-Trip-Latenz und ECN-Status verfolgen; Toleranz gegenüber Paketverlust, der als Normalfall behandelt und über eine selektive Bestätigungs-Bitmap ausgeglichen wird, ohne PFC; doppelte Staukontrolle aus AIMD auf Senderseite plus einem fairen Ratenhinweis auf Empfängerseite; Topologie-Unabhängigkeit, es braucht nur ECN-Markierung und ECMP, egal ob Fat-Tree, Multi-Plane oder Switches mit flachen Puffern; und eine vereinheitlichte Verbindung, bei der eine einzige Queue mehrere geordnete Nachrichtenströme und mehrere Pfade trägt und sich einen gemeinsamen Stau-Controller teilt.
Die Zahlen aus dem 64-Knoten-Test
Getestet wurde auf einem Cluster mit 64 AMD-GPU-Knoten. Der Durchsatz lag durchgehend über RoCEv2; bei 1 % Paketverlust blieben rund 86 % des Durchsatzes erhalten, bei 10 % Verlust funktionierte das System weiterhin. Bei Topologien mit 4 und 8 Ebenen ("Planes") skalierte der Durchsatz linear, getestet wurde bis zu 4.000 gleichzeitigen Verbindungen. Fällt eine einzelne Ebene aus, verteilt sich der Verkehr eigenständig neu, ohne dass die Anwendungsschicht eingreifen muss.
Zwischen 64 Knoten und "mehreren hunderttausend Karten" liegt noch ein weiter Weg. Meta teilt die weitere Arbeit in drei Bereiche: Scale-up innerhalb eines Racks soll schnelle Signalisierung für kurze Speicheroperationen optimieren und die Latenz durch Reorder-Puffer und PFC beseitigen; Scale-across über Tausende Kilometer soll pfadweise Anpassung und Fairness über Fernverbindungen mit Millisekunden-Round-Trip-Zeit ermöglichen; für Storage- und KV-Cache-Szenarien plant Meta, Ratenhinweise auf Empfängerseite gegen Incast einzusetzen, wenn ein einzelner Lesezugriff auf mehrere Server verteilt wird.
Open Source als Signal an die NIC-Hersteller
Auf der NIC-Seite gibt es bislang nur bei AMD Pensando eine verifizierte Implementierung, andere Hersteller arbeiten daran. Das entscheidet darüber, wie weit MetaRoCE kommt – ein noch so elegantes Protokoll bleibt Metas interne Lösung, wenn es nicht in die Firmware gängiger Netzwerkkarten einzieht.
Die Veröffentlichung über die OCP, ausdrücklich abgestimmt mit der ESUN-Initiative (Ethernet Scalable Unified Network), verfolgt eine klare Absicht: Hersteller sollen Netzwerkkarten nach dieser Spezifikation ausliefern, damit Meta selbst bei der Beschaffung mehr Auswahl hat. Diesen Weg ist das Ethernet-Lager schon einmal gegangen – RoCE konnte InfiniBand Marktanteile abnehmen, weil das Ethernet-Ökosystem günstiger war und mehr Anbieter hatte. Jetzt, wo RoCE selbst zum Flaschenhals geworden ist, will Meta denselben Ansatz noch einmal durchspielen: die Spezifikation zuerst offenlegen und alle anderen zum Mitziehen bewegen.
Für Teams, die große KI-Rechencluster aufbauen, lohnt sich nach Veröffentlichung der Oktober-Spezifikation ein genauer Blick, besonders auf den Punkt "kein PFC nötig". Wer sich das PFC-Tuning sparen kann, verliert eine der hartnäckigsten Fehlerquellen im Betrieb.
Quellen: Metas Engineering-Blog, CocoLoop, Materialien rund um die ESUN-Initiative der OCP; Angaben wie rund 86 % Durchsatz bei 1 % Paketverlust, weiterhin funktionsfähig bei 10 % Verlust, der 64-Knoten-AMD-GPU-Cluster und die 4.000 gleichzeitigen Verbindungen wurden anhand der von Meta veröffentlichten Testbeschreibung geprüft.