CoreWeave teilt fünf Netzwerk-Erkenntnisse aus dem Aufbau einer Fabric für agentische KI

Warum agentischer Traffic anders ist als Training

Das Training eines Foundation-Modells beschreibt CoreWeave als für das Netzwerk gut beherrschbares Problem: Tausende GPUs führen über Wochen hinweg ungefähr zur selben Zeit dieselbe Collective-Operation aus. Das fordert die Bandbreite stark, verläuft aber rhythmisch, sodass sich ein Netzwerk darauf auslegen lässt.

Agenten verhalten sich anders. Ein Agent zerlegt eine Aufgabe in Schritte, ruft einen Retriever, ein Tool, ein weiteres Modell und manchmal einen anderen Agenten auf und wartet an jeder Station, bevor er den nächsten Schritt kennt. Die Latenz einer solchen Kette ist die Summe aller Hops und nicht der schlechteste einzelne Wert. Tausende dieser Ketten, die neben Trainingsjobs und gewöhnlicher Inferenz laufen, machen den Traffic laut Unternehmen latenzempfindlich und hopreich.

CoreWeave sagt, man habe sein Backend-Netzwerk von der Topologie an neu aufgebaut, damit eine Flotte dauerhafte Trainings-Collectives, gleichmäßige Inferenz und stoßartigen Agenten-Traffic tragen kann, ohne dass eines der drei die anderen beeinträchtigt. Das Netzwerk nutzt die Ethernet-Plattform NVIDIA Spectrum-X, BlueField-3 DPUs und ConnectX-9 SuperNICs, kombiniert mit CoreWeave Kubernetes Service (CKS), SUNK und CoreWeave Mission Control. Die Fabric verbindet nach Angaben des Unternehmens inzwischen Flotten in mehr als 50 Rechenzentren.

Non-Blocking-Design und Multi-Plane-Skalierung

Die erste Erkenntnis lautet: nicht überbuchen. CoreWeave argumentiert, dass eine Fabric Punkt-zu-Punkt-Bandbreitentests bestehen und Agentenketten trotzdem ausbremsen kann, wenn Leaf-Switches weniger Uplink-Kapazität haben, als die darunterliegenden Knoten erzeugen können. Die Regel des Unternehmens ist ein Verhältnis von 1:1, sodass jeder Leaf auf jeder Ebene von jedem angeschlossenen Knoten die volle Leitungsgeschwindigkeit halten kann. Das sei der Grund, warum man einige der größten heute betriebenen NVIDIA-Quantum-InfiniBand- und RoCE-Fabrics betreibe.

Bei Spectrum-X sollen Adaptive Routing und telemetriebasierte Überlastkontrolle verhindern, dass der synchronisierte Trainingsburst eines Mandanten die Agentenkette eines anderen beeinträchtigt. CoreWeave gibt außerdem an, einer der ersten Cloud-Anbieter gewesen zu sein, die den NVIDIA Spectrum-X SN6600-LD eingesetzt haben, beschrieben als der erste vollständig flüssigkeitsgekühlte Ethernet-Switch der Branche mit 102,4 Tb/s, und zwar als Switching-Fabric für NVIDIA Vera Rubin NVL72.

Die zweite Erkenntnis betrifft das Wachstum. Ein flaches zweistufiges Leaf-Spine-Design stößt irgendwann an die Grenzen seiner Radix, und die übliche Lösung, eine dritte Ebene, bringt zusätzliche Hops und Jitter. Eine Multi-Plane-Topologie teilt stattdessen die SuperNIC-Anbindung jeder GPU auf zwei oder mehr unabhängige Planes auf. Laut CoreWeave erreicht so ein flaches zweistufiges Design 128.000 GPUs, das 64-Fache der Reichweite einer Single-Plane-Fabric. Multi-Rail funktioniert auf Knotenebene: Jede GPU ist über mehr als eine SuperNIC angebunden, und bei einem Rail-optimierten Design verbindet sich die N-te SuperNIC jedes Knotens mit demselben Leaf-Switch, was die Pfade zwischen GPUs kurz und vorhersehbar hält.

Hardware-Lastverteilung und mehrschichtige Ausfallsicherheit

Die dritte Erkenntnis: Bandbreite hilft nur, wenn der Traffic sie auch nutzt. Statisches Hashing kann große Flows auf einem Pfad bündeln, während andere brachliegen. Lastverteilung lief traditionell in Software, wobei NCCL den Traffic einer Collective-Operation verteilt, was um CPU-Zyklen des Hosts konkurriert und erst nachträglich auf Überlast reagiert.

CoreWeave sagt, ConnectX-9 SuperNICs verlagern diese Arbeit in die Hardware und reagieren mit Leitungsgeschwindigkeit auf Live-Telemetrie zur Überlast. Das Unternehmen kombiniert sie, bei bis zu 1.600 Gb/s pro GPU in seiner NVIDIA-Vera-Rubin-NVL72-Installation, mit Adaptive Routing in der Spectrum-X-Switch-Fabric. Zudem betont es das Tuning: Priority Flow Control und Explicit Congestion Notification sollten anhand realen Traffics eingestellt werden, und die Überlastschwellen müssten für NCCL-Muster separat abgestimmt werden, statt sich auf Lehrbuch-Standardwerte zu verlassen.

Die vierte Erkenntnis: Eine Agentenkette hat keine saubere Neustartgrenze. Ein stockender Trainingsjob kann von einem Checkpoint neu starten, ein Agent mitten in einer Kette aus 10 Schritten dagegen nicht. CoreWeave baut die Ausfallsicherheit daher über fünf Ebenen auf:

• Topologie: Multi-Plane und Multi-Rail verlagern Traffic weg von einer beeinträchtigten Plane oder Rail.
• Silizium: BlueField-3 DPUs übernehmen Netzwerk, Isolation und Richtlinienumsetzung auf dedizierter Hardware statt auf Host-CPUs.
• Software: CKS verzichtet vollständig auf den Hypervisor.
• Betrieb: Mission Control ersetzt beeinträchtigte Knoten automatisch, sobald sie einen Gesundheitsschwellenwert überschreiten, unterstützt von einem FleetOps-Team, das rund um die Uhr überwacht.
• Geografie: das Netzwerk-Backbone, wobei der Ausgangstext vor der Beschreibung abbricht.

Was das für Kunden von KI-Infrastruktur bedeutet

Der Beitrag stellt CoreWeaves eigene Designentscheidungen dar und enthält weder unabhängige Benchmarks noch Leistungsvergleiche. Seine Botschaft an Kunden mit gemischten Workloads lautet, Agenten-Traffic als vollwertige Anforderung an das Netzwerkdesign zu behandeln und nicht als nachrangiges Thema neben dem Training. Das Unternehmen sagt, die Vera-Rubin-NVL72-Installation gebe Kunden Zugang zu Netzwerken mit höherer Kapazität, sobald neue KI-Systeme in Betrieb gehen.