Pourquoi le cache KV augmente-t-il avec la longueur du contexte de l’IA locale ?

Le cache KV augmente avec la longueur du contexte, car le moteur stocke les clés et les valeurs d’attention de chaque token conservé à travers plusieurs couches du modèle.

Une courte invite d’IA à domicile peut laisser suffisamment de mémoire pour plusieurs utilisateurs, tandis qu’un long document, un historique de conversation étendu ou la trace d’un agent peut consommer beaucoup plus de mémoire de travail sans modifier le fichier du modèle lui-même. Le cache commence à se constituer pendant le traitement de l’invite et continue de croître lorsque le modèle génère de nouveaux tokens. Sa taille dépend également du nombre de couches, de l’architecture de l’attention, de la précision numérique et du nombre de requêtes simultanées. Les sections ci-dessous suivent cette croissance, du premier token jusqu’à la limite de mémoire du serveur.

Chaque token conservé ajoute un état d’attention

Lors de l’inférence avec un transformeur, chaque couche produit des tenseurs de clés et de valeurs à partir des tokens déjà traités. Le moteur conserve ces tenseurs afin que le token suivant puisse prêter attention au contexte précédent sans recalculer toute la séquence.

Les travaux sur vLLM identifient l’état KV par token comme un besoin majeur en mémoire pour le service des modèles. Les nouveaux tokens ajoutent de nouvelles entrées au cache, tandis que les entrées précédemment conservées restent disponibles lors des étapes d’attention suivantes.

Le cache constitue donc un état mutable de la requête, et non une partie des poids statiques du modèle. Charger le même modèle avec une conversation active plus longue crée une empreinte mémoire plus importante.

La croissance du cache est approximativement linéaire avec la longueur de séquence conservée

Pour une architecture de modèle et une précision de cache données, doubler le nombre de tokens conservés double approximativement le nombre d’entrées KV maintenues pour cette requête. L’invite et la réponse générée comptent toutes deux dans la séquence active.

H2O décrit comment le cache KV évolue avec la longueur de séquence et la taille du lot. La relation reste approximativement linéaire, car chaque token supplémentaire apporte des clés et des valeurs dans chaque couche qui produit un cache.

C’est pourquoi le fait d’augmenter un paramètre d’exécution, en passant d’un contexte réduit à une limite maximale beaucoup plus élevée, peut modifier le plafond de mémoire pratique, même lorsque le modèle utilise des poids identiques.

Le paramètre maximal et l’utilisation réelle sont deux choses différentes. Certains moteurs allouent les blocs de cache à la demande, tandis que d’autres réservent rapidement une zone plus importante afin de garantir la croissance future.

L’architecture du modèle modifie le nombre d’octets par token

Deux modèles ayant le même nombre de paramètres peuvent nécessiter des quantités de mémoire KV différentes, car ils peuvent utiliser un nombre différent de couches, des dimensions de tête différentes, un nombre différent de têtes d’attention, une attention à requêtes groupées ou une attention à requêtes multiples.

KIVI étudie la précision du cache KV et montre que le stockage des clés et des valeurs avec moins de bits peut réduire considérablement la mémoire de pointe. Cet avantage concerne l’état des requêtes, sans réduire les poids sous-jacents du modèle.

Les architectures à requêtes groupées et à requêtes multiples partagent les têtes clé-valeur entre un plus grand nombre de têtes de requête, ce qui peut réduire le nombre d’octets de cache par token par rapport à une attention entièrement multi-tête. Le nombre de couches et la largeur des têtes continuent toutefois de multiplier l’état conservé.

Une estimation utile doit donc s’appuyer sur l’architecture exacte du modèle et le format de cache du moteur, et non uniquement sur une règle générique d’octets par token copiée d’un autre modèle.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Les tokens générés continuent d’étendre le cache après le préremplissage

Le traitement de l’invite crée le cache initial correspondant au contexte d’entrée. Le décodage autorégressif ajoute ensuite l’état de chaque token de sortie accepté, afin que les tokens suivants puissent prêter attention à l’intégralité de la conversation.

vAttention considère la croissance dynamique du cache comme un problème d’allocation, car la longueur finale de la sortie est inconnue au début d’une requête. Réserver trop de mémoire la gaspille, tandis qu’en réserver trop peu peut imposer une préemption ou un travail d’extension.

Une invite qui tient largement dans la mémoire peut tout de même dépasser la limite pendant une longue réponse. Les limites de sortie protègent donc la mémoire, mais aussi la longueur de la réponse et le temps de génération.

Les utilisateurs simultanés multiplient les états de contexte distincts

Les poids du modèle peuvent être partagés entre les requêtes, mais chaque conversation active possède généralement son propre historique de tokens et son propre cache KV. Cinq utilisateurs ayant de longs contextes ne partagent pas un cache universel simplement parce qu’ils utilisent le même modèle.

Les recherches récentes sur la gestion du KV présentent les réservations par requête comme un compromis central entre efficacité mémoire et risque de préemption. L’inconnu concernant la longueur des sorties rend le pic combiné plus difficile à prévoir qu’un simple nombre d’utilisateurs.

Les préfixes d’invite partagés peuvent parfois réutiliser l’état du cache lorsque le moteur prend en charge la correspondance exacte des préfixes, mais l’historique privé des conversations et les sorties divergentes créent toujours des branches distinctes.

Le guide matériel de ZimaSpace considère le contexte et la simultanéité comme des besoins mémoire qui s’ajoutent au fichier du modèle. Un test avec un seul utilisateur peut donc sous-estimer la quantité de RAM ou de VRAM nécessaire à un assistant domestique.

La pagination, la quantification et l’éviction modifient la limite, pas la cause

L’allocation paginée réduit la fragmentation en divisant l’état du cache en blocs plus petits. Le moteur n’a ainsi pas besoin d’une seule réservation contiguë surdimensionnée pour chaque séquence possible.

PagedAttention fournit une allocation par blocs, tandis que la quantification du cache réduit le nombre d’octets par valeur stockée et que les politiques d’éviction suppriment certaines anciennes entrées. Chaque méthode modifie la quantité de contexte qui tient en mémoire, mais l’état d’attention conservé continue de croître à mesure que les tokens s’accumulent.

L’éviction ou les fenêtres glissantes peuvent plafonner la mémoire en supprimant les tokens précédents, mais le modèle ne peut alors plus prêter attention à l’état supprimé par le chemin normal de contexte complet. La compression et la conservation sélective peuvent également entraîner des compromis liés à la qualité ou à la charge de travail.

Mesurez l’utilisation du cache avec le modèle réel, le contexte, la précision du cache, la taille du lot et le nombre d’utilisateurs réels. La limite pratique est atteinte lorsqu’un token ou une requête supplémentaire ne peut pas être admis sans éviction, transfert vers une autre mémoire, recalcul ou échec.

FAQ

Le fichier du modèle devient-il plus volumineux lorsque la longueur du contexte augmente ?

Non. Les poids du modèle restent identiques. La mémoire supplémentaire correspond à l’état d’exécution créé pour l’invite active et les tokens générés.

Le fait de définir une grande longueur de contexte maximale alloue-t-il toujours immédiatement toute la mémoire KV ?

Non. Le comportement d’allocation dépend du moteur. Certains réservent rapidement de la capacité, tandis que les systèmes paginés allouent des blocs au fur et à mesure que les tokens sont admis.

La RAM peut-elle stocker le cache KV lorsque la VRAM est pleine ?

Certains moteurs peuvent déporter ou déplacer l’état du cache, mais les transferts ajoutent de la latence et dépendent de la prise en charge logicielle, de la bande passante et du chemin d’attention actif.