MRC macht KI Supercomputer Netzwerke schneller und robuster

MRC (Multipath Reliable Connection) ist ein Netzwerkprotokoll für sehr große GPU-Cluster, das Datenübertragungen parallel über viele Pfade verteilt und Ausfälle so schnell umgeht, dass synchrones KI-Training seltener ins Stocken gerät. Der Kernpunkt ist nicht mehr Spitzengeschwindigkeit pro Link, sondern planbare Leistung trotz Staus, Link-Flaps und Wartung.

Übersicht:

Warum großes KI-Training am Netzwerk scheitert

Bei synchronem Training arbeiten viele GPUs taktgesteuert zusammen. Wenn nur eine einzelne Datenübertragung zu spät ankommt, warten im Extremfall tausende GPUs, als würde in einer Fabrik ein einzelnes fehlendes Teil das Fließband stoppen.

In sehr großen Clustern nehmen drei Störquellen zu: Überlastung an Engstellen, kurzfristige Link-Probleme und Switch-Ausfälle. Je größer der Verbund, desto häufiger treten solche Ereignisse als Dauerrauschen auf, und desto teurer wird jeder Abbruch oder jede lange Rekonvergenz, weil GPU-Zeit verbrannt wird.

Was MRC ist und worauf es aufbaut

MRC ist ein Transportprotokoll für GPU-Netzwerke, das auf RDMA setzt, also Daten direkt zwischen Speicherbereichen von GPUs und CPUs schiebt, ohne die CPU mit Kopierarbeit zu beschäftigen. In Rechenzentren läuft RDMA häufig über Ethernet mit RoCE, das als Standardfamilie rund um RDMA over Converged Ethernet bekannt ist.

Die zentrale Abweichung zu klassischen RoCE-Setups ist die Pfadlogik: Statt eine Übertragung an genau einen Pfad zu binden, kann MRC ein und dieselbe Übertragung auf sehr viele Wege verteilen. Dazu kommt ein Mechanismus, der bei Verlust oder Stau aggressiv umsteuert, ohne erst auf langsam reagierende Routing-Neuberechnungen im Fabric zu warten.

OpenAI beschreibt MRC als Ergebnis einer Kooperation mit AMD, Broadcom, Intel, Microsoft und NVIDIA und ordnet es in einen breiteren Trend ein: Ethernet soll in sehr großen KI-Clustern nicht nur günstiger sein, sondern auch deterministischer betreibbar werden. Details stehen im begleitenden Paper Resilient AI Supercomputer Networking using MRC and SRv6.

Zur Standardisierung verweist OpenAI auf eine Einreichung bei der Open Compute Project Community. Öffentlich sichtbar ist dort zumindest der Kontext rund um den MRC-Workstream, etwa über Semi-Private Workstreams und den Einstieg über Open Compute Project.

Das Drei-Bausteine-Modell für KI-Fabrics

Wer KI-Training skalieren will, muss drei Ebenen gleichzeitig sauber lösen. MRC ist interessant, weil es genau an dieser Dreiteilung ansetzt.

• Topologie: Genug redundante Wege, damit Ausfälle keine Katastrophe sind.

• Verkehr: Last so verteilen, dass einzelne Links oder Switches nicht zu dauerhaften Hotspots werden.

• Steuerung: Ein Control-Plane-Ansatz, der im Fehlerfall nicht erst komplex nachdenken muss, sondern robust und vorhersehbar bleibt.

Ein praktischer Merksatz dazu lautet: Wenn die Topologie viele Wege bietet, aber der Verkehr weiterhin wie ein Einzelzug auf einem Gleis fährt, bleibt die Staugefahr hoch. Erst Multipath im Transport nutzt die Redundanz wirklich aus.

Multi-Plane-Topologie für Redundanz mit weniger Ebenen

Der Architekturkniff beginnt auf der Hardware-Seite: Eine 800-Gb/s-Netzwerkschnittstelle wird nicht als ein fetter Link behandelt, sondern in mehrere kleinere Links aufgespalten. Beispielhaft wird aus 800 Gb/s ein Bündel aus acht mal 100 Gb/s, die zu unterschiedlichen Switches führen können.

Damit lassen sich mehrere parallele Netzebenen bauen, oft als Planes bezeichnet. Der Effekt ist handfest: Mit niedrigerer Linkrate pro Lane steigt die Portdichte pro Switch-ASIC, und große Fabrics lassen sich mit weniger Switching-Ebenen aufspannen. OpenAI nennt als Größenordnung, dass sich so Cluster jenseits von 100.000 GPUs mit nur zwei Switch-Tiers aufbauen lassen, anstatt drei oder vier Ebenen zu benötigen.

Wichtig ist die Kehrseite: Mehr Pfade helfen nur, wenn das Transportprotokoll diese Pfade auch gleichzeitig nutzen darf. Genau hier scheitert klassisches Single-Path-Verhalten, weil es Reihenfolge garantiert, aber Lastverteilung verschenkt.

Packet-Spraying und Trimming gegen Hotspots

MRC behandelt eine Übertragung nicht als Strom, der durch ein Rohr fließt, sondern als viele kleine Pakete, die gleichzeitig über unterschiedliche Straßen geschickt werden. Diese Pakete dürfen außer Reihenfolge eintreffen, weil sie so markiert sind, dass der Empfänger sie direkt an der richtigen Speicheradresse ablegen kann.

Was das in der Praxis löst

• Weniger Kollisionen: Wenn viele GPUs gleichzeitig kommunizieren, prallen Flows sonst häufig auf denselben Links zusammen. Spraying verteilt die Last breit.

• Schnelles Umsteuern: Erkennt MRC Verlust oder anhaltenden Stau auf einem Pfad, wird dieser Pfad gemieden und durch Alternativen ersetzt, inklusive schneller Neuübertragung fehlender Pakete.

• Trimming: Statt Pakete bei Stau einfach zu verwerfen, kann ein Switch den Payload entfernen und nur den Header weiterreichen. Das triggert eine gezielte Nachlieferung und verhindert Fehlinterpretationen, bei denen Verlust fälschlich wie ein Leitungsdefekt aussieht.

Das Ziel ist nicht maximaler Durchschnittsdurchsatz, sondern minimale Ausreißer. Für synchrones Training zählt die langsamste Ecke im Schritt, nicht der Mittelwert.

SRv6 Source-Routing statt dynamischem Routing

Viele Rechenzentrumsnetze verlassen sich auf dynamische Routing-Protokolle, die bei Ausfällen neue Wege berechnen. Das ist grundsätzlich sinnvoll, bringt in sehr großen Fabrics aber eine zweite, komplexe Adaptionsschicht ins Spiel, die selbst Fehlerbilder erzeugen kann.

MRC kombiniert Multipath-Transport mit SRv6, also Segment Routing über IPv6. Vereinfacht gesagt kodiert der Sender den gewünschten Weg in Form einer Segmentliste, die von den Switches abgearbeitet wird. Der Rahmen dazu steht in der Segment-Routing-Architektur RFC 8402, die Programmierung von SRv6 ist in RFC 8986 beschrieben.

Der Kontrast zu klassischem dynamischem Routing lässt sich so lesen: Statt dass das Netz ständig seinen Zustand aushandelt, arbeitet das Fabric mit statischen Tabellen, und MRC entscheidet am Rand, welche Pfade noch gesund sind. BGP wird häufig als Beispiel für dynamisches Routing genannt, die Spezifikation ist in RFC 4271 dokumentiert.

Praxisbeispiel und klare Entscheidungsregel

OpenAI beschreibt den Betrieb in Trainingsnetzen mit Millionen Links, in denen ständig einzelne Verbindungen flattern. Der entscheidende Unterschied ist die betriebliche Konsequenz: Wartung und sogar Switch-Neustarts sollen häufiger möglich sein, ohne Trainingsläufe eng zu koordinieren, weil MRC betroffene Pfade sofort aus der Nutzung nimmt und später wieder einbindet.

Konkretes Praxisbeispiel

Ein synchroner Pretraining-Job läuft über viele Racks. Fällt an einer GPU-NIC eine von acht 100-Gb/s-Lanes aus, sinkt die theoretische NIC-Kapazität um ein Achtel. In einem klassischen Setup kann so ein Ereignis einen Job abbrechen oder durch Routing-Rekonvergenz sichtbar bremsen. In der MRC-Logik bleibt der Job typischerweise am Leben, nutzt die verbleibenden Planes weiter und kehrt nach Link-Erholung wieder näher an die Ausgangsleistung zurück.

Klare Entscheidungsregel

• Einsetzen, wenn Training synchron ist, sehr viele GPUs beteiligt sind und Ausreißer-Latenzen den Durchsatz dominieren.

• Priorisieren, wenn Wartungsfenster teuer sind und das Ziel lautet, Reparaturen im laufenden Betrieb zu überstehen.

• Vereinfachen, wenn die Control-Plane selbst zum Störfaktor wird, dann lohnt ein SRv6-basierter, deterministischer Ansatz besonders.

Markteinordnung als Mini-Modell

Die Entwicklung zeigt eine Verschiebung im Wettbewerb zwischen Hochleistungs-Fabrics: Nicht nur der Switch-ASIC zählt, sondern die Kopplung aus Topologie, Transport und Steuerung. Ethernet wird damit nicht automatisch zur besseren Wahl, aber es kann sich in sehr großen KI-Umgebungen wie eine spezialisierte Fabric verhalten, wenn Transportprotokoll und Routing-Strategie das Multipath-Potenzial wirklich ausnutzen.

Für die Einordnung helfen zwei Links als Kontext: der Standardisierungsrahmen von OCP und die Technikbasis von Ultra Ethernet Consortium. Für Deployments in Cloud-Umgebungen ist außerdem relevant, dass OpenAI unter anderem Standorte mit Oracle Cloud Infrastructure nennt.