Ultra Ethernet 1.1 : quand l’Ethernet de l’IA se dote d’en-têtes scale-up, d’opérations collectives et d’un contrôle de congestion programmable

Le 12 octobre 2026, l’Ultra Ethernet Consortium (UEC) a publié la spécification Ultra Ethernet v1.1, qui prolonge les fondations posées par la v1.0 en juin 2025. Dans sa propre annonce, le consortium présente la 1.1 comme bien plus qu’une simple version corrective : elle apporte des travaux d’ampleur sur les réseaux scale-up, des améliorations du transport pour la compatibilité des applications et l’accélération des transferts massifs, les opérations collectives dans le réseau (INC, In-Network Collectives), la signalisation de congestion (CSIG, Congestion Signaling) et la gestion programmable de la congestion (PCM, Programmable Congestion Management).

Cette publication compte pour les réseaux de clusters d’IA, car l’histoire de l’Ethernet dans l’IA ne se résume plus à « du RoCE soigneusement déployé à l’échelle d’une architecture leaf-spine ». L’UEC pousse explicitement la même famille de technologies vers le domaine court et sensible à la latence traditionnellement occupé par les liaisons propriétaires entre accélérateurs, tout en continuant de viser le scale-out du HPC et de l’IA. Cet article s’en tient au plus près de la spécification v1.1 de l’UEC et de ses documents de presse, attribue les gains chiffrés au consortium lui-même, signale les premières démonstrations de terminaux (et non des promesses de produits commercialisés) et situe la 1.1 par rapport à des initiatives ouvertes connexes comme ESUN, au sein de l’OCP, sans les fondre dans une même soupe d’acronymes.

Encadré : scale-up et scale-out (version pour non-spécialistes)
Le scale-up relie des accélérateurs au sein d’un domaine resserré (souvent un nœud, un tiroir ou un pod) afin que les GPU/XPU puissent échanger un trafic de type mémoire avec une latence très faible (des problèmes de la classe NVLink, auxquels s’attaquent désormais aussi des variantes ouvertes d’Ethernet).
Le scale-out relie de nombreux nœuds à travers la salle, afin que des milliers d’accélérateurs entraînent ou servent des modèles comme un seul cluster (les réseaux classiques InfiniBand ou Ethernet RoCE).
Ultra Ethernet est né comme un projet d’Ethernet de scale-out pour l’IA et le HPC ; selon l’UEC, la v1.1 ajoute des en-têtes, des profils et des délestages destinés aussi au scale-up, afin qu’une même famille de normes puisse couvrir les deux usages. Il s’agit toujours de conceptions différentes ; la 1.1 cherche à éviter qu’elles ne deviennent des univers différents.

Ce que la v1.0 avait déjà changé, et pourquoi la 1.1 est arrivée si vite

L’UEC présente Ultra Ethernet comme une architecture Ethernet ouverte et interopérable pour l’IA et le HPC, élaborée sous l’égide de la Joint Development Foundation avec un large panel d’industriels membres. La spécification v1.0 (juin 2025) a fixé l’orientation du transport et de l’écosystème ; l’annonce de la 1.1 indique que les déploiements d’IA et de HPC de nouvelle génération ont déjà adopté nombre de techniques de la v1.0. La version 1.1, datée du 12 octobre 2026 dans le communiqué comme dans le PDF publié, est la première révision majeure à s’engager résolument dans le scale-up et le calcul dans le réseau.

La spécification elle-même souligne qu’Ultra Ethernet n’impose aucune modification de la couche réseau ni des couches physique et liaison d’Ethernet : une mise en œuvre conforme peut s’appuyer sur les commutateurs Ethernet courants à la date de publication, tandis que des fonctions optionnelles améliorent le comportement pour l’IA et le HPC. Cette philosophie, qui consiste à enrichir Ethernet sans scinder l’univers physique, distingue politiquement l’UEC d’une interconnexion conçue de zéro, et concentre l’ingénierie la plus ardue sur les en-têtes, le transport, la congestion et la programmabilité des cartes réseau.

La prise en charge des réseaux scale-up dans la 1.1

Selon l’UEC, le thème le plus substantiel de la 1.1 est le scale-up. Le consortium met en avant plusieurs mécanismes concrets :

Des paquets plus petits, moins de surcoût à vide. L’UEC décrit des optimisations qui réduisent les octets inactifs de l’intervalle entre paquets (jusqu’à 11 octets économisés entre deux paquets, selon son explication) afin de rendre les petits messages plus efficaces. Le trafic de scale-up abonde en petites opérations sensibles à la latence ; gaspiller des octets dans les intervalles y pèse davantage que pour les gros AllReduce.

L’en-tête de transfert unifié (UFH, Unified Forwarding Header). L’UEC introduit l’UFH, un en-tête réseau qui se superpose à un en-tête Ethernet traditionnel et permet, selon le consortium, d’économiser 20 octets par rapport à un paquet IP classique, tout en préservant les fonctions de routage IP et l’interopérabilité sur le câble avec l’Ethernet traditionnel. L’annonce renvoie aux détails de l’UFH_32 dans la spécification 1.1.

Le profil « Unified Local ». Destiné aux terminaux de scale-up, ce profil comprend un transport simplifié prenant en charge les opérations d’écriture, de lecture et atomiques avec des en-têtes optimisés, tout en restant compatible sur le câble avec les normes Ultra Ethernet Transport (UET), selon l’UEC.

Pris ensemble, ces éléments ne font pas d’Ethernet « un NVLink plus lent ». Ils visent à alléger la taxe de la mise en paquets d’Ethernet à l’intérieur d’un pod tout en préservant l’interopérabilité : exactement le compromis que des coalitions ouvertes peuvent ratifier et que des bus propriétaires peuvent ignorer.

Les notes de collaboration du communiqué de l’UEC comptent sur le plan opérationnel : l’UEC indique travailler avec l’OCP pour que la prochaine spécification ESUN intègre les technologies de scale-up de la v1.1 (ESUN 1.0 reprenait déjà de nombreuses idées de la v1.0), avec OCP SUE-T sur l’élargissement de la prise en charge des terminaux, et avec l’IEEE sur la poursuite de la normalisation de CSIG. Les acheteurs doivent suivre ces convergences : une carte réseau compatible UET associée à une feuille de route de puces de commutation qui ne suit qu’ESUN, ou l’inverse, crée un risque d’intégration.

Améliorations du transport : porter sans réécrire

L’un des objectifs affichés de la 1.1 est de réduire le coût de migration. L’UEC a créé une correspondance Verbs pour Ultra Ethernet (UET Verbs) prenant en charge le profil AI Base et deux fonctions de la couche transport : une correspondance mémoire plus souple entre services logiques, et des groupes de synchronisation qui aident à reproduire la sémantique de livraison ordonnée des achèvements côté répondeur, familière aux utilisateurs des Verbs existants. Selon l’UEC, cette combinaison permet de porter les applications existantes vers Ultra Ethernet avec moins de modifications.

Pour les piles logicielles d’IA qui reposent sur NCCL, MPI et les bibliothèques collectives des fournisseurs, c’est là que se joue l’adoption. Des réseaux succombent dans le bourbier du portage, même lorsque leurs protocoles sont élégants. Une sémantique calquée sur les Verbs est le moyen par lequel l’UEC tente d’éviter que les infrastructures de l’ère PyTorch ne traitent Ultra Ethernet comme un simple projet de recherche du week-end.

Opérations collectives dans le réseau : le calcul de bande passante de l’UEC

Les opérations collectives dans le réseau (INC) constituent le délestage phare. Selon l’UEC, les chemins all-reduce traditionnels envoient les données deux fois dans le réseau (réduction, puis diffusion), si bien que produire un résultat réduit de 1 Go peut obliger chaque terminal à envoyer 2 Go. Avec l’INC, affirme l’UEC, un terminal n’a besoin d’envoyer que 1 Go, ce qui, dans ce calcul illustratif, procure une accélération des communications pouvant aller jusqu’à 2 fois, car les commutateurs réduisent les données au fil de leur arrivée et diffusent le résultat.

L’UEC affirme également que l’INC peut réduire la latence des petites opérations collectives en recourant à la diffusion par le réseau plutôt qu’à des algorithmes en arbre qui paient log n sauts de latence supplémentaire. Ces gains sont les bénéfices revendiqués par l’UEC pour ce schéma d’architecture ; ils supposent des commutateurs compatibles INC et une chaîne logicielle qui sollicite effectivement le délestage. Les exploitants doivent les lire comme des plafonds avancés par le consortium, en attendant les puces et l’intégration dans NCCL, et non comme des gains mesurés de temps d’exécution sur un cluster identifié.

Signalisation de congestion et contrôle programmable

L’Ethernet de l’IA vit ou meurt selon son comportement face à la congestion. L’annonce de la 1.1 détaille deux outils complémentaires.

La signalisation de congestion (CSIG). Selon l’UEC, CSIG est une étiquette compacte de couche 2, de 4 ou 8 octets, mise à jour par les commutateurs avec des informations très précises sur le goulot d’étranglement rencontré sur le chemin d’un paquet. Les terminaux connaissent ainsi à la fois l’ampleur et l’emplacement de la congestion. L’UEC indique que ses algorithmes de contrôle de congestion NSCC et RCCC exploitent désormais CSIG : NSCC utilise la latence de file d’attente signalée au saut goulot pour améliorer l’équité ; RCCC utilise des mesures de délai ou de profondeur de file pour attribuer les crédits d’émission. Au-delà des boucles de contrôle, l’UEC présente CSIG comme une télémesure fine à destination des exploitants. L’annonce renvoie à un article de l’ACM SIGCOMM pour une analyse plus approfondie de la conception de CSIG.

La gestion programmable de la congestion (PCM). Au-delà des algorithmes intégrés actuels, l’UEC décrit la PCM comme un langage et une interface de programmation unifiés exposés par les fournisseurs de cartes réseau, afin que les algorithmes de contrôle de congestion et d’équilibrage de charge puissent être adaptés à une charge de travail et compilés pour s’exécuter sur les terminaux, de manière portable entre cartes compatibles PCM. C’est un enjeu d’accélérateurs IA et de puces autant que de réseau : la carte réseau devient un calculateur de congestion programmable, et plus seulement un délestage RoCE figé.

Le billet d’AMD du 11 octobre 2026 sur sa carte réseau IA (la veille de la publication de la 1.1) souligne le parallèle industriel : AMD y décrit une architecture de carte réseau IA programmable utilisée pour développer et valider des transports Ethernet adaptés à l’IA, rappelle son statut de membre fondateur de l’UEC et d’auteur du Network-Signaled Congestion Control (NSCC) désormais intégré à la spécification de gestion de la congestion de l’UEC, et indique avoir livré l’une des premières cartes réseau IA capables de prendre en charge la spécification de transport de l’UEC pour les tests de l’écosystème. Il faut y voir un contexte fourni par un fournisseur, qui explique pourquoi le vocabulaire PCM/NSCC arrive dans les feuilles de route des puces, et non une évaluation indépendante des fonctions de la 1.1.

Les terminaux fin 2026 : des démonstrations, pas encore une offre commerciale complète

La vitesse d’élaboration des spécifications n’est utile que si des terminaux existent. Fin octobre 2026, les annonces matérielles publiques restent embryonnaires.

Lors de l’Altera Innovators Day 2026 (San José, 28 octobre 2026), DYNANIC a présenté la mise en trame et le chemin de données Ultra Ethernet sur une carte Silicom ThunderFjord dotée d’un FPGA Altera Agilex 7 de la série M (deux ports 400GbE et PCIe Gen5 x16), en utilisant un rebouclage pour émuler deux terminaux et montrer en temps réel l’effet de la congestion. Le compte rendu de DYNANIC est explicite sur le séquencement de sa feuille de route : la mise en trame et le chemin de données Ultra Ethernet fonctionnent sur du matériel réel dans la démonstration ; la retransmission, la réponse à la congestion et le multichemin, éléments centraux d’Ultra Ethernet Transport, constituent les prochaines étapes. Il s’agit d’une démonstration et d’un parcours d’évaluation, et non de l’annonce d’une carte réseau UET complète et commercialement disponible. DYNANIC indique également préparer des tests d’interopérabilité avec l’UEC et propose à certains partenaires une évaluation anticipée de sa propriété intellectuelle Ultra Ethernet.

Lire la 1.1 à la lumière de ce calendrier de démonstrations donne une image honnête de l’adoption : l’encre est sèche sur les en-têtes de scale-up et l’INC ; les cartes réseau commerciales complètes en matière de multichemin et de gestion de la congestion sont encore en voie de convergence. Les hyperscalers dotés de leurs propres puces avanceront les premiers ; les fournisseurs de FPGA et de propriété intellectuelle feront le lien pour tous les autres.

Ce que la 1.1 change pour les architectes

1. Une planification à deux domaines. Si votre pod d’accélérateurs de 2027 doit s’appuyer sur un Ethernet de scale-up ouvert (voies ESUN/Ultra Ethernet) et pas seulement sur des liaisons propriétaires, l’UFH et les profils Unified Local doivent figurer dans l’appel d’offres pour les cartes réseau et les commutateurs, et non en note de bas de page.

2. Le délestage des opérations collectives comme fonction du commutateur. Selon l’UEC, l’INC transfère la réduction dans le réseau. Cela suppose des fonctions dans les puces de commutation et le système d’exploitation réseau, des points d’ancrage dans NCCL et les bibliothèques, ainsi que des modes de défaillance lorsqu’un commutateur réducteur se comporte mal. Prévoyez un budget pour les tests d’intégration.

3. Une télémesure utile lors des rafales de l’IA. Les étiquettes de CSIG signalant le goulot d’étranglement du chemin sont conçues pour des flux d’IA synchronisés et à faible entropie, qui mettent en échec les hypothèses classiques de l’ECMP. Demandez aux fournisseurs comment CSIG apparaît dans leur télémesure en continu.

4. La gouvernance de la programmabilité. La PCM permet de compiler une politique de congestion sur mesure. C’est à la fois un pouvoir et un risque : versionnez les algorithmes comme des micrologiciels, testez-les sous différents mélanges de tâches et évitez les configurations uniques par cluster que seul un ingénieur comprend.

5. Tenir le scale-across à part. L’effort de scale-up de la 1.1 concerne les pods et les salles, et non l’interconnexion cohérente entre campus (DCI). Les réseaux Ethernet tenant compte de la distance et l’optique ZR relèvent d’un autre problème (voir notre article sur les réseaux multi-campus).

Comment la 1.1 s’articule avec RoCE, ESUN et le scale-up propriétaire

Ultra Ethernet ne fera pas disparaître RoCEv2 du jour au lendemain. De nombreux réseaux Ethernet d’IA continueront d’appliquer les recettes actuelles de gestion de la congestion pendant que les cartes réseau acquièrent les fonctions UET. Le scénario de migration que l’UEC défend avec la correspondance Verbs est progressif : préserver la sémantique applicative, introduire l’UFH et les profils locaux là où les pods en ont besoin, et activer l’INC là où les puces de commutation prennent en charge la réduction. Selon l’UEC, la compatibilité sur le câble avec l’Ethernet traditionnel reste une contrainte de conception : il n’est donc pas demandé aux infrastructures leaf-spine existantes de tout renuméroter dès le premier jour.

ESUN (Ethernet for Scale-Up Networking), au sein de l’OCP, constitue la déclinaison complémentaire de l’Ethernet pour les pods. Le communiqué de l’UEC indique qu’ESUN 1.0 intégrait déjà de nombreuses technologies de la v1.0 et que les groupes travaillent activement à intégrer les travaux de scale-up de la v1.1 dans la prochaine spécification ESUN, parallèlement aux travaux SUE-T sur les terminaux. Les architectes devraient donc soumettre à appel d’offres à la fois les affirmations de l’UEC sur le transport et celles d’ESUN sur les commutateurs et les profils, et demander aux fournisseurs une matrice d’interopérabilité unique plutôt que deux arborescences de diapositives qui ne se rencontrent jamais en laboratoire.

Le scale-up propriétaire (NVLink et ses équivalents) continuera de dominer les domaines les plus denses à sémantique mémoire. La 1.1 de l’UEC est la réponse du camp ouvert aux exploitants qui refusent un pod mono-fournisseur, ou qui veulent que leurs compétences d’exploitation Ethernet couvrent une plus grande partie de la baie. Elle ne prétend pas que l’Ethernet ouvert égale déjà toutes les latences des solutions propriétaires. Elle affirme que la taxe des en-têtes et les lacunes en matière de délestage des opérations collectives sont désormais des problèmes spécifiés, dotés d’outils spécifiés.

Sécurité, multilocation et réserves opérationnelles

Les clouds d’IA partagent leurs réseaux. La gestion programmable de la congestion (PCM), telle que la présente l’UEC, permet aux exploitants de compiler des politiques sur les terminaux. Ce pouvoir exige des cloisons entre locataires : le programme PCM agressif d’un locataire ne doit pas affamer la tâche d’entraînement d’un autre. Les étiquettes CSIG, en tant que télémesure de chemin, élargissent aussi ce qu’un observateur peut déduire des points chauds du réseau. Les revues de sécurité doivent traiter les commutateurs compatibles INC et les cartes réseau compatibles PCM comme des infrastructures privilégiées : signature des micrologiciels, listes d’algorithmes autorisés et tests de rayon d’impact ont leur place dans le même classeur que la politique BGP.

Les modes de défaillance se multiplient lorsque les opérations collectives migrent dans le réseau. Si un commutateur réducteur redémarre au milieu d’un AllReduce, les bibliothèques doivent se replier proprement sur des algorithmes exécutés uniquement par les terminaux. Les affirmations d’architecture de l’UEC supposent que tout se passe bien ; l’intégration en production dans NCCL (ou son successeur) sera jugée sur les cas où tout se passe mal. Exigez des démonstrations explicites de repli lors des preuves de concept des fournisseurs.

Une liste de contrôle pratique à 180 jours après la spécification 1.1

1. Inventorier les cartes réseau de votre feuille de route qui revendiquent le profil UET AI Base et la correspondance Verbs, ainsi que les commutateurs qui revendiquent CSIG et l’INC.
2. Tester en laboratoire sur deux baies la reproduction d’un mélange d’opérations collectives de production, avec et sans INC (lorsque les puces le permettent), en comparant non seulement la bande passante, mais aussi la traîne des retardataires.
3. Aligner les fonctions de l’UEC 1.1 sur la révision OCP ESUN que votre fournisseur de commutateurs s’engage réellement à livrer.
4. Considérer les démonstrations Ultra Ethernet sur FPGA (comme la démonstration en rebouclage de DYNANIC à l’Altera Innovators Day) comme des outils d’apprentissage de la mise en trame et de visualisation de la congestion, et non comme des données de planification de capacité.
5. Rédiger des tests de réception pour le déploiement des algorithmes PCM : versions figées, tâches canaris et désactivation automatique en cas de pertes pathologiques.
6. Séparer les projets de campus et de DCI de ce chantier, afin que l’optique ZR et les en-têtes UFH ne figurent pas dans le même registre des risques.

Ces points imposent aussi une clarification organisationnelle : les équipes réseau, accélérateurs et plateforme de ML doivent partager un même responsable de la feuille de route Ultra Ethernet. Les spécifications avancent au rythme des calendriers des consortiums ; les clusters, au rythme des calendriers de gestion des changements. Faire le lien entre les deux constitue le véritable travail d’adoption de la 1.1.

Perspectives

La spécification Ultra Ethernet v1.1 marque le moment où l’UEC étend publiquement l’Ethernet de l’IA, de « meilleur successeur de RoCE pour le scale-out » vers des en-têtes de scale-up, des opérations collectives dans le réseau et un contrôle de congestion programmable, les gains chiffrés étant présentés comme les propres affirmations de l’UEC (économies d’octets, accélération des communications pouvant aller jusqu’à 2 fois dans l’exemple d’all-reduce avec INC, équité améliorée grâce à CSIG). Les premières démonstrations sur FPGA montrent les chemins de mise en trame s’animer ; la complétude fonctionnelle du transport reste à venir. Pour les acheteurs d’infrastructures IA hyperscale, l’étape concrète n’est pas de réécrire le cluster demain, mais d’exiger des feuilles de route intégrant la 1.1 dans les contrats de cartes réseau, de commutateurs et de logiciels d’opérations collectives conclus au quatrième trimestre 2026 et au premier semestre 2027.

Le tableau stratégique est similaire pour les équipes accélérateurs IA et puces : des puces de terminaux incapables d’exposer un contrôle tenant compte de CSIG et une correspondance Ultra Ethernet calquée sur les Verbs sortiront des appels d’offres hyperscale, même si leurs débits SerDes bruts paraissent satisfaisants. À l’inverse, des ASIC de commutation qui mettent en œuvre l’INC sans mécanisme de repli robuste échoueront aux revues de fiabilité au niveau des tâches. La spécification 1.1 relève le niveau minimal de ce que signifie « Ethernet pour l’IA » dans un bon de commande.

L’Ethernet ouvert pour l’IA n’est plus un simple slogan. C’est une spécification versionnée, avec un PDF daté, une piste de recherche sur la congestion et un circuit de démonstrations matérielles qui commence tout juste à tourner. La v1.1 doit être considérée comme la grille à laquelle les fournisseurs doivent désormais répondre, en continuant de mesurer le temps d’exécution des tâches, et pas seulement les logos de conformité.

À lire aussi

• InfiniBand vs Ethernet pour les clusters IA : la guerre des fabrics dans l’usine IA
• Au cœur du commutateur IA : l’optique co-packagée passe de la démonstration de laboratoire au réseau refroidi par liquide
• Superfactories IA distribuées : comment le réseau s’étire entre les campus
• La baie de 1 MW : comment le 800 V CC et le refroidissement à l’eau tiède recâblent l’usine d’IA

Images : illustrations originales créées pour AndBeyond.Tech ; aucun logo ni aucune personne réelle n’y figurent.