Imbue: 70B em 4.092 H100

01 · CONTEXTO

Um cluster em que tudo precisa funcionar

A Imbue treinou do zero um modelo de 70B parâmetros em infraestrutura própria, com uma equipe pequena, e publicou um guia que vai da subida do cluster à recuperação automática de erros durante o treino. O guia é a fonte deste caso.

O cluster descrito tinha 4.088 GPUs H100 distribuídas em 511 computadores, com oito GPUs por computador. Cada GPU se ligava a uma placa ConnectX-7 própria, capaz de transmitir e receber ao mesmo tempo a 400 Gbps para qualquer outra GPU da malha InfiniBand.

A malha InfiniBand tinha arquitetura de três camadas. A comunicação do treino passava por ela, e não pela Ethernet, que servia para transferir datasets, checkpoints e outros dados.

1. O cluster é feito de hosts com GPUs; cada GPU tem a própria placa de rede para falar com qualquer outra GPU da malha.

2. O tráfego do treino entre GPUs passa pela malha InfiniBand, organizada em três camadas.

3. Datasets, checkpoints e outros dados trafegam por uma rede Ethernet, não pela InfiniBand.

4. O projeto da InfiniBand é centralizado, com um cérebro só para a rede; a equipe lidava com uma única entidade para os 320 switches da malha.

5. Uma rede Ethernet secundária serve só para configuração e gerência. O BMC permite interagir com cada máquina como se estivessem fisicamente presentes.

02 · SUBIDA DO CLUSTER

Da máquina nua à malha InfiniBand

Um primeiro servidor foi instalado manualmente, e o software MAAS, da Ubuntu, ajudou a provisionar os demais.

Resolvidos os problemas de fiação, o UFM conseguiu contato com todos os switches da malha. Depois do recabeamento, a equipe adicionou verificações para confirmar que as conexões físicas batiam com o novo desenho.

03 · BURN-IN E CONJUNTO CONFIÁVEL

Estressar a malha e crescer um conjunto de máquinas confiáveis

Para diagnosticar problemas da InfiniBand com mais eficiência, a equipe criou uma carga que empurrava o máximo de dados possível por todas as portas da malha ao mesmo tempo. O UFM alertou transmissão acima de 97% da capacidade teórica na maioria das portas, e alguns switches caíram temporariamente. As portas que sobraram de pé ao fim do dia foram consideradas robustas o bastante; as demais foram desativadas ou enviadas para reparo.

Esse burn-in tem o espírito da engenharia do caos: exercitar a infraestrutura sob estresse deliberado, em vez de esperar a falha aparecer sozinha.

Como regra prática para hardware novo, a fonte cita cerca de 3% das máquinas quebrando por semana. A nuance é que não se trata de uma chance uniforme de falha por máquina: poucas máquinas problemáticas quebram repetidamente de formas diferentes até serem consertadas. Por isso, em vez de caçar falhas em máquinas aleatórias, a equipe pôde se concentrar em ampliar um conjunto de máquinas confiáveis.

04 · SAÚDE E RECUPERAÇÃO

Health checks por host e relançamento automático

A maioria dos problemas do treino pôde ser atribuída a máquinas ou componentes de rede defeituosos, e era essencial automatizar a desativação deles e o pedido de reparo. Os health checks foram desenhados para ter uma única porta de entrada, que responde sim ou não por host.

1. Uma falha de hardware, como um erro Xid ou SXid, pode derrubar a execução sem gerar um stack trace Python útil.

2. O orquestrador roda os health checks em todas as máquinas disponíveis e classifica a saúde de cada uma conforme os checks que ela passa.

3. O resultado de cada host se resume a uma resposta de sim ou não.

4. O orquestrador relança o treino nas máquinas mais saudáveis, a partir do checkpoint mais recente.

5. Para a rede, um script lê o log de eventos do UFM, desativa links e portas implicados, abre chamados de manutenção e reativa os componentes quando o conserto termina.

6. Ter mais máquinas do que o necessário, de 10% a 20% a mais, segundo a fonte, facilita relançar quando uma delas falha.

Reservar máquinas além do necessário é uma forma de redundância de capacidade.

05 · DIAGNÓSTICO

Travamentos sem stack trace e lentidões de MFU

O travamento mais memorável aparecia ao mesmo tempo em todos os workers da execução: quando um host não completava uma operação do NCCL, os demais ficavam bloqueados nela até o NCCL_TIMEOUT. A natureza do NCCL tornava muito difícil achar o host culpado. A equipe alterou o logging da biblioteca para mostrar quais operações estavam em andamento no momento da falha e, para achar hosts problemáticos, muitas vezes precisou ver quais hosts não produziram certas mensagens de log.

Havia situações em que uma execução num conjunto de máquinas falhava sem que se soubesse qual delas era a culpada. Um grupo de 48 máquinas, por exemplo, era dividido em seis grupos de oito e depois em oito grupos de seis; a máquina presente nas execuções com falha nas duas etapas era a problemática.

1. Um grupo de máquinas falha e não está claro qual delas é a culpada.

2. O grupo de 48 máquinas é dividido em seis grupos de oito, cada um com uma execução menor.

3. Depois, o mesmo conjunto é dividido em oito grupos de seis, com novas execuções menores.

4. A máquina que participa de execuções com falha nas duas etapas é a problemática.

Para lentidões, a fonte usa o MFU (utilização de FLOPs do modelo) como medida, e lentidões genéricas ou um MFU abaixo do já demonstrado podiam ter várias causas. A forma da curva de MFU ajudava a diagnosticar a classe do problema.

06 · LIÇÕES

O que o caso ensina sobre operar milhares de GPUs

A equipe destaca ter 10-20% mais máquinas do que o necessário para poder relançar com facilidade em caso de falha, e escrever testes e soluções automáticas para cada tipo de falha, porque todo problema encontrado reaparece. Adotou também a regra de mudar uma coisa de cada vez.

Por ser uma equipe pequena, ela tentou automatizar o máximo possível do processo.