Huginn supera o Ouro nos 10 benchmarks em comparação de LLMs looped

Modelos de linguagem looped (em loop) economizam parâmetros, mas até agora não estava claro quais decisões de arquitetura realmente geram o ganho. Um novo trabalho, a primeira parte da série «Towards Looped Models Done Right», separou essas decisões e testou cada uma individualmente. O resultado: com 730M parâmetros e 336B tokens, a arquitetura completa no estilo Huginn superou o Ouro nos dez benchmarks. Na versão MoE 8BA0.8B (32BA3B quando expandida), treinada com 500B tokens, o Huginn novamente fica à frente em quase todos os testes. Com os mesmos FLOPs no treinamento e na inferência, ele usa 75% menos parâmetros residentes que uma MoE feedforward de 112 camadas.

Três eixos que antes estavam misturados

Um modelo looped reutiliza os mesmos blocos físicos do Transformer em diferentes passos de profundidade lógica. Um único conjunto de pesos é executado várias vezes, e a rede "pensa" mais fundo sem aumentar o número de parâmetros. Nas arquiteturas existentes, três decisões estão acopladas. A primeira: em que ponto da pilha fica a recorrência. A segunda: como a entrada original é reinjetada a cada iteração. A terceira: como o estado recorrente é organizado. Por isso, ao comparar dois modelos prontos, não dá para dizer o que de fato funcionou.

Os autores separaram esses eixos. Os modelos foram treinados do zero, com a mesma escala de parâmetros, a mesma profundidade lógica e orçamentos de tokens iguais. Depois, verificaram se as conclusões se transferem para modelos MoE, nos quais coincidem tanto os parâmetros residentes quanto os ativos.

O que os experimentos mostraram

O melhor desempenho veio do "sanduíche": um bloco de entrada (prelude), um bloco recorrente e um de saída (coda). Essa estrutura melhora de forma consistente a recuperação de informações do contexto e as tarefas que exigem raciocínio. O input injection, ou seja, a nova entrega da entrada dentro do loop, ajuda principalmente na recuperação de conhecimento e no melhor aproveitamento do contexto. A inicialização aleatória do estado e os estados recorrentes separados H e L tiveram resultado misto ou negativo. A combinação dessas descobertas é o design do Huginn.

Principais números do trabalho:

• 730M parâmetros, 336B tokens: a arquitetura completa do Huginn é melhor que o Ouro nos 10 benchmarks.
• MoE 8BA0.8B (32BA3B quando expandido), 500B tokens: o Huginn supera o Ouro em quase todos os testes de conhecimento, raciocínio e programação.
• O roteamento dos especialistas no Huginn é mais equilibrado que no Ouro.
• Com os mesmos FLOPs no treinamento e na inferência, o Huginn usa 75% menos parâmetros residentes que uma MoE feedforward de 112 camadas.
• Contra essa base, o modelo looped vence em DROP e GSM8K, empata em MATH500 e continua competitivo nos demais testes.

A transferência para MoE merece destaque à parte. Arquiteturas looped costumam ser testadas em modelos densos, e um ganho nessa escala não garante que o design sobreviva à transição para especialistas. Aqui, ele sobrevive, o que reforça de forma notável o argumento a favor do Huginn.

O que muda na prática

O principal benefício está na memória. Os parâmetros residentes determinam quantos pesos precisam ficar no acelerador, e as passagens repetidas consomem computação, não memória. Se a inferência é limitada pelo volume de memória, e não pelos FLOPs, um MoE looped com um quarto dos parâmetros residentes parece uma alternativa séria a uma pilha feedforward profunda. Isso vale sobretudo onde pesam tarefas aritméticas e de leitura, como GSM8K e DROP.

Há ressalvas. O resumo do trabalho não traz dados de latência nem de vazão, e em parte dos benchmarks o modelo looped é apenas "competitivo", não melhor que a base. A escala se limita a 8B parâmetros residentes e 500B tokens, então as conclusões para modelos uma ordem de grandeza maiores precisam ser verificadas separadamente. Para equipes que constroem modelos looped, o trabalho deixa um checklist curto: adotar a topologia sanduíche, não abrir mão do input injection, não complicar o estado com H/L separados sem benefício comprovado e acompanhar o equilíbrio do roteamento dos especialistas. Esta é apenas a primeira parte da série; a continuação mostrará quão robusto é esse conjunto de decisões.