Comment l'entraînement distribué de l'IA redessine les réseaux entre datacenters

L'entraînement des grands modèles de langage a depuis longtemps dépassé le cadre d'un seul datacenter. Google a entraîné Gemini de façon synchrone sur des clusters répartis dans différentes zones géographiques. Microsoft a relié ses datacenters IA du Wisconsin et de Géorgie en un unique supercalculateur distribué. AWS a connecté sur de longues distances des clusters de calcul IA pour Anthropic, qui développe Claude. Meta a construit des liaisons inter-sites à très haute performance pour soutenir l'entraînement de ses modèles. CoreWeave et Google Cloud ont annoncé un entraînement multi-cloud via une interconnexion privée ; Azure prévoit de suivre plus tard dans l'année.

Cette dispersion géographique s'explique par les limites d'un seul datacenter ou d'un cluster de campus, incapable de répondre aux exigences de puissance et de refroidissement. Cisco estime qu'entraîner un modèle moderne nécessite des clusters de dizaines de milliers de GPU. D'ici 2030, les plus grands entraînements de pointe consommeront entre 4 et 16 GW, selon les chercheurs d'Epoch AI. Distribuer les calculs permet de construire là où la puissance, l'espace et les contraintes d'urbanisme sont plus favorables.

La synchronisation, un goulot d'étranglement critique

L'entraînement d'un réseau de neurones est une répétition cyclique de calcul et de synchronisation. À chaque cycle, des milliers d'accélérateurs (GPU, AWS Trainium, Google TPU) doivent échanger leurs résultats et se synchroniser avant l'étape suivante. Les réseaux ne transportent pas du texte ou des images à entraîner, mais de vastes volumes de données numériques : gradients et résultats intermédiaires.

Lorsque des milliers d'accélérateurs terminent simultanément leur phase de calcul et commencent à communiquer, des problèmes d'incast apparaissent : de nombreux émetteurs convergent vers un seul récepteur, et le trafic arrive plus vite que la ligne ne peut l'absorber. Le problème fondamental reste la synchronisation : dans une tâche d'entraînement synchrone, le groupe de GPU le plus lent bloque tous les autres. Le délai réseau devient un délai de calcul.

Ramesh Sivakolundu, architecte chez Cisco Silicon One, l'explique ainsi : « Toute tâche d'entraînement est une répétition de calcul et de synchronisation. On calcule les poids, on les communique pour synchroniser chaque GPU, puis on relance le calcul. Le trafic en rafales survient périodiquement, et tout le réseau doit achever l'échange avant l'étape suivante.

Optique cohérente et files d'attente profondes

À l'intérieur d'un même datacenter, la connectivité réseau complète entre racks de GPU atteint la bande passante prévue dès la conception. Mais pour le scale-across (entraînement distribué), le trafic vers un autre datacenter se trouve resserré : jusqu'à 14 fois moins que la référence DCI classique, selon les estimations de Cisco. Une rafale synchronisée peut transformer ce tuyau étroit en véritable goulot d'étranglement.

Une DCI traditionnelle relie des datacenters indépendants pour la redondance et la répartition de charge ; son trafic est asynchrone — un flux n'a pas besoin de terminer en même temps que les autres. Dans l'entraînement IA en scale-across, le réseau inter-sites devient une composante d'un calcul unique et coordonné, exigeant une bande passante suffisante et une livraison prévisible.

La bande passante évolue avec la distance. À l'intérieur d'un rack, on atteint jusqu'à 800 Gb/s, voire 1,6 Tb/s sur de courtes liaisons en cuivre. À l'échelle de la facility, on utilise des optiques enfichables : les liens scale-out couvrent de quelques centaines de mètres à environ 2 km. Le scale-across étend cela à des distances métropolitaines ou régionales, créant de nouvelles exigences.

L'optique courte portée des datacenters ne peut pas gérer 400–800 Gbps sur des centaines de kilomètres. Il faut une optique cohérente : une modulation sophistiquée et un traitement numérique du signal (DSP) compensent les distorsions physiques sur de longues distances. Le nombre de ports requis est colossal : relier deux sites IA de 100 MW nécessite entre 12 000 et 32 000 ports optiques cohérents (contre 1 000 à 2 000 pour une DCI classique entre facilities comparables). À 400–800 Gb/s par port, cela représente une capacité agrégée de l'ordre du multi-pétabit.

Une solution intelligente consiste à utiliser des optiques cohérentes enfichables : les longueurs d'onde DWDM sont générées directement dans les ports du routeur, évitant un banc séparé de transpondeurs DWDM. Le Cisco Open Transport 3000, avec sa conception multi-rail, réduit la consommation électrique par rail de 75 % et l'encombrement en rack de 80 %. Lorsqu'un système de transport dédié est nécessaire, le NCS 1014 offre 12,8 Tb/s depuis une carte ligne de 1 RU.

Latence, mise en tampon et gestion de la congestion

Sur de longues distances, le retour d'information sur la congestion arrive plus lentement. Sur une liaison à 800 Gb/s sur 100 km, environ 100 Mo de données sont déjà en transit au moment où l'émetteur apprend qu'il y a un problème. Les architectures à faibles files d'attente, conçues pour la basse latence au sein d'un datacenter, ne suffisent plus : il faut des files d'attente profondes.

La mise en tampon profonde absorbe les rafales temporaires pendant que la gestion du trafic et la signalisation de congestion résolvent le problème. Le buffer partagé est un pool unique de mémoire, réparti dynamiquement entre les ports. Cela permet à un lien saturé d'absorber une rafale plus importante sans perte de paquets.

Cisco utilise le Silicon One P200 (processeur de routage programmable de 51,2 Tb/s) dans ses plateformes 8223 et N9000, associé à des optiques enfichables cohérentes 400G et 800G pour les liaisons longue distance. Le P200 dispose d'un processeur réseau programmable et d'outils P4, permettant d'ajouter des fonctionnalités en logiciel sans modifier le silicium. Pour le scale-across, où topologie et gestion du trafic restent encore expérimentales, cette flexibilité est cruciale.

La stratégie de Cisco repose sur la co-conception : l'ASIC réseau est développé des années avant le routeur final, en anticipant la communication collective prévisible des entraînements IA. La gestion proactive de la congestion lisse ou ordonnance le trafic avant une rafale prévisible, tandis que la mise en tampon profonde sert de filet de sécurité pour la congestion transitoire et les pannes de liaison. Les deux approches sont complémentaires : l'une évite la formation de files d'attente, l'autre donne au réseau de l'espace pour le trafic lorsqu'une file se forme malgré tout. La protection par chiffrement matériel est intégrée, évitant un goulot d'étranglement supplémentaire sur le fabric d'entraînement.