Leis de Escalonamento

Visão geral

Leis de escalonamento (scaling laws) são regularidades empíricas que relacionam o desempenho de um modelo a “variáveis de escala (scale variables)” como:

• Tamanho do modelo (número de parâmetros, profundidade/largura ou capacidade efetiva (effective capacity))
• Tamanho do conjunto de dados (número de tokens/exemplos, diversidade)
• Computação de treinamento (training compute) (FLOPs, tempo de treinamento, orçamento de hardware)
• Às vezes: configurações do otimizador (optimizer settings), tamanho do lote (batch size), comprimento de contexto (context length) ou computação em tempo de inferência (inference-time compute)

No aprendizado profundo (deep learning) moderno — especialmente em modelos de linguagem de grande porte (large language models, LLMs) baseados na Arquitetura Transformer — leis de escalonamento frequentemente assumem a forma de leis de potência suaves (smooth power laws): à medida que você aumenta a escala, a perda (loss) diminui de modo previsível em um gráfico log-log. Isso tem sido útil para previsão, orçamentação e desenho de execuções de treinamento ótimas em computação (compute-optimal).

Ao mesmo tempo, leis de escalonamento não são leis universais da natureza. Elas descrevem comportamento em regimes específicos (escolhas de dados/modelo/computação, receita de treinamento fixa, distribuição de avaliação fixa). Elas podem falhar quando essas suposições mudam — por exemplo, quando a qualidade dos dados se altera, os objetivos de treinamento mudam (ajuste por instruções (instruction tuning), aprendizado por reforço com feedback humano (reinforcement learning from human feedback, RLHF)), as arquiteturas mudam, ou você atinge pisos de erro irredutível.

Este artigo explica o que leis de escalonamento predizem, por que elas frequentemente se parecem com leis de potência, como praticantes as usam e onde elas falham.

O que leis de escalonamento predizem (na prática)

Prevendo perda de treinamento e perplexidade

O alvo mais comum e confiável para leis de escalonamento é a perda de entropia cruzada (cross-entropy loss) (ou, de forma equivalente, a perplexidade (perplexity)) em uma amostra reservada da mesma distribuição dos dados de treinamento.

Empiricamente, para muitas famílias de modelos treinadas com uma receita consistente, a perda de teste frequentemente segue:

[ L(N) \approx L_{\infty} + a , N^{-\alpha} ]

onde:

• (N) é a contagem de parâmetros (ou outra medida de tamanho do modelo),
• (L_{\infty}) é um piso assintótico de perda (às vezes omitido se não for observado),
• (a) é uma constante,
• (\alpha > 0) é o expoente de escalonamento (frequentemente “pequeno”, por exemplo, ~0.05–0.1 para algumas configurações de modelos de linguagem de grande porte).

De forma semelhante, mantendo o tamanho do modelo fixo e escalonando os tokens do conjunto de dados (D):

[ L(D) \approx L_{\infty} + b , D^{-\beta} ]

E se você tratar a computação (C) como o recurso primário:

[ L(C) \approx L_{\infty} + k , C^{-\gamma} ]

Essas leis normalmente não são derivadas a partir de primeiros princípios; elas são ajustadas a partir de experimentos. Ainda assim, elas se sustentaram repetidamente ao longo de várias ordens de magnitude em computação para determinadas tarefas e receitas.

Prevendo trade-offs ótimos em computação (tamanho do modelo vs dados)

Uma questão prática central é: dado um orçamento de computação, você deve treinar um modelo maior com menos tokens, ou um modelo menor com mais tokens?

Trabalhos nessa área popularizaram regras de escalonamento “ótimas em computação”. Um resultado comum é:

• Existe uma alocação ótima de computação entre aumentar parâmetros e aumentar dados.
• Treinar um modelo grande demais com poucos tokens leva a modelos subtreinados (undertrained) (eles poderiam ter melhorado mais com mais dados).
• Treinar um modelo pequeno demais com muitos tokens leva a modelos limitados por capacidade (eles saturam cedo).

Uma atualização amplamente citada (frequentemente associada à “optimalidade em computação ao estilo Chinchilla”) é que muitos modelos históricos de linguagem de grande porte eram grandes demais para seus orçamentos de tokens, e que, para um orçamento fixo de computação, mais tokens + modelo menor pode vencer em perda.

Prevendo desempenho downstream (com ressalvas)

As pessoas frequentemente querem leis de escalonamento para métricas de tarefa como:

• acurácia em benchmarks,
• pass@k de programação,
• recuperação em contexto longo,
• pontuações de “raciocínio” (ver Raciocínio),
• tarefas multimodais (ver Modelos de Base Multimodais).

Às vezes, essas métricas se correlacionam com a perda e podem ser previstas de forma aproximada. Mas métricas downstream são menos estáveis porque:

• benchmarks saturam ou são ruidosos,
• pequenos deslocamentos de distribuição podem mudar os resultados,
• o uso de prompts (prompting) / formatação de instruções importa,
• protocolos de avaliação mudam ao longo do tempo.

Na prática, leis de escalonamento são mais confiáveis para perda em distribuição, e menos confiáveis quanto mais você caminha em direção a capacidades de alto nível.

Por que leis de escalonamento parecem leis de potência?

Não existe uma derivação única aceita, mas algumas intuições reaparecem:

1. Misturas de dificuldade / caudas longas
   Dados naturais contêm muitos “padrões raros”. À medida que os modelos escalam, eles capturam mais da cauda, mas cada incremento adicional é mais difícil — consistente com retornos decrescentes.

2. Trade-offs de aproximação + estimação
   O erro de generalização pode ser visto como uma combinação de limites de aproximação (capacidade do modelo) e limites de estimação (dados finitos). Sob certas suposições, ambos podem produzir comportamento semelhante a leis de potência.

3. Autossimilaridade entre escalas
   Se a dinâmica de aprendizado e a distribuição de dados forem “semelhantes” conforme você escala (mesma família de arquitetura, tokenização similar, mesmo objetivo), o comportamento agregado pode parecer invariável à escala em gráficos log-log.

Essas são intuições, não garantias. A regularidade empírica marcante é o que torna leis de escalonamento valiosas apesar de uma teoria imperfeita.

Um exemplo prático: ajustando uma lei de escalonamento

Um fluxo de trabalho comum é:

1. Treinar vários modelos em escalas diferentes com uma receita fixa.
2. Medir a perda de validação.
3. Ajustar uma lei de potência no espaço logarítmico.
4. Extrapolar com cautela para escalas planejadas.

Aqui está um exemplo mínimo de ajuste de (L(N) \approx c + aN^{-\alpha}) usando uma busca em grade (grid search) simples sobre (c) e regressão linear (linear regression) no espaço logarítmico (ilustrativo, não pronto para produção):

import numpy as np

# Example measurements (replace with real runs)
N = np.array([1e8, 3e8, 1e9, 3e9, 1e10])          # parameters
L = np.array([2.90, 2.65, 2.45, 2.33, 2.25])      # validation loss

def fit_power_law_with_floor(N, L, c_grid):
    best = None
    for c in c_grid:
        y = L - c
        if np.any(y <= 0):
            continue
        X = np.log(N)
        Y = np.log(y)
        # Fit Y = log(a) - alpha*log(N)
        A = np.vstack([np.ones_like(X), -X]).T
        coef, *_ = np.linalg.lstsq(A, Y, rcond=None)
        loga, alpha = coef[0], coef[1]
        a = np.exp(loga)
        # Compute RMSE in original space
        pred = c + a * N**(-alpha)
        rmse = np.sqrt(np.mean((pred - L)**2))
        if best is None or rmse < best["rmse"]:
            best = {"c": c, "a": a, "alpha": alpha, "rmse": rmse}
    return best

c_grid = np.linspace(1.5, 2.2, 50)
fit = fit_power_law_with_floor(N, L, c_grid)
print(fit)

Dicas práticas:

• Ajuste usando um conjunto de avaliação (eval set) consistente (mesmo tokenizador (tokenizer), mesma distribuição).
• Espere erro sistemático se seus maiores modelos mudarem a dinâmica de treinamento (tamanhos de lote diferentes, ajustes no otimizador).
• Prefira extrapolar um pequeno número de “dobragens” além das escalas observadas.

Como leis de escalonamento são usadas em projetos reais

Orçamentação e planejamento

Leis de escalonamento permitem que equipes estimem:

• “Se eu tiver 5× mais computação, quanto a perda vai melhorar?”
• “Devo gastar orçamento em mais tokens ou mais parâmetros?”
• “De quantas execuções eu preciso para reduzir risco de uma execução de treinamento de ponta (frontier run) cara?”

Isso ajuda a alocar recursos antes de se comprometer com execuções de treinamento de vários milhões de dólares.

Comparando receitas de treinamento e melhorias algorítmicas

Se você ajustar curvas de escalonamento para duas receitas (mesma família de arquitetura, truques de treinamento diferentes), você pode comparar:

• Mudanças no expoente (melhoria mais rápida com escala),
• Deslocamentos por fator constante (constant-factor shifts) (mesma inclinação (slope), mas perda uniformemente menor),
• Pisos diferentes (uma receita satura mais tarde).

Essa é uma forma prática de quantificar melhorias vindas de melhor curadoria de dados, mudanças no otimizador ou regularização (regularization) — semelhante em espírito a ablações controladas (controlled ablations) na prática de treinamento de Redes Neurais.

Detectando subtreinamento ou gargalos de dados

Se a perda de um modelo é pior do que a prevista por uma curva de escalonamento baseada em computação, causas comuns incluem:

• passos de treinamento insuficientes (parou cedo),
• tokens demais poucos (gargalo de dados),
• instabilidade (divergência, taxa de aprendizado (learning rate) alta demais),
• desalinhamento entre treinamento e inferência (por exemplo, a avaliação usa contextos mais longos do que os usados no treinamento).

Curvas de escalonamento podem sinalizar esses problemas cedo.

Onde leis de escalonamento falham

Leis de escalonamento são melhor vistas como modelos empíricos locais. Elas falham quando você sai do regime em que foram medidas.

1) Mudança de distribuição: desalinhamento entre treino e teste

A maioria das leis de escalonamento “limpas” assume que sua avaliação vem da mesma distribuição do treinamento (ou ao menos foi pré-processada de forma similar).

A falha ocorre quando:

• você avalia em um domínio diferente (por exemplo, texto jurídico vs texto da web),
• você muda o formato do prompt ou o estilo de instrução,
• você passa para avaliações adversariais ou resistentes a contaminação,
• você mede robustez (robustness) ou calibração (calibration) em vez de perda.

O escalonamento de perda pode ainda se manter no conjunto de validação original enquanto o comportamento downstream muda dramaticamente sob deslocamento.

2) Mudando o objetivo de treinamento (pré-treinamento vs ajuste por instruções vs RLHF)

Leis de escalonamento normalmente são ajustadas para o pré-treinamento (pretraining) de previsão do próximo token (next-token prediction). Mas muitos sistemas implantados passam por:

• ajuste por instruções / ajuste fino supervisionado (supervised fine-tuning),
• otimização por preferência (preference optimization) (por exemplo, métodos ao estilo RLHF),
• treinamento para uso de ferramentas (tool-use training), ciclos de dados sintéticos (synthetic data loops).

Essas etapas podem produzir saltos de capacidade não suaves ou regressões em algumas métricas. Uma curva de perda de pré-treinamento pode não prever:

• métricas de utilidade (helpfulness) ou inocuidade (harmlessness) (ver Pesquisa de Alinhamento),
• comportamento de recusa (refusal behavior),
• conformidade de estilo (style compliance),
• taxas de alucinação (hallucination rates).

Em resumo: leis de escalonamento para perda de pré-treinamento não se transferem automaticamente para comportamento pós-treinamento.

3) Qualidade dos dados e contagem efetiva de tokens

Uma variável oculta chave é a qualidade dos dados. Dois conjuntos de dados com o mesmo número de tokens podem se comportar como se tivessem tamanhos “efetivos” muito diferentes.

Modos de falha comuns:

• escalar tokens adicionando dados de baixa qualidade ou repetitivos rende menos melhoria do que o previsto,
• filtrar demais pode reduzir diversidade e prejudicar a generalização na cauda (tail generalization),
• misturas multilíngues ou multimodais podem alterar a relação entre tokens e perda.

Essa é uma razão pela qual “contagem de tokens” é uma medida imperfeita; o escalonamento pode ser mais estável quando medido contra computação efetiva em dados de alta qualidade.

4) Descontinuidades arquiteturais ou algorítmicas

Leis de escalonamento frequentemente assumem uma família de arquitetura fixa e um regime de otimizador fixo. Mas melhorias como:

• variantes de atenção (attention variants),
• codificações posicionais (positional encodings) melhores,
• roteamento de mistura de especialistas (mixture-of-experts routing),
• tokenização (tokenization) diferente,
• aumento com recuperação (retrieval augmentation),
• otimizadores ou cronogramas (schedules) melhores

podem deslocar curvas de formas que tornam ajustes antigos enganosos.

Por exemplo, passar de Transformers densos (dense transformers) para mistura de especialistas pode alterar o mapeamento entre “contagem de parâmetros” e “capacidade efetiva”, complicando comparações.

5) Pisos finitos e erro irredutível

Leis de potência podem parecer válidas até atingirem:

• erro de Bayes (Bayes error) / incerteza irredutível nos dados,
• pisos de ruído de avaliação,
• ambiguidade por contexto incompleto,
• ruído de rótulo (label noise) (para tarefas supervisionadas),
• efeitos de truncamento (truncation effects) (comprimento de contexto).

Quando um piso domina, escalonamento adicional rende melhorias decrescentes que podem parecer “falha” (a curva entorta ou satura).

6) Habilidades emergentes e limiares de métricas

Alguns comportamentos parecem “aparecer de repente” em determinada escala — frequentemente discutidos como habilidades emergentes (emergent abilities) (ver Habilidades Emergentes). Uma nuance importante:

• Uma melhoria suave na perda pode se traduzir em uma mudança abrupta em uma métrica com limiar (thresholded metric), por exemplo, aprovado/reprovado em um item de benchmark ou atingir um comprimento mínimo de cadeia de raciocínio.
• Pequenas melhorias podem empurrar o desempenho acima de um limiar, criando a impressão de descontinuidade.

Assim, a “falha” pode estar na métrica, e não na previsibilidade subjacente da perda.

7) Instabilidades de otimização e treinamento em escala

À medida que a escala aumenta, manter a “mesma receita” é difícil. Instabilidades podem surgir de:

• limites de escalonamento do tamanho de lote,
• incompatibilidades de cronograma de taxa de aprendizado,
• problemas numéricos de hardware,
• mudanças no ruído de gradiente (gradient noise),
• hiperparâmetros (hyperparameters) do otimizador que não se transferem.

Se sua maior execução treina em um regime diferente, o ajuste de lei de escalonamento feito em execuções menores pode falhar — não porque leis de escalonamento sejam falsas, mas porque você mudou as condições.

8) Escalonamento em tempo de inferência e computação em tempo de teste

Sistemas modernos podem escalar a computação em tempo de inferência (mais amostragem (sampling), reordenação (reranking), busca em árvore (tree search), chamadas de ferramenta (tool calls)), o que muda desempenho sem alterar a perda de treinamento. Exemplos incluem:

• amostragem best-of-N (best-of-N sampling) para programação,
• deliberação (deliberation) ou planejamento em múltiplas etapas (multi-step planning),
• raciocínio aumentado por ferramentas (tool-augmented reasoning).

Isso é especialmente relevante para Raciocínio: estratégias em tempo de teste podem produzir mudanças em degrau que não seguem curvas de escalonamento do pré-treinamento.

Orientação prática: usando leis de escalonamento sem se enganar

Trate leis de escalonamento como previsões condicionais

Um bom modelo mental é:

“Dada esta arquitetura, este pipeline de dados, este otimizador/cronograma, este comprimento de contexto e esta distribuição de avaliação, o desempenho vai melhorar como X.”

Mude as condições, e você precisa reajustar.

Use múltiplos eixos: parâmetros, tokens, computação

Se você ajustar apenas “perda vs parâmetros”, pode deixar passar que seus modelos estão limitados por dados. Uma abordagem mais robusta:

• rodar uma grade de pares ((N, D)),
• medir superfícies de perda (loss surfaces),
• identificar se você está em um regime limitado por dados (data-limited) ou limitado por modelo (model-limited).

Valide extrapolações com checkpoints de escala intermediária

Em vez de extrapolar diretamente de pequeno para enorme:

• extrapole para um modelo de escala intermediária,
• treine-o,
• atualize o ajuste,
• então extrapole mais.

Isso reduz o risco quando as curvas entortam.

Não exagere afirmações sobre capacidades de alto nível

O escalonamento de perda é útil, mas não especifica completamente:

• robustez,
• factualidade/alucinações,
• propriedades de interpretabilidade (ver Pesquisa em Interpretabilidade),
• comportamentos de segurança.

Para isso, você frequentemente precisa de avaliações dedicadas e, às vezes, de variáveis de escalonamento totalmente diferentes.

Leis de escalonamento no quadro mais amplo de “fronteiras”

Leis de escalonamento ficam na interseção entre:

• previsibilidade de engenharia (orçamentação e planejamento),
• questões científicas sobre por que o aprendizado profundo generaliza,
• previsão de capacidades e debate sobre descontinuidades,
• discussões de segurança e governança sobre como capacidades crescem com investimento.

Elas também se conectam a pesquisas sobre:

• Modelos de Mundo: à medida que modelos escalam, eles constroem estrutura latente mais coerente?
• Habilidades Emergentes: saltos aparentes são reais ou artefatos de métricas?
• Pesquisa de Alinhamento: comportamentos relevantes para segurança escalam de modo suave, e sob quais regimes de treinamento?

Principais conclusões

• Leis de escalonamento predizem de forma mais confiável a perda de pré-treinamento em distribuição em função de tamanho do modelo, dados e computação, frequentemente por meio de relações de lei de potência (power-law).
• Elas são valiosas na prática para orçamentação de computação, desenho de treinamento ótimo em computação e diagnóstico de gargalos.
• Elas falham (ou parecem falhar) quando você muda distribuições, objetivos, qualidade de dados, arquiteturas, regimes de otimização, ou quando você mede comportamentos com limiar ou pós-treinamento.
• O uso mais seguro de leis de escalonamento é previsão condicional com validação frequente, não afirmações incondicionais sobre “inteligência” ou desempenho amplo no mundo real.

Se você quiser, posso adicionar uma seção curta com desenhos concretos de experimentos em estilo “receituário” (quantos tamanhos de modelo/tokens amostrar, como escolher faixas e como reportar incerteza) sob medida para pré-treinamento de modelos de linguagem de grande porte ou treinamento multimodal.