Het netwerk is een van de meest kritieke onderdelen geworden van de infrastructuur voor kunstmatige intelligentie. Jarenlang behandelden veel teams Ethernet als een algemene laag: stabiel, bekend, relatief goedkoop en flexibiel genoeg voor vrijwel elke zakelijke belasting. In een modern AI-cluster is deze visie echter ontoereikend. Wanneer duizenden GPU’s een gedistribueerd model trainen, wordt het netwerk meer dan slechts een transportsysteem; het wordt een integraal onderdeel van het compute systeem.
RoCE, RDMA over Converged Ethernet, maakt het mogelijk om RDMA over Ethernet te gebruiken voor datatransfers tussen servers, met minder CPU- en OS-interventie. Het voordeel is duidelijk: lage latentie, hoge bandbreedte en betere efficiëntie voor GPU-naar-GPU communicatie. De uitdagingen liggen ook op de loer: voor optimale werking in AI moet Ethernet bijna verliesvrij functioneren, met gecontroleerde congestie, goed ontworpen wachtrijen, afgestelde buffers en voldoende telemetrie om problemen te detecteren voordat ze het trainen beïnvloeden.
Welke problemen lost RoCE op bij AI-belastingen
Bij gedistribueerde training werken GPU’s niet geïsoleerd. Ze wisselen gradiënten uit, synchroniseren statussen, voeren collectieve operaties uit zoals AllReduce en zijn afhankelijk van een vergelijkbaar tempo tussen alle knooppunten. Als een deel van het cluster vertraging oploopt door congestie, packetverlies of variabele latentie, wordt de algehele prestatie geremd. Een dure GPU die wacht op data is verspilde capaciteit.
RDMA vermindert geheugenkopieën en voorkomt een deel van het traditionele kernel- en CPU-verkeer. In plaats van elke overdracht als conventioneel verkeer te behandelen, stelt het NIC’s in staat veel directer betrokken te zijn bij datamobiliteit tussen geheugens. RoCEv2 breidt deze logica uit over IP/Ethernet-netwerken, waardoor RDMA-semanticemogelijk worden gemaakt in Ethernet-omgevingen.
Google Cloud gebruikt RoCEv2 op A3 Ultra en A4 machines voor knooppunt-communicatie en GPU-naar-GPU-verkeer, met tot 3,2 Tbps inter-node GPU-naar-GPU verkeer op de A3 Ultra. Meta heeft ook netwerken gedocumenteerd die RoCE gebruiken voor grootschalige gedistribueerde training, inclusief clusters van 24.576 H100 GPU’s voor Llama 3, waarvan één gebaseerd op RoCE en een ander op InfiniBand. NVIDIA ontwikkelde Spectrum-X, een Ethernet-platform geoptimaliseerd voor AI met RoCE-verbindingen, congestion control, telemetrie en prestatie-isolatie.
| Netwerkoptie | Gebruikstypen | Voordelen | Uitdagingen |
|---|---|---|---|
| Traditioneel Ethernet met TCP | Algemene toepassingen, cloudverkeer, bedrijfsservices | Volwassenheid, interoperabiliteit, kosten, bekendheid in beheer | Variabele latentie, retransmissies, verlies dat opzettelijk getolereerd wordt |
| RoCEv2 over Ethernet | GPU-clusters, gedistribueerde AI, HPC op Ethernet | RDMA over IP/Ethernet, minder CPU-overhead, goede multivendor compatibiliteit | Vereist PFC, ECN, buffer tuning, QoS en fijne telemetrie |
| InfiniBand | HPC, hoge-prestatie AI-training, gesloten clusters | Zeer lage latentie, volwassen RDMA, geïntegreerde stack | Minder algemeen, afhankelijker van leverancier |
| Ultra Ethernet | Next-gen voor grootschalige AI/HPC | Verbeteringen in multipath, schaalbaarheid en ultratransport | Nog in ontwikkeling, minder bewezen dan huidige RoCE-implementaties |
Technische componenten: PFC, ECN, DCQCN en QoS
RoCE maakt Ethernet niet automatisch verliesvrij. Het netwerk moet zo ingesteld worden dat het RDMA-verkeer protected is tegen pakketverlies, vooral onder congestie. Hier komen meerdere mechanismen kijken die je als onderdeel van een systeem moet begrijpen, niet als losse switchopties.
PFC (Priority Flow Control) pauzeert een specifieke prioriteit wanneer de bijbehorende wachtrij een drempel bereikt. Het voordeel is dat het verlies in RDMA-verkeer voorkomen wordt. Het risico is dat foutieve instellingen congestie kunnen verspreiden, head-of-line blocking veroorzaken en verkeer dat niet geblokkeerd zou moeten worden, beïnvloeden. Het wordt daarom aangeraden om PFC alleen op noodzakelijke wachtrijen toe te passen, niet in de hele netwerkinfrastructuur.
ECN (Explicit Congestion Notification) markeert pakketten vóór dat ze verloren gaan. Ontvanger of eindpunt interpreteert deze markering en de zender past zijn snelheid aan. In RoCEv2 gaat ECN vaak samen met congestiecontrolealgoritmes zoals DCQCN (Data Center Quantized Congestion Notification), dat de verzendsnelheid reguleert op basis van ECN-markeringen. Het is cruciaal om vroeg te markeren, maar niet te aggressief; te vroege markeringen verspillen capaciteit, terwijl te late markeringen queues doen ontstaan en vertragingen veroorzaken.
Het scheiden van wachtrijen is eveneens essentieel. RDMA-verkeer moet een eigen klasse, wachtrijen en beleid hebben. Congestiemeldingen zoals CNP (Congestion Notification Packets) moeten snel arriveren. Vertraging hierin betekent dat de zender blijft injecteren, zelfs wanneer het netwerk al verzadigd is. Cisco adviseert in AI/ML-omgevingen om RoCEv2-verkeer te scheiden, ECN en PFC toe te passen op de juiste wachtrijen en controleverkeer prioriteit te geven.
| Onderdeel | Functie | Risico bij verkeerde configuratie |
|---|---|---|
| PFC | Voorkomt verlies door pauzeren van specifieke prioriteiten | Verspreiding van congestie, blokkades, overmatige pauzes |
| ECN | Markeert congestie vóór dat verlies optreedt | Te late marking veroorzaakt queues; te vroege markering verlaagt de prestaties |
| DCQCN | Aanpast verzendsnelheid op eindpunten | Oscillaties, onderbenutting of aanhoudende congestie |
| QoS / Wachtrijen | Scheidt RDMA, controle en opslagverkeer | Verwarring en interferentie tussen kritisch en niet-kritisch verkeer, jitter en packet drops |
| Buffers | Absorberen microbursts en incast | Packet drops, queue-latentie, onnodig geheugenverbruik door switches |
| Telemetrie | Inzicht in PFC, ECN, wachtrijen en drops | Intermitterende problemen zonder duidelijke oorzaak |
Netwerkarchitectuur: topologie, rails en isolatie
Voor AI is een standaard leaf-spine-netwerk vaak niet voldoende. Je moet het ontwerpen op basis van communicatiepatronen. Distributie, parallel inferentie, opslag, checkpoints en controverkeer worden niet hetzelfde behandeld. Het netwerk moet oversubscription vermijden op kritische datastromen en consistente paden bieden tussen GPU-knooppunten.
De meest geavanceerde configuraties gebruiken rail-gebaseerde of multi-rail design, waarbij NICs in elke server verbonden zijn met parallelle fabrics of gesegmenteerde netwerken die verkeer gelijkmatig verdelen. Google bijvoorbeeld gebruikt een 4-weg rail-aligned netwerk in A3 Ultra voor niet-blokkerende GPU-naar-GPU communicatie. In eigen datacenters moet je letten op symmetrisch bekabelingsontwerp, NIC-distributie, ECMP-hashing, aantal hops en fysieke locatie van de knooppunten.
Isolatie van het netwerk is eveneens belangrijk: een RoCE-netwerk voor GPU’s mag niet cumulerend verkeer zoals beheer, back-ups, opslag en monitoring zonder controle delen. Sommige ontwerpen scheiden fysiek, anderen volstaan met logische scheidingen en strikte wachtrijpoli. De keuze hangt af van schaal, budget, risico’s en gebruikte belasting.
| Ontwerplaag | Technische aanbeveling | Reden |
|---|---|---|
| Topologie | Symmetrisch leaf-spine of rail-aligned | Vermindert ongelijkmatige paden en verhoogt voorspelbaarheid |
| Oversubscription | Vermijd dit bij kritische GPU-GPU communicatie | GPU’s degraderen snel onder wachttijd |
| Verkeer scheiding | RDMA op eigen wachtrijen en prioriteiten | Voorkomt dat algemeen verkeer de latency en buffers beïnvloedt |
| ECMP / hashing | Controleer verkeer-distributie over RoCE-stromen | Verkeersconcentratie op bepaalde links voorkomen |
| Bekabeling | Documenteer rails, NICs, leafs en segmenten | Fysieke fouten zijn moeilijk te diagnosticeren |
| Failures | Test verlies van verbindingen en switches | Het netwerk moet voorspelbaar degraderen, niet chaotisch |
Praktijkchecklist voor implementatie van RoCE
De meest gemaakte fout is RoCE behandelen als een stel functies dat je simpelweg activeert. In werkelijkheid is het een architectuur die getest moet worden. Voordat je in productie gaat, is het verstandig een laboratorium op te zetten met dezelfde NIC’s, firmware, besturingssysteem, drivers, switches, NOS-versies, optiek en verkeerspatronen als in het echte cluster. Het verschil tussen ‘werkt in een simpele test’ en ‘houdt wekenlang training vol’ kan enorm zijn.
Een goed validatieplan omvat persistente throughput-tests, incast en microbursts, gemengde traffic, verbinding- en congestietests, routewijzigingen, firmware-updates en daadwerkelijke NCCL-belastingen. Synthetische tests zoals ib_write_bw volstaan niet; het is cruciaal om de workload in een echte applicatie of een gelijkwaardig patroon te testen.
Daarnaast moet het operationeel beheer duidelijk gedefinieerd worden: wie mag ECN-drempels aanpassen, welke firmwareversies worden als goedgekeurd beschouwd, hoe PFC-gebeurtenissen gemonitord worden, welke alerts afgaan bij drops, hoe een vertraging in training toewijsbaar is aan het netwerk, en hoe GPU-, NCCL- en switch-metrics gekoppeld worden. Zonder dit raamwerk ontstaan er snel conflicten tussen netwerkteams, systeembeheerders en AI-specialisten.
| Fase | Minimale validatie | Verwacht resultaat |
|---|---|---|
| Laboratorium | NIC, switch, firmware en NOS gelijk aan productie | Reproduceerbare configuratie |
| Baseline | Throughput, latency, PFC, ECN, packet drops en wachtrijen zonder echte load | Stabiel referentiepunt |
| Synthetische belasting | RDMA, incast, microbursts en gemengde traffic | Voorspelbare congestie-uren |
| AI-belasting | NCCL, AllReduce, gedistribueerde training | Impact op GPU-prestaties meten |
| Fail-scenario’s | Verlies van verbinding, switch-reboots, routewijzigingen | Geleidelijke en controleerbare degradatie |
| Beheer | Alerting, dashboards, handleidingen, verantwoordelijken | Snel diagnoseerbare operaties |
Welke metrics monitor je het beste?
Een RoCE-netwerk kan er op traditionele metrics gezond uitzien, terwijl de training toch degradeert. Link-utilisatie is niet voldoende. Het is essentieel om wachtrijen, pausingen, ECN-markeringen en endpoints gedrag te volgen.
Belangrijke metrics omvatten PFC-events per poort en prioriteit, wachttijd, ECN-markeringen, CNP-verkeer, packet drops, bufferoccupancy, queue-latentie, retransmissies, rail-utilisatie, ECMP-distributie, fysieke fouten, CRC’s, optieken temperatuur en NCCL-prestaties. Op GPU-niveau is het waardevol om de GPU-utilisatie, kolomcommunicatietijd en trainingstijd te correlateren.
NVIDIA stimuleert deze aanpak met Spectrum-X en hun telemetriemodule voor AI-factories, waarbij de netwerkprestaties beschouwd worden als integraal onderdeel van de clusterperformance. Het idee is dat AI-teams onmiddellijk zien wanneer verlies van efficiëntie uit de netwerkomgeving komt, terwijl netwerkbeheerders de impact van wachtrijen op specifieke loads kunnen monitoren.
Veelvoorkomende fouten bij RoCE-implementaties
De eerste fout is PFC te activeren op te veel prioriteiten, waardoor lokale bescherming zich voordoet als een wereldprobleem. De tweede is ECN-waarden kopiëren zonder de configuratie aan te passen aan switch, buffer-en verkeerpatroon. De derde is RDMA-verkeer mengen met algemeen verkeer zonder adequate scheiding. De vierde is te vertrouwen op synthetische tests en niet op realistische workloads.
Ook onderschat men vaak het belang van firmware. NICs, drivers, switches en OS moeten als een geïntegreerde stack behandeld worden. Onverenigbare versies kunnen latenties, packetverlies of congestionproblemen introduceren die moeilijk te reproduceren zijn. Homogeniteit in grote clusters is dus belangrijk.
Verder wordt vaak vergeten te testen op fouten: wat gebeurt er als een link uitvalt, een wachtrij volloopt, een switch herstart of ECMP-routes wijzigen? In AI is een klein falen vaak niet fataal, maar wel zo significant dat de efficiëntie zo daalt dat kosten exponentieel oplopen.
RoCE is geen mode, maar een nieuwe vaardigheid
De groei van RoCE in AI onderstreept een onderliggende trend: hyperscalers en grote clouds willen hoge prestaties over Ethernet, vanwege de schaalbaarheid, diversiteit aan leveranciers en operationele flexibiliteit. InfiniBand behoudt een sterke rol in HPC en AI, maar Ethernet betreedt een terrein dat voorheen gereserveerd was voor speciale fabrics.
Voor technische teams betekent dit een update in vaardigheden. Je moet meer begrijpen dan VLANs, BGP EVPN en QoS: RDMA, communicatiepatronen in training, NCCL, congestiebeheer, PFC, ECN, DCQCN en telemetrie. Een integrale discipline tussen netwerken, systemen en AI-platform.
Het grootste pluspunt van Ethernet is dat het bekend, open en breed ondersteund is. Het minpunt: met RoCE moet de configuratie perfect zijn. Een gewone Ethernet-netwerk functioneert vaak redelijk zonder uiterste precisie; een RoCE-netwerk voor AI vraagt dat je de instelling tot in detail hebt afgestemd.
De kernboodschap: voor je meer GPU’s koopt, ontwerp eerst het netwerk dat ze effectief zal ondersteunen. AI schaalt niet alleen met versnellers, maar met een netwerk dat geheugen kan bewegen, packetverlies kan voorkomen en congestie kan managen tijdens dagen- of wekenlange training. RoCE is een van de technologieën die deze transitie mogelijk maken, maar vereist echte engineering, geen vinkje op de switch.
Veelgestelde vragen
Vervangt RoCE TCP binnen datacenters?
Nee. RoCE wordt vooral gebruikt voor lage-latentie, hoge-prestatie RDMA-verkeer, vooral tussen GPU-knooppunten of voor HPC-workloads. Andere toepassingen blijven TCP/IP gebruiken.
Moet je PFC verplicht gebruiken met RoCE?
In de praktijk gebruiken veel AI-architecturen RoCEv2 met PFC voor RDMA-verkeer om verlies te voorkomen. Vaak in combinatie met ECN en congestion control. Het is cruciaal om PFC nauwkeurig te configureren, niet in het hele netwerk tegelijk.
Wat is het verschil tussen RoCE en InfiniBand?
RoCE voert RDMA over Ethernet/IP uit, en profiteert van het Ethernet-ecosysteem. InfiniBand is een aparte fabric met native RDMA en een zeer geïntegreerde stack. Beide opties kunnen geschikt zijn, afhankelijk van schaal, kosten, hardware en doelen.
Wat moet je testen voorafgaand aan productie?
Throughput, latency, microbursts, incast, PFC-markeringen, ECN-signalen, ECMP-verdeling, linkfouten, NCCL-prestaties, en daadwerkelijke distributed training loads.
bron: RoCE AI