Nestor : la parcimonie imbriquée dans l'attention surpasse le MoE à budget égal

Le mixture-of-experts est depuis longtemps devenu le socle standard des grands modèles de langage : à chaque passe avant, seule une faible partie des poids est activée. Une équipe de l'Université de Hong Kong et de Berkeley propose d'ajouter une seconde couche de cette économie. Tianzhe Chu, Druv Pai et Yi Ma décrivent l'architecture Nestor, où les calculs conditionnels sont intégrés à l'opérateur d'attention et s'imbriquent dans la parcimonie du MoE. Selon leurs données, à calcul égal et parcimonie égale, Nestor affiche une meilleure qualité de pré-entraînement de modèle de langage qu'un transformer MoE classique. L'article est paru sur arXiv le 22 octobre 2026 (2610.31818), le code et les checkpoints ont été publiés.

Où se cache la seconde parcimonie dans le transformer

Dans un transformer MoE classique, la parcimonie ne vit qu'en un seul endroit. L'opérateur MoE généralise le perceptron multicouche du transformer classique : un routeur choisit quels experts traitent le token, les autres poids restant inactifs pour cette passe. Le bloc d'attention, lui, reste dense.

Les auteurs de Nestor procèdent de façon symétrique. Ils introduisent un mécanisme de calcul conditionnel qui généralise cette fois l'opérateur d'attention, et non le MLP. On obtient ainsi deux axes d'économie indépendants. Ils s'additionnent de façon hiérarchique, c'est-à-dire qu'ils s'imbriquent l'un dans l'autre, d'où le nom. Un même transformer bénéficie d'une parcimonie à la fois dans la partie attention et dans la partie MoE, et non plus dans une seule des deux.

La comparaison est construite avec soin : les modèles sont confrontés à calcul égal et parcimonie égale. Cela écarte l'objection la plus évidente, selon laquelle le gain serait acheté par des FLOPs supplémentaires ou un plus grand nombre de paramètres actifs.

Fine-tuning sur contexte long et nouveaux domaines

La partie la plus pratique du travail concerne le continual pretraining, c'est-à-dire la poursuite du pré-entraînement d'un modèle déjà prêt. Pour les laboratoires et les entreprises, c'est une opération de routine : on étend régulièrement un modèle de base à un contexte plus long, ou on le réentraîne sur un nouveau domaine métier.

Selon les résultats des auteurs, Nestor s'en sort mieux que les MoE classiques :

• il s'adapte plus efficacement à un contexte plus long ;
• il bascule plus efficacement vers de nouveaux domaines ;
• il oublie moins sur les anciens domaines.

Ce dernier point mérite une attention particulière. L'oubli catastrophique reste le principal coût du fine-tuning, et une architecture qui réduit ce coût sans recourir à des astuces séparées comme les buffers de replay intéresse tous ceux qui font transiter leurs modèles par plusieurs étapes d'entraînement.

Les auteurs ont également vérifié la mise à l'échelle. Les avantages se maintiennent avec la croissance de la taille du modèle, du volume du jeu de données et de la longueur du contexte. Pour les idées architecturales, c'est l'examen le plus décisif : beaucoup d'améliorations ont fière allure sur de petits modèles et disparaissent sur les grands.

Ce que l'on sait du travail

• Nom de l'architecture : Nestor (nested sparsity).
• Auteurs : Tianzhe Chu, Druv Pai, Yi Ma ; affiliation indiquée sur la page de l'article — The University of Hong Kong.
• Idée : un mécanisme de calcul conditionnel qui généralise l'opérateur d'attention, par analogie avec la façon dont le MoE généralise le MLP.
• Lien avec le MoE : les parcimonies s'imbriquent l'une dans l'autre de façon hiérarchique.
• Pré-entraînement : gain par rapport à un transformer MoE classique à calcul égal et parcimonie égale.
• Continual pretraining : meilleure adaptation au contexte long, transition plus efficace vers de nouveaux domaines, moins d'oubli des anciens.
• Mise à l'échelle : l'effet se maintient avec la croissance du modèle, des données et du contexte.
• Artefacts : code et checkpoints dans le dépôt GitHub Ma-Lab-Berkeley/Nestor, avec une page de projet sur ma-lab-berkeley.github.io/Nestor.

Que faire de cela pour les praticiens

Pour l'instant, il s'agit d'un article académique, sans déploiement dans des modèles industriels, et sur la page Hugging Face Daily Papers il n'a reçu qu'un seul vote. Mais le matériel est ouvert, ce qui signifie que l'idée peut être vérifiée sans négociation avec les auteurs. Les équipes qui entraînent leurs propres modèles MoE ont tout intérêt à récupérer les checkpoints et le code, et à comparer Nestor avec leur architecture de base sur des tâches d'extension de contexte et d'adaptation de domaine : c'est précisément là que l'effet annoncé est le plus important.

Pour les équipes infrastructure, une question distincte se pose : comment ce second axe de parcimonie va s'articuler avec les noyaux de calcul réels et l'entraînement distribué. Un gain à calcul égal, en théorie, ne garantit pas un gain en temps réel sur un cluster, tant qu'il n'existe pas d'implémentations optimisées pour le routage dans l'attention. Si de telles implémentations voient le jour, le MoE cessera d'être synonyme de MLP parcimonieux, et le champ des expérimentations architecturales s'élargira nettement.