Treinando LLMs do zero em uma startup
(yitay.net)- Ao construir do zero a infraestrutura de treinamento de modelos de linguagem e multimodais em larga escala, a Reka descobriu que o maior gargalo não era conseguir compute, mas sim a variação na qualidade dos clusters e a instabilidade operacional
- Mesmo com as mesmas GPUs H100, dependendo do provedor e do cluster, problemas como falhas de nó, cabeamento, erros de GPU, gargalos de I/O e de sistema de arquivos, exclusão de checkpoints e atrasos de entrega se acumulavam, criando uma espécie de loteria de hardware
- Ao contrário da experiência com TPUs e infraestrutura interna do Google, em ambientes externos com GPU havia grandes diferenças em treinamento multinó, cabeamento e qualidade do suporte, fazendo com que o MFU e o tempo de inatividade variassem muito entre clusters
- Foi preciso lidar com vários clusters, movimentação de grandes volumes de dados e limitações de codebases externas, e a Reka migrou para uma base em PyTorch enquanto construía por conta própria monitoramento, checkpoints eficientes e um sistema de arquivos customizado
- Com compute limitado, em vez do escalonamento sistemático típico das Big Techs, a equipe precisou confiar em poucos experimentos curtos e contidos e em Yolo runs, e assim conseguiu criar o Reka Flash 21B e um modelo edge 7B
Construindo infraestrutura de treinamento do zero
- A Reka, ao treinar modelos de linguagem multimodais fortes, construiu do zero a infraestrutura necessária para treinar modelos de linguagem e multimodais em larga escala
- A dificuldade central não era escolher entre TPU e GPU, mas garantir qualidade operacional suficiente para manter o treinamento rodando de forma estável em infraestrutura e ambientes de código externos
A loteria de hardware na era dos LLMs
- A primeira condição para treinar modelos é obter compute, mas na prática a maior variável era a diferença de qualidade entre provedores, clusters e conectividade entre aceleradores
- Mesmo usando a mesma GPU H100, a qualidade geral do cluster variava muito, e aqui “hardware” se aproximava mais da qualidade do cluster como um todo do que do chip em si
- A Reka alugou clusters de centenas a milhares de chips de vários provedores de compute, e o estado deles variava de relativamente administrável até falhas a cada poucas horas
- Alguns clusters tinham nós falhando em intervalos curtos por problemas de cabeamento ou erros de hardware da GPU
- Até clusters do mesmo provedor diferiam bastante em robustez
- Mesmo com nós estáveis, se I/O e sistema de arquivos fossem ruins, salvar checkpoints podia expirar por timeout ou derrubar fortemente a utilização do cluster
- Algumas fontes de compute exigiam uma camada de software completamente diferente para execução, o que adicionava custo de migração para equipes com codebase própria
- Era difícil saber de antemão que hardware seria recebido, quão robusta seria a experiência e quanta tolerância a falhas haveria
- Quando um provedor não entregava no prazo, isso podia causar atrasos de meses, e outros fornecedores também podiam ficar semanas ou meses sem conseguir suprir a demanda
- Alguns provedores chegaram a apagar checkpoints por engano
Ferramentas internas para MFU e resposta a falhas
- O Model Flop Utilisation (MFU) variava entre clusters, e quando apareciam nós cabeados incorretamente ou problemas do provedor, uma quantidade relevante de compute era desperdiçada
- Em ambientes com sistema de arquivos muito ineficiente, bastava alguém iniciar uma grande transferência de dados entre clusters para o MFU de um treinamento despencar
- O nível de suporte dos provedores também variava muito
- Ia de atendimento educado até respostas indiferentes
- Em alguns casos, havia respostas padronizadas “estilo ChatGPT” ou tentativas de culpar o usuário por todos os problemas
- Cada cluster tinha suas próprias dores e modos de falha, a ponto de parecer que cada um exigia hotfixes separados
- Para criar ambientes utilizáveis, a Reka desenvolveu várias ferramentas internas
- Ferramentas de monitoramento
- Checkpoints eficientes
- Várias otimizações
- Instalação de um sistema de arquivos customizado para armazenamento de dados escalável
- Esse conjunto de ferramentas reduziu o tempo de inatividade e melhorou de forma significativa o MFU mesmo em hardware ruim
A diferença entre a experiência com GPU e TPU
- A Reka treinou a maior parte de seus modelos em GPUs
- Em comparação com a experiência anterior no Google, onde TPUs eram usadas principalmente para treinar grandes modelos de linguagem, CUDA e
nccleram um ambiente pouco familiar - A taxa de falhas em GPUs era muito diferente da experiência com TPUs no Google
- O UL2 20B do Google ficou rodando por um mês por engano sem falhar
- Em um ambiente com GPU, a expectativa era de que teria falhado nos primeiros dias
- Ainda assim, essa diferença pode estar mais relacionada à capacidade da equipe de hardware que gerencia os aceleradores e à qualidade do suporte do provedor do que ao chip em si
- O treinamento multinó em ambientes com GPU não parecia algo concebido como conceito de primeira classe, como em um TPU pod, mas sim algo acoplado depois
- O modo de cabeamento que viabilizava treinamento multinó também parecia variar entre provedores, aumentando a discrepância entre locais
O peso de operar múltiplos clusters
- A infraestrutura interna do Google era um ambiente acessível de qualquer lugar sobre Borg, Xmanager e Colossus
- Em ambientes externos, era preciso configurar manualmente novos ambientes em vários clusters, algo muito diferente da experiência anterior
- A menos que se construa diretamente um grande pool de aceleradores em um único local, parece inevitável usar pools de aceleradores espalhados por vários clusters
- A escassez de GPUs naturalmente transforma a aquisição em clusters distribuídos
- O treinamento de modelos grandes exige dados na casa de dezenas de TB, o que faz da própria movimentação de dados um grande fardo
- Em escalas muito grandes, replicar dados também não é simples e custa caro
- O formato ideal seria uma camada de orquestração para despachar jobs a vários servidores, mas é difícil para uma startup nova e enxuta ter logo no início uma infraestrutura de treinamento de ML tão sofisticada
- A Reka mitigou esses problemas com vários workflows internos e segue avançando em direção a uma infraestrutura de experimentação de classe mundial
- Segundo o relato, esse tipo de arranjo improvisado é bastante comum fora do grupo de elite ou das grandes empresas
Codebases externas e a escolha por PyTorch
- As codebases preferidas eram T5X e Mesh Tensorflow, mas elas não eram opções realistas na Reka
- Têm pouco suporte fora do Google
- Estão até certo ponto em estado deprecated
- Não são amigáveis para pessoas da equipe sem histórico no Google
- A Reka escolheu PyTorch por parecer mais próximo do vanilla, mais estável e mais amplamente usado
- No começo, foi preciso se adaptar a ambientes externos de desenvolvimento como
pip,gitedocker - Também é possível que usar codebases do Google de forma estável e amigável fora da empresa fosse difícil
- A qualidade das codebases externas pareceu ficar bem atrás das codebases às quais a equipe estava acostumada no Google
- A percepção era de que codebases internas do Google muitas vezes haviam sido escritas diretamente por pesquisadores de ML como Noam Shazeer, Barret Zoph, Adam Roberts e Hyung Won Chung
- Em alguns códigos feitos por outras empresas, a qualidade era especialmente frustrante
- Em algumas codebases, foi necessário escrever conversores separados para mudar a configuração de paralelismo do modelo, em vez de isso ser oferecido automaticamente
- Também havia pouco suporte para treinamento encoder-decoder em grande escala ou para treinamento prefixLM
- Segundo o relato, o flash attention continuou sem oferecer suporte a treinamento prefixLM, isto é, máscaras customizadas, apesar de haver demanda razoável registrada em issues do GitHub
- Havia a percepção de que seria preciso usar Jax, mas para se mover rápido em uma startup a escolha foi PyTorch
Compute limitado e Yolo runs
- O escalonamento sistemático de modelos normalmente segue várias etapas, como 1B → 8B → 64B → 300B, executando experimentos em modelos menores antes de ampliar os vencedores
- Em uma startup, havia muito menos compute disponível para fazer grandes varreduras de hiperparâmetros
- A Reka dependeu bastante de Yolo runs, e na avaliação da equipe isso acabou funcionando bem
- Com apenas um pequeno número de experimentos menores e curtos de ablação, conseguiram chegar ao forte Reka Flash 21B, a um modelo edge 7B e ao maior modelo core ainda previsto
- É difícil encontrar uma boa receita com poucas execuções, e o espaço de busca é tão grande que muitas variáveis precisam mudar ao mesmo tempo
- Em vez da sistematização típica das Big Techs, foi necessário confiar muito em Yolo, feeling e intuição
- A intuição acumulada pela equipe em experiências anteriores com ML ajudou a acertar com poucas tentativas
- Mesmo que alguém já tenha treinado bons modelos em empregos anteriores, diferenças na infraestrutura de treinamento, nos dados, na integração de novas ideias e nos problemas do ambiente podem alterar bastante os resultados
- Uma experiência prévia forte reduziu bastante o espaço de busca e pode ser uma das explicações mais simples para terem conseguido treinar modelos fortes com poucas tentativas, poucos recursos e poucos experimentos
Resultados em menos de um ano e desafios restantes
- A falta de compute e a oferta instável de compute criaram dificuldades muito maiores do que o esperado
- A Reka fundou a empresa, levantou capital, comprou chips e construiu tudo do zero
- Em menos de um ano, afirma ter alcançado nível comparável ao Gemini Pro/GPT-3.5 e superado vários outros modelos
- Tópicos como pipeline de dados e avaliação humana ainda ficam para discussões futuras
1 comentários
Comentários do Hacker News
Nesse contexto, uma startup acaba parecendo uma organização com poucas pessoas e muito dinheiro para gastar em um cluster de treinamento
O texto parte do pressuposto de que há vários provedores de aluguel de servidores e que esses servidores vão para várias startups ou empresas já estabelecidas
No fim, vários criadores de LLM fazem basicamente a mesma coisa, treinando texto e imagens com hardware parecido e dados parecidos, e cada um tenta se diferenciar com seu “molho secreto”
Esse molho secreto pode fazer diferença na qualidade da saída de um LLM, mas, no conjunto, parece uma enorme duplicação de trabalho que consome muita energia
No fim, só uma porcentagem muito pequena terá ao menos algum sucesso razoável, mas esse é o custo a pagar na fronteira do progresso
Um monopólio planejado até poderia ser mais eficiente, mas é raro uma estrutura dessas vencer o mercado em inovação
Os fundadores parecem esperar ser adquiridos simplesmente porque conseguem treinar um LLM “quase no estado da arte”, e esse nível de capacidade e infraestrutura talvez tenha valor suficiente para construir algo em cima
Só que essa história é muito mais difícil de explicar a investidores
Na prática, imagino que muitas startups estejam contratando escritores e fotógrafos para criar dados de treinamento não contaminados e muito bem rotulados
Olhando para o lado do civitai, dá para ver até onde é possível chegar com um orçamento pequeno de computação usando apenas rotulagem densa
A maioria dos casos de uso de LLM pode ser sustentada com ajuste fino de modelos-base prontos
Se você treina um modelo-base do zero, está entrando em um mercado difícil de monetizar, e basta um grande player lançar um novo modelo-base para fazer mais de 95% do que o seu modelo faz
Pelo contexto, Yi Tay foi tech lead do Google PaLM, UL2, Flan, Bard etc., e agora é cofundador da Reka
A Reka lançou alguns modelos multimodais pequenos e interessantes que já apareceram por aqui
Pedi que ele escrevesse este texto porque ele vem do Google e agora está na posição de treinar LLMs em uma startup independente: https://twitter.com/YiTayML/status/1765105066263052718
A gravação da conversa está aqui: https://sub.thursdai.news/p/thursdai-feb-15-2024-openai-chan...
Foi por este texto que conheci a reka.ai, e parece que os LLMs da Reka ainda não foram muito discutidos no HN [1]
Por curiosidade, na última hora testei prompts pela interface de chat [2], comparando com ChatGPT 4, Gemini Advanced, Claude 3 e Mistral Large, e publiquei os resultados em [3]
No geral, o Reka Flash não parece nem muito pior nem muito melhor que os outros modelos
Claro que seriam necessários muito mais testes para ter certeza
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://chat.reka.ai/chat
[3] https://gally.net/temp/20240307llmcomparison.html
Vale apontar que o autor simplesmente parte do pressuposto de que os leitores entendem “selva” como qualquer lugar que não seja o Google
O texto dá muito crédito à infraestrutura e às equipes de hardware do Google, e eu também gostaria de ler a perspectiva de alguém que esteve lá dentro e depois trabalhou com isso em outro lugar
Mais precisamente, é algo como: “passei toda a minha carreira dentro do Google usando TPUs do Google e estava acostumado aos padrões de falha delas, mas não conhecia nada dos padrões de falha de GPUs”
Quando eu vinha principalmente de GPUs e experimentei TPUs, os jobs continuavam falhando por motivos difíceis de depurar
Por causa da camada indireta entre chips x86 e dispositivos TPU, eu muitas vezes passava horas arrancando os cabelos, com tipos de problema que não encontrava em x86+NVIDIA+PyTorch
Há 10 a 15 anos, o Google produziu muitos cientistas de dados que valiam mais de US$ 10 milhões — os engenheiros de Sawzall — e, quando eles também saíram para a “selva”, tiveram reações parecidas
Este texto parece mais voltado a promover a empresa e a marca pessoal do autor do que a deixar um registro útil para a comunidade
Na minha experiência, nunca tive falhas de GPU nem mesmo em treinamento em grande escala
Meu job de treinamento atual usa um arquivo JSON de 20 GB que leva 6 horas só para carregar, está rodando há mais de 15 dias sem problemas e usa uma Tesla T4 mais antiga
GPUs têm problemas de restrição de memória, mas, se você consegue planejar e contornar isso, na prática nunca vi crash
Parece uma metáfora bem clara, e uma startup fazendo projetos de infraestrutura em grande escala precisa construir sua própria logística, como se estivesse montando acampamento no meio do mato
Parece a cena em que Seven of Nine se separa do Collective e percebe que precisa depender das capacidades humanas insignificantes
Os insights sobre fornecedores foram úteis
Imagino que não se perca todo o progresso do treinamento; então a dor está principalmente em diagnosticar o problema e reiniciar o cluster, e não é preciso se preocupar com perda de dados?
Mas qual é exatamente o produto que eles vendem?
A página inicial da Reka.AI parece um clone comum do ChatGPT em que você paga por token
Não sei o que a diferencia de outras empresas, e o preço também parece parecido com o do ChatGPT 3.5-Turbo
O problema de treinar LLMs do zero é um tema muito importante, com impacto tão grande na velocidade e na amplitude das iterações em IA quanto as melhorias brutas de hardware
O texto é interessante, mas um pouco superficial; se você já lidou de alguma forma com clusters de GPU por alguns anos, não é tecnicamente profundo nem surpreendente
A perspectiva de ex-Googlers foi boa, mas não entendi bem por que antigos colegas recomendaram JAX em vez de PyTorch para fazer LLM fora do Google
Seria bom se essa startup publicasse mais tarde um relatório mais técnico sobre sua jornada de treinamento. Por exemplo, algo como este PDF: https://github.com/facebookresearch/metaseq/tree/main/projec...
Provavelmente também há um viés do Google misturado nisso
A grande pergunta é como uma startup pequena sem o background e o pedigree certos consegue levantar capital com um produto de LLM
O mundo das startups de LLM está ficando parecido com o mundo dos hedge funds e do private equity
Os pré-requisitos para investimento seed e captação parecem ser A) carreira de elite e pedigree correto, B) uma rede sólida de investidores pronta para entrar antes mesmo de o produto começar
Provavelmente é também por isso que os VCs investem nesse tipo de empresa
Há pouquíssimas pessoas no mundo com a experiência certa para levantar esse tipo de capital, e só quem consegue levantar capital consegue acumular essa experiência, então surge uma barreira de entrada natural
Pelo menos parece que será assim até o custo de computação ficar barato o suficiente
Ao ler o trecho “fundamos a empresa, levantamos dinheiro, compramos chips e, em menos de um ano, construímos tudo do zero, igualando Gemini Pro/GPT 3.5 e superando muitos modelos”, fico curioso sobre o tamanho do orçamento gasto em chips ou GPUs em nuvem para chegar ao nível de um LLM como o GPT 3.5
Será que foi algo na ordem de US$ 2 milhões a US$ 5 milhões, mesmo que aproximado?
Acho que o título deveria ser “from the ground up” em vez de “ground zero”: https://en.wikipedia.org/wiki/Hypocenter
Como expressão idiomática, é um uso totalmente aceitável
Talvez queira dizer que os LLMs são uma bomba nuclear metafórica para a indústria de tecnologia, mas, sinceramente, eu também fiquei confuso
Eu não gostaria de aprender com um autor desse tipo
Os sistemas do Google são estáveis porque o Google investiu dezenas de bilhões de dólares ao longo de 25 anos no desenvolvimento de hardware, software e processos de datacenter
Mesmo equipes muito competentes em organizações menores e menos maduras inevitavelmente vão produzir resultados de qualidade muito inferior
Outro ponto a considerar são as prioridades
O Google prioriza estabilidade e aposenta componentes que falham repetidamente, mesmo que as falhas sejam relativamente raras
Datacenters menores e menos sofisticados continuam usando peças que falham com frequência, ou nem sequer monitoram a taxa de falha de componentes específicos
Datacenters pequenos também podem comprar e usar peças antigas do Google e componentes menos confiáveis
Portanto, o fato de as máquinas serem instáveis não diz muito sobre a competência da equipe de hardware
Se a baixa confiabilidade do hardware está atrasando o trabalho, basta melhorar o software para tolerar hardware instável ou mudar para um fornecedor de hardware mais estável e mais caro