Scaling laws III: inference-aware e over-training

1

Conceito

Training-compute optimality pergunta como obter a menor loss de um budget de pretraining. Um modelo implantado tem vida mais longa. Treinamento ocorre uma vez; inference acontece para todo prompt e token gerado. Se a demanda for grande, o custo recorrente domina a conta única. O objetivo deveria incluir ambos.

Suponha dois modelos com qualidade semelhante. A é maior e treinado com menos tokens. B é menor e treinado por mais tempo. A análise training-only pode preferir A porque os últimos dados de B são relativamente ineficientes durante pretraining. Uma análise de ciclo de vida pode preferir B porque cada forward futuro toca menos parâmetros e requer menos memory bandwidth.

Isso recebe o nome de over-training apenas em relação a um ótimo de training compute, como um ponto Chinchilla fitted. Não significa treinar além de toda aprendizagem útil ou overfit. Os tokens adicionais compram um modelo menor numa loss-alvo. O termo engana se a referência não for declarada.

Um objetivo simples escreve

onde $R$ é volume esperado e $L$ representa comprimentos de input e output. Sistemas reais separam prefill de decode, batch, reuso de cache, hardware, energia, memória e utilização. Parameter count é proxy útil, não modelo completo de serving.

Sardana e colaboradores modificaram a análise Chinchilla para incluir inference e treinaram uma família para validar razões altas de tokens por parâmetro. O artigo de 2024 relata que demanda suficientemente grande desloca a preferência para modelos menores com mais dados. O crossover exato depende de custos, fits e workloads do estudo.

Qualidade é multidimensional. Igualar validation loss não garante mesma factuality, segurança, latency ou desempenho multilíngue. Um modelo menor e intensamente treinado é atraente, mas benchmarks e safety evals precisam confirmar o alvo. Shape arquitetural também importa: modelos de igual tamanho têm latencies diferentes porque profundidade limita execução sequencial e largura afeta eficiência matricial.

Disponibilidade de dados é restrição dura. Tokens únicos de alta qualidade podem acabar. Repetir dados muda o objetivo efetivo e pode elevar memorização. Dados sintéticos têm custo e dependência de qualidade. Um plano deve modelar o valor marginal dos últimos tokens, não assumir que todo $D$ informa igualmente.

A escolha interage com cadência de updates. Um checkpoint substituído em um mês tem volume de vida menor que um mantido por anos. Réplicas regionais, quantização, speculative decoding e amortização alteram economia. Obrigações de remoção podem encurtar a vida do modelo.

Uma calculadora útil expõe target loss, parâmetros, tokens, throughput, utilização, requests, comprimentos, batching, energia e preço. Deve mostrar faixa e manter coeficientes empíricos ligados à fonte e data.

O princípio durável é otimizar a vida do sistema, não uma run. Chinchilla pergunta como gastar pretraining. Scaling inference-aware pergunta qual modelo deve existir depois, dada a frequência de uso. Mais treinamento pode ser racional se compra uma máquina menor para todo token futuro.