Comprendre l'inférence d'un LLM

L'inférence, c'est l'étape où un modèle de langage déjà entraîné génère du texte en réponse à votre demande. Chaque fois que vous posez une question à un assistant IA, vous déclenchez une inférence. Comprendre comment elle fonctionne — les deux phases prefill et decode, le rôle du KV cache, la différence entre latence et débit — est indispensable avant de choisir un outil pour faire tourner un modèle. Ce guide pose ces bases sans jargon, pour un lecteur débutant. Aucune connaissance préalable n'est requise au-delà de savoir ce qu'est un LLM.

Ce que vous allez apprendre

Distinguer l'inférence de l'entraînement d'un modèle.
Comprendre les deux phases d'une génération : le prefill et le decode.
Savoir ce qu'est le KV cache et pourquoi il consomme de la mémoire.
Différencier la latence et le débit, deux mesures souvent confondues.
Comprendre pourquoi l'inférence tourne mieux sur GPU que sur CPU.

Qu'est-ce que l'inférence ?

Un modèle de langage passe par deux grandes étapes dans sa vie. La première est l'entraînement : le modèle apprend, en analysant des milliards de textes, à prédire le mot suivant. C'est une opération unique, extrêmement coûteuse, qui dure des semaines sur des milliers de GPU. La seconde est l'inférence : une fois entraîné, le modèle est utilisé pour générer du texte. C'est ce qui se passe à chaque requête.

Une analogie simple : l'entraînement, c'est écrire un dictionnaire — un travail long, fait une fois. L'inférence, c'est consulter ce dictionnaire — une opération rapide, répétée des millions de fois. Les outils dont parle ce parcours (Ollama, llama.cpp, vLLM, SGLang) ne servent qu'à l'inférence : ils ne créent pas de modèle, ils exécutent un modèle existant.

Comment un LLM génère : prefill et decode

Quand vous envoyez un prompt à un modèle, la génération se déroule en deux phases bien distinctes. Les comprendre explique presque tout du comportement d'un serveur d'inférence.

La première phase est le prefill. Le modèle lit tout votre prompt d'un seul coup. Comme il a accès à l'intégralité du texte d'entrée dès le départ, il peut traiter tous les tokens en parallèle. C'est une opération massivement parallèle, donc rapide, même pour un prompt long.

La seconde phase est le decode. Le modèle génère la réponse un token à la fois. Et c'est là le point crucial : chaque nouveau token dépend de tous les tokens précédents, y compris ceux que le modèle vient lui-même de produire. Impossible de générer le 10ᵉ mot avant d'avoir écrit le 9ᵉ. Le decode est donc séquentiel, et c'est l'étape lente de l'inférence.

Cette asymétrie a une conséquence directe : la vitesse ressentie d'un assistant IA dépend surtout de la vitesse du decode. Un modèle peut « avaler » un prompt de 5 000 mots en une fraction de seconde, puis mettre plusieurs secondes à rédiger sa réponse.

Le KV cache : la mémoire de travail du modèle

Pendant le decode, le modèle doit, pour produire chaque nouveau token, examiner tous les tokens précédents. Sans optimisation, il recalculerait à chaque étape l'analyse de l'ensemble du texte déjà traité — un gaspillage énorme qui empire à mesure que la réponse s'allonge.

La solution s'appelle le KV cache (cache des clés et valeurs, deux quantités issues du mécanisme d'attention). À chaque token traité, le modèle range dans ce cache les calculs intermédiaires le concernant. Pour le token suivant, il réutilise ces calculs au lieu de les refaire. Le KV cache est la mémoire de travail du modèle pendant une génération.

Ce cache a un coût : il occupe de la mémoire, et il grandit avec la longueur du texte. Plus la conversation est longue, plus le KV cache est volumineux. Sur un GPU, c'est lui qui détermine combien de conversations simultanées la carte peut tenir. Cette contrainte explique une grande partie du comportement des serveurs d'inférence — un sujet développé dans le guide sur le serving.

Latence ou débit : deux mesures, deux objectifs

Deux mots reviennent sans cesse pour mesurer un système d'inférence, et on les confond souvent. Ils ne mesurent pas la même chose.

La latence est le temps que met une seule requête à être traitée, du début à la fin. C'est ce que ressent un utilisateur isolé : « ma réponse a mis 3 secondes ».

Le débit (en anglais throughput) est la quantité totale de travail accompli par unité de temps — par exemple, le nombre de tokens générés par seconde pour l'ensemble des utilisateurs. C'est ce qui intéresse l'exploitant du service : « mon serveur produit 8 000 tokens par seconde ».

Le point clé : optimiser l'un peut dégrader l'autre. Un serveur qui regroupe beaucoup de requêtes pour maximiser le débit fait parfois attendre chaque requête un peu plus longtemps, donc augmente la latence individuelle. Choisir un système d'inférence, c'est largement choisir où placer le curseur entre ces deux objectifs.

TTFT et TPOT : ce que ressent l'utilisateur

Pour parler de latence avec précision, on la découpe en deux mesures qui correspondent exactement aux deux phases vues plus haut.

Le TTFT (Time To First Token) est le délai avant le premier mot de la réponse. Il correspond à la durée du prefill : le temps que le modèle met à « digérer » votre prompt avant de commencer à répondre. C'est le « blanc » que vous voyez après avoir appuyé sur Entrée.

Le TPOT (Time Per Output Token) est le temps entre deux mots une fois la réponse lancée. Il correspond à la cadence du decode. Un TPOT de 30 millisecondes signifie que le modèle produit environ 33 tokens par seconde — assez fluide pour une lecture humaine.

Mesure	Phase concernée	Ce que l'utilisateur perçoit
TTFT	Prefill	Le délai avant que « ça commence »
TPOT	Decode	La vitesse à laquelle le texte « se déroule »

Un bon TTFT donne une impression de réactivité ; un bon TPOT donne une impression de fluidité. Les deux comptent, mais un long prompt pèse surtout sur le TTFT, tandis qu'une longue réponse se ressent surtout via le TPOT.

CPU ou GPU pour l'inférence ?

L'inférence d'un LLM consiste, à chaque token, en une avalanche de multiplications de matrices. Ces opérations sont massivement parallèles : des milliers de calculs identiques et indépendants.

Un GPU est précisément conçu pour ça : il possède des milliers de petites unités de calcul qui travaillent de front. Un CPU, lui, dispose de quelques cœurs très polyvalents, mais bien moins nombreux. Pour l'inférence, le GPU est donc largement plus rapide.

Cela ne rend pas le CPU inutile. Pour un petit modèle, un usage mono-utilisateur ou du prototypage local, un CPU moderne suffit — c'est tout l'intérêt d'outils comme llama.cpp. Mais dès qu'on vise un gros modèle ou un service partagé entre plusieurs utilisateurs, le GPU devient incontournable.

Idées fausses fréquentes

Quelques raccourcis trompeurs reviennent souvent quand on découvre l'inférence. Les corriger évite de mauvaises décisions.

« Un modèle plus gros répond plus vite. » Faux : un modèle plus gros est généralement plus lent en inférence, car chaque token demande plus de calculs. Il est souvent meilleur en qualité, pas en vitesse.
« Tokens par seconde, c'est la seule métrique qui compte. » Faux : un excellent débit avec un mauvais TTFT donne un service qui paraît lent à démarrer. Il faut regarder les deux.
« Le CPU, c'est juste un GPU en plus lent. » Faux : la différence est structurelle. Le GPU n'est pas « un peu » plus rapide, il est conçu pour un type de calcul que le CPU traite mal.
« Allonger le contexte est gratuit. » Faux : un contexte plus long gonfle le KV cache, consomme de la mémoire et réduit le nombre d'utilisateurs simultanés.

À retenir

L'inférence est l'usage d'un modèle entraîné ; c'est ce qui se passe à chaque requête.
Une génération a deux phases : le prefill (lecture du prompt, parallèle et rapide) et le decode (génération mot à mot, séquentielle et lente).
Le KV cache est la mémoire de travail du modèle : il évite de tout recalculer, mais grossit avec la longueur du texte.
La latence mesure une requête isolée ; le débit mesure le travail total. Optimiser l'un peut dégrader l'autre.
TTFT et TPOT découpent la latence : délai de démarrage et cadence de génération.
Le GPU surpasse le CPU en inférence par conception, mais le CPU reste valable pour les petits modèles et le prototypage.

Prochaines étapes

Servir un LLM : batching et débit Comment un serveur traite plusieurs utilisateurs à la fois sans s'effondrer.

Comprendre la quantification des LLM Pourquoi et comment réduire la taille d'un modèle pour le faire tenir en mémoire.

Anatomie d'un LLM Revenir sur les fondations : tokens, attention, génération.

Comparatif des backends d'inférence Choisir l'outil qui exécutera vos modèles selon votre matériel.