Quanto custa chegar à escala do GPT-3, por que a VRAM quase nunca é o limite, e a fórmula que diz qual tamanho treinar com o dinheiro que você tem.
Os pesos do GPT-3 nunca foram publicados. O repositório openai/gpt-3 tem amostras de texto e estatísticas do corpus — nenhum peso. Não existe "baixar o GPT-3".
E arquiteturalmente ele é, em essência, um GPT-2 maior: mesmos blocos, mesma atenção causal, com camadas de atenção esparsa alternadas. O que separa os dois é escala, não invenção.
Então "chegar ao GPT-3" significa subir degraus de tamanho. E o paper define oito, não um — o 175 B é o último, não o único.
Chinchilla (Hoffmann et al., 2022) mediu a relação entre parâmetros, dados e compute. A regra prática: ~20 tokens de treino por parâmetro.
O custo em operações de ponto flutuante para treinar
O fator 6 vem de duas multiplicações por parâmetro na passada direta e quatro na reversa. Substituindo
Dado um orçamento, existe um tamanho ótimo. Treinar maior deixa o modelo subtreinado — ele tem capacidade que nunca foi preenchida. Treinar menor desperdiça compute em algo que já convergiu.
"Pego o maior modelo que couber na VRAM" é a heurística errada, e é a mais comum.
Numa RTX 5090 alugada (32 GB, US$ 0,678/h), a 60 TFLOP/s efetivos:
| Modelo | Params | Tokens | Texto | VRAM | Horas | Custo |
|---|---|---|---|---|---|---|
nosso mini ✓ | 7 M | 0,1 B | 1 GB | 0,2 GB | — | — |
nosso grande | 97,5 M | 1,9 B | 7 GB | 2,1 GB | 5,3 | US$ 2 |
| GPT-3 Small | 125 M | 2,5 B | 9 GB | 2,7 GB | 8,7 | US$ 4 |
| GPT-3 Medium | 350 M | 7,0 B | 26 GB | 7,6 GB | 68 | US$ 31 |
| GPT-3 Large | 760 M | 15,2 B | 57 GB | 16,6 GB | 321 | US$ 145 |
| GPT-3 XL | 1,3 B | 26 B | 97 GB | 28,3 GB | 939 | US$ 424 |
| GPT-3 2.7B | 2,7 B | 54 B | 201 GB | 58,8 GB ✗ | 4 050 | US$ 1 831 |
| GPT-3 175B | 175 B | 3,5 T | 13 TB | 3 814 GB ✗ | 1 942 anos | US$ 7,7 M |
A VRAM quase nunca é o limite. Até o GPT-3 Large cabe nos 32 GB. Só a partir de 2,7 B a placa fica pequena — e aí o problema deixa de ser alugar uma e passa a ser paralelizar entre várias, que é outra engenharia.
O limite é o corpus. Temos 310,6 M tokens. O GPT-3 Small pede 2,5 bilhões: 8× mais texto do que temos. Nenhuma placa resolve isso.
O 175 B não é uma questão de dinheiro seu. Quase dois mil anos numa placa. Aquilo foi feito com milhares de GPUs em paralelo por meses — outra categoria de empreendimento, não o próximo degrau.
Treinar exige mais que os pesos. Com AdamW: os pesos, os gradientes, e dois momentos por parâmetro. Em fp32 são 16 bytes por parâmetro; com bf16 misto, ~18 contando a cópia mestra. Somamos ~30% para ativações:
Um modelo de 1 B pede ~24 GB só para o estado do otimizador. É por isso que a linha do 2,7 B estoura uma placa de 32 GB — não pelos pesos, que são 5,4 GB.
Os 60 TFLOP/s efetivos são uma estimativa, não medida. Calibramos contra um ponto real: o nanoGPT treina o GPT-2 de 124 M em 8×A100 a ~870 k tok/s, ou ~110 k por placa. Nossa fórmula dá ~117 k para um modelo equivalente — bate.
Em modelos pequenos, ela mente para cima. Um modelo de 3 M de parâmetros não satura placa nenhuma: o gargalo vira lançamento de kernel e alimentação de dados, não cálculo. Por isso a tabela marca com ? as linhas que bateram no teto conservador de 400 k tok/s.
A solução é não estimar: cloud/calibrate.py roda alguns passos reais em cada tamanho, mede, e só então recomenda. Custa ~4 centavos.
Um orçamento pequeno nesta faixa de aluguel dá da ordem de 7,4 horas de uma placa. Aplicando
| Throughput efetivo | Orçamento em FLOPs | Tamanho ótimo |
|---|---|---|
| 40 TFLOP/s (conservador) | 1,07 × 10¹⁸ | 94 M |
| 60 TFLOP/s (otimista) | 1,60 × 10¹⁸ | 115 M |
O nosso preset grande tem 97,5 M. O GPT-3 Small tem 125 M. Sete horas de uma única placa compram exatamente essa faixa — treinada até o ponto ótimo, não pela metade.
O que ela exige são ~2 bilhões de tokens, ou ~8 GB de texto. É o degrau que falta, e ele é de dados, não de dinheiro.
Três desperdícios aparecem ao preparar um aluguel — todos encontrados lendo o código antes de rodá-lo.
| Vazamento | Causa | Custo |
|---|---|---|
| Treino na CPU da máquina alugada | o script de treino nunca move o modelo para a GPU | todas as horas contratadas |
| Tokenização serial | tok.encode um documento por vez roda em uma thread | ~35% do orçamento |
| Pesos irrecuperáveis | checkpoint salvo com tensores CUDA | o trabalho todo |
O segundo é o mais instrutivo. Trocar tok.encode(um_texto) por tok(lista_de_textos) aciona o paralelismo do backend em Rust:
um a um : 0,80 M chars/s em bloco : 6,35 M chars/s -> 7,9x mais rapido 8 GB de corpus: 178,2 min um a um vs 22,5 min em bloco
35% do orçamento, numa linha de código. E numa máquina cobrada por hora, o preparo de dados custa tanto quanto o treino — a GPU fica parada enquanto a CPU tokeniza.
destroy para a cobrança. stop pausa a GPU e continua cobrando o disco.| # | Passo | Custo | Destranca |
|---|---|---|---|
| 1 | treinar pequeno até convergir | grátis (4 h de CPU) | primeiro modelo sério |
| 2 | corpus para ~10 GB | tempo de download | GPT-3 Small vira viável |
| 3 | alugar e treinar grande | ~US$ 2 | escala do GPT-2 base |
| 4 | GPT-3 Small com o nosso tokenizador | ~US$ 4 | paridade de escala |
| 5 | GPT-3 Medium | ~US$ 31 | teto sensato para projeto pessoal |
Chegar à escala do GPT-3 Small custa menos de oito horas de uma única GPU. O que falta não é tempo de placa: é texto. Por isso a prioridade é corpus, e por isso a apostila 01 insiste tanto no tokenizador — cada token economizado é orçamento de treino devolvido.
Com a conta feita, a apostila 08 mostra a bancada: onde tudo isso se opera
— servir, radiografar e treinar, sem sair do navegador.