Ultra Ethernet Consortium: Reconstruindo Ethernet para IA em escala

Sumário Executivo

• O Ultra Ethernet Consortium é um projeto da Joint Development Foundation lançado em 19 de julho de 2023 por AMD, Arista Networks, Broadcom, Cisco, Eviden/Atos, Hewlett Packard Enterprise, Intel, Meta e Microsoft. É um consórcio de especificação industrial, não uma empresa convencional ou operadora de rede.
• O escopo da UEC é mais amplo do que um link Ethernet mais rápido ou um substituto para RoCE. Sua especificação versão 1.0.3, de 573 páginas, abrange as camadas de software, transporte, rede, enlace e física, com trabalho de gerenciamento, armazenamento, testes e conformidade em torno da pilha central.
• O Ultra Ethernet Transport combina vários modos de entrega, multipercurso em nível de pacote, retransmissão seletiva, controle de congestionamento orientado ao remetente e ao receptor, ECN, corte opcional de pacotes, retentativa de enlace opcional, controle de fluxo baseado em crédito opcional e segurança de transporte ponta a ponta opcional.
• Produtos e demonstrações da AMD, Broadcom, Nokia e Keysight mostram que a implementação começou, mas a conformidade pública ainda se baseia principalmente em autodeclaração do implementador e nenhum registro abrangente de certificação independente ou censo de implantação em larga escala foi publicado.
• A oportunidade estratégica da UEC vem da base instalada de Ethernet e da cadeia de suprimentos de múltiplos fornecedores. Seus principais riscos são a complexidade do endpoint, fragmentação de recursos opcionais, obrigações de patentes RAND, gerenciamento e testes imaturos e a lacuna entre a publicação de uma especificação e a interoperabilidade verificada em produção.

Por que a IA transformou a rede em parte do computador

O Ultra Ethernet Consortium foi criado em torno de uma mudança na economia da computação. Em uma rede empresarial comum, espera-se que a malha movimente muitos fluxos independentes com vazão e disponibilidade aceitáveis. Em um grande sistema de treinamento de inteligência artificial ou máquina de computação de alto desempenho, a rede se torna parte de uma computação sincronizada. Milhares de aceleradores podem trocar parâmetros de modelo, gradientes ou dados científicos em operações coletivas. Uma fase pode não avançar até que o participante mais lento receba as informações necessárias.

Uma pequena quantidade de desequilíbrio de caminho, congestionamento ou perda de pacotes pode, portanto, manter processadores caros em espera, mesmo quando a utilização média da malha parece saudável.

Isso muda o que os operadores otimizam. A largura de banda agregada ainda importa, mas não é suficiente. Eles também se preocupam com o tempo de conclusão do trabalho, latência de cauda, incast, recuperação de perdas, distribuição do tráfego entre caminhos paralelos e a quantidade de estado que os terminais precisam manter. Uma rede que entrega a maioria dos pacotes rapidamente, mas atrasa uma pequena fração, pode travar toda uma operação coletiva. Um método de retransmissão aceitável para tráfego convencional pode desperdiçar tempo demais quando uma mensagem longa perde um único pacote.

Um fluxo fixado em um caminho de igual custo pode ter desempenho inferior enquanto há capacidade disponível em outro lugar da topologia.

A proposição fundadora da UEC era que esses problemas não poderiam ser resolvidos com um único novo recurso de switch ou um algoritmo de congestionamento revisado. O caminho de comunicação começa acima da rede, nas bibliotecas de software e na semântica da aplicação. Ele passa pelo registro de memória, operações remotas, estado de transporte, entrega de pacotes, controle de congestionamento, encaminhamento IP, enlaces Ethernet, óptica e sinalização física. Se essas camadas forem projetadas independentemente, uma otimização em um ponto pode simplesmente mover o gargalo ou criar premissas incompatíveis em outro.

A resposta da UEC é uma arquitetura coordenada. Ela mantém Ethernet e IP porque os operadores já os compreendem e porque existe uma enorme cadeia de suprimentos em torno de switches, óptica, cabos, sistemas operacionais de rede, telemetria e gerenciamento. Ela altera ou estende as partes que o consórcio considera mal adaptadas a grandes cargas de trabalho de IA e HPC. O resultado não é “Ethernet comum com um logotipo novo”. É uma tentativa de fazer uma rede familiar transportar um transporte especializado cujo comportamento é definido desde a API de software até a taxa da pista.

Essa distinção explica por que a UEC importa para a infraestrutura digital. O projeto não possui aceleradores, fábricas, data centers ou regiões de nuvem. Ele define os contratos que as empresas membros e outros implementadores podem colocar dentro de NICs, ASICs de switch, sistemas, drivers, bibliotecas e equipamentos de teste. Sua influência só será concretizada quando esses produtos independentes trocarem tráfego corretamente sob condições de falha, congestionamento, atualização e ambientes com múltiplos fornecedores.

O que é a UEC — e o que não é

Ultra Ethernet Consortium é o nome público de um projeto formal cuja série legal se chama Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. A estrutura de série insere o projeto na Joint Development Foundation e na família mais ampla da Linux Foundation. Ela oferece aos participantes uma estrutura legal pré-existente para associação, governança, propriedade intelectual, financiamento e relacionamentos externos, sem exigir a criação de uma nova corporação independente.

Essa estrutura é importante porque a UEC é frequentemente descrita de forma imprecisa como empresa, aliança ou órgão de padronização. Não é uma empresa comercial com acionistas, capital social, avaliação ou demonstrações financeiras independentes. Ela não vende produtos Ethernet, opera uma rede pública ou é proprietária do hardware promovido por seus membros. É um consórcio de desenvolvimento de especificações com um arcabouço jurídico e de propriedade intelectual. Seus documentos públicos têm a intenção de se tornar contratos de implementação entre várias empresas.

A UEC também não é idêntica ao Ultra Ethernet Transport. O UET é a arquitetura de transporte no centro da especificação. O trabalho do consórcio é mais amplo. Inclui o mapeamento de software para libfabric, semântica de pacotes e mensagens, premissas de rede, opções da camada de enlace, requisitos da camada física, gerenciamento, alinhamento com armazenamento, desempenho e depuração, conformidade e testes. Reduzir o projeto a “um novo protocolo RDMA” oculta o design entre camadas que o torna ambicioso e difícil.

A UEC também não é o Grupo de Trabalho IEEE 802.3. O IEEE 802.3 desenvolve os padrões centrais de MAC e camada física Ethernet por meio de seu processo formal próprio. A UEC depende desse ecossistema e mantém um contato, mas não o substitui. O mesmo limite se aplica aos mecanismos do IETF abaixo do UET, incluindo IPv4, IPv6 e Explicit Congestion Notification; ao ecossistema OpenFabrics que mantém o libfabric; e a organizações que trabalham com armazenamento, hardware aberto e interconexões de aceleradores.

O site do projeto usou linguagem que sugere o status de organização internacional de normas. A descrição mais segura e melhor fundamentada é que a UEC é uma organização internacional de desenvolvimento de especificações sob a estrutura da JDF. Não há evidências de que faça parte da International Organization for Standardization, que seus documentos sejam normas ISO ou que tenha um número de norma ISO. A distinção é mais do que terminológica. Ela identifica de onde vem a autoridade, como funciona a participação e quais compromissos legais os implementadores podem enfrentar.

Portanto, a UEC deve ser julgada pelo papel que realmente desempenha. Ela coordena concorrentes e operadores em torno de um design técnico comum. Publica especificações. Administra grupos de trabalho e declarações de patentes. Desenvolve materiais de conformidade e relacionamentos com organizações adjacentes. Sozinha, não pode, por decreto, tornar um produto interoperável ou fazer o mercado adotar sua arquitetura.

A coalizão fundadora de nove empresas

O consórcio foi anunciado em 19 de julho de 2023 por nove organizações posicionadas em diferentes camadas da cadeia de suprimentos de IA e HPC: AMD, Arista Networks, Broadcom, Cisco, Eviden (então associada à Atos), Hewlett Packard Enterprise, Intel, Meta e Microsoft. Essa amplitude foi um ativo estratégico desde o início. Um transporte desenvolvido apenas por fabricantes de switches poderia negligenciar as restrições das aplicações e dos terminais. Um design liderado apenas por fornecedores de aceleradores poderia otimizar de forma muito restrita em torno de um único ecossistema de hardware.

Um projeto apenas de nuvem poderia carecer da experiência em silício, óptica e sistemas necessária para transformar uma arquitetura em produtos.

A AMD trouxe processadores, aceleradores e rede de terminais. Arista e Cisco trouxeram comutação Ethernet em larga escala e experiência operacional. A Broadcom contribuiu com silício de comutação, NICs e SerDes de alta velocidade. HPE e Eviden trouxeram sistemas HPC e histórico de interconexões especializadas. A Intel contribuiu com processadores, Ethernet e experiência em software. Meta e Microsoft representaram operadores de hiperescala com incentivos diretos para aumentar a utilização de grandes clusters de IA e reduzir a dependência de um único fornecedor integrado.

A coalizão também continha interesses comerciais concorrentes. Os membros vendem NICs, ASICs de switch, sistemas, capacidade de nuvem, óptica, software e suporte. Alguns possuem portfólios de patentes que podem ser necessários para implementação. Alguns se beneficiam de um padrão amplo de múltiplos fornecedores, enquanto outros também podem lucrar com recursos proprietários diferenciados. O consórcio, portanto, não elimina a concorrência. Cria um fórum no qual concorrentes concordam em interfaces mínimas enquanto continuam a competir em qualidade de implementação, desempenho, integração e termos comerciais.

O interconector Slingshot da HPE oferece um exemplo útil de linhagem técnica. Slingshot é uma malha HPC compatível com Ethernet, com roteamento adaptativo e recursos de gerenciamento de congestionamento. Comentários associados à HPE disseram que uma especificação de Ethernet para HPC foi contribuída para a UEC e estimaram que uma grande parcela do UET deriva das ideias de transporte do Slingshot. A porcentagem exata não é verificada independentemente e não deve ser tratada como contabilidade do consórcio. O ponto mais amplo é bem sustentado: a UEC não começou de uma folha em branco.

Baseou-se na experiência de produção em HPC, redes de nuvem, RDMA e Ethernet.

Essa mistura de sistemas anteriores é uma razão pela qual a palavra “aberto” precisa de precisão. A especificação ratificada da UEC é publicamente baixável. A arquitetura é destinada à implementação por vários fornecedores. Mas o projeto também é um local onde os membros contribuem com conhecimento existente, patentes e roteiros de produtos. A abertura do documento não elimina as condições econômicas ou legais em torno da tecnologia.

Uma série legal construída para concorrentes colaborarem

O modelo da Joint Development Foundation dá à UEC uma casca formal sem transformá-la em uma empresa operacional convencional. O projeto tem nome, escopo, classes de associação, Comitê Diretivo, grupos de trabalho e obrigações de propriedade intelectual próprios. O guarda-chuva JDF fornece infraestrutura corporativa e sem fins lucrativos e pode manter ativos e acordos do projeto. Isso reduz o custo de formar um consórcio e oferece aos concorrentes um processo reconhecido para colaborar.

O Comitê Diretivo governa o projeto. Suas responsabilidades documentadas incluem coordenar grupos de trabalho, aprovar membros, gerenciar ativos e finanças, selecionar ou substituir o presidente, supervisionar o progresso e controlar a divulgação pública e as marcas do projeto. O consenso é preferido. Se o consenso falhar, o estatuto prevê um mecanismo de supermaioria de três quartos entre os participantes elegíveis que atendem aos requisitos de presença. Recursos por escrito podem ser encaminhados ao presidente.

O presidente original era Brad Booth, da Meta. A especificação 1.0.3 atual lista J Metz (AMD) como presidente, Barry Davis (HPE) como vice-presidente, Hugh Holbrook (Arista) como presidente do Comitê Consultivo Técnico (TAC) e Puneet Agarwal (Marvell) como vice-presidente do TAC. Paul Congdon é listado como editor da especificação. O documento também identifica líderes e autores nos trabalhos de camada física, enlace, transporte e software. A agenda da cúpula de 2026 nomeia líderes operacionais adicionais.

Esses papéis de cúpula não substituem necessariamente os títulos formais da especificação; o material público não fornece um organograma completo e atualizado.

Três classes de associação aparecem no estatuto: Direção (Steering), Geral (General) e Contribuidor (Contributor). Membros Diretores participam da governança e normalmente designam representantes para o Comitê Diretivo. Membros Gerais podem trabalhar em todos os grupos técnicos, mas não têm assento no Comitê Diretivo. Membros Contribuidores participam de grupos selecionados e não possuem direito de voto de supermaioria. A página pública atual de associação comercializa os níveis Geral e Contribuidor, com preços anuais de projeto de US$ 20.000 e US$ 5.000, respectivamente, mais a associação à Linux Foundation.

Não explica claramente o caminho de admissão ou o preço atual para o status de Direção.

A diferença de poder formal importa. Uma associação ampla pode fornecer especialização e alcance de implementação, mas a governança não é distribuída uniformemente. Grandes empresas capazes de manter posições de Direção, contribuir com engenheiros para muitos grupos e manter programas de patentes e produtos têm mais influência prática do que membros Contribuidores menores. Não membros podem baixar a especificação final, mas não podem observar o processo completo de elaboração ou participar em igualdade de condições.

As informações internas do projeto não são tratadas como dados corporativos confidenciais comuns, mas os membros são impedidos de divulgar material de rascunho até que o comitê relevante aprove a publicação. Esse arranjo pode ajudar os concorrentes a discutir ideias não finalizadas sem sinalização prematura ao mercado. Também significa que pessoas de fora não podem ver propostas rejeitadas, registros de votação, preocupações de implementação intermediárias ou as negociações que produziram recursos opcionais. A especificação final é aberta; o caminho até ela é apenas parcialmente visível.

Do lançamento com quatro grupos a uma especificação de 573 páginas

A primeira estrutura pública da UEC em 2023 concentrou-se em quatro grupos de trabalho: software, transporte, enlace e física. A sequência refletia a ambição ponta a ponta do projeto. A associação não foi aberta como uma lista de discussão pública irrestrita. Mais de 200 organizações manifestaram interesse, e o consórcio realizou a integração em fases, exigindo orientação sobre processos e antitruste. Essa cautela era compreensível porque os participantes competem diretamente em vários mercados e estariam discutindo requisitos compartilhados de produtos e protocolos.

Em dezembro de 2023, a UEC relatou aproximadamente 40 empresas e mais de 300 indivíduos. Havia estabelecido um Comitê Consultivo Técnico e expandido para oito grupos de trabalho. O propósito do TAC era a coerência arquitetural: um design de transporte não poderia pressupor um comportamento de switch, método de sinalização ou API que outro grupo não tivesse concordado em suportar. Em março de 2024, o consórcio relatou 55 empresas e mais de 750 participantes ativos e publicou uma descrição muito mais clara da arquitetura pretendida.

A atualização de março introduziu as principais ideias que mais tarde apareceriam na especificação normativa: libfabric como a API voltada para software, pulverização de pacotes, ordenação flexível, vários modos de entrega, controle de congestionamento orientado ao remetente e ao receptor, ECN, corte de pacotes, Retentativa de Camada de Enlace (LLR), controle de fluxo baseado em crédito opcional, segurança de transporte e futuras operações coletivas na rede. Também enfatizou que o UET poderia operar através de switches Ethernet existentes, enquanto switches aprimorados poderiam oferecer desempenho adicional.

O alcance institucional cresceu junto com o trabalho técnico. A UEC relatou 1.193 participantes ativos em julho de 2024 e 97 organizações membros em agosto. Esses são números do consórcio com base em definições que não são totalmente públicas. Não devem ser somados mecanicamente a anúncios posteriores. Em 2025, a UEC disse que 27 novas empresas haviam ingressado, mas saídas, fusões e períodos de relatório sobrepostos impedem que essa declaração estabeleça um total atual exato. O próprio site afirma que nem todos os membros são exibidos.

O consórcio lançou a Ultra Ethernet Specification 1.0 em 11 de junho de 2025. Esse foi o momento em que a UEC passou de um roteiro para uma linha de base de implementação pública. A versão 1.0.1 veio em setembro e corrigiu o algoritmo de origem do controle de congestionamento por crédito do receptor e questões editoriais. A versão 1.0.2 chegou em janeiro de 2026 e corrigiu algoritmos de gerenciamento de congestionamento, embora documentos oficiais discordem se a data de lançamento foi 21 ou 28 de janeiro. A inconsistência deve permanecer visível em vez de ser resolvida silenciosamente.

A versão 1.0.3, publicada em 16 de julho de 2026, é a referência atual no fechamento da pesquisa. Ela tem 573 páginas e adiciona suporte para sinalização de 200 Gb/s por pista e uma capacidade de negociação booleana. Suas notas de lançamento também identificam correções obrigatórias envolvendo entrega de pacotes, créditos de congestionamento, Retentativa de Enlace e conjuntos ordenados de controle da camada física, além de esclarecimentos para segurança de transporte, operações atômicas e pacotes cortados.

A distinção entre correções obrigatórias e esclarecimentos editoriais importa: algumas mudanças afetam o comportamento conforme e, portanto, a manutenção da implementação.

A Cúpula de Membros de 2026 em Denver mostrou uma segunda transição. A agenda concentrou-se em implantação, industrialização, conformidade, gerenciamento, desempenho, depuração, integração de armazenamento e testes de switches e endpoints. O documento arquitetural central existe; a credibilidade do projeto agora depende cada vez mais de se os implementadores podem construir, qualificar, operar e atualizar a pilha através das fronteiras organizacionais.

Uma arquitetura em cinco camadas funcionais

A especificação atual divide o Ultra Ethernet em camadas de software, transporte, rede, enlace e física. Essa divisão é útil, mas o valor do projeto reside nas premissas que conectam as camadas.

No topo, frameworks de IA, MPI, SHMEM e bibliotecas coletivas interagem através das OpenFabrics Interfaces, especialmente libfabric. A Subcamada de Serviços Semânticos UET traduz operações da aplicação em transações de transporte. A Subcamada de Entrega de Pacotes decide como as mensagens são empacotadas, ordenadas, reconhecidas e recuperadas. O gerenciamento de congestionamento controla quantos dados entram na malha e como o tráfego é distribuído entre os caminhos. A segurança de transporte opcional protege o tráfego ponto a ponto. IPv4 ou IPv6 padrão fornecem encaminhamento na camada de rede.

A Ethernet fornece o enlace, com corte opcional de pacotes, Retentativa de Enlace, Controle de Fluxo Baseado em Crédito e negociação de recursos. A camada física define estatísticas e requisitos de sinalização a 100 ou 200 Gb/s por pista.

Essa estrutura preserva partes importantes da rede existente. A UEC não define um substituto para o roteamento IP. Ela espera encaminhamento por múltiplos caminhos de igual custo (ECMP) e switches capazes de ECN. Grande parte da inteligência permanece nos Fabric Endpoints (FEPs), que manipulam a entropia, monitoram o estado do transporte, posicionam dados e respondem a sinais de congestionamento. Switches aprimorados podem adicionar funções, mas o design não exige que cada implantação substitua toda a sua malha para que o tráfego UET possa passar.

Isso cria uma vantagem de migração e um problema de classificação. Uma implantação pode usar endpoints UET sobre Ethernet convencional com ECMP e ECN. Outra pode adicionar corte de pacotes, retentativa de enlace, créditos por canal virtual, telemetria mais rica e, posteriormente, operações na rede. Ambas podem ser chamadas de Ultra Ethernet, embora seu desempenho, características de recuperação e complexidade operacional difiram materialmente.

A abordagem de cinco camadas também torna as falhas de implementação mais difíceis de isolar. Um resultado ruim pode vir do mapeamento da aplicação, da máquina de estado do endpoint, dos parâmetros de congestionamento, da configuração da fila do switch, do mapeamento DSCP, da óptica, do firmware ou do sistema de segurança. Transportar pacotes não é suficiente. O sistema deve preservar a semântica e o desempenho pretendidos sob escala, tráfego misto, falhas e mudanças de versão.

O contrato de software: libfabric em vez de uma API de aplicação proprietária

A UEC seleciona libfabric 2.0 como a API norte de referência para endpoints compatíveis. Essa escolha conecta o projeto a um ecossistema existente de software de HPC e redes avançadas, em vez de pedir que cada framework adote uma nova interface proprietária. O libfabric já representa fabrics, domínios, endpoints, filas de conclusão, filas de eventos, vetores de endereços, regiões de memória, mensagens, operações de memória remota e atômicas. A UEC mapeia e restringe esses conceitos para que os provedores possam traduzir chamadas em comportamento UET.

O valor estratégico é a continuidade acima do transporte. MPI, SHMEM e bibliotecas de comunicação de aceleradores podem usar abstrações familiares enquanto o provedor abaixo delas muda. Em princípio, uma aplicação pode solicitar uma operação sem saber de qual fornecedor é a NIC que implementa a entrega de pacotes ou qual silício de switch encaminha os pacotes. Esse é um dos principais mecanismos pelos quais um transporte comum poderia criar escolha de fornecedor.

A abstração não garante implementações equivalentes. Os provedores podem suportar diferentes tamanhos de injeção, limites de dispersão e coleta, contagens de endpoints, operações atômicas, técnicas de registro de memória, comportamento de conclusão, descarregamento de hardware e funções de segurança. Uma biblioteca que compila contra a mesma API pode ainda encontrar limites diferentes de desempenho ou capacidade. Compras e qualificação de software, portanto, precisam de mais do que uma caixa dizendo “libfabric suportado”.

A camada de software da UEC também carrega semântica de tarefas e autorização. Sistemas de IA e HPC frequentemente executam muitos trabalhos em infraestrutura compartilhada, cada um com seus próprios processos, regiões de memória e limites de segurança. A especificação deve identificar qual endpoint pertence a qual job, quais buffers podem ser acessados, como uma operação remota é casada e como as informações de conclusão ou erro retornam ao software. Essas decisões determinam se uma rede rápida é utilizável pelo escalonador, pelo runtime e pela aplicação, em vez de apenas impressionante em um benchmark de pacotes.

O projeto depende do ecossistema OpenFabrics porque não é proprietário do libfabric. Essa relação ilustra uma característica mais ampla da UEC: a arquitetura é montada a partir de componentes governados em lugares diferentes. A UEC pode definir como seu transporte mapeia para o libfabric, mas precisa se coordenar com os mantenedores e usuários da API. Dependências semelhantes existem com o IEEE Ethernet, a rede IETF, as organizações de armazenamento e os sistemas operacionais dos fornecedores.

Fabric Endpoints e perfis de carga de trabalho

Um Fabric Endpoint (FEP) é o local lógico onde o UET termina. Ele conecta uma instância de sistema operacional a um ou mais planos de malha isolados e pode incluir um provedor de espaço de usuário, driver de kernel, transporte no lado da NIC ou acelerador, sistema de registro de memória, contexto de segurança, filas de conclusão, vetores de endereços e o estado usado para entrega de pacotes e controle de congestionamento.

Este design centrado no endpoint permite que a maioria dos switches permaneça como dispositivos reconhecidamente Ethernet e IP. O FEP escolhe valores de entropia, mantém o estado dos pacotes e do congestionamento, coloca dados na memória autorizada e interpreta confirmações, cortes e outros feedbacks. Isso pode reduzir a dependência de inteligência de roteamento proprietária dentro do switch. Também concentra a complexidade no silício da NIC, firmware, drivers e software.

A UEC define três perfis de implementação: AI Base, AI Full e HPC. Eles não são tipos de rede separados. São conjuntos que especificam quais funções uma implementação deve suportar. O AI Base é destinado a cobrir a comunicação de IA comum com menor custo de implementação e estado. O AI Full adiciona funções como envios adiáveis (deferrable sends), correspondência exata e operações atômicas do tipo buscar-ou-comparar. O perfil HPC inclui a maioria das capacidades AI Full, exclui o envio adiável e coloca maior ênfase em ordenação, mensagens curtas e semântica de HPC.

O sistema de perfis é uma tentativa de evitar que cada produto tenha que implementar o conjunto máximo de recursos. Ele reconhece que uma NIC de IA de alto volume pode priorizar o movimento de dados coletivos, enquanto um endpoint HPC pode precisar de ordenação e atômicas mais fortes. No entanto, os perfis não eliminam a opcionalidade. Um produto pode implementar recursos opcionais dentro de um perfil, e dois produtos com o mesmo rótulo de perfil ainda podem diferir em segurança, aprimoramentos de enlace, capacidade e desempenho.

A terminologia já é um sinal de alerta. A especificação autoritativa 1.0.3 usa AI Base, AI Full e HPC. Um arquivo de conformidade separado de 2025 usa AI Base, AI Extended e HPC. A interpretação mais bem suportada é que “AI Full” é o atual e o material de conformidade está desatualizado ou inconsistente. Até que o pacote de teste público seja corrigido, fornecedores e compradores devem identificar tanto a versão da especificação quanto a linguagem exata do perfil por trás de uma alegação.

Da intenção da aplicação à entrega de pacotes

Dentro do UET, a Subcamada de Serviços Semânticos carrega a intenção da aplicação. Ela define a identidade da mensagem, endereçamento de buffers, operações rotuladas e não rotuladas, acesso à memória remota, atômicas, comportamento de conclusão, identificadores de trabalho, autorização de buffer, respostas e erros. A Subcamada de Entrega de Pacotes então determina como essa intenção se torna pacotes e como esses pacotes chegam a outro endpoint.

Para modos confiáveis, os endpoints estabelecem Contextos de Entrega de Pacotes (PDC). Um PDC contém estado como números de sequência de pacotes, confirmações, detecção de duplicatas, modo de ordenação, informações de congestionamento, estado da direção de retorno e classe de tráfego. Um PDC está associado a um modo de entrega e classe de tráfego, e múltiplos PDCs podem existir entre o mesmo par de FEPs.

Esse estado não é um detalhe de implementação menor. Grandes clusters podem criar um número enorme de relações de comunicação. Se cada relação exigir um extenso estado no destino, a memória do endpoint e o custo de busca podem se tornar limitantes. Portanto, a UEC não força cada operação a um modelo de conexão. Ela define quatro serviços de entrega com diferentes contratos de confiabilidade e ordenação.

Reliable Unordered Delivery (RUD) fornece entrega de pacotes exatamente uma vez para a camada semântica, permitindo que os pacotes cheguem fora de ordem. Ele suporta pulverização de pacotes por vários caminhos, retransmissão seletiva, supressão de duplicatas e colocação direta de dados. Como o destino pode colocar dados de acordo com deslocamentos, em vez de esperar por um buffer de reordenação no nível de transporte, uma operação coletiva longa pode explorar múltiplos caminhos sem serializar todos os pacotes atrás de uma unidade perdida.

Reliable Ordered Delivery (ROD) fornece entrega exatamente uma vez e em ordem. Ele usa um caminho e um valor de entropia, descarta pacotes fora de ordem e depende de recuperação Go-Back-N a partir do primeiro pacote perdido. Isso parece menos sofisticado que o RUD, mas preserva a semântica exigida por operações para as quais a ordenação estrita importa. A UEC trata a ordenação como um requisito da aplicação, em vez de presumir que toda transferência deva pagar por ela.

Reliable Unordered Delivery for Idempotent Operations (RUDI) faz uma troca diferente. Ele fornece entrega pelo menos uma vez e permite duplicatas, reduzindo o estado comum de sequência e confirmação no destino. Pode ser útil quando repetir uma operação não altera o resultado final, como certos movimentos de memória remota seguidos por uma barreira separada. É perigoso quando aplicado incorretamente. A camada de pacotes não infere se uma operação é idempotente; o software deve tomar essa decisão. Usar RUDI para uma operação não idempotente pode produzir um estado de aplicação inválido.

Unreliable Unordered Delivery (UUD) fornece datagramas de melhor esforço sem garantias normais de confiabilidade ou ordenação. Pertence ao mesmo arcabouço semântico, mas não carrega os mesmos requisitos de controle de congestionamento do RUD e ROD. As aplicações devem evitar prejudicar o tráfego controlado por congestionamento quando o UUD compartilha filas ou classes de tráfego.

Os quatro modos revelam uma filosofia central da UEC: a rede deve expor vários mecanismos para que o software possa igualar o custo do transporte à semântica da operação. O benefício é a eficiência. O custo é uma superfície maior de implementação e teste, com mais oportunidades para um provedor, aplicação ou operador escolher uma combinação incompatível.

Pulverização de pacotes: utilizando a malha em vez de um único caminho afortunado

O encaminhamento convencional por múltiplos caminhos de igual custo (ECMP) frequentemente hasheia um fluxo inteiro para uma única rota. Em uma malha Clos ampla, isso pode criar uma loteria. Vários fluxos grandes podem colidir nos mesmos enlaces enquanto capacidade equivalente permanece sem uso em outro lugar. Uma longa transferência de IA pode então ser limitada por um hash infeliz durante toda a sua vida.

O UET aborda isso alterando a entropia na granularidade de pacote. Um remetente pode usar dezenas ou centenas de valores de entropia, permitindo que os mecanismos ECMP existentes nos switches distribuam pacotes por muitas rotas. A Subcamada de Entrega de Pacotes fornece a informação de sequência; a Subcamada de Gerenciamento de Congestionamento seleciona a entropia ou o caminho; os switches executam seu hash normal; e o feedback informa ao remetente quais valores de entropia aparentam estar congestionados.

A pulverização de pacotes só é prática porque outras partes do design a suportam. Pacotes podem chegar fora de ordem. O RUD pode colocar dados diretamente em vez de esperar por uma reordenação completa de transporte. A retransmissão seletiva pode recuperar apenas o que foi perdido. O feedback de congestionamento pode reduzir o uso de caminhos problemáticos. Portanto, o mecanismo não é um truque isolado de balanceamento de carga. Faz parte de um modelo de transporte construído em torno da diversidade de caminhos.

A UEC não exige que cada switch execute um algoritmo proprietário de roteamento adaptativo. Implementações básicas podem usar entropia pseudo-aleatória ou round-robin sobre ECMP padrão. Endpoints mais avançados podem associar sinais de ECN, latência ou corte a valores de entropia particulares e evitar caminhos que parecem congestionados. O encaminhamento adaptativo específico de fornecedor pode coexistir com o UET, mas não é a única fonte de consciência de caminho.

A promessa é uma melhor utilização da malha e menor latência de cauda. A questão não resolvida é quão consistentemente diferentes endpoints interpretam o feedback e como a pulverização de pacotes interage com buffers de switch, reordenação, falhas e tráfego misto. Um algoritmo que funciona bem em um laboratório homogêneo pode se comportar de forma diferente em uma grande malha com várias gerações de switches e classes de tráfego. Evidências independentes e de múltiplos fornecedores ainda são limitadas.

Três mecanismos de congestionamento para três gargalos diferentes

A UEC não define um algoritmo universal de congestionamento. Ela distingue congestionamento no núcleo da rede, incast no receptor e buffer limitado do endpoint.

Network-signal Congestion Control (NSCC) é orientado à fonte. O remetente mantém uma janela de congestionamento, estima bytes em voo e ajusta a janela usando confirmações, confirmações negativas, timeouts, latência e sinais de rede como ECN. Coordena o comportamento da janela com o multipercurso em nível de pacote. A UEC argumenta que uma janela naturalmente interrompe a admissão de dados quando os pacotes não conseguem sair da rede, enquanto um controlador puramente baseado em taxa pode interpretar mal a ausência de feedback.

Esse é o argumento arquitetural do consórcio, não uma prova independente de que toda implementação NSCC supera DCQCN ou outros controles de congestionamento RoCE. Os resultados dependem dos detalhes do algoritmo, da marcação do switch, da topologia, dos padrões de tráfego e das escolhas de parâmetros. “Usa NSCC” não é, portanto, uma alegação de desempenho suficiente.

Receiver-credit Congestion Control (RCCC) tem como alvo o incast. Quando muitas fontes enviam simultaneamente para um destino, o enlace final pode se tornar o gargalo mesmo que o núcleo da rede não esteja congestionado. O receptor rastreia a demanda e distribui créditos entre os remetentes, controlando a chegada agregada e variando a janela efetiva de cada fonte de acordo com a competição. O RCCC pode operar ao lado do NSCC porque a sobrecarga do receptor e o congestionamento do núcleo são problemas diferentes.

Transport Flow Control (TFC) também usa créditos, mas atende serviços ponto a ponto com buffer limitado. Seu propósito é a prevenção direta de estouro de buffer do receptor quando a tolerância à perda é baixa. Pode ser usado com ou sem multipercurso. Tratar todos os mecanismos de crédito como iguais obscureceria os domínios de falha distintos que cada um pretende controlar.

A especificação espera Explicit Congestion Notification em toda a malha e inclui premissas operacionais sobre a marcação, inclusive marcação na desenfileiramento em vez de depender apenas do comportamento de enfileiramento. Os endpoints interpretam ECN juntamente com confirmações, latência e corte. A configuração consistente entre switches é, portanto, essencial. Uma implementação de transporte pode estar correta enquanto uma malha configurada incorretamente produz resultados ruins.

O histórico de manutenção demonstra a dificuldade. A versão 1.0.1 corrigiu o algoritmo de origem do RCCC. A 1.0.2 corrigiu casos de gerenciamento de congestionamento. A 1.0.3 corrigiu interações envolvendo créditos e Link Layer Retry. Esses são sinais normais de uma especificação viva, mas também mostram que o estado de crédito, retransmissão e controle de caminho pode interagir de maneiras sutis. Os operadores precisarão de disciplina de versão e testes de regressão, não apenas conformidade no primeiro dia.

Corte de pacotes e recuperação precisa de perdas

O corte de pacotes altera o que um switch capacitado faz quando não pode preservar um pacote inteiro. Em vez de descartar o quadro sem mais informações, o switch remove a maior parte ou toda a carga útil, preserva cabeçalho e metadados suficientes para identificar o pacote, marca-o como cortado e encaminha a notificação encurtada em direção ao receptor. O receptor pode então relatar os dados faltantes específicos ao remetente.

Isso é mais informativo do que uma marca ECN. ECN diz que houve congestionamento; o corte identifica um pacote cuja carga útil não sobreviveu. Combinado com RUD e retransmissão seletiva, isso pode acelerar a recuperação sem esperar por um timeout ou retransmitir uma longa sequência após uma única perda.

O recurso do switch é opcional, mas os endpoints compatíveis devem receber e interpretar pacotes cortados de acordo com os requisitos aplicáveis. Essa assimetria suporta a implantação sobre switches convencionais, ao mesmo tempo que permite que malhas aprimoradas forneçam informações de perda mais ricas. Também cria um problema de atualização. Uma rede parcialmente aprimorada pode precisar restringir o corte por caminho, perfil ou topologia para que cada endpoint receptor o manipule corretamente.

A UEC também define classes de tráfego diferenciadas para requisições, pacotes de controle, retransmissões e tráfego cortado. Os operadores devem mapear valores DSCP, filas de switch, filas de endpoint e níveis de prioridade de forma consistente. A especificação não fornece um sistema de gerenciamento universal para esse mapeamento. Um descasamento pode famintar o tráfego de controle, distorcer o feedback de congestionamento ou fazer com que os pacotes de recuperação compitam com o tráfego que devem reparar.

O corte de pacotes ilustra o desafio mais amplo de implementação do projeto. O protocolo pode definir o comportamento no fio, mas o resultado operacional depende do enfileiramento do switch, da lógica do endpoint, da telemetria, da configuração e do tratamento de falhas. A interoperabilidade é, portanto, uma propriedade de sistemas, e não uma propriedade de formato de pacote.

Recuperação de enlace, créditos e negociação de recursos

Link Layer Retry (LLR) tenta recuperar corrupção em um enlace físico antes que o transporte ponta a ponta reaja. Um par detecta uma lacuna de sequência ou quadro corrompido, envia uma confirmação negativa no nível do enlace e faz com que o transmissor retransmita o quadro afetado a partir de um buffer local. Se a recuperação for bem-sucedida rapidamente, o transporte pode evitar uma retransmissão ponta a ponta mais longa.

O valor potencial aumenta conforme as taxas de pista e densidades de porta aumentam. Erros ópticos ou elétricos ocasionais podem, de outra forma, criar atrasos desproporcionais em um trabalho fortemente sincronizado. No entanto, o LLR adiciona estado de sequência, buffers de retransmissão, mensagens de controle, janelas de descarte e novos modos de falha. Ele também deve coexistir com atualizações de crédito e reinicializações de enlace. A versão 1.0.3 corrigiu vários casos de borda, incluindo uma condição de corrida envolvendo informações de crédito CBFC e LLR.

Credit-Based Flow Control (CBFC) opera por canal virtual no nível do enlace. Ele informa ao remetente quanta capacidade de recepção resta e pode fornecer um controle mais granular do que pausas amplas por prioridade. A UEC o apresenta como uma forma de suportar comportamento sem perdas controlado sem exigir que cada implantação UET seja globalmente sem perdas. O CBFC é opcional, e o UET é projetado para operar sobre redes de melhor esforço.

O CBFC não deve ser tratado como outro nome para Priority Flow Control. Os mecanismos diferem em sinalização e granularidade, embora ambos busquem evitar estouro de buffer. O CBFC ainda requer configuração consistente e entrega correta de seus próprios quadros de controle. Créditos locais também podem interagir com janelas ponta a ponta e créditos do receptor, criando vários loops de controle aninhados.

A UEC usa negociação baseada em LLDP para descobrir recursos de enlace opcionais e evitar que um lado habilite uma capacidade que seu vizinho não suporta. A negociação deve levar em conta perfis, canais virtuais, mapeamento de DSCP e prioridade, reinicializações, atualizações de software e combinações parciais de recursos. A versão 1.0.3 adicionou uma capacidade de negociação booleana, reforçando a importância do acordo explícito em cada enlace.

Essas opções fornecem um caminho do Ethernet básico ao aprimorado. Elas também criam uma matriz que a linguagem de aquisição pode esconder. Um switch pode encaminhar UET perfeitamente sem ter corte de pacotes, LLR ou CBFC. Outro pode suportar os recursos apenas em certas versões de software ou modos de porta. Um registro de implantação confiável precisa do conjunto exato de recursos, não simplesmente do nome do consórcio.

Sinalização física a 100 e 200 gigabits por pista

A camada física ancora a UEC no roteiro de hardware. O trabalho inicial 1.0 foi escrito em torno da sinalização de 100 Gb/s por pista. A versão 1.0.3 adicionou suporte para 200 Gb/s por pista. Essa mudança alinha a especificação com uma geração de enlaces e sistemas de maior densidade, mas é uma capacidade de especificação, não uma prova de que todos os produtos UEC oferecem suporte imediato a essa taxa.

O trabalho da camada física da UEC também aborda estatísticas de correção antecipada de erros (FEC), proporções de palavras de código corrigíveis e não corrigíveis, conjuntos ordenados de controle, relatórios de qualidade do enlace e a interação entre erros físicos e LLR. Esses detalhes importam porque as decisões de recuperação do transporte dependem do que as camadas inferiores podem observar e relatar.

Em taxas de sinalização mais altas, a fronteira entre óptica, SerDes, FEC, retentativa de enlace e recuperação de transporte se torna economicamente significativa. FEC mais forte pode reduzir erros residuais ao custo de latência e potência. A retentativa de enlace pode recuperar corrupção local mais rapidamente, mas requer buffers e estado. A retransmissão ponta a ponta é mais simples através da rede, mas pode desperdiçar mais tempo. A UEC tenta definir como essas camadas cooperam em vez de permitir que cada fornecedor otimize isoladamente.

A adição de pistas de 200G também ilustra o alvo móvel do consórcio. Implementadores da versão 1.0 devem manter compatibilidade enquanto planejam novas capacidades físicas. Equipamentos de teste, firmware e sistemas de gerenciamento precisam distinguir o que é suportado em cada porta. Compradores não devem inferir a taxa da pista a partir de uma alegação genérica de UEC.

Segurança de transporte ponta a ponta opcional

A Subcamada de Segurança de Transporte (TSS) fornece proteção opcional ponto a ponto. Seu modelo de ameaça não exige que os switches sejam confiáveis. Ela pode fornecer confidencialidade, integridade, proteção contra repetição, isolamento de jobs, domínios seguros, chaveamento de grupo, rotação de chaves e integração com raízes de confiança de hardware.

O design utiliza domínios seguros cujos membros compartilham contexto criptográfico. Identificadores, números de associação, épocas, identidade de origem segura e derivação de chaves são projetados para escalar além do estabelecimento de uma sessão independente para cada par de endpoints. Isso é necessário quando as populações de aceleradores e a associação a jobs mudam rapidamente.

O protocolo é apenas uma parte do sistema de segurança. Um operador de produção deve executar autoridades de chave, certificados ou outras raízes de confiança, serviços de associação a jobs, distribuição e revogação, transições de época, recuperação de endpoints, criptografia de hardware e telemetria de segurança. A rede pode estar em conformidade com um perfil sem habilitar todas as funções opcionais do TSS. “Compatível com UEC” não significa automaticamente criptografado.

A opcionalidade da segurança reflete diferentes pressupostos de implantação. Uma malha fisicamente controlada e dedicada pode priorizar o desempenho e confiar nos controles ambientais. Uma nuvem multilocatário pode exigir forte isolamento e proteção criptográfica. O perfil e o sistema de aquisição devem tornar essa diferença visível.

O risco mais sério não é simplesmente a sobrecarga da criptografia. É a falha no ciclo de vida em escala: associação desatualizada, revogação atrasada, épocas inconsistentes, recuperação após um endpoint falho ou incapacidade de provar qual job pode acessar qual memória. Esses problemas conectam a segurança de transporte a sistemas de orquestração e identidade fora da especificação central.

O que “compatível com UEC” significa atualmente

A UEC começou a publicar materiais de conformidade com a versão 1.0, mas o sistema público não é um regime de certificação independente maduro. O pacote disponível é projetado principalmente para autodeclaração do implementador. Matrizes mapeiam requisitos da especificação para perfis, e a orientação do testbed descreve configurações recomendadas de endpoint e switch. Nenhum banco de dados público abrangente foi identificado no qual uma autoridade independente registre produtos que passaram ou falharam em um programa completo da UEC.

A distinção é essencial porque várias alegações diferentes circulam no mercado. Um produto pode ser projetado em torno de recursos em desenvolvimento da UEC. Pode implementar funções de fio selecionadas. Pode suportar um perfil, ou partes de um perfil, em uma versão de software específica. Um fornecedor pode declarar que está em total conformidade com os recursos. Um laboratório de testes pode gerar tráfego UET através de um switch. Nenhuma dessas declarações é automaticamente equivalente a certificação independente, de múltiplos fornecedores e ponta a ponta.

As recomendações públicas de testbed são úteis, mas deliberadamente limitadas. Elas fornecem topologias e verificações de melhores práticas, em vez de uma qualificação completa do sistema. Os materiais excluem ou não cobrem totalmente testes mais amplos de interoperabilidade, desempenho, estresse, escala e ciclo de vida da API. Eles não comprovam o comportamento sob tráfego misto UET e RoCE, atualizações parciais, falhas repetidas, grandes domínios de chave ou as contagens de endpoints mais ambiciosas do consórcio.

A inconsistência do nome do perfil entre AI Full e AI Extended ilustra ainda mais por que a conformidade precisa de versionamento disciplinado. Um comprador deve perguntar qual especificação, nível de correção, perfil, recursos opcionais, modos de enlace e funções de segurança uma alegação cobre. A resposta deve identificar se a evidência veio de testes internos, uma demonstração bilateral, um evento do consórcio ou um laboratório independente.

Um próximo estágio confiável incluiria definições de teste públicas vinculadas a versões exatas da especificação, plugfests de múltiplos fornecedores, resultados administrados de forma independente, desfechos negativos e também sucessos e um registro que distinga endpoints, switches, software e sistemas completos. Até lá, “compatível com UEC” é uma pergunta inicial, e não uma garantia completa.

Um documento aberto com obrigações de patente RAND

A especificação Ultra Ethernet 1.0.3 é publicamente baixável e distribuída sob a licença Creative Commons Attribution-NoDerivatives 4.0. Isso permite redistribuição com atribuição, mas não permite distribuição de versões modificadas sob a licença. Mais importante, o acesso ao copyright e o acesso a patentes são separados.

Os estatutos documentados dos grupos de trabalho geralmente usam um modelo tradicional de desenvolvimento de especificações com licenciamento de patentes razoável e não discriminatório (RAND). RAND não significa necessariamente royalty zero. Não garante um preço universal único, elimina a negociação ou impede disputas sobre validade, essencialidade, geografia ou condições defensivas. A posição comercial real depende de cada patente declarada, do compromisso do membro e de qualquer licença bilateral.

A UEC mantém um registro público de declarações de Necessary Claims. No fechamento da pesquisa, declarações associadas a Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell e outras eram visíveis, incluindo registros relacionados a futuros trabalhos da versão 1.1. O registro melhora a transparência ao mostrar que os implementadores podem precisar investigar a propriedade intelectual antes de construir ou enviar um produto.

O consórcio explicitamente não determina se uma patente declarada é válida, realmente essencial, infringida ou disponível a um determinado preço. Também não publica uma licença comum. Pequenos implementadores podem, portanto, enfrentar custos legais e de transação que grandes membros podem absorver mais facilmente. Uma especificação publicamente disponível ainda pode produzir um ecossistema de implementação comercialmente concentrado se o custo de liberação de patentes, silício e testes for alto.

O arcabouço de propriedade intelectual também molda os incentivos de governança. As empresas contribuem com tecnologia em parte para criar um mercado amplo para seus produtos e em parte para garantir que suas capacidades existentes estejam representadas no design comum. As declarações de patentes podem proteger os implementadores de surpresas apenas se forem oportunas e suficientemente claras. Elas não eliminam a possibilidade de que o licenciamento se torne uma barreira depois que a arquitetura ganhar adoção.

A descrição honesta, portanto, é “publicamente divulgada e de múltiplos fornecedores, com compromissos de patente RAND”, e não universalmente royalty free. As equipes de aquisição precisam tanto do perfil técnico quanto do caminho de licenciamento.

A primeira onda de produtos e testes

Evidências de implementação tornaram-se visíveis em torno do lançamento da versão 1.0, mas os exemplos ocupam diferentes estágios de maturidade.

A AMD tornou sua Pollara 400 AI NIC disponível comercialmente em abril de 2025 e a descreveu como projetada em torno de capacidades em desenvolvimento da UEC. A Pollara é uma plataforma de endpoint programável e um sinal importante de que o transporte havia passado a hardware embarcado. A redação importa: projeto para recursos em evolução da UEC não é o mesmo que certificação independente contra todos os requisitos finais da versão 1.0.3.

A Broadcom anunciou o Tomahawk 6 em junho de 2025 como um ASIC de comutação de 102,4 terabits por segundo com recursos relevantes para malhas na escala da UEC. Em outubro, anunciou a Thor Ultra 800G NIC e afirmou que o design fornece total conformidade com os recursos UEC. Essa é uma alegação significativa do fornecedor, mas as evidências públicas não a convertem em um certificado independente do consórcio. Amostragem do produto, maturidade do software e suporte exato ao perfil devem ser identificados separadamente.

Nokia e Keysight anunciaram uma demonstração de tráfego UET ponta a ponta em outubro de 2025, através das famílias de switches de data center Nokia 7220 e 7250 a 800 Gigabit Ethernet. A Keysight forneceu geração e validação de tráfego. O teste mostra que o tráfego UET pode atravessar sistemas de comutação comerciais e que o suporte de equipamentos de teste está se desenvolvendo. Ele não estabelece um perfil completo de endpoint de múltiplos fornecedores, escala de produção ou certificação independente de cada recurso opcional.

Outros membros descreveram switches, sistemas, software ou planos de teste capazes para UEC, e a cúpula de 2026 focou fortemente na industrialização. As evidências sustentam uma transição para a implementação. Elas ainda não sustentam uma contagem exata de NICs UET em embarque, switches certificados, regiões de nuvem implantadas ou malhas completas.

A maneira mais útil de ler a onda de produtos é como uma cadeia de evidências. Uma especificação pública permite o design. Anúncios de silício e NICs mostram investimento. Demonstrações de tráfego mostram alguma interoperabilidade. Matrizes de conformidade organizam os requisitos. Relatos de implantação de operadores mostrariam valor operacional. Plugfests independentes e resultados de produção estabeleceriam a credibilidade mais ampla que o registro atual ainda carece.

RoCE, InfiniBand, Slingshot e UALink

A UEC entra em um mercado com alternativas maduras e tecnologias adjacentes. Seu argumento estratégico não é que Ethernet nunca tenha transportado RDMA ou que malhas especializadas não funcionem. É que a escala e a sincronização das cargas de trabalho atuais de IA justificam uma nova arquitetura Ethernet ponta a ponta com entrega mais flexível, uso de caminhos e controle de congestionamento.

RoCEv2 é o predecessor direto e uma tecnologia com grande base instalada. Coloca o tráfego RDMA em Ethernet roteável e tem amplo suporte de aplicações e produtos. A UEC critica implantações comuns de RoCE por fixação de fluxo inteiro em um caminho, recuperação Go-Back-N, reordenação no receptor, difícil ajuste de DCQCN, dependência de Priority Flow Control em muitos projetos e comportamento fraco sob incast ou rajadas coletivas. Essas são posições técnicas da UEC, não evidências de que toda rede RoCE tenha desempenho ruim.

A comparação também é dinâmica. Fornecedores podem adicionar roteamento adaptativo, pulverização de pacotes, melhores algoritmos de congestionamento ou outras funções similares às da UEC a NICs programáveis, mantendo a compatibilidade com RoCE. A mensagem da AMD em torno da Pollara, por exemplo, apresenta RoCEv2 e UEC RDMA como escolhas em hardware programável. A UEC pode, portanto, competir com RoCE como um transporte completo, ao mesmo tempo que influencia a evolução de futuros produtos RoCE.

InfiniBand é a principal alternativa de malha especializada. Oferece um ecossistema integrado de RDMA, congestionamento, confiabilidade de enlace e gerenciamento, com longa experiência em HPC. O trabalho 2.0 da InfiniBand Trade Association inclui suporte físico XDR de 200 Gb/s por pista e telemetria atualizada. A diferenciação mais forte da UEC não é a alegação de que InfiniBand carece de desempenho. É a possibilidade de obter comportamento de IA e HPC através da cadeia de suprimentos mais ampla de Ethernet, roteamento IP padrão e maior escolha de múltiplos fornecedores.

O Slingshot da HPE ocupa uma posição intermediária. É uma malha HPC comercial compatível com Ethernet, com roteamento adaptativo e gerenciamento de congestionamento, e forneceu antecedentes técnicos importantes para o UET. Demonstra que um comportamento especializado pode ser construído sobre Ethernet, ao mesmo tempo que mostra a diferença entre uma plataforma comercial controlada e uma especificação para toda a indústria.

UALink é geralmente complementar em vez de um substituto direto. Sua especificação atual 200G pública tem como alvo conectividade de escala vertical (scale-up) de baixa latência entre aceleradores dentro de um pod e descreve sistemas de até 1.024 aceleradores. A UEC 1.0 é principalmente uma malha de escala horizontal (scale-out) conectando nós através de switches. Um data center pode usar um enlace de scale-up dentro de um pod de computação e UEC entre pods ou nós. Trabalhos futuros da UEC em transporte otimizado para scale-up e operações coletivas na rede podem aproximar as fronteiras e criar convergência ou competição.

NVIDIA Spectrum-X e malhas proprietárias de aceleradores apresentam outra comparação: uma pilha fortemente integrada pode otimizar hardware, software e suporte rapidamente, mas aumenta a dependência de um único ecossistema. A UEC troca parte dessa integração pela promessa de interfaces comuns e escolha de fornecedores. Se a troca vale a pena dependerá do desempenho, suporte, termos de patentes, interoperabilidade e custo operacional total — não da abertura como um rótulo abstrato.

O problema operacional é maior que o protocolo

Uma especificação de 573 páginas pode definir muitos requisitos, mas uma malha de produção ainda precisa de um modelo operacional. A UEC 1.0 deixa um trabalho importante de gerenciamento fora ou ao redor do documento normativo central. Os operadores precisam configurar perfis, classes de tráfego, limiares ECN, conjuntos de entropia, recursos de enlace opcionais, chaves, firmware, telemetria e política de falhas de forma consistente em endpoints e switches.

O tráfego misto torna o problema mais difícil. Uma malha de data center pode transportar UET, RoCE, TCP, armazenamento, gerenciamento e serviços UET ordenados e não ordenados. A alocação de filas e a justiça entre essas classes não são resolvidas meramente porque cada protocolo está implementado corretamente. Um algoritmo de congestionamento pode se comportar bem isoladamente e mal quando compete com outro controlador usando feedback e premissas diferentes.

A complexidade do endpoint é outro risco estrutural. O UET coloca multipercurso, colocação direta, retransmissão seletiva, vários modos de entrega, controle de janela e crédito, recepção de corte, segurança e estado substancial no FEP. Isso pode aumentar a área do die da NIC, o tamanho do firmware, o esforço de verificação, a potência e o número de condições de falha que precisam ser diagnosticadas. A dependência do projeto na inteligência do endpoint torna uma cadeia de suprimentos ampla possível, mas também significa que a implementação mais difícil pode residir no componente que cada servidor precisa comprar.

Recursos opcionais criam diferenciação de produto e fragmentação ao mesmo tempo. Um fornecedor pode otimizar um endpoint básico AI Base para ECMP e ECN convencionais. Outro pode suportar AI Full, TSS, corte de pacotes, LLR e CBFC. Ambos podem participar do ecossistema UEC, mas os operadores não podem presumir a mesma semântica, desempenho ou segurança. Matrizes de conformidade precisam se tornar matrizes de capacidade operacional.

A manutenção de versões será contínua. Correções de 1.0.1 a 1.0.3 afetaram congestionamento, créditos, retentativa e comportamento de pacotes. Um grande cluster pode conter várias versões de firmware de NIC, releases de switch e ferramentas de teste. Atualizar uma camada sem coordenar as outras pode expor exatamente a condição de corrida entre camadas que o consórcio está tentando evitar.

As alianças externas da UEC são, portanto, centrais, e não cerimoniais. O Open Compute Project pode conectar o transporte a sistemas abertos e hardware. A OpenFabrics Alliance e a comunidade libfabric conectam aplicações. O IEEE 802.3 provê o trabalho formal de Ethernet. SNIA e NVM Express trazem requisitos de armazenamento e gerenciamento. As tecnologias da IETF fornecem IP, ECN e mecanismos relacionados. Essas organizações têm processos de decisão e roteiros diferentes; a ligação reduz a duplicação, mas não pode garantir adoção simultânea.

O teste operacional final é a infraestrutura em execução. Um documento pode especificar o comportamento, um fornecedor pode anunciar um produto e um consórcio pode organizar uma cúpula. Nada disso substitui um cluster no qual endpoints e switches independentes concluem trabalhos reais sob congestionamento, falha e atualização, enquanto os operadores podem explicar o que aconteceu.

Relevância atual: da vitória da especificação à credibilidade de implementação

Até julho de 2026, a UEC havia alcançado várias coisas que eram incertas no lançamento. Formou uma ampla coalizão, produziu uma arquitetura integrada de cinco camadas, lançou uma especificação 1.0 completa, manteve-a por meio de releases de correção, adicionou suporte a 200G por pista, divulgou declarações de patentes e atraiu anúncios de produtos e testes. O projeto está ativo e sua agenda mudou decisivamente para a implementação.

Esse progresso torna as próximas incertezas mais importantes, não menos. O número exato atual de membros e a composição do Comitê Diretivo não são publicados em um registro autoritativo único. As páginas públicas de associação e o estatuto descrevem o acesso de forma diferente. A liderança atual formal do TAC não está totalmente conciliada com os papéis da cúpula. A data de lançamento da versão 1.0.2 conflita em documentos oficiais. O pacote de conformidade usa terminologia de perfil desatualizada.

Nenhum desses problemas destrói a arquitetura, mas cada um é um sinal sobre controle de documentos e transparência em um projeto onde versões exatas importam.

Lacunas mais consequentes dizem respeito à adoção. A UEC não publica um censo de implantação, registro de produtos verificado independentemente, orçamento autônomo ou contas auditadas. Nenhuma evidência pública estabelece uma rede UEC 1.0 totalmente interoperável nas metas de escala máximas do consórcio. Demonstrações e alegações de fornecedores são valiosas, mas comercialmente interessadas. Comparações de desempenho neutras com as plataformas atuais RoCE, InfiniBand e Ethernet integrada permanecem limitadas.

A oportunidade do consórcio ainda é substancial. Ethernet é o denominador comum entre data centers, e o mercado de infraestrutura de IA é grande o suficiente para suportar novas gerações de NICs, switches, óptica e software. Os operadores têm fortes incentivos para evitar dependência de um único fornecedor e para melhorar a utilização dos aceleradores. Uma pilha comum poderia transformar esses incentivos em poder de compra.

Seu risco é que “Ultra Ethernet” se torne um guarda-chuva para subconjuntos de recursos incompatíveis. Se o encaminhamento básico funcionar, mas os perfis, o congestionamento, a segurança e o gerenciamento divergirem, a marca pode se espalhar mais rápido que a interoperabilidade. Se o licenciamento RAND for caro ou incerto, o conjunto de fornecedores pode se estreitar. Se os produtos RoCE absorverem as ideias mais atraentes sem exigir um novo transporte, a UEC pode influenciar o mercado sem se tornar o rótulo dominante.

A questão decisiva não é mais se o consórcio pode publicar uma especificação sofisticada. Ele já o fez. A questão é se organizações independentes podem implementar os mesmos contratos, licenciar a tecnologia necessária, operar a malha em escala e preservar a compatibilidade conforme a especificação evolui. A UEC se tornará infraestrutura apenas na medida em que essas afirmações sobrevivam ao contato com o código em execução.