Cache KV et batching : pourquoi une IA rapide peut vous faire attendre

Un serveur peut produire davantage de texte par seconde tout en faisant attendre plus longtemps certains utilisateurs. Il faut distinguer le débit global, le délai avant le premier morceau de réponse et le temps nécessaire pour recevoir la réponse complète. Le cache KV et le regroupement de requêtes modifient ces mesures, mais n’améliorent pas toutes ces mesures de la même façon dans toutes les configurations.

Ces notions concernent notamment le service de modèles de langage autorégressifs, qui construisent leur sortie progressivement. Elles aident à lire un essai de performance sans confondre puissance de calcul et qualité de l’attente ressentie.

Quatre chronomètres pour une seule réponse

Pour l’utilisateur, le délai commence lorsqu’il envoie sa demande. Côté serveur, plusieurs étapes peuvent se succéder : attente dans une file, traitement du texte d’entrée, génération, transmission. Une mesure limitée au calcul du modèle omet une partie de ce parcours.

Mesure	Question à laquelle elle répond	Ce qu’elle ne décrit pas seule
Délai avant le premier token	Quand la réponse commence-t-elle ?	Quand sera-t-elle complète ?
Temps entre tokens	Le texte arrive-t-il régulièrement ?	Combien de temps a précédé le premier token ?
Durée totale	Quand la réponse entière est-elle disponible ?	Quelle part vient de sa longueur ?
Débit du service	Combien de sorties le système produit-il sur une durée ?	Le délai subi par chaque personne

Le mot token désigne une unité de traitement du texte, pas nécessairement un mot. Le guide sur les tokens et la fenêtre de contexte précise cette différence. Comparer des débits entre modèles ou entre langues demande donc de regarder ce qui a réellement été produit.

Le cache KV garde un travail déjà effectué

Dans l’attention d’un Transformer autorégressif, les clés et valeurs, souvent abrégées K et V, représentent des informations utilisées pour traiter les positions précédentes. Le cache KV conserve ces éléments afin d’éviter de les recalculer à chaque nouveau token. Il consomme de la mémoire et accompagne l’état d’une génération. La documentation Transformers sur les caches décrit plusieurs stratégies : cache dynamique, allocation fixe, déplacement vers la mémoire du processeur ou réduction de précision.

Ce cache ne constitue pas une base de connaissances persistante de l’entreprise. Il ne garantit ni exactitude de la réponse ni mise à jour documentaire. Il ne faut pas non plus le confondre avec un cache de réponses complètes qui renverrait un résultat déjà calculé.

L’enjeu de dimensionnement est double : conserver les informations nécessaires à chaque séquence et servir plusieurs séquences simultanément. Le travail original sur PagedAttention traite précisément la gestion de cette mémoire pour le service de grands modèles. Il montre pourquoi l’organisation du cache peut limiter le nombre de requêtes prises en charge. Ses résultats expérimentaux concernent les configurations de l’étude, pas une accélération garantie pour tout déploiement.

Regrouper les requêtes change l’utilisation du serveur

Un lot, ou batch, permet de traiter plusieurs requêtes ensemble. Dans un lot fixe, les requêtes n’ont pas forcément la même longueur : certaines finissent alors que d’autres continuent. Le continuous batching recompose le groupe pendant la génération pour faire entrer de nouvelles requêtes lorsque d’autres se terminent. C’est le principe décrit dans la documentation Hugging Face dédiée.

Cette organisation cherche à mieux utiliser la ressource disponible. Mais une règle qui attend davantage de requêtes avant de lancer un travail peut allonger une attente individuelle. Une politique d’ordonnancement doit donc être examinée sous charge, avec de vraies différences de longueur, et pas seulement sur un ensemble de requêtes identiques arrivé au même instant.

On peut visualiser le problème sans supposer un comportement précis de logiciel : une requête courte arrive pendant qu’une longue est déjà en cours. Le service doit décider quand préparer la nouvelle entrée et comment partager les ressources avec les sorties en cours. Le résultat dépend de ses règles et de la capacité disponible.

Un débit supérieur n’est pas une conversation plus fluide

Prenons deux services entièrement fictifs pendant une minute, avec les mêmes demandes et des sorties de même longueur. A termine 60 réponses et B en termine 80. Le débit de B est supérieur sur cette fenêtre. Supposons cependant que le délai avant le premier token de la requête étudiée passe de 0,4 seconde chez A à 1,2 seconde chez B. Pour cette personne, la réponse commence plus tard.

Cet exemple est logiquement possible ; il ne décrit aucune mesure réelle. Il rappelle qu’un nombre agrégé ne contient pas la distribution des attentes. Pour comparer les services, il faut joindre aux moyennes des quantiles, par exemple le délai en dessous duquel se trouvent 95 % des observations, en précisant la taille et la nature de l’échantillon.

Il faut aussi compter les requêtes refusées ou interrompues. Un service qui ignore les demandes difficiles peut afficher une belle latence sur celles qu’il accepte. Le protocole devrait rapporter à la fois demandes envoyées, terminées, échouées et encore en attente à la fin de la fenêtre.

La mémoire économisée peut se payer ailleurs

Les stratégies de cache sont des compromis d’implémentation. Transformers indique notamment qu’un cache quantifié peut réduire la mémoire mais nuire à la latence dans certains cas ; déplacer le cache vers le processeur ajoute des transferts. Une allocation fixe peut faciliter certaines optimisations tout en réservant de l’espace inutilisé. Ces propriétés documentées ne classent pas les stratégies pour votre charge particulière.

Le guide sur la mémoire et le calcul des puces IA fournit le contexte matériel. Ici, la décision pratique consiste à mesurer quelle contrainte domine pour les longueurs d’entrée, longueurs de sortie et nombres de requêtes simultanées du service envisagé.

Changer la précision du cache mérite également une vérification des sorties. Une optimisation de performance n’est pas une autorisation implicite de modifier le niveau de qualité attendu. Conserver la version du moteur et ses réglages rend le résultat interprétable lorsqu’une mise à jour change les compromis.

Le protocole minimum d’une démonstration utile

Préparer plusieurs profils de requêtes : entrée courte et sortie courte, entrée longue et sortie courte, génération longue, puis mélange représentatif. Fixer le modèle, les limites de sortie et les critères de réussite. Monter progressivement la charge et relever à chaque niveau les quatre mesures du tableau.

Distinguer un démarrage à froid d’un service déjà chargé en mémoire. Documenter les éventuels préfixes partagés entre requêtes et leur mise en cache. Garder le même point de mesure, idéalement depuis le client lorsque l’objectif est l’expérience utilisateur. Les temps internes restent utiles pour diagnostiquer, mais ne remplacent pas ce parcours complet.

Le livrable pertinent n’est donc pas « tant de tokens par seconde ». C’est une courbe de service : à quelle charge les réponses restent correctes, dans quel délai, avec quel taux d’échec et quelles ressources. Elle permet de choisir une configuration pour un usage, sans transformer une optimisation technique en promesse universelle.

Sources et portée

Consultées le 22 octobre 2026 : Transformers, stratégies de cache et continuous batching, documentations évolutives ; Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023. Les tableaux et le protocole sont une synthèse pédagogique ; l’exemple de latence est fictif.