Pré-treinamento e Leis de Escalonamento

Visão geral

Pré-treinamento (pretraining) é a etapa em que um modelo aprende representações de uso geral a partir de grandes conjuntos de dados, em sua maioria não rotulados — tipicamente prevendo tokens ausentes ou o próximo token. Para os modelos de linguagem grandes (large language models, LLMs) modernos, o pré-treinamento geralmente é a predição do próximo token auto-supervisionada (self-supervised next-token prediction) em trilhões de tokens usando uma Arquitetura Transformer.

Leis de escalonamento (scaling laws) são relações empíricas (e parcialmente motivadas teoricamente) que descrevem como o desempenho do modelo muda à medida que você escala:

Tamanho do modelo (número de parâmetros, N)
Dados (número de tokens de treinamento, D)
Computação (compute) (FLOPs de treinamento, C)

Elas são poderosas porque tornam o progresso dos LLMs previsível: para uma determinada arquitetura e receita de treinamento (training recipe), muitas vezes é possível prever melhorias de perda/qualidade com mais computação, mais dados ou um modelo maior — antes de treinar o sistema completo.

Este artigo explica:

o que o pré-treinamento está otimizando,
como são as leis de escalonamento,
o que elas preveem,
e como elas são usadas na prática para escolher o tamanho do modelo e do conjunto de dados sob um orçamento de computação.

Pré-treinamento em uma equação

A maior parte do pré-treinamento de LLMs minimiza a perda de entropia cruzada (cross-entropy loss) em sequências de tokens. Dados tokens (x_1, \dots, x_T), um modelo de linguagem autorregressivo aprende:

[ \min_{\theta} \ \mathbb{E}{x \sim \mathcal{D}} \left[ \sum{t=1}^{T} -\log p_{\theta}(x_t \mid x_{<t}) \right] ]

Pontos-chave:

A perda é frequentemente reportada como log-verossimilhança negativa (negative log-likelihood) ou entropia cruzada por token (per-token cross-entropy).
Perplexidade (perplexity) é ( \exp(\text{loss}) ). Quanto menor, melhor.
Melhorias na perda de pré-treinamento tendem a se transferir para muitas tarefas downstream (downstream tasks) (embora não de forma uniforme).

O pré-treinamento normalmente é seguido por alinhamento (alignment) ou ajuste por instruções (instruction tuning) (veja ajuste fino (fine-tuning) em Ajuste Fino, Alinhamento e métodos de otimização por preferência (preference optimization methods) em Métodos de Otimização por Preferência), mas as leis de escalonamento se aplicam de forma mais direta à fase de pré-treinamento, em que o objetivo é estável e bem definido.

O que “escalonar” significa: parâmetros, dados, computação

Tamanho do modelo (N)

Para Transformers densos, N é o número de parâmetros aprendidos (por exemplo, 7B, 70B).

Escalonar N geralmente melhora:

capacidade de representação,
aprendizado de padrões em contexto (in-context learning) (Aprendizado em Contexto),
e a perda — desde que você também escale dados e computação de forma apropriada.

Dados (D)

D é o número de tokens de treinamento vistos (às vezes “tokens únicos”, às vezes “atualizações de token”, dependendo de você repetir ou não os dados).

Escalonar D ajuda a reduzir:

sobreajuste (overfitting),
pressão de memorização (memorization pressure),
e regimes de treinamento limitados por dados (data-limited), em que o modelo é grande, mas subtreinado.

A qualidade dos dados importa: as leis de escalonamento frequentemente tratam tokens como intercambiáveis, mas na prática “um token” de código de alta qualidade ou texto didático pode valer muitos tokens de fontes ruidosas.

Computação (C)

A computação é frequentemente aproximada como o total de FLOPs de treinamento. Uma regra prática (rule of thumb) comum para Transformers densos é:

[ C \approx 6ND ]

Isso vem do custo aproximado das passagens forward+backward (forward+backward passes) por token, agregado entre camadas. A constante varia por arquitetura, tamanho de sequência, implementação de atenção, checkpointing de ativações, etc., mas é útil para orçamentação.

A ideia central das leis de escalonamento

Em muitos experimentos, pesquisadores observaram que a perda diminui como uma lei de potência (power law) com a escala (ao longo de faixas amplas):

Mais parâmetros → menor perda, como (N^{-\alpha})
Mais dados → menor perda, como (D^{-\beta})
Mais computação → menor perda, como (C^{-\gamma})

Uma forma funcional comum é:

[ L(N, D) \approx L_{\infty} + aN^{-\alpha} + bD^{-\beta} ]

Onde:

(L_{\infty}) é um piso de perda irredutível (irreducible loss floor) para a distribuição de dados (e classe de modelos).
(\alpha, \beta) são expoentes empíricos (frequentemente pequenos; as melhorias são constantes, mas com retornos decrescentes).

O que “lei de potência” implica na prática?

Leis de potência significam retornos decrescentes suaves e previsíveis:

Dobrar a computação não dobra o desempenho.
Cada aumento de 10× na computação produz uma redução incremental semelhante na perda (em um gráfico log-log (log-log plot), fica próximo de uma linha reta).

Essa é uma das razões pelas quais o desenvolvimento de modelos de fronteira (frontier model) frequentemente parece “escala + polimento”: se sua pilha de treinamento está estável, você consegue prever o quanto uma execução maior será melhor.

Treinamento ótimo em computação: como gastar um orçamento fixo

Uma questão prática crucial é:

Se eu tenho um orçamento de computação fixo C, devo treinar um modelo maior em menos tokens ou um modelo menor em mais tokens?

Resultados iniciais (notadamente, leis de escalonamento no estilo Kaplan (Kaplan-style)) sugeriam que muitos modelos grandes estavam subtreinados (poucos tokens por parâmetro). Trabalhos posteriores (frequentemente associados a resultados ótimos em computação no estilo Chinchilla (Chinchilla-style)) argumentaram que, para Transformers densos, a estratégia ótima em computação usa mais dados por parâmetro do que muitas execuções anteriores.

A regra prática de “tokens por parâmetro”

Uma heurística amplamente citada em análises ótimas em computação para LLMs densos é:

Treinar com ~20 tokens por parâmetro (ordem de grandeza; varia por conjunto de dados e modelo)

Então:

1B params → ~20B tokens
10B params → ~200B tokens
70B params → ~1.4T tokens

Isso não é uma lei da natureza; é um “centro” prático derivado sob certas suposições (arquitetura, otimizador (optimizer), distribuição dos dados, etc.). Mas captura um ponto-chave: para um orçamento de computação fixo, pode ser melhor treinar modelos menores por mais tempo do que tornar o modelo enorme e parar cedo.

Um exemplo prático de dimensionamento ótimo em computação

Assuma:

Orçamento de computação (C = 1 \times 10^{23}) FLOPs
Computação aproximada de treinamento (C \approx 6ND)
Razão ótima em computação (D \approx 20N)

Então:

[ C \approx 6N(20N) = 120N^2 \Rightarrow N \approx \sqrt{\frac{C}{120}} ]

[ N \approx \sqrt{\frac{10^{23}}{120}} \approx 9.1 \times 10^{10} \ (\text{cerca de } 91B\ \text{parâmetros}) ] [ D \approx 20N \approx 1.8 \times 10^{12}\ \text{tokens} ]

Assim, com 1e23 FLOPs, um plano aproximadamente ótimo em computação pode ser **90B parâmetros treinados em ~1,8T tokens**, assumindo que a regra prática se aplica.

Aqui vai um pequeno trecho de código que faz essa estimativa:

import math

C = 1e23          # FLOPs budget
k = 6.0           # FLOPs per parameter-token (rough for dense Transformers)
ratio = 20.0      # tokens per parameter (rule of thumb)

# C ≈ k * N * D and D ≈ ratio * N  =>  C ≈ k * ratio * N^2
N = math.sqrt(C / (k * ratio))
D = ratio * N

print(f"Compute budget: {C:.2e} FLOPs")
print(f"Compute-optimal params N: {N/1e9:.1f}B")
print(f"Compute-optimal tokens D: {D/1e12:.2f}T")

No planejamento real, você ajustaria:

o fator constante (depende do tamanho de sequência e da implementação),
se você repetirá tokens (épocas (epochs)) ou usará majoritariamente tokens únicos,
e a qualidade dos dados (tokens efetivos (effective tokens)).

O que as leis de escalonamento preveem (e o que não preveem)

Previsões que funcionam bem

1) Perda de pré-treinamento vs. escala

Para uma configuração fixa (família de arquitetura + otimizador + pipeline de dados (data pipeline)), as leis de escalonamento frequentemente preveem a perda de treinamento/validação com uma precisão surpreendente ao longo de várias ordens de magnitude.

Isso é usado para:

estimar o quanto uma execução 10× será melhor,
decidir se uma execução está “na curva de escalonamento” ou com desempenho abaixo do esperado (bug/instabilidade/problema de dados),
e planejar tamanhos de modelo para um orçamento de computação.

2) Alocação ótima em computação

As leis de escalonamento ajudam a responder:

“Devemos comprar mais GPUs ou coletar mais dados?”
“Se os dados são limitados, ainda vale a pena escalar parâmetros?”
“Em que ponto mais dados deixam de ajudar a menos que aumentemos o tamanho do modelo?”

3) Muitas métricas downstream correlacionam com a perda

Uma perda de pré-treinamento menor frequentemente se correlaciona com:

maior acurácia em benchmarks de compreensão de linguagem,
melhor desempenho few-shot (few-shot performance),
geração de código aprimorada (veja Modelos de Código),

…mas com ressalvas: algumas capacidades melhoram mais rápido do que a perda, outras mais devagar, e incompatibilidades de conjunto de dados/domínio podem quebrar correlações.

Coisas que as leis de escalonamento preveem com menos confiabilidade

1) “Habilidades emergentes”

Alguns benchmarks mostram transições abruptas — habilidades que parecem surgir repentinamente com a escala. Uma interpretação é que a melhoria subjacente é suave, mas a métrica tem limiar (thresholded metric) (por exemplo, sai de 0% para >0% quando a acurácia cruza um ponto de virada).

Às vezes, as leis de escalonamento conseguem prever quando uma transição pode ocorrer, mas isso é menos confiável do que prever perda.

2) Segurança, factualidade e alucinações

Menor perda não garante:

menos alucinações (hallucinations) (Alucinações),
melhor calibração (calibration),
comportamento mais seguro sem treinamento direcionado (Mitigações de Segurança).

Escalonar muda os modos de falha: modelos podem ficar mais persuasivos e fluentes, o que pode aumentar a superfície de risco (risk surface) mesmo que a factualidade média melhore.

3) Desempenho de contexto longo

Aumentar o comprimento de contexto (context length) altera a arquitetura/codificações posicionais (position encodings) e os padrões de computação (veja Janelas de Contexto). O escalonamento de perda com N, D, C não diz diretamente como o desempenho escala com comprimento de contexto, recuperação (retrieval) ou mecanismos de memória (memory mechanisms).

4) Uso de ferramentas e comportamento agentivo

O uso de ferramentas (tool use) depende fortemente de dados de treinamento, suporte (scaffolding) e pós-treinamento (post-training) (veja LLMs que Usam Ferramentas). Escalonar o pré-treinamento ajuda, mas não é a história toda.

Por que essas leis de potência aparecem (intuição)

Embora as leis de escalonamento sejam principalmente empíricas, há intuições consistentes com teoria de aprendizado e aproximação:

Modelos maiores reduzem o erro de aproximação (approximation error) (eles podem representar mais funções).
Mais dados reduzem o erro de estimação (estimation error) (melhor generalização).
Melhorias de otimização reduzem a ineficiência de treinamento (training inefficiency) (aproximando-se mais da melhor perda atingível para um dado N e D).

À medida que você escala, frequentemente passa por regimes:

Limitado por computação (compute-limited): não dá para treinar por tempo suficiente ou com tamanho suficiente.
Limitado por dados (data-limited): o modelo é grande, mas repete dados; pressão de sobreajuste/memorização cresce.
Limitado por modelo (model-limited): muitos dados e computação, mas a capacidade da arquitetura vira o gargalo.

O treinamento ótimo em computação tenta equilibrar esses fatores para que você não desperdice computação no regime de gargalo “errado”.

Fluxo de trabalho prático: usando leis de escalonamento em projetos reais

As leis de escalonamento são mais úteis quando você as trata como uma ferramenta de engenharia:

1) Fixe uma receita de treinamento

Para ajustar curvas de escalonamento confiáveis, mantenha consistentes:

família de modelos (por exemplo, Transformer denso),
tokenizador (tokenizer) (Tokenização),
otimizador e cronograma de taxa de aprendizado (learning rate schedule),
pipeline de dados e filtragem (filtering),
e protocolo de avaliação (evaluation protocol).

Se você mudar coisas demais ao mesmo tempo, a curva se desloca e a extrapolação deixa de funcionar.

2) Execute uma varredura de modelos menores

Treine múltiplos tamanhos (por exemplo, 100M, 300M, 1B, 3B) com diferentes orçamentos de tokens.

Colete:

perda de validação (validation loss) na convergência (convergence),
computação gasta,
e métricas de estabilidade (stability metrics) (divergência (divergence), normas de gradiente (gradient norms), etc.).

3) Ajuste uma lei de potência e extrapole

Você pode ajustar uma curva da forma:

(L(C) = L_{\infty} + kC^{-\gamma}) (escalonamento por computação), ou
(L(N, D) = L_{\infty} + aN^{-\alpha} + bD^{-\beta})

Então, você pode responder:

“Que perda devemos esperar com 10× computação?”
“É melhor dobrar dados ou dobrar parâmetros?”

4) Valide extrapolações com uma execução de escala intermediária

Antes de se comprometer com uma execução de fronteira, faça uma execução intermediária de verificação de sanidade (sanity check) para confirmar que você ainda está na curva. Isso detecta problemas como:

mudanças no pipeline de dados,
bugs silenciosos em precisão mista (mixed precision),
ou ineficiências de treinamento distribuído (distributed training).

Escalonamento além de modelos densos: esparsidade e outras mudanças

Muitos sistemas modernos usam variantes que complicam o simples (C \approx 6ND):

Modelos de Mistura de Especialistas (Mixture-of-Experts, MoE) ativam apenas um subconjunto de parâmetros por token, mudando a troca entre computação e capacidade.
Mudanças arquiteturais (variantes de atenção (attention variants), recorrência (recurrence), modelos de espaço de estados (state space models)) alteram constantes e, às vezes, expoentes.
Misturas de dados (mais código, mais matemática, multilíngue) mudam a “dificuldade efetiva” da distribuição e podem deslocar (L_{\infty}).

As leis de escalonamento ainda podem se aplicar, mas, em geral, é preciso reajustá-las para o novo regime em vez de reutilizar coeficientes de Transformers densos.

Interações com escalonamento no tempo de inferência

O escalonamento em tempo de treinamento (pré-treinamento) é apenas metade da história. Aumentar a computação em tempo de teste (test-time compute) — por exemplo, via amostrar (sampling) mais candidatos, reordenação (reranking), busca (search) ou “pensar por mais tempo” (thinking longer) — pode melhorar resultados sem mudar parâmetros (veja Computação em Tempo de Teste).

Distinção importante:

Leis de escalonamento de pré-treinamento: como a capacidade muda quando você gasta mais computação antes do deployment.
Escalonamento em tempo de teste: como a capacidade muda quando você gasta mais computação por consulta.

Na prática, sistemas frequentemente combinam ambos:

treinam um bom modelo base,
depois gastam computação extra de inferência para tarefas difíceis (raciocínio, código, planejamento).

Armadilhas comuns e modos de falha

Superinterpretar saltos em benchmarks

Uma melhoria súbita em um benchmark pode ser:

contaminação do conjunto de dados (dataset contamination),
artefatos de avaliação (evaluation artifacts),
ou uma métrica com limiar.

Use conjuntos separados (held-out sets) limpos e verifique correlações com a perda.

Ignorar qualidade e duplicação de dados

Dois conjuntos de dados com a mesma contagem de tokens podem produzir resultados diferentes dependendo de:

desduplicação (deduplication),
filtragem de qualidade de documentos,
aderência de domínio (domain match) às tarefas-alvo,
e presença de conteúdo sintético (synthetic content) ou repetitivo.

Leis de escalonamento frequentemente tratam tokens como homogêneos; pipelines reais precisam acompanhar “tokens efetivos”.

Usar o modelo de computação errado

A estimativa de FLOPs depende de:

tamanho de sequência (sequence length),
implementação de atenção,
recomputação de ativações (activation recomputation),
e utilização de hardware (hardware utilization).

Um plano baseado em (C \approx 6ND) pode errar por um fator de 2–5+ no custo de tempo real (wall-clock cost) se você ignorar detalhes de sistemas.

Mudar botões demais de uma vez

Curvas de escalonamento são mais estáveis quando você escala um eixo por vez sob uma receita consistente. Mudanças grandes (novo tokenizador, nova arquitetura, nova mistura de dados) significam que você deve reestimar o escalonamento.

Resumo

Pré-treinamento otimiza a predição do próximo token em escala massiva; é onde a maior parte da capacidade geral é aprendida.
Leis de escalonamento descrevem melhorias previsíveis de lei de potência na perda à medida que você aumenta parâmetros (N), dados (D) e computação (C).
Para Transformers densos, um modelo aproximado de computação (C \approx 6ND) permite orçamentação prática.
Treinamento ótimo em computação equilibra tamanho do modelo e dados; orientações modernas frequentemente favorecem treinar por mais tempo em mais tokens em vez de tornar o modelo enorme e subtreinado (por exemplo, na ordem de ~20 tokens/parâmetro como heurística grosseira).
Leis de escalonamento são excelentes para prever perda e orientar alocação de recursos, mas menos confiáveis para segurança, alucinações, uso de ferramentas e alguns comportamentos “emergentes”.

Se você quiser se aprofundar a seguir, bons tópicos complementares são Ajuste Fino (adaptação pós-treinamento), Computação em Tempo de Teste (escalonamento na inferência) e Janelas de Contexto (trocas em contexto longo).