Treinar LLMs do zero como uma startup

Artigo original ↗ Discussão no Hacker News ↗

Treinar grandes modelos de linguagem do zero em escala de startup levanta questões difíceis sobre infraestrutura, confiabilidade de hardware e escolhas de framework, especialmente quando contrastado com os sistemas de TPU e as ferramentas internas fortemente integradas do Google. Os comentaristas debatem se usar GPUs, JAX ou PyTorch muda de forma significativa a confiabilidade e a velocidade de iteração, e quanto do progresso atual depende de experiência de elite, capital vasto e pipelines de dados opacos. Muitos veem um cenário em que várias equipes bem financiadas duplicam modelos próximos do estado da arte com diferenciação modesta — via alinhamento, qualidade de dados ou produtos de nicho — enquanto investidores lutam para distinguir valor duradouro de hype.

Contexto e Visão Geral

  • A thread discute um post de blog sobre treinar LLMs de fronteira a partir do zero em uma startup, depois de sair de uma grande empresa de tecnologia.
  • Os comentaristas se interessam pelo contraste de estar “na selva”: fazer trabalho com LLMs grandes sem a infraestrutura interna de hyperscaler e sem TPUs.

Frameworks, Hardware e Confiabilidade

  • Debate sobre JAX vs PyTorch:
    • Alguns veem o JAX como bom para pesquisa e otimização em TPU; outros dizem que o PyTorch é melhor para prototipagem rápida e ecossistema.
    • O TensorFlow é amplamente visto como atrasado ou “legado”.
  • Experiências mistas com a confiabilidade de GPU vs TPU:
    • Alguns relatam falhas frequentes de TPU e depuração dolorosa; outros relatam experiências sólidas com JAX+TPU.
    • Anedotas sobre confiabilidade de GPU divergem: setups pequenos com T4 são vistos como extremamente confiáveis, enquanto clusters grandes com A100/H100 são descritos como propensos a falhas.
  • Uma visão: as diferenças de confiabilidade podem estar mais ligadas à maturidade do datacenter e ao gerenciamento de hardware do que aos chips em si.

Google vs Código e Infra de Não-Google

  • Vários descrevem o código interno do Google como de alta qualidade, altamente padronizado e apoiado por ferramentas e CI fortes.
  • Tradeoff: melhor manutenibilidade, mas velocidade menor e uma infraestrutura de ML/LLM complexa e frágil, difícil de aprender e depurar.
  • Alguns ex-insiders recentes afirmam que a infraestrutura de LLM do Google, em particular, é confusa e lenta para iterar em comparação com outros laboratórios.

Economia e Redundância das Startups de LLM

  • Muitos veem startups de treino de modelos de base como fazendo trabalho semelhante com hardware e dados semelhantes, criando uma redundância massiva e intensiva em energia.
  • Visão cética: muitas têm pouco “molho secreto” e buscam בעיקר mostrar que conseguem treinar modelos próximos do estado da arte, esperando aquisição.
  • Outros argumentam que essa redundância é como os mercados impulsionam a inovação, apesar do enorme desperdício.
  • Há consenso de que levantar dinheiro para esse tipo de startup é mais fácil para pessoas com histórico e redes de elite, criando um fosso baseado em pedigree.

Alinhamento, Censura e Comportamento do Modelo

  • Discussão sobre o que diferencia os modelos: dados, fine-tuning, alinhamento/censura.
  • Uma definição de alinhamento: fazer os modelos seguirem padrões de interação desejados (por exemplo, comportamento de perguntas e respostas), não apenas continuação bruta de tokens.
  • O uso mais recente se concentra em restrições morais/políticas e em evitar saídas “embaraçosas”.
  • Alguns veem isso como controle de produto necessário e prática para uma segurança mais crítica; outros veem como um “campo de distorção da realidade” e potencialmente orwelliano.

Qualidade do Produto e Diferenciação

  • O produto público de chat da startup parece uma interface típica no estilo ChatGPT, com preço comparável ao de modelos fechados de faixa intermediária.
  • A comparação informal de um comentarista entre vários modelos grandes conclui que o modelo da startup é aproximadamente comparável em qualidade, sem ser claramente melhor ou pior.
  • Questiona-se qual o orçamento exato de compute necessário para alcançar desempenho semelhante ao do GPT-3.5; especula-se uma ordem de grandeza (milhões de dólares), mas sem resposta.

Dados de Treinamento e Preocupações de GIGO

  • Várias pessoas querem mais detalhes sobre os pipelines de dados de treinamento, rotulagem e curadoria; o post é visto como superficial nesse ponto.
  • Uma perspectiva enfatiza “garbage in, garbage out”: a qualidade e a estrutura dos dados são cruciais, especialmente em domínios como detecção de malware ou medicina.
  • Sugere-se que algumas startups podem estar investindo silenciosamente pesadamente em dados curados e bem rotulados como um verdadeiro diferencial, mesmo que as histórias sobre compute dominem os pitches para investidores.

Pontos Operacionais e Miscellâneos

  • Trabalhos em grande escala precisam tolerar falhas frequentes de hardware; checkpointing e software robusto são necessidades implícitas.
  • Observa-se que alguns setups de carregamento de dados (por exemplo, 20GB de JSON levando 6 horas) são altamente subótimos; sugerem-se parsers mais rápidos e abordagens de streaming.
  • Pequenos debates paralelos cobrem CLIs de cloud baseadas em Python, runtimes empacotados, tamanho de binário e se “ground zero” é o idiomatismo certo no título.