Passer au contenu principal
Le cache KV est la mémoire active d’une conversation qu’un modèle construit au fur et à mesure qu’il traite votre invite et génère une réponse — et c’est la raison pour laquelle un contexte plus long coûte plus de VRAM, même si la taille du modèle lui-même ne change pas. Cette page explique ce qu’il est et pourquoi il grandit de cette manière ; pour les mécaniques de préremplissage (prefill) et de décodage (decode) qui le construisent et l’utilisent, consultez Comment fonctionne l’inférence.

​
Ce qu’est réellement le cache KV

« KV » signifie clé/valeur (key/value) — les représentations internes que le modèle calcule pour chaque jeton qu’il a traité jusqu’à présent. Au lieu de recalculer ces représentations à partir de zéro pour chaque nouveau jeton, le modèle les stocke dans le cache KV et les réutilise, en ajoutant une nouvelle entrée chaque fois qu’un jeton est ajouté à la séquence. C’est ce qui rend la génération praticable. Sans cache, générer le jeton 500 d’une réponse signifierait retraiter tous les 499 jetons qui le précèdent, à chaque fois. Avec le cache, le modèle n’a à effectuer que le nouveau travail pour chaque nouveau jeton, et réutilise tout ce qu’il a déjà calculé. Le cache est construit pendant le préremplissage (lorsque le modèle lit votre invite) et étendu d’une entrée par jeton pendant le décodage (lorsqu’il génère la réponse) — consultez Comment fonctionne l’inférence pour comprendre comment fonctionnent ces deux phases.

​
Pourquoi un contexte plus long coûte plus de mémoire

Le cache KV contient une entrée par jeton, par couche, aussi longtemps que ce jeton reste dans le contexte actif. Cela signifie que sa taille évolue directement avec :
  • Context length — plus de jetons en jeu signifie plus d’entrées dans le cache. Une conversation de 128K jetons contient beaucoup plus d’état mis en cache qu’une conversation de 4K jetons.
  • La taille du lot (batch size) — si vous servez plusieurs requêtes simultanément, chacune nécessite son propre cache KV, donc la mémoire totale du cache est multipliée par les requêtes concurrentes.
Il s’agit de mémoire en plus de les poids du modèle, et non à la place d’eux. Un modèle qui tient à peine dans votre VRAM avec un contexte court peut manquer complètement de mémoire une fois que vous le poussez vers une longue conversation ou un grand document, car les poids restent fixes mais le cache continue de croître. Consultez Mémoire et délestage pour voir comment le cache KV s’intègre dans la formule de dimensionnement complète, et le guide d’ajustement du modèle sur GPU pour des tableaux VRAM concrets — cette page ne répétera pas ces chiffres.

​
Le compromis contexte-vitesse

Au-delà de la mémoire, un cache KV plus important a également un coût en vitesse. Le décodage est limité par la bande passante mémoire — à chaque jeton généré, le modèle lit l’intégralité du cache KV construit jusqu’à présent, en plus de ses poids (voir Comment fonctionne l’inférence). Un cache plus grand signifie plus de données à lire à chaque étape, donc :
  • Un contexte plus long ralentit le décodage. La vitesse de génération (jetons/sec) a tendance à diminuer au fur et à mesure que la conversation grandit, même si le modèle lui-même n’a pas changé.
  • Un contexte plus long coûte plus de mémoire, indépendamment du coût en vitesse — c’est une deuxième facture, séparée.
Les deux effets proviennent de la même cause racine : le cache KV évolue avec le contexte, et tout ce qui concerne le décodage évolue avec le cache KV.
Il n’y a aucun moyen de contourner ce compromis en choisissant une quantification différente — la quantification des poids et la quantification du cache KV sont des leviers distincts, et certains backends prennent en charge la quantification du cache KV indépendamment comme moyen de faire tenir des contextes plus longs. Il s’agit d’un paramètre spécifique au backend ; vérifiez la documentation de votre runtime pour le support avant de vous y fier.

​
Conclusion pratique

Lorsque vous décidez de la quantité de contexte à allouer pour un déploiement, considérez-le comme un budget de ressources réel, et non comme un paramètre gratuit. Un modèle annoncé avec un contexte maximum énorme (128K, 256K) ne signifie pas que vous devez toujours l’exécuter à cette limite — dimensionnez votre contexte en fonction des besoins réels de la tâche, et vérifiez le coût mémoire réel avec le guide d’ajustement du modèle sur GPU avant de vous engager.

​
Pour aller plus loin

Comment fonctionne l'inférence

Le cycle de vie complet de l’invite — préremplissage, décodage, et ce qui va où en mémoire.

Mémoire et délestage

La formule de dimensionnement complète, incluant les poids et la surcharge en plus du cache KV.

​
Une fois le contexte et la mémoire adaptés

Dimensionner votre cache KV fait partie de faire fonctionner un modèle correctement localement. Une fois qu’il fonctionne et répond aux requêtes sur localhost, l’étape suivante est d’y accéder depuis n’importe où ailleurs.

Donnez-lui un point de terminaison stable

Tokios ne choisit, n’héberge ni n’affine le modèle — une fois qu’il fonctionne localement, Tokios le transforme en un point de terminaison stable et authentifié que vous pouvez appeler depuis n’importe où.