MetaRoCE o protocolo RDMA que a Meta criou para redes Ethernet com milhões de GPUs

O problema: RoCE não foi feito para um milhão de GPUs

Se você já sofreu com um job de treino distribuído travando porque um único link lento segurou o all-reduce inteiro, sabe do que estamos falando. Operações coletivas sincronizam milhares de aceleradores, e a transferência mais lenta define o ritmo do job inteiro.

O RoCEv2 padrão foi pensado para um mundo onde a fabric garante ausência de perdas via PFC e entrega os frames em ordem. Funciona bem em escala pequena. Na escala da Meta — centenas de milhares de GPUs espalhadas por data centers e regiões — isso vira um problema:

• PFC gera head-of-line blocking e tempestades de pause
• Entrega em ordem desencoraja o packet spraying, que é exatamente o que você precisa em fabrics multiplane
• Cada queue pair (QP) carrega sua própria janela de congestionamento, cega para as outras

A sacada central do MetaRoCE é simples: a fabric vê pacotes, mas a NIC vê intenção. Então a Meta moveu a inteligência para o endpoint.

Se você curte entender como governança aberta transforma ecossistemas inteiros, dá uma olhada no nosso post sobre a migração da React Foundation para a Linux Foundation — a mesma filosofia multi-vendor se aplica aqui.

Como o MetaRoCE funciona de verdade

Quatro pilares sustentam o protocolo:

1. Entrega fora de ordem nativa

O MetaRoCE faz spray de pacotes por vários caminhos, então eles chegam fora de ordem de propósito. Cada pacote carrega seu próprio destino, então o dado é escrito direto na memória final ao chegar — sem reorder buffer, sem head-of-line blocking.

# Visão conceitual: como um Send chega sem esperar predecessores
# (Pseudocódigo ilustrando o matching endpoint-driven do MetaRoCE)

def handle_incoming_packet(pkt):
    # Cada pacote carrega seu destino — sem reorder buffer
    if pkt.type == "WRITE":
        write_to_memory(pkt.dest_addr, pkt.payload)
    elif pkt.type == "SEND":
        # Faz match direto no buffer de recepção postado
        # Mesmo se mensagens anteriores ainda não chegaram
        match_and_deliver(pkt.match_bits, pkt.payload)
    # ACK imediato — sem round trip pra descobrir o destino
    send_ack(pkt.seq, pkt.path_id)

2. Multipathing nativo

Cada conexão ganha caminhos de primeira classe, com janelas e estimativas de RTT por caminho. Uma porta UDP de origem distinta por caminho serve como entropia ECMP, e a NIC pode trocar isso ao vivo pra desviar de link ruim. Em fabrics multiplane, a escolha do plano fica 100% com a NIC — a fabric só encaminha.

3. Tolerância a perdas por design

Sem PFC. Sem pause frames. O MetaRoCE trata o Ethernet como rede com perdas e não pede outra coisa. Cada caminho carrega sua própria sequência ordenada, então uma lacuna no bitvector SACK de 256 bits é evidência de perda, não de reordenação. O SACK dispara retransmissão exata do pacote faltante, no caminho que o perdeu, no momento em que a lacuna aparece.

4. Controle de congestionamento dos dois lados

O MetaRoCE combina AIMD baseado em ECN (sender-driven) com dicas de fair-share vindas do receptor. Em cada ACK, o receptor devolve a fatia de banda que alocou pra aquele sender — então os senders chegam direto na velocidade certa em vez de ficar buscando. Incast resolve em um ou dois round trips.

Benchmarks (cluster AMD de 64 nós, coletivas RCCL)

Se você quer prototipar os conceitos antes de mexer em hardware real, nosso guia de CodePen slideVars mostra como montar visualizações interativas de mudanças de estado — ótimo pra demonstrar lógica de fluxo de pacotes.

O que isso muda no seu cluster

Independência de topologia

O MetaRoCE pede à fabric exatamente duas coisas que todo switch já tem: marcação ECN e ECMP. Não exige packet trimming, telemetria in-network, controle de fluxo baseado em crédito, nem spraying do lado do switch. O mesmo transporte roda em fat-tree, multiplane, deep-buffer e shallow-buffer — incluindo clouds de vendor cuja config você não controla.

Conexões unificadas em escala

RDMA tradicional ganha banda abrindo mais QPs — dúzias por par de nós, cada uma com sua própria janela de congestionamento. O MetaRoCE separa streams de banda: uma única conexão carrega vários streams ordenados independentes por cima e vários caminhos por baixo, sob um único controlador de congestionamento. O estado da conexão para de crescer com o paralelismo do workload.

O que continua igual

APIs RDMA Verbs existentes e stacks de software funcionam sem modificação. Recursos extras como suporte a multiplane vêm via APIs de extensão. Isso é enorme pra quem tem investimento grande em código RDMA existente.

Limitações honestas

• Scale-up ainda não está resolvido. Dentro do rack, o MetaRoCE remove o reorder buffer e o PFC, mas o caminho rápido de sinalização pra operações curtas de memória (PE-to-PE) ainda está sendo otimizado.
• Scale-across está em andamento. Links longos com RTT em milissegundos e pequenas assimetrias de caminho são outro regime — compartilhamento justo de links longos congestionados é trabalho ativo.
• Storage/KV-cache é uma nova dimensão. Manter as dicas de rate do receptor precisas com velocidades de rede e tamanhos de request variáveis ainda está em aberto.
• Dependência de ecossistema. O sucesso depende dos vendors de NIC realmente entregarem silício compatível. A spec é aberta, mas silício leva tempo.

Conclusão

O MetaRoCE é uma aposta de que projetar pra perdas desde o dia zero vence fingir que Ethernet é InfiniBand. Ao empurrar a inteligência pro endpoint e tratar caminhos como entidades de primeira classe, você ganha um transporte que performa melhor em condições ideais e degrada com elegância quando as coisas dão errado — 86% de throughput com 1% de perda não é erro de digitação.

A especificação, uma implementação de referência otimizada pra DPDK e um framework de compliance de produção estão sendo liberados via OCP. Se você constrói NICs, switches ou infra de IA, vale acompanhar de perto.

Próximos passos

1. Leia a spec da OCP quando sair e compare com a semântica de flow control do RoCEv2.
2. Experimente a implementação de referência (libsoftmetaroce) — roda em Linux comum sobre sockets UDP padrão, sem hardware especial.
3. Estude o compliance suite se estiver avaliando vendors de NIC — é a ferramenta que prova se uma implementação bate com a spec.
4. Fique de olho na iniciativa ESUN — o MetaRoCE estende a filosofia multi-vendor dela da camada de fabric pra camada de transporte.

Leitura complementar

• Governança aberta da React Foundation — por que padrões abertos multi-vendor seguem vencendo
• Guia CodePen slideVars — monte demos interativas pra visualizar comportamento de protocolo

Baseado no anúncio do MetaRoCE publicado no Meta Engineering.