Multipath Reliable Connection: Das unsichtbare Protokoll, das die Internet-Architektur zwingt, erwachsen zu werden

Während die Welt über Modellgrößen, Benchmark-Scores und die nächste ChatGPT-Version debattiert, hat OpenAI zusammen mit AMD, Broadcom, Intel, Microsoft und NVIDIA still und leise etwas getan, das langfristig wichtiger sein könnte als jedes einzelne Sprachmodell: Sie haben ein neues Netzwerkprotokoll gebaut. Multipath Reliable Connection – MRC – ist nicht weniger als der Beweis, dass das Internet, wie wir es kennen, für die Ära synchronisierter KI-Supercomputer nicht gemacht ist. ^[1]

Das klingt abstrakt. Ist es auch. Und genau deshalb übersehen es fast alle.

Das Problem, das niemand sieht

Um zu verstehen, warum MRC existieren muss, muss man verstehen, wie KI-Training funktioniert – und warum es das genaue Gegenteil dessen ist, wofür das Internet gebaut wurde.

TCP/IP, das Rückgrat des Internets seit den 1970er Jahren, wurde für statistische Multiplexierung entworfen. Viele unabhängige Gespräche teilen sich dieselben Leitungen, und das funktioniert, weil die meisten Verbindungen die meiste Zeit nicht auf voller Kapazität laufen. Wenn jemand eine E-Mail schickt, während ein anderer eine Webseite lädt, gleichen sich die Lastspitzen statistisch aus. Das war jahrzehntelang eine brillante Lösung.

KI-Training zerstört diese Annahme. Wenn Tausende GPUs ein Frontier-Modell trainieren, müssen sie sich nach jedem Rechenschritt synchronisieren. Jede GPU wartet auf jede andere GPU. Die Kommunikation ist nicht Beiwerk – sie ist Teil der Berechnung. ^[2] Mark Handley, Professor am University College London und Mitglied des Core Networking Teams bei OpenAI, beschreibt es im OpenAI-Podcast so: Das ist der „worst possible workload" für ein Netzwerk. Statt statistischer Glättung bekommt man perfekt korrelierte Last. Alle reden gleichzeitig, alle wollen gleichzeitig Antworten, und die langsamste Verbindung bestimmt die Geschwindigkeit des gesamten Systems. ^[3]

Das Ergebnis ist der sogenannte Straggler-Effekt: Eine einzige überlastete Leitung, ein einziger defekter Laser, ein einzelnes verworfenes Paket – und tausende GPUs warten. Bei Maschinen, die Millionen Dollar pro Stunde kosten, ist jede Millisekunde verschwendete Zeit bares Geld.

Warum TCP und InfiniBand an ihre Grenzen stoßen

Die klassischen Antworten auf Netzwerkprobleme in Rechenzentren waren bisher zwei: TCP optimieren oder InfiniBand nutzen. Beide stoßen bei der aktuellen Skalierung an fundamentale Grenzen.

TCP reagiert auf Überlastung, indem es die Senderate drosselt. Das funktioniert für Webverkehr, aber bei synchronisierten Workloads ist Drosselung Gift. Wenn eine GPU langsamer sendet, warten alle anderen länger. ECMP (Equal-Cost Multi-Path Routing), die Standardmethode zur Lastverteilung in Ethernet-Netzwerken, verteilt Datenströme auf verschiedene Pfade – aber auf der Ebene ganzer Verbindungen, nicht einzelner Pakete. ^[4] Das führt unweigerlich zu Hot Spots, weil große Datenströme sich auf einzelnen Pfaden stauen.

InfiniBand, die proprietäre Alternative, war jahrelang das Protokoll der Wahl für Supercomputer. Es bietet RDMA (Remote Direct Memory Access) – direkten Speicherzugriff zwischen GPUs, ohne den Umweg über den Prozessor. Aber InfiniBand hat einen strategischen Nachteil: Es ist ein geschlossenes Ökosystem, weitgehend kontrolliert von einem einzigen Hersteller. Und es skaliert schlecht über die Grenzen eines einzelnen Racks oder Clusters hinaus. ^[5]

OpenAI brauchte etwas, das die Vorteile beider Welten vereint: die offene Ökosystem-Stärke von Ethernet mit der Leistungsfähigkeit, die bisher nur InfiniBand bieten konnte. Und es musste für Cluster mit mehr als 100.000 GPUs funktionieren.

Wie MRC das Netzwerk neu denkt

MRC löst das Problem auf drei Ebenen gleichzeitig, und jede davon bricht mit Grundannahmen des traditionellen Netzwerkdesigns.

Erstens: Packet Spraying statt Flow-basiertem Routing. Statt einen Datenstrom einem einzelnen Pfad zuzuweisen, verteilt MRC jedes einzelne Paket über Hunderte verschiedener Pfade gleichzeitig. Das klingt chaotisch, ist aber mathematisch elegant: Wenn die Last über alle verfügbaren Pfade gesprüht wird, gibt es keine Hot Spots mehr. Die Bandbreitenauslastung nähert sich dem theoretischen Maximum. ^[1]

Zweitens: Packet Trimming statt Packet Drop. Herkömmliche Netzwerke verwerfen bei Überlastung komplette Pakete. Der Sender weiß dann nicht, ob das Paket verloren ging oder nur verzögert ist – und wartet. MRC schneidet bei Überlastung nur die Nutzlast ab und schickt den Header weiter. Der Empfänger weiß sofort: Dieses Paket muss neu gesendet werden. Die Unsicherheit verschwindet, die Reaktionszeit sinkt von Millisekunden auf Mikrosekunden. ^[3]

Drittens: Intelligenz am Rand, Einfachheit im Kern. MRC verlagert die Routing-Intelligenz komplett in die Endpunkte – die Netzwerkkarten der GPUs – und vereinfacht die Switches im Netzwerkkern radikal. Die Switches booten mit einer statischen Konfiguration und ändern sie nie wieder. Keine BGP-Konvergenz, die Sekunden dauern kann. Keine Routing-Tabellen, die sich ständig aktualisieren. Stattdessen nutzt MRC SRv6-basiertes Source Routing: Jeder Endpunkt bestimmt selbst, über welche Pfade seine Pakete laufen, und erkennt innerhalb von Millisekunden, wenn ein Pfad ausfällt. ^[6]

In Produktion: Nicht Theorie, sondern Realität

MRC ist kein Forschungspaper. Es läuft bereits auf allen großen OpenAI-Supercomputern – darunter der Oracle-Cloud-Infrastruktur-Cluster in Abilene, Texas, und Microsofts Fairwater-Supercomputer. ^[1] Greg Steinreer, verantwortlich für Workload Systems bei OpenAI, berichtet von einem bezeichnenden Erlebnis während der Inbetriebnahme: Während Techniker noch am physischen Aufbau des Clusters arbeiteten, fielen ständig Links aus – Kabel wurden gezogen, Laser getauscht, ganze Rack-Einheiten vom Netz genommen. Das Training lief trotzdem stabil durch. ^[3]

Das ist der eigentliche Durchbruch. Nicht die Theorie hinter MRC, sondern die Tatsache, dass ein Netzwerk mit Millionen optischer Verbindungen sich selbst heilt, während Handwerker buchstäblich Kabel herausziehen. In herkömmlichen Netzwerken hätte das den gesamten Trainingslauf zerstört.

Die Zahlen unterstreichen die Dimension: Pro GPU gibt es eine Größenordnung mehr Laser und Netzwerkkomponenten als GPUs selbst. Bei einem Cluster mit 100.000 GPUs sprechen wir über Millionen potenzieller Fehlerpunkte. Die Mean Time Between Failure sinkt mit der Systemgröße – verdoppelt man das System, verdoppeln sich die Ausfälle. MRC macht das beherrschbar. ^[3]

Die strategische Dimension: Ethernet gegen InfiniBand

Die Entscheidung, MRC auf Ethernet aufzubauen und als offenen Standard über das Open Compute Project (OCP) zu veröffentlichen, ist keine technische Nebensache. Es ist ein strategischer Schachzug, der die Kräfteverhältnisse in der Datacenter-Industrie verschieben könnte. ^[7]

InfiniBand dominierte bisher das High-Performance-Networking in KI-Clustern. Aber InfiniBand bedeutet Abhängigkeit von einem einzigen Ökosystem. MRC demokratisiert die Leistung: AMD, Broadcom, Intel und NVIDIA unterstützen es bereits. Die Spezifikation ist in 800-Gbit/s-Netzwerkinterfaces integriert. ^[4] NVIDIA hat MRC in seine Spectrum-X Ethernet-Plattform aufgenommen. ^[8] Broadcom liefert eigene Implementierungen. ^[9]

Was hier passiert, ist mehr als ein Protokollwechsel. Es ist der Moment, in dem Ethernet – das Arbeitspferd des Internets seit den 1980ern – die letzte Bastion von InfiniBand erobert. Und damit wird die Lieferkette für KI-Infrastruktur diverser, wettbewerbsfähiger und langfristig günstiger.

Warum das weit über KI-Training hinausgeht

Hier wird es für alle interessant, nicht nur für Datacenter-Ingenieure. Die Techniken, die MRC einführt – Packet Spraying, Packet Trimming, SRv6 Source Routing, Endpunkt-Intelligenz – sind nicht auf GPU-Cluster beschränkt. Sie lösen fundamentale Probleme jeder latenzkritischen Netzwerkkommunikation.

Cloud-Gaming, Videokonferenzen, autonomes Fahren, Echtzeit-Finanztransaktionen – überall dort, wo Millisekunden zählen und Ausfallsicherheit kritisch ist, bieten die MRC-Prinzipien Vorteile. Die Ultra Ethernet Consortium (UEC) arbeitet bereits daran, ähnliche Techniken in den Ethernet-Standard zu integrieren. ^[6] MRC baut explizit auf UEC-Arbeit auf und erweitert sie.

Die historische Parallele ist aufschlussreich: Als Google 2003 das Google File System veröffentlichte, war es eine Lösung für Googles spezifisches Problem – massive verteilte Speicherung. Innerhalb eines Jahrzehnts hatte es die gesamte Dateisystem-Architektur der Industrie verändert. MRC könnte denselben Weg nehmen. Ein Protokoll, das für die extremen Anforderungen des KI-Trainings entwickelt wurde, aber dessen Prinzipien universell anwendbar sind.

Der wahre Wettlauf findet im Kabel statt

Die öffentliche Debatte um KI-Führung dreht sich um Chips, Modelle und Trainingsdaten. Das sind die sichtbaren Waffen. Aber der Wettlauf entscheidet sich zunehmend in der unsichtbaren Schicht dazwischen: den Netzwerkprotokollen, die bestimmen, ob ein 100.000-GPU-Cluster tatsächlich als ein System funktioniert oder als teure Ansammlung isolierter Maschinen.

MRC ist der erste praktische Beweis, dass das TCP/IP-Paradigma – statistisches Multiplexing, reaktive Flusskontrolle, zentralisiertes Routing – für die Ära synchronisierter Supercomputer nicht ausreicht. Nicht, weil TCP schlecht wäre. Sondern weil es für ein fundamental anderes Problem entworfen wurde.

Die Frage ist nicht mehr, ob sich die Internet-Infrastruktur verändern wird. Die Frage ist, wer die neuen Standards setzt. OpenAI hat mit MRC den ersten Vorschlag gemacht – und mit AMD, Broadcom, Intel, Microsoft und NVIDIA genug Gewicht hinter sich, um ihn durchzusetzen. Europa, das bei Chips bereits hinterherhinkt, sollte genau hinschauen. Der nächste Engpass ist nicht der Prozessor. Es ist das Kabel.

Referenzen

1. OpenAI: Supercomputer networking to accelerate large scale AI training, Mai 2026
   https://openai.com/index/mrc-supercomputer-networking/
2. Data Center Knowledge: OpenAI Pushes New AI Networking Protocol as GPU Clusters Scale, Mai 2026
   https://www.datacenterknowledge.com/infrastructure/openai-pushes-new-ai-networking-protocol-as-gpu-clusters-scale
3. OpenAI Podcast Ep. 18: Why AI needs a new kind of supercomputer network, Mai 2026
   https://www.youtube.com/watch?v=TiW96H5HmAw
4. AMD Blog: Next Gen Networking Transport for Large Scale AI Training, Mai 2026
   https://www.amd.com/en/blogs/2026/next-gen-networking-transport-for-large-scale-ai-training.html
5. Dell'Oro Group: OpenAI's MRC Initiative Reinforces Ethernet's Expanding Role in AI Back-end Networks, Mai 2026
   https://www.delloro.com/openais-mrc-initiative-reinforces-ethernets-expanding-role-in-ai-back-end-networks/
6. 4sysops: Multipath Reliable Connection (MRC): a new, open networking protocol for AI supercomputers, Mai 2026
   https://4sysops.com/archives/multipath-reliable-connection-mrc-a-new-open-networking-protocol-for-ai-supercomputers/
7. SDxCentral: OpenAI simplifies large AI training networks with Ethernet-based protocol, Mai 2026
   https://www.sdxcentral.com/news/openai-simplifies-large-ai-training-networks-with-ethernet-based-protocol/
8. NVIDIA Blog: Spectrum-X – the Open, AI-Native Ethernet Fabric – Sets the Standard for Gigascale AI, Now With MRC, Mai 2026
   https://blogs.nvidia.com/blog/spectrum-x-ethernet-mrc/
9. Broadcom Blog: Enabling AI Networking @ Scale with Multi-path Reliable Connections (MRC), Mai 2026
   https://www.broadcom.com/blog/enabling-ai-networking-scale-with-multi-path-reliable-connections-mrc