Resumo

  • O Consórcio Ultra Ethernet é 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 industrial para desenvolvimento de especificações, não uma empresa tradicional ou operadora de rede.
  • O escopo da UEC vai muito além de apenas um link Ethernet mais rápido ou um substituto para RoCE. A especificação 1.0.3, com 573 páginas, abrange as camadas de software, transporte, rede, enlace e física, além de gerenciamento, armazenamento, testes e conformidade em torno da pilha principal.
  • O Ultra Ethernet Transport combina múltiplos modos de entrega, múltiplos caminhos no nível de pacote, retransmissão seletiva, controle de congestionamento no emissor e receptor, ECN, descarte parcial de pacotes opcional, retransmissão local opcional, controle de fluxo baseado em créditos opcional e segurança de transporte opcional de ponta a ponta.
  • Produtos e demonstrações da AMD, Broadcom, Nokia e Keysight indicam o início da implementação, mas a conformidade pública ainda depende principalmente da autodeclaração do implementador, e não foi publicado um registro abrangente de certificações independentes ou contagem de implantações em larga escala.
  • A oportunidade estratégica da UEC se baseia na base instalada do Ethernet e em sua cadeia de fornecedores múltiplos. Os principais riscos são a complexidade dos endpoints, a fragmentação devido a recursos opcionais, compromissos de patentes RAND, imaturidade de gerenciamento e testes, e a lacuna entre a publicação da especificação e a comprovação da interoperabilidade em ambiente de produção.

Por que a inteligência artificial tornou a rede parte do computador

O Consórcio Ultra Ethernet surgiu em resposta a uma mudança na economia da computação. Em uma rede corporativa comum, espera-se que a malha de rede transporte um grande número de fluxos independentes com taxa de transferência e disponibilidade aceitáveis. Já em um sistema grande de treinamento de inteligência artificial ou em uma máquina de computação de alto desempenho, a rede se torna parte de uma única operação computacional síncrona. Milhares de aceleradores podem trocar parâmetros de modelos, gradientes ou dados científicos em operações coletivas.

A próxima fase pode não avançar até que o participante mais lento receba as informações necessárias. Assim, um pequeno desbalanceamento entre caminhos, um estado de congestionamento ou a perda de um único pacote pode deixar processadores de alto custo em estado de espera, mesmo que a utilização média da malha pareça boa.

Isso muda o que os operadores tentam otimizar. A capacidade total ainda é importante, mas não é suficiente. Também importam o tempo de conclusão da tarefa, a latência de cauda, o incast, a recuperação de perdas, a distribuição de tráfego por caminhos paralelos e a quantidade de estado que os endpoints precisam manter. Uma rede que entrega a maioria dos pacotes rapidamente, mas atrasa uma pequena porcentagem, pode interromper uma operação coletiva inteira. Um método de retransmissão aceitável para tráfego tradicional pode ser muito lento se um único pacote de uma mensagem longa for perdido.

Da mesma forma, o desempenho de um fluxo fixado em um único caminho de custo igual pode cair enquanto há capacidade disponível em outros pontos da topologia.

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

A resposta da UEC é uma arquitetura coordenada. Ela mantém Ethernet e IP porque os operadores os conhecem e porque uma enorme cadeia de suprimentos cresceu em torno de switches, óptica, cabos, sistemas operacionais de rede, telemetria e gerenciamento. Ao mesmo tempo, modifica ou expande as partes que o consórcio considera inadequadas para as cargas de trabalho de IA e HPC. O resultado não é “Ethernet comum com um novo slogan”, mas uma tentativa de fazer uma rede familiar transportar um transporte especializado cujo comportamento é definido desde a interface de software até a velocidade do caminho físico.

Esse ponto mostra por que a UEC é importante para a infraestrutura digital. O projeto não possui aceleradores, fábricas, data centers ou regiões de nuvem. Mas define contratos que as empresas-membro e outros implementadores podem colocar dentro de NICs, ASICs de switches, sistemas, drivers, bibliotecas e equipamentos de teste. Seu impacto só se concretizará quando esses produtos independentes trocarem tráfego corretamente sob falhas, congestionamento, atualizações e combinações de fornecedores.

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

O Consórcio Ultra Ethernet é o nome público de um projeto formal cujo nome legal completo é Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. A estrutura de “série” coloca o projeto dentro da Joint Development Foundation e da família mais ampla da Linux Foundation. Ela oferece aos participantes uma estrutura legal existente para associação, governança, propriedade intelectual, financiamento e relações externas, sem a necessidade de criar uma nova empresa independente.

Essa estrutura é importante porque a UEC às vezes é descrita de forma imprecisa como uma empresa, aliança ou organismo de padronização. Ela não é uma empresa comercial com acionistas, capital, avaliação e contas independentes. Não vende produtos Ethernet, não opera uma rede pública, não possui o hardware promovido por seus membros. É um consórcio de desenvolvimento de especificações dentro de um quadro jurídico e de propriedade intelectual. O propósito de seus documentos públicos é servir como contratos de implementação entre múltiplas empresas.

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

A UEC também não é o grupo IEEE 802.3. Esse grupo desenvolve os padrões Ethernet básicos nas camadas MAC e física por meio de seu próprio processo formal. A UEC se baseia nesse sistema e mantém uma relação de coordenação, mas não o substitui. Os mesmos limites se aplicam aos mecanismos da IETF usados pelo UET, incluindo IPv4, IPv6 e Explicit Congestion Notification; ao ecossistema OpenFabrics que gerencia o libfabric; e às entidades que trabalham com armazenamento, hardware aberto e interconexões de aceleradores.

O site do projeto usou uma linguagem que sugere status de organismo internacional de padrões. A descrição mais segura e baseada em evidências é que a UEC é uma organização internacional de desenvolvimento de especificações dentro do quadro da JDF. Não há evidência de que faça parte da International Organization for Standardization, que seus documentos sejam normas ISO ou que tenha um número de padrão ISO. A distinção não é apenas terminológica; ela define a fonte de autoridade, como se participa e as obrigações legais que os implementadores podem enfrentar.

Portanto, a UEC deve ser avaliada com base no papel que realmente desempenha. Ela coordena concorrentes e operadores em torno de um design técnico comum, publica especificações, gerencia grupos de trabalho e compromissos de patentes declarados, e desenvolve materiais de conformidade e relações com órgãos vizinhos. Mas não pode, por mero anúncio, tornar um produto interoperável ou forçar o mercado a adotar sua arquitetura.

O consórcio fundador de nove empresas

O consórcio foi anunciado em 19 de julho de 2023 por nove organizações que atuam em diferentes camadas da cadeia de suprimentos de IA e HPC: AMD, Arista Networks, Broadcom, Cisco, Eviden, então ligada à Atos, Hewlett Packard Enterprise, Intel, Meta e Microsoft. Essa diversidade foi um ativo estratégico desde o início. Um transporte projetado apenas por fabricantes de switches poderia negligenciar as restrições das aplicações e dos endpoints. Um design liderado por empresas de aceleradores poderia ser otimizado em torno de um único ecossistema de hardware.

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

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

O consórcio também reúne interesses comerciais concorrentes. Os membros vendem NICs, chips de switch, sistemas, capacidade de nuvem, óptica, software e suporte. Alguns possuem portfólios de patentes que podem ser essenciais para a implementação. Alguns se beneficiam de um padrão amplo com múltiplos fornecedores, ao mesmo tempo em que podem lucrar com recursos proprietários diferenciados. Portanto, o consórcio não elimina a concorrência; ele cria um fórum onde concorrentes concordam com interfaces mínimas e continuam competindo em qualidade de implementação, desempenho, integração e condições comerciais.

O Slingshot da HPE oferece um exemplo útil da origem técnica. É uma malha HPC comercial compatível com Ethernet que inclui roteamento adaptativo e gerenciamento de congestionamento. Comentários ligados à HPE mencionaram que uma especificação de “HPC Ethernet” foi submetida à UEC, estimando que uma parte significativa do UET deriva das ideias de transporte do Slingshot. A proporção exata não foi verificada de forma independente e não deve ser apresentada como um cálculo oficial do consórcio.

O ponto mais amplo, porém, é bem sustentado: a UEC não começou de uma folha em branco, mas se beneficiou da experiência de produção em HPC, redes de nuvem, RDMA e Ethernet.

Essa combinação com sistemas anteriores é motivo para usar a palavra “aberto” com precisão. A especificação aprovada está disponível para download público, e a arquitetura é projetada para implementação por múltiplos fornecedores. Mas o projeto também é um espaço onde os membros contribuem com conhecimento prévio, patentes e roteiros de produtos. A abertura do documento não elimina as condições econômicas ou jurídicas que cercam a tecnologia.

Uma cadeia jurídica projetada para a cooperação entre concorrentes

O modelo da Joint Development Foundation dá ao Consórcio UEC uma estrutura formal sem transformá-lo em uma empresa operacional tradicional. O projeto tem nome, escopo, categorias de associação, um Steering Committee, grupos de trabalho e compromissos de propriedade intelectual. A estrutura da JDF oferece a base institucional e sem fins lucrativos, podendo manter os ativos e acordos do projeto. Isso reduz o custo de criação de um consórcio e proporciona aos concorrentes um processo reconhecido de cooperação.

O Steering Committee governa o projeto. Suas responsabilidades documentadas incluem coordenar os grupos de trabalho, admitir membros, gerenciar ativos e finanças, selecionar ou substituir o chair, monitorar o progresso e controlar as divulgações públicas e as marcas do projeto. O consenso é preferido. Se não for possível, o documento organizacional prevê um mecanismo de supermaioria de três quartos dos participantes elegíveis que atendam aos requisitos de presença. Objeções por escrito podem ser submetidas ao chair.

Brad Booth, da Meta, foi o chair original. A atual especificação 1.0.3 nomeia J Metz, da AMD, como chair; Barry Davis, da HPE, como vice-chair; Hugh Holbrook, da Arista, como chair do Technical Advisory Committee; e Puneet Agarwal, da Marvell, como vice-chair do TAC. Paul Congdon aparece como editor da especificação. O documento também nomeia líderes e autores nos trabalhos das camadas física, de enlace, transporte e software. A pauta da Cúpula de 2026 menciona outros dirigentes operacionais.

Essas funções não implicam necessariamente a substituição dos títulos oficiais na especificação, e não está disponível um organograma público completo e atualizado.

O documento organizacional prevê três categorias de associação: Steering, General e Contributor. Os membros Steering participam da governança e normalmente designam representantes no Steering Committee. Os membros General podem atuar em todos os grupos técnicos, mas não ocupam assentos no comitê. Já os membros Contributor participam de grupos selecionados e não têm direito a voto nas decisões de supermaioria.

A página pública de associação atualmente exibe as categorias General e Contributor com taxas anuais de US$ 20 mil e US$ 5 mil, respectivamente, mais a associação à Linux Foundation, mas não explica claramente o processo de admissão ou o valor atual da categoria Steering.

A diferença na autoridade formal é relevante. A associação ampla traz experiência e alcance de implementação, mas a governança não é igualmente distribuída. Grandes empresas capazes de ocupar assentos no Steering, alocar engenheiros para vários grupos e gerenciar programas de patentes e produtos exercem uma influência prática maior do que membros Contributor menores. Não membros podem baixar a especificação final, mas não acompanham todo o processo de elaboração das versões preliminares nem participam em igualdade de condições.

As informações internas do projeto não são tratadas como dados corporativos confidenciais comuns, mas os membros estão proibidos de divulgar materiais em versão preliminar antes da aprovação da publicação pelo comitê pertinente. Isso pode ajudar os concorrentes a discutir ideias inacabadas sem sinais precoces para o mercado. Mas também significa que o público não vê as propostas rejeitadas, os registros de votação, as preocupações intermediárias de implementação ou as negociações que resultaram nos recursos opcionais. A especificação final é aberta; o caminho até ela é apenas parcialmente visível.

De quatro grupos de trabalho a uma especificação de 573 páginas

A estrutura pública inicial da UEC em 2023 se concentrou em quatro grupos de trabalho: software, transporte, enlace e camada física. A sequência refletia a ambição de ponta a ponta do projeto. A associação não foi aberta imediatamente como uma lista pública de discussão sem restrições. Mais de 200 organizações manifestaram interesse, e o consórcio implementou a adesão em fases, exigindo orientação sobre procedimentos e regras antitruste. A cautela era compreensível, pois os participantes concorrem diretamente em vários mercados e discutiriam requisitos comuns de produtos e protocolos.

Em dezembro de 2023, a UEC relatou cerca de 40 empresas e mais de 300 indivíduos. Já havia criado o Technical Advisory Committee e se expandido para oito grupos de trabalho. O objetivo do TAC era manter a coerência arquitetônica: o design do transporte não deveria pressupor um comportamento de switch, um método de sinalização ou uma API que outro grupo não tivesse concordado em suportar. Em março de 2024, o consórcio informou 55 empresas e mais de 750 participantes ativos e publicou uma descrição bem mais clara da arquitetura pretendida.

As atualizações de março apresentaram as ideias centrais que depois apareceram na especificação normativa: libfabric como API voltada para software, packet spraying, ordenação flexível, múltiplos modos de entrega, controle de congestionamento no emissor e receptor, ECN, packet trimming, Link Layer Retry, controle opcional baseado em créditos, segurança de transporte e futuras operações coletivas dentro da rede. Também enfatizaram que o UET pode operar sobre switches Ethernet existentes, enquanto switches aprimorados oferecem desempenho adicional.

O número de organizações participantes cresceu em paralelo ao trabalho técnico. A UEC reportou 1.193 participantes ativos em julho de 2024 e 97 organizações membros em agosto. Esses são números datados, emitidos pelo consórcio e baseados em definições que não são totalmente públicas, portanto não devem ser somados automaticamente a anúncios posteriores. Em 2025, o consórcio informou a entrada de mais 27 empresas, mas saídas, fusões e sobreposição de períodos impedem que isso comprove um total atual exato. O próprio site afirma que nem todos os membros aparecem na página.

O consórcio publicou 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 pública de implementação. A versão 1.0.1 veio em setembro e corrigiu o algoritmo de fonte no controle de congestionamento baseado em créditos do receptor e alguns problemas editoriais. A versão 1.0.2 chegou em janeiro de 2026 e corrigiu algoritmos de gerenciamento de congestionamento, embora os documentos oficiais divirjam se a data de lançamento foi 21 ou 28 de janeiro. Essa divergência deve ser mantida visível, em vez de resolvida sem explicação.

A versão 1.0.3, publicada em 16 de julho de 2026, é a referência atual no momento da pesquisa. Tem 573 páginas e adiciona suporte para sinalização de 200 Gbps por pista e capacidade de negociação lógica. As notas de versão também listam correções obrigatórias relacionadas à entrega de pacotes, créditos de congestionamento, Link Layer Retry e conjuntos ordenados de controle na camada física, além de esclarecimentos sobre segurança de transporte, operações atômicas e pacotes recortados.

A diferença entre correções obrigatórias e esclarecimentos editoriais é importante, pois algumas mudanças afetam o comportamento conforme e exigem manutenção da implementação.

A Cúpula de Membros em Denver, em 2026, mostrou uma segunda transição. A pauta focou em implantação, transformação da especificação em produtos, conformidade, gerenciamento, desempenho, depuração, integração de armazenamento e testes de switches e endpoints. O documento arquitetônico fundamental existe; a credibilidade do projeto agora depende mais da capacidade dos implementadores de construir, qualificar, operar e atualizar a pilha através das fronteiras organizacionais.

Uma arquitetura em cinco camadas funcionais

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

No topo, frameworks de IA, MPI, SHMEM e bibliotecas de operações coletivas interagem por meio das OpenFabrics Interfaces, especialmente o libfabric. A Subcamada de Serviços Semânticos do UET traduz as operações da aplicação em transações de transporte. A Subcamada de Entrega de Pacotes decide como as mensagens são segmentadas, ordenadas, confirmadas e recuperadas. O gerenciamento de congestionamento controla a quantidade de dados que entra na malha e como o tráfego é distribuído pelos caminhos. A segurança de transporte opcional protege o tráfego de ponta a ponta. O IPv4 ou IPv6 padrão fornece o roteamento na camada de rede.

O Ethernet fornece o enlace, com packet trimming, Link Layer Retry, Credit-Based Flow Control e negociação de recursos opcionais. A camada física especifica estatísticas e requisitos de sinalização em 100 ou 200 Gbps por pista.

Essa estrutura preserva partes importantes da rede atual. A UEC não especifica um substituto para o roteamento IP. Ela pressupõe ECMP tradicional e switches com suporte a ECN. Grande parte da inteligência permanece nos Fabric Endpoints, que alteram valores de entropia, rastreiam o estado do transporte, realizam o posicionamento de dados e respondem aos sinais de congestionamento. Switches aprimorados podem adicionar funcionalidades, mas o design não exige a substituição de toda a malha antes de encaminhar o tráfego UET.

Isso oferece uma vantagem de transição, mas cria um problema de classificação. Uma implantação pode usar endpoints UET sobre Ethernet tradicional com ECMP e ECN. Outra pode adicionar trimming, retransmissão no enlace, créditos por canal virtual, telemetria mais rica e futuras operações dentro da rede. Ambas podem ser chamadas de Ultra Ethernet, embora seu desempenho, propriedades de recuperação e complexidade operacional difiram substancialmente.

Além disso, a abordagem de cinco camadas dificulta isolar falhas de implementação. O mau desempenho pode vir do alinhamento da aplicação, da máquina de estados do endpoint, dos parâmetros de congestionamento, da configuração de filas do switch, do mapeamento de DSCP, da óptica, do firmware ou do subsistema de segurança. A passagem de pacotes por si só não basta. O sistema deve manter 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 proprietária de aplicação

A UEC escolhe o libfabric 2.0 como a API de nível superior básica para endpoints conformes. Essa escolha vincula o projeto a um ecossistema de software existente para HPC e redes avançadas, em vez de exigir que cada framework adote uma nova interface proprietária. O libfabric já representa fabrics, domains, endpoints, completion queues, event queues, address vectors, memory regions, mensagens, operações remotas de memória e operações atômicas. A UEC alinha e restringe esses conceitos para que os provedores convertam as 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 mesmo que o provedor subjacente mude. Em princípio, uma aplicação pode solicitar uma operação sem saber qual fornecedor de NIC está realizando a entrega ou qual tipo de silício do switch está roteando os pacotes. Esse é um dos principais mecanismos pelos quais um transporte comum pode criar opções entre fornecedores.

Abstração não garante implementações equivalentes. Os provedores podem suportar tamanhos de injeção diferentes, limites de scatter/gather diferentes, quantidades diferentes de endpoints, operações atômicas, técnicas de registro de memória, comportamento de completion, hardware offload e funcionalidades de segurança distintas. Uma biblioteca construída sobre a mesma API pode encontrar limites de desempenho e capacidade diferentes. Por isso, as aquisições e a qualificação de software precisam de mais do que um selo “compatível com libfabric”.

A camada de software também carrega a semântica de tarefas e delegação. Sistemas de IA e HPC costumam executar muitas tarefas em uma infraestrutura compartilhada, cada uma com seus próprios processos, regiões de memória e limites de segurança. A especificação precisa definir a qual endpoint cada tarefa pertence, a memória que pode acessar, como a operação remota é correspondida e como as informações de conclusão ou erro retornam ao software. Essas decisões determinam se a rede rápida é realmente utilizável pelo escalonador, pelo ambiente de execução e pela aplicação, e não apenas um número impressionante em um teste 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 é composta por componentes governados em lugares diferentes. O consórcio pode definir o alinhamento do seu transporte com o libfabric, mas precisa coordenar com os mantenedores da API e seus usuários. Dependências semelhantes existem com o Ethernet no IEEE, com os mecanismos de rede na IETF, com entidades de armazenamento e com sistemas operacionais de fornecedores.

Fabric Endpoints e perfis de carga de trabalho

O Fabric Endpoint, ou FEP, é o local lógico onde o UET termina. Conecta uma única instância do sistema operacional a um ou mais níveis de malha isolada e pode incluir um provedor de espaço de usuário, um driver de kernel, o transporte dentro da NIC ou do acelerador, um sistema de registro de memória, um contexto de segurança, completion queues, address vectors e o estado usado para entrega de pacotes e controle de congestionamento.

Esse design centrado no endpoint permite que a maioria dos switches permaneça como dispositivos Ethernet e IP de função clara. O FEP escolhe os valores de entropia, mantém o estado dos pacotes e do congestionamento, posiciona os dados na memória autorizada e interpreta confirmações, trimming e outros feedbacks. Isso pode reduzir a dependência de inteligência de roteamento proprietária no switch, mas 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. Não são tipos de rede separados, mas conjuntos que determinam quais funcionalidades a implementação deve suportar. O AI Base visa cobrir comunicações comuns de IA com menor custo e estado de implementação. O AI Full adiciona recursos como deferrable sends, exact matching e operações atômicas do tipo fetch ou compare. O perfil HPC inclui a maioria das capacidades do AI Full, mas exclui deferrable send e dá mais peso à ordenação, mensagens curtas e semântica de HPC.

O sistema de perfis tenta evitar que todo produto seja obrigado a implementar o conjunto máximo de recursos. Reconhece que uma NIC voltada para IA de larga escala pode priorizar o tráfego de dados coletivos, enquanto um endpoint HPC pode exigir ordenação e operações atômicas mais robustas. Mas os perfis não eliminam as opções. Um produto pode implementar recursos opcionais dentro de um perfil, e dois produtos com o mesmo nome de perfil podem diferir em segurança, otimizações de enlace, capacidade e desempenho.

Um sinal de alerta aparece na própria terminologia. A especificação de referência 1.0.3 usa os nomes AI Base, AI Full e HPC. Enquanto isso, um readme separado de conformidade de 2025 usa AI Base, AI Extended e HPC. A interpretação mais baseada em evidências é que “AI Full” é o nome atual e o material de conformidade está desatualizado ou inconsistente. Até que o pacote de testes público seja corrigido, fornecedores e compradores devem especificar a versão da especificação e o nome exato do perfil por trás de cada 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ços de buffers, operações tagged e untagged, acesso remoto à memória, operações atômicas, comportamento de completion, identificadores de tarefa, delegação de buffers, respostas e erros. Em seguida, a Subcamada de Entrega de Pacotes determina como essa intenção se transforma em pacotes e como eles chegam a outro endpoint.

Nos modos confiáveis, os endpoints criam Packet Delivery Contexts (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 de caminho de retorno e classe de tráfego. Um único PDC está associado a um modo de entrega e uma classe de tráfego, e vários PDCs podem existir entre o mesmo par de FEPs.

Esse estado não é um detalhe simples. Clusters grandes podem criar quantidades enormes de relações de comunicação. Se cada relação exigir um estado extenso no destino, a memória do endpoint e o custo de busca podem se tornar uma restrição. Por isso, a UEC não força toda operação a um único modelo de comunicação, mas define quatro modos de entrega com diferentes contratos de confiabilidade e ordenação.

O Reliable Unordered Delivery (RUD) entrega cada pacote exatamente uma vez à camada semântica, permitindo que os pacotes cheguem fora de ordem. Suporta packet spraying por múltiplos caminhos, retransmissão seletiva, prevenção de duplicatas e posicionamento direto de dados. Como o destino pode posicionar os dados por deslocamento em vez de esperar por um buffer de reordenação no transporte, uma operação coletiva longa pode usar vários caminhos sem que todos os pacotes fiquem enfileirados atrás de um único pacote perdido.

O Reliable Ordered Delivery (ROD) oferece entrega única e em ordem. Usa um único caminho e um único valor de entropia, descarta pacotes fora de ordem e baseia-se em Go-Back-N a partir do primeiro número de sequência perdido. Parece menos complexo que o RUD, mas preserva a semântica necessária quando a ordenação estrita é importante. A UEC trata a ordenação como um requisito da aplicação, em vez de impor seu custo a todo transporte.

Já o Reliable Unordered Delivery for Idempotent Operations (RUDI) oferece um compromisso diferente. Garante entrega pelo menos uma vez e permite duplicatas, reduzindo o estado de sequenciamento e confirmação habitual no destino. Pode ser útil quando a repetição da operação não altera o resultado final, como em certas movimentações de memória remota seguidas por uma barreira separada. No entanto, é arriscado se usado incorretamente. A camada de pacotes não deduz se a operação é idempotente; o software precisa decidir. Usar RUDI para uma operação não idempotente pode produzir um estado de aplicação incorreto.

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

Os quatro modos revelam uma filosofia central: a rede deve expor múltiplos mecanismos para que o software combine o custo de transporte com a semântica da operação. O benefício é a eficiência; o custo é uma superfície de implementação e teste maior e mais oportunidades para que fornecedores, aplicações ou operadores escolham combinações incompatíveis.

Packet spraying: usando a malha em vez de depender de um único caminho sortudo

O ECMP tradicional frequentemente coloca um fluxo inteiro em um único caminho por meio de hash. Em uma malha Clos ampla, isso pode se tornar uma loteria. Vários fluxos grandes podem colidir nos mesmos enlaces enquanto capacidade equivalente permanece ociosa em outros lugares. Um longo transporte de IA pode ficar limitado por toda a sua duração a um caminho mal escolhido.

O UET resolve isso variando a entropia em nível de cada pacote. O remetente pode usar dezenas ou centenas de valores, permitindo que os mecanismos de ECMP existentes nos switches distribuam os pacotes por muitos caminhos. A Subcamada de Entrega de Pacotes fornece as informações de sequenciamento; a Subcamada de Gerenciamento de Congestionamento escolhe o valor de entropia ou o caminho; os switches realizam o hash habitual; e o feedback informa ao remetente quais valores parecem congestionados.

O packet spraying só se torna viável porque outras partes do design o suportam. Os pacotes podem chegar fora de ordem. O RUD consegue posicionar os dados diretamente, sem esperar por uma reordenação completa no transporte. A retransmissão seletiva recupera apenas o que foi perdido. O feedback de congestionamento reduz o uso dos caminhos afetados. Portanto, a técnica não é um truque isolado de balanceamento de carga, mas 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 round-robin ou entropia pseudoaleatória sobre ECMP padrão. Endpoints avançados podem associar sinais de ECN, latência ou trimming a valores específicos e evitar caminhos congestionados. O roteamento adaptativo proprietário do fornecedor pode coexistir com o UET, mas não é a única fonte de consciência de caminho.

A promessa é melhor utilização da malha e menor latência de cauda. A questão não resolvida é quão consistente será a interpretação do feedback por diferentes endpoints e como o spraying 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 maneira diferente em uma malha grande com múltiplas gerações de switches e diferentes classes de tráfego. Evidências independentes de múltiplos fornecedores ainda são limitadas.

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

A UEC não define um único algoritmo de congestionamento universal. Ela diferencia entre congestionamento no núcleo da rede, incast no receptor e limitações de buffer nos endpoints.

O Network-signal Congestion Control (NSCC) é um mecanismo orientado pelo emissor. O remetente mantém uma janela de congestionamento, estima o volume de dados em trânsito e ajusta a janela com base em acknowledgements, negative acknowledgements, timeouts, latência e sinais de rede como ECN. Também coordena o comportamento da janela com o uso de múltiplos caminhos em nível de pacote. A UEC argumenta que a janela naturalmente para de introduzir novos dados quando os pacotes não conseguem sair da rede, enquanto um controlador baseado apenas em taxa pode interpretar erroneamente a ausência de feedback.

Essa é a proposta arquitetônica do consórcio, não uma evidência independente de que toda implementação de NSCC supera o DCQCN ou outros mecanismos do RoCE. Os resultados dependem dos detalhes do algoritmo, da forma como os switches marcam, da topologia, dos padrões de tráfego e dos parâmetros escolhidos. Portanto, a frase “usa NSCC” não é suficiente para comprovar desempenho.

O Receiver-credit Congestion Control (RCCC) visa o problema de incast. Quando muitas fontes enviam simultaneamente para um único destino, o último enlace pode se tornar o gargalo, mesmo que o núcleo da rede não esteja congestionado. O receptor monitora a demanda e distribui créditos entre os remetentes, regulando a taxa agregada de chegada e alterando a janela efetiva de cada fonte conforme a contenção. O RCCC pode operar junto com o NSCC, pois a pressão no receptor e o congestionamento no núcleo são problemas diferentes.

O Transport Flow Control (TFC) também usa créditos, mas atende a conexões ponto a ponto com buffers limitados. Seu objetivo imediato é evitar o estouro do buffer do receptor quando a tolerância a perdas é baixa. Pode ser usado com ou sem múltiplos caminhos. Tratar todos os mecanismos de crédito como uma coisa só obscurece os diferentes domínios de falha que cada um foi projetado para resolver.

A especificação espera o uso de Explicit Congestion Notification em toda a malha e faz suposições operacionais sobre a marcação, incluindo a marcação no dequeue, em vez de depender apenas do enqueue. Os endpoints interpretam o ECN junto com acknowledgements, latência e trimming. Portanto, a consistência na configuração dos switches torna-se essencial. Uma implementação de transporte pode estar correta, mas uma malha mal configurada pode apresentar baixo desempenho.

O histórico de manutenção revela a complexidade. A versão 1.0.1 corrigiu o algoritmo de fonte do RCCC; a 1.0.2 corrigiu situações no gerenciamento de congestionamento; a 1.0.3 corrigiu interações entre créditos e Link Layer Retry. Esses são sinais normais de uma especificação viva, mas também mostram que cenários de créditos, retransmissão e controle de caminho podem interagir de maneiras sutis. Os operadores precisarão de disciplina de versionamento e testes de regressão, não apenas de conformidade inicial.

Packet trimming e recuperação refinada de perdas

O packet trimming modifica o que um switch capaz faz quando não consegue armazenar o pacote completo. Em vez de descartar o quadro sem informações adicionais, ele remove a maior parte ou toda a carga útil, preserva cabeçalho e metadados suficientes para identificar o pacote, marca-o como trimmed e envia a notificação truncada para o receptor. O receptor pode então informar ao remetente exatamente quais dados foram perdidos.

Isso fornece informações mais precisas do que a marcação ECN. O ECN diz que houve congestionamento, enquanto o trimming identifica o pacote exato cuja carga útil não sobreviveu. Com RUD e retransmissão seletiva, a recuperação pode ser acelerada sem esperar por timeout ou uma longa retransmissão em sequência por uma única perda.

O recurso no switch é opcional, mas os endpoints conformes são obrigados a receber e interpretar pacotes trimmed quando os requisitos se aplicam. Essa assimetria facilita a implantação do UET sobre switches comuns, ao mesmo tempo em que permite que malhas aprimoradas ofereçam informações de perda mais ricas. No entanto, também cria um problema de atualização: uma rede parcialmente aprimorada pode precisar restringir o trimming por caminho, perfil ou topologia para garantir que todo endpoint receptor o trate corretamente.

A UEC também define diferentes classes de tráfego para requisições, pacotes de controle, retransmissões e tráfego trimmed. Os operadores precisam alinhar consistentemente os valores de DSCP, filas de switch, filas de endpoint e níveis de prioridade. A especificação não fornece um sistema de gerenciamento universal para esse alinhamento. Um erro pode causar starvation do tráfego de controle, distorcer o feedback de congestionamento ou fazer com que os pacotes de recuperação compitam com o próprio tráfego que deveriam consertar.

O packet trimming resume o desafio mais amplo de implementação. O protocolo pode especificar o comportamento na rede, mas o resultado operacional depende das filas do switch, da lógica do endpoint, da telemetria, da configuração e do tratamento de falhas. A interoperabilidade é uma propriedade do sistema inteiro, não apenas do formato do pacote.

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

O Link Layer Retry (LLR) tenta recuperar um erro em um enlace físico antes que o transporte de ponta a ponta reaja. O lado receptor detecta uma lacuna de sequência ou um quadro corrompido, envia um negative acknowledgement em nível de enlace e faz o remetente reenviar o quadro afetado a partir de um buffer local. Se a recuperação for rápida, o transporte pode evitar uma retransmissão mais longa pelo caminho completo.

O valor potencial aumenta com velocidades de pista e densidade de portas mais altas. Erros ópticos ou elétricos esporádicos podem causar atrasos significativos em uma tarefa fortemente síncrona. Mas o LLR adiciona estado de sequência, buffers de replay, mensagens de controle, janelas de descarte e novos modos de falha. Além disso, precisa coexistir com atualizações de créditos e reconfigurações de enlace. A versão 1.0.3 corrigiu várias situações de borda, incluindo uma condição de corrida entre informações de crédito do CBFC e o LLR.

O Credit-Based Flow Control (CBFC) opera por canal virtual no nível de enlace. Informa ao remetente quanto da capacidade do receptor ainda está disponível, podendo oferecer controle mais fino do que uma pausa genérica baseada em prioridade. A UEC o apresenta como um meio de suportar comportamento sem perdas controlado, sem exigir que toda a rede UET seja completamente livre de perdas. O CBFC é opcional, e o UET foi projetado para funcionar sobre redes de melhor esforço.

O CBFC não deve ser tratado como outro nome para Priority Flow Control. Os dois mecanismos diferem em sinalização e granularidade, embora ambos busquem evitar overflow. O CBFC ainda requer configuração consistente e entrega correta de seus próprios quadros de controle. Os créditos locais podem interagir com janelas de ponta a ponta e créditos do receptor, produzindo múltiplos ciclos de controle aninhados.

A UEC usa uma negociação baseada em LLDP para descobrir recursos opcionais e evitar que um lado ative uma capacidade que o vizinho não suporta. A negociação deve considerar perfis, canais virtuais, DSCP, alinhamento de prioridades, reinicializações, atualizações de software e combinações parciais de recursos. A versão 1.0.3 introduziu a capacidade de negociação lógica, reforçando a importância de um acordo explícito em cada enlace.

Essas opções oferecem um caminho do Ethernet básico ao Ethernet aprimorado. Mas também criam uma matriz que a linguagem de aquisições pode esconder. Um switch pode encaminhar UET corretamente sem trimming, LLR ou CBFC. Outro switch pode oferecer suporte a essas capacidades apenas em versões de software ou modos de porta específicos. Um registro confiável de implantação exige o conjunto exato de recursos, não apenas o nome do consórcio.

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

A camada física conecta a UEC ao roteiro de hardware. O trabalho inicial da versão 1.0 foi projetado em torno de sinalização de 100 Gbps por pista. A 1.0.3 introduziu suporte a 200 Gbps por pista. Isso está alinhado com uma geração de densidade mais alta de enlaces e sistemas, mas é uma capacidade na especificação, não uma evidência de que todo produto UEC já a suporta de imediato.

O trabalho da PHY também aborda estatísticas de forward error correction, proporções de codewords corrigidos e incorrigíveis, control ordered sets, relatórios de qualidade do enlace e a interação entre erros físicos e LLR. Esses detalhes são importantes porque as decisões de recuperação no transporte dependem do que as camadas inferiores conseguem ver e reportar.

Em velocidades de sinalização mais altas, as fronteiras entre óptica, SerDes, FEC, retransmissão no enlace e recuperação no transporte passam a ter impacto econômico. Um FEC mais forte pode reduzir os erros residuais ao custo de latência e energia. A retransmissão local pode recuperar erros mais rápido, mas exige buffers e estado. Já a retransmissão de ponta a ponta é mais simples na rede, mas pode desperdiçar mais tempo. A UEC tenta especificar como essas camadas cooperam, em vez de deixar cada fornecedor otimizá-las isoladamente.

A adição de 200G por pista também mostra que o alvo é móvel. Implementadores da 1.0 precisam manter compatibilidade enquanto planejam novas capacidades físicas. Equipamentos de teste, firmware e sistemas de gerenciamento devem distinguir as capacidades de cada porta. Os compradores não devem inferir a velocidade da pista a partir de uma alegação genérica de suporte à UEC.

Segurança de transporte opcional de ponta a ponta

A Subcamada de Segurança de Transporte (TSS) oferece proteção opcional de ponta a ponta. O modelo de ameaça não exige confiança nos switches. Ela pode fornecer confidencialidade, integridade, proteção contra replay, isolamento de tarefas, domínios seguros, chaves de grupo, rotação de chaves e integração com raízes de confiança em hardware.

O design usa domínios seguros cujos membros compartilham um contexto criptográfico. Identificadores, números de ligação, epochs, identidade de fonte segura e derivação de chaves são projetados para escalar melhor do que criar uma sessão independente para cada par de endpoints. Isso é essencial quando o conjunto de aceleradores e a composição das tarefas mudam rapidamente.

O protocolo é apenas uma parte do sistema de segurança. Um operador de produção precisa executar autoridades de chaves e certificados ou outras raízes de confiança, serviços de associação de tarefas, distribuição e revogação, transições de epochs, recuperação de endpoints, criptografia em hardware e telemetria de segurança. Uma rede pode corresponder a um perfil sem ativar todas as funções opcionais do TSS. “Compatível com UEC” não significa automaticamente que o tráfego esteja criptografado.

A opcionalidade reflete diferentes premissas de implantação. Uma malha dedicada e fisicamente controlada pode priorizar o desempenho e confiar nos controles do ambiente. Uma nuvem multi-inquilino pode precisar de isolamento forte e proteção criptográfica. O sistema de perfis e as aquisições precisam evidenciar essa diferença.

O maior risco não é apenas o custo da criptografia, mas a falha no ciclo de vida em grande escala: associações obsoletas, revogações atrasadas, epochs inconsistentes, recuperação após falha de endpoint ou a incapacidade de comprovar qual tarefa pode acessar qual memória. Esses problemas conectam a segurança de transporte a sistemas de orquestração e identidade que estão fora da especificação principal.

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 programa de certificação independente maduro. O pacote disponível foi projetado principalmente para autodeclaração dos implementadores. As matrizes vinculam os requisitos da especificação aos perfis, e as diretrizes de testbed descrevem configurações recomendadas para endpoints e switches. Não foi encontrada uma base pública abrangente onde uma entidade independente registre produtos que passaram ou falharam em um programa completo da UEC.

A distinção é necessária porque diferentes alegações circulam no mercado. Um produto pode ter sido projetado em torno de funcionalidades UEC ainda em desenvolvimento, implementar funcionalidades selecionadas em rede, ou suportar um perfil ou partes dele em uma versão de software específica. Um fornecedor pode reivindicar conformidade total de funcionalidades, ou um laboratório pode gerar tráfego UET através de um switch. Nenhum desses casos equivale automaticamente a uma certificação independente de ponta a ponta com múltiplos fornecedores.

As diretrizes públicas de testbed são úteis, mas intencionalmente limitadas. Elas oferecem topologias e verificações de boas práticas, não uma qualificação completa do sistema. Não cobrem totalmente a interoperabilidade mais ampla, desempenho, estresse, escala, ciclo de vida da API. Também não comprovam o comportamento ao misturar UET e RoCE, em atualizações parciais, falhas repetidas, domínios de chave grandes ou nos maiores números de endpoints previstos.

A divergência entre AI Full e AI Extended comprova a necessidade de um controle de versão rigoroso. O comprador deve perguntar sobre a especificação, o nível de patch, o perfil, os recursos opcionais, os modos de enlace e as funcionalidades de segurança cobertas pela alegação. A resposta deve especificar se a evidência vem de teste interno, demonstração bilateral, evento do consórcio ou laboratório independente.

O próximo estágio confiável inclui definições de teste públicas vinculadas a versões exatas, plugfests com múltiplos fornecedores, resultados gerenciados por terceiros independentes – inclusive resultados negativos – e um registro que diferencie endpoints, switches, software e sistemas completos. Até que isso aconteça, a expressão “compatível com UEC” permanece um ponto de partida para verificação, não uma garantia completa.

Documento aberto com compromissos de patentes RAND

A Ultra Ethernet Specification 1.0.3 está disponível publicamente e é distribuída sob a licença Creative Commons Attribution-NoDerivatives 4.0. A licença permite a redistribuição com atribuição, mas não permite a distribuição de versões modificadas. Mais importante, o direito de acesso via copyright é separado do direito de uso das patentes.

Os estatutos documentados dos grupos de trabalho geralmente usam um modelo tradicional de desenvolvimento de especificações com licenciamento de patentes em termos razoáveis e não discriminatórios (RAND). RAND não significa necessariamente isento de royalties, não garante um preço universal, não elimina negociações e não impede disputas sobre validade, essencialidade, abrangência geográfica ou termos defensivos. O cenário comercial depende de cada patente declarada, do compromisso do membro e de quaisquer acordos bilaterais.

A UEC mantém um registro público de declarações de Necessary Claims. No momento da pesquisa, havia declarações associadas à Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell e outras, incluindo submissões relacionadas a trabalhos futuros da versão 1.1. O registro melhora a transparência, pois indica que os implementadores podem precisar examinar a propriedade intelectual antes de construir ou enviar um produto.

O consórcio declara que 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 conjunta. Implementadores menores podem enfrentar custos legais e transacionais que grandes empresas absorvem com mais facilidade. Uma especificação pública pode resultar em um mercado de implementação concentrado se o custo de liberação de patentes, silício e testes for alto.

O arcabouço de propriedade intelectual também afeta 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 sejam representadas no design conjunto. As declarações de patentes só protegem os implementadores de surpresas se forem feitas com antecedência e clareza suficientes. Elas não eliminam a possibilidade de o licenciamento se tornar uma barreira depois que a adoção se ampliar.

Portanto, a descrição honesta é “publicada publicamente, com múltiplos fornecedores e compromissos RAND”, e não “universalmente isenta de royalties”. As equipes de compras precisam tanto do perfil técnico quanto do caminho de licenciamento.

A primeira onda de produtos e testes

As evidências de implementação começaram a surgir por volta da versão 1.0, mas os exemplos estão em diferentes graus de maturidade.

A AMD disponibilizou comercialmente a NIC Pollara 400 AI em abril de 2025, descrevendo-a como projetada em torno das capacidades da UEC em evolução. A Pollara é uma plataforma de endpoint programável e um sinal importante da migração do transporte para hardware efetivamente embarcado. Mas a formulação é importante: o design em torno de funcionalidades em desenvolvimento não equivale a uma certificação independente contra todos os requisitos finais da versão 1.0.3.

A Broadcom anunciou em junho de 2025 o Tomahawk 6 como um ASIC de comutação de 102,4 Tbps com recursos relevantes para malhas UEC. Em outubro, anunciou a NIC Thor Ultra 800G e afirmou que o design oferece conformidade total de funcionalidades UEC. É uma alegação significativa do fornecedor, mas a evidência pública não a transforma em uma certificação independente do consórcio. Amostragem, maturidade do software e suporte exato aos perfis devem ser considerados separadamente.

A Nokia e a Keysight anunciaram em outubro de 2025 uma demonstração de tráfego UET de ponta a ponta através das famílias de switches de data center Nokia 7220 e 7250 em 800 Gigabit Ethernet. A Keysight forneceu a geração de tráfego e a verificação. O teste comprova que o tráfego UET pode atravessar sistemas de comutação comerciais e que o suporte a equipamentos de teste está evoluindo. Mas não comprova um perfil de endpoint completo com múltiplos fornecedores, volume de produção ou certificação independente para todos os recursos opcionais.

Outros membros descreveram switches, sistemas, software e planos de teste capazes de UEC, e a Cúpula de 2026 focou fortemente em productisation. As evidências respaldam uma transição para a implementação, mas não comprovam um número preciso de NICs UET enviadas, switches certificados, regiões de nuvem operacionais ou malhas completas.

A melhor leitura da onda é uma cadeia de evidências. A especificação pública permite o design. Os anúncios de silício e NICs demonstram investimento. As demonstrações de tráfego mostram alguma interoperabilidade. As matrizes de conformidade organizam os requisitos. Relatórios de operadores exibirão o valor operacional. Já os plugfests independentes e os resultados de produção fornecerão a confiança mais ampla que ainda falta.

RoCE, InfiniBand, Slingshot e UALink

A UEC entra em um mercado com alternativas maduras e tecnologias adjacentes. Sua proposta estratégica não se baseia em que o Ethernet nunca transportou RDMA antes ou que as malhas especializadas não funcionam, mas em que a escala e o sincronismo das cargas de trabalho de IA atuais justificam uma nova arquitetura Ethernet de ponta a ponta, mais flexível na entrega, no uso de caminhos e no controle de congestionamento.

O RoCEv2 é o predecessor direto e uma tecnologia amplamente difundida. Transporta tráfego RDMA sobre Ethernet roteável e tem amplo suporte em aplicações e produtos. A UEC critica as implementações comuns de RoCE por fixarem o fluxo inteiro em um único caminho, usarem Go-Back-N e reordenação no receptor, exigirem ajuste difícil do DCQCN, dependerem de Priority Flow Control em muitos designs e exibirem comportamento ruim sob incast ou rajadas coletivas. Essas são posições técnicas do consórcio, não evidência de que toda rede RoCE é deficiente.

A comparação também é móvel. Os fornecedores podem adicionar roteamento adaptativo, packet spraying, melhores algoritmos de congestionamento ou funcionalidades semelhantes às da UEC em NICs programáveis, mantendo a compatibilidade com RoCE. Por exemplo, a AMD, nas comunicações da Pollara, exibe tanto RoCEv2 quanto UEC RDMA como opções em hardware programável. A UEC pode competir com o RoCE como um transporte completo e, ao mesmo tempo, influenciar a evolução dos futuros produtos RoCE.

O InfiniBand é a alternativa especializada mais importante. Oferece um ecossistema integrado para 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 para XDR a 200 Gbps por pista e telemetria atualizada. O principal diferencial da UEC não é afirmar que o InfiniBand carece de desempenho, mas a possibilidade de obter comportamento de IA/HPC através da cadeia de suprimentos Ethernet mais ampla, com roteamento IP padrão e maior opção entre fornecedores.

O HPE Slingshot ocupa uma posição intermediária. É uma malha HPC comercial compatível com Ethernet, com roteamento adaptativo e gerenciamento de congestionamento, e forneceu precedentes técnicos importantes para o UET. Demonstra que o comportamento especializado pode ser construído sobre Ethernet, mas também ilustra a diferença entre uma plataforma comercial controlada e uma especificação em nível de indústria.

O UALink é muitas vezes complementar, não um substituto direto. Sua especificação pública atual de 200G visa a conectividade scale-up de baixa latência entre aceleradores dentro de um pod, descrevendo sistemas de até 1.024 aceleradores. Já a UEC 1.0 é essencialmente uma malha scale-out que conecta nós através de switches. Um data center pode usar um enlace scale-up dentro do pod e UEC entre pods ou nós. Os trabalhos futuros da UEC em transporte scale-up e operações coletivas dentro da rede podem aproximar as fronteiras e gerar convergência ou competição.

O NVIDIA Spectrum-X e as malhas proprietárias de aceleradores oferecem 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 substitui parte dessa integração pela promessa de interfaces comuns e opção de fornecedor. O sucesso dessa troca depende de desempenho, suporte, termos de patentes, interoperabilidade e custo operacional total, não da palavra “aberto” como mero slogan.

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 tarefas importantes de gerenciamento fora do documento normativo principal ou em torno dele. Os operadores precisam configurar perfis, classes de tráfego, limiares de ECN, conjuntos de entropia, recursos opcionais de enlace, chaves, firmware, telemetria e política de falhas de forma consistente entre endpoints e switches.

O tráfego misto torna a situação 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 questão do mapeamento de filas e da justiça entre eles não se resolve apenas com a implementação correta de cada protocolo. Um algoritmo de congestionamento pode funcionar bem isoladamente e depois se comportar mal ao competir com outro controlador que utiliza sinais e premissas diferentes.

A complexidade do endpoint é outro risco estrutural. O UET coloca múltiplos caminhos, posicionamento direto, retransmissão seletiva, múltiplos modos de entrega, controle de janela, créditos, recepção de trimming, segurança e estado pesado dentro do FEP. Isso pode aumentar a área do die da NIC, o tamanho do firmware, o esforço de verificação, o consumo de energia e o número de modos de falha a serem diagnosticados. A inteligência no endpoint viabiliza uma cadeia de suprimentos ampla, mas pode colocar a implementação mais difícil no componente que todo servidor precisa adquirir.

Os recursos opcionais geram diferenciação de produto e, ao mesmo tempo, fragmentação. Um fornecedor pode otimizar um endpoint básico para AI Base com ECMP e ECN comuns. Outro pode oferecer suporte a AI Full, HPC, TSS, trimming, LLR e CBFC. Ambos estão no ecossistema UEC, mas os operadores não podem presumir a mesma semântica, desempenho ou segurança. As matrizes de conformidade precisam se transformar em matrizes operacionais de capacidades.

A manutenção de versões será contínua. Os patches de 1.0.1 a 1.0.3 afetaram congestionamento, créditos, retransmissão e comportamento de pacotes. Um grande cluster pode conter diferentes versões de firmware de NIC, várias versões de switches e ferramentas de teste. Atualizar uma camada sem coordenar as demais pode expor exatamente a interação entre camadas que o consórcio busca evitar.

Por isso, as relações externas são centrais, não simbólicas. O Open Compute Project pode conectar o transporte a sistemas e hardware aberto. A OpenFabrics Alliance e a comunidade libfabric conectam as aplicações. O IEEE 802.3 fornece o trabalho formal do Ethernet. A SNIA e a NVM Express acrescentam requisitos de armazenamento e gerenciamento. Os mecanismos da IETF fornecem IP, ECN e tecnologias correlatas. Esses órgãos têm processos de decisão e roteiros diferentes; a coordenação reduz a duplicação, mas não garante adoção sincronizada.

O teste operacional definitivo é a infraestrutura em funcionamento. Um documento pode especificar o comportamento, um fornecedor pode anunciar um produto e o consórcio pode organizar uma cúpula. Nada disso substitui um cluster onde endpoints e switches independentes realizam tarefas reais sob congestionamento, falha e atualização, e os operadores conseguem interpretar o que aconteceu.

Importância atual: do sucesso da especificação à credibilidade da implementação

Até julho de 2026, a UEC havia alcançado coisas que não estavam garantidas no lançamento. Construiu um consórcio amplo, elaborou uma arquitetura integrada de cinco camadas, publicou uma especificação 1.0 completa, manteve-a por meio de versões de patch, adicionou 200G por pista, divulgou declarações de patentes e atraiu anúncios de produtos e testes. O projeto está ativo, e sua pauta claramente migrou para a implementação.

O progresso torna as dúvidas seguintes mais importantes, não menos. O número atual exato de membros e a composição do Steering não aparecem em um único registro de referência. As páginas públicas de associação e o documento organizacional descrevem o acesso de maneiras diferentes. A liderança oficial atual do TAC não corresponde totalmente às funções da cúpula. Documentos oficiais divergem sobre a data da versão 1.0.2, e o pacote de conformidade usa terminologia de perfil desatualizada. Nada disso destrói a arquitetura, mas é um indicador de disciplina documental e transparência em um projeto onde os resultados dependem de versões precisas.

As lacunas mais importantes dizem respeito à adoção. A UEC não publica estatísticas de implantação, nem um registro de produtos verificados por terceiros, nem orçamentos independentes ou contas auditadas. Não há evidência pública de uma rede UEC 1.0 totalmente interoperável nos volumes máximos visados pelo consórcio. Demonstrações e alegações de fornecedores são valiosas, mas vêm de partes com interesse comercial. Comparações neutras com o RoCE atual, InfiniBand e plataformas Ethernet integradas ainda são limitadas.

A oportunidade permanece grande. O Ethernet é o denominador comum nos 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 reduzir a dependência de um único fornecedor e melhorar a utilização dos aceleradores. Uma pilha comum pode transformar esses incentivos em poder de compra.

O risco é que “Ultra Ethernet” se torne um guarda-chuva para conjuntos de recursos incompatíveis. Se o roteamento 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 rol de fornecedores pode se estreitar. Se os produtos RoCE absorverem as ideias mais atraentes sem um novo transporte, a UEC pode influenciar o mercado sem se tornar o nome dominante.

A questão decisiva já não é se o consórcio consegue publicar uma especificação avançada. Ele conseguiu. A questão é se organizações independentes conseguem implementar os mesmos contratos, licenciar a tecnologia necessária, operar a malha em grande escala e manter a compatibilidade conforme a especificação evolui. A UEC só se transformará em infraestrutura na medida em que essas alegações resistirem ao teste dos sistemas em operação.