Scaling laws II: Chinchilla e compute-optimality

01 · Conceito

Conceito

Um colega vê que o Qwen3.8-27B tem 27 bilhões de parâmetros, lembra da famosa regra dos “vinte tokens por parâmetro”, multiplica e anuncia que o modelo foi treinado em cerca de 540 bilhões de tokens. É uma inferência natural, a aritmética está certa, e a conclusão não é sustentada pela evidência publicada. Entender por quê exige saber exatamente o que o Chinchilla mediu, o que ele otimizou e o que mudou desde então.

Leis no estilo Kaplan tornaram o planejamento previsível, mas sua alocação compute-optimal não foi a palavra final. Em 2022, Hoffmann e colaboradores revisitaram a questão com um conjunto mais amplo de experimentos iso-compute e produziram o modelo chamado Chinchilla. A saída interessante não foi um checkpoint. Foi uma resposta diferente para “quão grande o modelo deve ser, e quantos tokens ele deve ver?”.

Para um orçamento de treino fixo $C$, um modelo denso enfrenta a restrição aproximada $C\propto ND$, com $N$ parâmetros e $D$ tokens. Uma curva iso-compute fixa $C$, escolhe vários valores de $N$, treina cada um pelo $D$ correspondente e compara a loss de validação. Um modelo grande demais passa fome de dados; um pequeno demais carece de capacidade apesar de tokens abundantes. O fundo dessa curva em U é o melhor equilíbrio naquele orçamento. Repita ao longo de vários orçamentos, ajuste como o $N$ e o $D$ ótimos crescem juntos, e você tem uma regra. Hoffmann et al. concluíram que, no cenário que mediram, parâmetros e tokens deveriam escalar a taxas aproximadamente iguais. A comparação de destaque deles treinou um Chinchilla de 70 bilhões de parâmetros em 1,4 trilhão de tokens contra o maior Gopher de 280 bilhões de parâmetros em 300 bilhões de tokens, no mesmo compute de treino declarado, e o Chinchilla venceu na suíte reportada. Essa razão, 1,4 trilhão sobre 70 bilhões, é de onde vem o “cerca de vinte tokens por parâmetro”.

Agora faça a aritmética que seu colega fez, mas com cuidado. A vinte tokens por parâmetro, um modelo denso de 27 bilhões de parâmetros seria treinado em

e o compute de treino, usando a estimativa $6ND$ da lição 5.4, seria

Esse é um número real e uma âncora útil: ele diz a ordem de magnitude de uma run compute-optimal de 27B. Também é inteiramente uma construção nossa. Nenhuma contagem de tokens, número de compute ou orçamento de treino é publicado para o Qwen3.8-27B. Não existe relatório técnico; o model card documenta arquitetura, licença, presets de amostragem e benchmarks reportados pelo fornecedor. Então trate 8,75e22 FLOPs como “o que um 27B Chinchilla-optimal teria custado”, nunca como “o que este modelo custou”.

Dois refinamentos antes de seguir. O $N$ nesses ajustes é de parâmetros não-embedding, e a lição 5.3 mostrou que cerca de 2,54 bilhões dos parâmetros deste modelo vivem no embedding e na output head untied, com mais na vision tower — então uma aplicação estrita usaria algo mais próximo de 24 bilhões e encolheria a estimativa em torno de 10%. E o $6ND$ foi calibrado em stacks uniformes de attention, ao passo que 48 das 64 camadas deste modelo são Gated DeltaNet. As duas correções apontam na mesma direção: estes são números de planejamento em ordem de magnitude, e citá-los com três algarismos significativos é falsa precisão.

A correção conceitual que o Chinchilla entregou foi o subtreinamento. Um parâmetro ganha seu sustento através de muitos contextos variados de tokens; construir mais parâmetros enquanto se deixa cada um faminto de dados é pior do que treinar uma rede menor por mais tempo. Depois de 2022, “tokens por parâmetro” virou atalho de planejamento — mas uma única razão não consegue capturar qualidade de dados, arquitetura ou um regime de loss deslocado.

Esse algo é a implantação. A pergunta do Chinchilla termina no instante em que o treino para. Se um modelo vai servir bilhões de requisições, um modelo menor treinado por mais tempo custa mais uma vez e menos para sempre. Empurre nosso 27B para além do ponto compute-optimal até uns ilustrativos 150 tokens por parâmetro — de novo, suposição nossa, não um fato publicado — e o orçamento vira

aproximadamente 7,5 vezes o orçamento Chinchilla-optimal para a mesma contagem de parâmetros. De um ponto de vista só de treino, isso é desperdício. De um ponto de vista de serving, é uma compra: esses tokens extras empurram um modelo de 27 bilhões de parâmetros na direção de uma qualidade que de outro modo teria exigido um muito maior, e o modelo menor então lê 54 GB de pesos por forward pass em vez de várias centenas, para cada token de cada requisição, pela vida inteira da implantação. A lição 5.6 transforma essa troca num objetivo explícito e examina separadamente as consequências de serving da arquitetura publicada do Qwen3.8-27B, sem afirmar que a equipe o treinou sob essa justificativa de orçamento de tokens.

A lição metodológica sobrevive aos números. Uma recomendação famosa de scaling mudou porque a cobertura experimental e o ajuste melhoraram, e ela vai mudar de novo. Planeje uma run grande a partir de evidência piloto controlada, anexe incerteza, reajuste quando o pipeline ou a arquitetura se mover — e lembre que compute-optimality responde à pergunta que lhe foi feita. “Modelo maior” e “mais treino” competem pelo mesmo orçamento de treino. Nenhum dos dois decide a economia de vida útil de um sistema implantado, que é para onde esta track vai a seguir.