Ultra Ethernet entre dans le nœud d'IA
L'Ultra Ethernet Consortium a publié la version 1.1 de sa spécification le 12 octobre. Cette évolution ne concerne plus seulement les réseaux scale-out reliant les nœuds d'un cluster : elle vise aussi les réseaux scale-up, c'est-à-dire les interconnexions à courte distance entre les accélérateurs d'un même nœud, avec souvent un seul niveau de commutation, voire aucun commutateur.
Créé en 2023, le consortium cherche à adapter Ethernet aux besoins croissants de l'intelligence artificielle et du calcul haute performance. Publiée en juin 2025, la spécification 1.0 définissait un protocole de transport, des mécanismes de contrôle de congestion et une approche moderne de l'accès direct à la mémoire à distance (RDMA).
La version 1.1 complète cette base avec :
Un profil Unified Local destiné aux interconnexions locales entre accélérateurs.
Un Unified Forwarding Header (UFH) et une réduction facultative des temps d'inactivité pour diminuer la surcharge par paquet.
Des opérations collectives dans le réseau (INC) permettant aux commutateurs d'exécuter des réductions telles qu'allreduce pour un groupe de terminaux.
Le mécanisme Congestion Signaling (CSIG), qui transmet des mesures de congestion d'un commutateur constituant le goulot d'étranglement vers l'émetteur.
La Programmable Congestion Management (PCM), grâce à laquelle les algorithmes de contrôle de congestion et d'équilibrage de charge sont chargés sous forme de programmes sur les terminaux.
Des extensions exposant le transport Ultra Ethernet aux applications par l'intermédiaire de l'interface de programmation RDMA verbs.
« A big new focus of UEC 1.1 is extending support to scale-up networks », a expliqué Tom Emmons, président du comité consultatif technique de l'UEC, à Network World.
Pourquoi chaque octet compte dans un réseau scale-up
Un réseau scale-out relie les différents nœuds d'un cluster. Un réseau scale-up transporte au contraire les échanges entre les accélérateurs d'un même nœud. Ces flux se composent de petits messages émis à une cadence très élevée : la surcharge de chaque paquet devient donc déterminante.
D'après les éléments rapportés par Network World, une trame Ethernet standard transportant des données IPv4 et UDP comporte 66 octets de surcharge avant même l'ajout d'un en-tête de transport ou de la charge utile. UEC 1.1 s'attaque à ce problème au moyen de trois mécanismes complémentaires.
Le profil Unified Local
Unified Local propose un transport simplifié pour les réseaux locaux. Les requêtes circulant dans une direction peuvent également transporter les accusés de réception du trafic opposé, ce qui peut réduire l'état à conserver et le nombre de paquets d'acquittement distincts.
Ce profil est conçu pour un fabric sans perte reposant sur le Priority Flow Control (PFC) ou le Credit-Based Flow Control (CBFC).
L'Unified Forwarding Header
Facultatif, l'UFH remplace l'en-tête IP séparé et place les informations d'adressage dans l'en-tête MAC Ethernet existant de 12 octets. Il peut partager une liaison avec des trames Ethernet standard. À titre de comparaison, un en-tête IPv4 standard occupe 20 octets.
La réduction du temps entre les trames
Une autre fonction facultative réduit l'espacement obligatoire entre les trames. L'espacement minimal annoncé passe d'une moyenne de 84 octets à une valeur constante de 80 octets.
L'UEC collabore par ailleurs avec l'Open Compute Project afin d'intégrer ces technologies scale-up dans une prochaine version de la spécification Ethernet for Scale-up Networking.
Des signaux plus riches et des algorithmes adaptables
La congestion apparaît lorsque plusieurs émetteurs ciblent la même liaison et que les files d'attente des commutateurs commencent à se remplir. L'émetteur a alors besoin d'un signal indiquant le problème, mais aussi d'un algorithme capable de décider dans quelle mesure ralentir la transmission.
Un marquage classique de notification explicite de congestion ne fournit qu'un bit d'information. Il indique qu'une file d'attente se remplit quelque part sur le trajet, sans préciser où ni mesurer l'ampleur de la situation. Autre limite : l'algorithme de réaction peut être figé dans la carte réseau, ce qui complique son adaptation à l'évolution des charges de travail d'IA.
UEC 1.1 introduit deux mécanismes pour répondre à ces contraintes :
CSIG ajoute aux paquets une balise de 4 ou 8 octets que les commutateurs traversés peuvent mettre à jour avec des informations de congestion.
PCM permet d'exécuter les algorithmes de contrôle de congestion et d'équilibrage sous forme de programmes chargés sur le terminal, plutôt que de les figer définitivement dans la carte réseau.
Ces deux évolutions doivent fournir des informations plus utiles aux terminaux et rendre le comportement de gestion du trafic plus adaptable.
La préparation opérationnelle dépend de l'inventaire multiconstructeur
La publication d'une spécification ne signifie pas que chaque commutateur, carte réseau, nœud d'accélération ou firmware déployé prend immédiatement en charge toutes ses fonctions. Pour évaluer Ultra Ethernet 1.1, les exploitants doivent donc répondre à plusieurs questions distinctes :
Quels équipements disposent des capacités matérielles nécessaires ?
Quelle version de firmware ou de logiciel active chaque fonction ?
Quelles fonctions sont facultatives et quelles combinaisons ont été validées ensemble ?
Où faut-il configurer PFC ou CBFC pour utiliser le profil Unified Local ?
Un chemin multiconstructeur peut-il assurer un comportement cohérent d'un terminal à l'autre ?
Quelles configurations ont été modifiées pendant les essais et peuvent-elles être restaurées sans risque ?
Cette vérification est particulièrement importante pour les fonctions qui impliquent à la fois les terminaux et les commutateurs. CSIG dépend du traitement des paquets tout au long du chemin, tandis que PCM modifie la manière dont les terminaux réagissent aux informations reçues. Les opérations collectives déplacent également de nouvelles fonctions dans la couche de commutation.
L'état de préparation doit donc être évalué à l'échelle du fabric, et non en examinant un seul équipement isolé.
La place de ConnectMyAssets
ConnectMyAssets fournit une plateforme sur site et indépendante des constructeurs pour gérer les données opérationnelles nécessaires à la transition d'un fabric multiconstructeur. La plateforme n'ajoute pas la compatibilité Ultra Ethernet au matériel ; elle aide les équipes à établir précisément quels équipements, logiciels et paramètres sont réellement déployés.
La Dynamic CMDB permet de tenir un inventaire des commutateurs, adaptateurs, nœuds, modèles, systèmes d'exploitation et firmwares, puis d'y consigner les capacités Ultra Ethernet et leur statut de validation.
Le module Backup & History conserve les versions de configuration et permet une restauration en un clic, notamment lors d'essais portant sur le contrôle de flux, les files d'attente ou d'autres paramètres du fabric.
Le Compliance Engine peut contrôler les exigences de configuration approuvées et conserver les preuves associées aux politiques internes ou à des référentiels comme NIS2, ISO 27001, PCI, CISA et NIST.
Le suivi des CVE par équipement rattache les vulnérabilités aux infrastructures qui participent au fabric d'IA. Cette information est distincte de la compatibilité avec le protocole, mais elle reste indispensable pour déterminer si un firmware est acceptable en exploitation.
Le suivi de fin de vie identifie les équipements qui approchent de la fin du support constructeur. Les équipes peuvent ainsi distinguer ceux qui pourraient recevoir de nouvelles fonctions de ceux qui devront probablement être remplacés.
Le module Automation & ZTP peut soutenir des déploiements contrôlés et reproductibles après validation des configurations et des combinaisons de firmwares.
La topologie apporte le contexte de chemin nécessaire pour déterminer si un flux entre accélérateurs traverse des équipements dont les capacités ou les versions logicielles diffèrent.
Pour préparer Ultra Ethernet, l'objectif concret consiste à obtenir un état de préparation traçable pour chaque actif : capacité matérielle, firmware installé, configuration active, résultat de validation, rôle topologique et point de restauration.
Les informations à suivre dès maintenant
À mesure que les implémentations apparaîtront, les équipes réseau auront intérêt à créer un registre détaillé des capacités plutôt qu'à s'appuyer sur une simple étiquette « compatible UEC ». Elles devraient au minimum suivre :
La prise en charge distincte d'Unified Local, UFH, de la réduction du temps d'inactivité, d'INC, de CSIG et de PCM.
La version de firmware ou de logiciel associée à chaque fonction.
Les dépendances requises côté terminaux, commutateurs et contrôle de flux.
Les résultats de validation de chaque combinaison multiconstructeur.
Les configurations de référence avant et après les essais du fabric.
Les vulnérabilités et dates de fin de support des équipements concernés.
Ultra Ethernet 1.1 élargit le rôle d'Ethernet dans les infrastructures d'IA. Le véritable défi opérationnel consistera toutefois à démontrer que tous les composants d'un fabric réel sont alignés. La qualité de l'inventaire, l'historique des configurations et une validation tenant compte de la topologie seront aussi importants que la spécification elle-même.
Source : Network World
