🧬 Modèles·
13 juillet 2026
·
8 min

Que se passe-t-il vraiment entre votre prompt et la réponse d'une IA ?

Vous écrivez une question, vous appuyez sur Entrée, ChatGPT ou Claude répond presque instantanément. Derrière cette simplicité se cache une véritable chaîne de production numérique : tokenization, embeddings, attention, KV cache, sampling, streaming. Visite guidée, étape par étape.

YJ

Youssef Jlidi

Fondateur IA Pulsion · Praticien IA

Que se passe-t-il vraiment entre votre prompt et la réponse d'une IA ?

En bref

Entre le moment où vous appuyez sur Entrée et celui où la réponse s'affiche, votre texte traverse une chaîne de production complète : il est découpé en tokens puis converti en nombres (tokenization), projeté dans un espace mathématique à plusieurs milliers de dimensions (embeddings), analysé par des couches d'attention qui relient les éléments du contexte entre eux (transformer), mis en mémoire pour éviter de tout recalculer (KV cache), puis la réponse est générée token par token selon des règles de probabilité (sampling), parfois accélérée par un petit modèle éclaireur (speculative decoding), et diffusée au fil de l'eau vers votre écran (streaming). Deux phases dominent les performances : le prefill (lecture du prompt, gourmand en calcul) et le decode (génération, limité par la bande passante mémoire). Comprendre cette mécanique explique les prix au token, les limites de contexte et pas mal de comportements étranges des modèles.

Une simplicité trompeuse

Vous écrivez une question. Vous appuyez sur Entrée. ChatGPT ou Claude répond presque instantanément.

De votre côté de l'écran, c'est tout ce qui se passe. De l'autre côté, votre phrase vient de déclencher une chaîne de production numérique complète, répartie entre logiciels spécialisés et processeurs graphiques, avec ses étapes, ses goulots d'étranglement et ses astuces d'optimisation.

Cet article déroule cette chaîne, étape par étape, sans prérequis technique. À la fin, vous comprendrez pourquoi les modèles se trompent en comptant les lettres d'un mot, pourquoi les conversations longues coûtent plus cher, et pourquoi le texte s'affiche mot après mot comme si quelqu'un tapait au clavier.

Votre phrase vient de déclencher une chaîne de production numérique complète.

Étape 1 — Tokenization : votre texte devient des nombres

Première opération : votre texte est découpé en petites unités appelées « tokens ». Un token, c'est parfois un mot entier, parfois un morceau de mot, parfois un simple signe de ponctuation. Chaque token est ensuite converti en un identifiant numérique, puisé dans le vocabulaire fixe du modèle.

C'est le point le plus important à comprendre : le modèle ne lit pas comme un humain. Il ne voit ni lettres ni mots, il manipule des suites de nombres. Cela explique certaines de ses difficultés les plus célèbres, comme compter les lettres d'un mot : si « fraise » arrive au modèle sous la forme d'un ou deux identifiants numériques, les lettres individuelles n'existent tout simplement pas dans ce qu'il perçoit.

C'est aussi à cette étape que se joue votre facture. Les API des grands modèles se facturent au token, en entrée comme en sortie. Chaque mot de votre prompt, chaque document collé dans la conversation, se transforme en tokens comptabilisés.

Le modèle ne voit ni lettres ni mots : il manipule des suites de nombres.

Étape 2 — Embeddings : le langage devient géométrie

Un identifiant numérique brut ne dit rien du sens d'un mot. La deuxième étape corrige cela : chaque token est projeté dans un espace mathématique à plusieurs milliers de dimensions. Concrètement, chaque token devient un long vecteur de nombres, sa « position » dans cet espace.

L'intérêt de cette représentation : les notions proches par le sens y possèdent généralement des positions similaires. « Roi » et « reine » sont voisins, « chat » et « chien » aussi, tandis que « chat » et « facture » sont éloignés. Le langage devient une forme de géométrie, où la proximité spatiale encode la proximité sémantique.

Ces vecteurs, appelés embeddings, ne sont pas définis à la main : ils émergent de l'entraînement du modèle sur d'immenses corpus de textes. C'est le même principe qui alimente les moteurs de recherche sémantique et les systèmes de RAG, qui comparent des embeddings pour retrouver les documents proches d'une question.

Étape 3 — Transformer : l'attention relie tout à tout

Vient ensuite le cœur du réacteur : l'architecture Transformer, empilée en de nombreuses couches de calcul.

Dans chaque couche, des mécanismes dits « d'attention » analysent les relations entre les éléments du prompt. Chaque token « regarde » les autres et évalue lesquels comptent pour l'interpréter. Dans la phrase « le chat que le chien poursuit grimpe à l'arbre », l'attention permet de relier « grimpe » à « chat » et non à « chien », alors que « chien » est plus proche dans la phrase.

Couche après couche, le modèle construit ainsi une représentation de plus en plus riche et cohérente du contexte : qui fait quoi, ce qui se rapporte à quoi, le ton, l'intention. C'est cette mécanique, répétée à grande échelle, qui donne aux LLM leur capacité à suivre un raisonnement, une consigne ou une conversation.

Chaque token « regarde » les autres et évalue lesquels comptent pour l'interpréter.

Étape 4 — KV cache : la mémoire de travail de la génération

La réponse est générée token par token. Sans optimisation, produire chaque nouveau token obligerait à recalculer les relations d'attention sur tout ce qui précède, encore et encore.

C'est là qu'intervient le KV cache (pour « key-value cache ») : pendant la génération, certaines informations déjà calculées sur les tokens précédents sont conservées en mémoire, pour ne pas tout refaire à chaque étape. Résultat : une réponse nettement plus rapide.

La contrepartie est directe : plus la conversation s'allonge, plus ce cache grossit, et plus la mémoire nécessaire augmente. C'est l'une des raisons concrètes pour lesquelles les longues fenêtres de contexte coûtent cher aux fournisseurs, et pour lesquelles certains proposent des tarifs réduits sur les portions de prompt déjà « en cache » d'une requête à l'autre.

Étape 5 — Sampling : choisir le mot suivant

À chaque étape de génération, le modèle ne « décide » pas d'un mot : il attribue une probabilité aux différentes continuations possibles. Après « le chat est monté sur le », le token « toit » recevra une probabilité forte, « arbre » aussi, « réfrigérateur » une probabilité faible mais pas nulle.

Reste à choisir. C'est le rôle du sampling, piloté par quelques réglages que vous croisez peut-être dans les API :

La température dose la prise de risque : basse, le modèle choisit presque toujours les continuations les plus probables (résultat prévisible et régulier) ; haute, il s'autorise des choix moins attendus (résultat plus créatif, parfois plus erratique).

Le Top-K restreint le choix aux K continuations les plus probables. Le Top-P retient le plus petit ensemble de continuations dont les probabilités cumulées atteignent un seuil donné.

C'est aussi pour cela que la même question ne produit pas deux fois la même réponse : le choix final comporte une part de tirage aléatoire, encadrée par ces réglages.

  • 01Température : dose la prise de risque, du plus prévisible au plus créatif.
  • 02Top-K : limite le choix aux K continuations les plus probables.
  • 03Top-P : retient les continuations jusqu'à un seuil de probabilité cumulée.

Étape 6 — Speculative decoding : un éclaireur pour aller plus vite

Générer token par token avec un très gros modèle, c'est lent. Certains systèmes utilisent une astuce élégante : le speculative decoding.

Le principe : un petit modèle rapide propose plusieurs tokens à l'avance, comme un éclaireur. Le modèle principal, plus puissant mais plus lent, vérifie ces propositions en parallèle plutôt que de les produire une à une. Quand l'éclaireur a vu juste, plusieurs tokens sont validés d'un coup ; quand il se trompe, le grand modèle reprend la main.

Le résultat reste identique à ce que le grand modèle aurait produit seul, mais la génération peut être sensiblement accélérée. C'est l'une des nombreuses optimisations invisibles qui séparent un modèle de recherche d'un produit utilisé par des millions de personnes.

Étape 7 — Streaming : pourquoi le texte « se tape » sous vos yeux

Dernière étape : les tokens validés sont reconvertis en texte lisible et transmis progressivement à votre écran.

Cet effet de frappe que vous observez n'est donc pas (seulement) un artifice d'interface : il correspond souvent au déroulement réel de la génération. Le modèle produit ses tokens les uns après les autres, et l'interface vous les affiche au fil de l'eau plutôt que d'attendre la fin.

L'avantage est double : vous commencez à lire pendant que le modèle travaille encore, et le temps d'attente perçu s'effondre, même quand la génération complète prend plusieurs secondes.

Prefill et decode : la distinction qui explique les performances

Pour comprendre les performances d'un modèle, une distinction domine tout le reste : chaque requête se joue en deux phases très différentes.

Le prefill, d'abord : le modèle analyse l'ensemble de votre prompt, d'un bloc. Cette phase sollicite surtout la puissance de calcul brute des processeurs graphiques. C'est elle qui détermine le délai avant le premier mot de la réponse, et elle s'alourdit avec la taille de votre prompt.

Le decode, ensuite : le modèle génère la réponse token après token. Cette phase dépend fortement de la bande passante mémoire, c'est-à-dire de la vitesse à laquelle les données circulent entre la mémoire et les unités de calcul. C'est elle qui fixe le rythme d'affichage des mots.

Accélérer l'inférence exige donc de jouer sur tous les tableaux à la fois : le calcul, la mémoire, les transferts de données et les méthodes de génération. Les techniques vues plus haut (KV cache, speculative decoding) s'attaquent chacune à un maillon précis de cette chaîne.

Le prefill sollicite le calcul, le decode dépend de la bande passante mémoire.

Ce que ça change pour vous

Derrière chaque réponse obtenue en quelques secondes se cache une infrastructure logicielle et matérielle impressionnante. Et cette mécanique n'est pas qu'une curiosité d'ingénieur : elle éclaire des décisions très concrètes.

Elle explique la facturation au token, et pourquoi dégraisser ses prompts réduit directement les coûts. Elle explique pourquoi une conversation qui s'éternise devient plus lente et plus chère : le contexte à traiter et le KV cache grossissent. Elle explique les réglages de température quand une tâche exige de la constance plutôt que de la créativité. Et elle explique certaines limites structurelles, comme le comptage de lettres, qui ne relèvent pas d'un « bug » mais de la nature même de la représentation en tokens.

La prochaine fois que la réponse s'affichera mot après mot sous vos yeux, vous saurez exactement ce qui vient de se passer.

tags :LLMinférencetokensembeddingstransformerKV cachesamplingpédagogie

partager cet article