Résumé

  • Ultra Ethernet Consortium est un projet de la Joint Development Foundation lancé le 19 juillet 2023 par AMD, Arista Networks, Broadcom, Cisco, Eviden/Atos, Hewlett Packard Enterprise, Intel, Meta et Microsoft. C’est un consortium industriel d’élaboration de spécifications, pas une entreprise conventionnelle ni un opérateur de réseau.
  • Son périmètre va bien au-delà d’un lien Ethernet plus rapide ou du remplacement de RoCE. La version 1.0.3, de 573 pages, couvre le logiciel, le transport, le réseau, la liaison et la couche physique, ainsi que des travaux sur la gestion, le stockage, les tests et la conformité.
  • Ultra Ethernet Transport combine plusieurs modes de livraison, du multipath au niveau des paquets, une retransmission sélective, un contrôle de congestion côté émetteur et récepteur, l’ECN, une troncature optionnelle des paquets, une réémission locale optionnelle, un contrôle de flux basé sur des crédits optionnel et une sécurité de transport de bout en bout optionnelle.
  • Les produits et démonstrations d’AMD, Broadcom, Nokia et Keysight montrent que l’implémentation a commencé, mais la conformité publique reste surtout fondée sur l’auto-attestation de l’implémenteur; aucun registre public complet de certification indépendante ni recensement de déploiements à grande échelle n’a été publié.
  • L’opportunité stratégique de l’UEC vient de la base installée d’Ethernet et d’une chaîne d’approvisionnement multipartenaires. Ses principaux risques sont la complexité des endpoints, la fragmentation via des fonctions optionnelles, les obligations de brevets RAND, l’immaturité de la gestion et des tests, et l’écart entre la publication d’une spécification et la vérification de l’interopérabilité en production.

Pourquoi l’IA a fait du réseau une partie de l’ordinateur

Ultra Ethernet Consortium est né autour d’un changement de l’économie de la computation. Dans un réseau d’entreprise ordinaire, on attend qu’une infrastructure transporte de nombreux flux indépendants avec une capacité et une disponibilité acceptables. Dans un vaste système d’entraînement d’intelligence artificielle ou dans une machine de calcul haute performance, le réseau fait partie d’un calcul unique et synchronisé. Des milliers d’accélérateurs peuvent échanger des paramètres, des gradients ou des données scientifiques par des opérations collectives.

Une phase peut ne pas progresser tant que le entité le plus lent n’a pas reçu l’information nécessaire. C’est pourquoi un léger déséquilibre de routage, un épisode de congestion ou la perte d’un seul paquet peuvent laisser inutilisés des processeurs très coûteux alors que l’utilisation moyenne du réseau semble bonne.

Cela change ce que les opérateurs doivent optimiser. La bande passante agrégée reste importante, mais elle ne suffit plus. Le temps de fin de travaux, la latence de file d’attente, l’incast, la récupération des pertes, la répartition du trafic entre chemins parallèles et la quantité d’état que doivent conserver les endpoints comptent tout autant. Un réseau qui livre rapidement la majorité des paquets, mais retarde une petite fraction, peut bloquer toute une opération collective. Une méthode de retransmission acceptable pour le trafic conventionnel peut perdre trop de temps lorsqu’un seul paquet d’un long message se perd.

Un flux fixé à une seule route de coût équivalent peut plafonner plus tôt que prévu alors que la capacité reste libre dans d’autres parties de la topologie.

La thèse fondatrice de l’UEC était que ces problèmes ne pouvaient être réglés ni par une seule fonction nouvelle du switch, ni par un algorithme de congestion isolé. La chaîne de communication commence au-dessus du réseau, dans les bibliothèques logicielles et la sémantique applicative. Elle passe par la table mémoire, les opérations distantes, l’état du transport, la livraison des paquets, le contrôle de congestion, le forwarding IP, les liens Ethernet, l’optique et la signalisation physique.

Si ces couches sont conçues séparément, une optimisation localisée peut se contenter de déplacer le goulot d’étranglement ou de créer des hypothèses incompatibles ailleurs.

La réponse de l’UEC est une architecture coordonnée. Elle conserve Ethernet et IP parce que les opérateurs les connaissent déjà et parce qu’il existe une chaîne industrielle immense de commutateurs, d’optiques, de câbles, de systèmes d’exploitation réseau, de télémétrie et d’outils de gestion. Dans le même temps, elle modifie ou étend les parties que le consortium juge mal adaptées aux grandes charges IA et HPC. Le résultat n’est pas « un Ethernet classique avec un autre logo ».

C’est une tentative de faire circuler via une technologie connue un mécanisme spécialisé dont le comportement est défini depuis l’API logicielle jusqu’à la vitesse de signalisation de chaque lane.

Cette distinction explique l’importance de l’UEC pour l’infrastructure numérique. Le projet ne possède pas d’accélérateurs, d’usines, de centres de données ni de régions cloud. Il définit des contrats que les entreprises membres et d’autres implémenteurs peuvent intégrer dans des NIC, des ASIC de commutation, des systèmes, des pilotes, des bibliothèques et des bancs de test. Son influence ne se matérialisera que lorsque des produits indépendants échangeront correctement du trafic pendant des pannes, de la congestion, des mises à jour et des combinaisons de fournisseurs.

Qu’est-ce que le UEC et que n’est-ce pas

Ultra Ethernet Consortium est le nom public d’un projet formel dont la série juridique se nomme Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. La structure l’insère dans la Joint Development Foundation et dans la famille plus large de la Linux Foundation. Elle fournit aux entités un cadre juridique déjà existant pour l’adhésion, la gouvernance, la propriété intellectuelle, le financement et les relations extérieures sans les obliger à créer une nouvelle entité indépendante.

Cette structure compte car l’UEC est souvent décrit de manière imprécise comme entreprise, alliance ou organisme de normalisation. Il ne s’agit pas d’une société commerciale avec actionnaires, capital propre, valorisation ou comptes publiés de manière indépendante. Il ne vend pas de produits Ethernet, n’exploite pas un réseau public et n’est pas propriétaire du matériel promu par ses membres. C’est un consortium de développement de spécifications avec un cadre juridique et de propriété intellectuelle. Ses documents publics visent à devenir des contrats de mise en œuvre entre plusieurs entreprises.

L’UEC n’est pas non plus synonyme de Ultra Ethernet Transport. L’UET est l’architecture de transport située au cœur de la spécification, mais le travail du consortium est plus large. Il inclut le mappage du logiciel vers libfabric, la sémantique des messages et des paquets, les hypothèses réseau, les options de liaison, les exigences physiques, la gestion, l’alignement avec le stockage, la performance et le débogage, la conformité et les tests. Réduire le projet à « un nouveau protocole RDMA » masque la conception transversale qui le rend ambitieux et complexe.

L’UEC n’est pas le groupe de travail IEEE 802.3. L’IEEE 802.3 développe les normes fondamentales d’Ethernet en MAC et couche physique via son propre processus formel. L’UEC s’appuie sur cet écosystème et maintient une relation de dépendance, mais ne le remplace pas. La limite analogue s’applique aux mécanismes IETF utilisés par l’UET, notamment IPv4, IPv6 et l’Explicit Congestion Notification; à l’écosystème OpenFabrics qui maintient libfabric; et aux organisations qui travaillent sur le stockage, le matériel ouvert et les interconnexions d’accélérateurs.

Le site du projet a déjà utilisé une formulation suggérant un statut d’organisation internationale de normalisation. La formulation la plus prudente et la mieux étayée est que l’UEC est une organisation internationale de développement de spécifications sous le cadre JDF. Il n’existe aucune preuve qu’elle fasse partie de l’International Organization for Standardization, que ses documents soient des normes ISO, ni qu’ils possèdent un numéro ISO.

La distinction n’est pas qu’une question de terminologie: elle détermine l’origine de l’autorité, le fonctionnement de la participation et les engagements juridiques que les implémenteurs peuvent assumer.

L’UEC doit être évalué selon la fonction réelle qu’il remplit. Il coordonne des concurrents et des opérateurs autour d’un design technique commun, publie des spécifications, anime des groupes de travail et gère les obligations déclarées de brevets, produit des matériaux de conformité et entretient des relations avec des organismes voisins. Il ne peut pas rendre un produit interopérable ni obliger le marché à adopter son architecture par une simple déclaration.

La coalition fondatrice de neuf entreprises

Le consortium a été annoncé le 19 juillet 2023 par neuf organisations situées à différents niveaux de la chaîne d’approvisionnement IA et HPC: AMD, Arista Networks, Broadcom, Cisco, Eviden —alors associée à Atos—, Hewlett Packard Enterprise, Intel, Meta et Microsoft. Cette ampleur fut d’emblée un avantage stratégique. Un transport conçu uniquement par des fabricants de commutateurs pourrait ignorer les contraintes des applications et des endpoints. Un design dirigé uniquement par des fournisseurs d’accélérateurs pourrait optimiser autour d’un seul écosystème de matériel.

Un projet exclusivement orienté cloud pourrait manquer d’expertise en silicium, optique et systèmes nécessaire pour transformer une architecture en produits.

AMD apportait des processeurs, des accélérateurs et une connectivité endpoint. Arista et Cisco apportaient la commutation Ethernet à grande échelle et l’expérience opérationnelle. Broadcom contribua avec du silicium de switching, des NIC et des SerDes haute vitesse. HPE et Eviden fournissaient les systèmes HPC et une longue expérience des interconnexions spécialisées. Intel apportait des processeurs, de l’Ethernet et du logiciel. Meta et Microsoft représentaient des opérateurs hyperscale avec des incitations directes à améliorer l’utilisation des grands clusters IA et à réduire la dépendance vis-à-vis d’un fournisseur intégré.

La coalition réunit aussi des intérêts commerciaux concurrents. Les membres vendent des NIC, des ASIC de switch, des systèmes, des capacités cloud, de l’optique, du logiciel et du support. Certains détiennent des portefeuilles de brevets pouvant être nécessaires pour implémenter la spécification. Certains profitent d’un standard large et multipartenaires, tout en pouvant tirer avantage de fonctions propriétaires différenciées.

Le consortium n’efface pas la concurrence; il crée un forum où des rivaux s’accordent sur des interfaces minimales et continuent de se concurrencer sur la qualité de mise en œuvre, la performance, l’intégration et les conditions commerciales.

Le Slingshot de HPE fournit un exemple utile de lignée technique. C’est une fabric HPC commerciale compatible avec Ethernet, avec routage adaptatif et gestion de congestion. Des commentaires associés à HPE ont indiqué qu’une spécification « HPC Ethernet » avait été versée à l’UEC et ont estimé qu’une part significative de l’UET est issue d’idées de transport de Slingshot. Le pourcentage exact n’a pas été vérifié de manière indépendante et ne doit pas être traité comme une comptabilité officielle du consortium.

Le point le plus large est bien étayé: l’UEC n’a pas commencé à partir de zéro; il a intégré l’expérience de la production HPC, du cloud networking, de RDMA et d’Ethernet.

Ce mélange de systèmes antérieurs explique la nécessité d’utiliser « ouvert » avec précision. La spécification validée de l’UEC est diffusée publiquement et l’architecture est pensée pour être implémentée par plusieurs fournisseurs. Cependant, le projet est aussi un lieu où les membres apportent connaissance préalable, brevets et feuilles de route de produit. Le caractère public du document ne supprime pas les conditions économiques ou juridiques liées à la technologie.

Une série juridique conçue pour permettre la collaboration entre concurrents

Le modèle de la Joint Development Foundation offre à l’UEC une structure formelle sans en faire une entreprise opérationnelle conventionnelle. Le projet possède un nom, une portée, des catégories de membres, un Steering Committee, des groupes de travail et des obligations de propriété intellectuelle. L’entité parapluie JDF apporte une infrastructure non lucrative et corporative et peut conserver des actifs et accords. Cela réduit le coût de constitution d’un consortium et donne aux concurrents un processus reconnu pour collaborer.

Le Steering Committee pilote le projet. Ses responsabilités documentées incluent la coordination des groupes de travail, l’approbation des membres, l’administration des actifs et des finances, la sélection ou la rotation de la présidence, la supervision des progrès et le contrôle de la communication publique et des marques du projet. Le consensus est privilégié. Si celui-ci échoue, la charte prévoit une supermajorité des trois quarts parmi les entités éligibles qui remplissent les exigences de présence. Les recours écrits peuvent être adressés à la présidence.

Brad Booth, de Meta, était le président initial. La spécification 1.0.3 énumère J. Metz, d’AMD, comme président; Barry Davis, de HPE, comme vice-président; Hugh Holbrook, d’Arista, comme président du Technical Advisory Committee; et Puneet Agarwal, de Marvell, comme vice-président du TAC. Paul Congdon apparaît comme éditeur de la spécification. Le document identifie aussi des responsables et auteurs des travaux physiques, de liaison, transport et logiciel. Le programme de sommet de 2026 mentionne d’autres responsables opérationnels.

Ces fonctions ne remplacent pas nécessairement les titres formels de la spécification, et le matériel public ne fournit pas d’organigramme complet et à jour.

La charte prévoit trois catégories de membres: Steering, General et Contributor. Les membres Steering participent à la gouvernance et désignent en général des représentants au Steering Committee. Les membres General peuvent travailler dans tous les groupes techniques, mais n’ont pas de siège au comité. Les Contributor interviennent dans des groupes sélectionnés et ne votent pas sur les décisions à la supermajorité. La page publique actuelle propose les niveaux General et Contributor à 20 000 et 5 000 dollars annuels respectivement, en plus de l’adhésion à la Linux Foundation.

Elle n’explique pas clairement le chemin d’admission ni le prix actuel du statut Steering.

La différence de pouvoir formel compte. Une adhésion large peut apporter expertise et portée d’implémentation, mais la gouvernance n’est pas distribuée de façon égale. Les grandes entreprises capables d’occuper des postes Steering, d’affecter des ingénieurs à de nombreux groupes et de soutenir des programmes de brevets et de produits ont une influence pratique plus forte que les membres Contributor de petite taille. Les non-membres peuvent télécharger la spécification finale, mais ne voient pas tout le processus de rédaction et ne participent pas à égalité.

Les informations internes du projet ne sont pas traitées comme des données corporatives confidentielles ordinaires, mais les membres ne peuvent pas divulguer des matériaux de brouillon tant que le comité compétent n’approuve leur publication. Cela permet à des rivaux de discuter d’idées incomplètes sans envoyer des signaux précoces au marché. Cela signifie aussi que les personnes extérieures ne voient pas les propositions rejetées, les registres de vote, les préoccupations intermédiaires de mise en œuvre ni les négociations ayant produit des fonctions optionnelles.

La spécification finale est ouverte; le chemin jusqu’à elle n’est visible que partiellement.

De quatre groupes de travail à une spécification de 573 pages

La première structure publique de l’UEC, en 2023, se concentrait sur quatre groupes de travail: logiciel, transport, liaison et couche physique. La séquence reflétait l’ambition de bout en bout du projet. L’adhésion n’a pas été ouverte immédiatement comme une liste publique sans restrictions. Plus de 200 organisations avaient manifesté leur intérêt, et le consortium a introduit les membres progressivement tout en exigeant une formation sur les processus et l’antitrust.

La prudence était compréhensible car les entités se concurrencent directement sur plusieurs marchés et discuteraient de manière partagée d’exigences communes de produits et de protocoles.

En décembre 2023, l’UEC annonçait environ 40 entreprises et plus de 300 individus. Elle avait créé un Technical Advisory Committee et élargi la structure à huit groupes de travail. La finalité du TAC était de préserver la cohérence architecturale: un design de transport ne pouvait supposer un comportement de switch, un mécanisme de signalisation ou une API qu’un autre groupe n’avait pas convenu de supporter. En mars 2024, le consortium annonçait 55 entreprises et plus de 750 entités actifs, et publiait une description bien plus claire de l’architecture visée.

La mise à jour de mars introduisait les idées principales apparues ensuite dans la spécification normative: libfabric en API orientée logiciel, packet spraying, ordre flexible, plusieurs modes de livraison, contrôle de congestion côté émetteur et récepteur, ECN, packet trimming, Link Layer Retry, contrôle de flux basé sur des crédits optionnel, sécurité de transport et opérations collectives futures dans le réseau. Elle soulignait aussi que l’UET pouvait fonctionner via des commutateurs Ethernet existants, tandis que des commutateurs améliorés apporteraient des performances supplémentaires.

La portée institutionnelle a grandi en même temps que le travail technique. L’UEC a communiqué 1 193 entités actifs en juillet 2024 et 97 organisations membres en août. Ce sont des chiffres issus du propre consortium, fondés sur des définitions qui ne sont pas totalement publiques. Ils ne doivent pas être additionnés mécaniquement à des annonces ultérieures. En 2025, l’UEC a affirmé que 27 autres entreprises s’étaient intégrées, mais les sorties, fusions et périodes chevauchantes empêchent cette valeur d’établir un total actuel exact. Le site reconnaît qu’il ne présente pas tous les membres.

Le consortium a publié Ultra Ethernet Specification 1.0 le 11 juin 2025. C’était le moment où l’UEC a cessé d’être seulement une feuille de route et est devenu une référence publique de mise en œuvre. La version 1.0.1 est sortie en septembre et a corrigé l’algorithme d’origine de contrôles de congestion par crédits du récepteur et divers problèmes éditoriaux. La version 1.0.2 est apparue en janvier 2026 et a corrigé les algorithmes de gestion de congestion, même si les documents officiels divergent sur la date exacte: 21 ou 28 janvier. L’incohérence doit rester visible plutôt que d’être résolue sans explication.

La version 1.0.3, publiée le 16 juillet 2026, est la référence actuelle au moment de l’analyse. Elle comporte 573 pages et intègre une signalisation de 200 Gb/s par lane ainsi qu’une capacité booléenne de négociation. Les notes de version identifient aussi des corrections obligatoires liées à la livraison de paquets, aux crédits de congestion, au Link Layer Retry et au contrôle des ordered sets de la couche physique, avec des clarifications sur la sécurité de transport, les opérations atomiques et les paquets tronqués.

La différence entre corrections obligatoires et clarifications éditoriales compte: certaines modifications affectent le comportement conforme et donc la pérennité des implémentations.

Le Member Summit 2026 à Denver a montré une deuxième transition. L’ordre du jour s’est concentré sur le déploiement, la productisation, la conformité, la gestion, les performances, le débogage, l’intégration au stockage et les tests de switches et endpoints. L’architecture centrale existe; la crédibilité du projet dépend désormais de plus en plus de la capacité des implémenteurs à construire, qualifier, exploiter et mettre à jour la pile à travers les frontières organisationnelles.

Une architecture répartie sur cinq couches fonctionnelles

La spécification actuelle divise Ultra Ethernet en logiciel, transport, réseau, liaison et couche physique. Cette découpe est utile, mais la valeur du projet réside dans les hypothèses qui relient ces couches.

Dans la partie haute, les frameworks IA, MPI, SHMEM et les bibliothèques d’opérations collectives interagissent via les OpenFabrics Interfaces, en particulier libfabric. Le UET Semantic Services Sublayer traduit les intentions applicatives en transactions de transport. Le Packet Delivery Sublayer décide de la manière dont ces intentions sont fragmentées en paquets, ordonnées, acquittées et récupérées. La gestion de congestion contrôle combien de données entrent dans la fabric et comment le trafic se répartit entre chemins. La sécurité de transport optionnelle protège le trafic endpoint à endpoint.

IPv4 ou IPv6 standards fournissent le forwarding réseau. Ethernet assure la liaison, avec packet trimming, Link Layer Retry, Credit-Based Flow Control et négociation de fonctions optionnelles. La couche physique définit les statistiques et les exigences de signalisation à 100 ou 200 Gb/s par lane.

La structure conserve des parties importantes du réseau existant. L’UEC ne définit pas un remplacement du routage IP. Il attend du multipath à coût équivalent conventionnel et des switches compatibles ECN. Une grande part de l’intelligence reste dans les Fabric Endpoints, qui manipulent l’entropie, suivent l’état du transport, placent les données et répondent aux signaux de congestion. Les switches améliorés peuvent ajouter des fonctions, mais le design ne requiert pas de remplacer toute la fabric avant que le trafic UET puisse passer.

Cela crée à la fois un avantage de migration et une difficulté de classification. Un déploiement peut utiliser des endpoints UET sur Ethernet classique avec ECMP et ECN. Un autre peut ajouter du trimming, une réémission de liaison, des crédits par canal virtuel, une télémétrie plus riche et, à terme, des opérations dans le réseau. Les deux peuvent être qualifiés d’Ultra Ethernet, même si leurs niveaux de performance, de récupération et de complexité opérationnelle diffèrent matériellement.

L’approche à cinq couches complique aussi l’isolation des pannes. Un mauvais résultat peut provenir du mappage applicatif, de la machine à états du endpoint, des paramètres de congestion, de la configuration des files d’attente du switch, du mappage DSCP, de l’optique, du firmware ou du système de sécurité. Faire simplement transiter des paquets ne suffit pas. Le système doit conserver la sémantique et la performance prévues à l’échelle, avec trafic mixte, défaillances et changements de version.

Le contrat logiciel: libfabric au lieu d’une API propriétaire applicative

L’UEC choisit libfabric 2.0 comme API northbound de référence pour les endpoints conformes. Cette décision connecte le projet à un écosystème existant de logiciels HPC et de networking avancé, plutôt qu’à demander à chaque framework d’adopter une nouvelle interface propriétaire. Libfabric couvre déjà les fabrics, domains, endpoints, completion queues, event queues, address vectors, memory regions, messagerie, opérations mémoire distante et atomics. L’UEC mappe et contraint ces concepts pour que les fournisseurs traduisent les appels en comportement UET.

La valeur stratégique tient à la continuité au-dessus du transport. MPI, SHMEM et les bibliothèques de communication d’accélérateurs peuvent utiliser des abstractions familières tandis que le fournisseur situé en dessous change. En principe, une application peut demander une opération sans savoir quelle NIC implémente la livraison ni quel silicium de switch reroute les paquets. C’est l’un des mécanismes centraux par lequel un transport commun peut créer un choix réel entre fournisseurs.

L’abstraction ne garantit pas des implémentations équivalentes. Les fournisseurs peuvent supporter des tailles d’injection différentes, des limites scatter/gather, des quantités de endpoints, des opérations atomiques, des techniques d’enregistrement mémoire, un comportement d’acquittement, des fonctions de sécurité et des offloads matériels différents. Une bibliothèque compilée contre la même API peut toujours rencontrer des limites de performance ou de capacité différentes. L’achat et la qualification des logiciels exigent donc plus qu’une simple mention « libfabric supported ».

La couche logicielle de l’UEC transporte aussi de la sémantique de jobs et d’autorisation. Les systèmes IA et HPC exécutent souvent de nombreux jobs sur une infrastructure partagée, chacun avec ses processus, zones mémoire et limites de sécurité. La spécification doit identifier quel endpoint appartient à quel job, quels buffers peuvent être utilisés, comment associer une opération distante et comment les informations de completion ou d’erreur reviennent au logiciel.

Ces choix déterminent si un réseau rapide est réellement exploitable par le scheduler, le runtime et l’application, plutôt que de n’être impressionnant que dans un benchmark de paquets.

Le projet dépend de l’écosystème OpenFabrics car libfabric n’est pas propriétaire. La relation illustre une caractéristique plus large de l’UEC: l’architecture est assemblée à partir de composants gouvernés en différents lieux. L’UEC peut définir comment mapper son transport vers libfabric, mais doit se coordonner avec les mainteneurs et les utilisateurs de l’API. Il existe des dépendances similaires avec Ethernet dans l’IEEE, les mécanismes réseau IETF, les organisations de stockage et les systèmes d’exploitation fournisseurs.

Fabric Endpoints et profils de charge

Un Fabric Endpoint, ou FEP, est l’endroit logique où se termine l’UET. Il relie une instance de système d’exploitation à un ou plusieurs plans de fabric isolés et peut inclure un fournisseur en espace utilisateur, un pilote noyau, le transport dans la NIC ou l’accélérateur, un système d’enregistrement mémoire, un contexte de sécurité, des completion queues, des address vectors et l’état utilisé pour la livraison de paquets et le contrôle de congestion.

La conception centrée sur le endpoint permet que la majorité des switches reste des dispositifs reconnaissables Ethernet et IP. Le FEP choisit les valeurs d’entropie, maintient l’état des paquets et de la congestion, place des données dans la mémoire autorisée et interprète les acknowledgements, le trimming et d’autres signaux. Il peut réduire la dépendance à une intelligence propriétaire dans le switch, mais concentre la complexité dans le silicium NIC, le firmware, les pilotes et le logiciel.

L’UEC définit trois profils d’implémentation: AI Base, AI Full et HPC. Ce ne sont pas des types de réseaux séparés, mais des paquets qui précisent les fonctions qu’une implémentation doit supporter. AI Base vise les communications IA courantes avec moins de coût et d’état. AI Full ajoute des fonctions telles que les envois différés, exact matching et opérations atomiques de fetching ou de comparaison. Le profil HPC inclut la plupart des capacités d’AI Full, exclut deferrable send et privilégie davantage l’ordre, les messages courts et la sémantique HPC.

Le système de profils tente d’éviter que chaque produit doive implémenter le plus grand ensemble de fonctions. Il reconnaît qu’une NIC IA à grand volume peut prioriser le mouvement collectif de données, tandis qu’un endpoint HPC peut exiger plus d’ordre et d’atomics. Cependant, les profils n’éliminent pas l’optionnalité. Un produit peut implémenter des fonctions optionnelles au sein d’un profil, et deux produits avec la même étiquette peuvent différer en sécurité, améliorations de liaison, capacité et performance.

La terminologie est déjà un signal d’alerte. La spécification de référence 1.0.3 utilise AI Base, AI Full et HPC. Un readme de conformité séparé, de 2025, utilise AI Base, AI Extended et HPC. L’interprétation la mieux étayée est que « AI Full » est le nom en vigueur et que le matériau de conformité est obsolète ou incohérent. Jusqu’à ce que le pack public de tests soit corrigé, fournisseurs et acheteurs doivent identifier à la fois la version et le libellé exact du profil utilisé dans une affirmation.

De l’intention applicative à la livraison de paquets

Dans l’UET, le UET Semantic Services Sublayer transporte l’intention de l’application. Il définit l’identité des messages, l’adressage des buffers, les opérations tagged et untagged, l’accès mémoire à distance, les atomics, le comportement de completion, les identifiants de jobs, l’autorisation des buffers, les réponses et erreurs. Le Packet Delivery Sublayer détermine ensuite comment cette intention devient des paquets et atteint un autre endpoint.

Pour les modes fiables, les endpoints établissent des Packet Delivery Contexts. Un PDC contient des états comme les numéros de séquence, les acknowledgements, la détection de doublons, le mode d’ordre, les informations de congestion, l’état de retour d’adresse et la classe de trafic. Un PDC est associé à un mode de livraison et à une classe de trafic; il peut y en avoir plusieurs entre la même paire de FEP.

Cet état n’est pas un détail secondaire. Les grands clusters peuvent créer d’énormes quantités de relations de communication. Si chaque relation exige beaucoup d’état à la destination, la mémoire et le coût de recherche du endpoint peuvent devenir des limites. L’UEC n’oblige donc pas à placer chaque opération dans un unique modèle de connexion. Il définit quatre services de livraison avec des contrats différents de fiabilité et d’ordre.

Reliable Unordered Delivery, ou RUD, fournit une livraison exactement une fois vers la couche sémantique, mais autorise l’arrivée hors ordre. Il prend en charge le packet spraying sur plusieurs chemins, la retransmission sélective, la suppression des doublons et le placement direct des données. Comme la destination peut placer les données par offset au lieu d’attendre un buffer de réordonnancement du transport, une collective longue peut exploiter plusieurs chemins sans sérialiser tous les paquets derrière une unité absente.

Reliable Ordered Delivery, ou ROD, fournit une livraison exactement une fois et dans l’ordre. Il utilise un chemin et une valeur d’entropie, rejette les paquets hors ordre et emploie une récupération Go-Back-N depuis la première séquence manquante. Il semble moins sophistiqué que le RUD, mais préserve la sémantique nécessaire lorsque l’ordre strict est important. L’UEC considère l’ordre comme une exigence de l’application plutôt que d’imposer que tout transfert paie ce coût.

Reliable Unordered Delivery for Idempotent Operations, ou RUDI, fait une autre concession. Il fournit une livraison au moins une fois et autorise les doublons, réduisant l’état normal de séquence et d’acquittement à la destination. Il peut être utile quand la répétition d’une opération ne change pas le résultat final, par exemple pour certains mouvements de mémoire distante suivis d’une barrière séparée. Il est dangereux s’il est mal utilisé. La couche paquet ne détermine pas qu’une opération est idempotente; le logiciel doit le décider. Utiliser RUDI pour une opération non idempotente peut produire un état applicatif invalide.

Unreliable Unordered Delivery, ou UUD, offre des datagrammes en best effort sans les garanties habituelles de fiabilité ou d’ordre. Il fait partie du même cadre sémantique, mais ne porte pas les mêmes exigences de contrôle de congestion que le RUD et le ROD. Les applications doivent éviter de nuire au trafic contrôlé quand l’UUD partage des files d’attente ou des classes.

Les quatre modes révèlent une philosophie centrale de l’UEC: le réseau doit exposer plusieurs mécanismes pour que le logiciel ajuste le coût du transport à la sémantique de l’opération. Le bénéfice est l’efficacité. Le coût est une surface d’implémentation plus large et plus d’opportunités pour qu’un fournisseur, une application ou un opérateur choisissent une combinaison incompatible.

Packet spraying: utiliser la fabric au lieu de dépendre d’une route chanceuse

Le multipath de coût équivalent conventionnel applique en général un hash au flux complet et le fixe sur un chemin. Dans une grande fabric Clos, cela peut devenir une loterie. Plusieurs gros flux peuvent entrer en collision sur les mêmes liens pendant qu’une capacité équivalente reste inutilisée ailleurs. Un transfert IA long peut être limité pendant toute sa durée par un choix défavorable.

L’UET répond en changeant l’entropie à la granularité paquet. Un émetteur peut utiliser des dizaines ou des centaines de valeurs, permettant aux mécanismes ECMP déjà existants dans les switches de répartir les paquets entre de nombreux chemins. Le Packet Delivery Sublayer fournit des informations de séquence; le Congestion Management Sublayer sélectionne l’entropie ou le chemin; les switches effectuent leur hash normal; et le feedback indique à l’émetteur quels valeurs semblent congestionnées.

Le packet spraying n’est viable que parce que d’autres parties de l’architecture le soutiennent. Les paquets peuvent arriver hors ordre. Le RUD peut placer les données directement sans attendre un réordonnancement complet du transport. La retransmission sélective récupère uniquement ce qui a été perdu. Le feedback de congestion réduit l’usage des chemins problématiques. Le mécanisme n’est donc pas un simple truc d’équilibrage, mais un modèle de transport construit autour de la diversité des chemins.

L’UEC n’exige pas que chaque switch exécute un algorithme propriétaire de routing adaptatif. Les implémentations de base peuvent utiliser le round-robin ou l’entropie pseudoaléatoire sur un ECMP standard. Les endpoints les plus avancés peuvent associer ECN, latence ou trimming à des valeurs précises et éviter les chemins congestionnés. Le routing adaptatif du fournisseur peut coexister avec l’UET, mais n’est pas la seule source d’information de route.

La promesse est une meilleure utilisation de la fabric et une latence de file d’attente plus faible. La question ouverte concerne la cohérence avec laquelle les différents endpoints interprètent le feedback et la manière dont le spraying interagit avec les buffers, la réordonnancement, les pannes et le trafic mixte. Un algorithme efficace en laboratoire homogène peut se comporter différemment dans une grande fabric avec plusieurs générations de switches et des classes de trafic. Les preuves indépendantes et multipartenaires restent limitées.

Trois mécanismes de congestion pour trois goulots d’étranglement distincts

L’UEC ne définit pas un algorithme universel unique de congestion. Il distingue la congestion dans le cœur réseau, l’incast au récepteur et la limitation des buffers dans les endpoints.

Network-signal Congestion Control, ou NSCC, est piloté par la source. L’émetteur maintient une fenêtre de congestion, estime les octets en vol et ajuste la fenêtre via acknowledgements, negative acknowledgements, timeouts, latence et signaux réseau comme l’ECN. Il coordonne le comportement de la fenêtre avec le multipath au niveau paquet. L’UEC soutient qu’une fenêtre cesse naturellement d’autoriser des données quand les paquets ne parviennent pas à sortir du réseau, tandis qu’un contrôleur purement taux pourrait interpréter mal l’absence de feedback.

Ceci est un argument architectural du consortium, pas une preuve indépendante que toutes les implémentations NSCC surclassent DCQCN ou d’autres contrôles de RoCE. Les résultats dépendent des détails d’algorithme, de la signalisation du switch, de la topologie, des modèles de trafic et du choix des paramètres. « Utiliser NSCC » n’est pas une affirmation suffisante de performance.

Receiver-credit Congestion Control, ou RCCC, cible l’incast. Quand de nombreuses sources envoient simultanément vers une destination, le dernier lien peut devenir un goulot d’étranglement même si le cœur du réseau n’est pas congestionné. Le récepteur suit la demande et distribue des crédits entre les émetteurs, régulant l’arrivée agrégée et faisant varier la fenêtre effective de chaque source selon la concurrence. Le RCCC peut fonctionner avec NSCC car la surcharge du récepteur et la congestion du cœur sont des problèmes différents.

Transport Flow Control, ou TFC, utilise également des crédits, mais sert à des services point à point avec buffers limités. Son but est d’éviter directement le débordement du buffer récepteur quand la tolérance aux pertes est faible. Il peut être utilisé avec multipath ou sans. Traiter tous les mécanismes de crédit comme équivalents masquerait les domaines de panne distincts que chacun cherche à maîtriser.

La spécification attend Explicit Congestion Notification sur toute la fabric et inclut des hypothèses opérationnelles sur la signalisation, dont le marquage en dequeue plutôt que de dépendre uniquement de l’enqueue. Les endpoints interprètent l’ECN avec les acknowledgements, la latence et le trimming. La configuration cohérente des switches est donc essentielle. Une implémentation de transport peut être correcte et produire de mauvais résultats dans une fabric mal configurée.

L’historique de maintenance montre la difficulté. La version 1.0.1 a corrigé l’algorithme d’origine du RCCC. La 1.0.2 a corrigé des cas de gestion de congestion. La 1.0.3 a corrigé des interactions entre crédits et Link Layer Retry. Ce sont des signaux normaux d’une spécification vivante, mais aussi la preuve que les crédits, la retransmission et l’état de contrôle des chemins interagissent de manière subtile. Les opérateurs auront besoin de discipline de version et de tests de régression, pas seulement de conformité initiale.

Packet trimming et récupération précise des pertes

Le packet trimming change ce qu’un switch peut faire quand il ne peut pas conserver un paquet complet. Plutôt que d’abandonner la trame sans information, il élimine la majeure partie ou l’intégralité du payload, conserve les entêtes et métadonnées suffisants pour identifier le paquet, le marque comme trimmed et renvoie la notification réduite vers le récepteur. Celui-ci peut alors indiquer à l’émetteur quelles données précises manquent.

Cela est plus informatif qu’un marqueur ECN. L’ECN indique que la congestion a été détectée; le trimming identifie un paquet dont la charge utile n’a pas survécu. Combiné au RUD et à la retransmission sélective, il peut accélérer la récupération sans attendre un timeout ni retransmettre une longue séquence pour une seule perte.

La fonction de switch est optionnelle, mais les endpoints conformes doivent recevoir et interpréter les paquets trimmed selon les exigences applicables. Cette asymétrie permet de déployer l’UET sur des switches conventionnels tout en obtenant une information de perte plus riche dans des fabrics améliorés. Elle crée aussi un problème de migration. Un réseau partiellement amélioré peut devoir limiter le trimming par chemin, profil ou topologie pour garantir que tous les récepteurs le traitent correctement.

L’UEC définit en outre des classes de trafic différenciées pour les requêtes, paquets de contrôle, retransmissions et trafic trimmed. Les opérateurs doivent cartographier de manière cohérente les valeurs DSCP, files de switches, files d’endpoints et niveaux de priorité. La spécification ne fournit pas de système universel unique pour cette gestion. Une attribution erronée peut retirer les ressources du trafic de contrôle, déformer le feedback de congestion ou faire en sorte que les paquets de récupération rivalisent avec le trafic qu’ils doivent réparer.

Le packet trimming illustre le défi d’implémentation plus large. Le protocole peut définir le comportement sur le câble, mais le résultat opérationnel dépend des files d’attente switch, de la logique endpoint, de la télémétrie, de la configuration et de la gestion des pannes. L’interopérabilité est une propriété du système, pas seulement du format du paquet.

Récupération de lien, crédits et négociation de fonctions

Le Link Layer Retry, ou LLR, tente de récupérer des corruptions sur un lien physique avant que le transport de bout en bout ne réagisse. Un pair détecte une interruption de séquence ou une trame endommagée, envoie un negative acknowledgement au niveau de la liaison et fait que l’émetteur répète la trame affectée depuis un buffer local. Si la récupération se termine vite, le transport peut éviter une retransmission plus longue via tout le réseau.

La valeur potentielle augmente avec la vitesse des lanes et la densité de ports. Les erreurs optiques ou électriques ponctuelles peuvent causer des retards disproportionnés sur un job très synchronisé. Cependant, le LLR ajoute de l’état de séquence, des buffers de replay, des messages de contrôle, des fenêtres de rejet et de nouveaux modes d’échec. Il doit aussi coexister avec des mises à jour de crédits et des remises à zéro de lien. La version 1.0.3 a corrigé plusieurs cas limites, y compris une course entre informations de crédits CBFC et LLR.

Le Credit-Based Flow Control, ou CBFC, fonctionne par canal virtuel au niveau liaison. Il indique à l’émetteur la capacité de réception restante et peut offrir un contrôle plus granulaire qu’une pause globale par priorité. L’UEC le présente comme la façon de soutenir un comportement lossless contrôlé sans exiger qu’au-delà du déploiement UET soit sans pertes globalement. Le CBFC est optionnel et l’UET est conçu pour fonctionner sur des réseaux best effort.

Le CBFC ne doit pas être traité comme un autre nom de Priority Flow Control. Les mécanismes diffèrent par signalisation et granularité, même s’ils visent tous deux à éviter les débordements. Le CBFC continue de requérir une configuration cohérente et une livraison correcte de ses propres frames de contrôle. Les crédits locaux peuvent aussi interagir avec les fenêtres bout en bout et les crédits du récepteur, créant plusieurs boucles de contrôle imbriquées.

L’UEC utilise une négociation basée sur LLDP pour détecter les fonctions optionnelles de liaison et empêcher qu’un côté active une capacité que le voisin ne supporte pas. La négociation doit prendre en compte les profils, canaux virtuels, mapping DSCP et priorités, remises à zéro, mises à jour logicielles et combinaisons partielles. La version 1.0.3 a ajouté une capacité booléenne de négociation, renforçant la nécessité d’un accord explicite sur chaque lien.

Ces options offrent une trajectoire d’Ethernet basique vers Ethernet amélioré. Elles créent aussi une matrice qui peut rester cachée dans un langage d’achat. Un switch peut acheminer correctement de l’UET sans trimming, LLR ou CBFC. Un autre peut soutenir ces fonctions seulement sur certaines versions ou modes de port. Un registre de déploiement crédible doit indiquer l’ensemble exact des capacités, pas uniquement le nom du consortium.

Signalisation physique à 100 et 200 gigabits par voie

La couche physique ancre l’UEC dans la feuille de route matérielle. Le travail initial de la 1.0 était rédigé autour d’une signalisation de 100 Gb/s par voie. La version 1.0.3 a ajouté le support pour 200 Gb/s par voie. La modification aligne la spécification avec une génération de liens et de systèmes de plus grande densité, mais il s’agit d’une capacité du document, pas d’une preuve que tous les produits UEC proposent immédiatement cette vitesse.

Le travail PHY de l’UEC traite aussi des statistiques de correction d’erreurs, des proportions de codewords corrigibles et non corrigibles, du contrôle des ordered sets, des rapports de qualité de liaison et de l’interaction entre erreurs physiques et LLR. Ces détails comptent car les décisions de récupération transport dépendent de ce que les couches inférieures peuvent observer et communiquer.

Avec des vitesses de signalisation plus élevées, la frontière entre optique, SerDes, FEC, retry local et récupération transport devient économiquement importante. Un FEC plus fort peut réduire les erreurs résiduelles au prix de latence et d’énergie. Le retry local peut récupérer plus vite, mais exige des buffers et de l’état. La retransmission bout en bout est plus simple à travers le réseau, mais peut coûter plus de temps. L’UEC cherche à définir la coopération entre ces couches au lieu de laisser chaque fournisseur optimiser isolément.

L’ajout de lanes à 200 G montre aussi que l’objectif du consortium évolue. Les implémenteurs de 1.0 doivent conserver la compatibilité tout en planifiant de nouvelles capacités physiques. Les bancs de test, firmware et systèmes de gestion doivent distinguer ce que supporte chaque port. Les acheteurs ne doivent pas déduire la vitesse par voie à partir d’une affirmation générique UEC.

Sécurité de transport de bout en bout optionnelle

Le Transport Security Sublayer, ou TSS, fournit une protection optionnelle endpoint à endpoint. Son modèle de menace ne requiert pas la confiance dans les switches. Il peut offrir confidentialité, intégrité, protection anti-rejeu, isolation de jobs, secure domains, clés de groupe, rotation des clés et intégration avec des racines de confiance matérielles.

Le design utilise des domaines sûrs dont les membres partagent un contexte cryptographique. Les identifiants, numéros d’association, epochs, identité d’origine sécurisée et dérivation de clés visent à évoluer au-delà de l’établissement d’une session indépendante pour chaque paire d’endpoints. C’est nécessaire lorsque les populations d’accélérateurs et l’adhésion aux jobs changent rapidement.

Le protocole n’est qu’une partie du système de sécurité. Un opérateur de production doit maintenir des autorités de clés, certificats ou autres racines de confiance, des services d’adhésion des jobs, la distribution et révocation, des transitions d’epoch, la récupération d’endpoints, la cryptographie matérielle et la télémétrie de sécurité. Le réseau peut s’adapter à un profil sans activer toutes les fonctions optionnelles du TSS. « UEC compliant » ne signifie pas automatiquement « chiffrement ».

L’optionnalité reflète des hypothèses de déploiement différentes. Une fabric dédiée et physiquement contrôlée peut prioriser la performance et faire confiance à des contrôles environnementaux. Un cloud multi-tenant peut nécessiter un isolement fort et une protection cryptographique. Les profils et les achats doivent rendre visible cette différence.

Le risque le plus sérieux n’est pas seulement la surcharge du chiffrement. C’est l’échec du cycle de vie à grande échelle: adhésion obsolète, révocation retardée, epochs incohérents, récupération après échec d’un endpoint ou impossibilité de démontrer quel job peut accéder à quelle mémoire. Ces questions relient la sécurité de transport aux systèmes d’orchestration et d’identité extérieurs à la spécification centrale.

Que signifie actuellement « UEC compliant »

L’UEC a commencé à publier des matériaux de conformité avec la version 1.0, mais le système public n’est pas un régime mature de certification indépendante. Le pack disponible est conçu principalement pour l’auto-attestation de l’implémenteur. Les matrices relient exigences et profils, et le guide de testbed décrit des configurations d’endpoints et switches recommandées. Aucune base publique complète n’a été identifiée dans laquelle une autorité indépendante enregistre des produits ayant approuvé ou échoué à l’ensemble du programme UEC.

La distinction est essentielle car circulent des affirmations différentes. Un produit peut être conçu autour de capacités UEC en développement. Il peut implémenter des fonctions sélectionnées du fil de données. Il peut soutenir un profil, ou une partie, dans une version précise. Un fournisseur peut revendiquer une conformité complète des fonctions. Un laboratoire peut générer du trafic UET au travers d’un switch. Aucune de ces déclarations n’équivaut automatiquement à une certification indépendante, bout en bout et multipartenaires.

Les recommandations publiques de testbed sont utiles, mais délibérément limitées. Elles fournissent des topologies et des vérifications de bonnes pratiques plutôt qu’une qualification complète du système. Elles excluent ou ne couvrent pas totalement l’interopérabilité plus large, la performance, le stress, l’échelle et le cycle de vie de l’API. Elles ne démontrent pas un comportement avec trafic UET et RoCE mixte, des mises à jour partielles, des pannes répétées, de grands domaines de clés ni les plus grandes populations.

L’incohérence entre AI Full et AI Extended montre aussi pourquoi la conformité exige un versionnage discipliné. Un acheteur doit demander quelle spécification, quel niveau de correction, quel profil, quelles fonctions optionnelles et quelles fonctions de sécurité couvrent une affirmation. La réponse doit identifier si les preuves proviennent de tests internes, d’une démonstration bilatérale, d’un événement du consortium ou d’un laboratoire indépendant.

Une phase suivante crédible inclurait des définitions publiques de test liées à des versions précises, des plugfests multipartenaires, des résultats gérés de manière indépendante — y compris des résultats négatifs — et un registre distinguant endpoints, switches, logiciels et systèmes complets. Jusqu’à ce stade, « UEC compliant » reste une question de départ, pas une garantie complète.

Un document ouvert avec obligations de brevets RAND

Ultra Ethernet Specification 1.0.3 peut être téléchargée publiquement et est distribuée sous Creative Commons Attribution-NoDerivatives 4.0. La licence autorise la redistribution avec attribution, mais interdit la distribution de versions modifiées. Plus important encore, l’accès par copyright et l’accès aux brevets sont des questions distinctes.

Les chartes documentées des groupes de travail utilisent généralement un modèle traditionnel de développement de spécifications avec des licences de brevets à des conditions raisonnables et non discriminatoires. RAND ne signifie pas nécessairement royaltiés libres. Elle ne garantit pas un prix universel, n’élimine pas la négociation et ne prévient pas les contestations sur la validité, l’essentialité, la portée géographique ou les conditions défensives. La position commerciale dépend de chaque brevet déclaré, de l’engagement du membre et de toute licence bilatérale.

L’UEC maintient un registre public des déclarations Necessary Claims. Au moment de l’analyse, des déclarations associées à Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell et d’autres étaient visibles, y compris des éléments liés à des travaux futurs de 1.1. Le registre augmente la transparence en montrant que les implémenteurs peuvent devoir analyser la propriété intellectuelle avant de construire ou vendre un produit.

Le consortium déclare explicitement qu’il ne détermine pas si un brevet est valide, réellement essentiel, enfreint ou disponible à un prix précis. Il ne publie pas de licence commune non plus. Les petits implémenteurs peuvent encourir des coûts juridiques et transactionnels que les grands membres absorbent plus facilement. Un document disponible publiquement peut malgré tout produire un écosystème commercial concentré si le débogage des brevets, le coût du silicium et les frais de tests sont élevés.

Le cadre de propriété intellectuelle façonne aussi les incitations de gouvernance. Les entreprises apportent de la technologie en partie pour créer un marché large pour leurs produits et en partie pour s’assurer que leurs capacités existantes apparaissent dans le design commun. Les déclarations de brevets protègent contre les surprises si elles sont précoces et suffisamment claires. Elles n’éliminent pas la possibilité que les licences deviennent une barrière après l’adoption de l’architecture.

La description fidèle est « publié ouvertement et multipartenaires, avec engagements RAND », pas « universellement sans redevances ». Les équipes d’achat ont besoin à la fois du profil technique et du chemin de licence.

La première vague de produits et de tests

La preuve d’implémentation est devenue visible autour de la publication de la 1.0, mais les exemples sont à des stades de maturité différents.

AMD a commercialisé sa NIC IA Pollara 400 en avril 2025 et l’a décrite comme conçue autour de capacités UEC en développement. Pollara est une plateforme endpoint programmable et un signal important que le transport est passé au matériel commercial. La rédaction compte: se concevoir pour des fonctions en évolution ne revient pas à une certification indépendante contre toutes les exigences finales de la version 1.0.3.

Broadcom a annoncé Tomahawk 6 en juin 2025 comme ASIC de commutation de 102,4 térabits par seconde avec des fonctions pertinentes pour les fabrics UEC. En octobre, elle a annoncé la NIC Thor Ultra 800G et affirmé que la conception fournissait une conformité complète des fonctions UEC. C’est une déclaration significative du fournisseur, mais la preuve publique ne la transforme pas en certificat indépendant du consortium. Le sampling, la maturité du logiciel et le support exact des profils doivent être identifiés séparément.

Nokia et Keysight ont annoncé en octobre 2025 une démonstration de bout en bout de trafic UET via les familles de switches Nokia 7220 et 7250 à 800 Gigabit Ethernet. Keysight a fourni génération et validation du trafic. L’essai montre que l’UET peut traverser des systèmes commerciaux et qu’il se développe un support dans les équipements de test. Il n’établit pas un profil complet d’endpoints multipartenaires, d’échelle en production ni de certification indépendante de chaque fonction optionnelle.

D’autres membres ont décrit switches, systèmes, logiciels ou plans de test capables d’UEC, et le sommet 2026 s’est concentré sur la productisation. Les preuves soutiennent une transition vers l’implémentation. Elles ne permettent pas encore de compter précisément des NIC UET en volume, des switches certifiés, des régions cloud déployées ou des fabrics complètes.

La manière la plus utile de lire la vague est de la considérer comme une chaîne de preuve. Une spécification publique permet de concevoir. Les annonces de silicium et de NIC démontrent l’investissement. Les démonstrations de trafic montrent une partie de l’interopérabilité. Les matrices de conformité organisent les exigences. Les rapports de déploiement des opérateurs démontreraient la valeur opérationnelle. Les plugfests indépendants et les résultats de production donneraient la crédibilité la plus large qui manque encore.

RoCE, InfiniBand, Slingshot et UALink

L’UEC entre sur un marché avec des alternatives matures et des technologies adjacentes. Son argument stratégique n’est pas que l’Ethernet n’ait jamais transporté de RDMA ni que les fabrics spécialisées ne fonctionnent pas. C’est que la vitesse et la synchronisation des charges IA actuelles justifient une nouvelle architecture Ethernet de bout en bout avec livraison, usage des chemins et contrôle de congestion plus flexibles.

RoCEv2 est le prédécesseur direct et une technologie installée importante. Il place le trafic RDMA sur Ethernet routable et dispose d’un large soutien applicatif et produit. L’UEC critique les déploiements habituels de RoCE pour fixer le flux complet à un chemin, utiliser une récupération Go-Back-N et une réordonnancement au récepteur, exiger un tuning difficile de DCQCN, dépendre de Priority Flow Control dans de nombreux designs et mal gérer l’incast ou les rafales collectives. Ce sont des positions techniques de l’UEC, pas des preuves que tous les réseaux RoCE performent mal.

La comparaison est dynamique. Les fournisseurs peuvent ajouter un routing adaptatif, du packet spraying, des algorithmes de congestion meilleurs ou d’autres fonctions proches de UEC dans des NIC programmables, tout en conservant la compatibilité RoCE. La communication d’AMD sur Pollara, par exemple, présente RoCEv2 et UEC RDMA comme options sur un même matériel programmable. L’UEC peut concurrencer RoCE comme transport complet et en même temps influencer l’évolution des produits RoCE futurs.

InfiniBand reste l’alternative principale d’fabric spécialisée. Elle offre un écosystème intégré de RDMA, congestion, fiabilité de liaison et gestion avec une longue expérience HPC. Le travail 2.0 de l’InfiniBand Trade Association inclut un support physique XDR à 200 Gb/s par voie et une télémétrie actualisée. La principale différenciation de l’UEC ne consiste pas à dire qu’InfiniBand manque de performance, mais à permettre d’obtenir un comportement IA et HPC via une chaîne Ethernet plus large, le routage IP standard et un choix multipartenaires plus important.

HPE Slingshot occupe une position intermédiaire. C’est une fabric HPC commerciale compatible avec Ethernet, avec adaptive routing et gestion de congestion, et elle a fourni des antécédents techniques importants à l’UET. Elle montre qu’on peut construire un comportement spécialisé sur Ethernet, mais aussi la différence entre une plateforme commerciale contrôlée et une spécification destinée à toute l’industrie.

UALink est généralement complémentaire, pas un substitut direct. Sa spécification publique 200G actuelle vise la connectivité scale-up de faible latence entre accélérateurs dans un pod et décrit des systèmes jusqu’à 1 024 accélérateurs. L’UEC 1.0 est principalement une fabric scale-out qui connecte les nœuds par des switches. Un centre de données peut utiliser une liaison scale-up à l’intérieur du pod et de l’UEC entre pods ou nœuds. Les travaux futurs de l’UEC sur un transport scale-up optimisé et des collectives dans le réseau peuvent rapprocher les limites et produire une convergence ou une concurrence.

NVIDIA Spectrum-X et les fabrics propriétaires d’accélérateurs apportent une autre comparaison. Une stack fortement intégrée peut optimiser rapidement matériel, logiciel et support, mais elle accroît la dépendance à un écosystème. L’UEC remplace une partie de cette intégration par la promesse d’interfaces communes et d’un choix de fournisseurs. Que l’échange en vaille la peine dépendra de la performance, du support, des conditions de brevets, de l’interopérabilité et du coût opérationnel total, pas du mot « ouvert » comme étiquette abstraite.

Le problème opérationnel est plus vaste que le protocole

Une spécification de 573 pages peut définir de nombreuses exigences, mais une fabric de production a toujours besoin d’un modèle opérationnel. L’UEC 1.0 laisse des éléments importants de gestion en dehors ou autour du noyau normatif. Les opérateurs doivent configurer profils, classes de trafic, seuils ECN, ensembles d’entropie, fonctions de liaison optionnelles, clés, firmware, télémétrie et politiques de pannes de manière cohérente entre endpoints et switches.

Le trafic mixte rend le problème plus difficile. Une fabric peut transporter UET, RoCE, TCP, stockage, gestion et services UET ordonnés et non ordonnés. La répartition des files et l’équité entre ces classes ne se résolvent pas uniquement parce que chaque protocole est correctement implémenté. Un algorithme de congestion peut bien fonctionner seul et mal en concurrence avec un autre contrôleur qui utilise un feedback et des hypothèses différents.

La complexité du endpoint est un autre risque structurel. L’UET place multiplexage de chemin, placement direct, retransmission sélective, plusieurs modes de livraison, contrôle par fenêtres et crédits, réception de trimming, sécurité et beaucoup d’état dans le FEP. Cela peut augmenter la surface du die NIC, la taille du firmware, l’effort de vérification, l’énergie et le nombre de conditions de panne à diagnostiquer. L’intelligence au niveau du endpoint rend possible une chaîne multipartenaires, mais peut aussi concentrer la complexité d’implémentation sur le composant que chaque serveur doit acheter.

Les fonctions optionnelles créent à la fois une différenciation et une fragmentation. Un fournisseur peut optimiser un endpoint AI Base de base pour ECMP et ECN conventionnels. Un autre peut soutenir AI Full, TSS, trimming, LLR et CBFC. Les deux appartiennent à l’écosystème UEC, mais les opérateurs ne peuvent pas supposer la même sémantique, performance ou sécurité. Les matrices de conformité doivent devenir des matrices opérationnelles de capacité.

La maintenance des versions sera continue. Les corrections de 1.0.1 à 1.0.3 ont affecté la congestion, les crédits, le retry et le comportement des paquets. Un grand cluster peut contenir plusieurs versions firmware NIC, releases switches et outils de test. Mettre à jour une couche sans coordonner les autres peut exposer précisément le couplage transversal que le consortium tente d’éviter.

Les alliances externes de l’UEC sont donc centrales et non cérémonielles. Open Compute Project relie le transport à des systèmes et matériels ouverts. OpenFabrics Alliance et la communauté libfabric relient les applications. IEEE 802.3 fournit le travail formel d’Ethernet. SNIA et NVM Express apportent les exigences de stockage et de gestion. Les technologies IETF fournissent IP, ECN et mécanismes liés. Ces organisations ont des processus de décision et des feuilles de route différents; la liaison réduit la duplication, mais ne garantit pas une adoption simultanée.

La preuve opérationnelle finale est une infrastructure en service. Un document peut spécifier un comportement, un fournisseur peut annoncer un produit et un consortium peut organiser un sommet. Rien ne remplace un cluster où endpoints et switches indépendants complètent des travaux réels sous congestion, pannes et mises à jour, et où les opérateurs peuvent expliquer ce qui s’est produit.

La pertinence actuelle: de la victoire de la spécification à la crédibilité d’implémentation

En juillet 2026, l’UEC avait obtenu plusieurs choses incertaines au lancement. Elle a formé une coalition large, produit une architecture intégrée de cinq couches, publié une spécification 1.0 complète, maintenu cette référence par des releases de correction, ajouté 200 G par voie, divulgué des déclarations de brevets et attiré des annonces de produits et de tests. Le projet est actif et son agenda a clairement glissé vers la mise en œuvre.

Ce progrès rend les incertitudes suivantes plus importantes, pas moins. L’adhésion actuelle exacte et le roster Steering ne sont pas publiés dans un registre d’autorité unique. Les pages publiques de membres et la charte décrivent l’accès de manière différente. La direction formelle du TAC n’est pas entièrement alignée avec les rôles du sommet. La date de 1.0.2 est contradictoire entre documents officiels. Le pack de conformité utilise une terminologie de profil obsolète. Aucun problème ne détruit l’architecture, mais chacun signale le contrôle documentaire et la transparence dans un projet où les versions précises importent.

Les lacunes les plus importantes touchent l’adoption. L’UEC ne publie pas de recensement de déploiements, pas de registre de produits vérifiés de manière indépendante, pas de budget propre ni de comptes audités. Il n’existe pas de preuve publique d’un réseau UEC 1.0 totalement interopérable aux objectifs maximums d’échelle du consortium. Les démonstrations et affirmations de fournisseurs sont utiles, mais proviennent de parties commercialement intéressées. Les comparaisons neutres avec RoCE actuel, InfiniBand et les plates-formes Ethernet intégrées restent limitées.

La question reste ouverte et l’opportunité demeure importante. L’Ethernet est le dénominateur commun des centres de données, et le marché des infrastructures IA est suffisamment vaste pour soutenir de nouvelles générations de NIC, switches, optique et logiciels. Les opérateurs ont de forts incitatifs pour éviter la dépendance à un seul fournisseur et améliorer l’utilisation des accélérateurs. Un stack commun peut transformer ces incitatifs en pouvoir d’achat.

Le risque est que « Ultra Ethernet » devienne un parapluie de sous-ensembles incompatibles. Si le forwarding de base fonctionne mais que profils, congestion, sécurité et gestion divergent, la marque peut se diffuser plus vite que l’interopérabilité. Si les licences RAND s’avèrent coûteuses ou incertaines, le jeu de fournisseurs peut se réduire. Si les produits RoCE intègrent les idées les plus attractives sans exiger un nouveau transport, l’UEC peut influencer le marché sans devenir l’étiquette dominante.

La question décisive n’est plus de savoir si le consortium peut publier une spécification sophistiquée; il l’a déjà fait. La question est de savoir si des organisations indépendantes peuvent implémenter les mêmes contrats, licencier la technologie nécessaire, exploiter la fabric à grande échelle et préserver la compatibilité pendant que la spécification évolue. L’UEC ne deviendra une infrastructure que si ces affirmations survivent à l’épreuve de systèmes en production.