LLM : KV cache et prefix cache accélèrent le service

Servir un modèle de langage ne consiste pas qu’à exécuter un Transformer à chaque requête. Deux caches complémentaires, l’un pour la génération en cours et l’autre pour des débuts de prompts récurrents, allègent le calcul. Leur efficacité dépend autant de la gestion de la mémoire GPU que de la façon de repérer et réutiliser les bons segments, y compris quand l’entrée devient multimodale.

La mémoire du cache est limitée: évictions et LRU sur GPU

La capacité allouée au KV cache est bornée et peut saturer si le service ajoute des blocs en continu. Lorsque l’espace vient à manquer en mémoire GPU, une politique d’éviction s’impose. Une stratégie fréquente est LRU, pour supprimer d’abord les blocs les moins récemment utilisés et faire de la place aux nouveaux calculs. Un exemple illustre la suppression de blocs anciens marqués [OLD] pour accueillir des blocs [NEW] tout en conservant des blocs récents. En pratique, le service doit arbitrer en permanence quels segments K/V conserver et lesquels retirer.

Au cœur du décodage, un état K/V réutilisé à chaque token

Un LLM produit sa sortie pas à pas, un token après l’autre, en s’appuyant sur l’attention pour relier le nouveau token au contexte. À chaque étape, le modèle génère des tenseurs Key et Value pour les tokens déjà traités, utiles aux tokens suivants. Sans mise en cache, ces états seraient recalculés en boucle, avec un coût croissant au fil de l’allongement de la séquence. Le KV cache évite ces recomputations en stockant les états K/V en mémoire, souvent sur GPU, et en les réutilisant au prochain pas de décodage. Lors du pré-remplissage d’un prompt comme « J’aime les LLM », les états K/V sont construits puis réemployés pendant la génération, tandis que chaque token ajouté contribue à de nouveaux états. Le mécanisme maintient ainsi l’état d’attention au fil de la réponse. Ce cache est toutefois attaché à la requête active et ne profite pas, en l’état, à une demande ultérieure sans lien.

Mutualiser les débuts communs entre requêtes avec un cache de préfixes

Quand deux utilisateurs envoient des prompts partageant un long préambule identique — par exemple un rôle d’assistant, des politiques, des instructions et des définitions d’outils —, recalculer ce préfixe à chaque fois gaspille du calcul. Le prefix caching permet de réutiliser les états K/V déjà construits pour la portion commune, en étendant la réutilisation au-delà d’une seule requête. Cette technique peut fortement réduire le coût de pré-remplissage pour des charges où de nombreuses demandes débutent de la même façon, à condition que le préfixe corresponde exactement.

Identifier et réutiliser les segments: blocs de tokens et hachage

Pour exploiter ces redondances, le service découpe le prompt en blocs de tokens de taille fixe, chaque bloc correspondant à une portion d’état K/V. Un hash, dérivé du contenu du bloc et de sa position dans le préfixe, sert d’identifiant compact. Ce marquage permet de savoir rapidement si un bloc a déjà été calculé, sans comparer les prompts en entier. Dans un exemple, deux premiers blocs partagés conduisent à des cache hits, tandis que les suivants, différents, mènent à des cache misses; seuls ces derniers exigent un passage par le modèle. Le point décisif est la transition du hit à la réutilisation effective des états K/V. À noter que le cache ne stocke pas le texte pour le recopier, mais l’état K/V calculé, qui peut être chargé à nouveau quand le même préfixe réapparaît.

La gestion du cache prend en compte les différences d’images dans les requêtes

Dans un scénario multimodal, deux requêtes avec un texte identique mais des images différentes ne peuvent pas être traitées comme équivalentes par le cache. L’éligibilité à la réutilisation doit intégrer une représentation correcte de chaque modalité. Cette exigence est particulièrement importante pour le service de modèles vision-langage, où les prompts combinent texte, images, audio ou d’autres types d’entrées.