Modelos de linguagem recorrentes deveriam ser a resposta para os custos de raciocínio: em vez de gerar milhares de tokens para pensar, as mesmas camadas da rede poderiam simplesmente rodar algumas voltas extras no espaço latente. A realidade é mais complicada. Quando pesquisadores escalaram o modelo recorrente Ouro, o loop em tempo de teste ajudou no início — as pontuações no AIME 2024 subiram de 0 para 65 na quarta rodada — e depois despencaram para 38,67 na oitava. Mais pensamento deixou o modelo pior. Esse colapso é a condição de contorno mais clara sobre compute em tempo de teste no campo atualmente.
Duas maneiras de fazer um modelo pensar mais
Um Transformer padrão é um prédio com andares fixos. A informação entra pela base, passa por todas as camadas e sai no topo — independentemente de a entrada ser “1+1” ou uma prova de matemática difícil. Cada token gerado percorre aproximadamente a mesma profundidade de rede. Então, quando um Transformer enfrenta um problema difícil, ele tem um único truque maduro: falar mais. O chain-of-thought serializa múltiplas passagens da rede em tokens de saída. O modelo raciocina em voz alta, confere as próprias respostas, revisa. Perguntas simples recebem poucos tokens, difíceis recebem muitos. Funciona, mas é caro — cada passo intermediário precisa ser organizado em uma sequência que o modelo possa emitir, mesmo os passos que nunca precisariam ser ditos.
Modelos com loop seguem o outro caminho. Em vez de percorrer a torre novamente, eles voltam pelas mesmas camadas e atualizam o estado oculto no lugar, reutilizando os mesmos parâmetros. Universal Transformer, Deep Equilibrium Models e a recente onda de Transformers recorrentes fazem a mesma pergunta: um modelo pode decidir internamente quantas rodadas executar, sem serializar seus pensamentos em tokens? As evidências iniciais indicam que a ideia tem futuro. Um estudo de escalabilidade de 2025 levou um modelo de profundidade recorrente a 3,5B de parâmetros treinados com 800B de tokens e, em tempo de teste, ele continuou melhorando com rodadas extras em algumas tarefas de raciocínio — até o compute de uma passagem forward de 50B de parâmetros.
Onde o loop quebra: os três obstáculos
Modelos recorrentes enfrentam três obstáculos. Primeiro: a arquitetura consegue expressar o cálculo — parâmetros compartilhados iterando sobre um estado oculto? Esse está com bom aspecto. Segundo: o treinamento consegue de fato aprender o comportamento de iteração? Terceiro — o gargalo — o modelo consegue continuar computando de forma estável em tempo de inferência?
O Ouro mostra como o terceiro obstáculo dói. No treinamento inicial, com 8 loops, houve picos de perda e oscilação de gradientes, então a equipe reduziu a profundidade de treinamento para 4 rodadas. Em tempo de teste, elevaram os loops de volta a 8 — e o compute extra comprou respostas piores. Os mesmos parâmetros compartilhados, a mesma atualização do estado oculto, e ainda assim, rodada após rodada, os erros se acumulam até que o estado pareça estável, mas já não consegue sustentar o resultado.
O acúmulo de erros é o vilão recorrente. O estudo Parcae de 2026 descobriu que modelos de linguagem recorrentes sofrem explosão residual e quedas súbitas na perda; após redesenhar os mecanismos de estabilidade dentro do loop, a perplexidade de validação melhorou até 6,3%, e com 1,3B de parâmetros o modelo superou um baseline de Transformer padrão com orçamentos fixos de parâmetros e dados. A narrativa de que “os modelos não querem aprender” tem um ponto de virada — a receita de treinamento, não a arquitetura, é o que está imaturo. Transformers padrão carregam décadas de equipamento afinado: conexões residuais, normalização, inicialização, cronogramas de taxa de aprendizado, otimizadores. Grandes modelos de linguagem recorrentes ainda estão descobrindo qual combinação de arquitetura, otimizador, perda e supervisão intermediária funciona.
Por que isso importa: a estrutura de custos do raciocínio
Este não é um debate arquitetural de nicho. Ele decide qual lado do mercado de raciocínio vence. O chain-of-thought queima tokens: barato por token, enorme em volume, e cada pensamento precisa ser serializado em saída. O loop queima rodadas: compacto e interno, mas instável além da profundidade do treinamento. Se a estabilidade do loop amadurecer, o raciocínio se torna drasticamente mais barato — sem imposto de serialização em tokens, com o compute gasto dentro da rede em vez de no fio. Se não amadurecer, o chain-of-thought permanece a única rota confiável, e o custo dos tokens segue como pedágio em todo modelo pensante. A mesma lógica fundamenta a aposta no treinamento em tempo de teste: a próxima guerra de custos na IA será travada sobre como os modelos gastam o compute extra, não apenas sobre quanto dele têm.
O lado de produto já está caminhando nessa direção: relata-se que o Astra da OpenAI aposta na profundidade recorrente para fazer do trade entre compute e capacidade cognitiva o destaque de um modelo comercial.
O que fazer a respeito
Para quem avalia modelos “pensantes”, número de rodadas e comprimento de raciocínio são métricas vaidosas — o que importa é se o compute extra muda a resposta. Para equipes que constroem sobre modelos de pesos abertos, acompanhem a literatura de treinamento recorrente: os trabalhos de estabilização no estilo Parcae são onde o próximo desbloqueio vai acontecer, e é um sinal que vale monitorar mensalmente. Para o resto de nós, a conclusão prática é mais simples: a suposição de que mais pensamento sempre ajuda está morta. A questão é qual arquitetura faz o compute extra valer a pena — e hoje, essa resposta ainda é o chain-of-thought, com os modelos recorrentes a uma receita estável de treinamento de distância para mudar isso.
