Scaling laws II: Chinchilla e compute-optimality

1

Conceito

As leis de Kaplan tornaram o planejamento mais previsível, mas sua alocação compute-optimal não foi a palavra final. Em 2022, Hoffmann e colaboradores revisitaram a pergunta com mais experimentos iso-compute e produziram o modelo Chinchilla. O resultado central não foi apenas um checkpoint melhor, mas uma nova resposta para “qual deve ser o tamanho e quantos tokens ele deve ver?”.

Sob budget $C$, um modelo denso enfrenta aproximadamente $C\propto ND$, onde $N$ são parâmetros e $D$ são tokens. Uma curva iso-compute escolhe vários $N$, treina cada um pelo $D$ correspondente e compara validation loss. Modelo grande demais vê pouco dado. Modelo pequeno demais carece de capacidade apesar dos tokens. O fundo da curva estima o melhor equilíbrio.

Repita em vários budgets e ajuste como $N$ e $D$ ótimos crescem. Hoffmann et al. concluíram que, no cenário medido, tamanho e tokens deveriam escalar em taxas aproximadamente iguais com o compute. O resultado representativo comparou Chinchilla com 70 bilhões de parâmetros treinado em 1,4 trilhão de tokens ao Gopher de 280 bilhões treinado em 300 bilhões; os números são do artigo de 2022. Chinchilla usou o mesmo compute declarado e superou Gopher na suíte reportada.

A correção conceitual foi undertraining. Um parâmetro recebe pressão útil por muitos contextos variados. Construir mais parâmetros e privá-los de dados pode ser pior que treinar uma rede menor por mais tempo. Após Chinchilla, “tokens por parâmetro” virou atalho comum, embora uma razão única não capture qualidade, arquitetura ou regimes de loss.

Compute-optimality depende do custo otimizado. A pergunta central de Chinchilla é budget fixo de pretraining e loss. Se um modelo atender bilhões de requisições, um modelo menor treinado mais tempo talvez custe mais no treino e muito menos na operação. Se dados são escassos, tokens duplicados não equivalem a informação nova. Se latency impõe largura ou profundidade, o conjunto viável muda.

Reproduzir o método exige mais que ajustar uma linha a checkpoints públicos. Receitas precisam ser tunadas entre tamanhos; caso contrário, um modelo pequeno com learning rate ruim parece fraco artificialmente. Definições de tokens e parâmetros devem ser consistentes. Runs precisam atingir seus budgets sem divergence. O validation set deve estar held-out e deduplicado.

Um gráfico interativo deveria mostrar famílias de curvas em U, não apenas a linha final. Mover à direita aumenta parâmetros e reduz tokens sob compute fixo. O mínimo identifica o equilíbrio. Conectar os mínimos gera a regra ajustada e deixa claro que a conclusão é empírica.

A lição de Chinchilla é metodológica. Uma recomendação famosa muda quando cobertura experimental e fitting melhoram. Planeje a run grande com pilotos controlados, exponha incerteza e refaça os ajustes quando pipeline ou arquitetura mudar.

O takeaway durável é que “modelo maior” e “mais treinamento” disputam o mesmo compute. Compute-optimality encontra equilíbrio para um objetivo declarado. Ela não decide a economia total do deployment, que adiciona inference demand na próxima aula.