100 millions de tokens : mémoire o mirage ?
Essayons de raisonner par images. Cent millions de tokens n'est pas un nombre que le cerveau humain parvient à visualiser spontanément, il nous faut donc une ancre. Un token, dans le jargon des modèles de langage, correspond approximativement à trois quarts d'un mot anglais. Dix mille tokens représentent environ soixante-quinze pages de texte. Un million de tokens équivaut à l'intégralité de la *Recherche de Proust, cette œuvre en sept volumes que presque tout le monde prétend avoir lue. Dix millions de tokens couvrent l'œuvre complète de Shakespeare plus la Bible plus quelques encyclopédies de taille moyenne. Cent millions de tokens, c'est de l'ordre d'une petite bibliothèque universitaire, disons soixante mille romans de longueur moyenne chargés dans un seul contexte actif, disponibles simultanément pour un modèle de langage qui répond à des questions.*
C'est l'affirmation centrale du projet Memory Sparse Attention (MSA), publié par l'équipe d'EverMind en mars 2026 sur Zenodo et accompagné d'un dépôt GitHub qui compte actuellement plus de 3000 étoiles. L'affirmation est nette : une architecture capable de faire grimper la mémoire contextuelle jusqu'à 100 millions de tokens tout en maintenant une dégradation des performances inférieure à 9 % par rapport au point de départ. Pour ceux qui travaillent avec des modèles de langage en 2026, où la limite pratique de l'attention pleine se situe encore entre 128 000 et un million de tokens avant que les choses ne commencent à se détériorer sérieusement, c'est un chiffre qui mérite attention. Il mérite aussi quelques questions.
Le goulot d'étranglement qui freine tout
Pour comprendre ce que propose MSA, il faut d'abord comprendre pourquoi le problème existe. Les Transformers, l'architecture sur laquelle reposent pratiquement tous les grands modèles de langage contemporains, présentent un défaut structurel connu : l'attention à pleine densité croît de manière quadratique par rapport à la longueur du contexte. En termes pratiques, cela signifie que doubler le contexte ne double pas le coût de calcul, il le quadruple. À 128 000 tokens, la situation est déjà complexe ; à un million, elle devient prohibitive ; à cent millions, elle est tout simplement impossible avec l'architecture standard, quelle que soit la quantité de GPU déployée.
Les solutions existantes se divisent grossièrement en trois familles, dont aucune n'est satisfaisante. La première est la compression des états latents, comme dans les architectures linéaires ou hybrides (Mamba, Jamba et consorts), qui réduisent la complexité de calcul mais ont tendance à perdre de l'information progressivement, comme une photocopie d'une photocopie d'une photocopie. La deuxième est la mémoire externe via le RAG (Retrieval-Augmented Generation) : on conserve hors du contexte actif un corpus de documents et on récupère les morceaux pertinents au moment de la requête. Cela fonctionne, c'est déjà en production partout, mais cela introduit une discontinuité structurelle : la récupération et la génération sont deux systèmes séparés, entraînés séparément, optimisés séparément, et cette séparation a un coût en termes de cohérence et de raisonnement multi-hop. La troisième famille est l'extension brute du contexte, qui subit tous les problèmes quadratiques mentionnés plus haut.
MSA se propose d'occuper un quatrième espace, jusqu'ici peu exploré : un mécanisme d'attention éparse entraîné end-to-end, qui intègre le retrieval directement dans l'architecture du Transformer sans rompre la chaîne différentiable. L'intuition est brillante. L'exécution demande examen.
Le cerveau à deux vitesses
L'architecture MSA s'inspire, du moins métaphoriquement, de quelque chose de similaire à la distinction neuropsychologique entre mémoire de travail et mémoire à long terme. Ce n'est pas une nouveauté conceptuelle absolue, mais la manière dont elle est mise en œuvre présente certaines caractéristiques originales.
Le point de départ est la séparation physique de la mémoire. Lorsqu'un document est traité par MSA, le modèle produit trois types de représentations compressées : les routing keys (Kᵣ), les content keys (K̄) et les content values (V̄). Les routing keys sont des vecteurs très compressés, légers, conçus pour faire une seule chose : répondre rapidement à la question "ce document est-il pertinent pour la requête actuelle ?". Leur place est dans la VRAM du GPU, où la latence d'accès est de l'ordre de la microseconde. Le contenu complet, clés et valeurs K̄/V̄, est quant à lui déplacé dans la RAM système du CPU, beaucoup plus abondante et bien moins coûteuse, mais plus lente. Lorsque le router décide qu'un document est pertinent, ce n'est qu'à ce moment-là que ce contenu est transféré de la RAM vers la VRAM pour participer au calcul de l'attention.
Ce schéma, que l'équipe appelle Memory Parallel, permet de distribuer la phase de routing sur plusieurs GPU en parallèle : chacun gère une portion des routing keys, les requêtes sont diffusées en broadcast, les scores de pertinence sont agrégés, et seuls les documents top-k sélectionnés sont effectivement chargés. Le tout, affirment les auteurs, sur une configuration de seulement deux GPU NVIDIA A800.
Le deuxième élément architectural pertinent est le document-wise RoPE, une variante des embeddings de position rotatifs (RoPE) utilisés dans les Transformers modernes. Le problème avec le RoPE standard dans les contextes très longs est que le modèle, entraîné sur des séquences courtes, "ne sait pas" comment interpréter les positions très élevées qui apparaissent lors de l'inférence sur des contextes longs, ce qui entraîne une dégradation des performances. La solution proposée par MSA est simple : le compteur de position est remis à zéro au début de chaque document. Chaque texte commence toujours à la position zéro, quel que soit le nombre de documents qui le précèdent en mémoire. Cela permet à un modèle entraîné sur des séquences de 64 000 tokens d'en extrapoler 100 millions sans jamais voir de positions hors distribution.
Le choix est intelligent, mais il introduit une conséquence qui mérite d'être notée : les documents en mémoire deviennent, d'un point de vue positionnel, indiscernables les uns des autres dans l'ordre. Le modèle sait ce qu'il y a à l'intérieur de chaque document, mais il n'a pas de signal positionnel indiquant quel document est "plus récent" ou "plus ancien" dans la séquence temporelle absolue. Pour les applications où l'ordre chronologique compte, c'est une limite réelle que l'article ne reconnaît qu'implicitement.
Memory Interleave : raisonnement ou récupération intelligente ?
Le troisième pilier de l'architecture est probablement le plus intéressant du point de vue du raisonnement, et aussi celui qui soulève les questions les plus difficiles. Il s'appelle Memory Interleave, et s'attaque à un problème que les systèmes RAG traditionnels gèrent mal : les questions multi-hop.
Une question multi-hop est une question dont la réponse nécessite de relier des informations éparpillées dans différents documents, où l'information du document B est nécessaire pour comprendre quelle partie du document C chercher. "Qui était le réalisateur du film préféré de l'écrivain qui a remporté le prix Booker en 1981 ?" est un exemple banal : il faut au moins trois étapes, et chaque étape dépend du résultat de la précédente. Un système RAG qui récupère des documents une seule fois, avant de générer, a structurellement du mal avec ce type de raisonnement. Il peut récupérer cinq documents, en espérant qu'ils contiennent tout le nécessaire, mais c'est un pari aveugle.
Memory Interleave propose au contraire un cycle itératif : le modèle alterne des phases de "generative retrieval" (il produit les identifiants des documents qu'il veut lire), des phases de récupération effective de ces documents, et des phases de génération partielle, jusqu'à ce qu'il ait assez de preuves pour répondre. Le nombre de documents récupérés pour chaque tour est déterminé dynamiquement par le modèle lui-même, et non par un hyperparamètre fixe. Les expériences d'ablation dans l'article montrent que la suppression de Memory Interleave provoque une chute moyenne de 5,3 points de pourcentage sur les benchmarks QA, et de 19,2 points sur le seul HotpotQA, un jeu de données spécifiquement conçu pour le raisonnement à deux sauts.
Ces chiffres sont convaincants, mais une question journalistique pertinente surgit ici, que l'article ne résout pas explicitement : Memory Interleave améliore-t-il le raisonnement du modèle, ou améliore-t-il simplement le retrieval ? La distinction n'est pas académique. Si l'effet est principalement que le modèle récupère des informations plus utiles grâce aux itérations, alors la capacité de raisonnement sous-jacente reste celle du backbone Qwen3-4B, et les améliorations sur HotpotQA reflètent un retrieval plus intelligent, et non une capacité inférentielle supérieure. Si, en revanche, le mécanisme itératif permet au modèle de construire des chaînes de raisonnement plus complexes que celles qu'il pourrait construire avec toutes les informations déjà présentes dans le contexte, alors nous sommes face à quelque chose de structurellement nouveau.
L'article ne fournit pas d'expériences qui distinguent nettement ces deux scénarios, et le fait que MuSiQue — le jeu de données de raisonnement multi-hop à trois étapes ou plus — affiche le score absolu le plus bas de tout le tableau (2,211 sur 5) suggère que, à mesure que la complexité inférentielle croît, les gains diminuent. Ce n'est pas une critique, c'est un domaine ouvert que la recherche ultérieure devra explorer.
Les chiffres à la loupe
Passons aux benchmarks, qui méritent une attention particulière et un œil critique. La configuration expérimentale décrite dans le dépôt GitHub utilise neuf jeux de données de question answering (MS MARCO, Natural Questions, DuReader, TriviaQA, NarrativeQA, PopQA, 2WikiMultiHopQA, HotpotQA, MuSiQue) avec des banques de mémoire allant de 277 000 à 10 millions de tokens, plus les tests NIAH (Needle-in-a-Haystack, dans la version RULER) jusqu'à un million de tokens. Le backbone (modèle de base) est Qwen3-4B-Instruct, un modèle de quatre milliards de paramètres de 2025.
Les résultats en comparaison avec le RAG sur le même backbone sont véritablement impressionnants : MSA obtient un score moyen de 3,760 sur 5 contre 3,242 pour le meilleur RAG avec reranker, soit une amélioration relative de 11,5 %. Sur MS MARCO, le jeu de données avec la plus grande banque de mémoire (7,34 millions de tokens), l'écart se creuse notablement : 4,141 contre 3,032, soit environ 37 % d'avantage. Sur HotpotQA, MSA surpasse le RAG+reranker d'environ 4 %. Sur NarrativeQA, cependant, il perd : le RAG avec reranker obtient 3,638 contre 3,395 pour MSA, le seul jeu de données sur neuf où MSA n'est pas le meilleur dans la comparaison à backbone égal.
La comparaison avec des systèmes RAG sur des backbones beaucoup plus grands (KaLMv2 avec Qwen3-235B et avec Llama-3.3-70B) est plus nuancée. MSA avec 4B de paramètres obtient la meilleure moyenne absolue (3,760) mais perd sur quatre jeux de données sur neuf par rapport aux configurations les plus fortes, et l'avantage moyen sur Qwen3-235B avec reranker est de 5 %. En pratique, un modèle soixante fois plus petit tient tête à un colosse de 235 milliards de paramètres lorsque l'avantage architectural dans la gestion de la mémoire est suffisamment grand pour compenser la différence d'échelle. C'est un résultat remarquable, mais il doit être lu sans hyperbole.
Deux aspects de la configuration expérimentale méritent cependant d'être déclarés explicitement, car ils conditionnent la lecture des chiffres. Premièrement : la métrique d'évaluation pour les benchmarks QA est un juge LLM qui attribue des notes de 0 à 5. Ce type d'évaluation, bien qu'il soit devenu standard dans le domaine, comporte une variabilité intrinsèque, et le fait que le modèle juge ne soit pas spécifié dans le README ajoute une opacité qui ne serait pas acceptable dans un article révisé par les pairs. Deuxièmement : le benchmark de scalabilité principal, la courbe 16K→100M tokens avec moins de 9 % de dégradation, est mesuré sur MS MARCO, un seul jeu de données. La généralisation de cette courbe à d'autres types de contenu, distributions de questions, ou langues autres que l'anglais reste à démontrer.
Sur le front NIAH, les résultats sont plus nets et plus faciles à évaluer : MSA maintient 94,84 % de précision à un million de tokens, alors que le backbone non modifié s'effondre à 24,69 %. Les modèles à attention linéaire hybride (la concurrence la plus directe) montrent une dégradation appréciable dès 128 000-256 000 tokens. C'est le résultat le plus solide de l'article, car le benchmark NIAH est standardisé, largement utilisé par la communauté et laisse peu de place à l'ambiguïté d'interprétation.
Au moment où nous écrivons ces lignes, le code est publiquement disponible sur le dépôt GitHub, avec des instructions d'installation, le modèle MSA-4B téléchargeable directement depuis Hugging Face et les benchmarks reproductibles par script. C'est un signe de maturité non négligeable : cela signifie que les résultats sont en principe vérifiables par quiconque dispose du matériel adéquat, et que la communauté peut commencer à tester le système sur ses propres cas d'usage.
100 millions de tokens sur 2×A800 : à quel prix ?
La "complexité quasi linéaire" est l'une des expressions les plus galvaudées dans le vocabulaire de la recherche sur les Transformers, et elle nécessite presque toujours une traduction. Dans le cas de MSA, la complexité formelle d'O(L) se réfère à la phase de routing et d'attention éparse, mais cache une série de coûts concrets qu'un article sérieux ne peut ignorer.
Le premier coût est la latence de récupération (fetch) depuis la mémoire CPU. Lorsque le router décide quels documents charger, ces données doivent être transférées de la RAM système vers la VRAM du GPU via le bus PCIe, qui a une bande passante typique de 16-32 Go/s. Pour cent millions de tokens, même avec une compression agressive du cache KV, la taille des données à transférer par requête peut être de l'ordre du gigaoctet. L'article ne mentionne pas de chiffres explicites de latence de bout en bout pour une seule requête, et c'est une omission importante pour quiconque souhaite évaluer la faisabilité en production.
Le deuxième coût est la phase d'encodage offline. Avant que MSA puisse répondre à une question sur un corpus, il doit traiter tous les documents de ce corpus pour produire les représentations K̄, V̄ et Kᵣ. C'est un coût ponctuel pour les corpus statiques, mais cela devient un problème récurrent pour les corpus qui se mettent à jour fréquemment, comme les historiques de conversation dans une application d'agent ou les flux de données d'entreprise en temps réel. L'article décrit cela comme un encodage offline, ce qui suggère que l'architecture est pensée principalement pour des corpus relativement stables.
Le troisième coût est celui de la mémoire persistante. Un corpus de 100 millions de tokens, même avec une compression agressive, nécessite des quantités importantes de RAM système. Sans chiffres spécifiques de l'article sur les ratios de compression effectifs et les tailles résultantes du cache KV compressé, il est difficile d'estimer les coûts d'infrastructure précis, mais pour un déploiement d'entreprise sur des corpus réels, nous sommes probablement de l'ordre de centaines de gigaoctets de RAM. Pas impossible, mais pas anodin.
Cela amène à la question centrale, qu'il convient de formuler explicitement : MSA résout-il le goulot d'étranglement de la mémoire, ou déplace-t-il la complexité vers le stockage, le retrieval et l'orchestration ? La réponse honnête est que les deux sont vrais en même temps. MSA allège véritablement le problème de la complexité quadratique de l'attention, en intégrant le retrieval de manière différentiable et en obtenant de meilleurs résultats que le RAG sur pratiquement tous les benchmarks testés. Mais il n'élimine pas la complexité infrastructurelle : il la distribue sur différents composants, dont certains (le transfert CPU-GPU, la gestion de la RAM, l'encodage offline) ne sont pas encore bien documentés dans le matériel public disponible. Pour une équipe de recherche, c'est un progrès réel. Pour une équipe d'ingénierie qui doit le mettre en production, des questions restent ouvertes.
EverMind : la mémoire comme service
Il est utile de comprendre qui se cache derrière MSA, car la lecture du projet change sensiblement selon le contexte. EverMind est une startup basée à Singapour, fondée avec l'objectif affiché de construire une infrastructure de mémoire à long terme pour les agents IA. Son produit principal est EverOS, un système de gestion de mémoire pour agents qui intègre diverses techniques, dont MSA, dans une plateforme plus large. L'équipe a publié fin mars 2026 des résultats sur quatre benchmarks de mémoire (LoCoMo, LongMemEval, PersonaMem et un framework d'évaluation propriétaire) revendiquant des performances à l'état de l'art.
La trajectoire est celle d'une startup qui construit ce que l'on appelle dans le jargon du secteur le "Memory-as-a-Service" : une couche d'abstraction qui s'insère entre les modèles de langage de base et les applications, gérant la persistance, la récupération et l'organisation des souvenirs de l'agent dans le temps. C'est un positionnement industriel cohérent, et MSA en est la base technique.
Le fait que l'article ait été publié sur arXiv, et non sur une plateforme mineure, et que le code soit déjà disponible publiquement sur GitHub, avec le modèle MSA-4B téléchargeable directement depuis Hugging Face et les benchmarks exécutables via script, est un signe de maturité non négligeable. Les résultats sont en principe vérifiables par quiconque dispose du matériel adéquat, et la communauté peut commencer à tester le système sur ses propres cas d'usage. La recherche est communiquée publiquement et les actifs techniques sont ouverts : pour une startup en phase de démarrage, ce n'est pas la norme, et c'est un élément qui pèse positivement dans l'évaluation globale du projet.
Les treize auteurs de l'article (dont Chen Yu, Chen Runkai, Yi Sheng et d'autres, avec Lidong Bing et Tianqiao Chen comme figures senior) représentent une équipe de taille et de profil crédibles pour le type de travail décrit. Il n'y a pas, pour l'instant, d'évaluations indépendantes des résultats par des groupes de recherche tiers, ce qui est normal pour un article vieux de quelques mois, mais c'est un élément à garder à l'esprit lors de la lecture des pourcentages d'amélioration.
Proof-of-concept élégant ou système prêt ?
C'est la question que tout article honnête sur ce type de recherche doit se poser, et la réponse ici est en demi-teinte. MSA est, en l'état actuel, un système décrit de manière convaincante, avec des résultats de benchmarks crédibles sur un ensemble de tests suffisamment large pour ne pas être taxé de cherry picking (sélection partiale), et avec une architecture qui possède une logique interne cohérente et bien motivée. Ce n'est pas une promesse en l'air.
Dans le même temps, ce n'est probablement pas encore un système prêt pour la production au sens ingénierie du terme. Les benchmarks de scalabilité à 100 millions de tokens sont démontrés sur un seul jeu de données (MS MARCO), et la dégradation réelle sur d'autres types de contenu à cette échelle est inconnue. Les performances sur NarrativeQA, le jeu de données avec les histoires les plus longues et la compréhension la plus contextuelle, sont le seul cas où MSA perd face au RAG avec reranker, suggérant que les contenus narratifs denses pourraient être un point faible. La latence des requêtes de bout en bout, le coût d'encodage du corpus et les exigences de RAM système ne sont pas communiqués avec la précision nécessaire à une évaluation d'ingénierie.
Il y a aussi une question plus subtile sur la portabilité. Tous les résultats sont obtenus sur Qwen3-4B, un backbone spécifique avec des caractéristiques spécifiques. MSA nécessite d'entraîner le router et le mécanisme d'attention éparse end-to-end : ce n'est pas quelque chose qui se greffe sur n'importe quel modèle pré-entraîné comme un plugin. L'article décrit un entraînement sur 158,95 milliards de tokens avec une perte auxiliaire de routing, suivi de deux phases de fine-tuning supervisé avec un curriculum de 8 000 à 64 000 tokens. Repliquer ce processus sur un backbone différent (Llama, Mistral, Gemma) nécessiterait des ressources et du temps considérables, et il n'est pas garanti que les résultats soient identiques.
Disco Elysium, le jeu de rôle narratif de ZA/UM, construit son système de mémoire sur des fragments, des murmures, des souvenirs que le protagoniste récupère de manière itérative et souvent peu fiable pour reconstruire une histoire plus vaste. MSA, d'une certaine manière, fait quelque chose de similaire : il récupère des fragments épars d'une bibliothèque immense, les assemble itérativement, tente de construire un raisonnement cohérent. La différence est que dans le jeu, l'échec du retrieval fait partie du récit ; dans un système de production, c'est un bug. À quelle fréquence MSA échoue-t-il à récupérer les bons fragments, et avec quelles conséquences ? C'est exactement le type de question auquel seuls le code public et l'expérimentation indépendante peuvent répondre.
MSA mérite attention, étude et expérimentation directe. La question de savoir s'il résout réellement le goulot d'étranglement de la mémoire ou s'il le déplace simplement vers l'infrastructure, le stockage et l'orchestration n'a pas encore de réponse définitive, et n'en aura probablement pas tant que quelqu'un en dehors d'EverMind n'aura pas pu le démonter et le remonter sur un cas d'usage réel. En attendant, c'est l'une des architectures les plus intéressantes apparues cette année dans le domaine de la mémoire pour les modèles de langage, et le dépôt GitHub vaut déjà la peine d'être suivi de près.