Ultra Ethernet Consortium: Reconstruir Ethernet para la IA a gran escala

Resumen

• El Ultra Ethernet Consortium es un proyecto de la Joint Development Foundation lanzado el 19 de julio de 2023 por AMD, Arista Networks, Broadcom, Cisco, Eviden/Atos, Hewlett Packard Enterprise, Intel, Meta y Microsoft. Se trata de un consorcio industrial para el desarrollo de especificaciones, no una empresa tradicional ni un operador de red.
• El alcance de UEC va mucho más allá de un simple enlace Ethernet más rápido o un reemplazo de RoCE. La especificación 1.0.3, de 573 páginas, cubre las capas de software, transporte, red, enlace y física, así como las tareas de gestión, almacenamiento, pruebas y conformidad que rodean al núcleo.
• El transporte Ultra Ethernet combina múltiples modos de entrega, pulverización de paquetes a nivel de paquete, retransmisión selectiva, control de congestión del lado del emisor y del receptor, ECN, recorte opcional de paquetes, reintento local opcional en el enlace, control de flujo opcional basado en créditos y seguridad de transporte opcional de extremo a extremo.
• Los productos y demostraciones de AMD, Broadcom, Nokia y Keysight indican que la implementación ha comenzado, pero la conformidad pública sigue basándose principalmente en la autodeclaración del implementador, y no se ha publicado un registro completo de certificaciones independientes ni un número de despliegues a gran escala.
• La oportunidad estratégica de UEC se basa en la base instalada de Ethernet y su cadena de suministro con múltiples proveedores. Los principales riesgos son la complejidad de los endpoints, la fragmentación debida a las características opcionales, los compromisos de patentes RAND, la inmadurez de la gestión y las pruebas, y la brecha entre la publicación de la especificación y la demostración de interoperabilidad en producción.

Por qué la inteligencia artificial convierte la red en parte del ordenador

El Ultra Ethernet Consortium surgió como respuesta a un cambio en la economía de la computación. En una red empresarial habitual, se espera que el tejido de red transporte un gran número de flujos independientes con un rendimiento y una disponibilidad aceptables. En un sistema de entrenamiento de IA a gran escala o en una máquina de computación de alto rendimiento (HPC), la red pasa a formar parte de un único cálculo síncrono. Miles de aceleradores pueden intercambiar parámetros de modelos, gradientes o datos científicos mediante operaciones colectivas.

La siguiente fase puede no comenzar hasta que el participante más lento haya recibido la información necesaria. Por lo tanto, un pequeño desequilibrio entre rutas, una situación de congestión o un solo paquete perdido pueden dejar costosos procesadores en espera, aunque la utilización media del tejido parezca buena.

Esto cambia lo que los operadores intentan optimizar. La capacidad total sigue siendo importante, pero no es suficiente. También importan la duración de la tarea, la latencia de cola, las ráfagas de entrada (incast), la recuperación de pérdidas, la distribución del tráfico en rutas paralelas y la cantidad de estado que deben mantener los endpoints. Una red que entrega la mayoría de los paquetes rápidamente pero retrasa un pequeño porcentaje puede detener una operación colectiva completa. Un método de retransmisión aceptable para el tráfico tradicional puede ser demasiado lento si se pierde un solo paquete de un mensaje largo.

Un flujo anclado a una única ruta de coste igual puede ver su rendimiento degradado mientras hay capacidad disponible en otras partes de la topología.

La premisa fundacional de UEC era que estos problemas no se resuelven con una sola característica nueva en el conmutador o un único algoritmo de congestión modificado. El camino de la comunicación comienza por encima de la red, en las bibliotecas de software y la semántica de las aplicaciones, y continúa a través del registro de memoria, las operaciones remotas, el estado del transporte, la entrega de paquetes, el control de congestión, el enrutamiento IP, los enlaces Ethernet, la óptica y la señalización física.

Si estas capas se diseñan de forma aislada, una optimización en un punto puede trasladar el cuello de botella o crear supuestos incompatibles en otro.

La respuesta de UEC es una arquitectura coordinada. Mantiene Ethernet e IP porque los operadores los conocen y porque ha crecido una enorme cadena de suministro en torno a conmutadores, óptica, cableado, sistemas operativos de red, telemetría y gestión. Al mismo tiempo, modifica o amplía las partes que el consorcio considera inadecuadas para las cargas de trabajo masivas de IA y HPC. El resultado no es "Ethernet de siempre con un nuevo logotipo", sino un intento de que una red conocida soporte un transporte especializado cuyo comportamiento se define desde la interfaz de software hasta la velocidad del camino físico.

Esto explica por qué UEC es relevante para la infraestructura digital. El proyecto no posee aceleradores, fábricas, centros de datos ni regiones en la nube. Pero define contratos que las empresas miembro y otros implementadores pueden incorporar en NICs, ASICs de conmutación, sistemas, controladores, bibliotecas y equipos de prueba. Su impacto solo se materializará cuando estos productos independientes intercambien tráfico correctamente en condiciones de fallo, congestión, actualización y mezcla de proveedores.

Qué es UEC y qué no es

Ultra Ethernet Consortium es el nombre público de un proyecto formal cuyo nombre legal completo es Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. La estructura de "Series" sitúa el proyecto dentro de la Joint Development Foundation y de la familia más amplia de la Linux Foundation. Proporciona a los participantes un marco legal preexistente para la afiliación, la gobernanza, la propiedad intelectual, la financiación y las relaciones externas, sin obligarles a crear una nueva empresa independiente.

Esta estructura es relevante porque a veces se describe a UEC de forma imprecisa como una empresa, una alianza o un organismo de normalización. No es una empresa comercial con accionistas, capital, valoración y cuentas independientes. No vende productos Ethernet, no opera una red pública ni posee el hardware que promocionan sus miembros. Es un consorcio de desarrollo de especificaciones dentro de un marco legal y de propiedad intelectual. El propósito de sus documentos públicos es convertirse en contratos de implementación entre múltiples empresas.

Además, UEC no es lo mismo que Ultra Ethernet Transport. UET es la arquitectura de transporte en el corazón de la especificación, pero el trabajo del consorcio es más amplio. Incluye la alineación del software con libfabric, la semántica de paquetes y mensajes, los supuestos de red, las opciones de la capa de enlace, los requisitos de la capa física, la gestión, la alineación con el almacenamiento, el rendimiento y la depuración, y la conformidad y las pruebas. Reducir el proyecto a un "nuevo protocolo RDMA" oculta el diseño transversal que lo hace ambicioso y difícil.

UEC tampoco es un grupo de trabajo IEEE 802.3. Ese grupo desarrolla los estándares básicos de Ethernet en las capas MAC y física mediante su propio proceso formal. UEC se apoya en ese ecosistema y mantiene una relación de coordinación, pero no lo sustituye. Lo mismo se aplica a los mecanismos de la IETF que utiliza UET, como IPv4, IPv6 y Explicit Congestion Notification; al ecosistema OpenFabrics que mantiene libfabric; y a los organismos de almacenamiento, hardware abierto e interconexiones de aceleradores.

El sitio web del proyecto ha utilizado un lenguaje que sugiere el estatus de organización internacional de normalización. La descripción más segura y respaldada por la evidencia es que UEC es una organización internacional de desarrollo de especificaciones dentro del marco JDF. No hay evidencia de que forme parte de la International Organization for Standardization, de que sus documentos sean normas ISO o de que tenga un número de estándar ISO. La distinción no es solo terminológica; define la fuente de autoridad, el modo de participación y las obligaciones legales que pueden enfrentar los implementadores.

Por tanto, UEC debe evaluarse según la función que realmente desempeña. Coordina a competidores y operadores en torno a un diseño técnico común, publica especificaciones, gestiona grupos de trabajo y compromisos de patentes declarados, y desarrolla materiales de conformidad y relaciones con organismos adyacentes. Pero no puede, por sí solo, hacer que un producto sea interoperable ni obligar al mercado a adoptar su arquitectura.

La coalición fundadora de nueve empresas

El consorcio se anunció el 19 de julio de 2023 por nueve organizaciones que ocupan diferentes niveles de la cadena de suministro de IA y HPC: AMD, Arista Networks, Broadcom, Cisco, Eviden (entonces vinculada a Atos), Hewlett Packard Enterprise, Intel, Meta y Microsoft. Esta diversidad fue estratégica desde el principio. Un transporte diseñado solo por fabricantes de conmutadores podría ignorar las limitaciones de las aplicaciones y los endpoints. Un diseño liderado por fabricantes de aceleradores podría optimizarse en torno a un único ecosistema de hardware.

Un proyecto dirigido solo por empresas de la nube podría carecer de la experiencia en silicio, óptica y sistemas necesaria para convertir la arquitectura en productos.

AMD aportó procesadores, aceleradores y redes de endpoints. Arista y Cisco ofrecieron experiencia en conmutación Ethernet a gran escala y conocimientos operativos. Broadcom contribuyó con silicio de conmutación, NICs y SerDes de alta velocidad. HPE y Eviden aportaron experiencia en sistemas HPC e interconexiones especializadas. Intel sumó procesadores, Ethernet y software. Meta y Microsoft representaron a operadores hyperscale con incentivos directos para aumentar la utilización de grandes clústeres de IA y reducir la dependencia de un único proveedor integrado.

El consorcio también incluye intereses comerciales contrapuestos. Los miembros venden NICs, chips de conmutación, sistemas, capacidad en la nube, óptica, software y soporte. Algunos poseen carteras de patentes que pueden ser esenciales para la implementación. Algunos se benefician de un estándar amplio y multivendor, al tiempo que pueden obtener beneficios de características propietarias diferenciadas. Por tanto, el consorcio no elimina la competencia; crea un foro donde los competidores acuerdan interfaces mínimas y continúan compitiendo en calidad de implementación, rendimiento, integración y condiciones comerciales.

El Slingshot de HPE proporciona un ejemplo útil del origen técnico. Es un tejido HPC comercial compatible con Ethernet que incluye enrutamiento adaptativo y gestión de congestión. Comentarios vinculados a HPE indicaron que una especificación de "HPC Ethernet" se presentó a UEC y estimaron que una gran parte de UET deriva de las ideas de transporte de Slingshot. La proporción exacta no se ha verificado de forma independiente y no debe presentarse como un cálculo oficial del consorcio. El punto más amplio está bien respaldado: UEC no partió de cero, sino que se benefició de la experiencia de producción en HPC, redes en la nube, RDMA y Ethernet.

Esta mezcla de sistemas previos es una razón para utilizar la palabra "abierto" con precisión. La especificación adoptada está disponible para descarga pública, y la arquitectura está diseñada para ser implementada por múltiples proveedores. Pero el proyecto también es un lugar donde los miembros contribuyen con conocimientos previos, patentes y hojas de ruta de productos. La apertura del documento no elimina las condiciones económicas o legales que rodean a la tecnología.

Una cadena legal diseñada para la colaboración entre competidores

El modelo de Joint Development Foundation proporciona a UEC una estructura formal sin convertirlo en una empresa operativa tradicional. El proyecto tiene un nombre, un alcance, categorías de afiliación, un Steering Committee, grupos de trabajo y compromisos de propiedad intelectual. La protección de JDF proporciona la infraestructura corporativa y sin ánimo de lucro, y puede custodiar los activos y acuerdos del proyecto. Esto reduce el coste de crear un consorcio y ofrece a los competidores un proceso reconocido para colaborar.

La gobernanza del proyecto recae en el Steering Committee. Sus responsabilidades documentadas incluyen la coordinación de los grupos de trabajo, la admisión de miembros, la gestión de activos y finanzas, la selección o sustitución del presidente, el seguimiento del progreso y el control de la divulgación pública y las marcas del proyecto. Se prefiere el consenso. Si no es posible, el documento organizativo establece un mecanismo de mayoría cualificada de tres cuartas partes de los participantes elegibles que cumplan los requisitos de asistencia. Se pueden presentar objeciones por escrito al presidente.

Brad Booth, de Meta, fue el presidente original. La especificación actual 1.0.3 nombra a J Metz, de AMD, como presidente; a Barry Davis, de HPE, como vicepresidente; a Hugh Holbrook, de Arista, como presidente del Technical Advisory Committee (TAC); y a Puneet Agarwal, de Marvell, como vicepresidente del TAC. Paul Congdon aparece como editor de la especificación. El documento también nombra a líderes y autores en los trabajos de capa física, enlace, transporte y software. La agenda de la cumbre de 2026 menciona a responsables operativos adicionales.

Esos roles no implican necesariamente la sustitución de los títulos oficiales de la especificación, y no se dispone de un organigrama público completo y actualizado.

El documento organizativo contempla tres categorías de afiliación: Steering, General y Contributor. Los miembros Steering participan en la gobernanza y normalmente designan representantes para el Steering Committee. Los miembros General pueden trabajar en todos los grupos técnicos pero no ocupan puestos en el comité. Los miembros Contributor participan en grupos seleccionados y no tienen derecho a voto en las decisiones por mayoría cualificada.

La página pública de afiliación muestra actualmente las categorías General y Contributor con cuotas anuales de 20.000 y 5.000 dólares, respectivamente, más la afiliación a la Linux Foundation, pero no explica claramente el proceso de admisión ni la tarifa actual para la categoría Steering.

La diferencia en la autoridad formal es importante. Una afiliación amplia aporta experiencia y difusión de la implementación, pero la gobernanza no se distribuye equitativamente. Las grandes empresas capaces de ocupar puestos en el Steering, asignar ingenieros a varios grupos y gestionar programas de patentes y productos tienen una influencia práctica mayor que los miembros Contributor más pequeños. Los no miembros pueden descargar la especificación final, pero no ven el proceso completo de borrador ni participan en igualdad de condiciones.

La información interna del proyecto no se trata como datos corporativos confidenciales ordinarios, pero se prohíbe a los miembros revelar materiales en fase de borrador antes de que el comité correspondiente apruebe su publicación. Esto puede ayudar a los competidores a discutir ideas incompletas sin señales prematuras al mercado. Pero también significa que el público no ve las propuestas rechazadas, los registros de votación, las preocupaciones intermedias sobre la implementación ni las negociaciones que dieron lugar a las características opcionales. La especificación final es abierta; el camino hasta ella solo es parcialmente visible.

De cuatro grupos de trabajo a una especificación de 573 páginas

La estructura pública inicial de UEC en 2023 se centró en cuatro grupos de trabajo: software, transporte, enlace y capa física. La secuencia reflejaba la ambición del proyecto de extremo a extremo. La afiliación no se abrió inmediatamente como una lista de correo pública sin restricciones. Más de 200 organizaciones expresaron interés, y el consorcio llevó a cabo la incorporación por fases, con requisitos de orientación sobre procedimientos y normas antimonopolio. La precaución era comprensible porque los participantes compiten directamente en múltiples mercados e iban a discutir requisitos comunes para productos y protocolos.

En diciembre de 2023, UEC informó de unas 40 empresas y más de 300 personas. También había establecido el Technical Advisory Committee y se había ampliado a ocho grupos de trabajo. El propósito del TAC era mantener la coherencia arquitectónica: el diseño del transporte no debía suponer un comportamiento del conmutador, un método de señalización o una API que otro grupo no hubiera acordado soportar. En marzo de 2024, el consorcio informó de 55 empresas y más de 750 participantes activos, y publicó una descripción mucho más clara de la arquitectura prevista.

Las actualizaciones de marzo presentaron las ideas centrales que luego aparecieron en la especificación normativa: libfabric como API orientada al software, pulverización de paquetes (packet spraying), ordenación flexible, múltiples modos de entrega, control de congestión del lado del emisor y del receptor, ECN, recorte de paquetes (packet trimming), Link Layer Retry, control opcional basado en créditos, seguridad del transporte y futuras operaciones colectivas dentro de la red. También subrayaron que UET puede funcionar sobre conmutadores Ethernet existentes, mientras que los conmutadores mejorados ofrecen un rendimiento adicional.

La participación institucional creció en paralelo al trabajo técnico. UEC informó de 1.193 participantes activos en julio de 2024 y de 97 organizaciones miembro en agosto. Son cifras fechadas emitidas por el consorcio y basadas en definiciones que no son del todo públicas, por lo que no deben sumarse automáticamente a anuncios posteriores. En 2025, el consorcio dijo que se habían unido otras 27 empresas, pero las salidas, fusiones y solapamientos temporales impiden deducir un total actual exacto. El propio sitio web señala que no todos los miembros aparecen en la página.

El consorcio publicó la Ultra Ethernet Specification 1.0 el 11 de junio de 2025. Ese fue el momento en el que UEC pasó de ser una hoja de ruta a una línea base pública para la implementación. Le siguió la versión 1.0.1 en septiembre, que corrigió el algoritmo fuente del control de congestión por crédito del receptor (receiver-credit) y problemas editoriales. La 1.0.2 llegó en enero de 2026 y corrigió algoritmos de gestión de congestión, aunque los documentos oficiales difieren sobre si la fecha de publicación fue el 21 o el 28 de enero. Esta contradicción debe mantenerse visible en lugar de resolverse sin comentario.

La versión 1.0.3, publicada el 16 de julio de 2026, es la referencia actual en la fecha de corte de la investigación. Tiene 573 páginas y añade soporte para señalización de 200 gigabits por segundo por carril y capacidad lógica de negociación. Las notas de la versión también identifican correcciones obligatorias relacionadas con la entrega de paquetes, los créditos de congestión, el Link Layer Retry y los conjuntos ordenados de control en la capa física, junto con aclaraciones sobre la seguridad del transporte, las operaciones atómicas y los paquetes recortados.

La diferencia entre correcciones obligatorias y aclaraciones editoriales es importante, porque algunos cambios afectan al comportamiento conforme y requieren mantenimiento de la implementación.

La cumbre de miembros de Denver en 2026 marcó una segunda transición. La agenda se centró en el despliegue, la transformación de la especificación en productos, la conformidad, la gestión, el rendimiento, la depuración, la integración del almacenamiento y las pruebas de conmutadores y endpoints. El documento arquitectónico central ya existe; la credibilidad del proyecto depende ahora más de la capacidad de los implementadores para construir, cualificar, operar y actualizar la pila a través de las fronteras institucionales.

Una arquitectura a través de cinco capas funcionales

La especificación actual de Ultra Ethernet divide la pila en capas de software, transporte, red, enlace y física. Esta división es útil, pero el valor del proyecto reside en los supuestos que vinculan las capas.

En la parte superior, los frameworks de IA, MPI, SHMEM y las bibliotecas de operaciones colectivas interactúan a través de OpenFabrics Interfaces, en particular libfabric. El sublayer de Servicios Semánticos de UET traduce las operaciones de la aplicación en transacciones de transporte. El sublayer de Entrega de Paquetes decide cómo se segmentan, ordenan, reconocen y recuperan los mensajes. La gestión de congestión controla cuántos datos entran en el tejido y cómo se distribuye el tráfico entre las rutas. La seguridad de transporte opcional protege el tráfico de extremo a extremo.

El IPv4 o IPv6 estándar proporciona el enrutamiento en la capa de red. Ethernet proporciona el enlace, con recorte de paquetes, Link Layer Retry, control de flujo basado en créditos y negociación de características opcionales. La capa física define las estadísticas y los requisitos de señalización a 100 o 200 gigabits por segundo por carril.

Esta arquitectura conserva partes importantes de la red actual. UEC no define un sustituto para el enrutamiento IP. En su lugar, espera ECMP tradicional y conmutadores que soporten ECN. Una gran parte de la inteligencia reside en los Fabric Endpoints, que modifican los valores de entropía, rastrean el estado del transporte, colocan los datos y responden a las señales de congestión. Los conmutadores mejorados pueden añadir funciones, pero el diseño no obliga a reemplazar todo el tejido antes de transmitir tráfico UET.

Esto ofrece una ventaja de transición, pero crea un problema de clasificación. Un despliegue podría utilizar endpoints UET sobre Ethernet tradicional con ECMP y ECN. Otro podría añadir recorte, reintento en el enlace, créditos por canal virtual, telemetría más rica y futuras operaciones dentro de la red. Ambos podrían llamarse Ultra Ethernet, aunque su rendimiento, características de recuperación y complejidad operativa difieran sustancialmente.

El enfoque de cinco capas también dificulta el aislamiento de fallos de implementación. Un rendimiento deficiente podría deberse a la alineación de la aplicación, la máquina de estados del endpoint, las transacciones de congestión, la configuración de las colas del conmutador, la alineación DSCP, la óptica, el firmware o el sistema de seguridad. El paso de paquetes por sí solo no basta. El sistema debe mantener la semántica y el rendimiento previstos a escala, con tráfico mixto, fallos y cambios de versión.

El contrato del software: libfabric en lugar de una API propietaria

UEC elige la versión 2.0 de libfabric como API de alto nivel principal para los endpoints conformes. Esta elección vincula el proyecto a un ecosistema de software existente para HPC y redes avanzadas, en lugar de exigir a cada framework que adopte una nueva interfaz propietaria. libfabric ya representa fabrics, dominios, endpoints, colas de finalización, colas de eventos, vectores de direcciones, regiones de memoria, mensajes, operaciones de memoria remota y operaciones atómicas. UEC alinea y restringe estos conceptos para que los proveedores traduzcan las llamadas al comportamiento de UET.

El valor estratégico es la continuidad por encima del transporte. MPI, SHMEM y las bibliotecas de comunicación de aceleradores pueden utilizar abstracciones familiares incluso si el proveedor subyacente cambia. En principio, una aplicación puede solicitar una operación sin saber qué proveedor de NIC realiza la entrega o qué tipo de silicio de conmutador enruta los paquetes. Este es uno de los principales mecanismos por los que un transporte común podría generar opciones entre proveedores.

La abstracción no garantiza implementaciones equivalentes. Los proveedores pueden admitir diferentes tamaños de inyección, límites de dispersión/reunión, números distintos de endpoints, operaciones atómicas y técnicas de registro de memoria, comportamiento de finalización, descarga de hardware y funciones de seguridad diferentes. Una biblioteca construida sobre la misma API puede encontrar límites de rendimiento y capacidad diferentes. Por lo tanto, las adquisiciones y la cualificación del software necesitan algo más que una etiqueta que diga "libfabric soportado".

La capa de software también soporta la semántica de tareas y la delegación. Los sistemas de IA y HPC suelen ejecutar muchas tareas en una infraestructura compartida, cada una con sus propias operaciones, regiones de memoria y límites de seguridad. La especificación debe definir qué endpoint pertenece a cada tarea, qué memoria está permitida, cómo se empareja la operación remota y cómo se devuelve la información de finalización o error al software. Estas decisiones determinan si la red rápida es utilizable por el planificador, el entorno de ejecución y la aplicación, y no solo un número impresionante en una prueba de paquetes.

El proyecto depende del ecosistema OpenFabrics porque no posee libfabric. Esta relación ilustra una característica más amplia de UEC: la arquitectura es compuesta, con componentes gobernados en lugares distintos. El consorcio puede especificar la alineación de su transporte con libfabric, pero necesita coordinarse con los mantenedores de la API y sus usuarios. Existen dependencias similares con Ethernet (IEEE), los mecanismos de red (IETF), los organismos de almacenamiento y los sistemas operativos de los proveedores.

Fabric Endpoints y perfiles de carga de trabajo

Un Fabric Endpoint, o FEP, es el lugar lógico donde termina UET. Vincula una única instancia del sistema operativo con uno o más niveles de tejido aislados, y puede incluir un proveedor de espacio de usuario, un controlador de kernel, transporte dentro de la NIC o el acelerador, un sistema de registro de memoria, un contexto de seguridad, colas de finalización, vectores de direcciones y el estado utilizado para la entrega de paquetes y el control de congestión.

Este diseño centrado en el endpoint permite que la mayoría de los conmutadores sigan siendo dispositivos Ethernet e IP de función clara. El FEP selecciona los valores de entropía, mantiene el estado de paquetes y congestión, coloca los datos en la memoria autorizada e interpreta los acuses de recibo, el recorte y otras retroalimentaciones. Esto puede reducir la dependencia de la inteligencia de enrutamiento propietaria dentro del conmutador, pero concentra la complejidad en el silicio de la NIC, el firmware, los controladores y el software.

UEC define tres perfiles de implementación: AI Base, AI Full y HPC. No son tipos de red separados, sino paquetes que especifican las funciones que una implementación debe soportar. AI Base está pensado para cubrir las comunicaciones de IA más comunes con menor coste y estado de implementación. AI Full añade funciones como envíos diferibles (deferrable sends), emparejamiento exacto y operaciones atómicas de tipo fetch o compare. El perfil HPC incluye la mayoría de las capacidades de AI Full, pero excluye el envío diferible y da más peso a la ordenación, los mensajes cortos y la semántica HPC.

El sistema de perfiles intenta evitar que cada producto tenga que implementar el conjunto máximo de características. Reconoce que una NIC diseñada para IA en general puede priorizar el tráfico de datos colectivos, mientras que un endpoint HPC puede necesitar una ordenación más fuerte y operaciones atómicas. Pero los perfiles no eliminan las opciones. Un producto puede implementar características opcionales dentro de un perfil, y dos productos con el mismo nombre pueden diferir en seguridad, mejoras de enlace, capacidad y rendimiento.

Una señal de advertencia aparece en la propia terminología. La especificación de referencia 1.0.3 utiliza los nombres AI Base, AI Full y HPC. Mientras que un archivo léame de conformidad independiente de 2025 utiliza AI Base, AI Extended y HPC. La interpretación más sólida es que "AI Full" es el nombre actual y que el material de conformidad está obsoleto o es inconsistente. Hasta que se corrija el conjunto de pruebas público, los proveedores y compradores deberían especificar la versión de la especificación y el nombre exacto del perfil detrás de cada reclamación.

De la intención de la aplicación a la entrega de paquetes

Dentro de UET, el sublayer de Servicios Semánticos transporta la intención de la aplicación. Define la identidad del mensaje, las direcciones de los búferes, las operaciones etiquetadas y no etiquetadas, el acceso remoto a memoria, las operaciones atómicas, el comportamiento de finalización, los identificadores de tareas, la delegación de búferes y las respuestas y errores. A continuación, el sublayer de Entrega de Paquetes decide cómo se convierte esa intención en paquetes y cómo llegan a otro endpoint.

En los modos fiables, los endpoints crean Contextos de Entrega de Paquetes (PDC). Un PDC contiene estado como números de secuencia de paquetes, acuses de recibo, detección de duplicados, modo de ordenación, información de congestión, estado del camino de retorno y clase de tráfico. Un PDC está asociado a un modo de entrega y una clase de tráfico, y pueden existir varios PDC entre el mismo par de FEP.

Este estado no es un detalle menor. Los clústeres grandes pueden generar un número enorme de relaciones de comunicación. Si cada relación requiere un estado extenso en el destino, la memoria del endpoint y el coste de búsqueda pueden convertirse en un límite. Por eso UEC no obliga a todas las operaciones a seguir un único modelo de comunicación, sino que define cuatro modos de entrega con diferentes contratos de fiabilidad y ordenación.

La Entrega Fiable No Ordenada (Reliable Unordered Delivery, RUD) entrega cada paquete exactamente una vez a la capa semántica, pero permite que los paquetes lleguen fuera de orden. Admite la pulverización de paquetes a través de múltiples rutas, la retransmisión selectiva, la prevención de duplicados y la colocación directa de datos. Como el destino puede colocar los datos según los desplazamientos en lugar de esperar un búfer de reordenación en el transporte, una operación colectiva larga puede utilizar múltiples rutas sin que todos los paquetes se alineen detrás de una unidad perdida.

La Entrega Fiable Ordenada (Reliable Ordered Delivery, ROD) proporciona una entrega única y en orden. Utiliza una sola ruta y un único valor de entropía, descarta los paquetes fuera de orden y se basa en Go-Back-N a partir del primer número de secuencia perdido. Parece menos compleja que RUD, pero mantiene la semántica necesaria cuando el orden estricto es importante. UEC trata la ordenación como un requisito de la aplicación en lugar de imponer su coste a todo el transporte.

La Entrega Fiable No Ordenada para Operaciones Idempotentes (Reliable Unordered Delivery for Idempotent Operations, RUDI) ofrece un compromiso diferente. Garantiza la entrega al menos una vez y permite duplicados, lo que reduce el estado habitual de secuencia y acuse en el destino. Puede ser útil cuando la repetición de una operación no altera el resultado final, como en ciertos movimientos de memoria remota seguidos de una barrera separada. Pero es peligrosa si se utiliza incorrectamente. La capa de paquetes no deduce si una operación es idempotente; el software debe decidirlo.

Usar RUDI para una operación no idempotente podría producir un estado de aplicación incorrecto.

La Entrega No Fiable No Ordenada (Unreliable Unordered Delivery, UUD) ofrece datagramas de mejor esfuerzo sin garantías normales de fiabilidad u orden. Está dentro del mismo marco semántico, pero no conlleva los mismos requisitos de control de congestión que RUD y ROD. Las aplicaciones deben evitar perjudicar al tráfico controlado cuando UUD comparte colas o clases con él.

Los cuatro modos revelan una filosofía central: la red debe ofrecer múltiples mecanismos para que el software ajuste el coste del transporte a la semántica de la operación. El beneficio es la eficiencia; el coste es una mayor superficie de implementación y pruebas, y más oportunidades de que un proveedor, una aplicación o un operador elijan una combinación incompatible.

Pulverización de paquetes: usar el tejido en lugar de confiar en una ruta afortunada

El ECMP tradicional suele asignar un flujo completo a una sola ruta mediante un hash. En un tejido Clos amplio, esto puede convertirse en una lotería. Varios flujos grandes pueden colisionar en los mismos enlaces mientras que una capacidad similar permanece sin usar en otras partes. Un transporte largo de IA puede permanecer limitado durante toda su vida por una ruta elegida de forma subóptima.

UET aborda esto cambiando la entropía a nivel de cada paquete. El emisor puede utilizar decenas o cientos de valores, lo que permite que los mecanismos ECMP existentes en los conmutadores distribuyan los paquetes por numerosos caminos. El sublayer de Entrega de Paquetes proporciona la información de secuencia, el sublayer de Gestión de Congestión selecciona un valor de entropía o una ruta, los conmutadores realizan el hash habitual y la retroalimentación informa al emisor sobre qué valores parecen congestionados.

La pulverización de paquetes solo es práctica porque otras partes del diseño la respaldan. Los paquetes pueden llegar fuera de orden. RUD puede colocar los datos directamente sin esperar una reordenación completa en el transporte. La retransmisión selectiva recupera solo lo perdido. La retroalimentación de congestión reduce el uso de los caminos afectados. Por tanto, el mecanismo no es un truco aislado de equilibrio de carga, sino parte de un modelo de transporte construido en torno a la diversidad de rutas.

UEC no exige que cada conmutador ejecute un algoritmo propietario de enrutamiento adaptativo. Las implementaciones básicas pueden utilizar round-robin o entropía pseudoaleatoria sobre ECMP estándar. Los endpoints avanzados pueden vincular señales ECN, latencia o recorte a valores concretos y evitar las rutas congestionadas. El enrutamiento adaptativo específico del proveedor puede coexistir con UET, pero no es la única fuente de conocimiento de la ruta.

La promesa es una mejor utilización del tejido y una menor latencia de cola. La cuestión pendiente es con qué coherencia interpretan los distintos endpoints la retroalimentación, y cómo interactúa la pulverización con los búferes de los conmutadores, la reordenación, los fallos y el tráfico mixto. Un algoritmo que funciona bien en un laboratorio homogéneo puede comportarse de forma diferente en un tejido grande con múltiples generaciones de conmutadores y diversas clases de tráfico. Las pruebas independientes con múltiples proveedores siguen siendo limitadas.

Tres mecanismos de congestión para tres cuellos de botella diferentes

UEC no define un único algoritmo de congestión universal. Distingue entre la congestión en el núcleo de la red, las ráfagas de entrada (incast) en el receptor y las limitaciones de búfer en los endpoints.

El Control de Congestión Señalizado por la Red (Network-signal Congestion Control, NSCC) es un mecanismo controlado por el emisor. El emisor mantiene una ventana de congestión, estima la cantidad de datos en vuelo y ajusta la ventana en función de los acuses de recibo, los acuses negativos, los tiempos de espera, la latencia y señales de red como ECN. También coordina el comportamiento de la ventana con las múltiples rutas a nivel de paquete.

UEC argumenta que la ventana deja de introducir nuevos datos de forma natural cuando los paquetes no pueden salir de la red, mientras que un controlador basado únicamente en la tasa podría malinterpretar la ausencia de retroalimentación.

Este es el argumento arquitectónico del consorcio, no una prueba independiente de que cada implementación de NSCC supere a DCQCN u otros mecanismos RoCE. Los resultados dependen de los detalles del algoritmo, la forma en que los conmutadores marcan los paquetes, la topología, los patrones de tráfico y los parámetros elegidos. Por lo tanto, la frase "utiliza NSCC" no es suficiente para demostrar el rendimiento.

El Control de Congestión por Crédito del Receptor (Receiver-credit Congestion Control, RCCC) aborda el problema del incast. Cuando muchas fuentes envían simultáneamente a un único destino, el último enlace puede convertirse en un cuello de botella aunque el núcleo de la red no esté congestionado. El receptor rastrea la demanda y distribuye créditos a los emisores, regulando así la tasa de llegada agregada y modificando la ventana efectiva de cada fuente según la contienda. RCCC puede funcionar junto con NSCC porque la presión del receptor y la congestión del núcleo son problemas diferentes.

El Control de Flujo de Transporte (Transport Flow Control, TFC) también utiliza créditos, pero sirve para conexiones punto a punto con búferes limitados. Su objetivo inmediato es evitar el desbordamiento del búfer del receptor cuando la tolerancia a las pérdidas es baja. Puede utilizarse con o sin múltiples rutas. Tratar todos los mecanismos de crédito como lo mismo oculta el diferente ámbito de fallo que cada uno está diseñado para abordar.

La especificación espera que se utilice la Notificación Explícita de Congestión (ECN) en todo el tejido, y hace suposiciones operativas sobre el marcado, incluido el marcado en la salida de la cola (dequeue) en lugar de depender solo de la entrada (enqueue). Los endpoints interpretan ECN junto con los acuses de recibo, la latencia y el recorte. Por lo tanto, la coherencia en la configuración de los conmutadores se vuelve esencial. Una implementación de transporte puede ser correcta y, sin embargo, un tejido mal configurado puede producir un rendimiento deficiente.

El historial de mantenimiento revela la dificultad. La versión 1.0.1 corrigió el algoritmo fuente de RCCC, la 1.0.2 corrigió casos en la gestión de congestión y la 1.0.3 corrigió interacciones entre los créditos y el Link Layer Retry. Son signos normales de una especificación viva, pero también muestran que los estados de crédito, retransmisión y control de ruta pueden interactuar de forma sutil. Los operadores necesitarán disciplina de versiones y pruebas de regresión, no solo una conformidad inicial.

Recorte de paquetes y recuperación precisa de pérdidas

El recorte de paquetes (packet trimming) cambia lo que hace un conmutador capaz cuando no puede retener un paquete completo. En lugar de descartar la trama sin información adicional, elimina la mayor parte o la totalidad de la carga útil, conserva lo suficiente de la cabecera y los metadatos para identificar el paquete, lo marca como recortado y envía la notificación abreviada hacia el receptor. El receptor puede entonces informar al emisor de los datos específicos que se perdieron.

Esto proporciona información más precisa que el marcado ECN. ECN indica que se ha producido una congestión, mientras que el recorte identifica un paquete cuya carga útil no ha sobrevivido. Con RUD y la retransmisión selectiva, se puede acelerar la recuperación sin esperar un tiempo de espera ni una larga retransmisión en cadena debido a una sola pérdida.

La función en el conmutador es opcional, pero los endpoints conformes deben ser capaces de recibir e interpretar los paquetes recortados cuando se apliquen los requisitos. Esta asimetría ayuda a desplegar UET sobre conmutadores comunes, al tiempo que permite que los tejidos mejorados ofrezcan información de pérdida más rica. Pero también crea un problema de actualización; una red parcialmente mejorada puede necesitar restringir el recorte por ruta, perfil o topología para garantizar que cada endpoint receptor lo maneje correctamente.

UEC también define diferentes clases de tráfico para las solicitudes, los paquetes de control, las retransmisiones y el tráfico recortado. Los operadores deben alinear de forma coherente los valores DSCP, las colas de los conmutadores, las colas de los endpoints y los niveles de prioridad. La especificación no proporciona un sistema de gestión universal para esta alineación. Un error podría provocar la inanición del tráfico de control, distorsionar la retroalimentación de congestión o hacer que los paquetes de recuperación compitan con el tráfico que se supone que deben reparar.

El recorte de paquetes resume el desafío más amplio de la implementación. El protocolo puede definir el comportamiento en el cable, pero el resultado operativo depende de las colas del conmutador, la lógica del endpoint, la telemetría, la configuración y el manejo de fallos. La interoperabilidad es una propiedad de todo el sistema, no solo del formato del paquete.

Recuperación del enlace, créditos y negociación de características

El Link Layer Retry (LLR) intenta recuperar un error en un enlace físico antes de que reaccione el transporte de extremo a extremo. El extremo detecta un hueco de secuencia o una trama dañada, envía un acuse negativo a nivel de enlace y hace que el emisor retransmita la trama afectada desde un búfer local. Si la recuperación tiene éxito rápidamente, el transporte puede evitar una retransmisión más larga a través de todo el camino.

El valor potencial aumenta con la velocidad de los carriles y la densidad de puertos. Un error óptico o eléctrico ocasional podría causar un retraso significativo en una tarea altamente sincronizada. Pero LLR añade estado de secuencia, búferes de reproducción, mensajes de control, ventanas de descarte y nuevos modos de fallo. También debe coexistir con las actualizaciones de créditos y los reinicios del enlace. La versión 1.0.3 corrigió varios casos límite, incluida una condición de carrera entre la información de crédito de CBFC y LLR.

El Control de Flujo Basado en Créditos (Credit-Based Flow Control, CBFC) funciona por canal virtual en el nivel de enlace. Informa al emisor de cuánta capacidad de recepción queda, y puede proporcionar un control más fino que una pausa amplia basada en prioridad. UEC lo presenta como un medio para soportar un comportamiento sin pérdidas controlado sin exigir que toda la red UET sea completamente sin pérdidas. CBFC es opcional, y UET está diseñado para funcionar sobre redes de mejor esfuerzo.

No debe tratarse CBFC como otro nombre para el Control de Flujo por Prioridad (Priority Flow Control). Los dos mecanismos difieren en la señalización y la granularidad, aunque ambos buscan evitar el desbordamiento. CBFC sigue necesitando una configuración coherente y una entrega correcta de sus tramas de control. Los créditos locales pueden interactuar con las ventanas de extremo a extremo y los créditos del receptor, produciendo múltiples bucles de control anidados.

UEC utiliza una negociación basada en LLDP para descubrir las características opcionales y evitar que un extremo active una capacidad que el vecino no soporta. La negociación debe tener en cuenta los perfiles, los canales virtuales, DSCP, la alineación de prioridades, los reinicios, las actualizaciones de software y las combinaciones parciales de características. La versión 1.0.3 introdujo una capacidad de negociación lógica, lo que refuerza la importancia del acuerdo explícito en cada enlace.

Estas opciones proporcionan un camino desde la Ethernet básica a la Ethernet mejorada. Pero también crean una matriz que el lenguaje de adquisición puede ocultar. Un conmutador puede transmitir UET correctamente sin recorte, LLR ni CBFC. Otro conmutador puede soportar estas capacidades solo en versiones de software o modos de puerto específicos. Un registro de despliegue fiable necesita el conjunto exacto de características, no solo el nombre del consorcio.

Señalización física a 100 y 200 gigabits por segundo por carril

La capa física vincula UEC con la hoja de ruta del hardware. El trabajo inicial para la versión 1.0 se diseñó en torno a la señalización de 100 gigabits por segundo por carril. La versión 1.0.3 introdujo el soporte para 200 gigabits por segundo por carril. Esto se alinea con una generación de enlaces y sistemas de mayor densidad, pero es una capacidad de la especificación, no una prueba de que todos los productos UEC la soporten de inmediato.

El trabajo de PHY también aborda las estadísticas de corrección de errores hacia adelante (FEC), las proporciones de palabras de código corregidas e incorregibles, los conjuntos ordenados de control, los informes de calidad del enlace y la interacción entre los errores físicos y el LLR. Estos detalles son importantes porque las decisiones de recuperación del transporte dependen de lo que las capas inferiores pueden ver e informar.

A velocidades de señalización más altas, los límites entre la óptica, SerDes, FEC, el reintento de enlace y la recuperación en el transporte tienen consecuencias económicas. Una FEC más fuerte puede reducir los errores residuales a costa de la latencia y la energía. Un reintento local puede recuperar un error más rápido, pero necesita búferes y estado. La retransmisión de extremo a extremo es más simple en toda la red, pero puede desperdiciar más tiempo. UEC intenta especificar cómo cooperan estas capas en lugar de dejar que cada proveedor las optimice por separado.

La adición de 200G por carril también muestra que el objetivo se mueve. Los implementadores de la versión 1.0 deben mantener la compatibilidad mientras planifican nuevas capacidades físicas. Los equipos de prueba, el firmware y los sistemas de gestión deben distinguir entre las capacidades de cada puerto. Los compradores no deben deducir la velocidad del carril de una afirmación genérica de soporte UEC.

Seguridad de transporte opcional de extremo a extremo

El sublayer de Seguridad de Transporte (Transport Security Sublayer, TSS) proporciona protección opcional de extremo a extremo. No exige que el modelo de amenazas confíe en los conmutadores. Puede ofrecer confidencialidad, integridad, protección contra repetición, aislamiento de tareas, dominios seguros, claves de grupo y rotación de claves, e integración con raíces de confianza de hardware.

El diseño utiliza dominios seguros cuyos miembros comparten un contexto criptográfico. Los identificadores, los números de enlace, las épocas, la identidad de origen seguro y la derivación de claves están diseñados para escalar mejor que el establecimiento de una sesión independiente para cada par de endpoints. Esto es necesario cuando el conjunto de aceleradores y la pertenencia a tareas cambian rápidamente.

El protocolo es solo una parte del sistema de seguridad. Un operador de producción debe ejecutar autoridades de claves y certificados u otras raíces de confianza, servicios de pertenencia a tareas, distribución y revocación, transiciones de épocas, recuperación de endpoints, cifrado de hardware y telemetría de seguridad. Una red puede ajustarse a un perfil sin activar todas las funciones TSS opcionales. "Conforme con UEC" no significa automáticamente que el tráfico esté cifrado.

La opcionalidad refleja diferentes supuestos de despliegue. Un tejido dedicado y físicamente controlado puede priorizar el rendimiento y confiar en los controles del entorno. Una nube multiinquilino puede necesitar un aislamiento fuerte y protección criptográfica. El sistema de perfiles y las adquisiciones deben reflejar esta diferencia.

El mayor riesgo no es solo el coste del cifrado, sino el fallo del ciclo de vida a gran escala: pertenencia obsoleta, revocación tardía, épocas inconsistentes, recuperación tras un fallo del endpoint o la incapacidad de demostrar qué tarea puede acceder a qué memoria. Estos problemas vinculan la seguridad del transporte con los sistemas de orquestación e identidad más allá de la especificación central.

Qué significa actualmente "UEC compliant"

UEC comenzó a publicar materiales de conformidad con la versión 1.0, pero el sistema público no es un programa de certificación independiente maduro. El conjunto de herramientas disponible está diseñado principalmente para la autodeclaración de los implementadores. Las matrices vinculan los requisitos de la especificación con los perfiles, y las guías del banco de pruebas describen configuraciones recomendadas para endpoints y conmutadores. No se ha encontrado una base pública completa en la que una entidad independiente registre qué productos han superado o no un programa UEC completo.

La distinción es necesaria porque circulan diferentes afirmaciones en el mercado. Un producto puede estar diseñado en torno a características UEC en desarrollo, implementar funciones seleccionadas en el cable o soportar un perfil o partes del mismo en una versión de software específica. Un proveedor puede afirmar la conformidad total de las características, o un laboratorio puede generar tráfico UET a través de un conmutador. Ninguna de estas situaciones equivale automáticamente a una certificación independiente de extremo a extremo con múltiples proveedores.

Las guías públicas del banco de pruebas son útiles pero limitadas intencionadamente. Ofrecen topologías y comprobaciones de buenas prácticas, no una cualificación completa del sistema. No cubren completamente la interoperabilidad más amplia, el rendimiento, el estrés, la escala ni el ciclo de vida de la API. Tampoco demuestran el comportamiento al mezclar UET y RoCE, las actualizaciones parciales, los fallos repetidos, los grandes dominios de claves o los mayores números de endpoints objetivo.

La contradicción entre AI Full y AI Extended demuestra la necesidad de un versionado disciplinado. Un comprador debería preguntar por la especificación, el nivel de parche, el perfil, las características opcionales, los modos de enlace y las funciones de seguridad que cubre la afirmación. La respuesta debería especificar si la prueba procede de pruebas internas, una demostración bilateral, un evento del consorcio o un laboratorio independiente.

La siguiente fase creíble incluye definiciones de pruebas públicas vinculadas a versiones exactas, plugfests multivendor, resultados gestionados por una entidad independiente (incluidos los negativos) y un registro que distinga endpoints, conmutadores, software y sistemas completos. Hasta que eso ocurra, "UEC compliant" es un punto de partida para la verificación, no una garantía completa.

Documento abierto con compromisos de patentes RAND

La Ultra Ethernet Specification 1.0.3 está disponible públicamente y se distribuye bajo la licencia Creative Commons Attribution-NoDerivatives 4.0. La licencia permite la redistribución con atribución, pero no permite la distribución de versiones modificadas. Y lo que es más importante, el acceso a través del copyright es independiente del derecho a utilizar las patentes.

Los estatutos documentados de los grupos de trabajo suelen utilizar un modelo tradicional de desarrollo de especificaciones con una licencia de patentes en términos razonables y no discriminatorios (RAND). RAND no significa necesariamente libre de regalías, no garantiza un precio universal, no elimina la negociación ni impide disputas sobre validez, esencialidad, alcance geográfico o condiciones defensivas. El panorama comercial depende de cada patente declarada, del compromiso del miembro y de cualquier acuerdo bilateral.

UEC mantiene un registro público de declaraciones de reivindicaciones necesarias (Necessary Claims). En la fecha de corte de la investigación, aparecían declaraciones vinculadas a Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell y otras, incluidas solicitudes relacionadas con trabajos futuros de la versión 1.1. El registro mejora la transparencia porque deja claro que los implementadores pueden necesitar examinar la propiedad intelectual antes de construir o enviar un producto.

El consorcio declara que no determina si una patente declarada es válida, realmente necesaria, infringida o está disponible a un precio determinado. Tampoco publica una licencia común. Los implementadores pequeños pueden enfrentarse a costes legales y de transacción que las grandes empresas pueden absorber más fácilmente. Una especificación pública puede dar lugar a un mercado de implementación concentrado si el coste de la liquidación de patentes, el silicio y las pruebas es elevado.

El marco de propiedad intelectual también influye en los incentivos de la gobernanza. Las empresas contribuyen con tecnología en parte para crear un mercado amplio para sus productos y en parte para garantizar que sus capacidades estén representadas en el diseño común. Las declaraciones de patentes solo protegen a los implementadores de sorpresas si son tempranas y suficientemente claras. Y no eliminan la posibilidad de que la concesión de licencias se convierta en una barrera una vez que la adopción sea amplia.

Por lo tanto, la descripción honesta es "publicada públicamente y con múltiples proveedores, con compromisos RAND", no "libre de regalías a nivel universal". Los equipos de adquisiciones necesitan tanto el perfil técnico como la vía de licencia.

La primera ola de productos y pruebas

Las pruebas de implementación comenzaron a aparecer en torno a la versión 1.0, pero los ejemplos se encuentran en diferentes grados de madurez.

AMD puso a disposición comercial la NIC Pollara 400 AI en abril de 2025, describiéndola como diseñada en torno a las capacidades de UEC en desarrollo. Pollara es una plataforma de endpoint programable y una señal importante de que el transporte está pasando a hardware que se envía realmente. Pero la redacción es importante: diseñar en torno a características en evolución no equivale a una certificación independiente contra todos los requisitos finales de la 1.0.3.

Broadcom anunció en junio de 2025 el Tomahawk 6 como un ASIC de conmutación de 102,4 terabits por segundo con características relevantes para los tejidos UEC. En octubre, anunció la NIC Thor Ultra 800G y afirmó que el diseño ofrecía una conformidad completa con las características de UEC. Se trata de una afirmación importante del proveedor, pero la prueba pública no la convierte en una certificación independiente del consorcio. Deben separarse el muestreo, la madurez del software y el soporte preciso de los perfiles.

Nokia y Keysight anunciaron en octubre de 2025 una demostración de tráfico UET de extremo a extremo a través de las familias de conmutadores para centros de datos Nokia 7220 y 7250 a 800 Gigabit Ethernet. Keysight proporcionó la generación de tráfico y la verificación. La prueba demuestra que el tráfico UET puede atravesar sistemas de conmutación comerciales y que el soporte de los equipos de prueba está evolucionando. Pero no demuestra un perfil de endpoint completo multivendor, escala de producción o certificación independiente para todas las características opcionales.

Otros miembros han descrito conmutadores, sistemas, software y planes de prueba capaces de UEC, y la cumbre de 2026 se centró fuertemente en la productización. Las pruebas apoyan una transición hacia la implementación, pero no demuestran un número preciso de NICs UET enviadas, conmutadores cualificados, regiones de nube operativas o tejidos completos.

La mejor lectura de la ola es una cadena de pruebas. La especificación pública permite el diseño. Los anuncios de silicio y NIC muestran inversión. Las demostraciones de tráfico muestran cierta interoperabilidad. Las matrices de conformidad organizan los requisitos. Los informes de los operadores mostrarán el valor operativo. Las plugfests independientes y los resultados de producción proporcionarán la confianza más amplia que aún falta.

RoCE, InfiniBand, Slingshot y UALink

UEC entra en un mercado con alternativas maduras y tecnologías adyacentes. Su propuesta estratégica no se basa en que Ethernet nunca haya transportado RDMA o en que los tejidos especializados no funcionen, sino en que la escala y la sincronización de las cargas de trabajo de IA actuales justifican una nueva arquitectura Ethernet de extremo a extremo, más flexible en la entrega, el uso de rutas y el control de congestión.

RoCEv2 es el predecesor directo y una tecnología ampliamente desplegada. Coloca el tráfico RDMA sobre Ethernet enrutable y cuenta con un amplio soporte en aplicaciones y productos. UEC critica las implementaciones comunes de RoCE porque anclan el flujo completo a una sola ruta, utilizan Go-Back-N y reordenación en el receptor, requieren un ajuste difícil de DCQCN y dependen del Control de Flujo por Prioridad en muchos diseños, mostrando un mal comportamiento en incast o ráfagas colectivas. Estas son posiciones técnicas del consorcio, no una prueba de debilidad de todas las redes RoCE.

La comparación también es móvil. Los proveedores pueden añadir enrutamiento adaptativo, pulverización de paquetes, mejores algoritmos de congestión o funciones similares a UEC a NIC programables manteniendo la compatibilidad con RoCE. Por ejemplo, AMD presenta en sus mensajes de Pollara tanto RoCEv2 como UEC RDMA como opciones en hardware programable. UEC puede competir con RoCE como un transporte completo e influir al mismo tiempo en la evolución de los futuros productos RoCE.

InfiniBand es la alternativa especializada más importante. Ofrece un ecosistema integrado para RDMA, congestión, fiabilidad del enlace y gestión, con una larga experiencia en HPC. El trabajo 2.0 de la InfiniBand Trade Association incluye soporte físico para XDR a 200 gigabits por segundo por carril y telemetría actualizada. El diferenciador más fuerte de UEC no es afirmar que InfiniBand carece de rendimiento, sino la posibilidad de lograr un comportamiento de IA/HPC a través de la cadena de suministro más amplia de Ethernet, el enrutamiento IP estándar y una mayor opción de proveedores.

HPE Slingshot ocupa una posición intermedia. Es un tejido HPC comercial compatible con Ethernet, que incluye enrutamiento adaptativo y gestión de congestión, y proporcionó importantes precedentes técnicos para UET. Demuestra que se puede construir un comportamiento especializado sobre Ethernet, pero también ilustra la diferencia entre una plataforma comercial controlada y una especificación a nivel de industria.

UALink suele ser complementario y no un sustituto directo. Su especificación pública actual de 200G se dirige a la interconexión de baja latencia scale-up entre aceleradores dentro de un pod, y describe sistemas de hasta 1.024 aceleradores. UEC 1.0 es fundamentalmente un tejido scale-out que conecta nodos a través de conmutadores. Un centro de datos podría utilizar un enlace scale-up dentro del pod y UEC entre pods o nodos. Los futuros trabajos de UEC en transporte scale-up y operaciones colectivas dentro de la red podrían acercar los límites y producir convergencia o competencia.

NVIDIA Spectrum-X y los tejidos propietarios de aceleradores ofrecen otra comparación. Una pila estrechamente integrada puede optimizar rápidamente el hardware, el software y el soporte, pero aumenta la dependencia de un único ecosistema. UEC sustituye parte de esta integración por la promesa de interfaces comunes y elección de proveedor. El éxito de la compensación depende del rendimiento, el soporte, las condiciones de las patentes, la interoperabilidad y el coste operativo total, no de la palabra "abierto" como mero eslogan.

El problema operativo es mayor que el protocolo

Una especificación de 573 páginas puede definir muchos requisitos, pero un tejido de producción sigue necesitando un modelo operativo. UEC 1.0 deja fuera del documento normativo central, o lo rodea, importantes trabajos de gestión. Los operadores deben configurar perfiles, clases de tráfico, umbrales de ECN, conjuntos de entropía, características opcionales del enlace, claves, firmware, telemetría y políticas de fallos de forma coherente entre endpoints y conmutadores.

El tráfico mixto lo hace más difícil. Un tejido de centro de datos puede transportar UET, RoCE, TCP, almacenamiento, gestión y servicios UET ordenados y no ordenados. La cuestión de la distribución de colas y la equidad entre ellas no se resuelve simplemente porque cada implementación de protocolo sea correcta. Un algoritmo de congestión puede funcionar bien por sí solo y luego comportarse mal cuando compite con otro controlador que se basa en señales y supuestos diferentes.

La complejidad del endpoint es otro riesgo estructural. UET coloca el multipath, la colocación directa, la retransmisión selectiva, los múltiples modos de entrega, el control de ventanas y créditos, la recepción de recortes, la seguridad y un gran estado dentro del FEP. Esto puede aumentar el área del die de la NIC, el tamaño del firmware, el esfuerzo de verificación, la energía y el número de casos de fallo que deben diagnosticarse. La inteligencia del endpoint permite una amplia cadena de suministro, pero puede situar la implementación más difícil en el componente que cada servidor debe comprar.

Las características opcionales crean diferenciación de productos y fragmentación al mismo tiempo. Un proveedor puede optimizar un endpoint básico para AI Base con ECMP y ECN ordinarios. Otro puede soportar AI Full, HPC, TSS, recorte, LLR y CBFC. Ambos están en el ecosistema UEC, pero los operadores no pueden asumir la misma semántica, rendimiento o seguridad. Las matrices de conformidad deben convertirse en matrices operativas de capacidades.

El mantenimiento de versiones será continuo. Los parches de 1.0.1 a 1.0.3 afectaron a la congestión, los créditos, el reintento y el comportamiento de los paquetes. Un clúster grande puede incluir diferentes versiones de firmware en las NIC, varias versiones de conmutadores y herramientas de prueba. Actualizar una capa sin coordinar el resto puede desencadenar exactamente la interacción entre capas que el consorcio busca evitar.

Por eso las relaciones externas son centrales, no simbólicas. El Open Compute Project puede vincular el transporte con sistemas y hardware abierto. La OpenFabrics Alliance y la comunidad libfabric conectan las aplicaciones. El IEEE 802.3 proporciona el trabajo formal de Ethernet. SNIA y NVM Express añaden requisitos de almacenamiento y gestión. Las tecnologías de la IETF proporcionan los mecanismos de IP, ECN y relacionados. Estos organismos tienen procesos de decisión y hojas de ruta diferentes; la coordinación reduce la duplicación pero no garantiza una adopción sincronizada.

La prueba operativa final es la infraestructura en funcionamiento. Un documento puede definir el comportamiento, un proveedor puede anunciar un producto y un consorcio puede organizar una cumbre. Nada de eso sustituye a un clúster en el que endpoints y conmutadores independientes completen tareas reales bajo congestión, fallos y actualizaciones, y los operadores puedan interpretar lo que sucedió.

Importancia actual: del éxito de la especificación a la credibilidad de la implementación

En julio de 2026, UEC había logrado cosas que no estaban garantizadas en el momento del lanzamiento. Creó un amplio consorcio, estableció una arquitectura integrada de cinco capas, publicó una especificación 1.0 completa, la mantuvo a través de versiones de parche, añadió 200G por carril, reveló declaraciones de patentes y atrajo anuncios de productos y pruebas. El proyecto está activo y su agenda se ha desplazado claramente hacia la implementación.

El progreso hace que las siguientes incertidumbres sean más importantes, no menos. El número exacto actual de miembros y la lista del Steering Committee no aparecen en un único registro de referencia. Las páginas públicas de afiliación y el documento organizativo describen el acceso de forma diferente. El liderazgo oficial actual del TAC no coincide del todo con los roles de la cumbre. Documentos oficiales difieren en la fecha de la versión 1.0.2, y el paquete de conformidad utiliza una terminología de perfil anticuada.

Nada de esto destruye la arquitectura, pero es un indicador de la disciplina documental y la transparencia en un proyecto donde los resultados dependen de versiones precisas.

Las lagunas más importantes se refieren a la adopción. UEC no publica estadísticas de despliegue, ni un registro de productos verificado de forma independiente, ni un presupuesto o cuentas auditadas independientes. No hay pruebas públicas de una red UEC 1.0 completamente interoperable a los volúmenes máximos previstos por el consorcio. Las demostraciones y afirmaciones de los proveedores son valiosas, pero proceden de partes con un interés comercial. Las comparaciones neutrales con RoCE, InfiniBand y las plataformas Ethernet integradas existentes siguen siendo limitadas.

La oportunidad sigue siendo grande. Ethernet es el denominador común en los centros de datos, y el mercado de la infraestructura de IA es lo suficientemente grande como para soportar nuevas generaciones de NICs, conmutadores, óptica y software. Los operadores tienen fuertes incentivos para reducir la dependencia de un solo proveedor y mejorar la utilización de los aceleradores. Una pila común puede convertir estos incentivos en poder adquisitivo.

El riesgo es que "Ultra Ethernet" se convierta en un paraguas para conjuntos de características incompatibles. Si el enrutamiento básico funciona pero los perfiles, la congestión, la seguridad y la gestión difieren, la marca podría extenderse más rápido que la interoperabilidad. Si la licencia RAND es costosa o ambigua, el número de proveedores podría reducirse. Si los productos RoCE absorben las ideas más atractivas sin un nuevo transporte, UEC podría influir en el mercado sin convertirse en el nombre dominante.

La pregunta crítica ya no es si el consorcio puede publicar una especificación avanzada. Lo ha hecho. La pregunta es si las organizaciones independientes pueden implementar los mismos contratos, licenciar la tecnología necesaria, operar el tejido a gran escala y mantener la compatibilidad a medida que evoluciona la especificación. UEC solo se convertirá en infraestructura en la medida en que estas afirmaciones resistan en sistemas en funcionamiento.