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. Es un consorcio industrial para el desarrollo de especificaciones, no una empresa ordinaria ni un operador de redes.
  • El alcance de UEC va mucho más allá de un enlace Ethernet más rápido o un sustituto de RoCE. La especificación 1.0.3, de 573 páginas, abarca las capas de software, transporte, red, enlace y física; además, incluye trabajos sobre gestión, almacenamiento, pruebas y conformidad.
  • Ultra Ethernet Transport combina múltiples modos de entrega, multirrutas a nivel de paquete, retransmisión selectiva, control de congestión impulsado por el emisor y el receptor, ECN, recorte de paquetes opcional, repetición de enlace local opcional, control de flujo basado en créditos opcional y seguridad de transporte de extremo a extremo opcional.
  • Los productos y demostraciones de AMD, Broadcom, Nokia y Keysight muestran que la implementación ha comenzado. Sin embargo, la conformidad pública se basa principalmente en autodeclaraciones de los implementadores; no se ha publicado un registro de certificación independiente exhaustivo ni un censo de despliegues a gran escala.
  • La oportunidad estratégica de UEC reside en la base instalada de Ethernet y la cadena de suministro con múltiples proveedores. Los mayores riesgos son la complejidad de los puntos finales, la fragmentación por funciones opcionales, las obligaciones de patentes RAND, la gestión y pruebas inmaduras, y la brecha entre una especificación publicada y la interoperabilidad demostrada en producción.

Por qué la IA ha convertido la red en parte del ordenador

El Ultra Ethernet Consortium surgió de un cambio en la economía de la computación. En una red empresarial convencional, el fabric debe transportar muchos flujos de datos independientes con un rendimiento y una disponibilidad aceptables. En cambio, en un gran sistema de entrenamiento de IA o en una máquina de computación de alto rendimiento, la red se convierte en parte de un único cálculo sincronizado. Miles de aceleradores pueden intercambiar parámetros de modelo, gradientes o datos científicos en operaciones colectivas. Una fase puede no avanzar hasta que el participante más lento reciba la información necesaria.

Por lo tanto, incluso un pequeño desequilibrio entre caminos, un evento de congestión o una pérdida de paquete puede dejar costosos procesadores esperando, aunque la utilización media del fabric parezca saludable.

Esto cambia los objetivos de optimización de los operadores. El ancho de banda agregado sigue siendo importante, pero no suficiente. Igualmente relevantes son el tiempo de finalización del trabajo, la latencia de cola, el incast, la corrección de pérdidas, la distribución del tráfico por caminos paralelos y la cantidad de estado que deben mantener los puntos finales. Una red que entrega casi todos los paquetes rápidamente, pero retrasa una pequeña fracción, puede detener toda una operación colectiva.

Un procedimiento de repetición aceptable para el tráfico convencional puede perder demasiado tiempo si solo falta un paquete en un mensaje largo. Un flujo vinculado a un único camino equivalente puede tener un rendimiento inferior aunque en otras partes de la topología quede capacidad libre.

La tesis fundacional de UEC era que estos problemas no pueden resolverse con una única función nueva de conmutador o un algoritmo de congestión revisado. La ruta de comunicación comienza por encima de la red, en bibliotecas de software y semántica de aplicaciones. Atraviesa el registro de memoria, las operaciones remotas, el estado de transporte, la entrega de paquetes, el control de congestión, el reenvío IP, los enlaces Ethernet, la óptica y la señalización física. Si estas capas se diseñan de forma independiente, una optimización en un lugar puede simplemente desplazar 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 conocen estas tecnologías y porque se ha formado una enorme cadena de suministro en torno a conmutadores, óptica, cables, sistemas operativos de red, telemetría y gestión. Al mismo tiempo, modifica o amplía aquellas áreas que el consorcio considera insuficientes para las grandes cargas de trabajo de IA y HPC. El resultado no es “Ethernet ordinaria con un logotipo nuevo”. Es el intento de que una red familiar soporte un transporte especializado cuyo comportamiento está definido desde la API de software hasta la velocidad de línea.

Esta distinción explica la importancia de UEC para la infraestructura digital. El proyecto no posee aceleradores, fábricas, centros de datos ni regiones de nube. Define contratos que las empresas miembros y otros implementadores pueden incorporar en NIC, ASIC de conmutación, sistemas, controladores, bibliotecas y equipos de prueba. La influencia solo surge cuando estos productos independientes intercambian datos correctamente en condiciones de error, congestión, actualizaciones y combinaciones de múltiples proveedores.

Qué es UEC, y qué no es

Ultra Ethernet Consortium es el nombre público de un proyecto formal cuya serie legal es Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. La estructura de serie asigna el proyecto a la Joint Development Foundation y a la familia más amplia de Linux Foundation. Proporciona un marco legal existente para la afiliación, la gobernanza, la propiedad intelectual, la financiación y las relaciones externas, sin necesidad de que los participantes creen una nueva sociedad independiente.

Esta estructura es importante porque a menudo se describe a UEC con imprecisión como una empresa, una alianza o una organización de normalización. No es una empresa comercial con accionistas, capital propio, valoración o estados financieros presentados por separado. No vende productos Ethernet, no opera una red pública y no posee el hardware que promocionan sus miembros. Es un consorcio de desarrollo de especificaciones con un marco jurídico y de propiedad intelectual. Sus documentos públicos pretenden convertirse en contratos de implementación entre múltiples empresas.

UEC tampoco es sinónimo de Ultra Ethernet Transport. UET es la arquitectura de transporte central de la especificación, pero el trabajo del consorcio es más amplio. Incluye la correspondencia con el software a través de libfabric, la semántica de paquetes y mensajes, los supuestos de red, las opciones de capa de enlace, los requisitos de capa física, la gestión, la armonización del almacenamiento, el rendimiento y la depuración, la conformidad y las pruebas. Reducirlo a “un nuevo protocolo RDMA” oculta el diseño transversal que hace que el proyecto sea ambicioso y difícil a la vez.

UEC tampoco es el grupo de trabajo IEEE 802.3. IEEE 802.3 desarrolla estándares básicos de Ethernet MAC y PHY mediante su propio procedimiento formal. UEC se apoya en ese ecosistema y mantiene un enlace, pero no lo sustituye. La misma frontera se aplica a los mecanismos de IETF por debajo de UET, incluidos IPv4, IPv6 y Explicit Congestion Notification; al ecosistema OpenFabrics, que mantiene libfabric; y a las organizaciones que trabajan en almacenamiento, hardware abierto e interconexiones de aceleradores.

El sitio web del proyecto ha utilizado expresiones que sugieren el estatus de una organización internacional de normalización. La descripción más segura y mejor documentada es: UEC es una organización internacional de desarrollo de especificaciones bajo el marco JDF. No hay evidencia de que UEC forme parte de la International Organization for Standardization, de que sus documentos sean normas ISO o de que posea un número de norma ISO. La diferencia no es solo lingüística. Muestra de dónde emana la autoridad, cómo funciona la participación y a qué obligaciones legales pueden enfrentarse los implementadores.

Por lo tanto, UEC debe juzgarse por su función real. Coordina a competidores y operadores en torno a un diseño técnico común, publica especificaciones, gestiona grupos de trabajo y declaraciones de patentes, desarrolla documentación de conformidad y relaciones con organizaciones vecinas. Por sí misma, una declaración no puede hacer que un producto sea interoperable ni lograr que el mercado adopte su arquitectura.

La coalición fundacional de nueve empresas

El consorcio fue anunciado el 19 de julio de 2023 por nueve organizaciones situadas en distintos puntos 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 amplitud fue una ventaja estratégica desde el principio. Un transporte desarrollado solo por proveedores de conmutadores podría pasar por alto las limitaciones de las aplicaciones y los puntos finales. Un diseño dirigido únicamente por fabricantes de aceleradores podría optimizarse estrechamente en torno a un ecosistema de hardware.

Un proyecto puramente de 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 punto final. Arista y Cisco contribuyeron con experiencia en conmutación y operación de Ethernet a gran escala. Broadcom proporcionó silicio de conmutación, NIC y SerDes de alta velocidad. HPE y Eviden incorporaron sistemas HPC y la trayectoria de las interconexiones especializadas. Intel contribuyó con experiencia en procesadores, Ethernet y software. Meta y Microsoft representaron a operadores de hiperescala con un interés directo en aumentar la utilización de grandes clústeres de IA y reducir la dependencia de un único proveedor integrado.

La coalición también contiene intereses comerciales contrapuestos. Los miembros venden NIC, ASIC de conmutación, sistemas, capacidad de nube, óptica, software y soporte. Algunos poseen carteras de patentes que podrían ser necesarias para una implementación. Algunos se benefician de un estándar amplio de múltiples proveedores, al tiempo que pueden ganar dinero con funciones propietarias diferenciadas. El consorcio no elimina la competencia. Crea un foro en el que los competidores acuerdan interfaces mínimas y siguen compitiendo en calidad de implementación, rendimiento, integración y condiciones comerciales.

La interconexión Slingshot de HPE es un ejemplo útil de herencia técnica. Slingshot es un fabric HPC comercial compatible con Ethernet, con enrutamiento adaptativo y gestión de congestión. Comentarios cercanos a HPE han afirmado que se contribuyó a UEC una especificación “HPC Ethernet” y han estimado que una gran parte de UET procede de ideas de transporte de Slingshot. El porcentaje exacto no está verificado de forma independiente y no debe tratarse como un cálculo del consorcio. El punto más amplio está bien documentado: UEC no empezó desde cero, sino que se nutrió de la experiencia de producción en HPC, redes de nube, RDMA y Ethernet.

Esta mezcla de sistemas heredados es una razón para usar la palabra “abierto” con precisión. La especificación ratificada de UEC es descargable públicamente. La arquitectura está pensada para implementaciones de múltiples proveedores. Sin embargo, el proyecto también es un lugar donde los miembros aportan conocimientos, patentes y hojas de ruta de productos existentes. La apertura del documento no anula las condiciones económicas o legales de la tecnología.

Una serie jurídica para la colaboración entre competidores

El modelo de la Joint Development Foundation proporciona a UEC una envoltura formal sin convertirlo en una empresa operativa ordinaria. El proyecto tiene su propio nombre, alcance, clases de miembros, Comité Directivo, grupos de trabajo y compromisos de propiedad intelectual. El paraguas de JDF ofrece infraestructura corporativa y sin ánimo de lucro, y puede mantener activos y contratos del proyecto. Esto reduce los costos de formación del consorcio y ofrece a los competidores un procedimiento reconocido para la colaboración.

El Comité Directivo dirige el proyecto. Entre sus funciones documentadas se 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 destitución de la presidencia, el control del progreso y la dirección de las publicaciones y las marcas del proyecto. Se prefiere el consenso. Si fracasa, la carta prevé un mecanismo de supermayoría de tres cuartos entre los miembros con derecho a voto que cumplan los requisitos de asistencia. Las quejas por escrito pueden dirigirse a la presidencia.

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

Estos roles no sustituyen necesariamente a los títulos formales de la especificación; no se dispone públicamente de un organigrama completo y actualizado.

La carta reconoce tres clases de miembros: Steering, General y Contributor. Los miembros Steering participan en la gobernanza y normalmente designan representantes para el Comité Directivo. Los miembros General pueden trabajar en todos los grupos técnicos, pero no forman parte del Comité Directivo. Los miembros Contributor participan en grupos seleccionados y no tienen derecho a voto en las decisiones por supermayoría. La página pública actual de membresía ofrece los niveles General y Contributor con cuotas anuales del proyecto de 20.000 y 5.000 dólares estadounidenses respectivamente, además de la afiliación a Linux Foundation.

No explica claramente la vía de admisión ni el precio actual para el estatus Steering.

Las diferencias en el poder formal son relevantes. Una membresía amplia puede aportar experiencia y alcance de implementación, pero la gobernanza no está distribuida de manera uniforme. Las grandes empresas que ocupan puestos Steering, despliegan ingenieros en muchos grupos y pueden mantener programas de patentes y productos, ejercen 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 redacción y no participan en igualdad de condiciones.

La información interna del proyecto no se trata como datos confidenciales corporativos ordinarios, pero los miembros no deben revelar material en borrador antes de que el comité correspondiente autorice su publicación. Esto facilita las conversaciones entre competidores sobre ideas inacabadas sin señales prematuras al mercado. Al mismo tiempo, los observadores externos no pueden ver las propuestas rechazadas, las actas de votación, las preocupaciones intermedias sobre la implementación ni las negociaciones que hay detrás de las funciones opcionales. El resultado final es abierto; el camino hasta él solo es parcialmente visible.

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

La primera estructura pública de UEC, en 2023, se centraba en cuatro grupos de trabajo: Software, Transporte, Enlace y Capa Física. El orden reflejaba la pretensión de extremo a extremo. La membresía no se abrió inmediatamente como una lista de correo pública sin restricciones. Más de 200 organizaciones habían manifestado interés y el consorcio realizó la incorporación por fases, con orientación sobre procesos y derecho de la competencia. Esta precaución era comprensible porque los participantes compiten directamente en varios mercados y discutirían requisitos comunes de productos y protocolos.

En diciembre de 2023, UEC informó de unas 40 empresas y más de 300 personas. Había establecido un Technical Advisory Committee y se había ampliado a ocho grupos de trabajo. La tarea del TAC era la coherencia arquitectónica: un diseño de transporte no debía presuponer un comportamiento de conmutación, un método de señalización o una API que otro grupo no hubiera acordado. 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.

La actualización de marzo introdujo las ideas que más tarde aparecerían en la especificación normativa: libfabric como API del lado del software, Packet Spraying, ordenación flexible, múltiples modos de entrega, control de congestión impulsado por el emisor y el receptor, ECN, recorte de paquetes, Link Layer Retry, control de flujo opcional basado en créditos, seguridad en el transporte y futuras operaciones colectivas dentro de la red. También subrayó que UET podría funcionar sobre conmutadores Ethernet existentes, mientras que los conmutadores mejorados podrían proporcionar un rendimiento adicional.

El alcance institucional creció en paralelo al trabajo técnico. UEC informó de 1.193 participantes activos en julio de 2024 y de 97 organizaciones miembros en agosto. Se trata de cifras fechadas del consorcio, basadas en definiciones no completamente públicas. No deben sumarse mecánicamente a cifras posteriores. En 2025, UEC declaró que se habían incorporado otras 27 empresas; sin embargo, las salidas, fusiones y solapamientos en los períodos de notificación impiden una suma exacta y actualizada. El propio sitio web señala que no se muestran todos los miembros.

El consorcio publicó Ultra Ethernet Specification 1.0 el 11 de junio de 2025. Con esto, UEC pasó de ser una hoja de ruta a una base de implementación pública. La versión 1.0.1 llegó en septiembre, corrigiendo el algoritmo fuente del control de créditos basado en el receptor, así como aspectos editoriales. La versión 1.0.2 apareció en enero de 2026, corrigiendo algoritmos de gestión de congestión; los documentos oficiales discrepan sobre si la fecha de publicación fue el 21 o el 28 de enero. La inconsistencia debe permanecer visible y no resolverse de forma encubierta.

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. Consta de 573 páginas y añade soporte para señalización de 200 Gb/s por línea, así como una capacidad de negociación booleana. Las notas de la versión mencionan además correcciones necesarias en la entrega de paquetes, los créditos de congestión, el Link Layer Retry y los Control Ordered Sets de la capa física, así como aclaraciones sobre la seguridad del transporte, las operaciones atómicas y los paquetes recortados.

La diferencia entre correcciones necesarias y aclaraciones editoriales es importante: algunos cambios afectan al comportamiento conforme y, por tanto, al mantenimiento de las implementaciones.

La Member Summit 2026 en Denver mostró una segunda transición. La agenda se centró en el despliegue, la productización, la conformidad, la gestión, el rendimiento, la depuración, la integración del almacenamiento y las pruebas de conmutadores y puntos finales. El documento arquitectónico central existe; la credibilidad del proyecto depende ahora cada vez más de si los implementadores pueden construir, cualificar, operar y actualizar la pila a través de las fronteras organizativas.

Una arquitectura a través de cinco capas funcionales

La especificación actual divide Ultra Ethernet 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 conectan las capas entre sí.

En la parte superior, los frameworks de IA, MPI, SHMEM y las bibliotecas colectivas interactúan a través de OpenFabrics Interfaces, en particular libfabric. El UET Semantic Services Sublayer traduce las operaciones de la aplicación en transacciones de transporte. El Packet Delivery Sublayer decide cómo empaquetar, ordenar, confirmar y recuperar los mensajes. La Congestion Management controla cuántos datos entran en el fabric y cómo se distribuye el tráfico entre los caminos. La seguridad de transporte opcional protege el tráfico de extremo a extremo. El IPv4 o IPv6 estándar se encarga del reenvío en la capa de red.

Ethernet proporciona el enlace con recorte de paquetes opcional, Link Layer Retry, control de flujo basado en créditos y negociación de funciones. La capa física define los requisitos de estadísticas y señalización a 100 o 200 Gb/s por línea.

Esta estructura conserva partes importantes de la red existente. UEC no define un sustituto para el enrutamiento IP. Se espera el Equal-Cost Multipath convencional y conmutadores compatibles con ECN. Gran parte de la inteligencia permanece en los puntos finales del fabric, que manipulan la entropía, rastrean el estado del transporte, colocan los datos y reaccionan a las señales de congestión. Los conmutadores mejorados pueden añadir funciones, pero el diseño no exige que cada instalación reemplace todo su fabric antes de que el tráfico UET pueda pasar.

Esto crea una ventaja de migración y un problema de clasificación. Una instalación puede desplegar puntos finales UET sobre Ethernet convencional con ECMP y ECN. Otra puede añadir recorte, repetición de enlace, créditos por canal virtual, telemetría más rica y, más adelante, funciones en la red. Ambas pueden llamarse “Ultra Ethernet”, aunque el rendimiento, la recuperación y la complejidad operativa difieran considerablemente.

El enfoque de cinco capas también complica la localización de fallos. Un mal resultado puede deberse al mapeo de la aplicación, a la máquina de estados del punto final, a los parámetros de congestión, a la configuración de las colas del conmutador, al mapeo DSCP, a la óptica, al firmware o al sistema de seguridad. Reenviar paquetes no es suficiente. El sistema debe preservar la semántica y el rendimiento previstos bajo escalado, tráfico mixto, errores y cambios de versión.

El contrato de software: libfabric en lugar de una API de aplicación propietaria

UEC elige libfabric 2.0 como API northbound fundamental para los puntos finales conformes. Esta decisión vincula el proyecto a un ecosistema existente de HPC y redes avanzadas, en lugar de obligar a cada framework a adoptar una nueva interfaz propietaria. Libfabric ya describe fabrics, dominios, puntos finales, colas de finalización, colas de eventos, vectores de direcciones, regiones de memoria, mensajería, operaciones de memoria remota y atómicas. UEC mapea y limita estos conceptos para que los proveedores puedan traducir las llamadas en comportamientos 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 mientras el proveedor subyacente cambia. En principio, una aplicación puede solicitar una operación sin saber qué proveedor suministra la NIC para la entrega de paquetes o qué silicio de conmutación reenvía los paquetes. Este es un mecanismo clave por el cual un transporte común podría permitir la elección de proveedor.

La abstracción no garantiza implementaciones equivalentes. Los proveedores pueden diferir en el tamaño de inyección, los límites de scatter/gather, el número de puntos finales, las operaciones atómicas, el registro de memoria, el comportamiento de finalización, la descarga por hardware y las funciones de seguridad. Una biblioteca compilada contra la misma API puede encontrar, por tanto, límites de rendimiento o capacidad diferentes. La adquisición y la cualificación del software requieren más que una marca de verificación en “soporta libfabric”.

La capa de software de UEC también incorpora semántica de trabajos y autorización. Los sistemas de IA y HPC suelen ejecutar muchos trabajos en infraestructura compartida, cada uno con sus propios procesos, regiones de memoria y límites de seguridad. La especificación debe determinar qué punto final pertenece a cada trabajo, a qué búferes se puede acceder, cómo se mapean las operaciones remotas y cómo llegan al software la información de finalización o error. Estas decisiones determinan si una red rápida es utilizable para el planificador, el tiempo de ejecución y la aplicación, o si solo impresiona en una prueba de paquetes de laboratorio.

El proyecto depende del ecosistema OpenFabrics, ya que no es propietario de libfabric. Esta relación ilustra una característica más amplia de UEC: la arquitectura está compuesta por componentes controlados en diferentes lugares. UEC puede definir cómo se mapea su transporte en libfabric, pero debe coordinarse con los mantenedores y usuarios de la API. Existen dependencias similares con IEEE Ethernet, las redes IETF, las organizaciones de almacenamiento y los sistemas operativos de los proveedores.

Puntos finales del fabric y perfiles de carga de trabajo

Un punto final del fabric, o FEP, es el lugar lógico donde termina UET. Conecta una instancia del sistema operativo con uno o varios planos de fabric aislados y puede contener un proveedor de espacio de usuario, un controlador del kernel, el transporte del lado de la NIC o del acelerador, el registro de memoria, el contexto de seguridad, las colas de finalización, los vectores de direcciones y el estado para la entrega de paquetes y el control de congestión.

Este diseño centrado en los puntos finales permite que la mayoría de los conmutadores sigan siendo reconocibles como dispositivos Ethernet e IP. 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 las confirmaciones, los recortes y otras retroalimentaciones. Esto puede reducir la dependencia de la inteligencia de enrutamiento propietaria en el conmutador. Al mismo tiempo, 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 diferentes, sino paquetes que establecen qué funciones debe soportar una implementación. AI Base está pensado para cubrir la comunicación de IA ordinaria con costos de implementación y estado más bajos. AI Full añade funciones como envíos diferibles, coincidencia exacta y operaciones atómicas de tipo fetch o compare. El perfil HPC incluye la mayor parte de AI Full, excluye los envíos diferibles y da más peso a la ordenación, los mensajes cortos y la semántica HPC.

El sistema de perfiles pretende evitar que cada producto tenga que implementar el conjunto completo de funciones. Reconoce que una NIC de IA de alto volumen puede priorizar el movimiento colectivo de datos, mientras que un punto final HPC necesita una ordenación y atómicas más sólidas. La opcionalidad no desaparece, sin embargo. Un producto puede implementar funciones opcionales dentro de un perfil, y dos productos con la misma etiqueta de perfil pueden diferir en seguridad, extensiones de enlace, capacidad y rendimiento.

La propia terminología es una señal de advertencia. La especificación normativa 1.0.3 utiliza AI Base, AI Full y HPC. Un archivo de conformidad independiente de 2025 utiliza AI Base, AI Extended y HPC. La interpretación mejor respaldada es que “AI Full” es el término actual y que el material de conformidad está desactualizado o es inconsistente. Hasta que se corrija el paquete de pruebas público, los proveedores y compradores deben indicar tanto la versión de la especificación como el lenguaje exacto del perfil que respalda una afirmación.

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

Dentro de UET, el Semantic Services Sublayer transporta la intención de la aplicación. Define la identidad del mensaje, el direccionamiento de búferes, las operaciones etiquetadas y no etiquetadas, el acceso a memoria remota, las operaciones atómicas, el comportamiento de finalización, los identificadores de trabajo, la autorización de búferes, las respuestas y los errores. A continuación, el Packet Delivery Sublayer determina cómo se convierten esas intenciones en paquetes y cómo llegan a otro punto final.

Para los modos fiables, los puntos finales establecen contextos de entrega de paquetes (Packet Delivery Contexts, PDC). Un PDC contiene estado como números de secuencia de paquetes, confirmaciones, detección de duplicados, modo de ordenación, información de congestión, estado de la ruta de retorno y clase de tráfico. Un PDC está asociado a un modo de entrega y a una clase de tráfico; pueden existir varios PDC entre el mismo par de FEP.

Este estado no es un detalle de implementación menor. Los grandes clústeres pueden generar enormes cantidades de relaciones de comunicación. Si cada relación requiere un estado de destino extenso, el almacenamiento de los puntos finales y los costos de búsqueda pueden limitar la escalabilidad. Por eso UEC no obliga a que cada operación utilice un único modelo de conexión, sino que define cuatro servicios 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 la llegada fuera de orden. Admite Packet Spraying sobre múltiples caminos, retransmisión selectiva, supresión de duplicados y colocación directa de datos. Dado que el destino puede colocar los datos basándose en los desplazamientos, en lugar de esperar a un búfer de reordenamiento de transporte, una operación colectiva larga puede utilizar múltiples caminos sin serializar todos los paquetes detrás de una unidad faltante.

La entrega fiable ordenada (Reliable Ordered Delivery, ROD) garantiza una entrega exactamente una vez y ordenada. Utiliza un camino y un valor de entropía, descarta los paquetes fuera de orden y emplea una recuperación Go-Back-N a partir del primer número de secuencia faltante. Esto parece menos sofisticado que RUD, pero preserva la semántica para las operaciones en las que se requiere un orden estricto. UEC trata la ordenación como un requisito de la aplicación, en lugar de hacer que cada transmisión soporte su costo.

La entrega fiable no ordenada para operaciones idempotentes (Reliable Unordered Delivery for Idempotent Operations, RUDI) tiene un enfoque diferente. Entrega al menos una vez y permite duplicados, lo que reduce el estado normal de secuencia y confirmación en el destino. Esto puede ser útil cuando una operación repetida no altera el resultado final, como en ciertas transferencias de memoria remota con una barrera separada posterior. Es peligrosa si se utiliza incorrectamente. La capa de paquetes no deduce por sí misma la idempotencia; el software debe decidir.

Usar RUDI para una operación no idempotente puede generar un estado de aplicación inválido.

La entrega no fiable no ordenada (Unreliable Unordered Delivery, UUD) ofrece datagramas de mejor esfuerzo sin garantías normales de fiabilidad u ordenación. Pertenece al mismo marco semántico, pero no tiene los mismos requisitos de control de congestión que RUD y ROD. Las aplicaciones deben evitar que UUD perjudique al tráfico controlado por congestión si se comparten colas o clases de tráfico.

Los cuatro modos muestran una filosofía central de UEC: la red debe proporcionar múltiples mecanismos para que el software adapte los costos de transporte a la semántica de la operación. El beneficio es la eficiencia. El costo es una mayor superficie de implementación y prueba, con más posibilidades de que el proveedor, la aplicación o el operador elijan una combinación incompatible.

Packet Spraying: aprovechar el fabric en lugar de esperar un camino afortunado

El Equal-Cost Multipath convencional suele asignar, mediante un hash, todo un flujo a una ruta. En un fabric Clos amplio, esto crea una lotería. Varios flujos grandes pueden colisionar en los mismos enlaces, mientras que una capacidad equivalente permanece sin usar en otras partes. Una transferencia larga de IA queda entonces limitada durante toda su vida por un hash desafortunado.

UET responde a esto variando la entropía a nivel de paquete. Un emisor puede utilizar docenas o cientos de valores de entropía, de modo que los mecanismos ECMP existentes en los conmutadores distribuyan los paquetes por muchas rutas. El Packet Delivery Sublayer proporciona la información de secuencia; el Congestion Management Sublayer selecciona la entropía o la ruta; los conmutadores ejecutan su hash normal; la retroalimentación informa al emisor sobre qué valores son sospechosos de congestión.

El Packet Spraying solo es factible porque otras partes del diseño lo respaldan. Los paquetes pueden llegar fuera de orden. RUD puede colocar los datos directamente en lugar de esperar a un reordenamiento completo del transporte. La retransmisión selectiva solo recupera lo perdido. La retroalimentación de congestión reduce el uso de los caminos problemáticos. El mecanismo no es, por tanto, un truco de equilibrio de carga aislado, sino un componente de un modelo de transporte que se basa en la diversidad de caminos.

UEC no exige que cada conmutador implemente un algoritmo de enrutamiento adaptativo propietario. Las implementaciones básicas pueden utilizar la entropía round-robin o pseudoaleatoria sobre ECMP estándar. Los puntos finales más avanzados pueden asignar señales de ECN, latencia o recorte a valores de entropía específicos y evitar los caminos congestionados. El reenvío adaptativo específico de cada proveedor puede coexistir con UET, pero no es la única fuente de conocimiento de los caminos.

La promesa es una mejor utilización del fabric y una menor latencia de cola. Queda por ver con qué uniformidad interpretan los distintos puntos finales la retroalimentación y cómo interactúa el Packet Spraying con los búferes de los conmutadores, el reordenamiento, los errores y el tráfico mixto. Un algoritmo que funciona en un laboratorio homogéneo puede comportarse de manera diferente en un fabric grande con varias generaciones de conmutadores y clases de tráfico. Las evidencias independientes con múltiples proveedores siguen siendo limitadas.

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

UEC no define un algoritmo de congestión universal. Distingue entre la congestión en el núcleo de la red, el incast en el receptor y los búferes limitados de los puntos finales.

El control de congestión por señales de red (Network-signal Congestion Control, NSCC) está dirigido por la fuente. El emisor mantiene una ventana de congestión, estima los bytes en vuelo y ajusta la ventana en función de las confirmaciones, las confirmaciones negativas, los tiempos de espera, la latencia y las señales de red como ECN. El comportamiento de la ventana se coordina con el multirruta a nivel de paquete. UEC argumenta que una ventana detiene por sí misma la admisión de nuevos datos cuando los paquetes dejan de salir de la red, mientras que un controlador puramente basado en tasa podría malinterpretar la falta de retroalimentación.

Esta es la tesis arquitectónica del consorcio, no una prueba independiente de que cualquier implementación de NSCC supere a DCQCN u otros métodos de congestión de RoCE. Los resultados dependen de los detalles del algoritmo, el marcado del conmutador, la topología, los patrones de tráfico y los parámetros. Por tanto, “usa NSCC” no es una declaración de rendimiento suficiente.

El control de congestión por créditos del receptor (Receiver-credit Congestion Control, RCCC) se dirige al incast. Cuando muchas fuentes envían simultáneamente a un único destino, el último enlace puede convertirse en el cuello de botella aunque el núcleo de la red no esté congestionado. El receptor realiza un seguimiento de la demanda y distribuye créditos entre los emisores, regulando así la llegada total y variando la ventana efectiva de cada fuente según la competencia. RCCC puede funcionar junto con NSCC porque la congestión del receptor y la del núcleo son problemas diferentes.

El control de flujo de transporte (Transport Flow Control, TFC) también utiliza créditos, pero está pensado para servicios punto a punto con búferes limitados. Su objetivo es evitar directamente el desbordamiento del búfer receptor cuando la tolerancia a las pérdidas es baja. TFC puede usarse con o sin multirruta. Equiparar todos los mecanismos de crédito ocultaría los distintos dominios de fallo que cada uno debe controlar.

La especificación espera Explicit Congestion Notification en todo el fabric e incluye supuestos operativos sobre el marcado, incluido el marcado en la salida de la cola y no solo en la entrada. Los puntos finales interpretan ECN junto con las confirmaciones, la latencia y el recorte. Una configuración uniforme de los conmutadores es, por tanto, indispensable. Una implementación de transporte correcta puede dar malos resultados en un fabric mal configurado.

El historial de mantenimiento muestra la dificultad. La versión 1.0.1 corrigió el algoritmo fuente de RCCC. La versión 1.0.2 corrigió casos de gestión de congestión. La versión 1.0.3 corrigió las interacciones entre créditos y Link Layer Retry. Son signos normales de una especificación viva, pero también evidencias de que los estados de crédito, retransmisión y control de caminos interactúan de forma sutil. Los operadores necesitan disciplina de versiones y pruebas de regresión, no solo conformidad el primer día.

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

El recorte de paquetes (Packet Trimming) cambia lo que hace un conmutador adecuado cuando no puede conservar un paquete completo. En lugar de descartar la trama sin más información, el conmutador elimina la mayor parte o toda la carga útil, conserva suficientes cabeceras y metadatos para la identificación, marca el paquete como “recortado” y reenvía la notificación acortada al receptor. Este puede entonces informar al emisor de los datos concretos que faltan.

Esto es más informativo que una marca ECN. ECN indica que se ha producido congestión; el recorte señala un paquete cuya carga útil no ha sobrevivido. Combinado con RUD y la retransmisión selectiva, esto puede acelerar la recuperación sin esperar un tiempo de espera ni reenviar una larga ráfaga por una sola pérdida.

La función del conmutador es opcional, pero los puntos finales conformes deben poder recibir e interpretar los paquetes recortados según los requisitos aplicables. Esta asimetría permite despliegues sobre conmutadores convencionales, a la vez que ofrece a los fabrics mejorados información de pérdidas más rica. Al mismo tiempo, crea un problema de actualización. Una red parcialmente mejorada puede tener que limitar el recorte por camino, perfil o topología para que todos los puntos finales receptores lo manejen correctamente.

UEC también define diferentes clases de tráfico para las peticiones, los paquetes de control, las retransmisiones y el tráfico recortado. Los operadores deben mapear de forma coherente los valores DSCP, las colas del conmutador, las colas de los puntos finales y los niveles de prioridad. La especificación no proporciona un sistema de gestión universal para ello. Un mapeo incorrecto puede privar de recursos al 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 deben reparar.

El recorte de paquetes ilustra la mayor tarea de implementación del proyecto. El protocolo puede definir el comportamiento en el cable, pero el resultado operativo depende del encolado del conmutador, la lógica del punto final, la telemetría, la configuración y el manejo de errores. La interoperabilidad es una propiedad del sistema, no solo del formato de paquete.

Recuperación de enlace, créditos y negociación de funciones

La repetición a nivel de enlace (Link Layer Retry, LLR) intenta corregir errores en un enlace físico antes de que reaccione el transporte de extremo a extremo. Un par detecta un hueco de secuencia o una trama dañada, envía una confirmación negativa local al enlace y hace que el emisor repita la trama afectada desde un búfer local. Si la recuperación es rápida, el transporte puede evitar una retransmisión de extremo a extremo más larga.

El valor potencial aumenta con las velocidades de línea y la densidad de puertos. Los errores ópticos o eléctricos ocasionales podrían causar retrasos desproporcionados en un trabajo estrechamente sincronizado. Sin embargo, LLR añade estado de secuencia, búferes de repetición, mensajes de control, ventanas de descarte y nuevos modos de error. Debe coexistir con las actualizaciones de créditos y los reinicios de enlace. La versión 1.0.3 corrigió varios casos extremos, incluida una condición de carrera entre la información de créditos CBFC y LLR.

El control de flujo basado en créditos (Credit-Based Flow Control, CBFC) opera a nivel de enlace por canal virtual. Informa al emisor de cuánta capacidad de recepción queda y puede ser más granular que una pausa de prioridad amplia. UEC lo describe como un medio para un comportamiento controlado sin pérdidas sin necesidad de hacer que todo el fabric UET sea completamente libre de pérdidas. CBFC es opcional y UET debe funcionar también en redes de mejor esfuerzo.

CBFC no es simplemente otro nombre para Priority Flow Control. La señalización y la granularidad difieren, aunque ambos pretenden evitar el desbordamiento de búferes. CBFC sigue exigiendo una configuración uniforme y la entrega correcta de sus propias tramas de control. Los créditos locales pueden además interactuar con las ventanas de extremo a extremo y los créditos del receptor, creando múltiples bucles de control anidados.

UEC utiliza una negociación basada en LLDP para descubrir funciones de enlace opcionales y evitar que un lado active una capacidad que el vecino no soporta. La negociación debe tener en cuenta los perfiles, los canales virtuales, el mapeo DSCP y de prioridad, los reinicios, las actualizaciones de software y las combinaciones parciales de funciones. La versión 1.0.3 añadió una capacidad de negociación booleana, lo que subraya la necesidad de un acuerdo explícito en cada enlace.

Estas opciones crean un camino desde la Ethernet básica a la mejorada. Al mismo tiempo, generan una matriz que el lenguaje de adquisición puede ocultar. Un conmutador puede reenviar UET perfectamente sin soportar recorte, LLR o CBFC. Otro puede ofrecer las funciones solo en determinadas versiones de software o modos de puerto. Una prueba de despliegue creíble necesita el alcance exacto de las funciones, no solo el nombre del consorcio.

Señalización física a 100 y 200 Gigabits por línea

La capa física ancla a UEC en la hoja de ruta del hardware. El trabajo inicial de la versión 1.0 se centró en la señalización de 100 Gb/s por línea. La versión 1.0.3 añadió 200 Gb/s por línea. Esto alinea la especificación con una generación de enlaces y sistemas más densos; sin embargo, la presencia de la capacidad en el documento no prueba 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, las proporciones de palabras de código corregibles e incorregibles, los Control Ordered Sets, los informes de calidad del enlace y la interacción de los errores físicos con LLR. Estos detalles son importantes porque las decisiones de recuperación del transporte dependen de lo que las capas inferiores pueden observar e informar.

A velocidades de señalización más altas, la frontera entre la óptica, el SerDes, el FEC, la repetición de enlace y la recuperación del transporte adquiere importancia económica. Un FEC más fuerte puede reducir los errores residuales a costa de la latencia y la energía. La repetición de enlace puede corregir errores locales más rápidamente, pero requiere búferes y estado. La retransmisión de extremo a extremo es más sencilla en toda la red, pero puede desperdiciar más tiempo. UEC intenta definir cómo interactúan estas capas, en lugar de dejar que cada proveedor optimice de forma aislada.

La adición de líneas de 200G también muestra el objetivo móvil del consorcio. 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 qué soporta cada puerto. Los compradores no deben inferir la velocidad de línea a partir de una declaración genérica de UEC.

Seguridad de transporte opcional de extremo a extremo

La subcapa de seguridad del transporte (Transport Security Sublayer, TSS) ofrece una protección opcional de extremo a extremo. Su modelo de amenaza no requiere confiar en los conmutadores. Puede proporcionar confidencialidad, integridad, protección contra repeticiones, aislamiento de trabajos, dominios seguros, claves de grupo, rotación de claves y la integración de raíces de confianza basadas en hardware.

El diseño utiliza dominios seguros cuyos miembros comparten un contexto criptográfico. Los identificadores, los números de asociación, las épocas, la identidad de origen segura y la derivación de claves están pensados para escalar mejor que una sesión independiente para cada par de puntos finales. Esto es necesario cuando las poblaciones de aceleradores y las pertenencias a trabajos cambian rápidamente.

El protocolo es solo una parte del sistema de seguridad. Un operador en producción debe gestionar autoridades de claves, certificados u otras raíces de confianza, servicios de pertenencia a trabajos, distribución y revocación, cambios de época, recuperación de puntos finales, criptografía por hardware y telemetría de seguridad. Una red puede cumplir un perfil sin activar todas las funciones opcionales de TSS. “Conforme a UEC” no significa automáticamente “cifrado”.

La opcionalidad refleja diferentes supuestos de despliegue. Un fabric dedicado y físicamente controlado puede priorizar el rendimiento y confiar en medidas ambientales. Una nube multiinquilino puede requerir un fuerte aislamiento y protección criptográfica. Los sistemas de perfiles y adquisiciones deben hacer visible la diferencia.

El mayor riesgo no es solo la sobrecarga del cifrado. Es el fallo del ciclo de vida a gran escala: pertenencia obsoleta, revocación tardía, épocas inconsistentes, recuperación tras el fallo de un punto final o la incapacidad de demostrar qué trabajo puede acceder a qué memoria. Estos problemas vinculan la seguridad del transporte con los sistemas de orquestación e identidad, fuera de la especificación central.

Qué significa actualmente “conforme a UEC”

UEC comenzó a publicar documentación de conformidad con la versión 1.0, pero el sistema público no es un régimen de certificación independiente y maduro. El paquete disponible está diseñado principalmente para autodeclaraciones de los implementadores. Las matrices asignan los requisitos de la especificación a los perfiles, y las guías del banco de pruebas describen configuraciones recomendadas para puntos finales y conmutadores. No se ha encontrado un registro público exhaustivo en el que una entidad independiente inscriba productos como aprobados o no en un programa completo de UEC.

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

Las recomendaciones públicas para el banco de pruebas son útiles, pero deliberadamente limitadas. Proporcionan mejores prácticas de topologías y comprobaciones, en lugar de una cualificación completa del sistema. La interoperabilidad más amplia, el rendimiento, el estrés, la escala y el ciclo de vida de la API quedan excluidos o no se cubren por completo. Los materiales no demuestran el comportamiento con tráfico mixto UET y RoCE, actualizaciones parciales, errores repetidos, grandes dominios de claves o las cifras más ambiciosas de puntos finales del consorcio.

La inconsistencia entre AI Full y AI Extended muestra además por qué la conformidad necesita un versionado estricto. Los compradores deben preguntar qué especificación, nivel de corrección, perfil, funciones opcionales, modos de enlace y funciones de seguridad cubre una afirmación. La respuesta debe explicar si la evidencia procede de pruebas internas, una demostración bilateral, un evento del consorcio o un laboratorio independiente.

Un siguiente paso creíble serían definiciones de prueba públicas vinculadas a versiones exactas de la especificación, eventos de interoperabilidad con múltiples proveedores, resultados gestionados de forma independiente, incluidos los negativos, y un registro que distinga entre puntos finales, conmutadores, software y sistemas completos. Hasta entonces, “conforme a UEC” es una pregunta de partida, no una garantía completa.

Un documento abierto con obligaciones de patentes RAND

Ultra Ethernet Specification 1.0.3 es descargable públicamente y se distribuye bajo Creative Commons Attribution-NoDerivatives 4.0. Esto permite compartir con atribución, pero no distribuir versiones modificadas bajo esta licencia. Más importante aún, el acceso a los derechos de autor y el acceso a las patentes están separados.

Las cartas de los grupos de trabajo documentadas utilizan generalmente un modelo de especificación tradicional con licencias de patentes razonables y no discriminatorias (RAND). RAND no significa necesariamente libre de regalías. No garantiza un precio uniforme, no elimina las negociaciones y no previene disputas sobre validez, esencialidad, geografía o condiciones defensivas. La posición comercial real depende de cada patente declarada, del compromiso del miembro y de una licencia bilateral.

UEC mantiene un registro público de declaraciones de reclamaciones necesarias. En la fecha de corte, estaban visibles declaraciones de Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell y otras empresas, incluidas presentaciones para futuros trabajos de la versión 1.1. El registro aumenta la transparencia, ya que muestra que los implementadores deben examinar la propiedad intelectual antes de desarrollar o distribuir un producto.

El consorcio no decide expresamente si una patente declarada es válida, realmente esencial, infringida o está disponible a un precio determinado. Tampoco publica una licencia conjunta. Por tanto, los implementadores más pequeños pueden asumir costos legales y de transacción que los grandes miembros absorben con más facilidad. Una especificación públicamente disponible puede generar, no obstante, un ecosistema comercialmente concentrado si la liberación de patentes, los costos del silicio y el esfuerzo de prueba son elevados.

El marco de propiedad intelectual también condiciona los incentivos de gobernanza. Las empresas aportan tecnología para crear un mercado amplio para sus productos y para asegurarse de que sus capacidades existentes estén representadas en el diseño común. Las declaraciones de patentes solo protegen a los implementadores de sorpresas si se realizan a tiempo y con suficiente claridad. No eliminan la posibilidad de que las licencias se conviertan en una barrera tras una amplia adopción.

La descripción honesta es, por tanto, “publicado abiertamente y con múltiples proveedores, con obligaciones de patentes RAND”, no “universalmente libre de regalías”. Los equipos de adquisiciones necesitan tanto el perfil técnico como la vía de licencia.

La primera oleada de productos y pruebas

La evidencia de implementación se hizo visible en torno a la publicación de la versión 1.0, pero los ejemplos se encuentran en diferentes estados de madurez.

AMD puso a disposición comercial su NIC para IA Pollara 400 en abril de 2025, describiéndola como concebida en torno a las capacidades UEC en evolución. Pollara es una plataforma de punto final programable y una señal importante de que el transporte ha pasado al hardware en envío. La redacción es crucial: diseñar para funciones UEC en evolución no es una certificación independiente contra todos los requisitos finales de la versión 1.0.3.

Broadcom anunció Tomahawk 6 en junio de 2025 como un ASIC de conmutación de 102,4 terabits por segundo con funciones relevantes para UEC. En octubre le siguió la NIC Thor Ultra 800G, con la afirmación del proveedor de plena conformidad con las funciones UEC. Es una declaración significativa, pero la evidencia pública no la convierte en un certificado independiente del consorcio. El muestreo, la madurez del software y el soporte exacto del perfil deben acreditarse por separado.

Nokia y Keysight anunciaron en octubre de 2025 una demostración de extremo a extremo de tráfico UET a través de las familias de conmutadores para centros de datos 7220 y 7250 de Nokia a 800 Gigabit Ethernet. Keysight proporcionó la generación de tráfico y la validación. La prueba muestra que el tráfico UET puede atravesar sistemas de conmutación comerciales y que está surgiendo soporte en equipos de prueba. No demuestra un perfil completo de puntos finales de múltiples proveedores, escala de producción ni certificación independiente de todas las funciones opcionales.

Otros miembros han descrito conmutadores, sistemas, software o planes de prueba compatibles con UEC, y la cumbre de 2026 se centró intensamente en la productización. La evidencia respalda la transición a la implementación. Todavía no respalda una cifra exacta de NIC UET en envío, conmutadores certificados, regiones de nube en producción o fabrics completos.

Lo más razonable es leer la oleada de productos como una cadena de evidencia. Una especificación pública permite el diseño. Los anuncios de silicio y NIC muestran inversión. Las demostraciones de tráfico muestran parte de la interoperabilidad. Las matrices de conformidad mapean los requisitos. Los informes de despliegue de los operadores demostrarían el valor operativo. Las pruebas de interoperabilidad independientes y los resultados en producción establecerían la credibilidad más amplia que aún falta en el acervo actual.

RoCE, InfiniBand, Slingshot y UALink

UEC entra en un mercado con alternativas maduras y tecnologías adyacentes. El argumento estratégico no es que Ethernet nunca haya transportado RDMA o que los fabrics especializados no funcionen. Es que la escala y la sincronización de las cargas de trabajo de IA actuales justifican una nueva arquitectura Ethernet de extremo a extremo con una entrega, un uso de los caminos y un control de congestión más flexibles.

RoCEv2 es el predecesor directo y una tecnología instalada importante. Transporta RDMA sobre Ethernet enrutable y cuenta con un amplio respaldo de aplicaciones y productos. UEC critica las instalaciones habituales de RoCE por vincular flujos completos a un solo camino, la recuperación Go-Back-N, el reordenamiento en el receptor, la difícil sintonización de DCQCN, la dependencia de Priority Flow Control en muchos diseños y un comportamiento débil ante el incast o las ráfagas colectivas. Estas son posiciones técnicas de UEC, no pruebas de que todas las redes RoCE funcionen mal.

La comparación es dinámica. Los proveedores pueden incorporar enrutamiento adaptativo, Packet Spraying, mejores algoritmos de congestión u otras funciones similares a UEC en NIC programables y mantener la compatibilidad con RoCE. La presentación que AMD hace de Pollara, por ejemplo, presenta RoCEv2 y UEC RDMA como opciones en hardware programable. Por tanto, UEC puede competir con RoCE como transporte completo e influir al mismo tiempo en el desarrollo de futuros productos RoCE.

InfiniBand es la principal alternativa de fabric especializado. Ofrece un ecosistema integrado de RDMA, congestión, fiabilidad de enlace y gestión, con una larga experiencia en HPC. El trabajo 2.0 de la InfiniBand Trade Association incluye soporte XDR para 200 Gb/s por línea y telemetría actualizada. La principal diferenciación de UEC no es la afirmación de que a InfiniBand le falte rendimiento. Es la posibilidad de lograr un comportamiento de IA y HPC a través de la cadena de suministro más amplia de Ethernet, el enrutamiento IP estándar y una mayor capacidad de elección entre múltiples proveedores.

HPE Slingshot ocupa una posición intermedia. Es un fabric HPC comercial compatible con Ethernet, con enrutamiento adaptativo y gestión de congestión, y proporcionó importantes precursores técnicos para UET. Muestra que se puede construir un comportamiento especializado sobre Ethernet y, al mismo tiempo, la diferencia entre una plataforma comercial controlada y una especificación de ámbito sectorial.

UALink es en su mayor parte complementario, no un sustituto directo. Su especificación pública actual de 200G apunta a conexiones scale-up de baja latencia entre aceleradores dentro de un pod y describe sistemas con hasta 1.024 aceleradores. UEC 1.0 es principalmente un fabric scale-out que conecta nodos a través de conmutadores. Un centro de datos puede usar un enlace scale-up dentro de un pod de cómputo y UEC entre pods o nodos. El futuro trabajo de UEC en transporte scale-up optimizado y colectivas en la red puede acercar las fronteras y generar convergencia o competencia.

NVIDIA Spectrum-X y los fabrics propietarios de aceleradores son otra comparación. Una pila estrechamente integrada puede optimizar rápidamente el hardware, el software y el soporte, pero aumenta la dependencia de un solo ecosistema. UEC intercambia parte de esa integración por la promesa de interfaces comunes y elección de proveedores. Si el intercambio es sensato depende del rendimiento, el soporte, las condiciones de las patentes, la interoperabilidad y el costo total de propiedad, no de la “apertura” como etiqueta abstracta.

El problema operativo es mayor que el protocolo

Una especificación de 573 páginas puede definir muchos requisitos, pero un fabric en producción necesita un modelo operativo. UEC 1.0 deja un trabajo de gestión importante fuera del núcleo normativo o en sus márgenes. Los operadores deben configurar de forma coherente los perfiles, las clases de tráfico, los umbrales de ECN, las cantidades de entropía, las funciones de enlace opcionales, las claves, el firmware, la telemetría y las reglas de error en los puntos finales y los conmutadores.

El tráfico mixto complica la tarea. Un fabric de centro de datos puede transportar UET, RoCE, TCP, almacenamiento, gestión y los servicios ordenados y no ordenados de UET. La asignación de colas y la equidad entre estas clases no se resuelven solo con que cada protocolo esté correctamente implementado. Un algoritmo de congestión puede funcionar bien de forma aislada y mal en competencia con otro controlador que tenga retroalimentación y supuestos diferentes.

La complejidad de los puntos finales es otro riesgo estructural. UET sitúa en el FEP el multirruta, la colocación directa, la retransmisión selectiva, múltiples modos de entrega, el control por ventanas y créditos, la recepción de recortes, la seguridad y una gran cantidad de estado. Esto puede aumentar el área del chip de la NIC, el tamaño del firmware, el esfuerzo de verificación, el consumo de energía y el número de condiciones de error a diagnosticar. La inteligencia en el punto final permite una cadena de suministro amplia, pero puede trasladar la implementación más difícil al componente que cada servidor debe comprar.

Las funciones opcionales crean simultáneamente diferenciación de producto y fragmentación. Un proveedor puede optimizar un punto final AI Base básico para ECMP y ECN convencionales. Otro soporta AI Full, TSS, recorte, LLR y CBFC. Ambos pertenecen al ecosistema UEC, pero los operadores no deben asumir la misma semántica, rendimiento o seguridad. Las matrices de conformidad deben convertirse en matrices de capacidad operativa.

El mantenimiento de versiones será continuo. Las correcciones de la 1.0.1 a la 1.0.3 afectaron a la congestión, los créditos, la repetición y el comportamiento de los paquetes. Un gran clúster puede contener varios estados de firmware de NIC, versiones de conmutador y herramientas de prueba. Actualizar una capa sin coordinarla con las demás puede desencadenar precisamente la condición de carrera entre capas que el consorcio quiere evitar.

Las alianzas externas de UEC son, por tanto, centrales, no ceremoniales. El Open Compute Project vincula el transporte con sistemas y hardware abiertos. La OpenFabrics Alliance y la comunidad libfabric conectan las aplicaciones. IEEE 802.3 proporciona el trabajo formal de Ethernet. SNIA y NVM Express aportan requisitos de almacenamiento y gestión. Las tecnologías IETF proporcionan IP, ECN y mecanismos relacionados. Estas organizaciones tienen procesos de decisión y hojas de ruta diferentes; el enlace reduce la duplicación, pero no garantiza una adopción simultánea.

La prueba operativa definitiva es la infraestructura en funcionamiento. Un documento puede establecer un comportamiento, un proveedor puede anunciar un producto y un consorcio puede organizar una cumbre. Nada de esto sustituye a un clúster en el que puntos finales y conmutadores independientes completen trabajos reales bajo congestión, errores y actualizaciones, y los operadores puedan explicar lo que ha ocurrido.

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

Para julio de 2026, UEC había alcanzado varios objetivos que eran inciertos en el momento de su lanzamiento. Formó una amplia coalición, creó una arquitectura integrada de cinco capas, publicó una especificación 1.0 completa, la mantuvo con versiones de corrección, añadió 200G por línea, divulgó declaraciones de patentes y atrajo anuncios de productos y pruebas. El proyecto está activo y su agenda ha virado claramente hacia la implementación.

Este progreso hace que las siguientes incertidumbres sean más importantes, no menos. La membresía exacta actual y la composición del Comité Directivo no están publicadas en un único registro autorizado. Las páginas públicas de membresía y la carta describen el acceso de manera diferente. El liderazgo formal del TAC no está completamente alineado con los roles de la cumbre. La fecha de la versión 1.0.2 es contradictoria en los documentos oficiales. El paquete de conformidad utiliza una terminología de perfiles obsoleta.

Ninguno de estos puntos destruye la arquitectura, pero cada uno es una señal sobre el control documental y la transparencia en un proyecto donde las versiones exactas importan.

Las lagunas más significativas se refieren a la adopción. UEC no publica un censo de despliegues, ni un registro de productos auditado de forma independiente, ni un presupuesto propio, ni estados financieros auditados. La evidencia pública no demuestra una red UEC 1.0 completamente interoperable en los objetivos de escala máximos del consorcio. Las demostraciones y afirmaciones de los proveedores son valiosas, pero provienen de partes con intereses comerciales. Las comparaciones de rendimiento neutrales con RoCE, InfiniBand y plataformas Ethernet integradas actuales siguen siendo limitadas.

La oportunidad sigue siendo considerable. Ethernet es el denominador común de los centros de datos, y el mercado de infraestructura para IA es lo suficientemente grande para nuevas generaciones de NIC, conmutadores, óptica y software. Los operadores tienen fuertes incentivos para evitar la dependencia de un único proveedor y aumentar la utilización de los aceleradores. Una pila común podría traducir esos incentivos en poder de adquisición.

El riesgo es que “Ultra Ethernet” se convierta en un paraguas para subconjuntos de funciones incompatibles. Si el reenvío básico funciona, pero los perfiles, la congestión, la seguridad y la gestión divergen, la marca puede extenderse más rápido que la interoperabilidad. Si las licencias RAND son costosas o poco claras, el círculo de proveedores puede estrecharse. Si los productos RoCE adoptan las ideas más atractivas sin un nuevo transporte, UEC puede influir en el mercado sin convertirse en la etiqueta dominante.

La cuestión decisiva ya no es si el consorcio puede publicar una especificación ambiciosa. Lo ha hecho. La cuestión es si organizaciones independientes pueden implementar los mismos contratos, licenciar la tecnología necesaria, operar el fabric a gran escala y mantener la compatibilidad durante su evolución. UEC solo se convertirá en infraestructura en la medida en que estas pretensiones resistan el contacto con el código en ejecución.