Un modèle de langage « écrit » souvent comme s'il enchaînait les mots d'un seul geste. En pratique, il travaille autrement : il choisit une unité à la fois, en partant d'un contexte donné. Et ce détail change tout : pour comprendre ses capacités, ses limites, et aussi ce que ça coûte quand on veut des réponses longues ou des conversations qui s'étirent.
On résume parfois un LLM à une formule simple : il prédit le mot suivant. L'idée est utile, mais elle cache le vrai mécanisme. Le modèle ne manipule pas des mots au sens humain, ne consulte pas une mémoire personnelle interne, et n'« anticipe » pas la phrase comme si elle était déjà écrite. Il transforme des tokens en représentations numériques, les combine via l'attention, puis attribue une probabilité aux prochaines unités possibles.
Comprendre cette boucle ne demande pas de savoir entraîner un réseau neuronal. En revanche, ça aide à prendre de meilleures décisions produit : quand utiliser un modèle, pourquoi le long contexte coûte plus cher, ce qu'on peut (et ne peut pas) appeler « mémoire » côté modèle, et où se logent les risques de confidentialité. Voici le mécanisme, puis ce que ça implique concrètement en entreprise.
Du texte aux tokens : ce que le modèle reçoit
Un token n'est pas forcément un mot
Avant qu'un modèle traite une phrase, un tokeniseur la découpe en tokens. Un token peut représenter un mot entier, une partie de mot, un signe de ponctuation, ou même un espace lié au mot suivant. Par exemple, « Le renard traverse la rue » peut devenir plusieurs unités : certaines coïncident avec les mots, d'autres découpent des fragments.
Il n'y a pas un découpage unique valable partout. Chaque modèle utilise son vocabulaire et ses règles de tokenisation. Les mots rares, les noms propres, les termes techniques et certaines langues peuvent produire plus de tokens que des expressions courantes. Résultat : le nombre de mots affiché n'est pas toujours le nombre d'unités réellement facturées ou traitées.
Chaque token correspond ensuite à un identifiant numérique. Le modèle ne reçoit donc pas une phrase « comme un humain », mais une suite d'identifiants, convertis en vecteurs. C'est sur ces vecteurs que les couches du réseau vont travailler.
Pour un usage en entreprise, le premier impact est très concret : les limites de contexte et les coûts se raisonnent en tokens, pas en pages ni en mots. Un document de 20 pages peut représenter des volumes très différents selon la langue, la mise en forme, les tableaux et le vocabulaire. Avant de dimensionner une fonctionnalité de résumé ou de recherche, il vaut mieux mesurer les tokens sur des exemples réels plutôt que d'appliquer un ratio « au feeling ».
Le contexte donne son sens au token
Le token « banque » peut renvoyer à un établissement financier... ou à une rive. Le tokeniseur assigne bien un identifiant, mais le modèle construit ensuite une représentation qui dépend de tout ce qui l'entoure. Autrement dit : le contexte ne change pas forcément l'identifiant de départ, mais il change ce que ce token « veut dire » dans l'opération de prédiction.
C'est aussi pour ça qu'une même question peut produire des réponses différentes selon les instructions, les documents fournis ou l'historique transmis. Le modèle ne répond pas « dans l'absolu » : il calcule à partir de l'entrée, plus ce qu'il a appris pendant l'entraînement.
Attention et génération : comment arrive le prochain token
Les couches transforment l'information
Un LLM moderne s'appuie souvent sur une architecture appelée transformer. Elle empile des couches qui transforment progressivement les représentations de la séquence. Dans une couche, deux mécanismes reviennent tout le temps : l'attention, qui met en relation des positions de la séquence, et un réseau feed-forward qui modifie chaque représentation.
L'attention sert à décider quelles autres positions sont utiles pour comprendre une position donnée. Une explication classique utilise trois termes : query (requête), key (clé) et value (valeur). La requête correspond à ce que la position cherche ; la clé correspond à ce que l'autre position « indique » ; la valeur correspond à l'information qu'on récupère si cette position est jugée pertinente.
Ensuite, le modèle compare les requêtes aux clés, convertit ces comparaisons en scores, puis combine les valeurs en fonction de ces scores. Le tout se fait en parallèle sur de nombreuses positions et sur plusieurs têtes d'attention. Ce n'est pas une « vérification consciente » ni une recherche de faits à la manière d'un moteur documentaire : c'est une opération mathématique apprise et répétée sur la séquence.
Dans un modèle génératif decoder-only, un masque causal empêche chaque position de regarder ce qui vient après elle. Le modèle peut utiliser le token courant et ceux qui le précèdent, mais pas la suite qu'il est en train de produire. Cette contrainte fait partie du jeu : apprendre à prédire la suite sans « tricher » en la lisant.
Du score à la sortie
Après plusieurs couches, une tête de sortie attribue un score à chaque token du vocabulaire. Ces scores reflètent les continuations que le modèle juge plus ou moins probables dans le contexte.
Une étape de sélection choisit ensuite le prochain token. Elle peut prendre le candidat le plus probable, ou introduire une part de variabilité selon le produit et les paramètres de génération.
Puis le modèle ajoute ce token à la séquence, et recommence pour le token suivant. La génération ressemble donc à une boucle : produire un token, l'ajouter au contexte, recalculer, et ainsi de suite. Sur une réponse complète, cette opération se répète parfois des centaines, voire des milliers de fois.
Et ça compte pour le produit : une réponse « bien structurée » ou un résumé « qui semble cohérent » ne sont pas garantis une fois pour toutes. Comme la génération avance pas à pas, une formulation fragile ou une erreur peut apparaître au milieu, même si le début était bon. D'où l'intérêt de concevoir des contrôles autour de l'usage : validation humaine, contraintes de format, vérifications métier - plutôt que de supposer qu'un bon démarrage suffit.
Préremplissage et décodage : pourquoi le cache compte
Deux phases différentes en production
En pratique, l'inférence se découpe souvent en deux phases. La première, appelée préremplissage (prefill), traite le prompt : instructions, question et éventuellement documents ou historique. Comme l'ensemble de cette entrée est déjà connu, le modèle peut traiter les positions en parallèle, via de grosses opérations matricielles. C'est généralement la phase la plus coûteuse, surtout quand l'entrée est longue.
Pendant ce préremplissage, le modèle calcule des vecteurs clés (keys) et valeurs (values) pour les tokens, à chaque couche. Il les conserve ensuite dans une mémoire temporaire appelée cache KV (cache des clés et des valeurs). La seconde phase, le décodage, produit la réponse token par token. À chaque étape, le modèle calcule ce qui concerne le nouveau token, mais réutilise ce qui est déjà dans le cache plutôt que de recalculer l'historique.
Sans ce cache, générer un token supplémentaire obligerait à refaire une grosse partie des calculs sur les tokens précédents. Et comme la génération s'allonge, refaire tout à chaque fois devient vite inefficace. Le cache accélère donc le décodage, mais il a un prix : il consomme de la mémoire, et cette mémoire augmente avec la longueur du contexte.
Pourquoi un long contexte mobilise beaucoup de mémoire
La taille du cache KV dépend de plusieurs paramètres : nombre de couches, nombre de têtes utilisées pour les clés et valeurs, dimension de ces têtes, longueur de séquence, et nombre d'octets nécessaires pour stocker chaque valeur. On peut résumer la relation ainsi :
Mémoire du cache KV ≈ 2 × couches × têtes KV × dimension des têtes × longueur de séquence × octets par valeur
Le facteur 2 correspond aux clés et aux valeurs. Par exemple, avec les caractéristiques de Llama 3.1 70B, une séquence de 128 000 tokens et des valeurs en précision 16 bits, l'estimation atteint environ 43 Go en unités décimales, soit environ 40 Gio. C'est un ordre de grandeur théorique pour une séquence, hors mémoire occupée par les poids du modèle, hors autres structures système, et hors variantes d'implémentation ou gestion de plusieurs requêtes.
Ce point est important : ce chiffre n'est pas « le » coût mémoire universel d'un LLM. Les architectures et les configurations changent. Mais ça donne une idée du problème : un contexte très long peut engloutir une part significative de la mémoire disponible sur l'accélérateur, avant même de produire la réponse. Et si plusieurs requêtes tournent en même temps, la pression mémoire augmente encore.
Les fournisseurs jouent alors sur plusieurs leviers : attention à requêtes groupées (grouped-query attention), quantification du cache, déport vers d'autres niveaux de mémoire, ou gestion plus efficace des requêtes. Toutes ces techniques ont des compromis (complexité, vitesse, qualité). Le contexte long n'est pas « gratuit », il devient juste plus gérable.
Ce que ce mécanisme change pour un produit d'IA
Le contexte n'est pas une mémoire personnelle
Un LLM ne conserve généralement pas, tout seul, un souvenir persistant entre deux requêtes. Pour donner l'impression d'une conversation continue, l'application renvoie souvent au modèle une partie (ou la totalité) des échanges précédents. Le modèle reconstruit alors la réponse à partir de l'historique inclus dans l'entrée de la requête.
Il faut aussi distinguer ce que fait le système autour. Une application peut stocker les conversations, créer un profil, récupérer des infos depuis une base documentaire, ou résumer ce qui s'est dit avant. Mais cette « mémoire » appartient à l'application, à son stockage et à ses règles de récupération. Elle n'est pas une mémoire interne automatique du modèle. Cette séparation est essentielle pour concevoir correctement la conservation des données, les fonctions de suppression et les droits d'accès.
Il y a aussi un impact budgétaire : si chaque tour renvoie un historique de plus en plus long, le préremplissage traite davantage de tokens et le cache KV devient plus volumineux. Une conversation « qui semble juste continuer » peut donc coûter plus cher à chaque étape. À grande échelle, une conception trop naïve peut transformer une démo convaincante en service lent et coûteux.
Réduire le contexte sans dégrader le service
Le bon réflexe n'est pas de supprimer l'historique à chaque fois. Il faut décider ce qui est utile, pour quelle tâche, et sous quelle forme. Par exemple, pour un assistant interne, il est souvent plus efficace de rechercher quelques passages pertinents dans une base documentaire que d'injecter des centaines de pages à chaque question. Pour une conversation longue, un résumé contrôlé peut garder les décisions et préférences importantes sans répéter chaque message.
Un processus pragmatique peut suivre quatre étapes :
- Mesurer la longueur réelle des entrées et des sorties, en tokens, sur des cas représentatifs.
- Définir les informations indispensables à la tâche et la durée de conservation souhaitée.
- Récupérer ou résumer uniquement ce qui est pertinent, au lieu d'envoyer tout l'historique.
- Tester qualité, latence et coût sur les cas limites : conversations longues, documents volumineux et requêtes simultanées.
Cette approche aide aussi à arbitrer qualité vs coût. Un contexte plus large peut améliorer une réponse quand il contient vraiment des éléments utiles. Il peut aussi introduire du bruit, augmenter la latence et faire travailler le modèle sur des passages qui ne servent à rien. Sur le terrain, la question n'est donc pas « quelle est la fenêtre de contexte maximale ? », mais plutôt : « quelle quantité d'information améliore réellement cette tâche ? »
Confidentialité et responsabilité
Renvoyer l'historique n'est pas un détail technique. Ça détermine quelles données personnelles ou professionnelles partent à chaque requête. Pour un projet déployé en France ou dans l'Union européenne, l'équipe doit analyser la finalité du traitement, la minimisation des données, la durée de conservation, les sous-traitants et les modalités d'exercice des droits prévus par le RGPD.
Le fait que le modèle « ne se souvienne pas » seul ne veut pas dire que rien n'est stocké ailleurs. Les journaux, bases de conversation, outils d'observabilité et services tiers peuvent conserver des informations selon leur configuration et leurs conditions. Il faut donc regarder le système complet, pas uniquement le modèle, puis éviter d'envoyer des données inutiles. Pour les contenus sensibles, une revue des risques et des règles d'accès devrait précéder le déploiement.
Côté métier, le niveau de contrôle dépend du risque. Un outil qui reformule un document interne n'a pas les mêmes exigences qu'un système qui influence une décision d'embauche, de crédit ou d'accès à un service. Le caractère probabiliste de la génération, la possibilité d'erreur et la gestion des données doivent être intégrés dès la conception. L'IA ne supprime pas la responsabilité de l'organisation qui choisit comment elle est utilisée.
Conclusion : concevoir autour de la boucle réelle
Un LLM transforme des tokens en représentations, utilise l'attention pour exploiter le contexte, puis choisit le prochain token. Le cache KV rend la génération plus efficace, mais il consomme de la mémoire ; l'historique donne l'impression de continuité, mais il faut généralement le renvoyer ou le gérer côté application.
Ces mécanismes ne sont pas des détails « d'ingénierie ». Ils influencent la latence, les coûts, l'architecture de la mémoire applicative et les choix de confidentialité. Avant de lancer une fonctionnalité, mesurez les tokens sur des données réalistes, définissez ce qui doit vraiment rester dans le contexte, et vérifiez le comportement à l'échelle prévue.
Pour aller plus loin, consultez l'article fondateur « Attention Is All You Need », le guide d'inférence de Modular et les ressources de Sebastian Raschka sur le cache KV. Vous pouvez aussi explorer notre guide sur le choix d'un modèle d'IA et notre dossier sur le RGPD et les projets d'IA. La bonne décision n'est pas de maximiser le contexte : c'est de fournir au modèle juste assez d'information pour livrer un service fiable, à un coût et à un niveau de risque acceptables.