Scaling laws III: inference-aware e over-training

01 · Conceito

Conceito

A otimalidade de compute de treino pergunta como obter a menor loss de um orçamento fixo de pretraining. Um modelo implantado tem uma vida muito mais longa do que essa pergunta imagina. O treino acontece uma vez. A inferência acontece para cada prompt e cada token gerado, em cada réplica, enquanto o checkpoint for servido. Se a demanda for grande, a conta recorrente faz a conta única parecer minúscula, e o alvo da otimização precisa incluir as duas.

O enquadramento padrão escreve o custo de vida como

com $R$ o volume esperado de inferência e $L$ capturando comprimentos de prompt e de saída. Sardana e colaboradores modificaram a análise no estilo Chinchilla exatamente nessas linhas, treinaram modelos em razões altas de token por parâmetro para validar o comportamento e reportaram que uma demanda de inferência suficientemente grande desloca a solução preferida na direção de modelos menores treinados em mais dados. O ponto de cruzamento deles é condicional aos seus custos, ajustes e suposições de workload — mas a direção é estrutural, não incidental.

Essa é a versão de inference-aware scaling que todo mundo cita, e ela trata $N$ como a única alavanca: escolha menos parâmetros, alimente mais tokens, aceite uma conta de treino maior em troca de um forward pass mais barato para sempre. A lição 5.5 percorreu essa aritmética. Ela é real, e é metade da história.

A metade que é pulada é que $C_{infer}$ não é função apenas da contagem de parâmetros. Com 27 bilhões de parâmetros fixos você pode construir arquiteturas cujos custos de serving diferem por mais de uma ordem de magnitude, porque uma requisição servida paga por três coisas: ler os pesos, computar as camadas e guardar o estado por requisição. Só a primeira escala limpo com $N$. A terceira — o KV cache — depende inteiramente de decisões sobre heads e tipos de camada, e é onde a arquitetura publicada do Qwen3.8-27B torna mensuráveis suas consequências de serving.

A lição 7.2 assume a aritmética do KV cache deste modelo, portanto esta lição usa seu resultado em vez de derivar um segundo orçamento. O contrafactual relevante mantém head dimension e contagem de camadas, mas troca quatro KV heads por 24 e troca 16 camadas de attention com cache por 64. A GQA reduz a contagem de KV heads por fator seis; o layout híbrido 3

A mesma distinção vale para o restante do projeto. Só 16 camadas mantêm cache que cresce com o comprimento da sequência, e os pesos lançados estão em bf16. Tamanho quantizado, contexto utilizável, throughput e fit total no acelerador dependem do runtime e do orçamento de memória exatos; a arquitetura sozinha não estabelece um alvo de workstation nem a intenção da equipe.

Honestidade sobre o que é e o que não é conhecido importa aqui tanto quanto em qualquer ponto desta track. Os fatos arquiteturais acima são verificáveis no model card e no config. O raciocínio atribuído a eles é inferência a partir do projeto, não uma justificativa publicada — não existe relatório técnico deste modelo, e o time nunca declarou suas suposições de serving, orçamento de tokens ou modelo de custo. O que se pode afirmar com confiança é que a arquitetura lançada reduz estado crescente por sequência em relação ao contrafactual declarado. Interpretar esse efeito como objetivo da equipe é plausível, mas continua sendo inferência.

As ressalvas usuais continuam valendo. Previsões de $R$ erram com frequência nas duas direções, então reporte sensibilidade ao longo de cenários de demanda em vez de uma estimativa pontual. Loss de validação equivalente não garante qualidade equivalente sob latência, factualidade, comportamento multilíngue ou responsividade a post-training. A disponibilidade de dados restringe a alavanca de over-training: tokens únicos extras de alta qualidade podem simplesmente não existir, e repetir dados muda o objetivo efetivo e eleva o risco de memorização. A cadência de atualização também importa — um checkpoint substituído no mês que vem acumula muito menos inferência de vida útil do que um servido por anos.

O princípio duradouro é otimizar a vida do sistema em vez de uma única run. O Chinchilla pergunta como gastar um orçamento de pretraining. Inference-aware scaling pergunta o que deve existir depois do treino, dado quão frequentemente será usado — e a resposta é expressa em tokens, em parâmetros e, o que é mais consequente, no formato das próprias camadas.