Google apprend aux LLM à « dormir » : SLEEP ancre les connaissances dans les poids, jusqu'à 10 millions de tokens

Google Research a publié SLEEP, un framework qui propose une nouvelle approche de l'apprentissage continu pour les modèles de langage. L'ingestion des nouvelles données et leur consolidation y sont séparées dans le temps, comme la veille et le sommeil chez l'humain. Pendant le « sommeil », les connaissances de la mémoire temporaire sont transférées dans les poids de blocs MoE supplémentaires. Lors des expériences, l'équipe a fait fonctionner le système sur des séquences allant jusqu'à 10 millions de tokens sur BABILong. Elle a aussi mesuré une chute de qualité quasi nulle lors de l'apprentissage séquentiel de la traduction, ainsi que 79,2% sur AIME 2024 contre 69% sur AIME 2025.

Deux trous dans la mémoire du modèle

L'apprentissage continu se heurte à deux problèmes anciens. Le premier s'appelle l'oubli catastrophique : le modèle assimile de nouvelles informations et perd des compétences acquises auparavant. Les mises à jour par gradient pour la nouvelle tâche écrasent les poids importants pour les anciennes.

Le second problème tient au fait que les connaissances présentes dans la fenêtre de contexte ne se transforment pas d'elles-mêmes en mémoire permanente. Tant que l'information reste dans le prompt, le modèle l'utilise. Quand le contexte se termine, tout disparaît. Un contexte long coûte en outre cher : il faut le retraiter et le conserver en mémoire de travail à chaque requête. Si les connaissances sont écrites dans les paramètres, elles n'occupent plus de contexte et restent accessibles sans être soumises de nouveau.

Éveil, sommeil et « rêves »

SLEEP alterne deux modes.

• Éveil. Le modèle travaille sur les données d'entrée et stocke l'information dans la mémoire à court terme.
• Sommeil. L'ingestion de nouvelles données est suspendue. Le modèle active des blocs de mémoire MoE supplémentaires et y transfère les connaissances, afin de perturber le moins possible les informations déjà consolidées. Une fois le transfert terminé, la mémoire temporaire est libérée.

Une étape distincte est appelée « rêves ». Des combinaisons aléatoires d'experts génèrent des exemples d'entraînement. Le système sélectionne les plus utiles et s'en sert pour poursuivre l'apprentissage. En somme, le modèle prépare lui-même son matériel de consolidation, sans jeu de données externe à chaque cycle.

La description comporte une réserve importante : le « sommeil » est ici un cycle de fine-tuning contrôlé, régi par des règles que fixent les chercheurs. L'architecture et le code du modèle restent figés. Ce n'est pas un organisme auto-évolutif, mais une procédure encadrée appliquée à un modèle MoE classique.

Ce que montrent les expériences

• BABILong. Exploitation d'informations issues de séquences allant jusqu'à 10 millions de tokens, en les ancrant dans les paramètres plutôt qu'en les conservant dans le contexte.
• Apprentissage séquentiel de la traduction. Chute des résultats quasi nulle sur les langues apprises auparavant, après l'acquisition de nouvelles langues.
• AIME 2024. Précision de 79,2%.
• AIME 2025. Précision de 69%.

Le résultat le plus parlant est sans doute celui de la traduction. Les langues sont apprises l'une après l'autre, ce qui constitue un banc d'essai classique de l'oubli : c'est généralement là que la qualité sur les premières langues se dégrade le plus nettement. Les résultats en mathématiques montrent que la consolidation de nouvelles connaissances ne détruit pas la capacité de raisonnement. Notons aussi que le résultat sur AIME 2025 est inférieur à celui sur AIME 2024. L'écart entre les deux années est du même ordre que celui observé chez de nombreux modèles, et il est trop tôt pour tirer des conclusions sur ses causes à partir d'une seule publication.

Là où la pratique risque de coincer

Pour les ingénieurs, la question principale est celle du coût. Transférer des connaissances dans les poids implique des cycles de fine-tuning supplémentaires, donc du calcul à planifier : quand le modèle « s'endort », il ne traite plus les requêtes. Il faudra décider à quelle fréquence dormir, sur quel volume de mémoire accumulée, et combien de blocs MoE consacrer au stockage. Ces paramètres sont définis par les règles des chercheurs, et il faudra les ajuster soi-même à chaque charge de travail.

Le gain potentiel se situe dans l'économie du contexte. Si les connaissances d'entreprise, de longues conversations ou une base documentaire mise à jour sont consolidées dans les poids, il n'est plus nécessaire de transporter des millions de tokens dans chaque requête ni de payer pour leur retraitement. Pour les agents dotés d'un long historique de travail, c'est une économie directe de mémoire et de latence.

Un risque subsiste, que la description ne lève pas : l'écriture dans les poids est irréversible et plus difficile à auditer qu'un document placé dans le contexte ou dans une base externe. Dans les secteurs réglementés, il faudra trancher séparément la question de la suppression et de la vérification des connaissances consolidées. Pour l'instant, SLEEP doit être considéré comme un solide résultat de recherche et un bon candidat pour des tests dans des projets dont les données sont mises à jour en continu. Ce n'est pas encore un composant prêt pour la production.