Huginn devance Ouro sur les 10 benchmarks dans la comparaison des LLM bouclés

Les modèles de langage bouclés économisent des paramètres, mais on ne savait pas jusqu'ici quels choix d'architecture produisent réellement le gain. Un nouveau papier, première partie de la série « Towards Looped Models Done Right », sépare ces choix et teste chacun isolément. Résultat : à 730M de paramètres et 336B tokens, l'architecture complète de type Huginn devance Ouro sur les dix benchmarks. Dans la version MoE 8BA0.8B (32BA3B en version dépliée), entraînée sur 500B tokens, Huginn reste devant presque partout. À FLOPs égaux à l'entraînement comme à l'inférence, elle utilise 75% de paramètres résidents en moins qu'une MoE feedforward de 112 couches.

Trois axes jusqu'ici entremêlés

Un modèle looped réutilise les mêmes blocs Transformer physiques à différentes étapes de profondeur logique. Un seul jeu de poids est exécuté plusieurs fois : le réseau « réfléchit » plus profondément sans que le nombre de paramètres augmente. Dans les architectures existantes, trois choix sont liés entre eux. Premièrement, l'endroit du stack où se situe la récurrence. Deuxièmement, la manière dont l'entrée d'origine est réinjectée à chaque itération. Troisièmement, l'organisation de l'état récurrent. Résultat : en comparant deux modèles déjà finis, impossible de dire ce qui a réellement fait la différence.

Les auteurs ont dissocié ces axes. Les modèles ont été entraînés from scratch, avec la même échelle de paramètres, la même profondeur logique et des budgets de tokens égaux. Ils ont ensuite vérifié si les conclusions se transposaient à des modèles MoE, où les paramètres résidents comme les paramètres actifs coïncident.

Ce que montrent les expériences

Le « sandwich » s'est révélé le plus efficace : un bloc d'entrée (prelude), un bloc récurrent et un bloc de sortie (coda). Il améliore de façon constante l'extraction d'informations du contexte et les tâches de raisonnement. L'input injection, c'est-à-dire la réinjection de l'entrée à l'intérieur de la boucle, aide surtout à extraire des connaissances et à mieux exploiter le contexte. L'initialisation aléatoire de l'état et la séparation des états récurrents H et L ont donné des résultats mitigés, voire négatifs. La combinaison de ces constats constitue le design de Huginn.

Chiffres clés du papier :

• 730M de paramètres, 336B tokens : l'architecture Huginn complète fait mieux qu'Ouro sur les 10 benchmarks.
• MoE 8BA0.8B (32BA3B une fois dépliée), 500B tokens : Huginn devance Ouro sur presque tous les tests de connaissances, de raisonnement et de code.
• Le routage des experts est plus équilibré chez Huginn que chez Ouro.
• À FLOPs égaux à l'entraînement et à l'inférence, Huginn utilise 75% de paramètres résidents en moins qu'une MoE feedforward de 112 couches.
• Face à cette base, le modèle looped l'emporte sur DROP et GSM8K, fait jeu égal sur MATH500 et reste compétitif sur les autres tests.

Le transfert vers les MoE mérite une mention à part. Les architectures looped sont généralement testées sur des modèles denses, et un gain à cette échelle ne garantit pas que le design survivra au passage aux experts. Ici, il y survit, ce qui renforce nettement l'argument en faveur de Huginn.

Ce que cela change en pratique

L'intérêt principal tient à la mémoire. Les paramètres résidents déterminent combien de poids il faut garder sur l'accélérateur, tandis que les passes répétées consomment du calcul, pas de la mémoire. Si l'inférence est limitée par la capacité mémoire plutôt que par les FLOPs, une MoE looped avec un quart des paramètres résidents apparaît comme une alternative sérieuse à un stack feedforward profond. C'est particulièrement vrai pour les tâches arithmétiques et de lecture comme GSM8K et DROP.

Il y a aussi des réserves. L'abstract ne fournit aucune donnée sur la latence et le débit, et sur une partie des benchmarks, le modèle looped est seulement « compétitif », sans faire mieux que la base. L'échelle se limite à 8B de paramètres résidents et 500B tokens ; les conclusions pour des modèles d'un ordre de grandeur plus grands doivent donc être vérifiées séparément.

Pour les équipes qui construisent des modèles looped, le travail livre une courte check-list : adopter la topologie sandwich, ne pas renoncer à l'input injection, ne pas compliquer l'état avec des H/L séparés sans bénéfice démontré, et surveiller l'équilibre du routage des experts. Ce n'est que la première partie de la série ; la suite montrera la robustesse de cet ensemble de choix.