Pourquoi l'attention d'un Transformer coûte cher sur un contexte long

Un Transformer lit un document long token par token, mais ne les traite pas les uns après les autres comme un lecteur humain. Il compare chaque token à tous ceux qui le précèdent, pour décider où porter son attention. Ce mécanisme explique une bonne part de la performance des grands modèles de langage sur le texte. Il explique aussi pourquoi la facture de calcul grimpe vite dès que le document dépasse quelques dizaines de milliers de mots.

Ce que fait le mécanisme d’attention

Ce que les données établissent. Vaswani et al. (2017), dans “Attention Is All You Need”, introduisent l’architecture Transformer et son mécanisme central : pour chaque token d’une séquence, le modèle calcule un score de compatibilité avec chacun des tokens précédents, puis pondère l’information à retenir en fonction de ces scores. Cette comparaison systématique, token contre token, permet de capter des dépendances à longue distance — un mot en début de paragraphe qui éclaire un mot en fin de page — sans la limite des réseaux récurrents antérieurs, qui devaient faire transiter l’information séquentiellement d’un mot au suivant et la perdaient souvent en chemin. C’est ce mécanisme, plus que la taille des modèles, qui a fait basculer le traitement automatique du langage vers les Transformers après 2017.

Le problème : un coût qui grossit plus vite que le contexte

Ce que les données établissent. Comparer chaque token à tous les précédents a un coût arithmétique simple : sur une séquence de n tokens, le nombre de paires à évaluer est proportionnel à n². Doubler la longueur du contexte ne double pas le nombre de comparaisons, il le multiplie par quatre. Une séquence de 8 tokens produit 64 paires à évaluer plutôt que les 16 d’une séquence de 4 tokens : la même règle de calcul, à l’échelle d’un document de plusieurs dizaines de milliers de tokens, transforme un facteur qui semblait négligeable sur une phrase en facture de calcul considérable sur un rapport long.

Un second coût s’ajoute, de nature différente. Pour ne pas recalculer l’intégralité de la séquence à chaque nouveau token généré, un Transformer conserve en mémoire les représentations (“clés” et “valeurs”) de tous les tokens déjà traités : c’est le cache KV. Chaque token supplémentaire ajoute son propre jeu de clés et de valeurs à conserver. Cette mémoire d’inférence croît donc de façon linéaire avec la longueur du contexte — moins brutal que la croissance quadratique du calcul, mais un coût qui s’accumule sans jamais se stabiliser tant que le contexte s’allonge. Sur un document de plusieurs centaines de pages, ce cache peut représenter une part significative de la mémoire GPU mobilisée pour une seule requête.

Une nuance qui compte : ce n’est pas un problème sur la majorité des usages

Mon interprétation. Cette mécanique ne rend pas l’attention inefficace en général — elle reste, à ce jour, le standard qui a produit la quasi-totalité des grands modèles de langage en production. Le problème ne se manifeste vraiment qu’à partir de contextes très longs, de l’ordre de dizaines à centaines de milliers de tokens : un rapport financier complet, un corpus juridique, plusieurs heures de transcription. Sur un échange conversationnel ou un document de quelques pages, la charge quadratique reste modeste en valeur absolue, et l’attention traite ces volumes avec une efficacité qui n’a pas d’équivalent démontré à ce niveau de qualité. La majorité des usages actuels des LLM se situe précisément dans cette zone où le problème décrit ici reste largement théorique.

Ce que Mamba a été conçu pour changer

Ce que les données établissent. C’est exactement ce goulot d’étranglement — coût de calcul quadratique et mémoire d’inférence qui croît avec le contexte — que Gu et Dao (2023) visent avec Mamba : une architecture à espace d’état sélectif, dont la mémoire reste de taille fixe quelle que soit la longueur du contexte traité, et dont le coût de calcul croît linéairement plutôt que quadratiquement. Le mécanisme précis par lequel Mamba y parvient, et les compromis que ce choix implique, font l’objet d’une fiche dédiée plutôt que d’être détaillés ici.

Le coût de l’attention n’est pas un défaut d’implémentation à corriger : c’est une conséquence directe de ce qui fait sa force — comparer chaque token à tous les précédents. Le problème n’apparaît que lorsque cette liste de “tous les précédents” devient très longue.

Mes réserves

• Cette lecture isole la charge théorique du mécanisme d’attention lui-même. Des optimisations d’implémentation (fenêtres glissantes, attention parcimonieuse, mise en cache optimisée) atténuent ce coût en pratique sur de nombreux déploiements réels, sans changer la courbe de croissance asymptotique décrite ici — un point que cet article ne développe pas.
• Le coût quadratique concerne l’attention elle-même ; un Transformer complet inclut aussi des couches de réseau à propagation avant dont le coût croît linéairement avec la longueur du contexte. Le coût quadratique domine à mesure que le contexte s’allonge, mais il ne représente pas la totalité du calcul d’un Transformer sur un contexte court.
• L’exemple “doubler le contexte multiplie le calcul par quatre” est une illustration mathématique du mécanisme d’attention pur, pas une mesure de temps de traitement observée sur un modèle déployé, qui dépend aussi du matériel et de l’implémentation logicielle utilisés.

Concrètement, ce compromis coût/contexte devient un critère de choix d’architecture dès qu’un usage porte sur des documents très longs de façon récurrente — pas un problème à anticiper pour un usage conversationnel ou documentaire courant.

Retour au dossier Comprendre les modèles post-LLM. Voir aussi Qu’est-ce que Mamba ?