Huginn supera a Ouro en los 10 benchmarks en una comparativa de LLM looped

Los modelos de lenguaje looped ahorran parámetros, pero hasta ahora no estaba claro qué decisiones arquitectónicas explican la mejora. Un nuevo trabajo, la primera parte de la serie «Towards Looped Models Done Right», separó esas decisiones y probó cada una por separado. El resultado: con 730M parámetros y 336B tokens, la arquitectura completa al estilo Huginn superó a Ouro en los diez benchmarks. En la versión MoE 8BA0.8B (32BA3B en su forma expandida), entrenada con 500B tokens, Huginn vuelve a ir por delante en casi todos los tests. Con los mismos FLOPs en entrenamiento e inferencia, utiliza un 75% menos de parámetros residentes que una MoE feedforward de 112 capas.

Tres ejes que antes iban unidos

Un modelo looped reutiliza los mismos bloques físicos de Transformer en distintos pasos de profundidad lógica. Un único conjunto de pesos se ejecuta varias veces, y la red «piensa» más a fondo sin que aumente el número de parámetros. En las arquitecturas existentes, tres decisiones están acopladas entre sí. La primera: en qué punto de la pila se sitúa la recurrencia. La segunda: cómo se reinyecta la entrada original en cada iteración. La tercera: cómo se organiza el estado recurrente. Por eso, al comparar dos modelos ya hechos, no se puede saber qué fue lo que funcionó.

Los autores separaron estos ejes. Entrenaron los modelos desde cero con la misma escala de parámetros, la misma profundidad lógica y presupuestos de tokens iguales. Después comprobaron si las conclusiones se trasladan a modelos MoE, donde coinciden tanto los parámetros residentes como los activos.

Qué mostraron los experimentos

La mejor configuración fue el «sándwich»: un bloque de entrada (prelude), un bloque recurrente y uno de salida (coda). Mejora de forma consistente la recuperación de información del contexto y las tareas que exigen razonamiento. La input injection, es decir, volver a introducir la entrada dentro del bucle, ayuda sobre todo a recuperar conocimiento y a aprovechar mejor el contexto. La inicialización aleatoria del estado y la separación de los estados recurrentes H y L dieron resultados mixtos o negativos. La combinación de estos hallazgos es el diseño de Huginn.

Las cifras clave del trabajo:

• 730M parámetros, 336B tokens: la arquitectura completa de Huginn supera a Ouro en los 10 benchmarks.
• MoE 8BA0.8B (32BA3B expandida), 500B tokens: Huginn supera a Ouro en casi todos los tests de conocimiento, razonamiento y programación.
• El enrutamiento de expertos de Huginn está más equilibrado que el de Ouro.
• Con los mismos FLOPs en entrenamiento e inferencia, Huginn utiliza un 75% menos de parámetros residentes que una MoE feedforward de 112 capas.
• Frente a esa base, el modelo looped gana en DROP y GSM8K, empata en MATH500 y se mantiene competitivo en el resto de los tests.

La transferencia a MoE merece una mención aparte. Las arquitecturas looped suelen probarse en modelos densos, y una mejora a esa escala no garantiza que el diseño sobreviva al paso a los expertos. Aquí sí lo hace, y eso refuerza de forma notable el argumento a favor de Huginn.

Qué cambiar en la práctica

La principal ventaja está en la memoria. Los parámetros residentes determinan cuántos pesos hay que mantener en el acelerador, mientras que los pasos repetidos consumen cómputo, no memoria. Si la inferencia está limitada por la capacidad de memoria y no por los FLOPs, una MoE looped con una cuarta parte de los parámetros residentes parece una alternativa seria a una pila feedforward profunda. Sobre todo cuando importan las tareas aritméticas y de lectura como GSM8K y DROP.

También hay reservas. El resumen del trabajo no incluye datos de latencia ni de rendimiento (throughput), y en parte de los benchmarks el modelo looped solo es «competitivo», no mejor que la base. La escala se limita a 8B parámetros residentes y 500B tokens, así que las conclusiones para modelos un orden de magnitud mayores deben verificarse por separado.

Para los equipos que construyen modelos looped, el trabajo deja una lista de comprobación breve: adoptar la topología sandwich, no renunciar a la input injection, no complicar el estado con H/L separados sin un beneficio demostrado y vigilar el equilibrio del enrutamiento de expertos. Es solo la primera parte de la serie; la continuación mostrará cuán robusto es este conjunto de decisiones.