Pré-treinar um LLM: dados, compute, leis de escala e custo

Nada muda no objetivo. O modelo continua a prever o próximo token, a perda continua a ser a cross-entropy do Capítulo 4 aplicada à fatorização do Capítulo 8, o otimizador continua a ser o AdamW do Capítulo 6. Pretraining não é um algoritmo novo; é o mesmo algoritmo executado num corpus suficientemente grande para a execução ter de ser orçamentada. Duas coisas tornam isso possível: os rótulos são gratuitos, porque o alvo para a posição $t$ é o token em $t+1$ e já está no texto; e a última secção do Capítulo 6 removeu a objeção, porque um modelo com muito mais parâmetros do que as regras clássicas permitem não colapsa, melhora. O resultado é um modelo base — algo que continua texto em vez de responder.

Antes de tudo isto poder ser orçamentado, tem de ser contado, e a área conta-o com uma fórmula:

onde $N$ é a contagem de parâmetros, $D$ os training tokens e $C$ o total de operações de vírgula flutuante. Kaplan et al. derivam-na em dois passos.¹ Forward: 2 FLOPs por parâmetro por token, porque cada parâmetro numa multiplicação de matrizes é usado uma vez por token, numa multiplicação e numa adição. Backward: o dobro do forward, porque a passagem backward do Capítulo 5 calcula dois gradientes em cada camada — relativamente aos inputs da camada, para o sinal continuar a viajar, e relativamente aos seus pesos — cada um uma multiplicação de matrizes do tamanho da forward, logo $4N$.

Essa é toda a derivação, e vale a pena verificá-la em vez de acreditar. O PyTorch inclui um contador FLOP real, torch.utils.flop_counter.FlopCounterMode, que interceta todas as operações que um modelo despacha e soma o trabalho real. Execute-o ao longo de quatro ordens de grandeza, o maior no dispositivo meta, que aloca formas e não memória:

from torch.utils.flop_counter import FlopCounterMode

counter = FlopCounterMode(display=False)
with counter:                       
    loss = model(x, targets)[1]     
    loss.backward()                 
measured = counter.get_total_flops()
print(measured / (6 * n_params * n_tokens))

O rácio forward+backward sobre forward é 3.000, exatamente, em todas as escalas: não é uma aproximação que por acaso é boa, mas a identidade aritmética acima devolvida como número redondo por um contador que nada sabe da derivação.

O total medido fica então entre 3 % e 17 % acima de $6ND$, assim que $N$ conta as matrizes de embedding — e essa cláusula importa, porque os dois artigos fundadores contam $N$ de forma diferente. Kaplan exclui "all vocabulary and positional embeddings" porque fazê-lo "produces significantly cleaner scaling laws" (§1.3); o Apêndice F de Chinchilla diz "we also count embeddings matrices in the total parameter count".² Para um vocabulário largo e uma dimensão hidden estreita, os dois diferem por um fator de nove, como mostra a primeira linha.

A diferença residual é o que $6ND$ omite deliberadamente: as pontuações de attention. A Eq. (2.2) de Kaplan escreve o custo forward como $2N + 2\,n_{\text{layer}} n_{\text{ctx}} d_{\text{model}}$ e elimina o segundo termo porque $d_{\text{model}} \gg n_{\text{ctx}}/12$ — seguro em 2020, menos seguro agora, e a razão pela qual o rácio sobe à medida que $T/d$ cresce — motivo pelo qual duas linhas aqui partilham um $T$ de 1.024 e o rácio cai, de 1.145 para 1.100, quando $d$ passa de 768 para 1.600. É o custo $O(T^2)$ que o Capítulo 9 introduziu e que o Capítulo 16 transforma num preço.

O compute decide quanto tempo uma execução demora; a memória decide se pode começar. Treine com AdamW fp32 simples e cada parâmetro transporta quatro números: o peso, o seu gradiente, e a média móvel $m$ e a variância $v$ do Adam — as duas médias construídas à mão no Capítulo 6. Quatro números a quatro bytes cada são 16 bytes por parâmetro, antes de uma única activation. Medido numa GPU de portátil de 8 GB, tomando a alocação residente no ponto do passo em que não há gráfico vivo:

Previsão e medição concordam dentro de 3 %. A surpresa é a última coluna: as activations esmagam o modelo. O mesmo modelo de 5,8 milhões de parâmetros que precisa de 89 MB de estado persistente precisa de 4.681 MB de activations com um batch de 128 — cinquenta e duas vezes o modelo — e muito disso nem sequer é o transformer. São os logits, um vetor do tamanho do vocabulário por token a quatro bytes por entrada: 512 MB na última linha, 393 MB na primeira. O tamanho do vocabulário foi escolhido no Capítulo 7, e continua a decidir o que cabe na placa.

Que termo domina depende da forma da execução, razão pela qual Micikevicius et al. dizem que a memória "is dominated by activations"³ enquanto o ZeRO diz que um modelo de 1,5 mil milhões de parâmetros precisa de "at least 24 GB" apenas para os estados do modelo.⁴ O ZeRO chega aos mesmos 16 bytes por outro caminho — $2\Psi$ para pesos fp16, $2\Psi$ para gradientes fp16, $4\Psi$ cada para os pesos mestres fp32 e os dois momentos do Adam — o que, para 70 mil milhões de parâmetros, dá 1,12 terabytes, o equivalente a catorze GPUs de 80 GB antes de uma única activation.

Nada disso cabe num só dispositivo à escala frontier, por isso a execução é dividida de quatro formas ao mesmo tempo. Paralelismo de dados coloca uma cópia do modelo em cada GPU e calcula a média dos gradientes — o padrão, e aquele que o ZeRO melhora ao recusar manter cópias redundantes do estado do otimizador. Paralelismo de tensores divide matrizes individuais entre dispositivos. Paralelismo de pipeline dá a cada dispositivo um grupo contíguo de camadas. Paralelismo de contexto divide a própria sequência, necessário apenas quando $T$ é suficientemente longo para o termo de attention dominar. A Tabela 4 do Llama 3 lista os quatro de uma vez: tensor 8, contexto até 16, pipeline 16, dados até 128, em 16.384 GPUs H100.⁵ É tudo o que este curso dirá sobre isso; engenharia de treino distribuído é um semestre próprio, e o CS336 de Stanford é esse semestre, aulas 5 a 8, com o código.⁶ O que sobrevive à delegação é um único número, model FLOPs utilisation — a fração da aritmética de pico de uma GPU que uma execução real atinge — que é o que transforma o arrumado $6ND$ em tempo de relógio e, portanto, em dinheiro.

Em janeiro de 2020, Kaplan et al. treinaram uma grelha de transformers e descobriram que a perda de teste segue uma lei de potência em cada um dos três recursos ao longo de mais de seis ordens de grandeza.¹ A secção §1.2 dá três leis ajustadas:

com companheiras $\alpha_D \approx 0.095$ para dados e $\alpha_C^{\min} \approx 0.050$ para compute alocado de forma ótima. As constantes não são universais, e o artigo di-lo: "the precise numerical values of $N_c$, $C_c^{\min}$ and $D_c$ depend on the vocabulary size and tokenization and hence do not have a fundamental meaning."

Os expoentes são minúsculos: dez vezes os parâmetros compram um fator $10^{0.076} \approx 1.19$ retirado à perda restante. Parece nada, e é o facto mais importante aqui — os retornos são péssimos e nunca acabam. Uma lei de potência com um expoente pequeno promete que a próxima ordem de grandeza ajudará, menos do que a anterior, para sempre. Comprar compute deixa de ser uma aposta e passa a ser uma compra com uma taxa de câmbio publicada, exatamente o argumento que desbloqueou o capital.

Depois veio a prescrição, e é aqui que o artigo estava errado de uma forma que custou muito dinheiro à indústria. A Tabela 6 de Kaplan dá $N_{\text{opt}} \propto C^{0.73}$ e $D_{\text{opt}} \propto C^{0.27}$: dez vezes o compute significam um modelo 5,4 vezes maior alimentado com apenas 1,9 vezes mais texto. O resumo é explícito — "optimally compute-efficient training involves training very large models on a relatively modest amount of data and stopping significantly before convergence." A área fez exatamente isso: GPT-3 tem 175 mil milhões de parâmetros em 300 mil milhões de tokens,⁷ Gopher 280 mil milhões em 300 mil milhões, Megatron-Turing NLG 530 mil milhões em 270 mil milhões.² De meio token a dois tokens por parâmetro, em toda a linha.

Em março de 2022, Hoffmann et al. treinaram mais de 400 modelos de 70 milhões a 16 mil milhões de parâmetros e chegaram à conclusão oposta por três vias independentes.² A Tabela 2 reporta o expoente $a$ em $N_{\text{opt}} \propto C^{a}$ como 0.50, 0.49 e 0.46, contra os 0.73 de Kaplan. Em termos simples: o tamanho do modelo e os dados de treino devem crescer em igual proporção.

A segunda abordagem deles é a reproduzida pela varredura no início deste capítulo, a uma milionésima da escala: fixar um orçamento, treinar muitos tamanhos exatamente com esse orçamento, representar a perda final contra o tamanho do modelo.

Perda held-out em nats por token, tokens por parâmetro entre parênteses, negrito para o melhor modelo em cada orçamento; um travessão é um ponto não executado, porque o orçamento exigia mais texto do que o corpus contém ou porque o tamanho ficava fora dos varridos ali.

Leia uma coluna para baixo: a perda cai, chega ao fundo e volta a subir. Um modelo pode ser grande demais para o seu orçamento tão facilmente como pequeno demais — em $10^{14}$, a penalização por escolher 665.280 parâmetros em vez de 295.808 é 0,08 nats, que no envelope ajustado acima é a perda que um modelo corretamente dimensionado atinge com 18 % menos compute. Escolher a forma errada deita fora um quinto do orçamento. É a Figura 3 de Chinchilla numa tarde numa GPU em vez de com quatrocentos modelos.

Agora leia na horizontal. Em $10^{13}$ o melhor modelo é o mais pequeno dos varridos; em $10^{14}$ são 295.808 parâmetros, enquadrado de ambos os lados. O ótimo desloca-se para a direita à medida que o orçamento cresce, que é todo o conteúdo da correção. Ajuste a terceira abordagem do artigo — a superfície $L(N,D) = E + A/N^{\alpha} + B/D^{\beta}$ sobre todas as execuções — e minimize sujeita a $C = 6ND$:

L(N, D) = 24.7 / N^0.195 + 46.8 / D^0.169       (E fits to ~0; see below)
implied   N_opt ∝ C^0.464
  compare   Chinchilla 0.46-0.50 · Besiroglu 0.513 · Kaplan 0.73

0,46, a partir de um portátil, contra os 0,73 de Kaplan. A concordância a três dígitos a partir de um ajuste de três orçamentos é sorte; a concordância no primeiro não é. O expoente viaja — a constante não, porque o rácio tokens-parâmetro nestes ótimos é de 170 a 540, não 20. Três razões, todas instrutivas. $E$ ajusta para zero porque, com uma perda acima de 4 nats, a execução não está nem perto do piso de entropia que domina o ajuste de Chinchilla. O tamanho do batch e a learning rate foram fixos em vez de ajustados por ponto, o que prejudica as execuções que recebem menos passos — e essas são os modelos grandes: em $10^{13}$ FLOPs, um modelo de 1,28 milhões de parâmetros recebe 159 passos de otimizador no total, muito abaixo dos poucos milhares que o termo $S_{\min}$ de Kaplan diz que qualquer modelo precisa. Uma lei de escala é ajustada dentro de um regime, e esta está seis ordens de grandeza abaixo de Chinchilla.

Daí o resumo do artigo: "current large language models are significantly undertrained". Chinchilla é a demonstração — 70 mil milhões de parâmetros em 1,4 biliões de tokens, o mesmo compute total que o Gopher de 280 mil milhões em 300 mil milhões, superando-o em 51 de 57 tarefas MMLU, 67,5 % contra 60 %.² Quatro vezes mais pequeno, quatro vezes e meia mais texto, mesmo dinheiro, melhor modelo.

Duas ressalvas sobre esse famoso rácio. "Vinte tokens por parâmetro" não é uma frase do artigo, que diz apenas que "for every doubling of model size the number of training tokens should also be doubled"; os 20 são uma inferência da Tabela 3 e do próprio Chinchilla, 70 B em 1,4 T. E a sua precisão é pior do que a publicada: Besiroglu et al. reajustaram a partir de uma digitalização da Figura 4, descobriram que os parâmetros originais "fit the reconstructed data poorly" com intervalos "implausibly tight given the number of data points", e colocaram o intervalo honesto em "between 4 and 40" tokens por parâmetro.⁸

Um detalhe do método de Chinchilla cumpre uma promessa que o Capítulo 1 fez sobre schedules de learning rate. O schedule cosseno tem de ser compatível com o orçamento de tokens. Um modelo que verá 10 milhões de tokens deve decair a sua learning rate para zero aos 10 milhões de tokens; dê-lhe um schedule dimensionado para 100 milhões, pare-o cedo, e está a ler uma perda a meio da descida com uma taxa demasiado alta. Chinchilla treina cada modelo em quatro comprimentos de ciclo para controlar exatamente isto; a varredura acima define o schedule a partir do orçamento pela mesma razão.

São o resultado empírico mais útil da área e são rotineiramente exageradas. Quatro limites.

Preveem perda, não capacidade. O lado esquerdo é cross-entropy em texto held-out. Nada nestes artigos autoriza uma afirmação sobre se um modelo escreverá SQL correto, recusará um pedido nocivo ou usará uma tool. É de novo a lição do Capítulo 5: uma previsão da perda não é uma previsão do comportamento pelo qual está a pagar.

São ajustadas, não derivadas. Nenhuma teoria produz $\alpha_N = 0.076$. As constantes movem-se com o tokenizer — é por isso que uma comparação de perplexity entre dois tokenizers não tem sentido, como explicou o Capítulo 8 — e com a mistura de dados, a arquitetura e o otimizador. Toda a lei publicada é uma lei da configuração que a produziu, razão pela qual a Meta reajustou a sua antes do Llama 3.⁵

Assumem um token novo para cada passo, o que discretamente assume um corpus infinito. Muennighoff et al. mediram o que acontece quando ele acaba: até quatro épocas de dados repetidos custam quase nada — um modelo de 8,7 mil milhões de parâmetros em 44 mil milhões de tokens únicos vistos quatro vezes terminou com "only 0.5 % higher validation loss" do que o mesmo modelo em 178 mil milhões de tokens únicos — enquanto, depois de cerca de dezasseis épocas, compute adicional não compra nada.⁹

E já ninguém treina de forma compute-optimal. Chinchilla minimiza o custo de treino; um modelo implementado paga depois cerca de $2N$ FLOPs por token gerado, para sempre. O LLaMA 1 disse-o claramente: "given a target level of performance, the preferred model is not the fastest to train but the fastest at inference".¹⁰ Sardana et al. formalizaram isto minimizando antes $6ND_{\text{train}} + 2ND_{\text{inference}}$, e descobriram que quem espera mil milhões de pedidos deve treinar "smaller and longer than Chinchilla-optimal".¹¹ A secção §9.1 do Llama 3 concorda: os seus modelos pequenos treinam "far beyond the point of compute optimal training, effectively trading training compute for inference efficiency".⁵ O rácio não está obsoleto; responde a uma pergunta que já não é a que está a ser feita.

A perda cai suavemente. As pontuações em benchmarks por vezes não. Wei et al. reuniram casos em que uma tarefa fica ao nível do acaso ao longo de ordens de grandeza de training compute e depois salta — aritmética de três dígitos a aparecer no GPT-3 por volta de $2 \times 10^{22}$ FLOPs, MMLU a subir acima do palpite entre $3$ e $5 \times 10^{23}$ — e deram nome ao padrão: "an ability is emergent if it is not present in smaller models but is present in larger models".¹² Se isso for uma propriedade real, extrapolar a partir de experiências baratas é inseguro, porque a capacidade que está a comprar pode não existir em nenhuma escala que consiga testar.

Schaeffer, Miranda e Koyejo argumentaram que a maior parte disso é um artefacto de medição, e o mecanismo é aritmético.¹³ A perda por token cai suavemente, por isso a probabilidade de um token estar certo, $\exp(-\mathcal{L})$, melhora gradualmente. Pontue o modelo com correspondência exata de string sobre uma resposta de $L$ tokens e eleva essa probabilidade à potência $L$ — uma curva suave elevada a uma potência grande parece um precipício. Troque para uma métrica que conta tokens em vez de exigir todos, nas mesmas saídas, e "the family's performance smoothly, continuously and predictably improves with increasing scale".

A auditoria deles é o número a reter — "of the 39 preferred metrics in BIG-Bench, at most 5 display emergence", com duas métricas descontínuas a explicarem mais de 92 % dos casos alegados — e também o é a cautela: "nothing in this paper should be interpreted as claiming that large language models cannot display emergent abilities". Um salto num gráfico é prova sobre a métrica até se mostrar o contrário. O Capítulo 29 é onde isso se torna problema seu, porque escolher uma métrica de corte rígido é uma decisão que tomará sem reparar.

O corpus é a parte de uma execução de pretraining sem equação associada, e onde vivem a maioria das decisões consequentes. A matéria-prima é uma recolha da web: o arquivo de agosto de 2026 da Common Crawl contém "2.14 billion web pages or 360 TiB of uncompressed content", um mês dela, gratuito para download.¹⁴ Quase nada é utilizável como está. O artigo T5 diz que a recolha "largely comprises gibberish or boiler-plate text like menus, error messages, or duplicate text", e o pipeline C4 que introduziu é uma lista de heurísticas grosseiras — manter apenas linhas que terminam em pontuação final, eliminar páginas com menos de três frases, eliminar qualquer página que contenha uma chaveta ou uma palavra de uma lista pública de obscenidades — transformando vinte terabytes de texto mensal em cerca de 750 GB.¹⁵

Grosseiras é a palavra. Dodge et al. auditaram o que esses filtros removem e descobriram que a blocklist de obscenidades elimina 42 % dos documentos em inglês afro-americano e 32 % em inglês alinhado com hispânicos, contra 6,2 % do inglês alinhado com brancos, deixando um corpus 97,8 % da última categoria.¹⁶ Uma regra sem opinião sobre dialeto tinha uma.

Depois deduplicação, que não é arrumação: Lee et al. encontraram uma frase de 61 palavras repetida 61.036 vezes no C4, e mostraram que deduplicar reduz dez vezes a taxa a que os modelos "emit memorized text", de 1,9 % dos tokens gerados para 0,19 %.¹⁷ Mais não é melhor, porém — a equipa do FineWeb deduplicou globalmente em 96 recolhas, obteve 4 biliões de tokens e nenhum ganho mensurável; depois deduplicou cada recolha separadamente, obteve 20 biliões, e igualou o melhor corpus existente.¹⁸

Depois contaminação. O Llama 3 mediu a sua e publicou-a: 98 % do AGIEval, 95 % do BIG-Bench Hard e 85 % do HellaSwag sobrepunham-se ao conjunto de treino por 8-grams, e no MMLU uma sobreposição tão alta que "it is impossible to get a good performance gain estimate".⁵ A secção §4 do GPT-3 relata um bug de filtragem que deixou benchmarks nos dados sem volta possível: "because of cost considerations it was infeasible to retrain the model".⁷

A proveniência é a parte por resolver. O Pile incluiu um componente de 100,96 GiB chamado Books3 — 12 % do corpus e, pela própria tabela de consentimento do artigo, livros de um tracker de torrents privado;¹⁹ foi retirado do ar em agosto de 2023 após uma queixa de direitos de autor. A posição legal em setembro de 2026 está por resolver, e as três decisões dos EUA citadas como tendência discordam entre si. Alsup considerou que treinar em livros adquiridos legalmente era "exceedingly transformative", mantendo que uma biblioteca construída a partir de cópias pirateadas não o era, e a Anthropic transacionou essa metade por $1.5 billion cobrindo 482.460 obras, cerca de $3.000 cada, aprovado em 20 de julho de 2026.²⁰ Chhabria concedeu julgamento sumário à Meta escrevendo ao mesmo tempo que a sua decisão "does not stand for the proposition that Meta's use of copyrighted materials to train its language models is lawful", apenas que "these plaintiffs made the wrong arguments".²¹ Bibas, decidindo contra a Ross Intelligence, assinalou que "only non-generative AI is before me today".²² Nenhum tribunal de recurso dos EUA decidiu a questão.

Pessoas fazem as partes que a perda não consegue. A TIME noticiou em janeiro de 2023 que trabalhadores que rotulavam texto tóxico para a OpenAI através da empresa Sama levavam para casa "between around $1.32 and $2 per hour" a ler passagens que descreviam abuso sexual infantil, tortura e automutilação, enquanto a OpenAI pagava à Sama $12.50 por hora pelo trabalho; a Sama contesta tanto o intervalo salarial como a quota.²³ Isso é a filtragem à volta do pretraining, não o pretraining em si — mas está na mesma fatura, e é onde uma pessoa se senta.

A eletricidade é real e normalmente mal citada. O valor publicado mais cuidadoso é o do BLOOM: 1.082.990 horas-GPU, 433 MWh e 24,7 toneladas de CO₂ equivalente para a execução, 50,5 contando fabrico e nós inativos;²⁴ Patterson et al. colocam o GPT-3 em 1.287 MWh e 552 toneladas.²⁵ Duas cautelas. A vantagem do BLOOM é a rede nuclear francesa a 57 g CO₂ por kWh, não a eficiência — usou mais energia do que o OPT-175B. E o valor de emissões mais citado da área, as 626.155 lb de Strubell et al. para uma neural architecture search, revelou-se depois 88 vezes alto demais, por ter assumido que a pesquisa corria no tamanho completo do modelo quando corria num proxy.²⁶ O enquadramento do LBNL é o defensável: os datacenters dos EUA usaram 192 TWh em 2024, 4,7 % da eletricidade nacional — um número ligado a uma indústria, não a uma execução individual.²⁷

O fio condutor é o que Bender et al. chamaram dívida de documentação: "putting ourselves in a situation where the datasets are both undocumented and too large to document post hoc".²⁸ Cada facto acima existe porque alguém foi ver. Para os corpora por trás dos modelos que a maioria das pessoas usa, ninguém consegue.

Agora a aritmética que todos querem, a partir de quatro inputs citados, para que, quando envelhecerem, seja óbvio quais substituir.

Leia as duas últimas colunas em conjunto. Com $10.000 obtém um modelo de 5 mil milhões de parâmetros num nó alugado em quinze dias. Com $100.000.000, a aritmética diz 546 mil milhões de parâmetros — e doze mil H100 interligadas durante três meses, o que não é algo que se alugue com cartão de crédito. Depois de cerca de $100.000, a restrição vinculativa deixa de ser dinheiro e passa a ser o cluster.

Antes de confiar numa tabela como essa, teste-a contra execuções cujo custo real está publicado — llm.c reproduz o GPT-2 124M em "~90 minutes" num nó 8×A100 "for about $20", e o GPT-2 1.6B em 24 horas num nó 8×H100 por $672.³¹

$672, against what $672 actually bought (llm.c GPT-2 1.6B, one 8xH100 node, 24 h)
  this table predicts:      168 H100-hours   N = 1.41 B params   D = 28.3 B tokens
  what was actually run:    192 H100-hours   N = 1.558 B params  D = 33.6 B tokens

Llama 3 405B, against Meta's own published GPU-hours
  from the paper's 3.8e25 FLOPs at 40 % MFU:   26.67 M H100-hours
  published in Meta's Llama 3.1 model card:    30.84 M H100-hours    ratio 0.86

Ambos dentro de cerca de 15 %, que é aproximadamente a precisão que este tipo de estimativa merece e consideravelmente melhor do que a precisão com que costuma ser citada.

O número mais repetido neste tema é que um modelo de classe GPT-2 que custava cerca de $43.000 em 2019 pode ser reproduzido hoje por umas dezenas de dólares. A metade moderna está bem documentada; a metade histórica não.

Hoje. README de nanochat de Karpathy: "you can train your own GPT-2 capability LLM ... for only $48 (~2 hours of 8XH100 GPU node) ... On a spot instance, the total cost can be closer to ~$15."³² "GPT-2 capability" aqui é preciso e publicado — superar a pontuação CORE do GPT-2 de 0.256525 — numa leaderboard cuja melhor entrada em 14 de março de 2026 é 1,65 horas. Os $48 assumem $3 por hora-GPU, abaixo dos $3.99 de tabela da Lambda; ao preço de tabela, fica mais perto de $64.

Em 2019. Não há fonte primária: a OpenAI nunca publicou uma duração ou um custo. A cadeia passa pelo The Register, fevereiro de 2019, que reporta "256 Google TPU3 cores" sem preço e sem duração; depois pelo Synced, junho de 2019, assinalando que o hardware custava $256 por hora na Google Cloud e afirmando explicitamente que "OpenAI didn't specify the training duration". $43.008 são $256 por hora vezes umas supostas 168 horas que ninguém alguma vez documentou.

Portanto, a manchete honesta é: um modelo que iguala a pontuação de benchmark publicada do GPT-2 pode ser treinado hoje por bastante menos de $100 em hardware alugado, contra um custo de 2019 que nunca foi publicado e cuja famosa estimativa assenta num palpite sem fonte sobre a duração. O colapso é real e a metade moderna é reproduzível por qualquer pessoa com cartão de crédito; o rácio é aritmética sobre um número que não existe. Esse é o estado dos custos de treino publicados em geral. O artigo do GPT-3 não contém qualquer montante em dólares, apenas $3.14 \times 10^{23}$ FLOPs na Tabela D.1;⁷ o artigo do Llama 3 também não contém nenhum.⁵ Todo o custo de treino que leu é uma estimativa a partir de uma contagem FLOP, uma hipótese de hardware e uma hipótese de preço — vale sempre a pena perguntar de quem.

O que resulta viu um corpus fixo montado num momento fixo, e seguem-se duas propriedades.

A primeira é o knowledge cutoff. Depois da data de recolha, o modelo não sabe nada — não "está incerto", nada — e confabulará fluentemente em vez de o dizer, porque dizê-lo nunca foi um comportamento em que foi treinado. O model card do Llama 3.1 dá dezembro de 2023;³³ todos os modelos têm uma, e é uma propriedade dos dados de treino, não do deployment. Contorná-lo é um problema de retrieval, que é o Capítulo 19.

A segunda é que um modelo base completa em vez de responder. Dê-lhe "Qual é a capital de França?" e uma continuação plausível é outra pergunta, porque no corpus essa string aparece mais frequentemente numa lista de exercícios.

Um completador de texto não é um assistente. Não segue instruções, porque nada no corpus lhe disse que um pedido deve ser obedecido em vez de continuado. Não tem noção de uma conversa com dois participantes. Produzirá alegremente a continuação mais provável de um prompt nocivo, porque provável é a única coisa para a qual alguma vez foi otimizado.

Transformá-lo em algo que responde exige uma segunda fase que custa uma fração de um por cento da primeira, e consiste quase inteiramente em mostrar-lhe exemplos do comportamento que quer e depois comparar pares das suas próprias saídas. Essa fase é de onde vêm o seguimento de instruções, chat templates, recusas e — isto surpreende as pessoas — a capacidade de chamar uma tool. O Capítulo 11 é essa fase: supervised fine-tuning, RLHF, DPO e GRPO, e a pergunta sobre o que significa "aligned" e quem decide.

Também vale a pena ler juntamente com este capítulo: build-nanogpt de Karpathy e o vídeo que o acompanha, que percorrem uma reprodução completa do GPT-2 de ponta a ponta a um ritmo que este capítulo não consegue; e Stanford CS324, Large Language Models, cujas aulas sobre dados e impacto ambiental vão mais fundo do que a secção acima em material que este curso trata uma vez e delega.