Redes de expansão de GPU baseadas em Ethernet

O recente lançamento do Gaudi-3 da Intel, que utiliza RoCE para interconexão Scale-UP, juntamente com as discussões de Jim Keller sobre a substituição do NVLink por Ethernet, chamaram a atenção para esta abordagem inovadora. Notavelmente, o Tenstorrent, onde Jim Keller está envolvido, implementou de forma inteligente a interconexão de rede entre chips usando Ethernet. Portanto, é pertinente abordar os desafios e requisitos da Ethernet para substituir o NVLink.

Substituir o NVLink pela Ethernet não é apenas uma questão de adotar um novo protocolo de transporte; requer uma série de modificações na arquitetura da GPU. Essencialmente, a questão equivale a descobrir como pendurar memória de alta largura de banda (HBM) em uma rede Ethernet e obter tanto o Scale-Out quanto uma série de otimizações de comunicação para atender às demandas computacionais, como a computação em rede exemplificada pelo SHARP. Globalmente, existem apenas alguns indivíduos capazes de resolver este problema multifacetado, e está claro que a UltraEthernet não compreendeu totalmente o conceito.

Para avançar, as seguintes questões-chave devem ser abordadas:

• Limite de latência: Qual é o limite de latência aceitável? A latência do link causada pelo SerDes FEC de alto rendimento e alta velocidade e pela interconexão além da escala de dezenas de milhares de cartões é inevitável. Esses problemas não podem ser resolvidos simplesmente modificando um protocolo de pacotes ou introduzindo HPC-Ethernet.
• Semântica de Transmissão: Quais são as semânticas da transmissão? Os profissionais de rede normalmente entendem as operações básicas de SEND/RECV. Por exemplo, a definição da UEC de Entrega Não Ordenada Confiável para Operações Idempotentes (RUDI) é um passo em falso técnico. Embora satisfaça as leis comutativas e idempotentes, não aborda como certas operações, como a idempotência da adição de redução, podem ser implementadas. Além disso, também são necessárias otimizações baseadas na lei associativa, que não são suportadas para o acesso refinado à memória no NVLink. De forma mais ampla, a semântica deve evoluir para uma semi-rede.
• Pooling de memória maior no NVLink: Como lidar com o pooling de memória maior no NVLink? Isso envolve resolver as compensações de tempo/espaço para operadores Compute Bound em problemas computacionais, como KV Cache.
• Roteamento dinâmico e controle de congestionamento: A capacidade de rotear e controlar dinamicamente o congestionamento em uma rede sem perdas não convergente 1:1 não é um problema significativo para clusters com dezenas de milhares de placas por meio de ajuste codificado. No entanto, para clusters na escala de centenas de milhares a milhões de cartões, que podem até exigir RDMA para transmissão de longa distância, nenhum fornecedor comercial ainda resolveu esses problemas.

Visão geral das soluções atuais de interconexão ScaleUP

Intel Gaudi3

De acordo com o whitepaper Gaudi3, o Gaudi Die está estruturado da seguinte forma: Incorpora 24 links RoCE de 200 Gbps, 21 dos quais são usados ​​para FullMesh interno e três para conexões externas.

A topologia para redes em escala ultralarga foi calculada e a largura de banda do switch Leaf é equivalente a um switch 25.6T.

Controle de congestão

O whitepaper da Intel afirma que, em vez de usar PFC, é empregado um mecanismo ACK seletivo. Além disso, o algoritmo SWIFT é usado para Controle de Congestionamento (CC) para evitar o uso de ECN. Essencialmente, este é um reaproveitamento do Reliable Transport Engine do Google Falcon na IPU da Intel.

Multipath e redução na rede

A Intel afirma oferecer suporte ao Packet Spraying, mas não está claro qual switch da empresa está sendo usado; certamente não é o seu próprio Tofino. Portanto, deve ser a Broadcom. Além disso, a Redução na Rede suporta FP8/BF16, etc., com as Operadoras suportando apenas Soma/Min/Máx. Combinado com os grupos de trabalho da UEC sobre In-Network-Computing (INC), o quadro fica mais claro.

Microsoft Maia100

Informações limitadas estão disponíveis, mas há uma largura de banda de chip único de 4800 Gbps. Um único chassi de servidor contém quatro placas Maia100 e um gabinete inteiro com oito servidores forma um cluster de 32 placas.

Examinando os switches ampliados e os cabos de interconexão, existem três switches, cada servidor possuindo 24 interfaces de rede de 400 Gbps. Existem conexões de loopback entre as portas (indicadas em preto no diagrama) e linhas de interconexão externas (indicadas em roxo).

Isto sugere uma topologia que forma uma interconexão em formato de boca dentro da placa-mãe, criando um anel na direção X e conectando-se a três switches em três planos na direção Y.

Os uplinks dos switches realizam conexões Scale-Out entre gabinetes, com cada plano em cada gabinete tendo um total de 32 400G interfaces. Adicionando uma convergência 1:1, o switch uplink se conecta para formar um switch 25.6T, tornando teoricamente viável uma expansão multicamadas. Isto representa uma fusão de redes Scale-Up e Scale-Out. Quanto ao protocolo, o RoCE simples ponto a ponto não deve representar um problema para o Torus Ring. No entanto, serão necessários recursos de multicaminhos ao interconectar-se com switches de escalabilidade horizontal.

A desvantagem é o potencial para maior latência. No entanto, para chips personalizados que não seguem o modelo SIMT como CUDA, mas usam uma abordagem de matriz sistólica, a latência não é um problema significativo. Além disso, com apenas quatro grupos Torus, o impacto da latência da comunicação coletiva é mínimo. Pessoalmente, acredito que esses chips provavelmente sejam usados ​​principalmente para inferência, já que os CSPs normalmente desenvolvem um chip de inferência antes dos chips de treinamento. Outros CSPs também têm uma distinção clara entre treinamento e inferência, como AWS Trainium/Inferentia e V5p/V5e do Google.

TPU do Google

A interconexão Google TPU é bem compreendida, apresentando uma topologia Torus Ring e switches ópticos para comutação de link.

O Optical Circuit Switching (OCS) serve dois propósitos: particionamento dinâmico de acordo com a escala de vendas e otimização da largura de banda de bissecção para comunicações All-to-All como MoE.

Por exemplo, um único chip TPUv5p suporta uma conexão Inter-Chip Interconnect (ICI) de 4800 Gbps com uma topologia 3D-Torus. Um cluster de 8960 unidades TPUv5p pode ser particionado dinamicamente pelo OCS para vender diferentes escalas, com a configuração máxima vendável sendo 6144 unidades formando um 3D-Torus.

A tolerância a falhas é uma consideração crítica para a topologia 3D Torus.

Além disso, o Google oferece suporte à extensão de dois pods pela rede do data center para criar treinamento Multislice, com paralelismo de dados paralelos (DP) entre os pods.

Treinamento AWS

A arquitetura AWS Trainium consiste em 16 chips formando um pequeno cluster interligado em uma estrutura 2D Torus Ring.

Tesla Dojô

Tesla Dojo desenvolveu seu próprio Tesla Transport Protocol para unificar Wafer/NOC e extensões Ethernet externas.

Utilizando o System-on-Wafer da TSMC, 25 unidades de computação D1 são encapsuladas em um único wafer, interconectado em uma rede Mesh 5D 5×2, com cada wafer formando um bloco contendo 40 matrizes de E/S.

Os Tiles são interconectados a uma taxa de 9 TB/s.

O roteamento de rede no chip pode ignorar núcleos ou blocos D1 com falha.

Para Ethernet de expansão externa, há uma placa Dojo Interface Processor (DIP), com cada mecanismo de computação D1 tendo sua própria SRAM e outra memória colocada na placa DIP equipada com HBM.

Cada placa de rede é conectada ao I/O Die do Dojo através de um barramento especial de 900GB/s, o Tesla Transport Protocol (TTP), correspondente ao 800GB Largura de banda HBM, com cada matriz de E/S capaz de se conectar a cinco placas DIP.

Devido à comunicação interna da rede Mesh 2D, a comunicação de longa distância é cara, portanto, projetos de roteamento especiais foram implementados.

O roteamento fornece vários caminhos no chip e está fora de ordem. Para comunicações de grande escala e longo caminho, um uso inteligente da placa de interface Dojo constrói um barramento Ethernet TTPoE de 400 Gbps como um atalho.

Dojo constrói uma rede on-chip em escala de wafer de alta densidade por meio do System-on-Wafer e uma rede privada de comunicação entre wafer de curta distância e alta velocidade a 9 TB/s. E/S e memória são integradas na placa DIP, fornecendo 900 GB/s por placa conectada à rede em escala wafer, formando uma rede Mesh 2D em grande escala. Porém, considerando o controle de congestionamento devido à longa distância de comunicação na rede on-chip, foi projetado um canal de escape de 400 Gbps baseado na placa DIP, que envia a comunicação através de um switch Ethernet externo para o wafer de destino.

Tentorrent

No projeto de interconexão chip a chip da Tenstorrent, Jim Keller utilizou Ethernet, que possui uma estrutura simples. O cabeçalho de controle Tensor + forma um pacote Ethernet e pode acionar recursos de execução condicional, conforme mostrado abaixo:

Interconexão completa chip a chip usando Ethernet

Suporta vários idiomas de origem de comunicação funcional

Depois, há o particionamento do gráfico. Parece que o número de instruções por estágio pode ser estimado, e a largura de banda dos operadores que entram e saem também pode ser estimada.

As restrições finais de mapeamento para os núcleos também parecem simples:

Uma estrutura de malha 2D simples

Pode ser dimensionado para até 40,960 núcleos para interconexões em grande escala

Requisitos técnicos para aumento de escala

Seleção de topologia

Na seleção da topologia de rede ScaleUp, podemos observar que a Nvidia atualmente usa uma estrutura Fat Tree convergente 1:1, enquanto outras empresas usam principalmente topologias Torus Ring ou 2D Mesh. Mais tarde, a Nvidia evoluirá para DragonFly.

A lógica por trás dessa escolha pode ser vista no artigo hammingMesh:

Para a largura de banda Allreduce, o Torus é o mais econômico e pode basicamente atingir o desempenho máximo. No entanto, para modelos como o MoE que requerem AlltoAll, a largura de banda da bissecção precisa ser considerada. O DragonFly tem um bom desempenho em termos de complexidade de fiação, largura de banda global e diâmetro da rede.

Roteamento dinâmico e transmissão confiável

Embora todos critiquem as deficiências do RoCE, o fato é que o BF3+Spectrum-4 possui roteamento adaptativo, a Broadcom possui DLB/GLB para evoluir o Packet Spraying e também existem tecnologias VoQ semelhantes às da Cisco. Meta também possui roteamento estático de múltiplos caminhos para engenharia de tráfego ou agendamento de afinidade no plano de controle.

No entanto, estas soluções só podem resolver parte dos problemas na escala de dezenas de milhares de cartões. O verdadeiro desafio surge ao dimensionar para centenas de milhares de cartões. Como podemos resolver isso?

Resolver rajadas algoritmicamente é uma tarefa difícil, e ainda mais desafiadora é que ninguém está tentando entender a causa raiz das rajadas. Em vez disso, eles estão constantemente tentando testar buffers de switch para mitigar rajadas, e alguns estão até explorando redes determinísticas e análise de Fourier. Isto é simplesmente perder o foco.

Este é um problema muito difícil e resta saber quando os outros intervenientes da indústria o resolverão. Outro aspecto é a falha do sistema e o dimensionamento elástico. O documento NSDI24 da Google menciona as razões da fragmentação.

Se essas questões não forem consideradas, isso levará a desafios de agendamento. Uma boa opção poderia ser a implementação da tabela de roteamento dentro do ICI, acoplada aos switches OCS.

Por que isso é importante para que a Ethernet suporte o ScaleUP? Porque a Ethernet precisa implementar uma camada de roteamento aqui para suportar o DragonFly e os recursos de comutação de links com falha.

A latência é importante para o Scale UP?

A essência desta questão é como as GPUs realizam o ocultamento de latência e as diferenças de latência entre NVLink e RDMA. É importante observar que as GPUs são processadores inerentemente otimizados para rendimento e, se buscassem baixa latência, isso indicaria problemas com sua implementação. O problema fundamental é que o NVLink usa semântica de memória, enquanto o RDMA usa semântica de mensagens, e também há desafios na implementação de RDMA para computação heterogênea.

Deficiências da implementação de RDMA

O principal fator que causa maior latência no RDMA em comparação ao NVLink é a CPU.

A Nvidia está resolvendo isso por meio do GDA-KI, que ajuda a ocultar muitas latências de acesso à memória de maneira mais eficaz.

Acesso refinado à memória

Outro problema é que o NVLink é baseado na semântica da memória e possui um grande número de acessos Load/Store refinados, tornando a eficiência e a latência da transmissão muito importantes. Mas como isso pode ser feito usando Ethernet RDMA? Seria necessário HPC Ethernet, pois os pacotes seriam muito grandes.

Este é o problema que venho discutindo no NetDAM – a necessidade de uma semântica Semi-Lattice para mensagens RDMA:

• A comutatividade garante que os dados possam ser enviados de maneira não ordenada.
• A idempotência resolve o problema de ambiguidade de pacotes descartados e retransmissões, mas para operações como Reduzir com efeitos colaterais, é necessária idempotência baseada em transações ou de dados.
• A associatividade ajuda a melhorar a eficiência da transmissão para acessos de memória refinados por meio de agendamento.

Para requisitos de acesso à memória, o protocolo no host normalmente tem tamanho FLIT. Para oferecer suporte a isso e ao mesmo tempo permitir interconexões ScaleUP em ultraescala, confiabilidade, cabeçalhos de roteamento, cabeçalhos Ethernet, isolamento multilocatário (cabeçalhos VPC), etc., a chave é aproveitar a associatividade. No entanto, o UEC parece ter perdido completamente isso, apenas fornecendo suporte para comutatividade e idempotência no RUDI.

A solução da Nvidia é a codificação associativa, que resolve o problema de acesso refinado.

A próxima geração do NVLink provavelmente convergirá com o Infiniband, e as redes ScaleOut e ScaleUP acabarão por se fundir.

Pool de memória para ScaleUP

Muitos modelos grandes hoje sofrem com a capacidade limitada do HBM (High-Bandwidth Memory). Embora a NVIDIA tenha resolvido isso conectando Grace e NVLink C2C para estender a memória, a questão fundamental é que a rede ScaleUP requer pooling de memória.

Conclusões

1. Qualquer empresa que pretenda fazer Ethernet ScaleUP precisa considerar os seguintes desafios principais:
2. A latência não é tão crítica. Ao modificar os padrões de acesso à memória da GPU para se alinhar com a semântica da mensagem e, em seguida, armazenar o processamento em cache, a latência pode ser ocultada.
3. Os recursos de roteamento dinâmico e isolamento de locatário da rede ScaleUP são cruciais. São necessárias soluções de roteamento eficazes, especialmente para resolver os problemas de fragmentação causados ​​por falhas de enlace.
4. A semântica do RDMA (Remote Direct Memory Access) é imperfeita e a simples cópia do SHARP (Scalable Hierarchical Aggregation and Reduction Protocol) apresenta muitas armadilhas. É necessária uma semântica Semi-Lattice, suportando uma série de operações de efeitos colaterais para alcançar a idempotência.
5. O encaminhamento de múltiplos caminhos de malha e o controle de congestionamento são necessários para melhorar a utilização geral da malha.
6. O pool de memória em grande escala é essencial.