De 200G-vraag
Onze zwerm-hubs kunnen nu al met 200 Gb/s verbinden met onderdelen uit het schap — één zit ingebouwd in de GB10. Dit is wat een dikke pijp een gedistribueerde MoE oplevert, en het ene ding dat het niet kan.
De premisse: WAN-decodering is RTT-gebonden, niet bandbreedtegebonden — onze comm-routekaart liet zien dat bytes het makkelijke deel zijn. Dus wat verandert er werkelijk als hubs 200-Gb/s-verbindingen krijgen? Bijna alles aan *capaciteit*, en bijna niets aan *latentie*.
De hardware is niet futuristisch — één zit in onze GB10-worker
De GB10 Grace Blackwell die onze 122B-experts berekent, draagt aan boord een NVIDIA ConnectX-7 met twee 200-GbE-QSFP-poorten. Twee van deze machines verbinden direct met één QSFP56-DAC-kabel van ~$100 — een 200G-cluster van twee hubs zonder switches. ARM is hier een eersteklas burger: dezelfde mlx5-driverstack die deze NIC's in x86-datacenters draait, draait ze op aarch64, wat precies is wat de GB10 is.
De kleine lettertjes: de GB10 voedt zijn ConnectX-7 via twee PCIe-Gen5-x4-verbindingen in multi-host-modus. Gemeten volle snelheid (~185–190 Gb/s) vereist RoCE (RDMA) en een correct gemapte topologie — naïeve TCP over een verkeerd gemapt pad landt op ~95 Gb/s of slechter. Dikke pijpen worden gekocht met configuratie, niet alleen met kabels.
200G is een catalogusartikel op elke afstand
| afstand | onderdeel | vormfactor |
|---|---|---|
| rack (0.5–3 m) | QSFP56-DAC-koper | kabel, ~$100 |
| kamer (~30 m) | AOC actief optisch | kabel |
| campus (2–10 km) | 200G FR4-/LR4-optiek | QSFP56-module |
| metro (~40 km) | 200G ER4-optiek | QSFP56-module |
| regio (~120 km) | 400G ZR+ coherent, gedraaid op 200G-lijnsnelheid | QSFP-DD-module |
| long-haul (100en km) | carrier-200G-golflengte / DWDM-lijnsysteem | geleaste dienst |
In het WAN is de *kabel* gewoon standaard single-mode glasvezel — snelheidsneutraal glas dat al elke stad overspant. De snelheid zit in de pluggable optiek aan elk uiteinde, en OpenZR+ maakte 200G-over-120 km een module die je in een switch plugt, geen telecomproject. Daarbuiten least je een golflengte.
Elke bandbreedteterm in de zwerm verdwijnt
- Een dispatch-payload (~110 KB/token/laag vandaag, ~10 KB na de wire-routekaart) serialiseert in microseconden — payloadgrootte houdt volledig op een ontwerpbeperking te zijn.
- Een expertplak wordt in ~32 ms verstuurd (794 MB, theoretisch) en een heel 122B-model synchroniseert in ~3 s — herbalancering van de dekkingsmarkt en onboarding van nieuwe hubs worden bijna-direct.
- Prefill van lange context — de enige echt bandbreedtezware fase — beweegt op wire speed, dus de tijd tot het eerste token op 100K-token-prompts wordt backbone-rekengebonden.
- Batch-dispatch schaalt zonder wire-plafond: expert-pool-verkeer geaggregeerd over vele gebruikersstromen is precies de bandbreedtezware, latentietolerante belasting die een dikke pijp opslokt. Dit is wat een multi-backbone-federatie — meerdere hubs, elk met KV voor hun eigen gebruikers, die één expert-pool delen — praktisch maakt.
Licht haast zich niet
Glasvezel draagt licht met ~5 µs/km, en geen hoeveelheid bandbreedte verandert dat. Een rondreis van 13 ms is 13 ms bij 200 Gb/s. Autoregressief decoderen betaalt die rondreis per gesharde laag, per token — daarom blijven speculatief decoderen (k tokens per rondreis) en shared-expert-overlap (rekenen terwijl de dispatch onderweg is) essentieel, zelfs tussen hubs verbonden door de dikste pijp op de markt. Bandbreedte koopt doorvoer; alleen rondreis-discipline koopt latentie.
Zo bezinkt de architectuur in twee lagen. Een hublaag — backbones en hot experts verbonden door 200G-klasse-links, waar de capaciteit feitelijk onbegrensd is — en een edgelaag — telefoons en kleine apparaten op de 443-relay, die de lange staart van experts dragen die de schaarstemarkt hun toewijst. De dikke pijp laat de eerste laag als één machine aanvoelen; de relay houdt de tweede laag open voor iedereen. Geen van beide vervangt de ander: die splitsing *is* het ontwerp.