Routing-Komplexität in KI-Netzwerken: ECMP, Adaptive Routing, DCQCN – und warum HPC-Profis davon besessen sind

Frühere Artikel haben Kabel, NICs, Switches und Topologien behandelt. In diesem geht es um die Ebene darüber: wie Pakete ihren Weg durch eine Fabric aus mehreren Switches finden und was verhindert, dass die Fabric zusammenbricht, wenn zehntausend GPUs im selben Augenblick ein All-Reduce starten.

KI-Verkehr sieht grundlegend anders aus als der eines normalen Rechenzentrums. Ein Web-Frontend erzeugt Millionen kleiner TCP-Verbindungen. Ein KI-Trainingslauf schickt wenige riesige, perfekt synchronisierte Flows an bekannte Gegenstellen — und alle warten auf den langsamsten. Die Techniken, die im ersten Fall funktionieren, versagen im zweiten.

Vorab eine Einschränkung: Die meisten Kentino-Kunden betreiben Cluster mit einem bis vier Nodes. In dieser Größenordnung tritt keines dieser Probleme wirklich auf. Verkabeln Sie vier Nodes mit einem einzigen 100-GbE-Switch (oder ganz ohne Switch — siehe N05), fahren Sie RoCE mit den Standardwerten und denken Sie nie über ECMP oder DCQCN nach. Wir schreiben diesen Artikel trotzdem, weil er (a) nützlicher Hintergrund für Dimensionierungsentscheidungen ist und (b) an dem Tag, an dem aus vier Nodes sechzehn werden, plötzlich alles davon zählt.

Was ECMP ist und warum es bis zur KI ausgereicht hat

ECMP — Equal-Cost Multi-Path — ist der Routing-Kniff, der Leaf-Spine- und Fat-Tree-Fabrics überhaupt erst funktionieren lässt. Gibt es mehrere gleich teure Pfade von Leaf A zu Leaf B (über die Spines S1..S4), hasht der Switch Paketfelder und wählt anhand des Hashes einen Spine. Der klassische 5-Tupel-Hash lautet (src IP, dst IP, src port, dst port, protocol).

Bei klassischen Cloud-Workloads — Millionen kurzlebiger TCP-Verbindungen — funktioniert ECMP hervorragend. Das Gesetz der großen Zahlen übernimmt das Load-Balancing. Mit 10,000 Flows und 8 Spines kommen Sie bis auf wenige Prozent an die perfekte Balance heran.

ECMP wurde für viele kleine Flows entworfen. KI-Training schickt wenige riesige, synchronisierte Flows — die statistische Balance bricht zusammen.

Das Elefanten-Flow-Problem

KI-Training ist das Gegenteil von Web-Verkehr. Ein Trainingsschritt: Jede GPU berechnet einen Gradienten, jede GPU schickt ihren Gradienten an alle anderen (All-Reduce), alle warten auf die langsamste Übertragung, und das Ganze wiederholt sich.

All-Reduce besteht aus wenigen, sehr großen Flows. Ring-All-Reduce auf 8 Nodes mit 200-Gbps-NICs bedeutet 8 gleichzeitige Flows, jeder mehrere Gigabyte groß, alle mit Leitungsgeschwindigkeit, alle im selben Augenblick gestartet. Metas Paper zu RoCE im großen Maßstab hat es klar dokumentiert: In KI-Clustern entfällt fast der gesamte Datenverkehr auf eine winzige Zahl von „Elefanten“-Flows — und die wollen alle gleichzeitig ins Netz.

Der 5-Tupel-Hash von ECMP hasst das. Bei N Elefanten-Flows über S Pfade beträgt die Wahrscheinlichkeit einer kollisionsfreien Verteilung S! / ((S-N)! · S^N). Bei 8 Flows auf 8 Spines: etwa 2.4%. Selbst 32 Spines für 8 Flows erreichen nur ~33%. Mehr Spines ändern am Münzwurf nichts — sie liefern nur mehr leere Links, während sich zwei Flows um einen streiten.

Eine Kollision überbucht den Spine-Link 2:1, die betroffenen Flows laufen mit halber Geschwindigkeit, und weil der Schritt auf den langsamsten Flow wartet, läuft die gesamte Iteration mit halber Geschwindigkeit. Messungen in Produktionsclustern berichten von ECMP-Kollisionen mit bis zu 40% Leistungsverlust beim All-Reduce.

Abhilfen: verbessertes Hashing, paketweises Load-Balancing, adaptives Routing

Vier praxistaugliche Antworten, nach steigendem Umstellungsaufwand:

1. Besseres Hashing (E-ECMP, QP-bewusst). Die günstigste Lösung. Standard-5-Tupel-Hashing legt RDMA-Verkehr auf genau ein Tupel pro QP-Paar zusammen — ein einzelner All-Reduce-Flow ist damit tatsächlich nur ein einziger ECMP-Bucket. Hashen Sie zusätzlich über die RoCE-Ziel-QP-Nummer und lassen Sie die Anwendung den Verkehr über viele QPs verteilen („QP-Scaling“). Metas Zahlen: bis zu 40% besseres All-Reduce. Weiterhin statistisch — Kollisionen werden seltener, nicht ausgeschlossen.

2. Flowlet-Switching. Eine Übertragungspause erkennen und ab dort neu hashen. Funktioniert bei TCP, schlecht bei lückenlosem RoCE.

3. Paketweises Load-Balancing / Packet Spraying. Pro Paket hashen, Umsortierung in Kauf nehmen, die NIC setzt wieder zusammen. Das beseitigt das Elefanten-Flow-Problem, verlangt aber, dass NIC und Switch zusammenspielen. Genau das macht NVIDIA Spectrum-X — Spraying pro Paket mit hardwareseitigem Reordering in der SuperNIC.

4. Adaptives Routing. Der Switch verfolgt die Auslastung pro Port und wählt zum Switching-Zeitpunkt den am wenigsten belasteten gleichwertigen Pfad, statt blind zu hashen. Kombiniert mit Packet Spraying ist das genau das, was InfiniBand seit fünfzehn Jahren beherrscht. Es auf Ethernet zu bringen, ist das Kernmerkmal von NVIDIA Spectrum-X (Spectrum-4/5-ASICs + BlueField- oder ConnectX-8-SuperNICs); Cisco Silicon One G200/P200; sowie Broadcom Tomahawk 5 / Jericho 3-AI mit zellbasierter, geplanter Fabric.

Für Cluster mit 1–8 Nodes ist adaptives Routing überdimensioniert. Bei Jobs mit 64+ GPUs, die auf 1,000 GPUs skalieren, macht es den Unterschied zwischen „das Netzwerk ist der Flaschenhals“ und „die GPUs sind der Flaschenhals“. Deshalb hat jeder ernstzunehmende Anbieter von KI-Ethernet zwischen 2024 und 2026 Silizium für adaptives Routing entwickelt oder lizenziert.

Congestion Control: warum „einfach keine Pakete verwerfen“ nicht umsonst ist

Die andere Hälfte der Routing-Komplexität ist das, was passiert, wenn zu viel Verkehr gleichzeitig an einem Switch-Port ankommt. Zwei Möglichkeiten: Ein verlustbehaftetes Netz verwirft Pakete, und die Endpunkte drosseln (das offene Internet); ein verlustfreies Netz bremst den vorgelagerten Switch aus — keine Verluste, aber die Überlastung wandert rückwärts.

RoCE hat bislang eine verlustfreie Fabric vorausgesetzt. RDMA-NICs gehen schlecht mit Paketverlust um — ein einziges verworfenes Paket löst einen Go-back-N-Retransmit der gesamten Nachricht aus, was bei 100 GbE bedeutet, Megabyte erneut zu senden. RoCEv2 mit Go-back-N ist in einem verlustbehafteten Netz bei hoher Auslastung praktisch unbrauchbar.

PFC — Priority Flow Control (IEEE 802.1Qbb) sorgt dafür, dass sich Ethernet verlustfrei verhält. Überschreitet die Egress-Queue einer Priorität am Switch einen Schwellwert, sendet er einen PAUSE-Frame stromaufwärts und bittet den Sender, diese Priorität nicht weiter zu senden. Acht Prioritäten, acht unabhängige Stop-and-go-Signale.

Head-of-Line-Blocking und Opfer-Flows

PFC-Pausen sind grob. Eine Pause sagt „schick keine Priorität 3 mehr über diesen Link“ — sie weiß nicht, welcher Flow die Überlastung verursacht hat. Teilen sich zehn Flows die Priorität 3 und ist einer davon stromabwärts überlastet, pausiert PFC alle zehn. Die anderen neun „Opfer-Flows“ werden für ein fremdes Problem bestraft. Das ist Head-of-Line-Blocking, der zentrale Schmerzpunkt von verlustfreiem Ethernet im großen Maßstab.

Head-of-Line-Blocking: A→X löst PFC auf dem Trunk aus. B und C, die mit Y sprechen (dem es gut geht), werden ebenfalls pausiert — Opfer-Flows.

PFC-Deadlock: Bilden Topologie und Verkehr eine zyklische Abhängigkeit pausierter Links — A wartet auf B, B auf C, C auf A —, blockiert die gesamte Fabric. In der Produktion beobachtet. Moderne Switches erkennen Deadlocks, moderne Clos-Topologien sind konstruktionsbedingt deadlock-frei — trotzdem hat jede ernsthafte RoCE-Installation einen Wiederherstellungsplan.

Der Sinn moderner KI-Congestion-Control besteht darin, die Puffer so klein zu halten, dass PFC im Normalbetrieb nie auslöst. PFC bleibt als Sicherheitsnetz für echte Mikrobursts scharfgeschaltet. Der Mechanismus, der es vom Auslösen abhält, heißt DCQCN.

DCQCN — die Standard-Congestion-Control für RoCEv2

DCQCN (DataCenter Quantized Congestion Notification) ist der Algorithmus, auf den sich verlustfreies RoCE geeinigt hat. Entwickelt von Microsoft und Mellanox (SIGCOMM 2015). Stand 2025–2026 läuft er auf NVIDIAs ConnectX-/BlueField-NICs standardmäßig, und Azure meldet ihn als Produktionsstandard für „~85% des Azure-Verkehrs, RDMA, in allen öffentlichen Regionen“.

DCQCN kennt drei Rollen: Der CP (Congestion Point) ist der Switch; er markiert Pakete mit ECN, sobald die Egress-Queue-Tiefe einen Schwellwert überschreitet (probabilistisch von 0% bei Kmin bis Pmax bei Kmax). Der NP (Notification Point) ist die Empfänger-NIC; sie erzeugt bei ECN-Markierungen ein CNP (Congestion Notification Packet) zurück an den Sender (ratenbegrenzt, typischerweise eines je 50 µs und Flow). Der RP (Reaction Point) ist die Sender-NIC; sie senkt die Rate der QP bei einem CNP multiplikativ und erhöht sie in deren Abwesenheit additiv (und anschließend hyperadditiv).

Typische Switch-Konfiguration für DCQCN bei 100 GbE:

# ECN-Profil im NVIDIA-Cumulus-Stil auf der verlustfreien RoCE-Priorität (Priorität 3)
interface swp1..swp32
  qos remark dscp-to-tc 26 to 3       # DSCP 26 → TC 3
  qos congestion-mark ecn priority 3
  qos ecn-kmin       5KB              # Markierung beginnt
  qos ecn-kmax     200KB              # Markierung bei Pmax
  qos ecn-pmax       1%
  qos pfc priority 3
  qos pfc xoff     400KB              # PFC-Pause (deutlich über Kmax)
  qos pfc xon      300KB

Kmin/Kmax/Pmax ist das meistgetunte Wertetripel in RoCE. Kmin klein (wenige Pakete), damit ECN greift, bevor der Puffer volläuft; Kmax deutlich größer, damit die Markierung allmählich ansteigt; die PFC-Pausenschwelle weit über Kmax, damit PFC nur auslöst, wenn DCQCN zu langsam war. Microsofts ursprüngliche Installation: Kmin = 5 KB, Kmax = 200 KB, Pmax = 1%.

Die bekannten Schwächen von DCQCN: Incast-Kollaps (100 Sender treffen auf einen Empfänger, die Queue füllt sich schneller, als CNPs zurücklaufen, PFC löst aus — DCQCN+ adressiert das); Long-Tail-Unfairness (später gestartete Flows werden länger gedrosselt); Parameterempfindlichkeit (ein für 4 Nodes abgestimmtes Kmin lässt sich nicht auf 64 übertragen). Ehrliches Fazit: DCQCN ist der Standard, weil es meistens funktioniert. HPCC, Swift, EQDS und ein wiederbelebtes TIMELY existieren als Nachfolgevorschläge, doch keiner hat es bis 2026 verdrängt.

ECN, DCTCP und wo reines TCP hineinpasst

Eine saubere Abgrenzung, weil diese Begriffe gern vermischt werden:

• ECN — Mechanismus auf IP-Ebene (RFC 3168), bei dem Switches markieren statt zu verwerfen. Ein Signal, von sich aus reagiert darauf nichts.
• DCQCN — die Reaktion des RDMA-Endpunkts. Liest ECN über CNPs und passt die Rate an.
• DCTCP — die Reaktion des TCP-Endpunkts. Liest ECN in den ACKs und skaliert das Fenster anhand des Anteils markierter Pakete. Microsoft + Stanford, SIGCOMM 2010, ausgeliefert in Windows Server und Linux.

Wenn Sie eine reine RoCE-Fabric betreiben, betreiben Sie DCQCN — kennen Sie Ihre Standardwerte. Läuft auf derselben Leitung auch TCP für Storage und Steuerung, lohnt es sich, DCTCP zu aktivieren (net.ipv4.tcp_ecn = 1 zusammen mit ECN-fähigen Switches).

Warum KI-Verkehr all das stärker belastet als ein klassisches Rechenzentrum

Drei Eigenschaften, für die klassische Congestion Control nicht entworfen wurde:

1. Synchronisierte Bursts. Alle GPUs starten das All-Reduce in derselben Nanosekunde. Von null auf 100% Auslastung in Mikrosekunden. Kein Anlauf, in dem Slow-Start die passende Rate finden könnte. Genau deshalb startet DCQCN mit Leitungsgeschwindigkeit.
2. Wenige, große Flows. Das Gesetz der großen Zahlen rettet Sie nicht. 8 Flows → häufige ECMP-Kollisionen; 8 Empfänger → massives PFC-HoL-Blocking.
3. Der kritische Pfad ist der langsamste Link. All-Reduce-Schrittzeit = maximale Flow-Abschlusszeit. Es gibt keinen „Durchschnittsfall“. Eine Wahrscheinlichkeit von 1% für eine ungünstige Kollision summiert sich über Monate des Trainings.

Deshalb sind HPC- und KI-Leute so besessen von Netzwerken, wie es Betreiber im Web-Maßstab historisch nie waren. Das Web ist elastisch — langsame Anfragen dauern für einige Nutzer etwas länger. KI-Training ist das nicht: Der gesamte Job läuft mit der Geschwindigkeit seiner langsamsten synchronisierten Komponente.

Die Komplexität ohne Switch (Vorschau auf N05)

N05 behandelt switchlose Topologien — Direct-Connect, Mesh, Ring, 2D-/3D-Torus, Tesserakt — für kleine Cluster, bei denen ein 100-GbE-Switch überdimensioniert wäre. Nimmt man den Switch heraus, wird jeder Node zum Router: mehrere NICs, mehrere Pfade, und irgendetwas muss den nächsten Hop wählen.

Die Standardantwort lautet 2026 FRR (FRRouting) auf jedem Node, konfiguriert für BGP unnumbered. BGP unnumbered nutzt IPv6-Link-Local-Adressen für das Peering, sodass Sie nicht jedem Link eine IPv4-Adresse zuweisen müssen. Jeder Node kündigt sein Loopback an, lernt die Loopbacks der Nachbarn, und die Linux-Routing-Tabelle wählt den richtigen nächsten Hop.

# Minimale FRR-Konfiguration für einen Node in einem switchlosen Mesh:
router bgp 65001
  bgp router-id 10.0.0.1
  neighbor enp1s0 interface remote-as external
  neighbor enp2s0 interface remote-as external
  neighbor enp3s0 interface remote-as external
  address-family ipv4 unicast
    network 10.0.0.1/32         # Loopback dieses Nodes
    redistribute connected
  exit-address-family

Zwölf Zeilen pro Node, ECMP über so viele NIC-Paare, wie der Node besitzt — mit denselben Vorbehalten wie beim Switch-ECMP. In einem 4-Node-Mesh treten ECMP-Kollisionen auch auf der Host-Seite auf. Abhilfe: mehr QPs — oder den Verlust hinnehmen (bei 4 Nodes ist er klein). „Kein Switch“ heißt nicht „keine Routing-Komplexität“ — sie verlagert sich nur auf die Hosts.

Wann das für Sie relevant wird

Die meisten Leser werden nichts davon tun müssen.

• 1–4 Nodes, ein Switch, RoCE für Storage und gelegentliches Multi-GPU-Training: Lassen Sie den Switch auf den Standardwerten. Die vorkonfigurierten DCQCN- und ECN-Schwellen sind in Ordnung. PFC ist aktiviert, und Sie werden es vermutlich nie pausieren sehen. ECMP-Kollisionen sind real, aber ihr Einfluss auf einen 4-Node-Lauf liegt im einstelligen Prozentbereich.
• 4–16 Nodes, dediziertes Trainingscluster: Aktivieren Sie DCQCN explizit, setzen Sie Kmin/Kmax/Pmax auf 5 KB / 200 KB / 1% (Azure-Basiswerte), schalten Sie QP-Scaling in NCCL ein und überwachen Sie PFC-Pausenzähler und CNP-Raten. Steigen die PFC-Pausen, ist DCQCN nicht aggressiv genug — senken Sie Kmin.
• 16+ Nodes oder 1,000+ GPUs: Adaptives Routing rechnet sich. Kaufen Sie Spectrum-X mit passenden SuperNICs oder InfiniBand und vergessen Sie ECMP — oder arbeiten Sie mit jemandem zusammen, der eine Fabric dieser Größe bereits betrieben hat. Ein Fehlgriff kostet Monate an Trainingszeit.
• Switchloses Cluster, beliebige Größe: FRR + BGP unnumbered. 1–2 Tage Konfiguration und Tests pro Verdopplung der Node-Zahl. Die große Stolperfalle ist das vergessene ECMP auf Kernel-Seite (net.ipv4.fib_multipath_hash_policy = 1 für L4-Hashing).

Der Reflex „Ich kaufe einfach mehr Bandbreite, dann gibt es keine Überlastung“ ist falsch. Synchronisierter KI-Verkehr erzeugt auf jedem Pfad augenblicklich Nachfrage mit Leitungsgeschwindigkeit, egal wie viele Spines Sie haben. Bandbreite löst Ratenprobleme, keine Koordinationsprobleme.

---

Dies ist Teil des Kentino Wiki, einer Referenzreihe über KI-Compute, Robotik und die Systeme, die beides verbinden. Kommentare und Korrekturen willkommen unter info@kentino.com.