Configuração de infraestrutura e scripts open source para treinar um modelo 70B em bare metal

 (imbue.com)
1 pontos por GN⁺ 2024-06-29 | 1 comentários | Compartilhar no WhatsApp
  • A Imbue treinou do zero um modelo de 70B de parâmetros em sua própria infraestrutura bare metal com uma equipe pequena e divulgou os procedimentos operacionais e scripts, da construção do cluster à recuperação de falhas
  • O cluster era composto por 4.088 GPUs H100 e 511 servidores GPU, com 8 GPUs por servidor participando de treinamento síncrono em larga escala via InfiniBand
  • Na prática, a implementação envolveu repetir o processo de provisionamento de máquinas individuais, manutenção da malha InfiniBand, verificações de saúde dos hosts, diagnóstico de erros de treinamento e melhorias de automação, além de lidar com cerca de 10% de falhas de boot das máquinas e um grande volume de alertas de portas
  • As ferramentas abertas incluem verificações de saúde dos hosts, patch de logging do NCCL, teste de estresse de GPU, testes de rede NVLink e InfiniBand, parser de logs de eventos do UFM e script gerador de workload de burn-in de InfiniBand
  • Em treinamentos de LLM em larga escala, um único host ou link instável pode atrasar toda a execução, por isso checagens automáticas de saúde, isolamento de falhas, reinício e desativação de portas tornam-se essenciais para a operação contínua

Construindo um cluster para treinar seu próprio modelo 70B

  • A Imbue treinou do zero, ao longo de vários meses, um modelo de 70B de parâmetros em sua própria infraestrutura, e esse modelo superou o GPT-4o zero-shot em tarefas relacionadas a raciocínio
  • O escopo divulgado cobre um processo de infraestrutura end-to-end, do boot inicial do cluster e instalação do sistema operacional à recuperação automática de erros durante o treinamento
  • As ferramentas de infraestrutura divulgadas junto foram as seguintes
    • Host-level health checks: scripts que verificam se o host pode ser colocado em treinamento sem erros conhecidos
    • Patch de NCCL: aprimorado para gerar mais logs em situações de erro e travamento
    • GPU stress test: valida se a GPU consegue alocar tensores grandes e executar operações padrão
    • Networking tests: verifica a comunicação NVLink entre GPUs da mesma máquina e a comunicação InfiniBand entre GPUs de máquinas diferentes
    • UFM event log parser: analisa logs de eventos do Unified Fabric Manager para decidir quais portas de rede devem ser desativadas
    • InfiniBand burn-in workload generator: gera uma carga de burn-in de InfiniBand que estressa todos os links disponíveis

Configuração do cluster e da rede

  • O cluster principal distribuía 4.088 GPUs H100 em 511 servidores GPU, com 8 GPUs por servidor
  • O motivo de haver 511 servidores GPU era a necessidade de reservar parte das conexões para nós do Unified Fabric Manager (UFM), usados na administração da rede InfiniBand
  • Cada GPU estava conectada diretamente a uma placa ConnectX-7 e podia enviar e receber a 400 Gbps simultaneamente com outras GPUs da rede InfiniBand por meio de sua própria placa ConnectX-7
  • A topologia InfiniBand tinha uma estrutura fully non-blocking, em que teoricamente todas as GPUs podiam se comunicar simultaneamente com outras GPUs na velocidade máxima
    • Uma arquitetura de switches InfiniBand em 3 níveis fornecia a vazão total da rede
    • A comunicação de treinamento era feita em InfiniBand, não em Ethernet
  • A Ethernet era usada para datasets, checkpoints e outras transferências de dados
    • Se a comunicação de treinamento fosse enviada pela Ethernet, teria de sair da GPU para a CPU e então passar por uma placa Ethernet de 100 Gbps, o que seria muito mais lento
    • Também é possível fazer treinamento em Ethernet com RoCE, mas isso exige muito trabalho adicional tanto no hardware quanto no software e, em geral, é menos confiável que InfiniBand
  • Uma rede Ethernet separada para gerenciamento era usada para acesso ao BIOS, às fontes de alimentação e a controladores de interface de máquina de baixo nível
    • Sem essa rede de gerenciamento, seria necessário configurar manualmente centenas de máquinas com pendrive USB, teclado e monitor
  • Em treinamentos de alto desempenho em larga escala, InfiniBand, Ethernet, GPUs e nós precisam funcionar de forma quase perfeita
    • Mesmo uma única conexão instável entre mais de 12 mil conexões pode tornar toda a execução de treinamento mais lenta

Provisionamento de máquinas individuais

  • Depois de criar uma conexão Ethernet com o cluster pela rede inicial de gerenciamento, foram obtidas as credenciais de acesso ao BMC (Baseboard Management Controller)
    • O BMC é um processador de serviço para monitorar o host remotamente
    • Ele fornece estado do hardware, configurações de BIOS e APIs de gerenciamento de energia
  • No primeiro servidor, o Ubuntu 22.04 foi instalado manualmente via iDRAC, o BMC da Dell
    • Era possível montar uma imagem ISO a partir do computador local para fazer o boot, e ele fornecia um console virtual baseado em navegador
    • O objetivo era fazer dessa instalação manual a única de todo o processo

  • MAAS e boot PXE

    • Após preparar a primeira máquina, foi instalado o Ubuntu MAAS (Metal-as-a-Service) para provisionar os demais servidores
    • Com boot PXE e ferramentas automatizadas de iDRAC, cada máquina foi instruída a iniciar pela rede
    • Os servidores recebiam um IP do MAAS via DHCP, baixavam o kernel inicial e faziam automaticamente a instalação permanente do sistema operacional, mesmo com o disco local vazio
    • Na prática, como a integração entre MAAS e BMC não era estável, todos os endereços MAC das máquinas foram coletados antecipadamente pela API do iDRAC
    • O MAAS foi em geral confiável durante todo o processo de treinamento, mas no início houve problemas específicos de configuração
      • Diferenças grandes de relógio faziam a verificação de certificados HTTPS falhar e bloqueavam instalações via apt
      • O servidor MAAS acumulava ao mesmo tempo as funções de DHCP, DNS, proxy HTTP, NTP, gerenciamento de configuração do cloud-init e banco de dados de referência de MAC, IP, hostname e metadados, o que dificultava rastrear a causa dos problemas

  • Falhas de boot e observabilidade básica

    • Como é comum na configuração de clusters grandes de GPU, cerca de 10% das máquinas falharam no boot, e a principal causa foram problemas físicos nos servidores
      • Cabo Ethernet desconectado ou ligado incorretamente
      • Problemas de hardware no iDRAC
      • Falha na fonte de alimentação
      • Unidade NVMe defeituosa
      • Cabeamento interno ausente
      • Placa de rede ou GPU não reconhecida
    • A Imbue automatizou verificações para esses problemas, encaminhou algumas máquinas para reinspeção da Dell e abriu os tickets necessários com a equipe do datacenter
    • Como a própria equipe fez a configuração da infraestrutura, foi possível usar imediatamente as máquinas saudáveis mesmo enquanto outras aguardavam reparo
    • Em todos os servidores, foram instalados Docker, driver de GPU para datacenter, Prometheus node exporter, NVIDIA DCGM exporter e um pool RAIDZ ZFS em todos os discos além do sistema operacional
    • O ZFS permitiu manter a máquina operacional mesmo com a queda de um disco e reduziu bastante o espaço usado por datasets de texto comum e logs repetitivos com compressão transparente
    • Ao instalar pacotes de software em paralelo em 400 nós, surgiu um gargalo de largura de banda
    • Alertas de alta temperatura apareceram inicialmente em vários componentes da implantação no datacenter, e a maior parte dos problemas térmicos iniciais foi amenizada com atualizações de firmware

  • Verificação de treinamento GPU em nó único

    • Foi verificado se cada máquina conseguia, de forma independente, lidar com workloads reais de GPU
    • Várias máquinas falharam no treinamento GPU em nó único pelos seguintes problemas
      • Erros relacionados a GPU foram em sua maioria resolvidos recolocando a placa no slot
      • Nos logs do servidor Ubuntu, a conexão PCIe aparecia como limited width: x4 < x16
      • Mesmo após a atualização de firmware do barramento do switch PCIe, ainda foi necessário reconectar os cabos PCIe internos em cerca de um quarto dos hosts do cluster
      • Havia unidades NVMe que não eram marcadas como defeituosas, mas travavam a máquina inteira quando acessadas
      • No Linux, a ordem dos discos aparecia aleatoriamente, fazendo o MAAS instalar o sistema operacional no disco errado
      • Leituras incorretas de temperatura faziam as ventoinhas girarem sempre a 100%
      • O escalonamento dinâmico de frequência da CPU limitava os núcleos ativos a 2 GHz
      • Houve falha na aplicação do GDR, ou seja, GPUDirect RDMA Peer Memory Client

Provisionamento do InfiniBand

  • O InfiniBand tinha um único controlador em toda a rede graças ao design centralizado, e era possível tratar 320 switches de rede como um único fabric
  • A primeira tarefa foi identificar qual switch estava conectado a qual máquina e, comparando com o diagrama de cabeamento, renomear os switches com base na localização física

  • Projeto incorreto do fabric e recabeamento

    • No início, o UFM não conseguia detectar os 320 switches de rede e também não encontrava os hosts que deveriam estar no fabric
    • Após verificar com o parceiro do data center, os switches estavam ligados e cabeados, mas não eram detectados
    • Ao investigar a lista de cabeamento de rede, descobriu-se que o fabric superior não era um fabric unificado, mas sim 8 redes separadas sem rota de encaminhamento comum
    • Após o recabeamento, foi adicionado um check para confirmar que todas as conexões físicas correspondiam ao novo projeto

  • Alertas de temperatura e erros de porta

    • Depois de resolver os problemas de cabeamento físico, o UFM se conectou a todos os switches InfiniBand, mas quase todas as portas dos switches reportavam temperatura excessivamente alta
    • Mesmo antes da transmissão real de dados, algumas portas já ultrapassavam 70 graus Celsius, e a causa era uma estrutura em que o ar quente recirculava para a frente pelos espaços vazios entre os switches no rack de rede
    • Muitas portas apresentavam altas taxas de erro ou link flapping, alternando entre estado normal e falho, e esse problema só aparecia quando a porta era realmente usada, o que dificultava a detecção prévia
    • O fabric inteiro tinha 10.000 links e alta redundância, mas quando cerca de 10% do fabric apresentava problemas, mesmo recursos como adaptive routing não conseguiam desviar suficientemente dos links que caíam de forma irregular
    • O parceiro do data center limpou e recolocou as portas com alerta, e os demais transceptores com alerta aguardando substituição foram desativados
    • Nesse período, foram executados treinamentos multinó em 100 a 200 máquinas para encontrar um subconjunto estável de InfiniBand

  • Burn-in do InfiniBand e GPUDirect RDMA

    • Para diagnosticar os problemas de InfiniBand com mais eficiência, foi criada uma workload especial que empurrava o máximo possível de dados simultaneamente por todas as portas de todo o fabric
    • Isso era diferente de executar um único all-reduce grande em todo o cluster
      • porque o NCCL otimiza a comunicação dentro de um único nó usando NVLink e os caminhos dos sockets SXM
    • O UFM enviou alertas de transferência de dados em mais de 97% da capacidade teórica na maioria das portas, e alguns switches chegaram a travar temporariamente
    • As portas que continuavam operando até o fim do dia eram consideradas robustas o suficiente, e as demais eram desativadas ou encaminhadas para reparo posterior
    • O GPUDirect RDMA foi ativado para que as GPUs se comunicassem sem overhead de CPU

  • Conjunto de máquinas estáveis e manutenção

    • Como regra prática para clusters de GPU com hardware recente, deve-se esperar que cerca de 3% das máquinas falhem por semana
    • Não é que todas as máquinas falhem com a mesma probabilidade de 3%; algumas máquinas problemáticas falham repetidamente de várias formas
    • Ao colocar muitas máquinas no mesmo fabric, é possível aumentar um conjunto de máquinas golden conhecidas por serem estáveis, em vez de ficar perseguindo problemas aleatórios de máquinas
    • A manutenção do InfiniBand consistia principalmente em responder a alertas do UFM, trocar cabos e transceptores e diagnosticar switches defeituosos
    • Regressões em grande escala normalmente vinham de dois fatores
      • Uma atualização de firmware aplicada a apenas metade do cluster corrompeu o estado do UFM, exigindo reinício do UFM em todos os switches InfiniBand
      • Reiniciar em massa as caixas de GPU ao mesmo tempo gerava uma enxurrada de atualizações de estado no UFM, exigindo reinício do serviço UFM

Sistema de health checks dos hosts

  • A Imbue encontrou várias falhas em máquinas individuais que faziam execuções de treinamento falharem ou ficarem lentas, e escreveu health checks para determinar se um host estava saudável o suficiente para treinamento
  • O código foi publicado em cluster-health
  • Muitos checks são específicos do ambiente de runtime da Imbue, mas o objetivo era retornar yes/no a partir de um único ponto de entrada sobre a prontidão para treinamento

  • Health checks rápidos

    • GPU Health Check: verifica quantidade de GPUs, ECC habilitado, erros de ECC, topologia NVLink e erros
    • Disk Space Health Check: verifica se o uso de disco do host não ultrapassa 95%
    • Docker Health Check: verifica se os contêineres com acesso a GPU estão em execução e as permissões dos contêineres de monitoramento e profiling
    • Dmesg Health Check: procura erros Xid e SXid de GPUs NVIDIA ou switches NVIDIA e verifica se as linhas de log do dmesg podem ser classificadas em uma lista de logs esperados
    • iDRAC Health Check: verifica erros de iDRAC em máquinas Dell e ignora mensagens de erro não críticas
      • Este check não é destinado à publicação open source
    • Disk Health Check: verifica montagem do zpool, conexão do Docker e se a CPU trava ao acessar o disco
    • InfiniBand Health Check: verifica aumento da taxa de erro do InfiniBand e firmware de driver desatualizado
    • Nvlink Health Check: verifica erros de NVLink na máquina
      • Empiricamente, isso não causava falhas de treinamento, mas podia deixá-lo mais lento
    • GDR Health Check: verifica se o GDR está habilitado na máquina
    • VBIOS Health Check: verifica se a versão do VBIOS da GPU e o firmware da baseboard H100 estão atualizados
    • Flint Health Check: usa flint e hca_self_test para verificar versões do driver Mellanox OFED, firmware da placa, firmware do transceptor e o estado de compilação do driver NVIDIA
    • PSB Health Check: consulta dispositivos PCIe para verificar se a velocidade e a largura da conexão entre GPU, PSB e placa de rede correspondem ao esperado
      • Como é um script desenvolvido pela Dell, ele não pode ser compartilhado no momento

  • Health checks mais longos

    • Inicializa cálculos matriciais com PyTorch para medir largura de banda do NVLink, velocidade de computação da GPU e memória
    • Define flags de GDR para testar tanto InfiniBand quanto NVLink
    • Usa ib_write_bw e --use_cuda para enviar dados à placa IB e medir a largura de banda da PCIe e da placa InfiniBand
    • É executado por cerca de 15 minutos para capturar links InfiniBand com flapping
    • Uma execução de diagnóstico multinó verifica se a inicialização do NCCL é possível e se há travamentos aleatórios
      • Se travar, o código de NCCL com fork deixa logs adicionais
    • Como a detecção de problemas pode levar de 12 a 24 horas, ele é usado principalmente em nós novos ou em situações suspeitas
    • Verifica eventos de throttling de clock da GPU nos exports do DCGM, excluindo os esperados gpu_idle e power_cap
    • Um treinamento multinó que usa simultaneamente todas as GPUs, placas InfiniBand, CPUs e discos é o que melhor revela eventos de energia

Diagnóstico de erros comuns durante o treinamento

  • Crash logo após o início

    • Os crashes logo após o início eram os erros mais fáceis de lidar, pois eram relativamente simples de reproduzir e repetir
    • Primeiro, verificava-se se a versão do código, a configuração e as variáveis de ambiente estavam corretas
    • Abstrações intermediárias, como cache de imagem Docker ou configurações opacas de secrets, podiam dificultar a identificação da causa
    • Também se verificava se todas as máquinas estavam online e se stack traces e logs podiam ser facilmente agregados e inspecionados
      • A Imbue usa a stack Loki, Prometheus e Grafana
    • Em execuções distribuídas síncronas, o primeiro erro frequentemente causava erros em cascata não relacionados
    • Ao criar um sistema de reexecução automática, a agregação de logs e erros se tornou ainda mais importante para evitar que logs e erros de execuções diferentes se misturassem
    • Os erros vistos com frequência eram os seguintes
      • Forward order differs across ranks...: podia ser resolvido com reexecução devido a uma característica da implementação PyTorch FSDP
      • CUDA out of memory...: era resolvido verificando configuração e código, e revertendo mudanças recentes no código
      • OOM de CPU/RAM: era melhor detectar pela chamada do OOM Killer nos logs dmesg do host fora do contêiner

  • Crash no meio do treinamento

    • Depois que o hardware começava a operar, a prioridade era ter um sistema que reexecutasse todos os health checks de diagnóstico e reiniciasse automaticamente excluindo os hosts não saudáveis
    • Erros aleatórios de hardware, como Xid e SXid, podiam derrubar a execução sem um stack trace Python significativo
    • Algumas ocorrências, como row remapping, podiam ser recuperadas com reinicialização, mas erros ECC não corrigíveis normalmente exigiam manutenção de hardware ou substituição de componentes
    • Dados de treinamento particularmente mal formatados também causavam crashes
      • Um único documento muito grande no corpus podia causar OOM de GPU ou CPU
      • Usava-se um data loader totalmente determinístico para relacionar facilmente epoch ou número de step com o crash
      • Para verificar se os dados eram a causa, desativava-se o carregamento de dados ou substituíam-se por dados falsos compostos apenas por zeros
    • Quedas momentâneas de Ethernet ou falta de espaço em disco podem não aparecer com mensagens de erro úteis, então métricas de rede e de estado dos nós eram registradas para verificar correlação

  • Travamento sem stack trace

    • Erros que travavam ou davam timeout sem stack trace eram especialmente difíceis de depurar, por falta de informação e por serem difíceis de reproduzir de forma estável
    • Uma mensagem típica era no formato Watchdog caught collective operation timeout...
    • Se um ou mais hosts não concluíssem uma operação NCCL ou se se desconectassem da conexão NCCL ou InfiniBand, todos os outros hosts ficavam bloqueados de forma síncrona nessa operação de tensor até NCCL_TIMEOUT
    • Pelas características da biblioteca NCCL, era difícil descobrir qual host era a causa
    • A Imbue adicionou mudanças de logging ao fork do NCCL para expor melhor mensagens ou operações in-flight no momento do crash e identificar o host ou GPU problemático
    • Muitas vezes era necessário verificar o host que não gerou uma determinada mensagem de log para encontrar o host com comportamento incorreto
    • Com Py-Spy e GDB, depuravam-se processos travados em tempo real para distinguir entre travamentos de NCCL, travamentos de driver e race conditions ou deadlocks em código Python

Queda de velocidade de treinamento vista por MFU

  • Quedas gerais de desempenho ou MFU (Model FLOPs Utilization) abaixo do nível observado anteriormente podiam surgir por várias causas
  • Primeiro, ajuda verificar novamente configuração, código e variáveis de ambiente
    • modelo incorreto
    • tamanho de batch incorreto
    • configuração incorreta de UFM ou NCCL
    • CUDA_DEVICE_MAX_CONNECTIONS incorreto
  • Medir o MFU instantâneo por batch, em vez de uma média suavizada, era mais útil para diagnosticar o tipo de problema

  • Causas por padrão de MFU

    • Se, logo após o início do treinamento, o MFU permanecesse estável abaixo de 1/10 do esperado, normalmente era um problema de hardware InfiniBand, como um switch morto nas camadas T2 ou T3
      • Problemas de hardware entre GPU e NIC também podiam ser a causa, aparecendo no dmesg como PCIe x16 lanes limited by ...
    • Se, logo após o início, o MFU permanecesse estável em 30% do esperado, podia haver configuração GDR incorreta ou variável de ambiente GDR incorreta em um host
    • Se, logo após o início, o MFU permanecesse estável entre 60% e 80% do esperado, normalmente a causa era um link InfiniBand degradado ou defeituoso
      • Se a NIC InfiniBand conectada a uma GPU específica estivesse com defeito, o NCCL tentava usar a NIC de outra GPU no mesmo host por meio do NVLink local
      • CPU throttling também podia ser a causa, exigindo ajuste de configuração de BIOS em um host específico
    • Se ocorressem quedas de 10x de forma regular em um único batch, quase sempre havia relação com checkpointing ou avaliação, o que podia ser verificado comparando com os números de epoch e step
      • Criar alerta automático apenas com base em anomalias de MFU gerava muitos false positives
    • Se quedas de 10x em um único batch fossem raras, aleatórias e se recuperassem imediatamente, era comum que um workload intensivo em CPU tivesse sido agendado em um dos hosts em execução
      • Problemas intermitentes de rede ou gargalos no data loader também podiam ser a causa
    • Se o gráfico de MFU caísse gradualmente ao longo da execução e voltasse a 100% ao reiniciar, validou-se com os profilers da Python e da NVIDIA que a coleta de lixo automática era a causa
      • Ao desativar a coleta de lixo automática e executá-la em intervalos específicos em todos os hosts, a queda de throughput desapareceu
    • Se o desempenho inicial fosse bom, mas depois caísse com frequência para 70% do esperado, havia correlação com NVIDIA GPU clock throttle reasons
      • As causas eram temperatura da GPU, falha ou degradação das ventoinhas de refrigeração do host e falha na fonte de alimentação
    • Se o desempenho fosse bom, mas houvesse muito ruído de alta frequência entre 90% e 100% do MFU esperado, normalmente era um problema de hardware InfiniBand, como degradação moderada em camadas superiores da rede ou link com flapping

  • Perguntas para verificar regressão de throughput

    • Verificar se isso já tinha funcionado normalmente antes
    • Verificar se houve algo alterado recentemente, como merge de código ou atualização de driver
    • Verificar se está sendo executado em hosts saudáveis e se serviços dependentes, como Docker Hub e GitHub, estão funcionando
    • Verificar se a execução está usando o mesmo código, ambiente, configuração, versão, lista de hosts, ordem de rank e random seed da última execução que funcionou normalmente
    • Verificar se é reproduzível
    • Verificar se há correlação com outros processos, crontab diário e métricas de host, DCGM ou UFM
    • Verificar se a ferramenta de medição de métricas está correta
    • Verificar se o problema também ocorre em código reduzido, como com modelo menor, dados falsos ou sem salvar/carregar checkpoints

Ferramentas de automação e melhorias operacionais

  • Mesmo que o treinamento comece com bom desempenho, algo acaba quebrando em algum momento, então foram necessárias ferramentas e sistemas para minimizar a intervenção humana
  • Como a Imbue é uma equipe pequena, não havia pessoal suficiente para continuar fazendo reparos manuais, então eles automatizaram o máximo de processos possível
  • A maioria dos problemas nas execuções de treinamento foi reduzida a máquinas ou componentes de rede com defeito

  • Exclusão automática de máquinas com defeito

    • Foi desenvolvido um sistema que reinicia automaticamente execuções que travaram a partir do checkpoint mais recente
    • O processo de reinício executa health checks em todas as máquinas disponíveis e classifica o estado de saúde das máquinas com base nos checks aprovados
    • Em seguida, o trabalho de treinamento é executado novamente nas máquinas mais saudáveis

  • Resposta automática a componentes de rede

    • Todas as falhas observadas em componentes de rede foram detectadas pelo UFM e registradas no log de eventos do UFM
    • Na prática, os eventos realmente problemáticos eram apenas alguns entre dezenas, e a maioria estava relacionada a queda de link ou alta contagem de symbol error
    • Os scripts fazem parse do log de eventos do UFM para desativar links e portas associados a eventos recentes, criar tickets de manutenção e reativá-los depois que o reparo é concluído

  • Espelho do sistema de arquivos local

    • A velocidade da Ethernet dentro e fora do cluster podia se tornar um gargalo para treinamento distribuído em larga escala
    • Uma conexão Ethernet compartilhada de cerca de 10 Gbit/s saturava rapidamente quando centenas de workers baixavam ao mesmo tempo datasets e checkpoints do modelo
    • A Imbue construiu um sistema de arquivos local dentro do cluster que espelha o armazenamento em nuvem para reduzir a quantidade de arquivos que precisavam ser buscados no S3
    • Para lidar com o churn, em que máquinas são frequentemente desativadas ou substituídas, cada arquivo era replicado 3 vezes
    • Usaram consistent hashing para distribuir a carga de forma equilibrada e minimizar a movimentação de arquivos durante o churn
    • Por causa do espaço limitado em disco, também desenvolveram ferramentas para rastrear o ciclo de vida dos arquivos e excluir os desnecessários

  • Registry Docker distribuído local

    • Para transferência de imagens Docker, usaram Kraken
    • O Kraken é um software open source que permite transferir imagens Docker em peer-to-peer, e a Imbue afirmou que quase não teve problemas com ele

  • Monitoramento de desempenho e identificação de hosts com defeito

    • Configuraram o Torch profiler e o NVIDIA Nsight Systems
    • O Nsight Systems foi útil para entender quanto tempo levavam o forward/backward pass e a comunicação NCCL
    • Isso ajudou a determinar, com base no tamanho do modelo e no número de workers, se o gargalo era de comunicação ou de computação
    • O uso foi um pouco difícil por exigir Docker privileged mode, desativação de checks de segurança relacionados a eventos de monitoramento de desempenho e interrupção do treinamento para salvar os perfis
    • Também criaram ferramentas para detectar batches lentos de treinamento e identificar a causa
      • A ferramenta mais útil monitorava o tempo de cada batch e, quando encontrava um batch anormalmente lento, fazia dump dos stack traces de todos os workers
      • Isso facilitou identificar hosts específicos com problemas sutis de hardware ou software
    • Antes de os health checks estarem maduros o suficiente, mesmo quando o treinamento falhava em um conjunto específico de máquinas, não ficava claro quais delas eram a causa
      • Por exemplo, se um grupo de 48 máquinas falhasse, eles iniciavam execuções menores em 6 grupos de 8 máquinas e em 8 grupos de 6 máquinas
      • As máquinas que apareciam em grupos com falha nas duas etapas eram consideradas, com alto grau de confiança, as máquinas problemáticas

Princípios operacionais obtidos durante a construção

  • Garantir de 10% a 20% mais máquinas do que o necessário para uma execução específica de treinamento facilita reiniciar o processo quando há falha de máquinas
  • Configurar a rede do cluster para que todas as máquinas estejam conectadas de forma próxima permite usar qualquer subconjunto funcional
  • Como as falhas de hardware e software encontradas durante o treinamento voltam a acontecer, vale a pena escrever testes e soluções de automação para cada tipo de falha
  • Para cada mensagem de erro opaca, é útil criar ferramentas mais interpretáveis
  • Para garantir reprodutibilidade, adotaram a regra de mudar apenas uma coisa por vez, mesmo nas alterações mais simples
  • Ao introduzir ferramentas externas ou quando novas pessoas entram no processo, eles revalidavam as premissas, especialmente quando etapas seguintes dependiam dos resultados
  • Todo o processo exigiu muita supervisão e iteração, mas o fator decisivo foi ter controle total da infraestrutura e conseguir depurar problemas em todas as camadas de abstração

Leituras relacionadas

1 comentários

 
GN⁺ 2024-06-29
Comentários do Hacker News
  • Ao longo de alguns meses, uma pequena equipe de pesquisa e engenharia treinou do zero, em sua própria infraestrutura, um modelo de 70 bilhões de parâmetros, e ele superou o GPT-4o zero-shot em tarefas relacionadas a inferência
    Para usar um cluster próprio em treinamento de alto desempenho, todos os componentes — de InfiniBand, Ethernet e GPUs até os nós — precisavam funcionar perfeitamente, e uma única conexão instável entre mais de 12.000 podia desacelerar todo o treinamento
    Eles publicaram scripts open source e um guia de ponta a ponta para configurar a infraestrutura, e isso faz parte de uma trilogia de toolkits para treinar um modelo de 70 bilhões. As ferramentas de avaliação e otimização de hiperparâmetros, CARBS, podem ser vistas aqui: https://imbue.com/research/70b-intro/
    • O nível de detalhe foi realmente ótimo, e acho que foi a primeira vez que vi um texto mostrar de forma tão interna e detalhada o trabalho de engenharia por trás de modelos assim
      Tenho duas curiosidades. Primeiro, queria saber o que mudaria ao treinar um modelo de 400 bilhões de parâmetros. No cluster como um todo, parece haver memória de vídeo suficiente, mas queria saber a avaliação real
      Segundo, queria saber se vocês veem essa arquitetura como a forma final do treinamento de modelos. Ela parece frágil demais; gostaria de saber se existem mecanismos ou arquiteturas melhores de treinamento compartilhado, ou estruturas de cluster melhores
    • Fico curioso para saber o que aconteceu com aquele mundo 3D parecido com Minecraft que a equipe estava criando. Mudaram de direção?
    • A parte de “superou o GPT-4o zero-shot” é interessante. Queria saber se este modelo passou por RLHF também, ou se foi apenas pré-treinado
      Se for o segundo caso, gostaria de entender como ele venceu o GPT-4
    • A frase dizendo que uma única conexão instável entre mais de 12.000 podia desacelerar todo o treinamento é bem peculiar, então pensei: “acho que já vi essa frase antes”
      De fato, essa frase e boa parte do texto parecem ter sido publicados quase palavra por palavra no Twitter, LinkedIn e Reddit. É só spam?
      https://x.com/imbue_ai/status/1805629547473518695
      https://reddit.com/r/learnmachinelearning/comments/1dobgbs/t...
      https://www.linkedin.com/posts/mattboulos_training-a-70b-mod...
  • Se a frase “511 computadores com 4.092 GPUs H100, 8 por computador” estiver correta, entendo certo que só as GPUs passam de US$ 100 milhões?
    Fico curioso para saber quanto disso, e por volta de quando, poderia entrar no território de desenvolvedores hobbyistas com orçamento de PC gamer
    • É interessante gastar US$ 100 milhões em GPUs e ainda estar mexendo em uma caixa Dell com porta Ethernet defeituosa
      Os problemas que eles enfrentaram são divertidos de ouvir
    • Parece que sim. Eles captaram US$ 200 milhões da NVIDIA, então provavelmente foi puramente em forma de GPUs: https://news.crunchbase.com/ai-robotics/new-ai-unicorn-imbue...
    • Se só as GPUs passam de US$ 100 milhões, então a maioria dos leitores que não tem esse nível de financiamento provavelmente deve seguir para o próximo post do HN
  • Muito legal. A Cisco lançou equipamentos em uma nova colaboração com a NVIDIA que oferecem 800G por porta, mas não lembro se era RoCE
    Aqui parece ser uma estrutura em que a GPU consegue acessar InfiniBand, e isso é bonito. É um daqueles textos diretamente úteis
  • O podcast Latent Space também abordou isso alguns dias atrás: https://www.latent.space/p/llm-training-2024
    Foi um bom episódio, e vale a pena ouvir a justificativa por trás dessas decisões
    • Não estou acostumado a esse tipo de entrevista, então senti que estava fora da minha área. Se houver perguntas que eu deveria ter feito e deixei passar, agradeço sugestões
  • Tenho curiosidade sobre o consumo total de energia envolvido em criar o modelo. Queria saber se há números incluindo energia e refrigeração
    Zuckerberg disse em um podcast que está planejando o próximo modelo de 1 GW, o que na prática significa um datacenter ligado a uma usina de médio porte, então isso me deixa ainda mais curioso
  • Texto realmente valioso, aprendi muito lendo. O código open source publicado também é excelente
    Tenho algumas perguntas. Por que montar um cluster próprio, e como foi a experiência de lidar com equipamentos ou switches defeituosos junto ao parceiro de nuvem?
    Além da comunicação all-to-all, o que vocês consideraram mais importante ao escolher a arquitetura do cluster e o que de fato se mostrou mais valioso? Como era a infraestrutura de logging além do fato de ser baseada em Loki? Por que um registro Docker local foi necessário? Vocês usaram outras imagens além de nvidia-container-runtime?
  • Pergunta sincera: por que há tanto hardware de PC misturado aqui?
    Será que não daria para conectar as GPUs a um backend PCI e InfiniBand, ter apenas um controlador de coordenação ARM bem pequeno e fazer tudo se coordenar entre si? Não sei se isso é inércia de projetos anteriores ou falta de mercado para controladores especializados de GPU
    • Se a pergunta é por que pagar a mais por CPU e RAM, a resposta é que nem todo trabalho pode ser feito na GPU. Por exemplo, descompactar .png
      Se você realmente analisar o código de treinamento e fizer bastante pré-processamento dos dados, talvez dê para usar recursos de CPU/RAM bem leves, mas como as GPUs são caras, CPU/RAM representam uma fatia pequena do custo total do sistema, então não é necessariamente preciso gastar tempo de desenvolvimento otimizando isso

Se você for um provedor de nuvem em hiperescala, é bem provável que persiga até essa eficiência de custo de 0.x%. Por exemplo, talvez queira pré-processar .png para .webp (sem perdas, multithread) ou .jpeg (com perdas), mas mudar para um formato que a GPU consiga descomprimir pode reduzir o custo de CPU durante o treinamento, porém aumentar os custos de armazenamento e transferência, então provavelmente não compensa
Mais precisamente, se o trabalho da CPU for o gargalo do treinamento, é preciso otimizar ao máximo com pré-processamento de dados e ajustes no script de treinamento. O ponto aqui é a diferença entre “rápido o suficiente” e “mais rápido”: CPU não é rápida o suficiente para o treinamento < CPU é exatamente rápida o suficiente para o treinamento < CPU é mais rápida do que o necessário para o treinamento

  • Se cada máquina tem US$ 250 mil em GPUs, é tolice se preocupar em economizar alguns milhares de dólares em hardware de controle. O risco de usar uma nova configuração de hardware é grande demais
    Outro problema é que o hardware relacionado a GPUs, os drivers e a experiência operacional estão todos do lado dos PCs. Para rodar em ARM, seria preciso começar praticamente do zero, e também haveria muito trabalho adicional para estabilizar. No fim, paga-se um custo alto para economizar um pouco no processador
  • Manter as GPUs continuamente alimentadas com dados é uma tarefa bastante complicada no treinamento de deep learning
    Não tenho experiência com LLM/NLP, mas, em workloads de imagem e áudio, às vezes é difícil aproveitar totalmente até mesmo GPUs RTX 2/3/4xxx com uma CPU comum de 4 a 8 núcleos. Não é tão difícil a CPU ou a entrada/saída virar gargalo
  • 4.092 GPUs H100 é uma escala grande
    Eles dizem que estão fazendo “self-coding”, e fico curioso se isso é mais próximo de uma solução no-code ou low-code
    O site também tem vários textos que podem ser interessantes: https://imbue.com/our-work/
  • Fico curioso sobre quanto custou. Somando custo de hardware, tempo de desenvolvimento, eletricidade e resfriamento para ir do zero até um arquivo de modelo utilizável, quanto terá sido?
  • Fico curioso se muitos desenvolvedores hobbyistas conseguiriam treinar um modelo juntos de forma distribuída, como no seti@home ou folding@home
    Esses projetos tinham a característica de conseguir dividir o trabalho em pacotes bastante independentes, mas não sei bem se o treinamento de modelos também pode ser dividido assim
    • Provavelmente não vai funcionar muito bem. Deve haver pouquíssimos, ou nenhum, desenvolvedores hobbyistas capazes de garantir 400 Gbps de throughput de rede entre suas GPUs