Interconnexion WAN (optiques 200G)

Comment des sites de calcul se relient à 200 Gb/s à travers une salle, un campus ou une ville : quelle optique à quelle distance, quoi se branche où, et ce qu'il faut pour vraiment atteindre le débit nominal.

Quand deux sites ont tous deux des routes publiques, le plan de données de dispatch d'experts devrait être un lien direct — le relais est pour les bordures sans adresse à elles. Cette entrée est la recette concrète pour faire de ce lien direct un lien de classe 200 Gb/s avec des pièces de catalogue. Une règle organise tout : la fibre est un verre neutre en vitesse ; la vitesse réside dans le module enfichable à chaque extrémité.

• Côté NIC — les cartes de classe ConnectX-6/7 exposent des cages QSFP56 ; DAC/AOC/FR4/LR4/ER4 se logent tous directement dans la NIC. Un hôte de classe GB10 possède déjà deux ports QSFP 200 GbE embarqués, si bien qu'un lien entre deux sites ne requiert exactement qu'un seul câble et aucun nouveau matériel.
• Côté switch — les optiques cohérentes ZR+ sont au format QSFP-DD et ont leur place dans un switch ou un routeur ; la NIC du site rejoint alors ce switch à 200G via un court DAC. Utilisez ce palier quand le site distant est à des dizaines de kilomètres.
• La fibre elle-même — des paires LC duplex monomode standard (G.652), louées comme fibre noire au brin. Le même verre porte 100G aujourd'hui et 400G demain ; les mises à niveau sont un échange de module, jamais des travaux de génie civil.
• Au-delà de ~120 km — vous cessez d'acheter des pièces et commencez à louer une longueur d'onde à un opérateur ; la démarcation est une remise Ethernet sur votre switch.

two-site bench  : site A qsfp0 ──QSFP56 DAC 1m── site B qsfp0
campus pair     : site A [LR4] ──dark fiber, ≤10km── [LR4] site B
metro federation: site ──DAC── switch [ZR+ @200G] ──SMF ≤120km── [ZR+] switch ──DAC── site

• Utilisez RDMA (RoCE) pour le flux de dispatch là où c'est disponible — les hôtes de classe GB10 alimentent la NIC via des liens PCIe scindés, et la pleine vitesse mesurée (~185–190 Gb/s) apparaît sous RoCE avec une topologie correctement mappée ; un chemin mal mappé plafonne près de la moitié du débit et un TCP simple non optimisé atterrit bien plus bas.
• Activez les jumbo frames (MTU 9000) de bout en bout et gardez TCP_NODELAY sur les sockets de dispatch (le bridge le règle déjà).
• Attendez-vous à *vérifier*, pas à supposer : lancez un perftest entre sites après chaque changement physique — la différence entre 95 et 190 Gb/s est invisible tant qu'elle n'est pas mesurée.
• Gardez le relais 443 comme voie de repli — la politique de composition est direct d'abord pour les pairs publics, relais pour le NAT. Le rôle du relais est la portée, le rôle du lien direct est la vitesse.

Pourquoi cela compte pour l'architecture : la latence de décodage est bornée par le temps d'aller-retour (~5 µs/km dans la fibre — de la physique, insensible à la bande passante), si bien qu'un gros tuyau achète de la vitesse de prefill, du débit de dispatch par lots et une distribution quasi instantanée des tranches d'experts, pas une latence par token plus basse. C'est exactement le rôle du palier site dans la conception à deux paliers : la capacité dans le palier gros tuyau, la portée dans le palier relais.