Comment un LLM consomme du texte et fait son inférence ?

Cette annexe descend dans la mécanique d’inférence d’un LLM. Elle éclaire trois questions qu’on prend souvent pour acquises ailleurs dans le handbook : pourquoi un token coûte ce qu’il coûte, pourquoi au-delà de 70 % de fenêtre la qualité décroche, et ce que stabilise vraiment le prompt caching.

Le pipeline d’inférence se déroule en quatre temps : tokenisation → embeddings → transformer (attention + feedforward) → unembedding. On les détaille dans l’ordre.

Le tokenizer

• Le tokenizer reçoit du texte brut, sans notion de mot.
• À partir d’un vocabulaire figé (appris une fois pour toutes sur un grand corpus), il découpe le texte en fragments fréquents appelés tokens. Un mot fréquent correspond souvent à un token unique ; un mot rare est éclaté en plusieurs (par exemple "Defsquare" → ['Def', 'square']).
• Selon la langue, un token couvre 3–4 caractères : ≈ 0,75 mot en anglais, ≈ 0,5 mot en français (accents, longueur des mots, élisions).
• Chaque token est converti en un identifiant entier via la table de vocabulaire. C’est la sortie du tokenizer.

Les embeddings

• Cet entier sert d’index dans la table d’embeddings du modèle.
• La table d’embeddings est une matrice avec autant de lignes que de tokens du vocabulaire, et autant de colonnes que de dimensions de l’espace.
• L’index pointe sur une ligne dans cette matrice, retournant un vecteur.
• En théorie, une dimension représente un trait sémantique comme le genre, la royauté ou le fait d’être vivant par exemple
• Un vecteur contient les coordonnées du token pour chaque dimension (en 3D, par exemple [0.83, 0.21, -0.2] signifie x=0.83, y=0.21, z=-0.2).
• Exemple :
  • un Roi [0.9, 0.9, 0.8] = [très masculin, très royal, très vivant],
  • une Reine [-0.9, 0.9, 0.8] = [très féminin, très royal, très vivant],
  • une table [0.0, -0.9, -0.9] = [neutre, pas royal, pas vivant].
• Conséquence célèbre : les opérations vectorielles d’addition et de soustraction de vecteurs font émerger du sens, par exemple Roi − Homme + Femme ≈ Reine.
• Dans un modèle industriel, la matrice contient plusieurs milliers de dimensions (4 096 pour Llama 3 8B, voir beaucoup plus pour les modèles “frontières”, ce nombre n’est pas connu et d’ailleurs les dimensions de ces vecteurs sont maintenant dynamiques).
• En réalité, chaque dimension est latente : c’est à dire qu’elle est décidée empiriquement lors de l’entraînement, elle n’a pas de sens humainement interprétable prise isolément. Le sens émerge de la combinaison des coordonnées sur toutes les dimensions à la fois (représentation distribuée).
• Pendant l’entraînement, ces vecteurs sont déplacés dans l’espace de sorte que les tokens de sémantique proche se retrouvent “proches” au sens de la distance vectorielle.

Le transformer

Le rôle d’un transformer est d’enrichir les embeddings statiques en embeddings contextualisés : le vecteur de chat dans chat bleu diffère du vecteur de chat dans petit chat.

Un transformer est composé de couches empilées, chacune contenant deux sous-blocs (attention + feedforward), et correspondant à un cycle complet de contextualisation syntaxique et sémantique.

La sous-couche d’attention

Chaque couche du transformer contient plusieurs têtes d’attention qui fonctionnent en parallèle, apprises lors de l’entraînement. Chaque tête est spécialisée dans la capture de relations différentes entre les tokens, et ont appris à se focaliser sur des choses différentes (une tête gère les relations grammaticales, une autre relie les pronoms à leur sujet, une autre repère les entités nommées la grammaire, une autre le temps des verbes, etc.).

Pour chaque tête d’attention : afin d’analyser le texte “à sa façon”, chaque tête possède ses propres matrices de poids aux dimensions réduites. Ces matrices sont fixes pour une couche donnée lors de l’inférence :

• Query ($W_Q$), (Matrice Query) la requête, que cherche ce token ?,
• Key ($W_K$), (Matrice Key) l’étiquette, quelles informations ce token propose-t-il ?,
• Value ($W_V$) (Matrice Value) ce que le token transmet, quelle est la valeur informative réelle de ce token ?.

L’analogie du “Catalogue” : Pour rendre le concept de $Q, K, V$ plus intuitif, on utilise souvent l’analogie du système de recherche (bibliothèque ou moteur de recherche) :

• Query : Votre recherche dans la barre Google.
• Key : Les titres des pages indexées (pour voir si ça correspond à votre recherche).
• Value : Le contenu réel de la page que vous lisez une fois que vous avez cliqué.

Pour chaque token, dans chaque tête : la projection individuelle. Pour un token donné (représenté par son vecteur d’entrée $x$, ce vecteur est celui de la couche précédente c-à-d l’embeddings initial mais déjà “chargé” du contexte accumulé dans les étapes précédentes), on utilise les matrices de la tête pour générer ses trois vecteurs spécifiques en multipliant le vecteur du token par les matrices $Q, K, V$:

• $q = x \cdot W_Q$
• $k = x \cdot W_K$
• $v = x \cdot W_V$

Le mécanisme d’attention (~ l’interaction entre les tokens) : Pour un token donné, on compare sa requête ($q$) avec les étiquettes ($k$) de tous les autres tokens de la phrase via un produit scalaire. On applique ensuite une fonction softmax (qui transforme ces scores en probabilités de 0 à 1 dont la somme égale 1) pour obtenir une distribution de poids. $\text{Scores d'attention} = \text{softmax}(q \cdot k^T)$

On obtient un nouveau vecteur pour chaque token : V pondéré par le softmax (lissage de 0 à 1) du produit scalaire Q·K. Ce nouveau vecteur est la version contextualisée du token, sa sémantique contextualisée : il intègre les informations des autres tokens, pondérées par leur pertinence.

La sémantique contextualisée finale (La fusion multi-têtes) : Le token ne s’arrête pas là. Les vecteurs obtenus pour ce token dans toutes les têtes de la couche sont concaténés, puis projetés une dernière fois par une matrice de sortie globale ($W_O$). C’est ce vecteur final qui constitue la véritable sémantique contextualisée du token, enrichie par les expertises complémentaires de toutes les têtes (TODO décrire plus précisément cette Matrice Output et son rôle dans la fusion).

La sous-couche de feedforward

• L’attention vient de faire circuler de l’information entre les tokens. Le feedforward, lui, traite chaque vecteur indépendamment des autres : il enrichit le token avec des connaissances stockées dans le modèle.
• Le mécanisme : deux matrices apprises (W_1, W_2) séparées par une non-linéarité. Schéma : FFN(x) = W_2 · activation(W_1 · x + b_1) + b_2.
• W_1 agit comme une batterie de questions / détecteurs : chacune de ses lignes encode un pattern (« est-ce un prénom ? un verbe d’action ? un concept royal ? ») et produit un score de matching avec le vecteur d’entrée.
• L’activation (ReLU, GELU, SwiGLU) filtre ces scores : elle écrase les négatifs à zéro, ne laisse vivre que les détecteurs réellement déclenchés.
• W_2 agit comme une banque de réponses : chaque colonne est un vecteur de concept (« royauté », « sport collectif »…). Les détecteurs allumés par W_1 décident quels concepts injecter, et à quelle intensité.
• Chaque matrice s’accompagne d’un biais (b_1, b_2) qui décale le score d’activation.
• C’est cette lecture clé-valeur qui fait dire que les connaissances factuelles d’un LLM vivent principalement dans les FFN, pas dans l’attention.
• Comme les matrices d’attention, W_1 et W_2 sont apprises lors de l’entraînement.

L’unembedding

• Après le passage de toutes les couches du transformer, on dispose d’un vecteur contextualisé par position dans l’input. Pour prédire le token suivant, seul compte le vecteur de la dernière position.
• Ce vecteur est projeté dans l’espace du vocabulaire via une dernière matrice apprise, l’unembedding (W_U, souvent partagée avec la matrice d’embeddings d’entrée). On obtient un vecteur de logits : un score par token possible.
• Un softmax convertit ces logits en distribution de probabilités (donc un nombre décimal entre 0 et 1) sur les ~100 000 tokens du vocabulaire.
• On échantillonne un token dans cette distribution (greedy / température / top-k / top-p). Le token retenu est ajouté à la séquence puis tout le pipeline recommence pour le suivant (autoregressive generation).

Ce que la fenêtre de contexte stocke vraiment

• Tokens d’entrée : tout ce qu’on envoie au modèle (system prompt, prompts, historique, outils, fichiers chargés…). Facturés en input.
• Tokens de sortie : tout ce que le modèle produit, y compris les tokens de raisonnement (extended thinking, reasoning tokens), qui s’ajoutent au budget de sortie même quand ils sont cachés à l’utilisateur. Facturés ~4–5× plus cher que l’input.
• KV cache (invisible) : à chaque couche, les vecteurs K et V des tokens déjà traités sont conservés en mémoire pour ne pas être recalculés à chaque étape. C’est ce qui rend la génération autorégressive viable. Non facturé en tant que tel, mais c’est lui qui occupe la VRAM du GPU.
• Prompt caching (Anthropic, OpenAI) : version « persistante » du KV cache, partagée entre requêtes successives qui partagent un même préfixe. Facturée ~10 % du prix normal. Stabiliser le début de la fenêtre = économie directe.