Em 24 de agosto, a Meta divulgou os detalhes de design do MetaRoCE, um protocolo de transporte RDMA desenvolvido internamente para substituir o RoCE padrão. Na OCP Global Summit de outubro, a especificação completa do protocolo, uma implementação de referência chamada libsoftmetaroce e um conjunto de testes de conformidade para produção serão lançados juntos.
O RoCE padrão não aguenta a escala de centenas de milhares de placas
O RoCE foi projetado partindo do princípio de que a rede entrega cada quadro em ordem, garantindo a ausência de perda de pacotes por meio do PFC (Priority Flow Control) nos switches. Essa premissa funciona bem em clusters de algumas centenas de placas, mas começa a falhar na escala atual da Meta.
Segundo a própria Meta, o RoCE padrão espera entrega ordenada de cada quadro, depende do PFC e desencoraja o packet spraying — justamente a técnica usada para melhorar o desempenho em redes de grande escala com múltiplos planos. É aí que está o conflito: espalhar os pacotes de um mesmo fluxo por vários caminhos ao mesmo tempo contraria diretamente a "entrega em ordem". O PFC também funciona como contrapressão salto a salto — um congestionamento em um ponto se propaga de volta por toda a rede, o que tende a gerar efeitos em cascata em escalas muito grandes. Já as comunicações coletivas, como o all-reduce, precisam sincronizar milhares de aceleradores, e a transferência mais lenta define o ritmo de todo o trabalho.
O cenário-alvo citado pela Meta é "centenas de milhares de GPUs distribuídas por vários data centers e regiões". Nessa escala, depender dos switches para manter uma rede sem perdas já é praticamente uma aposta em probabilidades.
A inteligência migra para a placa de rede
O princípio de design do MetaRoCE foi resumido pela Meta em uma frase:
"The fabric sees packets, but the NIC sees intent."
A rede só vê pacotes; é a placa de rede que entende a intenção.
Isso se traduz em seis pontos: entrega fora de ordem nativa, com pacotes deliberadamente espalhados por vários caminhos e dados escritos diretamente no endereço de memória de destino, sem buffer de reordenação; multicaminho nativo, em que cada conexão mantém vários caminhos lógicos, cada um rastreando sua própria latência de ida e volta e o estado do ECN; tolerância à perda de pacotes, tratada como normal e compensada por um bitmap de confirmação seletiva, sem necessidade de PFC; controle de congestionamento duplo, combinando AIMD no lado do envio com sinalização de taxa justa no lado da recepção; independência de topologia, exigindo apenas marcação ECN e ECMP, funcionando em fat-tree, múltiplos planos ou switches com buffers reduzidos; e conexão unificada, em que uma única fila carrega vários fluxos de mensagens ordenadas e vários caminhos, compartilhando um único controlador de congestionamento.
Os números do teste com 64 nós
Os testes foram realizados em um cluster de 64 nós com GPUs AMD. O throughput ficou consistentemente acima do RoCEv2; com 1% de perda de pacotes, manteve-se cerca de 86% do throughput; com 10% de perda, o sistema continuou funcional. Em topologias de 4 e 8 planos, o throughput escalou de forma linear, com testes chegando a 4.000 conexões simultâneas. Quando um único plano falha, o tráfego se redistribui automaticamente, sem necessidade de intervenção na camada de aplicação.
Ainda há um longo caminho entre 64 nós e "centenas de milhares de placas". A própria Meta divide o trabalho futuro em três frentes: o scale-up dentro do rack precisa otimizar a sinalização rápida para operações curtas de memória, eliminando a latência causada por buffers de reordenação e pelo PFC; o scale-across, em escala de milhares de quilômetros, precisa de adaptação por caminho e de garantia de justiça em enlaces de longa distância com latência de ida e volta em milissegundos; já para cenários de armazenamento e cache KV, a ideia é usar sinalização de taxa no lado da recepção para lidar com incast, quando uma única leitura se espalha por vários servidores.
O open source é um recado para os fabricantes de placas de rede
No lado das placas de rede, hoje só a AMD Pensando tem uma implementação verificada; outras fabricantes ainda estão trabalhando nisso. Esse é o ponto que vai determinar até onde o MetaRoCE consegue ir — por mais elegante que seja o protocolo, se ele não entrar no firmware das placas de rede mais usadas, continuará sendo apenas uma solução interna da Meta.
Ao abrir o código via OCP e alinhar explicitamente com a iniciativa ESUN (Ethernet Scalable Unified Network), a intenção é clara: fazer os fabricantes de placas de rede produzirem de acordo com essa especificação, ampliando as opções de compra da própria Meta. Esse é um caminho que o ecossistema Ethernet já percorreu antes — o RoCE conseguiu tomar espaço do InfiniBand justamente por causa do ecossistema Ethernet mais barato e com mais fornecedores. Agora que o próprio RoCE se tornou o gargalo, a Meta quer repetir a jogada: colocar a especificação na mesa primeiro e fazer todo mundo seguir.
Para equipes que constroem clusters de computação de IA em grande escala, vale a pena conferir a especificação de outubro assim que ela for publicada, especialmente o ponto sobre não precisar de PFC. Eliminar o ajuste de PFC remove uma das fontes mais complicadas de problemas na operação.
Fontes: blog de engenharia da Meta, CocoLoop, materiais relacionados à iniciativa ESUN da OCP; números como os cerca de 86% de throughput com 1% de perda, funcionamento mantido com 10% de perda, o cluster de 64 nós com GPUs AMD e as 4.000 conexões simultâneas foram conferidos de acordo com a descrição de testes publicada pela Meta.