72b: o que é, para que serve e por que ainda importa

Um modelo de linguagem com 72 bilhões de parâmetros não é novidade. Mas o 72b virou uma espécie de ponto de referência quando o assunto é equilíbrio entre custo e capacidade. Sempre que alguém pergunta “vale a pena rodar um 72b na minha infraestrutura”， a resposta começa com uma pergunta de volta: você precisa de raciocínio complexo ou só de respostas rápidas e baratas?Parece simplista， mas é exatamente aí que o 72b se posiciona. Ele não é o maior， nem o mais rápido. É o meio-termo que muita gente subestima.Conheci um caso curioso numa consultoria de dados. A equipe tentou usar um modelo de 7b para classificar contratos e extrair cláusulas. Funcionava em 70% dos casos. Subiram para um 72b e o acerto foi para 89%. O custo por inferência triplicou， mas o tempo de revisão humana caiu pela metade. O detalhe: eles rodavam o 72b em duas GPUs A100 alugadas por hora. No fim do mês， a conta fechou. Isso ilustra bem o papel do 72b: ele resolve problemas que modelos pequenos não dão conta， sem exigir o orçamento de um 180b ou 405b.

Por que 72 bilhões e não 70 ou 80?A arquitetura típica de um 72b usa 80 camadas com dimensão oculta de 8192 e 64 cabeças de atenção. Esses números não são mágicos， mas definem uma faixa de VRAM necessária: algo entre 140 GB e 160 GB em precisão de 16 bits. Com quantização em 4 bits， cai para uns 40 GB。o que cabe em uma única GPU de 48 GB ou duas de 24 GB. É por isso que o 72b virou o “modelo de entrada” para quem quer fazer fine-tuning em hardware acessível. Um 7b cabe em qualquer lugar， mas não aprende padrões tão finos. Um 72b ainda é domesticável.Não é só questão de tamanho. O 72b tem uma característica que modelos menores raramente exibem: consistência em tarefas de múltiplas etapas. Outro dia testei um 72b para gerar consultas SQL a partir de perguntas em português. Pedi algo como “liste os clientes que compraram mais de três vezes no último trimestre e não abriram chamado”. Modelos de 13b erravam a junção com a tabela de chamados. O 72b acertou de primeira， inclusive com o filtro de data. Isso não é mágica;é capacidade de manter o contexto e aplicar restrições lógicas. Para quem trabalha com dados， essa diferença vale o investimento.Claro que há limites. O 72b não é bom em raciocínio matemático avançado. Se você precisa resolver integrais ou provar teoremas， ele vai tropeçar. Também não é o melhor para conversas longas e criativas;modelos maiores mantêm o fio da meada por mais tempo. O 72b é um cavalo de trabalho: confiável para classificação， extração。sumarização e geração de código estruturado. Numa startup que conheço， eles usam um 72b para revisar pull requests automaticamente. O modelo aponta bugs simples e sugere correções. Nada de outro mundo， mas economiza umas duas horas por semana de revisão humana. O time nem pensa em trocar por um modelo maior porque o custo não se justifica.

E tem a questão do fine-tuning. Ajustar um 72b com LoRA é viável em uma máquina com 4 GPUs de 24 GB. O processo leva alguns dias， mas o resultado é um modelo especializado que supera modelos genéricos maiores em domínios específicos. Já vi um 72b ajustado para laudos médicos veterinários acertar 94% das classificações， enquanto um 180b genérico ficou em 87%. O segredo não está no tamanho bruto， mas na combinação de capacidade paramétrica com dados de qualidade. O 72b oferece parâmetros suficientes para absorver padrões complexos sem exigir um cluster de datacenter.Quem está começando agora talvez olhe para o 72b e pense: “mas já existem modelos de 400b”. Sim， existem. Só que a maioria das aplicações reais não precisa de um canhão. Precisa de uma ferramenta que funcione bem， custe pouco e não derreta o orçamento de nuvem. O 72b entrega isso. Ele não vai ganhar prêmio de inovação， mas resolve problemas de verdade. É o tipo de modelo que você coloca em produção e esquece que está lá. E， convenhamos。essa é a melhor definição de sucesso para uma peça de infraestrutura.