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 de especificación industrial, y no de una empresa convencional o de un operador de red.
• El alcance de la UEC va más allá de un enlace Ethernet más rápido o una simple sustitución de RoCE. Su especificación 1.0.3 de 573 páginas cubre las capas de software, transporte, red, enlace y física, con trabajos complementarios sobre gestión, almacenamiento, pruebas y conformidad.
• Ultra Ethernet Transport combina múltiples modos de entrega, múltiples rutas a nivel de paquete, retransmisión selectiva, controles de congestión gestionados por el emisor y el receptor, ECN, truncamiento opcional de paquetes, recuperación local opcional, control de flujo por 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, pero la conformidad pública todavía se basa sobre todo en la autocertificación de los proveedores, sin un registro completo de certificación independiente ni un censo de los despliegues a gran escala.
• La oportunidad estratégica de la UEC proviene de la base instalada de Ethernet y de su cadena de suministro de múltiples proveedores. Sus principales riesgos son la complejidad de los extremos, la fragmentación por funciones opcionales, las obligaciones de patentes RAND, la madurez limitada de la gestión y las pruebas, y la brecha entre la publicación de una especificación y la interoperabilidad verificada en producción.

Por qué la IA convirtió la red en parte del ordenador

El Ultra Ethernet Consortium nació de una transformación de la economía del cómputo. En una red empresarial ordinaria, la fábrica debe transportar muchos flujos independientes con un rendimiento y una disponibilidad aceptables. En un gran sistema de entrenamiento de inteligencia artificial o una máquina de computación de alto rendimiento, la red se convierte en un componente del mismo cálculo sincronizado. Miles de aceleradores pueden intercambiar parámetros de modelo, gradientes o datos científicos durante operaciones colectivas. Una fase puede quedar bloqueada hasta que el participante más lento haya recibido la información requerida.

Un ligero desequilibrio de ruta, un episodio de congestión o una pérdida de paquete puede, por tanto, dejar procesadores muy costosos inactivos, aunque el uso medio de la fábrica parezca satisfactorio.

Los criterios de optimización cambian. El ancho de banda agregado sigue siendo importante, pero ya no es suficiente. Los operadores también monitorizan el tiempo de finalización de las tareas, la latencia de cola, el incast, la recuperación tras pérdida, la distribución del tráfico entre rutas paralelas y la cantidad de estado que los extremos deben mantener. Una red que entrega rápidamente la mayoría de los paquetes pero retrasa una pequeña fracción puede ralentizar toda una operación colectiva. Un método de retransmisión aceptable para el tráfico convencional puede perder demasiado tiempo cuando falta un solo paquete en un mensaje largo.

Un flujo fijado en una sola ruta ECMP puede rendir por debajo de lo esperado mientras hay capacidad disponible en otras partes de la topología.

La propuesta fundacional de la UEC era que estas dificultades no podían resolverse con una sola función de conmutador ni con un único algoritmo de congestión. El camino de la comunicación comienza por encima de la red, en las bibliotecas de software y la semántica de la aplicación. Atraviesa el 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 por separado, una optimización local puede simplemente desplazar el cuello de botella o crear suposiciones incompatibles en otro lugar.

La respuesta de la UEC es una arquitectura coordinada. Conserva Ethernet e IP porque los operadores ya los conocen y existe una inmensa cadena industrial en torno a los conmutadores, las ópticas, los cables, los sistemas operativos de red, la telemetría y la gestión. Sustituye o amplía las partes que el consorcio considera inadecuadas para las cargas de trabajo de IA y HPC a gran escala. El resultado no es «Ethernet ordinario con un nuevo logo». Es un intento de hacer que una red familiar soporte un transporte especializado cuyo comportamiento se define desde la API de software hasta la velocidad por carril.

Esta distinción explica la importancia de la UEC para las infraestructuras digitales. El proyecto no posee aceleradores, ni fábricas, ni centros de datos, ni regiones cloud. Define los contratos que sus miembros y otros implementadores pueden integrar en tarjetas de red, ASIC de conmutación, sistemas, controladores, bibliotecas y equipos de prueba. Su influencia solo se hará real cuando estos productos independientes intercambien correctamente tráfico en situaciones de fallo, congestión, actualización y mezcla de múltiples proveedores.

Qué es la UEC — y qué no es

Ultra Ethernet Consortium es el nombre público de un proyecto formal cuya serie jurídica se titula Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. Esta estructura en serie sitúa el proyecto en la Joint Development Foundation y, más ampliamente, en la familia de la Linux Foundation. Ofrece a los participantes un marco preexistente para la adhesión, la gobernanza, la propiedad intelectual, la financiación y las relaciones externas, sin exigir la creación de una nueva sociedad autónoma.

Esta estructura es importante, porque a menudo se describe a la UEC de forma imprecisa como una empresa, una alianza o un organismo de normalización. No es una sociedad comercial con accionistas, capital, valoración o cuentas depositadas por separado. No vende productos Ethernet, no explota redes públicas y no posee el hardware promovido por sus miembros. Se trata de un consorcio de desarrollo de especificaciones dotado de un marco jurídico y de propiedad intelectual. Sus documentos públicos tienen la vocación de convertirse en contratos de implementación entre varias empresas.

La UEC tampoco es sinónimo de Ultra Ethernet Transport. UET es la arquitectura de transporte en el corazón de la especificación. Los trabajos del consorcio son más amplios: mapeo de software hacia libfabric, semántica de mensajes y paquetes, suposiciones de red, opciones de capa de enlace, requisitos físicos, gestión, alineación con el almacenamiento, rendimiento y depuración, conformidad y pruebas. Reducir el proyecto a «un nuevo protocolo RDMA» ocultaría precisamente la ambición transversal que lo hace a la vez prometedor y difícil.

La UEC tampoco es el grupo de trabajo IEEE 802.3. IEEE 802.3 elabora las normas esenciales de capa MAC y física Ethernet según su propio proceso formal. La UEC depende de este ecosistema y mantiene una vinculación con él, pero no lo sustituye. El mismo límite se aplica a los mecanismos IETF subyacentes a UET, en particular IPv4, IPv6 y Explicit Congestion Notification; al ecosistema OpenFabrics que mantiene libfabric; y a las organizaciones activas en almacenamiento, hardware abierto e interconexiones de aceleradores.

El sitio web del proyecto ha empleado una redacción que sugiere el estatus de organización internacional de normalización. La descripción más segura y mejor respaldada es la de una organización internacional de desarrollo de especificaciones bajo el amparo de la JDF. Nada permite afirmar que pertenezca a la Organización Internacional de Normalización, que sus documentos sean normas ISO o que dispongan de un número ISO. Este matiz no es cosmético: permite comprender de dónde proviene la autoridad del proyecto, cómo funciona la participación y qué obligaciones legales pueden recaer sobre los implementadores.

Por tanto, la UEC debe evaluarse según su función real. Coordina a competidores y operadores en torno a un diseño técnico común. Publica especificaciones, administra grupos de trabajo y declaraciones de patentes, desarrolla documentos de conformidad y mantiene relaciones con organizaciones afines. Pero ninguna declaración de intenciones basta para hacer un producto interoperable o para imponer su adopción en el mercado.

La coalición fundadora de nueve organizaciones

El consorcio fue anunciado el 19 de julio de 2023 por nueve organizaciones situadas en distintos 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 constituía desde el principio un activo estratégico. Un transporte diseñado únicamente por proveedores de conmutadores correría el riesgo de descuidar las limitaciones de las aplicaciones y de los extremos. Una arquitectura dominada por los fabricantes de aceleradores podría estar demasiado optimizada para un solo ecosistema.

Un proyecto liderado exclusivamente por nubes carecería quizás de la experiencia en silicio, óptica y sistemas necesaria para convertir una arquitectura en productos.

AMD aportaba procesadores, aceleradores y red de terminación. Arista y Cisco aportaban la conmutación Ethernet a gran escala y la experiencia operativa. Broadcom contribuía con ASIC de conmutación, tarjetas de red y SerDes de alta velocidad. HPE y Eviden aportaban los sistemas HPC y la trayectoria en interconexiones especializadas. Intel contribuía con procesadores, Ethernet y software. Meta y Microsoft representaban a operadores hiperescala directamente interesados en un mejor aprovechamiento de los grandes clústeres de IA y en una menor dependencia de un único proveedor integrado.

La coalición reunía también intereses comerciales contrapuestos. Sus miembros venden tarjetas de red, ASIC, sistemas, capacidad cloud, ópticas, software y soporte. Algunos poseen carteras de patentes potencialmente indispensables para la implementación. Algunos se benefician de una norma multi-proveedor amplia, al tiempo que pueden monetizar funciones propietarias diferenciadas. El consorcio no elimina, por tanto, la competencia. Crea un espacio donde los competidores acuerdan interfaces mínimas mientras siguen distinguiéndose por la calidad de implementación, el rendimiento, la integración y las condiciones comerciales.

La interconexión Slingshot de HPE ofrece un ejemplo útil de filiación técnica. Slingshot es una fábrica HPC compatible con Ethernet, dotada de funciones de enrutamiento adaptativo y gestión de congestión. Comentarios asociados a HPE indicaron que una especificación «HPC Ethernet» había sido aportada a la UEC y estimaron que una gran parte de UET procedía de ideas de transporte de Slingshot. El porcentaje exacto no ha sido verificado de forma independiente y no debe presentarse como una contabilidad del consorcio. El punto más amplio está sólidamente respaldado: la UEC no partió de un folio en blanco.

Se nutrió de la experiencia de producción en HPC, cloud, RDMA y Ethernet.

Esta mezcla de sistemas previos explica también por qué la palabra «abierto» debe definirse con precisión. La especificación ratificada se puede descargar públicamente y la arquitectura apunta a implementaciones multi-proveedor. Pero el proyecto es también un lugar donde los miembros aportan conocimiento existente, patentes y hojas de ruta de productos. La apertura del documento no elimina las condiciones económicas y jurídicas vinculadas a la tecnología.

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

El modelo de la Joint Development Foundation da a la UEC un envoltorio formal sin convertirla en una sociedad operativa convencional. El proyecto dispone de identidad, alcance, categorías de miembros, Comité de Dirección, grupos de trabajo y obligaciones de propiedad intelectual. El envoltorio de la JDF proporciona la infraestructura jurídica y sin ánimo de lucro, y puede ostentar los activos y acuerdos del proyecto. Este modelo reduce el coste de crear un consorcio y ofrece a los competidores un proceso reconocido para colaborar.

El Comité de Dirección gobierna el proyecto. Sus responsabilidades documentadas incluyen la coordinación de los grupos de trabajo, la aprobación de nuevos miembros, la gestión de activos y finanzas, la designación o sustitución del presidente, el seguimiento de los progresos y el control de la publicación y las marcas del proyecto. Se privilegia el consenso. En caso de no alcanzarse, los estatutos prevén una mayoría cualificada de tres cuartos entre los participantes elegibles que cumplan los requisitos de asistencia. Pueden dirigirse apelaciones por escrito al presidente.

El primer presidente fue Brad Booth, de Meta. La actual especificación 1.0.3 cita a J Metz, de AMD, como presidente; a Barry Davis, de HPE, como vicepresidente; a Hugh Holbrook, de Arista, como presidente del Comité Asesor Técnico; y a Puneet Agarwal, de Marvell, como vicepresidente del TAC. Paul Congdon figura como editor de la especificación. El documento identifica también a responsables y autores de los trabajos físico, de enlace, de transporte y de software. La agenda de la cumbre de 2026 menciona a otros responsables operativos.

Estos cargos de la cumbre no sustituyen necesariamente a los títulos formales de la especificación; los documentos públicos no proporcionan un organigrama actualizado completo.

Los estatutos reconocen tres categorías: Steering, General y Contributor. Los miembros Steering participan en la gobernanza y normalmente designan un representante en el Comité de Dirección. Los miembros General pueden trabajar en todos los grupos técnicos pero no tienen asiento en el comité. Los miembros Contributor participan en grupos seleccionados y no tienen derecho de voto en las decisiones por supermayoría. La página pública de adhesión comercializa los niveles General y Contributor, con tarifas anuales de 20 000 y 5 000 dólares estadounidenses, a lo que se suma la adhesión a la Linux Foundation.

No explica con claridad el proceso de admisión ni la tarifa actual del nivel Steering.

Esta diferencia de poder formal es importante. Una base amplia de miembros puede proporcionar experiencia y alcance de implementación, pero la gobernanza no está distribuida de forma igualitaria. Las grandes empresas capaces de ocupar posiciones Steering, de asignar ingenieros a varios grupos y de mantener programas de patentes y productos disponen de una influencia práctica superior a la de los pequeños miembros Contributor. Los no miembros pueden descargar la especificación final pero no ven todo el proceso de borrador y no participan en igualdad de condiciones.

La información interna no se considera secreto empresarial ordinario, pero los miembros no pueden hacer públicos los borradores antes de la aprobación del comité competente. Esta regla facilita la discusión entre competidores sin señalar al mercado orientaciones demasiado pronto. Impide también que los observadores externos conozcan las propuestas rechazadas, los votos, las preocupaciones provisionales de implementación o las negociaciones que condujeron a las funciones opcionales. La especificación final es abierta; el camino que conduce a ella solo lo es parcialmente.

Del lanzamiento con cuatro grupos a una especificación de 573 páginas

La estructura pública inicial de 2023 se basaba en cuatro grupos de trabajo: software, transporte, enlace y físico. Esta secuencia reflejaba la ambición de extremo a extremo del proyecto. La adhesión no se abrió como una lista de correo pública sin restricciones. Más de 200 organizaciones habían manifestado su interés, y el consorcio escalonó la integración a la vez que exigía formación sobre el proceso y las normas antimonopolio. Esta prudencia era comprensible, ya que los participantes son competidores directos en varios mercados y discuten requisitos comunes de productos y protocolos.

En diciembre de 2023, la UEC indicaba contar con alrededor de 40 empresas y más de 300 personas. Había creado un Comité Asesor Técnico y ampliado su estructura a ocho grupos. El TAC debía garantizar la coherencia arquitectónica: un transporte no podía suponer un comportamiento del conmutador, un método de señalización o una API que otro grupo no hubiera aceptado. En marzo de 2024, el consorcio anunciaba 55 empresas y más de 750 participantes activos y publicaba una presentación mucho más clara de su arquitectura prevista.

Esta actualización de marzo introducía las ideas principales que posteriormente se incorporaron a la especificación normativa: libfabric como API orientada a software, distribución de paquetes, orden flexible, varios modos de entrega, control de congestión del lado del emisor y del receptor, ECN, truncamiento de paquetes, Link Layer Retry, control de flujo por créditos opcional, seguridad de transporte y futuras operaciones colectivas en la red. Confirmaba asimismo que UET podía funcionar sobre conmutadores Ethernet existentes, y que los equipos enriquecidos podían aportar un rendimiento adicional.

El alcance institucional creció en paralelo. La UEC declaró 1 193 participantes activos en julio de 2024 y 97 organizaciones miembros en agosto. Se trata de cifras fechadas cuyas definiciones no son totalmente públicas. No deben sumarse mecánicamente con anuncios posteriores. En 2025, la UEC indicó la llegada de 27 nuevas empresas, pero las salidas, fusiones y períodos de referencia que se solapan impiden deducir un total actual exacto. El propio sitio web precisa que no todos los miembros aparecen publicados.

La versión 1.0 de Ultra Ethernet Specification se publicó el 11 de junio de 2025. A partir de ese momento, la UEC ya no era solo una hoja de ruta, sino una referencia de implementación pública. La versión 1.0.1, publicada en septiembre, corrigió el algoritmo fuente del control de congestión por créditos del receptor y problemas editoriales. La versión 1.0.2 llegó en enero de 2026 y corrigió algoritmos de congestión, pero dos documentos oficiales divergen entre el 21 y el 28 de enero. Esta incoherencia debe conservarse en lugar de resolverse silenciosamente.

La versión 1.0.3, publicada el 16 de julio de 2026, es la referencia actual en la fecha de investigación. Cuenta con 573 páginas y añade la señalización a 200 Gbit/s por carril, así como una capacidad de negociación booleana. Sus notas de versión identifican también correcciones obligatorias relativas a la entrega de paquetes, los créditos de congestión, Link Layer Retry y los conjuntos ordenados de control físico, así como aclaraciones sobre la seguridad de transporte, las operaciones atómicas y los paquetes truncados.

La distinción entre corrección obligatoria y aclaración editorial es esencial: algunas modificaciones cambian el comportamiento conforme y, por tanto, imponen tareas de mantenimiento a las implementaciones.

El Member Summit 2026 de Denver señaló una segunda transición. Su programa versaba sobre el despliegue, la puesta en producción, la conformidad, la gestión, el rendimiento, la depuración, la integración del almacenamiento y las pruebas entre conmutadores y extremos. El documento arquitectónico existe; la credibilidad del proyecto depende ahora más de la capacidad de los implementadores para construir, cualificar, explotar y actualizar la pila más allá de las fronteras organizativas.

Una sola arquitectura en cinco capas funcionales

La especificación actual reparte Ultra Ethernet entre las capas de software, transporte, red, enlace y física. Esta división es útil, pero el valor del proyecto reside en las hipótesis que vinculan estas capas.

En la cima, los frameworks de IA, MPI, SHMEM y las bibliotecas colectivas interactúan a través de OpenFabrics Interfaces, en particular libfabric. La subcapa de servicios semánticos de UET traduce las operaciones de la aplicación en transacciones de transporte. La subcapa de entrega de paquetes decide la segmentación, el orden, los acuses de recibo y la recuperación. La gestión de la congestión controla la cantidad de datos inyectados en la fábrica y su distribución entre rutas. La seguridad de transporte opcional protege los intercambios punto a punto. IPv4 o IPv6 aseguran el reenvío en la red.

Ethernet proporciona el enlace, con truncamiento, Link Layer Retry, control de flujo basado en créditos y negociación de funciones opcionales. La capa física especifica las estadísticas y la señalización a 100 o 200 Gbit/s por carril.

Esta estructura conserva elementos esenciales de la red existente. La UEC no define un sustituto para el enrutamiento IP. Espera de los conmutadores que proporcionen ECMP convencional y ECN. Gran parte de la inteligencia permanece en los extremos de la fábrica, que manipulan la entropía, mantienen el estado del transporte, colocan los datos y reaccionan a las señales de congestión. Los conmutadores enriquecidos pueden añadir funciones, pero el modelo no obliga a sustituir toda la fábrica antes de poder transportar UET.

Esto crea una ventaja de migración y un problema de clasificación. Un despliegue puede utilizar extremos UET sobre Ethernet convencional con ECMP y ECN. Otro puede añadir truncamiento, recuperación de enlace, créditos por canal virtual, telemetría avanzada y futuras operaciones en la red. Ambos pueden calificarse de Ultra Ethernet aun cuando sus prestaciones, características de recuperación y complejidad operativa difieran sensiblemente.

El enfoque en cinco capas hace también que los fallos sean más difíciles de aislar. Un mal resultado puede provenir del mapeo de la aplicación, la máquina de estados del extremo, los parámetros de congestión, la configuración de las colas, el mapeo DSCP, la óptica, el firmware o el sistema de seguridad. Hacer pasar paquetes no es suficiente. El sistema debe preservar la semántica y el rendimiento esperados a gran escala, con tráfico mixto, durante los fallos y en los cambios de versión.

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

La UEC elige libfabric 2.0 como API norte de referencia para los extremos conformes. Esta decisión vincula el proyecto a un ecosistema de software ya existente del HPC y las redes avanzadas, en lugar de exigir a cada framework la adopción de una nueva interfaz propietaria. Libfabric ya representa fábricas, dominios, extremos, colas de finalización, colas de eventos, vectores de direcciones, regiones de memoria, mensajes, operaciones de memoria remota y operaciones atómicas. La UEC mapea y restringe estos conceptos para que los proveedores puedan traducir las llamadas en comportamiento UET.

El valor estratégico es la continuidad por encima del transporte. MPI, SHMEM y las bibliotecas de comunicación de aceleradores pueden conservar abstracciones familiares mientras el proveedor subyacente cambia. En principio, una aplicación puede solicitar una operación sin conocer la marca de la tarjeta de red que asegura la entrega ni el silicio que conmuta los paquetes. Este es uno de los principales mecanismos mediante los cuales un transporte común podría crear una verdadera libertad de elección de proveedores.

La abstracción no garantiza implementaciones equivalentes. Los proveedores pueden ofrecer tamaños de inyección, límites de scatter-gather, número de extremos, operaciones atómicas, técnicas de registro de memoria, comportamientos de finalización, aceleraciones hardware y funciones de seguridad diferentes. Una biblioteca compilada para la misma API puede, por tanto, encontrarse con límites de capacidad o de rendimiento distintos. La compra y la cualificación del software exigen algo más que una casilla «compatible con libfabric».

La capa de software también conlleva la semántica de tareas y de autorización. Los sistemas de IA y HPC ejecutan a menudo muchos trabajos sobre una infraestructura compartida, cada uno con sus procesos, regiones de memoria y límites de seguridad. La especificación debe identificar qué extremo pertenece a qué trabajo, qué búferes pueden ser accesibles, cómo se empareja una operación remota y cómo la información de finalización o de error regresa al software. Estas decisiones determinan si la red rápida es realmente utilizable por el planificador, el runtime y la aplicación, en lugar de ser solo impresionante en un benchmark de paquetes.

El proyecto depende del ecosistema OpenFabrics, porque no posee libfabric. Esta relación ilustra una característica más general: la arquitectura UEC se ensambla a partir de componentes gobernados en otros lugares. La UEC puede definir cómo su transporte se mapea sobre libfabric, pero debe coordinarse con los mantenedores y usuarios de la API. Existen dependencias comparables con Ethernet IEEE, los mecanismos IETF, las organizaciones de almacenamiento y los sistemas operativos de los proveedores.

Extremos de la fábrica y perfiles de carga

Un extremo de la fábrica (Fabric Endpoint, FEP) es el punto lógico donde termina UET. Conecta una instancia de sistema operativo a una o varias fábricas aisladas y puede incluir un proveedor en espacio de usuario, un controlador del núcleo, un transporte en tarjeta de red o acelerador, un sistema de registro de memoria, un contexto de seguridad, colas de finalización, vectores de direcciones y el estado necesario para la entrega y el control de congestión.

Este diseño centrado en el extremo permite que los conmutadores sigan siendo principalmente equipos Ethernet e IP reconocibles. El FEP elige los valores de entropía, conserva el estado de paquete y de congestión, coloca los datos en la memoria autorizada e interpreta los acuses de recibo, el truncamiento y otras respuestas. Esto puede reducir la dependencia de una inteligencia de enrutamiento propietaria en el conmutador. También concentra la complejidad en el silicio de la tarjeta de red, su firmware, los controladores y el software.

La UEC define tres perfiles de implementación: AI Base, AI Full y HPC. No son tres redes diferentes, sino conjuntos de funciones obligatorias. AI Base está orientado a las comunicaciones de IA comunes con un coste y una cantidad de estado más bajos. AI Full añade, en particular, los envíos aplazables, el emparejamiento exacto y ciertas operaciones atómicas de lectura o comparación. El perfil HPC retoma la mayoría de las capacidades de AI Full, excluye el envío aplazable e insiste más en el orden, los mensajes pequeños y la semántica HPC.

El sistema de perfiles busca evitar que cada producto tenga que implementar el conjunto máximo. Reconoce que una tarjeta de IA de gran volumen puede privilegiar los intercambios colectivos, mientras que un extremo HPC puede exigir un orden más fuerte y más operaciones atómicas. Los perfiles no suprimen, sin embargo, las opciones. Un producto puede implementar funciones opcionales dentro de un perfil, y dos productos con la misma etiqueta pueden aún diferir en seguridad, mejoras de enlace, capacidad y rendimiento.

La terminología ya constituye una señal de alerta. La especificación 1.0.3 que sirve de autoridad emplea AI Base, AI Full y HPC. Un documento de conformidad de 2025 utiliza AI Base, AI Extended y HPC. La interpretación más sólida es que «AI Full» es la denominación actual y que el documento de conformidad es antiguo o incoherente. Mientras el paquete de pruebas no se corrija, los proveedores y compradores deben identificar la versión de la especificación y el vocabulario exacto que hay detrás de cada afirmación.

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

En UET, la subcapa de servicios semánticos transporta la intención de la aplicación. Define la identidad de los mensajes, el direccionamiento de los búferes, las operaciones con o sin etiqueta, el acceso a memoria remota, las operaciones atómicas, el comportamiento de finalización, los identificadores de trabajo, la autorización de los búferes, las respuestas y los errores. La subcapa de entrega de paquetes determina a continuación cómo esta intención se convierte en paquetes y cómo estos alcanzan el otro extremo.

Para los modos fiables, los extremos establecen contextos de entrega de paquetes (Packet Delivery Contexts, PDC). Un PDC contiene, en particular, los números de secuencia, los acuses de recibo, la detección de duplicados, el modo de orden, las informaciones de congestión, el estado de la vía de retorno y la clase de tráfico. Un PDC corresponde a un modo de entrega y una clase de tráfico, y pueden existir varios PDC entre los mismos FEP.

Esta cantidad de estado no es secundaria. Los grandes clústeres pueden crear un número muy elevado de relaciones de comunicación. Si cada una exige un estado de destino importante, la memoria y el coste de búsqueda se convierten en limitantes. La UEC no fuerza, por tanto, todas las operaciones en un único modelo de conexión. Define cuatro servicios con contratos diferentes.

La entrega no ordenada fiable (Reliable Unordered Delivery, RUD) garantiza una entrega exactamente una vez a la capa semántica, permitiendo al mismo tiempo una llegada desordenada. Soporta la distribución de paquetes en varias rutas, la retransmisión selectiva, la eliminación de duplicados y la colocación directa de datos. Como el destino puede colocar los datos según sus offsets en lugar de esperar un búfer de reordenación del transporte, una operación colectiva larga puede explotar varias rutas sin bloquear todos los paquetes detrás de una sola unidad faltante.

La entrega ordenada fiable (Reliable Ordered Delivery, ROD) garantiza una entrega exactamente una vez y en orden. Utiliza una sola ruta y un solo valor de entropía, rechaza los paquetes fuera de orden y se basa en una recuperación Go-Back-N a partir del primer número faltante. Este modelo parece menos avanzado que RUD, pero preserva la semántica necesaria para las operaciones que exigen un orden estricto. La UEC trata el orden como un requisito de la aplicación más que como un coste impuesto a todas las transferencias.

La entrega no ordenada fiable para operaciones idempotentes (Reliable Unordered Delivery for Idempotent Operations, RUDI) realiza otro compromiso. Garantiza una entrega al menos una vez y permite duplicados, lo que reduce el estado ordinario de secuencia y acuse de recibo en el destino. Puede convenir para ciertos movimientos de memoria remota seguidos de una barrera separada. Se vuelve peligrosa si se aplica mal: la capa de paquete no deduce si una operación es idempotente. El software debe saberlo. Utilizar RUDI para una operación no idempotente puede invalidar el estado de la aplicación.

La entrega no ordenada no fiable (Unreliable Unordered Delivery, UUD) proporciona datagramas de mejor esfuerzo sin garantía normal de fiabilidad u orden. Pertenece al mismo marco semántico pero no asume las mismas exigencias de control de congestión que RUD y ROD. Las aplicaciones deben evitar perjudicar al tráfico controlado cuando UUD comparte las mismas colas o clases.

Estos cuatro modos revelan una filosofía central: la red debe exponer varios mecanismos para que el software alinee el coste del transporte con la semántica de la operación. El beneficio es la eficiencia. El precio es una superficie de implementación y prueba más amplia, con más combinaciones incompatibles posibles.

Distribuir los paquetes: utilizar toda la fábrica en lugar de una ruta afortunada

El ECMP convencional fija a menudo un flujo entero en una sola ruta mediante un hash. En una amplia fábrica Clos, esto crea una lotería: varios flujos pesados pueden encontrarse en los mismos enlaces mientras una capacidad equivalente permanece libre en otro lugar. Una larga transferencia de IA puede verse limitada por este mal reparto durante toda su duración.

UET modifica la entropía a nivel de cada paquete. El emisor puede utilizar decenas o centenas de valores, lo que deja a los mecanismos ECMP existentes la posibilidad de repartir los paquetes entre varias rutas. La subcapa de entrega de paquetes proporciona la secuencia, la subcapa de gestión de congestión elige la entropía o la ruta, los conmutadores aplican su hash normal, y los acuses de recibo indican al emisor qué valores parecen congestionados.

Esta distribución solo es practicable porque los demás componentes la soportan. Los paquetes pueden llegar desordenados. RUD puede colocar los datos directamente en lugar de esperar una reordenación completa. La retransmisión selectiva solo recupera lo que falta. Las señales de congestión reducen el uso de las rutas difíciles. No se trata, pues, de un simple truco de equilibrado, sino de un modelo de transporte construido en torno a la diversidad de rutas.

La UEC no exige que cada conmutador ejecute un algoritmo propietario de enrutamiento adaptativo. Las implementaciones básicas pueden usar una selección pseudoaleatoria o rotatoria sobre el ECMP estándar. Los extremos más avanzados pueden asociar ECN, latencia o truncamiento a ciertos valores de entropía y evitar las rutas problemáticas. Un enrutamiento adaptativo específico de un proveedor puede coexistir con UET, pero no es la única fuente de conciencia de ruta.

La promesa es una mejor utilización y una latencia de cola más baja. La cuestión abierta es la coherencia con la que diferentes extremos interpretan los acuses de recibo y la manera en que la distribución interactúa con los búferes, el desorden, los fallos y los tráficos mixtos. Un algoritmo eficaz en un laboratorio homogéneo puede comportarse de otro modo en una gran fábrica compuesta por varias generaciones de conmutadores. Las pruebas independientes y multi-proveedor siguen siendo limitadas.

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

La UEC no define un algoritmo universal. Distingue la congestión en el núcleo de la red, el incast en el receptor y los límites de búfer del extremo.

El control de congestión señalizado por la red (Network-signal Congestion Control, NSCC) está pilotado por la fuente. El emisor mantiene una ventana de congestión, estima los octetos en vuelo y ajusta esta ventana en función de los acuses de recibo, NACK, retardos, latencia y señales de la red como ECN. Coordina la ventana con el uso de múltiples rutas a nivel de paquete. La UEC sostiene que una ventana deja de admitir datos de forma natural cuando los paquetes ya no abandonan la red, mientras que un controlador puramente basado en la tasa puede interpretar mal una respuesta ausente.

Se trata del argumento arquitectónico del consorcio, no de una prueba independiente de que cualquier implementación NSCC supere a DCQCN u otros controles RoCE. Los resultados dependen de los detalles del algoritmo, el marcado de los conmutadores, la topología, el tráfico y los parámetros. «Utiliza NSCC» no es, por tanto, una afirmación de rendimiento suficiente.

El control de congestión por créditos del receptor (Receiver-credit Congestion Control, RCCC) tiene como objetivo el incast. Cuando numerosas fuentes envían simultáneamente hacia un destino, el último enlace puede convertirse en el cuello de botella mientras el núcleo no está congestionado. El receptor sigue la demanda, distribuye créditos, controla el ritmo de llegada agregada y adapta la ventana implícita de cada fuente en función de la concurrencia. RCCC puede funcionar con NSCC, ya que la sobrecarga del receptor y la congestión del núcleo son diferentes.

El control de flujo de transporte (Transport Flow Control, TFC) emplea también créditos, pero para servicios punto a punto que disponen de pequeños búferes y toleran mal la pérdida. Su objetivo es impedir directamente el desbordamiento. Puede utilizarse con o sin múltiples rutas. Confundir todos los mecanismos de crédito ocultaría los distintos ámbitos de fallo que controlan.

La especificación espera ECN en toda la fábrica y formula hipótesis operativas, en particular el marcado a la salida en lugar de exclusivamente a la entrada. Los extremos interpretan ECN junto con los acuses de recibo, la latencia y el truncamiento. Por tanto, es indispensable una configuración coherente de todos los conmutadores. Un transporte puede estar correctamente implementado y dar malos resultados en una fábrica mal configurada.

El historial de mantenimiento muestra la dificultad. La versión 1.0.1 corrigió el algoritmo fuente de RCCC. La 1.0.2 corrigió casos de gestión de congestión. La 1.0.3 corrigió interacciones entre créditos y Link Layer Retry. Estas correcciones son normales para una especificación viva, pero también demuestran que los créditos, las retransmisiones y las rutas interactúan de manera sutil. Los operadores deberán mantener una disciplina de versiones y pruebas de regresión, y no solo una conformidad inicial.

Truncamiento de paquetes y recuperación precisa tras una pérdida

El truncamiento cambia lo que hace un conmutador capaz cuando no puede conservar un paquete entero. En lugar de descartar la trama sin información, elimina toda o parte de la carga útil, conserva suficiente cabecera y metadatos para identificar el paquete, lo marca como truncado y transmite esta notificación reducida al receptor. Este puede entonces señalar con precisión los datos faltantes al emisor.

Esta información es más rica que un marcado ECN. ECN indica que se ha encontrado congestión; el truncamiento identifica un paquete cuya carga útil no ha sobrevivido. Con RUD y la retransmisión selectiva, puede acelerar la recuperación sin esperar un timeout ni retransmitir una larga secuencia por una sola pérdida.

La función de conmutación es opcional, pero los extremos conformes deben recibir e interpretar los paquetes truncados según los requisitos aplicables. Esta asimetría permite el despliegue sobre conmutadores convencionales al tiempo que da a las fábricas enriquecidas una respuesta más precisa. También crea un problema de actualización. Una red parcialmente modernizada deberá quizás limitar el truncamiento en función de las rutas, los perfiles o las topologías para que todos los receptores lo comprendan.

La UEC define igualmente clases diferenciadas para las peticiones, los paquetes de control, las retransmisiones y el tráfico truncado. Los operadores deben mapear de forma coherente los valores DSCP, las colas de los conmutadores y de los extremos, así como los niveles de prioridad. La especificación no proporciona un sistema universal de gestión de este mapeo. Un error puede hacer pasar hambre al tráfico de control, deformar la respuesta de congestión o poner los paquetes de recuperación en competencia con los flujos que deben reparar.

El truncamiento ilustra el desafío global del proyecto. El protocolo puede definir el comportamiento en el cable, pero el resultado depende de las colas, la lógica de terminación, la telemetría, la configuración y la gestión de fallos. La interoperabilidad es una propiedad del sistema, no solo del formato de paquete.

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

Link Layer Retry (LLR) intenta recuperar una corrupción en un enlace físico antes de la reacción del transporte de extremo a extremo. Un par detecta una ruptura de secuencia o una trama corrupta, envía un NACK de enlace y provoca la relectura de la trama desde un búfer local. Si la recuperación tiene éxito rápidamente, el transporte puede evitar una retransmisión más larga.

El valor potencial aumenta con la velocidad por carril y la densidad de puertos. Errores ópticos o eléctricos ocasionales pueden, de otro modo, producir un retraso desproporcionado en una tarea sincronizada. LLR añade, sin embargo, estado de secuencia, búferes de relectura, mensajes de control, ventanas de rechazo y nuevos modos de fallo. También debe coexistir con las actualizaciones de créditos y los reinicios. La versión 1.0.3 corrigió varios casos límite, entre ellos una carrera entre las informaciones CBFC y LLR.

El control de flujo basado en créditos (Credit-Based Flow Control, CBFC) funciona por canal virtual a nivel de enlace. Indica al emisor la capacidad de recepción restante y puede ofrecer un control más granular que la pausa por prioridad. La UEC lo presenta como un medio para crear un comportamiento sin pérdidas controlado sin exigir que todos los despliegues UET sean globalmente lossless. CBFC es opcional, y UET debe funcionar en redes de mejor esfuerzo.

CBFC no es otro nombre para Priority Flow Control. Los mecanismos difieren en su señalización y granularidad, aunque ambos busquen evitar el desbordamiento. CBFC exige, no obstante, una configuración coherente y la entrega correcta de sus propias tramas de control. Los créditos locales pueden interactuar con las ventanas de extremo a extremo y los créditos del receptor, produciendo varios bucles de regulación anidados.

La UEC utiliza una negociación basada en LLDP para descubrir las funciones opcionales e impedir que un lado active una capacidad ausente en su vecino. La negociación debe tener en cuenta los perfiles, los canales virtuales, los mapeos DSCP y de prioridad, los reinicios, las actualizaciones y las combinaciones parciales. La versión 1.0.3 añadió una capacidad de negociación booleana, reforzando la importancia de un acuerdo explícito en cada enlace.

Estas opciones crean una trayectoria desde Ethernet básico hacia una fábrica enriquecida, pero también una matriz que el lenguaje comercial puede disimular. Un conmutador puede transportar UET correctamente sin truncamiento, LLR ni CBFC. Otro puede soportarlos únicamente en ciertas versiones o ciertos modos de puerto. Un expediente de despliegue creíble debe, por tanto, describir el conjunto exacto de funciones, y no solo citar el nombre del consorcio.

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

La capa física ancla la UEC en la hoja de ruta del hardware. El trabajo inicial 1.0 estaba centrado en 100 Gbit/s por carril. La versión 1.0.3 añadió 200 Gbit/s por carril. Esta evolución alinea la especificación con una nueva generación de enlaces de mayor densidad, pero no prueba que todos los productos UEC soporten inmediatamente esta velocidad.

Los trabajos PHY cubren también las estadísticas de corrección de errores, las tasas de palabras de código corregidas y no corregibles, los conjuntos ordenados de control, el reporte de calidad de enlace y la interacción entre errores físicos y LLR. Estos detalles importan porque las decisiones de recuperación dependen de lo que las capas bajas pueden observar y señalizar.

A velocidades superiores, la frontera entre ópticas, SerDes, FEC, recuperación local y retransmisión de transporte se vuelve económicamente importante. Un FEC más fuerte puede reducir los errores residuales al precio de latencia y energía. LLR puede recuperar más rápido una corrupción local, pero exige búferes y estado. La recuperación de extremo a extremo es más simple en la red, pero puede desperdiciar más tiempo. La UEC intenta definir la cooperación entre estas capas en lugar de dejar que cada proveedor optimice por su cuenta.

La adición de los carriles de 200G muestra también que el objetivo se mueve. Los implementadores de la versión 1.0 deben preservar la compatibilidad al tiempo que preparan nuevas capacidades físicas. Los equipos de prueba, firmwares y sistemas de gestión deben distinguir lo que está soportado en cada puerto. Los compradores no deben deducir la velocidad de carril de una afirmación UEC genérica.

Seguridad de transporte de extremo a extremo opcional

La subcapa de seguridad de transporte (Transport Security Sublayer, TSS) proporciona una protección opcional entre extremos. Su modelo de amenaza no supone que los conmutadores sean dignos de confianza. Puede garantizar confidencialidad, integridad, protección contra repetición, aislamiento de tareas, dominios seguros, claves de grupo, rotación de claves e integración con raíces de confianza hardware.

El diseño utiliza dominios seguros cuyos miembros comparten un contexto criptográfico. Identificadores, números de asociación, épocas, identidades de fuente segura y mecanismos de derivación deben permitir una escala superior a la de una sesión independiente para cada par de extremos. Esto es necesario cuando las poblaciones de aceleradores y la pertenencia a trabajos cambian rápidamente.

El protocolo no constituye más que una parte del sistema de seguridad. Un operador debe gestionar las autoridades de claves, los certificados u otras raíces de confianza, la pertenencia a trabajos, la distribución y la revocación, los cambios de época, la recuperación de los extremos, la criptografía hardware y la telemetría. Una red puede ser conforme a un perfil sin activar cada función TSS. «Conforme UEC» no significa, pues, automáticamente cifrada.

El carácter opcional refleja hipótesis de despliegue diferentes. Una fábrica dedicada y físicamente controlada puede privilegiar el rendimiento y apoyarse en controles ambientales. Una nube multi-tenant puede exigir un aislamiento fuerte y una protección criptográfica. Los perfiles y el procedimiento de compra deben hacer visible esta diferencia.

El riesgo más grave no es solo el sobrecoste del cifrado. Está vinculado a los fallos del ciclo de vida a gran escala: pertenencia caducada, revocación tardía, épocas incoherentes, recuperación tras fallo o incapacidad para probar qué trabajo puede acceder a qué memoria. Estos problemas vinculan la seguridad de transporte a los sistemas de orquestación e identidad externos al núcleo de la especificación.

Lo que significa hoy «conforme a la UEC»

La UEC ha comenzado a publicar documentos de conformidad con la versión 1.0, pero el sistema público no constituye aún un régimen maduro de certificación independiente. El paquete disponible está diseñado principalmente para la auto-atestación por parte de los implementadores. Las matrices relacionan los requisitos con los perfiles, y las recomendaciones de banco de pruebas describen configuraciones de extremos y conmutadores. No se ha identificado ningún registro público completo en el que una autoridad independiente consigne los éxitos y fracasos de productos sometidos a un programa UEC exhaustivo.

La distinción es esencial, porque circulan varios tipos de afirmaciones. Un producto puede haber sido diseñado en torno a funciones UEC en desarrollo. Puede implementar ciertos comportamientos en el cable. Puede soportar un perfil, o una parte de un perfil, en una versión de software precisa. Un proveedor puede afirmar una conformidad completa. 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, multi-proveedor y de extremo a extremo.

Las recomendaciones de banco de pruebas son útiles pero voluntariamente limitadas. Proporcionan topologías y controles de buenas prácticas más que una cualificación completa del sistema. Excluyen o no cubren completamente la interoperabilidad general, el rendimiento, el estrés, la escala y el ciclo de vida de las API. No prueban el comportamiento en tráfico mixto UET/RoCE, durante actualizaciones parciales, fallos repetidos, en grandes dominios de claves o con los números de extremos más ambiciosos.

La incoherencia entre AI Full y AI Extended muestra también por qué la conformidad debe estar rigurosamente versionada. Un comprador debe preguntar qué especificación, qué nivel de corrección, qué perfil, qué funciones opcionales, qué modos de enlace y qué funciones de seguridad están cubiertas. Debe saber también si la prueba proviene de un test interno, una demostración bilateral, un evento del consorcio o un laboratorio independiente.

El siguiente paso creíble sería un conjunto de pruebas públicas vinculado a versiones exactas, plugfests multi-proveedor, resultados administrados de forma independiente, incluidos los fallos, y un registro que distinga extremos, conmutadores, software y sistemas completos. Hasta entonces, «conforme a la UEC» debe ser el inicio de la investigación, no su conclusión.

Un documento abierto acompañado de obligaciones de patentes RAND

La especificación 1.0.3 se puede descargar públicamente y se distribuye bajo licencia Creative Commons Attribution-NoDerivatives 4.0. Esta licencia autoriza la redistribución con atribución pero no la difusión de versiones modificadas. Sobre todo, el acceso al derecho de autor y el acceso a las patentes son dos cuestiones separadas.

Los estatutos de los grupos de trabajo utilizan generalmente un modelo tradicional basado en licencias de patentes razonables y no discriminatorias. RAND no significa necesariamente gratuito. El término no garantiza un precio único, no elimina la negociación y no impide los litigios sobre la validez, la esencialidad, la geografía o las condiciones defensivas. La posición comercial depende de cada patente declarada, del compromiso del miembro y de cualquier licencia bilateral.

La UEC mantiene un registro público de declaraciones de Necessary Claims. En la fecha de investigación, eran visibles declaraciones vinculadas en particular a Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google y Marvell, incluidos depósitos asociados a los futuros trabajos 1.1. El registro mejora la transparencia al señalar que los implementadores pueden tener que investigar la propiedad intelectual antes de construir o vender un producto.

El consorcio no determina si una patente declarada es válida, realmente esencial, infringida o disponible a un precio dado. Tampoco publica una licencia común. Los pequeños implementadores pueden, pues, soportar costes jurídicos y transaccionales que los grandes miembros absorben más fácilmente. Una especificación pública puede, aun así, conducir a un mercado concentrado si la clarificación de las patentes, el coste del silicio y las pruebas son elevados.

El marco de propiedad intelectual influye también en los incentivos de gobernanza. Las empresas aportan tecnología para ampliar el mercado de sus productos y para que sus capacidades existentes estén representadas en el diseño común. Las declaraciones de patentes reducen las sorpresas únicamente si son precoces y suficientemente claras. No eliminan el riesgo de que las licencias se conviertan en una barrera después de la adopción de la arquitectura.

La descripción honesta es, por tanto, «especificación publicada abiertamente y multi-proveedor, con compromisos de patentes RAND», y no «universalmente libre de regalías». Los compradores necesitan tanto el perfil técnico como un camino de licencia.

La primera ola de productos y pruebas

Las pruebas de implementación se hicieron visibles en torno a la versión 1.0, pero corresponden a niveles de madurez diferentes.

AMD puso a disposición su tarjeta Pollara 400 AI en abril de 2025 y la describió como diseñada en torno a capacidades UEC en desarrollo. Pollara es una plataforma programable importante, que muestra que el transporte ha llegado al hardware comercial. La formulación sigue siendo esencial: estar diseñado para funciones UEC evolutivas no equivale a una certificación independiente de todos los requisitos finales 1.0.3.

Broadcom anunció Tomahawk 6 en junio de 2025 como un ASIC de conmutación de 102,4 Tbit/s dotado de funciones adaptadas a las fábricas UEC. En octubre, anunció la tarjeta Thor Ultra 800G y afirmó una conformidad completa de las funciones UEC. Es una afirmación significativa del proveedor, pero las pruebas públicas no la convierten en un certificado independiente del consorcio. El muestreo del producto, la madurez del software y el perfil exacto deben distinguirse.

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 Nokia 7220 y 7250 a 800 Gigabit Ethernet. Keysight proporcionó la generación y la validación del tráfico. La prueba muestra que UET puede atravesar sistemas comerciales y que las herramientas de prueba se están desarrollando. No prueba un perfil completo de extremos multi-proveedor, una escala de producción o la certificación independiente de todas las opciones.

Otros miembros han descrito conmutadores, sistemas, software o planes de prueba vinculados a la UEC, y la cumbre de 2026 dio un lugar importante a la puesta en producción. Los elementos disponibles apoyan la idea de una transición hacia la implementación. No permiten establecer el número exacto de tarjetas UET enviadas, de conmutadores certificados, de regiones cloud desplegadas o de fábricas completas.

La mejor lectura de esta ola es la de una cadena de pruebas. Una especificación permite el diseño. Los anuncios de silicio y tarjetas muestran la inversión. Las demostraciones de tráfico muestran una parte de la interoperabilidad. Las matrices organizan los requisitos. Los informes de despliegue de operadores mostrarían el valor en explotación. Plugfests independientes y resultados de producción aportarían la credibilidad más amplia que aún falta.

RoCE, InfiniBand, Slingshot y UALink

La UEC llega a un mercado donde existen tecnologías maduras y sistemas adyacentes. Su argumento estratégico no es que Ethernet nunca haya transportado RDMA ni que las fábricas especializadas no funcionen. Afirma que la escala y la sincronización de las cargas de IA actuales justifican una nueva arquitectura Ethernet de extremo a extremo, con más flexibilidad en la entrega, la utilización de las rutas y la congestión.

RoCEv2 es el predecesor directo y una tecnología ampliamente instalada. Transporta el RDMA sobre Ethernet enrutable y cuenta con un vasto soporte aplicativo y de producto. La UEC critica los despliegues comunes por la fijación de un flujo entero en una ruta, la recuperación Go-Back-N, la reordenación en el receptor, la difícil puesta a punto de DCQCN, la dependencia de Priority Flow Control en numerosas arquitecturas y el comportamiento bajo incast o ráfagas colectivas. Estas son las posiciones técnicas de la UEC, no una prueba de que todas las redes RoCE sean mediocres.

La comparación evoluciona. Los proveedores pueden añadir enrutamiento adaptativo, distribución de paquetes, mejores controles de congestión u otras ideas de la UEC a tarjetas programables conservando al mismo tiempo la compatibilidad RoCE. La comunicación de AMD en torno a Pollara presenta ya RoCEv2 y UEC RDMA como dos opciones sobre un hardware programable. La UEC puede, por tanto, competir con RoCE como transporte completo al mismo tiempo que influye en su evolución.

InfiniBand es la principal alternativa especializada. Proporciona un ecosistema integrado de RDMA, congestión, fiabilidad de enlace y gestión, con una larga experiencia en HPC. Los trabajos 2.0 de la InfiniBand Trade Association incluyen carriles XDR a 200 Gbit/s y telemetría actualizada. La diferenciación más sólida de la UEC no es pretender que InfiniBand carezca de rendimiento, sino intentar obtener un comportamiento IA/HPC a través de la cadena Ethernet, el enrutamiento IP estándar y una elección más amplia de proveedores.

HPE Slingshot ocupa una posición intermedia. Esta fábrica HPC compatible con Ethernet, con enrutamiento adaptativo y gestión de congestión, proporcionó antecedentes importantes a UET. Demuestra que se puede construir un comportamiento especializado sobre Ethernet, al tiempo que ilustra la diferencia entre una plataforma comercial controlada y una especificación industrial.

UALink es generalmente complementario. Su especificación pública de 200G apunta a la conectividad scale-up de baja latencia entre aceleradores dentro de un pod y describe hasta 1 024 aceleradores. UEC 1.0 es principalmente una fábrica scale-out entre nodos a través de conmutadores. Un centro de datos puede utilizar un enlace scale-up dentro de un pod y UEC entre pods o nodos. Los futuros trabajos de la UEC sobre el scale-up optimizado y las operaciones colectivas en la red pueden acercar las fronteras y producir ya sea una convergencia, ya sea una competencia.

NVIDIA Spectrum-X y las fábricas propietarias ilustran otro compromiso: una pila integrada puede optimizar hardware, software y soporte rápidamente, pero aumenta la dependencia de un ecosistema. La UEC intercambia una parte de esta integración por la promesa de interfaces comunes y elección. El valor del compromiso dependerá del rendimiento, el soporte, las patentes, la interoperabilidad y el coste total, y no de la apertura como simple eslogan.

El problema operativo va más allá del protocolo

Una especificación de 573 páginas puede definir numerosos requisitos, pero una fábrica de producción necesita todavía un modelo de explotación. La versión 1.0 deja importantes trabajos de gestión en torno al documento normativo. Los operadores deben configurar de forma coherente los perfiles, las clases de tráfico, los umbrales ECN, los conjuntos de entropía, las opciones de enlace, las claves, los firmwares, la telemetría y las políticas de fallo.

El tráfico mixto complica aún más la tarea. Una fábrica puede transportar UET, RoCE, TCP, almacenamiento, gestión y servicios UET ordenados o no. La distribución de las colas y la equidad no se resuelven solo con la corrección de cada protocolo. Un control de congestión puede funcionar bien de forma aislada y comportarse mal frente a otro controlador que utilice señales diferentes.

La complejidad de los extremos es otro riesgo estructural. UET coloca en ellos el uso de múltiples rutas, la colocación directa, la retransmisión selectiva, varios modos, el control por ventana y créditos, la recepción de paquetes truncados, la seguridad y mucho estado. Esto puede aumentar la superficie del silicio, el tamaño del firmware, el esfuerzo de verificación, la energía y el número de fallos a diagnosticar. La inteligencia de terminación permite una cadena de proveedores amplia, pero también vuelve complejo el componente presente en cada servidor.

Las funciones opcionales crean a la vez diferenciación y fragmentación. Un proveedor puede optimizar AI Base para ECMP y ECN convencionales. Otro puede soportar AI Full, TSS, truncamiento, LLR y CBFC. Ambos participan en el mismo ecosistema, sin garantizar el mismo rendimiento o la misma seguridad. Las matrices de conformidad deben convertirse en matrices de capacidades operativas.

El mantenimiento de versiones será continuo. Las correcciones 1.0.1 a 1.0.3 afectaron a la congestión, los créditos, la recuperación y los paquetes. Un gran clúster puede contener varias versiones de firmware de tarjetas, de software de conmutadores y de herramientas de prueba. Actualizar una capa sin coordinar las otras puede exponer las carreras transversales que el consorcio busca precisamente evitar.

Las alianzas externas son, por tanto, centrales. OCP vincula el transporte al hardware y los sistemas abiertos. OFA y libfabric vinculan las aplicaciones. IEEE 802.3 aporta el proceso Ethernet formal. SNIA y NVM Express aportan el almacenamiento y la gestión. Los mecanismos IETF proporcionan IP, ECN y otras bases. Estas organizaciones tienen procesos y calendarios diferentes; la vinculación reduce las duplicaciones sin garantizar una adopción simultánea.

La prueba final es la infraestructura en funcionamiento. Un documento puede definir el comportamiento, un proveedor anunciar un producto y un consorcio organizar una cumbre. Nada de esto sustituye a un clúster donde los extremos y conmutadores independientes terminan trabajos reales bajo congestión, fallo y actualización, con operadores capaces de explicar el resultado.

Relevancia actual: de la victoria documental a la credibilidad de implementación

En julio de 2026, la UEC había alcanzado varios objetivos que eran inciertos en el momento de su lanzamiento. Había formado una amplia coalición, producido una arquitectura integrada en cinco capas, publicado una especificación 1.0 completa, asegurado su mantenimiento, añadido los carriles de 200G, divulgado declaraciones de patentes y suscitado anuncios de productos y pruebas. El proyecto está activo y su agenda se ha orientado claramente hacia la implementación.

Este progreso hace que las incertidumbres sean más importantes. Ningún registro único publica el total actual de miembros y la composición del Comité de Dirección. Las páginas de adhesión y los estatutos describen de forma diferente el acceso. La dirección formal del TAC no está completamente conciliada con los roles de la cumbre. La fecha de la versión 1.0.2 diverge entre documentos oficiales. El paquete de conformidad emplea una terminología de perfil obsoleta. Ninguno de estos problemas destruye la arquitectura, pero cada uno de ellos señala la calidad del control documental en un proyecto en el que las versiones exactas importan.

Las lagunas más importantes se refieren a la adopción. La UEC no publica ni censo de despliegue, ni registro independiente de productos, ni presupuesto autónomo, ni cuentas auditadas. Ninguna prueba pública establece una red 1.0 plenamente interoperable a la escala máxima deseada. Las demostraciones y afirmaciones de los proveedores son útiles pero interesadas. Las comparaciones neutrales con RoCE, InfiniBand y las plataformas Ethernet integradas siguen siendo limitadas.

La oportunidad sigue siendo considerable. Ethernet es el denominador común de los centros de datos, y el mercado de la IA puede soportar nuevas generaciones de tarjetas, conmutadores, ópticas y software. Los operadores tienen fuertes incentivos para evitar la dependencia única y mejorar la utilización de los aceleradores. Una pila común podría transformar estos incentivos en poder de compra.

El riesgo es que «Ultra Ethernet» se convierta en un paraguas para subconjuntos incompatibles. Si la transferencia básica funciona pero los perfiles, la congestión, la seguridad y la gestión divergen, la marca puede difundirse más rápido que la interoperabilidad. Si las licencias RAND son costosas o inciertas, el número de proveedores puede reducirse. Si RoCE absorbe las ideas más atractivas sin cambiar de transporte, la 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 sofisticada. Lo ha hecho. Es si organizaciones independientes pueden implementar los mismos contratos, obtener las licencias necesarias, explotar la fábrica a gran escala y preservar la compatibilidad durante la evolución. La UEC no se convertirá en infraestructura sino en la medida en que sus afirmaciones resistan el código en producción.