O que de fato impulsiona a taxa de retorno do compute

Na Parte 1 percorremos o argumento de Sara Hooker de que a era do "maior é melhor" está terminando. A pergunta de continuação natural — e aquela em que Hooker gasta a maior parte do ensaio — é se compute já não é a alavanca dominante, o que é?

A resposta dela: o que importa agora é a taxa de retorno por unidade de compute, e essa taxa está sendo impulsionada por quatro coisas, das quais apenas uma é "mais parâmetros". Vamos passar por elas em ordem, porque cada uma tem implicações para como uma equipe de engenharia deve escolher modelos, projetar pipelines de treino e orçar infraestrutura em 2026.

1. Parâmetros: retornos decrescentes, depois esquisitice

Em 2016, o Inception tinha 23M de parâmetros. Em 2025, o Qwen3-235B-A22B tem 235 bilhões. Esse salto de quatro ordens de magnitude comprou ganhos reais por um tempo. Também expôs um fato profundamente desconfortável: não entendemos por que precisamos da maioria desses pesos.

Hooker cita um corpo de trabalho que deixa isso concreto:

• Você pode remover a maioria dos pesos treinados depois do treino com perda mínima de desempenho (Gale et al. 2019; Han et al. 2015; Evci et al. 2019; Hooker et al. 2020). É o conhecido resultado de sparsity / pruning.
• Mas — e aqui está o enigma — você não consegue atingir o mesmo desempenho se começar com a rede menor desde o início. Os pesos extras estão fazendo algo durante o treino que não fazem na inferência.
• Denil et al. (2014) mostraram que um pequeno conjunto de pesos pode ser usado para prever 95% dos pesos numa rede. O espaço é enormemente redundante.

A explicação mais simples é desconfortável: redes profundas são aprendizes incrivelmente ineficientes da cauda longa. Padrões frequentes são aprendidos cedo e barato. Os raros — exatamente aqueles que fazem um modelo parecer "inteligente" em casos extremos — exigem uma fatia desproporcional do compute e uma fatia desproporcional dos pesos, em grande parte porque treinamos com minimização de loss média e exposição igual entre exemplos. O sinal de atributos raros se dilui em atualizações de batch.

Hooker chama isso de "construir uma escada para a lua" — tecnicamente progredindo, mas com uma estrutura de custo que não pode continuar dando retorno. Se você aceita esse diagnóstico, as próximas três alavancas não são otimizações opcionais. São a fronteira real.

2. Qualidade dos dados: a alavanca em que todo mundo subinveste

Qualidade dos dados compensa compute. Hooker monta um grande corpo de evidência — deduplicação, data pruning, priorização de dados — mostrando que corpora de treino melhor curados reduzem a contagem de parâmetros necessária para atingir uma dada barra de capacidade. Conforme Marion et al. (2023), Penedo et al. (2023), Singh et al. (2024b) e outros, datasets menores bem curados conseguem igualar ou bater os maiores usados de forma ingênua. O tempo de treino cai diretamente, e a economia de compute é estrutural, não incremental.

Por que a indústria cronicamente subinveste aqui? Três razões familiares a qualquer um que tenha tocado um time de ML:

1. Trabalho de curadoria não cabe num planejamento trimestral. "Limpar dados" é um verbo que não cabe num slide de roadmap. "Treinar um modelo 10× maior" cabe.
2. Compute se compra; dados curados se constroem. Você pode transferir dinheiro para a NVIDIA e ter GPUs no próximo trimestre. Você não pode transferir dinheiro e ter um corpus limpo, deduplicado, balanceado e com licenciamento claro no próximo trimestre.
3. As métricas de sucesso são gameadas. Melhorias de benchmark vindas de qualidade de dados se parecem idênticas no gráfico a melhorias de benchmark vindas de escala, então o crédito vai para quem foi mais barulhento sobre scaling, e não para o time de dados que silenciosamente fez a deduplicação.

A mudança que Hooker descreve — de dados como snapshot congelado (MNIST, ImageNet, SQuAD) para dados como objeto maleável e otimizado — é uma das mudanças de paradigma mais importantes do ensaio. É também onde os retornos mais assimétricos existem para times que não têm orçamento de hyperscaler mas têm expertise de domínio. Voltaremos a isso na Parte 3 sob "o espaço de dados maleável".

3. Técnicas algorítmicas: a composição silenciosa

A terceira alavanca é a mais subestimada, principalmente porque não vem como um grande breakthrough, mas como um gotejar contínuo de técnicas que individualmente parecem otimizações menores. Hooker enumera uma lista parcial do que compensou compute bruto nos últimos anos:

• Instruction fine-tuning. Ensinar modelos a seguir instruções em cima do pré-treino.
• Distillation a partir de teachers maiores. Um "student" pequeno e capaz treinado com dados sintéticos de um "teacher" maior pode aproximar o teacher a uma fração do custo de inferência.
• Chain-of-thought reasoning. Um padrão de prompting e treino que melhora o desempenho em múltiplos passos sem mudança no compute de treino.
• Maior comprimento de contexto. Mudanças arquiteturais e de atenção que permitem ao mesmo modelo condicionar-se em muito mais informação no tempo de inferência.
• Retrieval-augmented generation. Terceirizar a cauda longa de fatos para uma camada de retrieval. Reduz alucinação, reduz a necessidade de memorizar, reduz a pressão sobre parâmetros.
• RLHF e treino por preferência. Constitutional AI, DPO, RLOO e outras variantes mudam comportamento substancialmente sem proporcionalmente mais parâmetros.

Davidson et al. (2023) estimam que técnicas puramente de compute em tempo de inferência podem entregar melhorias de 5×–20× sobre o desempenho base pós-treino. Vale parar nesse número. Uma melhoria de 10× em capacidade que exige zero retraining é o tipo de coisa que quebra roadmaps de "modelo maior no próximo ano".

Para times de engenharia, a lição prática é: a maior parte do seu roadmap de IA deveria ser algorítmica, não de capacidade. Você ganhará mais alavancagem adicionando uma camada de retrieval bem implementada, um passo de verificação, um modelo distilled específico para a tarefa ou uma estrutura de prompt chain-of-thought do que esperando a próxima classe de tamanho de modelo.

4. Arquitetura: a definidora do teto

Arquitetura é a alavanca que todo mundo subestima porque se move raramente. Mas quando se move, reseta toda scaling law que veio antes. Hooker é direta:

Um novo design de arquitetura pode mudar fundamentalmente a relação entre compute e desempenho e tornar irrelevante qualquer scaling law existente.

Temos os recibos históricos. CNNs mudaram a relação para visão (Ciresan et al. 2011; Krizhevsky et al. 2012; Szegedy et al. 2014). Transformers mudaram a relação para linguagem (Vaswani et al. 2017). Cada uma dessas foi uma mudança de paradigma que tornou as curvas de compute-desempenho anteriores obsoletas e destravou uma década inteira de trabalho subsequente.

Estamos quase certamente devendo outra. O ensaio é direto ao dizer que a arquitetura atual "mostra todos os sinais de plateau nos retornos de compute adicional" e que "o próximo passo significativo à frente exigirá uma arquitetura inteiramente diferente". Redes profundas são particularmente ruins em:

• Aprendizado contínuo — sofrem de esquecimento catastrófico quando novos dados interferem em comportamentos antigos.
• Especialização de conhecimento — atualizações de gradiente globais não esculpem regiões de competência da forma como sistemas biológicos o fazem.
• Eficiência amostral — precisam de exemplos vastamente mais numerosos do que uma criança humana para tarefas comparáveis.

Uma nova arquitetura que conserte sequer um desses re-embaralharia toda a paisagem. É por isso que concentrar toda a despesa de capital em escalar a arquitetura atual é, no enquadramento de Hooker, subinvestir na fonte mais provável do próximo salto.

O que isso muda para líderes de engenharia

Juntando essas quatro alavancas, eis o que eu levaria para uma conversa de planejamento no Q3 de 2026:

• Pare de ranquear modelos por contagem de parâmetros. Ranqueie por capacidade-por-token-por-dólar no seu mix real de tarefas. A correlação entre contagem de parâmetros e essa razão hoje é fraca.
• Suba data engineering no organograma. Se você não tem uma pessoa sênior dona da curadoria de dados, deduplicação, compliance de licenças e priorização, está deixando a maior alavanca gratuita no chão.
• Trate melhorias algorítmicas como o primeiro movimento default. Antes de encomendar um fine-tune ou um deploy de modelo maior, esgote: retrieval, estrutura de prompt, passos de verificação, distillation, uso de ferramentas, chain-of-thought. A maioria dos times desiste dessa camada cedo demais.
• Acompanhe mudanças de arquitetura a sério. Quando a próxima arquitetura pós-transformer chegar (e vai chegar), os times que sobreinvestiram em infraestrutura no formato transformer — pipelines, ops, compromissos com fornecedores — serão os mais lentos para se adaptar. Diversidade arquitetural no seu stack é um hedge.
• Não confunda "estratégia de IA" com "seleção de modelo". O modelo é uma decisão entre muitas. Os dados, o retrieval, a verificação, o design human-in-the-loop — é aí que o trabalho diferenciado acontece.

O enquadramento de Hooker — taxa de retorno por unidade de compute — é o certo para internalizar. Move a conversa de "quão grande" para "quanta capacidade por unidade de custo, e quais são as alavancas que a movem". Essa é uma conversa que times de engenharia podem de fato ganhar, e que CFOs podem de fato precificar.

---

A seguir nesta série: Além do scaling — os novos espaços de otimização para o progresso da IA. Métodos livres de gradiente, compute em tempo de inferência como alavanca de primeira classe, o espaço de dados maleável, sistemas agênticos, e o que a morte do scaling significa (e não significa) para o impacto ambiental.