D'où vient la latence : batching, streaming, décodage spéculatif

CONCEPTS — DU MODÈLE AU SYSTÈME · LATENCE D'INFÉRENCE

Sources officielles et travaux de recherche vérifiés au 18 juillet 2026.

Dans les comptes rendus de recette d'une application qui appelle un modèle, la même phrase revient : « c'est lent ». Elle ne dit rien d'exploitable. Lent où ? Avant le premier mot, ou pendant que le texte se déroule ? Lent pour un utilisateur isolé, ou seulement quand la charge monte ? Sans réponse à ces questions, toute optimisation relève du tir dans le noir — et une équipe peut dégrader l'expérience de chaque utilisateur en croyant améliorer son service.

La cause est structurelle. Une génération de texte n'est pas une opération, mais deux, aux propriétés physiques opposées : la première est bornée par la puissance de calcul, la seconde par la bande passante mémoire. Elles produisent deux latences distinctes, se mesurent différemment et se soignent avec des leviers qui parfois se contredisent. Comprendre cette bascule, c'est passer d'un ressenti à un diagnostic.

« C'est lent » ne veut rien dire : deux phases, deux latences

Un modèle traite d'abord votre prompt en entier, puis écrit sa réponse un token à la fois. Ces deux moments ont des noms précis : prefill et decode.

Pendant le prefill, le modèle ingère tous les tokens du prompt en parallèle et calcule les états intermédiaires — clés et valeurs — de chaque position, en une opération matricielle massive qui sature les unités de calcul du processeur graphique. La documentation de NVIDIA sur l'optimisation de l'inférence qualifie cette phase de compute-bound : bornée par le calcul. Doubler la longueur du prompt double, en gros, le travail à fournir. La phase s'achève exactement au moment où le premier token sort : le prefill, c'est le TTFT.

Pendant le decode, tout change. Le modèle produit un token, l'ajoute à la séquence, recommence. Chaque pas ne calcule qu'une poignée de vecteurs, mais doit relire l'intégralité du cache d'attention accumulé. Le facteur limitant n'est plus le calcul, largement inemployé, mais la vitesse de lecture de la mémoire du processeur graphique : c'est le régime memory-bandwidth-bound. Red Hat le résume dans sa note sur l'inférence distribuée de juin 2026 : le prefill veut du calcul, le decode veut de la bande passante, et les deux se disputent le même matériel. Le decode, c'est le TPOT.

Anatomie d'une requête d'inférence. Le prefill traite tout le prompt d'un bloc et se termine sur le premier token : sa durée est le TTFT. Le decode enchaîne ensuite des pas séquentiels dont l'écart moyen est le TPOT. La frise inférieure montre l'effet du streaming : la longueur totale ne change pas, seul le moment où le texte devient visible avance.

Cette dualité explique qu'un même symptôme ait deux causes sans rapport. Une application muette quatre secondes puis qui crache sa réponse d'un coup a un problème de prefill : prompt trop long, file saturée. Une application qui répond aussitôt mais dont le texte s'égrène péniblement a un problème de decode : bande passante disputée, lot trop chargé, réponse trop longue. Seul le premier cas se traite en raccourcissant l'entrée.

Le vocabulaire qui permet de diagnostiquer

Ces deux phases posées, les métriques deviennent des instruments. Le TTFT mesure la phase compute-bound plus l'attente en amont, le TPOT la phase memory-bound, et la latence de bout en bout est leur somme. Trois nombres, trois causes séparables.

La distinction la plus contre-intuitive concerne les débits. Empiler des requêtes en parallèle fait monter le débit serveur, mais allonge chaque étape de décodage : la machine produit plus de tokens par seconde au total, pendant que chaque utilisateur en reçoit moins. Piloter son infrastructure au seul débit agrégé revient donc à optimiser sa facture en dégradant son produit, sans que le tableau de bord le signale jamais.

Un dernier repère : la documentation de latence d'OpenAI est catégorique sur la hiérarchie des leviers : générer moins de tokens de sortie est « presque toujours l'étape la plus coûteuse en latence », et couper la moitié des tokens produits coupe environ la moitié de la latence, tandis que réduire les tokens d'entrée ne rapporte que 1 à 5 %. Ce déséquilibre découle de la nature séquentielle du decode. Sur le coût, voir « Le vrai coût d'un modèle : tokens, inférence ».

Le batching : le débit du serveur contre la latence de chacun

Puisque le decode laisse les unités de calcul largement au repos, l'idée s'impose : traiter plusieurs requêtes dans le même passage. C'est le batching. Sa forme naïve, dite statique, groupe des requêtes au départ et attend la fin de la plus longue pour libérer les places et lancer le lot suivant. Une requête de trente tokens coincée derrière une requête de mille immobilise donc sa place jusqu'au bout de la seconde.

La réponse académique à ce gâchis date de 2022, avec le système Orca présenté à USENIX OSDI. Sa contribution centrale — l'ordonnancement au niveau de l'itération — reconsidère la composition du lot à chaque pas de décodage plutôt qu'à chaque requête : dès qu'une séquence se termine, sa place est rendue à une requête en attente. C'est aujourd'hui le batching continu, ou in-flight batching chez NVIDIA.

Batching statique contre batching continu. En haut, quatre requêtes démarrent ensemble et les places restent bloquées jusqu'à ce que la plus longue s'achève — les zones vides sont du matériel payé pour ne rien faire. En bas, chaque place libérée est immédiatement réattribuée, sans attendre la fin du lot.

Les gains publiés sont substantiels, à condition de citer leur protocole. Le banc d'essai d'Anyscale de juin 2023, mené sur un OPT-13B et un seul processeur graphique A100 40 Go, avec pour référence un batching statique naïf, rapporte jusqu'à 23× de débit pour vLLM — qui combine batching continu et optimisations mémoire —, 8× pour les moteurs à batching continu simple, et 4× pour FasterTransformer. Ces multiples valent pour cette configuration et cette référence précises, et ne se transposent pas à un autre modèle ou matériel.

Le paysage des moteurs a d'ailleurs bougé. Text Generation Inference, l'un des serveurs qui popularisèrent le batching continu en production, affiche en tête de sa documentation officielle un bandeau de passage en mode maintenance — seuls les correctifs mineurs sont acceptés — et redirige les nouveaux déploiements vers vLLM, SGLang, llama.cpp ou MLX. Quand un éditeur recommande lui-même de migrer ailleurs, c'est un fait de documentation, pas une opinion de marché.

Le batching n'accélère personne. Il permet à la machine de servir davantage de monde pendant le même temps — et chacun attend un peu plus longtemps.
— Principe de l'arbitrage débit / latence

Ce qui plafonne le batch : la mémoire du cache

Si empiler des requêtes améliore le débit, pourquoi ne pas en empiler mille ? Parce que chaque requête active traîne son cache d'attention, qui occupe de la mémoire graphique. Le mécanisme est détaillé dans « Prompt caching & KV cache » ; retenons sa conséquence de dimensionnement.

La taille du cache par token suit une formule simple : deux — clés et valeurs stockées séparément — multiplié par le nombre de couches, par la dimension cachée, par le nombre d'octets de la précision ; multipliée par la taille du lot et la longueur de séquence, elle donne l'empreinte totale. NVIDIA en donne un ordre de grandeur : un Llama 2 7B en précision 16 bits mobilise environ 2 Go de cache pour une seule séquence. Une fois les poids chargés, ce n'est donc plus le nombre de paramètres qui limite les requêtes simultanées, c'est le cache.

D'où l'importance des travaux sur cette mémoire. PagedAttention, publié à SOSP 2023, applique au cache d'attention le principe de la mémoire virtuelle : chaque séquence adresse ses blocs via une table d'indirection, ce qui supprime la fragmentation et autorise le partage entre séquences aux préfixes communs. Les auteurs rapportent un débit multiplié par 2 à 4 face à FasterTransformer et Orca, à latence équivalente. Réduire la précision des poids et du cache produit un effet voisin — levier exploré dans « Quantization : faire tourner un LLM sur sa machine ».

Le décodage spéculatif : deviner plusieurs mots, les vérifier d'un coup

Reste une anomalie à exploiter : pendant le decode, les unités de calcul chôment. Et si l'on s'en servait pour deviner en avance ?

C'est l'intuition du décodage spéculatif, formalisée par Leviathan, Kalman et Matias chez Google Research dans « Fast Inference from Transformers via Speculative Decoding » (2022). Un petit modèle « brouillon », rapide et approximatif, propose plusieurs tokens candidats d'affilée. Le grand modèle les vérifie tous en un seul passage — vérifier plusieurs tokens en parallèle coûte à peu près autant qu'en produire un seul dans un régime borné par la mémoire — et un échantillonnage par rejet accepte ou refuse chaque candidat.

Le point décisif est la garantie mathématique : la distribution des sorties est exactement celle d'un décodage classique du grand modèle. La rétrospective de Google Research et l'introduction publiée par NVIDIA en septembre 2025 insistent toutes deux sur ce point : l'accélération se fait sans perte de qualité. Ce n'est pas une approximation, mais une réorganisation du calcul.

Les gains publiés sont réels, chacun attaché à son protocole. Le papier fondateur rapporte de 2× à 3× sur un T5-XXL de 11 milliards de paramètres assisté d'un brouillon T5-small de 60 millions, sur des tâches de traduction et de résumé. Medusa (ICML 2024), qui greffe des têtes de décodage sur le modèle cible au lieu d'un brouillon séparé, annonce plus de 2,2× en version 1 et 2,3× à 3,6× en version 2 avec entraînement dédié. EAGLE, dont le brouillon travaille sur les représentations internes de l'avant-dernière couche, rapporte de 2,7× à 3,5× sur LLaMA2-Chat 70B. Lookahead decoding, sans modèle brouillon, se situe entre 1,5× et 2,3× selon les jeux d'évaluation. Et le décodage auto-spéculatif, où le modèle se sert de brouillon à lui-même en sautant des couches, atteint 1,99× sur LLaMA-2 sans mémoire supplémentaire.

Le streaming ne rend rien plus rapide

Disons-le nettement : le streaming n'est pas une optimisation de performance. Le temps total de génération reste identique, voire légèrement supérieur du fait de la diffusion incrémentale sur le réseau, et ni le TTFT réel, ni le TPOT, ni le débit du serveur ne s'améliorent. Ce qu'il change, c'est ce que l'utilisateur a sous les yeux pendant l'attente.

Cette nuance n'en fait pas un gadget. Le repère UX classique — un dixième de seconde perçu comme instantané, une seconde qui préserve le fil de la pensée, dix secondes au bout desquelles l'attention décroche — s'applique au premier signe de vie, pas à la réponse complète. Une réponse de huit cents tokens ne tiendra jamais dans la seconde ; son premier mot, si. La documentation de latence d'OpenAI classe d'ailleurs le streaming comme « l'approche la plus efficace », parce qu'elle ramène le temps d'attente ressenti sous la seconde. En interactif, un TTFT de 200 à 500 millisecondes avec streaming est un bon score.

En pratique, si votre TTFT est bon et votre TPOT correct, le streaming transforme le ressenti sans rien changer à l'infrastructure. S'il est mauvais, il ne masquera rien : l'utilisateur attendra le même silence, simplement avant un texte qui défile.

Ce que les modèles de raisonnement changent au profil de latence

Le schéma en deux phases se complique avec les modèles qui dépensent du calcul à l'inférence pour réfléchir avant de répondre — mécanisme détaillé dans « Modèles de raisonnement : payer du calcul à l'inférence ». Ils insèrent une phase de génération de tokens de réflexion entre le prefill et le texte final. Le TTFT du texte visible ne dépend donc plus seulement de la longueur du prompt, mais aussi de cette réflexion interne, qui peut ajouter de plusieurs secondes à quelques dizaines de secondes selon son ampleur.

Les fournisseurs ont produit des réglages pour ce profil. La documentation d'Anthropic sur la réflexion étendue décrit un paramètre d'affichage qui contrôle la diffusion des tokens de raisonnement ; en mode omis, le serveur n'envoie qu'une signature et démarre plus tôt le flux du texte final, améliorant le délai jusqu'au premier token visible. L'avertissement qui l'accompagne compte : omettre réduit la latence, pas le coût — les tokens de réflexion restent facturés. De son côté, la documentation d'OpenAI sur les modèles de raisonnement expose un curseur d'effort qui échange de la latence contre de la qualité sur les problèmes difficiles, et suggère de demander un bref préambule avant le raisonnement pour donner plus tôt un signe de vie.

Servir un modèle vite, c'est donc arbitrer en connaissance de cause : accepter un peu de latence individuelle pour beaucoup de débit collectif, dépenser du calcul disponible sur des tokens devinés, ou écrire des réponses plus courtes. Ils supposent une chose qu'on interroge rarement : que les poids qui tournent sur vos machines soient bien ceux que vous croyez avoir installés. Après la performance vient la confiance — le prochain article remonte la chaîne d'approvisionnement d'un modèle, du jeu de données au fichier téléchargé, pour examiner comment on l'empoisonne et comment on y dissimule des portes dérobées.

Une question, un projet IA ?

Vous dimensionnez un service qui appelle un modèle, arbitrez entre débit, latence et coût d'infrastructure — échangeons sur votre contexte.

Prendre contact →

Pour aller plus loin : côté terrain, nos décryptages d'outils IA montrent comment ces arbitrages de latence se traduisent dans les plateformes du quotidien ; et pour le mécanisme mémoire qui plafonne tout le reste, l'article « Prompt caching & KV cache » détaille ce que le cache d'attention coûte réellement.