FR
Une représentation de cache partagée pour plusieurs couches
BellowsKV: One Latent for Many Layers, Expanded on Demand · arXiv:2610.35023
En termes simples
Les modèles de langue gardent une trace des mots précédents pour pouvoir répondre à partir d’un long texte, mais chaque couche stocke son propre cache. BellowsKV est une méthode de compression qui ne nécessite pas de réentraîner le modèle : elle stocke une représentation par jeton pour des couches voisines, puis chaque couche reconstitue ses propres clés et valeurs d’attention au moment voulu.
Les auteurs ont constaté que les entrées de couches voisines se ressemblaient, même lorsque les éléments de leur cache étaient différents. Sur trois modèles, la version quantifiée a conservé environ 97–98 % des scores des modèles non compressés, en moyenne sur 11 tâches à long contexte et avec une compression d’environ 13–14 fois.
La recherche
Un modèle de langue à long contexte garde une trace distincte des jetons précédents dans chaque couche, et chaque requête nécessite son propre cache.
Des couches voisines peuvent-elles partager cette mémoire pendant la génération tout en récupérant les différentes clés et valeurs d’attention dont chacune a besoin ?
BellowsKV est une méthode sans réentraînement qui stocke une représentation partagée calibrée pour chaque jeton entre couches voisines, puis reconstitue les clés et valeurs propres à chaque couche.
Trois modèles d’instructions ont été évalués avec le banc d’évaluation des auteurs de xKV sur LongBench, qui regroupe 11 tâches en anglais portant sur les questions-réponses, le résumé et la recherche de détails dans de longs textes.
Pour chaque tâche, le score a été divisé par celui du même modèle avec cache non compressé, puis les résultats ont été moyennés. La version quantifiée de BellowsKV a conservé 97–98 % des scores avec une compression de 13–14× ; xKV en a conservé 54–84 % avec une compression proche de 16×.
Ces résultats appuient le stockage de la représentation partagée dans sa dimension complète avec moins de bits, même si les taux de compression diffèrent.
Les résultats sur LongBench portent sur trois modèles et 11 tâches, avec des entrées de plus de 4 000 et jusqu’à 32 000 jetons. Les points de comparaison de BellowsKV utilisent aussi des taux de compression inférieurs à ceux de xKV et CommonKV.
Ce que montrent les preuves
- Partir du coût mémoire
BellowsKV compresse sans entraînement supplémentaire le cache clé-valeur (KV) d’un modèle, c’est-à-dire les traces que chaque couche conserve des jetons précédents.
Chaque requête possède un cache distinct pour chaque couche ; les entrées longues et les lots de requêtes plus grands augmentent donc la mémoire utilisée. La question est de savoir si des couches voisines peuvent partager les informations stockées tout en retrouvant leurs propres clés et valeurs d’attention.
- Repérer les informations communes
Les auteurs ont comparé, jeton par jeton, des couches voisines de modèles Llama et Qwen non compressés. Ils ont mesuré la similarité cosinus, qui indique si des vecteurs pointent dans des directions semblables, pour les états cachés et les éléments du cache.
Les états cachés étaient très similaires, tandis que les clés et valeurs correspondantes avaient une similarité proche de zéro. Cela indique que les informations communes se trouvent dans les entrées servant à former le cache, et non dans des éléments du cache qu’une couche pourrait réutiliser.
- Reconstruire le cache de chaque couche
BellowsKV ajuste une projection à partir de données de calibration pour chaque bloc de couches voisines. Cette projection sert à stocker une représentation partagée par jeton, puis chaque couche applique sa propre projection pour reconstruire ses clés et ses valeurs.
La représentation partagée conserve sa dimension complète ; sa taille est réduite soit en stockant les valeurs avec moins de bits, soit en supprimant certains jetons au moyen d’une décision commune au bloc.
- Mesurer les performances préservées
LongBench regroupe 11 tâches en anglais portant sur les questions-réponses, le résumé et la recherche d’informations dans de longs textes. Le banc d’évaluation des auteurs de xKV a mesuré trois modèles d’instructions sur des entrées de plus de 4 000 et jusqu’à 32 000 jetons.
L’article a divisé, pour chaque tâche, le score compressé par le score du même modèle avec cache non compressé, puis a calculé la moyenne sur les tâches. La version quantifiée de BellowsKV a conservé 97–98 % des scores avec une compression de 13–14× ; xKV en a conservé 54–84 % avec une compression proche de 16×.
- Examiner l’hypothèse du rang
Un contrôle a comparé la base de xKV au quart de son rang en fp16, avec une compression de 16×, à xKV-hold, qui garde une base proche du rang complet mais la stocke avec une précision de quatre bits, pour une compression de 15,06×.
La rétention a progressé sur Llama et Mistral, de 83,5 % à 97,6 % et de 79,5 % à 99,2 %, mais a baissé de 54,4 % à 23,4 % sur Qwen. Comme le rang et la précision ont changé ensemble, ce contrôle ne peut isoler aucun des deux facteurs ; les auteurs n’expliquent pas non plus le résultat sur Qwen.
- Vérifier la recherche sur d’autres modèles
BrowseComp-Plus évalue la recherche d’informations en un tour suivie d’une réponse, et son juge note les réponses à 830 requêtes. Avec une invite de 32 768 jetons remplie de passages distracteurs difficiles, les scores de BellowsKV avec une compression de 14,61× sont proches de ceux de l’exécution avec cache non compressé : 86,02 contre 85,54 sur Qwen3-32B et 85,78 contre 86,14 sur Qwen3-30B-A3B.
Ces résultats ajoutent des éléments pour deux modèles et une tâche ; ils n’établissent pas des performances générales sur d’autres tâches.
Détails
- Auteurs de l’article original
- Jiamu Zhang, Hanjie Chen
- Soumis à arXiv
- Licence
- CC BY 4.0