Resumo

  • 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 industrial para desenvolvimento de especificações, não uma empresa comum nem um operador de rede.
  • O escopo da UEC vai muito além de 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 trabalhos sobre gerenciamento, armazenamento, testes e conformidade.
  • O Ultra Ethernet Transport combina vários modos de entrega, múltiplos caminhos em nível de pacote, retransmissão seletiva, controle de congestionamento orientado pelo remetente e pelo destinatário, ECN, packet trimming opcional, repetição de enlace local 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 já começou. No entanto, a conformidade pública baseia-se principalmente em autodeclarações dos implementadores; não foi publicado um registro abrangente e independente de certificação nem um levantamento de implantações em larga escala.
  • A oportunidade estratégica da UEC reside na base instalada de Ethernet e na cadeia de suprimentos com múltiplos fornecedores. Os maiores riscos são a complexidade dos endpoints, a fragmentação por funcionalidades opcionais, as obrigações de patentes RAND, a gestão e os testes ainda imaturos, além da lacuna entre uma especificação publicada e a interoperabilidade comprovada em produção.

Por que a IA transformou a rede em parte do computador

O Ultra Ethernet Consortium surgiu de uma mudança na economia da computação. Em uma rede corporativa comum, o fabric deve transportar muitos fluxos de dados independentes com throughput e disponibilidade aceitáveis. Já em um grande sistema de treinamento de IA ou em uma máquina de computação de alto desempenho, a rede torna-se parte de uma única 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 tenha recebido as informações necessárias.

Mesmo um pequeno desequilíbrio entre caminhos, um evento de congestionamento ou uma perda de pacote pode, portanto, fazer processadores caros esperarem, ainda que a utilização média do fabric pareça saudável.

Com isso, mudam-se os objetivos de otimização dos operadores. A largura de banda agregada continua importante, mas não é suficiente. Igualmente relevantes são o tempo de conclusão do job, a tail latency, o incast, a recuperação de perdas, a distribuição do tráfego por caminhos paralelos e a quantidade de estado que os endpoints precisam manter. Uma rede que entrega quase todos os pacotes rapidamente, mas atrasa uma pequena parte, pode travar toda uma operação coletiva. Um procedimento de retransmissão aceitável para tráfego comum pode perder tempo demais quando em uma mensagem longa falta apenas um pacote.

Um fluxo vinculado a um único caminho de igual custo pode ter desempenho abaixo do esperado, mesmo que haja capacidade ociosa em outro ponto da topologia.

A tese fundadora da UEC era que esses problemas não se resolvem com uma única funcionalidade nova no switch ou com 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 de forma independente, uma otimização em um ponto pode apenas deslocar o gargalo ou criar premissas incompatíveis em outro lugar.

A resposta da UEC é uma arquitetura coordenada. Ela mantém Ethernet e IP, porque os operadores conhecem essas tecnologias e porque se formou uma enorme cadeia de suprimentos em torno de switches, óptica, cabos, sistemas operacionais de rede, telemetria e gerenciamento. Ao mesmo tempo, ela altera ou expande as áreas que o consórcio considera insuficientes para grandes cargas de trabalho de IA e HPC. O resultado não é "Ethernet comum com um logo novo". É a tentativa de fazer uma rede familiar transportar um transporte especializado, cujo comportamento é definido desde a API de software até a taxa por lane.

Essa distinção explica a importância da UEC para a infraestrutura digital. O projeto não possui aceleradores, fábricas, data centers ou regiões de nuvem. Ele define contratos que empresas-membro e outros implementadores podem incorporar em NICs, ASICs de switch, sistemas, drivers, bibliotecas e equipamentos de teste. A influência só surge quando esses produtos independentes trocam dados corretamente sob falhas, congestionamento, upgrades e combinações de 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 jurídica se chama Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. A estrutura de série vincula o projeto à Joint Development Foundation e à família mais ampla da Linux Foundation. Ela oferece um arcabouço jurídico existente para associação, governança, propriedade intelectual, financiamento e relações externas, sem que os participantes precisem criar uma nova empresa independente.

Essa estrutura é importante porque a UEC é muitas vezes descrita de forma imprecisa como empresa, aliança ou organização de padronização. Ela não é uma empresa comercial com acionistas, capital próprio, avaliação ou demonstrações financeiras separadas. Não vende produtos Ethernet, não opera uma rede pública e não detém o hardware que seus membros promovem. É um consórcio de desenvolvimento de especificações com um arcabouço jurídico e de propriedade intelectual. Seus documentos públicos devem se tornar contratos de implementação entre várias empresas.

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

A UEC também não é o grupo de trabalho IEEE 802.3. O IEEE 802.3 desenvolve padrões básicos de MAC e PHY Ethernet em um processo formal próprio. A UEC se apoia nesse ecossistema e mantém uma ligação, mas não o substitui. A mesma fronteira se aplica aos mecanismos IETF abaixo do UET, incluindo IPv4, IPv6 e Explicit Congestion Notification; ao ecossistema OpenFabrics, que mantém o libfabric; e às organizações que trabalham com armazenamento, hardware aberto e interconexões de aceleradores.

O site do projeto usou formulações que sugerem o status de uma organização internacional de padronização. A descrição mais segura e mais bem documentada é: a UEC é uma organização internacional de desenvolvimento de especificações sob o arcabouço JDF. Não há evidência de que a UEC faça parte da International Organization for Standardization, que seus documentos sejam normas ISO ou que ela tenha um número de norma ISO. A diferença é mais do que linguística. Ela mostra de onde vem a autoridade, como funciona a participação e a quais obrigações legais os implementadores podem estar sujeitos.

Portanto, a UEC deve ser julgada por sua função real. Ela coordena concorrentes e operadores em torno de um projeto técnico comum, publica especificações, gerencia grupos de trabalho e obrigações patentárias declaradas, desenvolve documentação de conformidade e relacionamentos com organizações vizinhas. Sozinha, a declaração não pode tornar um produto interoperável nem 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 situadas em diferentes pontos da cadeia de suprimentos de IA e HPC: AMD, Arista Networks, Broadcom, Cisco, Eviden — então vinculada à Atos —, Hewlett Packard Enterprise, Intel, Meta e Microsoft. Essa amplitude foi uma vantagem estratégica desde o início. Um transporte desenvolvido apenas por fornecedores de switches poderia ignorar as fronteiras de aplicação e endpoint. Um projeto liderado apenas por fabricantes de aceleradores poderia se otimizar excessivamente em torno de um único ecossistema de hardware.

Um projeto puramente de nuvem poderia não contar com a competência em silício, óptica e sistemas necessária para transformar arquitetura em produtos.

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

A coalizão contém, ao mesmo tempo, 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 uma implementação. Alguns se beneficiam de um padrão amplo de múltiplos fornecedores, ao mesmo tempo em que podem lucrar com funcionalidades proprietárias diferenciadas. O consórcio, portanto, não elimina a concorrência. Ele cria um fórum onde concorrentes concordam com interfaces mínimas e continuam a competir em qualidade de implementação, desempenho, integração e condições comerciais.

A interconexão Slingshot da HPE é um exemplo útil de herança técnica. O Slingshot é um fabric HPC comercial compatível com Ethernet, com roteamento adaptativo e gerenciamento de congestionamento. Comentários próximos à HPE afirmaram que uma especificação "HPC Ethernet" foi contribuída para a UEC e estimaram que uma grande parte do UET vem de ideias de transporte do Slingshot. O percentual exato não foi verificado de forma independente e não deve ser tratado como uma conta do consórcio.

O ponto mais amplo está bem documentado: a UEC não começou de uma folha em branco, mas se baseou na experiência de produção em HPC, redes de nuvem, RDMA e Ethernet.

Essa mistura de sistemas legados é uma razão para usar a palavra "aberto" com precisão. A especificação ratificada da UEC está disponível publicamente para download. A arquitetura é destinada a implementações de vários fornecedores. No entanto, o projeto também é um local onde os membros contribuem com conhecimento existente, patentes e roadmaps de produtos. A abertura do documento não elimina as condições econômicas ou jurídicas da tecnologia.

Uma série jurídica para a cooperação entre concorrentes

O modelo da Joint Development Foundation dá à UEC uma estrutura formal sem transformá-la em uma empresa operacional comum. O projeto possui nome, escopo, classes de membros, Steering Committee, grupos de trabalho e obrigações de propriedade intelectual próprios. O guarda-chuva da JDF fornece infraestrutura corporativa e sem fins lucrativos, podendo deter ativos e contratos do projeto. Isso reduz os custos de formação do consórcio e oferece aos concorrentes um procedimento reconhecido para cooperação.

O Steering Committee conduz o projeto. Entre as funções documentadas estão a coordenação dos grupos de trabalho, a admissão de membros, a gestão de ativos e finanças, a seleção ou destituição da presidência, o acompanhamento do progresso e o controle de publicações e marcas do projeto. O consenso é preferido. Quando não é alcançado, a carta prevê um mecanismo de supermaioria de três quartos entre os membros elegíveis que cumprirem os requisitos de presença. Reclamações formais podem ser encaminhadas ao presidente.

O presidente original era Brad Booth, da Meta. A especificação 1.0.3 atual lista 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 TAC Vice Chair. Paul Congdon é listado como Editor da especificação. O documento também lista líderes e autores nos trabalhos de camada física, enlace, transporte e software. A agenda da Cúpula de 2026 apresenta outros responsáveis operacionais. Esses papéis não substituem necessariamente os títulos formais da especificação; um organograma atualizado completo não está disponível publicamente.

A carta reconhece três classes de membros: Steering, General e Contributor. Os membros Steering participam da governança e geralmente nomeiam representantes para o Steering Committee. Os membros General podem trabalhar em todos os grupos técnicos, mas não têm assento no Steering Committee. Os membros Contributor participam de grupos selecionados e não têm direito a voto em decisões por supermaioria. A página pública atual de membros comercializa os níveis General e Contributor com taxas anuais de projeto de US$ 20.000 e US$ 5.000, respectivamente, além da associação à Linux Foundation.

Ela não esclarece com precisão o caminho de admissão ou o preço atual para o status Steering.

As diferenças de poder formal são relevantes. Uma ampla adesão pode trazer expertise e alcance de implementação, mas a governança não é distribuída igualmente. Grandes empresas que ocupam posições no Steering, alocam engenheiros em muitos grupos e mantêm programas de patentes e produtos têm mais influência prática do que membros Contributor menores. Não membros podem baixar a especificação final, mas não veem o processo de elaboração completo e não participam em condições iguais.

As informações internas do projeto não são tratadas como dados corporativos confidenciais comuns, mas os membros não podem divulgar material preliminar antes que o comitê competente autorize a publicação. Isso facilita conversas entre concorrentes sobre ideias inacabadas, sem sinais prematuros ao mercado. Ao mesmo tempo, agentes externos não conseguem ver propostas rejeitadas, atas de votação, preocupações intermediárias de implementação ou as negociações por trás das funcionalidades opcionais. A versão final é aberta; o caminho até ela é apenas parcialmente visível.

De quatro grupos de trabalho para 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 Camada Física. A ordem refletia a pretensão ponta a ponta. A associação não foi aberta de imediato 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 etapas, com orientação sobre processo e legislação antitruste. Essa cautela era compreensível, porque os participantes concorrem diretamente em vários mercados e discutiriam requisitos comuns de produtos e protocolos.

Em dezembro de 2023, a UEC reportou cerca de 40 empresas e mais de 300 pessoas. Havia criado um Technical Advisory Committee (Comitê Técnico Consultivo) e se expandido para oito grupos de trabalho. A tarefa do TAC era a coerência arquitetônica: um projeto de transporte não podia pressupor comportamento de switch, procedimento de sinalização ou API que outro grupo não tivesse acordado em suportar. Em março de 2024, o consórcio informou 55 empresas e mais de 750 participantes ativos e publicou uma descrição muito mais clara da arquitetura planejada.

A atualização de março introduziu as ideias que mais tarde apareceriam na especificação normativa: libfabric como API do lado do software, packet spraying, ordenação flexível, vários modos de entrega, controle de congestionamento orientado pelo remetente e pelo destinatário, ECN, packet trimming, Link Layer Retry, controle de fluxo opcional baseado em crédito, segurança de transporte e futuras operações coletivas na rede. Também enfatizou que o UET poderia rodar sobre switches Ethernet existentes, enquanto switches avançados poderiam oferecer desempenho adicional.

O alcance institucional cresceu junto com o trabalho técnico. A UEC reportou 1.193 participantes ativos em julho de 2024 e 97 organizações-membro em agosto. Esses são números datados do consórcio, baseados em definições não totalmente públicas. Não devem ser mecanicamente somados a informações posteriores. Em 2025, a UEC declarou que mais 27 empresas haviam ingressado; no entanto, saídas, fusões e períodos de reporte sobrepostos impedem uma soma atual exata. O próprio site indica que nem todos os membros são exibidos.

O consórcio publicou a Ultra Ethernet Specification 1.0 em 11 de junho de 2025. Com isso, a UEC passou de um roadmap para uma base de implementação pública. A versão 1.0.1 veio em setembro, corrigindo o algoritmo de origem do controle de crédito baseado no receptor e pontos editoriais. A versão 1.0.2 saiu em janeiro de 2026, corrigindo algoritmos de gerenciamento de congestionamento, embora documentos oficiais divirjam sobre se a data de publicação foi 21 ou 28 de janeiro. A inconsistência deve permanecer visível e não ser resolvida silenciosamente.

A versão 1.0.3, publicada em 16 de julho de 2026, é a referência atual na data desta pesquisa. Ela tem 573 páginas e adiciona suporte para sinalização de 200 Gb/s por lane, além de uma capacidade de negociação booleana. As notas de liberação também mencionam correções necessárias na entrega de pacotes, congestion credits, Link Layer Retry e Control Ordered Sets da camada física, bem como esclarecimentos sobre segurança de transporte, operações atômicas e pacotes trimmed.

A diferença entre correções obrigatórias e esclarecimentos editoriais é importante: algumas alterações afetam o comportamento conforme e, portanto, a manutenção das implementações.

A Cúpula de Membros de 2026 em Denver mostrou uma segunda transição. A agenda concentrou-se em implantação, produtização, conformidade, gerenciamento, desempenho, depuração, integração de armazenamento e testes de switch e endpoint. O documento central de arquitetura existe; a credibilidade do projeto agora depende cada vez mais de os implementadores conseguirem 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 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 coletivas interagem por meio das OpenFabrics Interfaces, especialmente o libfabric. O UET Semantic Services Sublayer traduz as operações da aplicação em transações de transporte. O Packet Delivery Sublayer decide como as mensagens são empacotadas, ordenadas, confirmadas e recuperadas. O Congestion Management controla quantos dados entram no fabric e como o tráfego é distribuído pelos caminhos. A segurança de transporte opcional protege o tráfego ponta a ponta. O IPv4 ou IPv6 padrão cuida do encaminhamento na camada de rede.

O Ethernet fornece o enlace com packet trimming opcional, Link Layer Retry, Credit-Based Flow Control e negociação de funcionalidades. A camada física define requisitos de estatísticas e sinalização a 100 ou 200 Gb/s por lane.

Essa estrutura preserva partes importantes da rede existente. A UEC não define um substituto para o roteamento IP. Espera-se o uso de Equal-Cost Multipath comum e switches com capacidade ECN. Grande parte da inteligência permanece nos endpoints do fabric, que manipulam a entropia, rastreiam o estado do transporte, posicionam os dados e reagem aos sinais de congestionamento. Switches avançados podem acrescentar funcionalidades, mas o design não exige que cada instalação substitua todo o seu fabric antes que o tráfego UET possa passar.

Isso cria uma vantagem de migração e um problema de classificação. Uma instalação pode usar endpoints UET sobre Ethernet convencional com ECMP e ECN. Outra pode adicionar trimming, Link Retry, créditos por canal virtual, telemetria mais rica e, mais tarde, funcionalidades na rede. Ambas podem ser chamadas de “Ultra Ethernet”, embora o desempenho, a recuperação e a complexidade operacional sejam muito diferentes.

A abordagem em cinco camadas também dificulta a localização de falhas. Um mau resultado pode vir do mapeamento da aplicação, da máquina de estados do endpoint, dos parâmetros de congestionamento, da configuração das filas do switch, do mapeamento DSCP, da óptica, do firmware ou do sistema de segurança. Encaminhar 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 API de aplicação proprietária

A UEC escolheu o libfabric 2.0 como a API northbound fundamental para endpoints conformes. Essa decisão conecta o projeto a um ecossistema existente de HPC e redes avançadas, em vez de forçar cada framework a adotar uma nova interface proprietária. O libfabric já descreve fabrics, domínios, endpoints, completion queues, event queues, address vectors, memory regions, mensagens, operações de memória remota e atômicas. A UEC mapeia e limita esses conceitos para que os provedores possam traduzir as chamadas em comportamento UET.

O valor estratégico está na continuidade acima do transporte. MPI, SHMEM e bibliotecas de comunicação de aceleradores podem usar abstrações familiares enquanto o provedor subjacente muda. Em princípio, uma aplicação pode solicitar uma operação sem saber qual provedor fornece a NIC para a entrega de pacotes ou qual silício de switch encaminha os pacotes. Esse é um mecanismo central pelo qual um transporte comum poderia permitir a escolha de fornecedores.

A abstração não garante implementações equivalentes. Os provedores podem diferir em tamanho de inject, limites de scatter/gather, número de endpoints, operações atômicas, registro de memória, comportamento de completion, offload de hardware e funcionalidades de segurança. Uma biblioteca compilada contra a mesma API pode, portanto, encontrar limites diferentes de desempenho ou capacidade. A aquisição e a qualificação de software exigem mais do que uma marca ao lado de “suporta libfabric”.

A camada de software da UEC também carrega a semântica de jobs e autorização. Sistemas de IA e HPC frequentemente executam muitos jobs em infraestrutura compartilhada, cada um com seus próprios processos, regiões de memória e fronteiras de segurança. A especificação precisa determinar qual endpoint pertence a qual job, quais buffers podem ser acessados, como as operações remotas são mapeadas e como as informações de conclusão ou erro retornam ao software. Essas decisões determinam se uma rede rápida é utilizável por schedulers, runtimes e aplicações ou se impressiona apenas em um benchmark de pacotes.

O projeto é dependente do ecossistema OpenFabrics, porque não detém o libfabric. Essa relação ilustra uma característica mais ampla da UEC: a arquitetura é composta por componentes controlados em lugares diferentes. A UEC pode definir como seu transporte é mapeado para o libfabric, mas precisa se alinhar com os mantenedores e usuários da API. Dependências semelhantes existem com o Ethernet do IEEE, as redes do IETF, organizações de armazenamento e 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 do sistema operacional a um ou mais planos de fabric isolados e pode incluir um provedor de user space, driver de kernel, transporte no lado da NIC ou do acelerador, registro de memória, contexto de segurança, completion queues, address vectors e estado para entrega de pacotes e controle de congestionamento.

Esse design centrado no endpoint deixa a maioria dos switches reconhecíveis como dispositivos Ethernet e IP. O FEP escolhe valores de entropia, mantém estado de pacotes e congestionamento, posiciona dados na memória autorizada e interpreta confirmações, trimming e outros feedbacks. Com isso, a dependência de inteligência de roteamento proprietário no switch pode diminuir. Ao mesmo tempo, a complexidade se concentra no silício, firmware, drivers e software da NIC.

A UEC define três perfis de implementação: AI Base, AI Full e HPC. Não são tipos de rede separados, mas pacotes que estabelecem quais funcionalidades uma implementação deve suportar. O AI Base deve cobrir a comunicação comum de IA com custos menores de implementação e estado. O AI Full acrescenta funcionalidades como deferred sends, correspondência exata e operações atômicas do tipo fetch ou compare. O perfil HPC inclui a maior parte do AI Full, exclui o Deferrable Send e dá mais peso à ordenação, mensagens curtas e semântica HPC.

O sistema de perfis visa evitar que cada produto precise implementar o conjunto máximo de funcionalidades. Ele reconhece que uma NIC de IA de alto volume pode priorizar a movimentação coletiva de dados, enquanto um endpoint HPC exige ordenação mais forte e atômicas. A opcionalidade, contudo, não desaparece. Um produto pode implementar funcionalidades opcionais dentro de um perfil, e dois produtos com o mesmo rótulo de perfil podem diferir em segurança, extensões de enlace, capacidade e desempenho.

A própria terminologia é um sinal de alerta. A especificação normativa 1.0.3 utiliza AI Base, AI Full e HPC. Um readme de conformidade separado, de 2025, utiliza AI Base, AI Extended e HPC. A interpretação mais respaldada é que “AI Full” é a atual e o material de conformidade está desatualizado ou inconsistente. Até que o pacote de testes público seja corrigido, fornecedores e compradores devem citar tanto a versão da especificação quanto a linguagem exata do perfil por trás de uma afirmação.

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

Dentro do UET, o Semantic Services Sublayer carrega a intenção da aplicação. Ele define identidade de mensagem, endereçamento de buffers, operações tagged e untagged, acesso remoto à memória, atômicas, comportamento de completion, identificadores de job, autorização de buffers, respostas e erros. O Packet Delivery Sublayer, em seguida, determina como essa intenção se transforma em pacotes e como eles chegam a outro endpoint.

Para modos confiáveis, os endpoints estabelecem Contextos de Entrega de Pacotes (PDCs). 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 retorno e classe de tráfego. Um PDC é associado a um modo de entrega e a uma classe de tráfego; podem existir vários PDCs entre o mesmo par de FEPs.

Esse estado não é um detalhe de implementação negligenciável. Clusters grandes podem gerar quantidades enormes de relações de comunicação. Se cada relação exigir um estado de destino extenso, o armazenamento do endpoint e os custos de lookup podem ser limitantes. A UEC, por isso, não força cada operação a um único modelo de conexão, mas define quatro serviços de entrega com contratos diferentes de confiabilidade e ordenação.

O Reliable Unordered Delivery (RUD) entrega cada pacote exatamente uma vez à camada semântica, mas permite que cheguem fora de ordem. Suporta packet spraying por múltiplos caminhos, retransmissão seletiva, supressão de duplicatas e colocação direta de dados. Como o destino pode depositar os dados com base em offsets, em vez de esperar por um buffer de reordenação do transporte, uma operação coletiva longa pode usar vários caminhos sem serializar todos os pacotes atrás de um único faltante.

O Reliable Ordered Delivery (ROD) garante entrega exatamente uma vez e ordenada. Utiliza um único caminho e valor de entropia, descarta pacotes fora de ordem e usa recuperação Go-Back-N a partir do primeiro número de sequência faltante. Parece menos sofisticado que o RUD, mas preserva a semântica para operações que exigem ordenação estrita. A UEC trata a ordenação como um requisito da aplicação, em vez de impor seu custo a toda transmissão.

O Reliable Unordered Delivery for Idempotent Operations (RUDI) coloca uma ênfase diferente. Entrega pelo menos uma vez e permite duplicatas, reduzindo o estado comum de sequência e confirmação no destino. Isso pode ser útil quando uma operação repetida não altera o resultado final, como em transferências remotas de memória selecionadas com uma barreira separada posterior. É perigoso se aplicado incorretamente. A camada de pacotes não infere idempotência; é o software que deve decidir. Usar RUDI para uma operação não idempotente pode gerar estado de aplicação inválido.

O Unreliable Unordered Delivery (UUD) entrega datagramas em melhor esforço, sem garantias normais de confiabilidade ou ordenação. Pertence ao mesmo quadro semântico, mas não carrega os mesmos requisitos de controle de congestionamento que RUD e ROD. As aplicações devem impedir que o UUD prejudique o tráfego controlado por congestionamento, caso filas ou classes de tráfego sejam compartilhadas.

Os quatro modos mostram uma filosofia central da UEC: a rede deve fornecer múltiplos mecanismos para que o software possa adequar os custos de transporte à semântica da operação. O benefício é a eficiência. O preço é uma superfície de implementação e teste maior, com mais possibilidades de o provedor, a aplicação ou o operador escolherem uma combinação incompatível.

Packet Spraying: usar o fabric em vez de apostar em um único caminho

O Equal-Cost Multipath convencional frequentemente amarra, por hash, um fluxo inteiro a uma rota. Em um fabric Clos amplo, isso cria uma loteria. Vários fluxos grandes podem colidir nos mesmos links, enquanto capacidade equivalente permanece ociosa em outro lugar. Uma longa transferência de IA fica então limitada, durante toda a sua vida, por um hash infeliz.

O UET enfrenta isso alterando a entropia no nível do pacote. Um remetente pode usar dezenas ou centenas de valores de entropia, de modo que os mecanismos ECMP existentes nos switches distribuam os pacotes por muitas rotas. O Packet Delivery Sublayer fornece informações de sequência; o Congestion Management Sublayer escolhe a entropia ou o caminho; os switches executam seu hash normal; o feedback informa ao remetente quais valores estão associados a congestionamento.

O packet spraying só é viável porque outras partes do design o suportam. Os pacotes podem chegar fora de ordem. O RUD pode posicionar os dados diretamente, em vez de esperar uma reordenação completa do transporte. A retransmissão seletiva recupera apenas o que foi perdido. O feedback de congestionamento reduz o uso de caminhos problemáticos. O mecanismo, portanto, não é um truque isolado de balanceamento de carga, mas parte de um modelo de transporte que tira proveito da diversidade de caminhos.

A UEC não exige que cada switch tenha um algoritmo proprietário de roteamento adaptativo. Implementações básicas podem usar entropia round-robin ou pseudoaleatória sobre ECMP padrão. Endpoints mais avançados podem mapear sinais de ECN, latência ou trimming para valores de entropia específicos e evitar os caminhos congestionados. O encaminhamento adaptativo proprietário pode coexistir com o UET, mas não é a única fonte de conhecimento de caminho.

A promessa é uma melhor utilização do fabric e menor tail latency. A questão em aberto é quão uniformemente diferentes endpoints interpretam o feedback e como o packet spraying interage com buffers de switch, reordenação, falhas e tráfego misto. Um algoritmo que funciona em um laboratório homogêneo pode se comportar de maneira diferente em um fabric grande, com várias gerações de switches e classes de tráfego. As evidências independentes com 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 o congestionamento no núcleo da rede, o incast no receptor e os buffers limitados do endpoint.

O Network-signal Congestion Control (NSCC) é controlado pela fonte. O remetente mantém uma janela de congestionamento, estima os bytes em trânsito e ajusta a janela com base em confirmações, confirmações negativas, timeouts, latência e sinais da rede como ECN. O comportamento da janela é coordenado com o múltiplos caminhos em nível de pacote. A UEC argumenta que uma janela interrompe naturalmente a admissão de novos dados quando os pacotes deixam de 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 o DCQCN ou outros mecanismos de congestionamento do RoCE. Os resultados dependem dos detalhes do algoritmo, da marcação do switch, da topologia, dos padrões de tráfego e dos parâmetros. “Usa NSCC” não é, portanto, uma declaração de desempenho suficiente.

O Receiver-credit Congestion Control (RCCC) visa o incast. Quando muitas fontes enviam simultaneamente para um destino, o último enlace pode se tornar o gargalo, ainda que o núcleo da rede não esteja congestionado. O receptor acompanha a demanda e distribui créditos entre os remetentes, escalonando a chegada total e variando a janela efetiva de cada fonte conforme a contenção. O RCCC pode trabalhar com o NSCC, porque o congestionamento no receptor e o congestionamento no núcleo são problemas distintos.

O Transport Flow Control (TFC) também utiliza créditos, mas é destinado a serviços ponto a ponto com buffers limitados. O objetivo é impedir diretamente o estouro do buffer de recepção quando a tolerância a perdas é baixa. O TFC pode ser usado com ou sem múltiplos caminhos. Igualar todos os mecanismos de crédito esconderia os diferentes domínios de falha que cada um deve controlar.

A especificação espera Explicit Congestion Notification em todo o fabric e contém premissas operacionais sobre marcação, incluindo a marcação no dequeue, e não apenas no enqueue. Os endpoints interpretam o ECN juntamente com confirmações, latência e trimming. A configuração uniforme dos switches é, portanto, indispensável. Uma implementação de transporte correta pode, ainda assim, apresentar maus resultados em um fabric mal configurado.

O histórico de manutenção mostra a dificuldade. A versão 1.0.1 corrigiu o algoritmo fonte do RCCC. A versão 1.0.2 corrigiu casos de gerenciamento de congestionamento. A versão 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 evidências de que o estado de crédito, retransmissão e controle de caminho interage de forma sutil. Os operadores precisam de disciplina de versão e testes de regressão, não apenas da conformidade do primeiro dia.

Packet Trimming e recuperação precisa de perdas

O Packet Trimming altera o que um switch adequado faz quando não consegue preservar um pacote completo. 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 identificação, marca o pacote como “trimmed” e encaminha a notificação reduzida ao destinatário. Este, então, pode informar ao remetente exatamente quais dados estão faltando.

Isso é mais informativo do que uma marcação de ECN. O ECN informa que houve congestionamento; o trimming aponta um pacote cuja carga útil não sobreviveu. Em combinação com RUD e retransmissão seletiva, isso pode acelerar a recuperação sem esperar por um timeout ou retransmitir uma longa rajada por causa de uma única perda.

A funcionalidade no switch é opcional, mas os endpoints conformes devem ser capazes de receber e interpretar pacotes trimmed segundo os requisitos aplicáveis. Essa assimetria viabiliza implantações sobre switches convencionais e permite que fabrics avançados ofereçam informações de perda mais ricas. Ao mesmo tempo, cria um problema de upgrade. Uma rede parcialmente atualizada pode precisar limitar o trimming por caminho, perfil ou topologia, para 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 devem mapear consistentemente valores DSCP, filas de switch, filas de endpoint e níveis de prioridade. A especificação não oferece um sistema de gerenciamento universal para isso. Um mapeamento incorreto pode matar de fome o tráfego de controle, distorcer o feedback de congestionamento ou fazer os pacotes de recuperação competirem com o tráfego que deveriam reparar.

O Packet Trimming ilustra a tarefa maior 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 é uma propriedade do sistema, não apenas do formato do pacote.

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

O Link Layer Retry (LLR) tenta corrigir falhas em um enlace físico antes que o transporte ponta a ponta reaja. Um par detecta uma lacuna de sequência ou um quadro corrompido, envia uma confirmação negativa local e faz o remetente repetir o quadro afetado a partir de um buffer local. Se a recuperação for rápida, o transporte pode evitar uma retransmissão ponta a ponta mais longa.

O valor potencial aumenta com as taxas por lane e a densidade de portas. Falhas ópticas ou elétricas ocasionais poderiam, de outro modo, gerar atrasos desproporcionais em um job fortemente sincronizado. O LLR, porém, adiciona estado de sequência, buffers de replay, mensagens de controle, janelas de descarte e novos modos de falha. Precisa coexistir com atualizações de crédito e resets de enlace. A versão 1.0.3 corrigiu várias condições de corrida, incluindo uma entre informações de crédito CBFC e LLR.

O Credit-Based Flow Control (CBFC) opera no nível de enlace, por canal virtual. Ele informa ao remetente quanta capacidade de recepção resta e pode ser mais granular do que uma pausa de prioridade genérica. A UEC o descreve como um meio de obter comportamento sem perdas controlado, sem tornar todo fabric UET totalmente livre de perdas. O CBFC é opcional, e o UET deve funcionar também sobre redes de melhor esforço.

O CBFC não é simplesmente outro nome para Priority Flow Control. A sinalização e a granularidade diferem, embora ambos busquem evitar o estouro de buffer. O CBFC ainda exige configuração uniforme e a entrega correta de seus próprios quadros de controle. Créditos locais podem, além disso, interagir com janelas ponta a ponta e créditos de receptor, gerando múltiplos laços de controle aninhados.

A UEC usa negociação baseada em LLDP para descobrir funcionalidades opcionais de enlace e impedir que um lado ative algo que o vizinho não suporta. A negociação precisa considerar perfis, canais virtuais, mapeamento DSCP e de prioridade, resets, upgrades de software e combinações parciais de funcionalidades. A versão 1.0.3 acrescentou uma capacidade de negociação booleana, ressaltando a necessidade de acordo explícito em cada enlace.

Essas opções criam um caminho do Ethernet básico ao avançado. Ao mesmo tempo, geram uma matriz que a linguagem de aquisição pode esconder. Um switch pode encaminhar UET perfeitamente sem suportar trimming, LLR ou CBFC. Outro pode oferecer as funcionalidades apenas em determinadas versões de software ou modos de porta. Uma evidência crível de implantação exige o conjunto exato de funcionalidades, não apenas o nome do consórcio.

Sinalização física com 100 e 200 Gigabit por lane

A camada física ancora a UEC no roteiro do hardware. O trabalho inicial da versão 1.0 era voltado para sinalização de 100 Gb/s por lane. A versão 1.0.3 acrescentou 200 Gb/s por lane. Isso alinha a especificação a uma geração de enlaces e sistemas mais densos; a capacidade no documento, porém, não prova que todos os produtos UEC suportem essa taxa de imediato.

O trabalho da PHY também aborda estatísticas de Forward Error Correction, taxas de palavras de código corrigidas e incorrigíveis, Control Ordered Sets, relatórios de qualidade de enlace e a interação de falhas físicas com o LLR. Esses detalhes são importantes porque as decisões de recuperação do transporte dependem do que as camadas inferiores conseguem observar e reportar.

Em taxas de sinalização mais altas, a fronteira entre óptica, SerDes, FEC, Link Retry e recuperação de transporte torna-se economicamente significativa. Um FEC mais forte pode reduzir erros residuais ao custo de latência e energia. O Link Retry pode corrigir falhas locais mais rápido, mas exige buffers e estado. A retransmissão ponta a ponta é mais simples em toda a rede, mas pode desperdiçar mais tempo. A UEC tenta definir como essas camadas cooperam, em vez de deixar cada fornecedor otimizar isoladamente.

A adição de lanes de 200G também mostra o alvo móvel do consórcio. Implementadores da versão 1.0 precisam manter compatibilidade enquanto planejam novas capacidades físicas. Equipamentos de teste, firmware e sistemas de gerenciamento devem distinguir o que cada porta suporta. Os compradores não devem inferir a taxa por lane a partir de uma declaração genérica sobre a UEC.

Segurança de transporte ponta a ponta opcional

O Transport Security Sublayer (TSS) oferece proteção opcional de endpoint a endpoint. Seu modelo de ameaça não exige confiança nos switches. Ele pode prover confidencialidade, integridade, proteção contra replay, isolamento de jobs, domínios seguros, chaves de grupo, rotação de chaves e integração com raízes de confiança baseadas em hardware.

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

O protocolo é apenas uma parte do sistema de segurança. Um operador em produção precisa gerenciar autoridades de chaves, certificados ou outras raízes de confiança, serviços de associação de jobs, distribuição e revogação, mudanças de época, recuperação de endpoint, criptografia em hardware e telemetria de segurança. Uma rede pode estar em conformidade com um perfil sem ativar todas as funcionalidades opcionais do TSS. “UEC-conforme” não significa automaticamente “criptografado”.

A opcionalidade reflete diferentes premissas de implantação. Um fabric dedicado e fisicamente controlado pode priorizar o desempenho e confiar em medidas ambientais. Uma nuvem multi-tenant pode exigir isolamento forte e proteção criptográfica. Os sistemas de perfil e aquisição precisam tornar a diferença visível.

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

O que significa “UEC-conforme” atualmente

A UEC começou a publicar documentação de conformidade com a versão 1.0, mas o sistema público não é um regime maduro de certificação independente. O pacote disponível é projetado principalmente para autodeclarações dos implementadores. Matrizes mapeiam requisitos da especificação para os perfis, e guias de testbed descrevem configurações recomendadas de endpoint e switch. Não foi encontrado um registro público abrangente em que uma entidade independente ateste aprovação ou reprovação de produtos em um programa completo da UEC.

A distinção é essencial porque circulam diferentes afirmações no mercado. Um produto pode ser projetado em torno de funcionalidades UEC em evolução. Pode implementar funcionalidades de fio selecionadas. Pode suportar um perfil, ou partes dele, em uma versão de software específica. Um fornecedor pode reivindicar total conformidade de funcionalidades. Um laboratório pode gerar tráfego UET através de um switch. Nenhuma dessas afirmações equivale automaticamente a certificação independente, ponta a ponta e com múltiplos fornecedores.

As recomendações públicas de testbed são úteis, mas deliberadamente limitadas. Elas fornecem topologias e verificações de boas práticas, em vez de uma qualificação completa do sistema. Interoperabilidade mais ampla, desempenho, estresse, escala e ciclo de vida de APIs são excluídos ou não cobertos integralmente. Os materiais não comprovam o comportamento com tráfego misto UET e RoCE, upgrades parciais, falhas repetidas, grandes domínios de chaves ou os números mais ambiciosos de endpoints do consórcio.

A inconsistência entre AI Full e AI Extended mostra adicionalmente por que a conformidade exige versionamento rigoroso. Os compradores devem perguntar qual especificação, nível de correção, perfil, funcionalidades opcionais, modos de enlace e funcionalidades de segurança estão cobertos pela afirmação. A resposta deve explicar se a evidência vem de testes internos, uma demonstração bilateral, um evento do consórcio ou um laboratório independente.

Um próximo passo crível seriam definições públicas de teste vinculadas a versões exatas da especificação, plugfests multi-fornecedor, resultados geridos de forma independente — incluindo negativos — e um registro que diferencie endpoints, switches, software e sistemas completos. Até lá, “UEC-conforme” é uma pergunta de entrada, não uma garantia plena.

Um documento aberto com obrigações de patente RAND

A Ultra Ethernet Specification 1.0.3 está disponível para download público e é distribuída sob a licença Creative Commons Attribution-NoDerivatives 4.0. Isso permite o compartilhamento com atribuição, mas veda a distribuição de versões modificadas sob essa licença. Mais importante ainda, o acesso ao copyright e o acesso às patentes são coisas separadas.

As cartas documentadas dos grupos de trabalho geralmente usam um modelo tradicional de especificação com licenciamento de patentes em bases razoáveis e não discriminatórias (RAND). RAND não significa necessariamente isento de royalties. Não garante um preço uniforme, não elimina negociações e não previne disputas sobre validade, essencialidade, abrangência geográfica ou condições defensivas. A posição comercial real depende de cada patente declarada, do compromisso do membro e de uma licença bilateral.

A UEC mantém um registro público de declarações de Necessary Claims. Até a data de referência, estavam visíveis declarações de Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell e outros, incluindo submissões para o futuro trabalho da versão 1.1. O registro aumenta a transparência, pois mostra que os implementadores precisam examinar a propriedade intelectual antes de desenvolver ou comercializar um produto.

O consórcio expressamente não decide se uma patente declarada é válida, realmente essencial, infringida ou disponível a determinado preço. Também não publica uma licença conjunta. Implementadores menores podem, portanto, arcar com custos legais e transacionais que grandes membros absorvem com mais facilidade. Uma especificação publicamente disponível pode, ainda assim, gerar um ecossistema comercialmente concentrado se a liberação de patentes, o custo do silício e o esforço de teste forem elevados.

O arcabouço de propriedade intelectual também molda os incentivos de governança. Empresas contribuem com tecnologia para criar um mercado amplo para seus produtos e para garantir que capacidades já existentes estejam representadas no design comum. As declarações de patentes só protegem os implementadores de surpresas se forem feitas em tempo hábil e com clareza suficiente. Elas não eliminam a possibilidade de o licenciamento se tornar uma barreira depois que a adoção tiver crescido.

A descrição honesta, portanto, é “publicado abertamente e multi-fornecedor, com compromissos de patente RAND”, e não “universalmente isento de royalties”. 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 por volta da publicação da versão 1.0, mas os exemplos estão em diferentes estágios de maturidade.

A AMD tornou sua NIC de IA Pollara 400 disponível comercialmente em abril de 2025 e a descreveu como projetada em torno das capacidades UEC em evolução. A Pollara é uma plataforma de endpoint programável e um sinal importante de que o transporte passou para o hardware em distribuição. A formulação é crucial: projetada para funcionalidades UEC em evolução não é uma 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 switching com 102,4 terabits por segundo e funcionalidades relevantes para a UEC. Em outubro, veio a NIC Thor Ultra 800G, com a afirmação do fornecedor de total conformidade com as funcionalidades UEC. Essa é uma alegação significativa, mas a evidência pública não a transforma em um certificado independente do consórcio. Amostragem, maturidade do software e suporte exato de perfil precisam ser demonstrados separadamente.

Nokia e Keysight anunciaram em outubro de 2025 uma demonstração ponta a ponta de tráfego UET sobre as famílias de switches de data center 7220 e 7250 da Nokia, 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 switching comerciais e que o suporte em equipamentos de teste está surgindo. Ele não comprova um perfil completo de endpoint multi-fornecedor, escala de produção e certificação independente de todas as funcionalidades opcionais.

Outros membros descreveram switches, sistemas, software ou planos de teste com capacidade UEC, e a Cúpula de 2026 concentrou-se fortemente na produtização. As evidências sustentam a transição para a implementação. Ainda não sustentam um número preciso de NICs UET em distribuição, switches certificados, regiões de nuvem produtivas ou fabrics completos.

A maneira mais sensata 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 NIC mostram investimento. Demonstrações de tráfego mostram parte da interoperabilidade. Matrizes de conformidade mapeiam requisitos. Relatos de implantação por operadores demonstrariam o valor operacional. Plugfests independentes e resultados de produção construiriam a credibilidade mais ampla que o acervo atual ainda não possui.

RoCE, InfiniBand, Slingshot e UALink

A UEC entra em um mercado com alternativas maduras e tecnologias adjacentes. O argumento estratégico não é que o Ethernet nunca transportou RDMA ou que os fabrics especializados não funcionam. É que a escala e a sincronização das cargas de IA atuais justificam uma nova arquitetura Ethernet ponta a ponta, com entrega, uso de caminhos e controle de congestionamento mais flexíveis.

O RoCEv2 é o predecessor direto e uma tecnologia instalada importante. Ele transporta RDMA sobre Ethernet roteável e é amplamente suportado por aplicações e produtos. A UEC critica as instalações comuns de RoCE por amarrarem fluxos inteiros a um único caminho, pela recuperação Go-Back-N, pela reordenação no receptor, pela difícil sintonia do DCQCN, pela dependência de Priority Flow Control em muitos designs e pelo comportamento fraco sob incast ou rajadas coletivas. Essas são posições técnicas da UEC, e não uma prova de que toda rede RoCE tem mau desempenho.

A comparação é dinâmica. Fornecedores podem incorporar roteamento adaptativo, packet spraying, melhores algoritmos de congestionamento ou outras funcionalidades semelhantes às da UEC em NICs programáveis e manter a compatibilidade com RoCE. A apresentação da Pollara pela AMD, por exemplo, mostra o RoCEv2 e o UEC RDMA como opções em hardware programável. A UEC pode, portanto, competir com o RoCE como transporte completo e, ao mesmo tempo, influenciar o desenvolvimento dos futuros produtos RoCE.

O InfiniBand é a principal alternativa de fabric especializado. Ele 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 a XDR para 200 Gb/s por lane e telemetria atualizada. O maior diferencial da UEC não é a alegação de que o InfiniBand não tem desempenho. É a possibilidade de alcançar o comportamento de IA e HPC por meio da cadeia de suprimentos Ethernet mais ampla, do roteamento IP padrão e de uma maior escolha de múltiplos fornecedores.

O HPE Slingshot ocupa uma posição intermediária. É um fabric HPC comercial compatível com Ethernet, com roteamento adaptativo e gerenciamento de congestionamento, e forneceu importantes precursores técnicos para o UET. Ele mostra que um comportamento especializado pode ser construído sobre Ethernet e, ao mesmo tempo, a diferença entre uma plataforma comercial controlada e uma especificação em âmbito setorial.

O UALink é, em sua maioria, complementar, em vez de substituto direto. Sua especificação pública atual de 200G visa conexões scale-up de baixa latência entre aceleradores dentro de um pod e descreve sistemas com até 1.024 aceleradores. A UEC 1.0 é primariamente um fabric scale-out que conecta nós através de switches. Um data center pode usar um enlace scale-up dentro de um pod de computação e UEC entre pods ou nós. Trabalhos futuros da UEC em transporte scale-up otimizado e coletivas na rede podem aproximar as fronteiras, gerando convergência ou competição.

O NVIDIA Spectrum-X e os fabrics proprietários de aceleradores são outra comparação. Uma pilha rigidamente integrada pode otimizar rapidamente hardware, software e suporte, 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, depende de desempenho, suporte, condições de patente, interoperabilidade e custo total de operação — não de “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 um fabric produtivo ainda precisa de um modelo operacional. A UEC 1.0 deixa um trabalho importante de gerenciamento fora ou nas bordas do núcleo normativo. Os operadores precisam configurar de maneira consistente perfis, classes de tráfego, limiares de ECN, quantidades de entropia, funcionalidades opcionais de enlace, chaves, firmware, telemetria e regras de falha em endpoints e switches.

O tráfego misto complica a tarefa. Um fabric 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 se resolvem apenas com a implementação correta de cada protocolo. Um algoritmo de congestionamento pode funcionar bem isoladamente e mal quando compete com outro controlador que tem feedback e premissas diferentes.

A complexidade do endpoint é outro risco estrutural. O UET coloca múltiplos caminhos, posicionamento direto, retransmissão seletiva, vários modos de entrega, controle por janela e crédito, recepção de trimming, segurança e grande quantidade de estado no FEP. Isso pode aumentar a área de die da NIC, o tamanho do firmware, o esforço de verificação, o consumo de energia e o número de condições de falha a diagnosticar. A inteligência no endpoint viabiliza uma cadeia de suprimentos ampla, mas pode deslocar a implementação mais difícil para o componente que todo servidor precisa comprar.

Funcionalidades opcionais criam simultaneously diferenciação de produto e fragmentação. Um fornecedor pode otimizar um endpoint AI Base básico para ECMP e ECN convencionais. Outro suporta AI Full, TSS, trimming, LLR e CBFC. Ambos pertencem ao ecossistema UEC, mas os operadores não devem presumir a mesma semântica, desempenho ou segurança. As matrizes de conformidade precisam se tornar matrizes de capacidades operacionais.

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

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

O teste operacional definitivo é a infraestrutura em operação. Um documento pode fixar 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 jobs reais sob congestionamento, falhas e upgrades, e os operadores conseguem explicar o que aconteceu.

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

Até julho de 2026, a UEC havia alcançado vários objetivos que eram incertos no lançamento. Formou uma ampla coalizão, criou uma arquitetura integrada em cinco camadas, publicou uma especificação 1.0 completa, manteve-a com versões de correção, acrescentou 200G por lane, divulgou declarações de patentes e atraiu anúncios de produtos e testes. O projeto está ativo, e sua agenda claramente transitou para a implementação.

Esse progresso torna as próximas incertezas mais importantes, não menores. A composição exata da adesão atual e o escalão do Steering Committee não estão publicados em um único registro oficial. As páginas públicas de membros e a carta descrevem o acesso de maneiras diferentes. A liderança formal do TAC não está totalmente alinhada com os papéis da cúpula. A data da versão 1.0.2 é contraditória nos documentos oficiais. O pacote de conformidade usa terminologia de perfil desatualizada. Nenhum desses pontos destrói a arquitetura, mas cada um é um sinal de controle documental e transparência em um projeto no qual as versões exatas importam.

Lacunas mais significativas dizem respeito à adoção. A UEC não publica censo de implantações, registro de produtos auditados de forma independente, orçamento autônomo ou demonstrações financeiras auditadas. As evidências públicas não comprovam uma rede UEC 1.0 totalmente interoperável nas metas máximas de escala do consórcio. Demonstrações e afirmações de fornecedores são valiosas, mas vêm de partes com interesses comerciais. Comparações neutras de desempenho com RoCE, InfiniBand e plataformas Ethernet integradas atuais permanecem limitadas.

A oportunidade continua sendo considerável. O Ethernet é o denominador comum nos data centers, e o mercado de infraestrutura de IA é grande o suficiente para novas gerações de NICs, switches, óptica e software. Os operadores têm fortes incentivos para evitar a dependência de um único fornecedor e aumentar a utilização dos aceleradores. Uma pilha comum poderia traduzir esses incentivos em poder de compra.

O risco é que “Ultra Ethernet” se torne um guarda-chuva para subconjuntos incompatíveis de funcionalidades. Se o encaminhamento básico funcionar, enquanto perfis, congestionamento, segurança e gerenciamento divergirem, a marca pode se espalhar mais rápido do que a interoperabilidade. Se o licenciamento RAND for caro ou obscuro, o círculo 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 rótulo dominante.

A pergunta decisiva não é mais se o consórcio consegue publicar uma especificação ambiciosa. Ele já o fez. A pergunta é se organizações independentes conseguem implementar os mesmos contratos, licenciar a tecnologia necessária, operar o fabric em grande escala e manter a compatibilidade durante a evolução. A UEC só se tornará infraestrutura na medida em que essas pretensões resistirem ao contato com o código em execução.