Antes de escrever código: o que você realmente precisa para treinar um LLM
Treinar um modelo de linguagem do zero não é baixar um script e apertar enter. É um projeto de engenharia com três frentes que você deve resolver antes da primeira linha: dados, computação e avaliação. Segundo a documentação oficial de frameworks como PyTorch e Hugging Face, a maioria dos fracassos em projetos de treinamento não vem do código, mas de um planejamento deficiente do corpus e de uma infraestrutura mal dimensionada.
Este artigo descreve uma configuração passo a passo assumindo que você quer construir um modelo pequeno ou médio (entre 100M e 1.500M de parâmetros) para um domínio específico, não um concorrente dos grandes modelos generalistas. Se o seu objetivo é um modelo de 70B parâmetros com dados multilíngues massivos, o orçamento é medido em milhões de dólares e este tutorial fica aquém: reconheça isso desde o início.
Passo 1: definição do escopo e do orçamento de computação
Antes de escrever o tokenizador, decida o tamanho do modelo em função das GPUs disponíveis. A regra prática usada na indústria relaciona tokens de treinamento com parâmetros: um modelo bem treinado costuma consumir entre 20 e 100 vezes mais tokens que parâmetros. Para um modelo de 125M parâmetros, um corpus de 2.500M a 10.000M de tokens é razoável.
Estimativa de VRAM e tempo
A memória necessária durante o treinamento não depende apenas do tamanho do modelo. Os estados do otimizador AdamW multiplicam por quatro o peso do modelo em precisão mista. Um modelo de 125M parâmetros pode consumir entre 2 e 3 GB apenas em estados do otimizador, mais ativações e gradientes. Em uma GPU de 24 GB você pode treinar modelos de até 300-400M parâmetros com batch pequeno e gradient checkpointing.
Um erro comum que vi em equipes novatas: assumir que uma RTX 4090 de consumo permite treinar um modelo de 1B parâmetros sem técnicas de economia de memória. A realidade é que o treinamento para por OOM (out of memory) nos primeiros passos, e o tempo de depuração supera o de treinamento.
Passo 2: construção e limpeza do corpus
O dataset é o ativo mais valioso e o mais negligenciado. Para um modelo de domínio (jurídico, médico, técnico, atendimento ao cliente), você precisa entre 1.000 e 10.000 milhões de tokens de texto de qualidade. Se você parte do zero, o pipeline de limpeza deve incluir:
- Deduplicação em nível de documento e de parágrafo com MinHash ou SimHash. Sem isso, o modelo memoriza e sofre overfitting a frases repetidas.
- Filtragem de idioma com um classificador leve (fastText funciona bem) para descartar conteúdo que não seja português se esse for o seu domínio.
- Eliminação de boilerplate (menus de navegação, avisos de cookies, footers) que envenenam o sinal de treinamento.
- Controle de qualidade heurístico: proporção de caracteres alfabéticos, comprimento médio de frase, presença de repetições n-grama.
Segundo estudos do setor sobre datasets públicos como C4 e The Pile, entre 40% e 60% do texto bruto é descartado após a limpeza. Planeje o armazenamento em conformidade: um corpus de 10.000M tokens em texto plano ocupa aproximadamente 40 GB.
Passo 3: tokenizador específico do domínio
Não reutilize o tokenizador do GPT-2 ou do Llama se o seu domínio tem vocabulário próprio. Um tokenizador BPE treinado sobre o seu corpus reduz o número de tokens por documento e acelera o treinamento. A configuração com a biblioteca tokenizers do Hugging Face é direta:
from tokenizers import Tokenizer, models, trainers, pre_tokenizers
tokenizer = Tokenizer(models.BPE(unk_token=»[UNK]»))
tokenizer.pre_tokenizer = pre_tokenizers.ByteLevel(add_prefix_space=False)
trainer = trainers.BpeTrainer(vocab_size=32000, special_tokens=[«[PAD]»,»[UNK]»,»[BOS]»,»[EOS]»])
tokenizer.train_from_iterator(corpus_iter, trainer=trainer)
tokenizer.save(«tokenizer_dominio.json»)
Um vocabulário entre 32.000 e 50.000 tokens cobre bem o português geral. Para domínios técnicos com muitos acrônimos, considere 48.000. Verifique a taxa de compressão: se o seu tokenizador gera mais de 1,4 tokens por palavra em média, provavelmente você precisa de mais vocabulário ou de um corpus de treinamento mais representativo.
Passo 4: arquitetura do modelo e configuração inicial
Para um modelo do zero, uma arquitetura decoder-only tipo GPT é o padrão. A configuração deve ser coerente: dimensão oculta (d_model), número de camadas, cabeças de atenção e dimensão de feed-forward. Uma regra que funciona: feed-forward = 4 × d_model, e número de cabeças tal que a dimensão por cabeça seja 64 ou 128.
Exemplo de configuração para um modelo de 125M
{
«vocab_size»: 32000,
«hidden_size»: 768,
«num_hidden_layers»: 12,
«num_attention_heads»: 12,
«intermediate_size»: 3072,
«max_position_embeddings»: 1024,
«hidden_act»: «gelu»,
«dropout»: 0.1
}
Com esta configuração, o modelo tem aproximadamente 125M de parâmetros. Se a sua GPU é de 16 GB, reduza o batch por dispositivo para 8 e use acumulação de gradientes de 4 para um batch efetivo de 32. O learning rate inicial típico é 3e-4 com scheduler cosseno e warmup de 2.000 passos.
Passo 5: loop de treinamento com PyTorch e Accelerate
A configuração mínima viável usa transformers com Trainer ou um loop manual com accelerate. Para controle total, o loop manual é preferível. Os pontos críticos:
- Precisão mista (fp16 ou bf16) com torch.cuda.amp. Em GPUs Ampere ou superiores, bf16 é mais estável.
- Gradient checkpointing ativado se o modelo não cabe na memória.
- Salvamento de checkpoints a cada 500 passos, não a cada época. Em modelos grandes, uma época pode ser inviável.
- Avaliação de perplexidade em um conjunto de validação de 5% do corpus.
Um detalhe que só se aprende com a prática: o loss pode parecer estável, mas a perplexidade de validação divergir se o corpus de validação tem uma distribuição diferente. Certifique-se de que a validação é extraída aleatoriamente do mesmo corpus limpo, não de uma fonte diferente.
Passo 6: avaliação e sinais de alarme
A perplexidade não basta. Você precisa avaliar o modelo em tarefas concretas: geração de texto, classificação ou resposta a perguntas. Para um modelo pequeno, use benchmarks leves como um subconjunto da tarefa de raciocínio ou testes manuais de geração com prompts do seu domínio.
Sinais de que algo vai mal:
- Loss que baixa mas geração incoerente: provavelmente overfitting por duplicados no corpus.
- Perplexidade de validação que sobe após um mínimo: learning rate muito alto ou corpus muito pequeno para o tamanho do modelo.
- Repetições na geração: falta de diversidade no corpus ou tokenizador mal treinado.
Passo 7: ajuste fino e implantação
Um modelo base treinado do zero não responde a instruções. Para uso prático, você precisa de uma fase de instrução ou ajuste fino supervisionado com pares pergunta-resposta do seu domínio. Esta fase é mais leve: entre 10.000 e 100.000 exemplos de qualidade costumam ser suficientes para um modelo pequeno.
A implantação com vLLM ou llama.cpp permite servir o modelo com quantização a 8 ou 4 bits, reduzindo requisitos de VRAM. Um modelo de 125M quantizado a 4 bits ocupa menos de 100 MB e pode rodar em CPU, embora a latência será maior.
Limitações que você deve assumir
Treinar do zero não garante qualidade. Um modelo de 125M treinado com 5.000M de tokens em português terá um conhecimento factual limitado e alucinará com frequência. Não compete com modelos pré-treinados de maior tamanho. Se o seu objetivo é um assistente conversacional geral, o ajuste fino de um modelo existente é mais eficiente em custo e tempo. O treinamento do zero faz sentido quando você precisa de controle total sobre o vocabulário, a licença ou a arquitetura, ou quando você pesquisa dinâmicas de treinamento.
Segundo a documentação oficial do PyTorch e os guias do Hugging Face, o custo de um treinamento de 125M parâmetros com 5.000M de tokens em uma única GPU de 24 GB pode oscilar entre vários dias e uma semana, dependendo do throughput. Não há atalhos: o pipeline de dados consome tanto tempo quanto o treinamento.
Se você decidir avançar, comece com um corpus de 500M tokens e um modelo de 50M parâmetros. Valide o pipeline completo antes de escalar. A experiência demonstra que 80% dos erros aparecem nas primeiras 24 horas de treinamento e são mais fáceis de corrigir com um modelo pequeno.