A morte lenta do scaling: por que maior já não é sempre melhor

Sara Hooker — ex-líder da Cohere For AI, uma das poucas pesquisadoras com pele em jogo tanto no campo industrial quanto no acadêmico — publicou um ensaio chamado On the slow death of scaling. Ele encara uma pergunta que, durante a maior parte da última década, foi tratada como já respondida: maior é sempre melhor?

A resposta honesta, ela argumenta, é não. E as consequências de ter assumido o contrário são maiores do que a maioria das equipes — e da maioria dos reguladores — começou a encarar. Este é o primeiro post de uma série de três partes que destrincha o ensaio e o que ele significa para qualquer um que esteja entregando ou regulando IA em 2026.

A década que transformou "escala" em sinônimo de "progresso"

A história que Hooker conta começa com um acidente. Em 1945, Percy Spencer notou uma barra de chocolate derretendo no bolso perto de um tubo magnetron de radar e ganhamos o micro-ondas. Nos anos 2000, GPUs — projetadas nos anos 70 para renderizar o Mario — foram reaproveitadas para multiplicação de matrizes e ganhamos deep learning. O artigo do Google de 2012 usou 16.000 núcleos de CPU para classificar gatos; um ano depois, a mesma tarefa foi resolvida com dois núcleos de CPU e quatro GPUs.

Esse momento acendeu uma corrida por compute e, com ela, uma cultura. A velha piada de Ken Thompson — "quando em dúvida, use força bruta" — foi elevada à bitter lesson de Rich Sutton: jogue mais compute no problema, e a engenharia de conhecimento humano continua perdendo. De 2017 a 2023, os custos de treinamento cresceram aproximadamente quatro ordens de magnitude. O GNMT custou ~US$ 100 mil para treinar; o Gemini Ultra ultrapassou US$ 100 milhões. A "fórmula" virou: escalar o tamanho do modelo e dos dados de treino, repetir.

As implicações de capital foram enormes. A pesquisa de fronteira migrou da academia para um punhado de labs da indústria. Hooker cita a geografia diretamente: a produção notável de modelos de ML está hoje concentrada nos EUA e na China num grau que teria sido impensável em 2010. A cultura de publicação aberta colapsou em paralelo. Os labs da indústria pararam de publicar não porque a ciência ficou mais difícil de descrever, mas porque o moat mudou dos algoritmos para o capex.

A evidência de que o pressuposto está quebrando

É aqui que o ensaio fica desconfortável para qualquer um cujo roadmap dependa do dogma "maior é melhor" estar certo.

Hooker plota o Open LLM Leaderboard ao longo de dois anos. A tendência não é sutil:

• Falcon 180B — antes fronteira — é facilmente superado por Llama-3 8B, Command R 35B e Gemma 2 27B.
• Aya 23 8B e Aya Expanse 8B batem o BLOOM 176B apesar de terem 4,5% dos parâmetros.
• Os melhores modelos abaixo de 13B rotineiramente batem outros muito maiores submetidos na mesma janela.

Esses não são casos isolados. São a tendência dominante num benchmark público ao longo de vários anos. Se "maior" ainda implicasse "melhor" de maneira significativa e confiável, nada disso estaria acontecendo. O que estamos vendo é que a taxa de retorno por unidade de compute está mudando, e essa mudança está sendo impulsionada por coisas além da contagem bruta de parâmetros — qualidade dos dados, técnica algorítmica, escolhas arquiteturais. Vamos entrar nisso na Parte 2.

Por que as leis de escala foram supervalorizadas

A justificativa intelectual dominante para a trajetória "maior é melhor" foram as scaling laws — Kaplan et al. (2020), Chinchilla, Hernandez et al. — que tentam prever como a loss diminui à medida que compute, dados e parâmetros crescem. Elas se tornaram, nas palavras de Hooker, "uma frase guarda-chuva para justificar tudo, de investimentos massivos de capital em startups de IA a decisões de política sobre limiares de compute".

Mas o ensaio cataloga, com citações, um conjunto de ressalvas que deveriam deixar nervoso qualquer um que use scaling laws para algo além de um único treinamento planejado:

1. Elas preveem principalmente a loss de teste de pré-treino, não capacidades downstream — e a relação entre as duas é "nebulosa ou inconsistente". Esta é a discussão das propriedades emergentes, que Hooker reformula com ironia: propriedades emergentes são apenas nossa admissão de que as scaling laws não previram o que saiu.
2. Foram difíceis de replicar sob premissas ligeiramente diferentes sobre a distribuição dos dados (Besiroglu et al. 2024 sobre Chinchilla; Anwar et al. 2024).
3. Muitas "power laws" se apoiam em menos de 100 pontos de dados (Ruan et al. 2024). Em qualquer outra área isso não passaria na revisão.
4. Algumas capacidades downstream escalam de forma errática ou não seguem power laws de jeito nenhum (Srivastava et al. 2023; Caballero et al. 2023).
5. Funcionam melhor quando arquitetura, otimizador e qualidade de dados permanecem constantes — exatamente as condições com menor probabilidade de se manter num horizonte de planejamento de vários anos.

A leitura honesta é que as scaling laws são úteis para planejar o próximo treinamento dentro de um regime conhecido e não muito mais. Tratá-las como uma previsão estrutural sobre a trajetória da capacidade da IA ao longo dos anos sempre foi um exagero.

O problema de política pública que isso cria

É aqui que o ensaio se torna estrutural para qualquer um que não esteja de fato treinando modelos de fronteira — ou seja, a maioria de nós. A regulação foi construída em cima do pressuposto "maior é melhor". O EU AI Act, as ordens executivas dos EUA e a onda de linguagem sobre limiares de compute na legislação de 2024–25 compartilham uma premissa estrutural: que compute de treino (FLOPs no tempo de treino, ou por proxy, acesso a hardware) é o melhor indicador de capacidade e, portanto, de risco.

Se Hooker estiver certa — e a evidência empírica que ela apresenta é difícil de descartar — então os limiares de compute:

• Deixam passar inteiramente modelos pequenos e capazes. Um modelo de 8B que supere um de 180B em capacidades nocivas não vai disparar nenhum limiar baseado em FLOPs.
• Sobre-regulam modelos grandes mas subperformantes, criando custo de compliance para uma capacidade que não existe.
• Vão envelhecer mal à medida que compute em tempo de inferência, sistemas agênticos e técnicas livres de gradiente (Parte 3) deslocam onde a capacidade de fato se acumula.
• Concentram poder ainda mais ao gravar em lei os pressupostos de escala do oligopólio atual.

As "responsible scaling policies" da Anthropic e da OpenAI herdam o mesmo pressuposto embutido: que o scaling vai continuar acontecendo e que a única pergunta em aberto é como escalar de forma responsável. O desafio de Hooker é mais desconfortável: e se scaling não for o único — nem o mais interessante — eixo de progresso?

O que isso significa se você está entregando produto, não política

As implicações descem em cascata. Se você é CTO, VP de Eng ou founder técnico tomando decisões de modelo para produção:

• Pare de indexar por contagem de parâmetros. Sempre foi um proxy ruidoso e agora é ativamente enganoso. Scores de leaderboard abertos, evals específicos da tarefa e seu próprio mix de tráfego em produção dizem mais do que B-de-parâmetros.
• Tenha como default "o menor modelo que atinge a barra do eval", não "o maior modelo que o orçamento permite". O custo de inferência compõe. A realidade "8B-bate-180B" significa que você normalmente consegue se virar com muito menos do que o marketing do fornecedor sugere.
• Encare com desconfiança qualquer roadmap de fornecedor cuja proposta de valor seja "vamos ser maiores no ano que vem". Alguns dos ganhos de capacidade mais importantes dos últimos 24 meses — RAG, uso de ferramentas, chain-of-thought, distillation — não exigiram scaling nenhum.
• Audite qualquer documento de planejamento interno que use scaling laws como previsão. Elas são previsoras fracas fora de regimes estreitos de treinamento. Se um roadmap de 3 anos depende de extrapolar uma, isso é risco, não plano.

O pressuposto "maior é melhor" foi útil durante uma década. Está, graciosa e lentamente, morrendo. A pergunta interessante é o que vem a seguir — e é aí que isso fica empolgante de novo. A criatividade de engenharia foi expulsa pelo capex durante anos. Está prestes a importar de novo.

---

A seguir nesta série: O que de fato impulsiona a taxa de retorno do compute — retornos decrescentes sobre parâmetros, o papel da qualidade dos dados, as melhorias algorítmicas que fazem o trabalho de verdade e por que arquitetura é o teto sobre o qual ninguém fala.