DeepSeek, Google et Meta : 10 techniques pour compresser le cache KV des LLM et réduire la mémoire en inférence

Le cache KV, longtemps simple détail annexe, est devenu l'un des principaux goulots d'étranglement de l'inférence de LLM en production. Une nouvelle synthèse recense 10 techniques qui aident à réduire la consommation de mémoire sans réentraîner entièrement le modèle et, dans certains cas, accélèrent nettement la génération.

Où les LLM atteignent leurs limites

Plus le contexte est long et plus le modèle traite de requêtes simultanées, plus le cache KV, le stockage intermédiaire des clés et des valeurs du mécanisme d'attention, gonfle vite. La synthèse donne un exemple parlant : pour un modèle de 30 milliards de paramètres, avec un batch size de 128 et une entrée de 1024 tokens, le cache KV peut occuper jusqu'à 180 Go de mémoire. Même pour un modèle de 7B, les poids occupent environ 14 Go de mémoire GPU, contre environ 72 Go pour le cache : le mécanisme de génération lui-même finit par coûter plus cher que le stockage des paramètres.

L'optimisation du cache KV est donc devenue un chantier à part entière, et non un simple réglage mineur. Compresser le cache permet d'augmenter le batch size, de servir plus d'utilisateurs sur le même GPU et de ne pas buter sur les limites de mémoire avec des prompts longs. Un avantage important : une bonne partie des méthodes agit au stade de l'inférence. Le modèle de base n'a pas à être réentraîné, et l'effet se voit immédiatement sur le débit et le coût du serving.

Comment on le compresse

Les chercheurs emploient aujourd'hui plusieurs stratégies, qui diffèrent non seulement par la qualité, mais aussi par leur place dans le pipeline. Certaines méthodes écartent les tokens les moins utiles, d'autres réduisent la précision de la représentation du cache, d'autres encore modifient l'architecture d'attention elle-même. Une classe à part redistribue la mémoire entre les couches, car les premières couches ont besoin d'un contexte plus riche, tandis que les couches profondes peuvent se contenter d'un jeu de clés et de valeurs plus réduit. Au fond, il ne s'agit plus de pourcentages d'économie, mais de la possibilité de faire tourner un long contexte sur le même matériel.

• Éviction de tokens : H2O, StreamingLLM et SnapKV ne conservent qu'une partie des états. H2O garde les tokens « lourds », qui contribuent le plus à l'attention ; StreamingLLM conserve les premiers tokens et une fenêtre récente ; SnapKV choisit les positions importantes d'après l'attention en fin de prompt.
• Répartition du budget par couche : PyramidKV et PyramidInfer partent du principe que les couches profondes n'ont pas besoin d'un contexte aussi riche que les premières, et allouent donc la mémoire de façon inégale.
• Quantification : KIVI, KVQuant et TurboQuant réduisent la précision de la représentation du cache KV, tout en cherchant à ne pas perdre en qualité de génération.
• Changements d'architecture : MQA, GQA et MLA réduisent la taille du cache au niveau du schéma d'attention lui-même, et non par-dessus un modèle déjà prêt.
• Compression de bas rang : Palu, LoRC et les méthodes voisines réduisent la dimension cachée des tenseurs KV, et non la longueur de la séquence.

Les plus simples à exploiter sont les méthodes sans fine-tuning. H2O repère les tokens qui concentrent l'essentiel de l'attention et élimine les positions faibles. StreamingLLM garde les premiers tokens comme « ancres d'attention » plus une fenêtre récente, ce qui convient aux conversations sans fin, mais risque de perdre un passage important du milieu. SnapKV agit au stade du prefill et sélectionne les positions importantes séparément pour chaque tête d'attention ; à limite de cache égale, il l'emporte donc généralement sur les schémas plus grossiers.

La distribution des poids d'attention ressemble souvent à une loi de

puissance, si bien que supprimer les tokens à faible contribution n'abîme pas toujours beaucoup la qualité.

Qui offre le meilleur gain

En quantification, KIVI, KVQuant et TurboQuant se distinguent nettement. KIVI convertit le cache KV en représentation 2 bits sans fine-tuning et, selon la synthèse, réduit jusqu'à 2,6 fois le pic de mémoire de l'ensemble poids plus cache, tout en autorisant des lots jusqu'à quatre fois plus grands. KVQuant va plus loin : il recourt à la calibration, à la précision mixte et à un traitement séparé des valeurs aberrantes pour préserver la qualité même sur des contextes extrêmement longs.

Le résultat le plus spectaculaire du document est attribué à TurboQuant, de Google Research. Cette méthode uniformise d'abord la distribution des valeurs par une rotation orthogonale aléatoire, puis corrige l'erreur de quantification pour que l'estimation des produits scalaires reste non biaisée. Sur un H100, elle affiche au moins une réduction de mémoire par 6 et une attention jusqu'à 8 fois plus rapide avec une précision de 3 bits. Pour les équipes d'infrastructure, il ne s'agit plus d'une optimisation locale, mais d'une candidature à un nouveau standard de serving.

Une autre voie consiste à changer l'architecture du modèle elle-même. GQA est devenu de facto la norme des LLM open-weight actuels : utilisé seulement dans la version 70B de Llama 2, il s'est étendu dans Llama 3 aux versions 8B et 70B. Le MLA de DeepSeek va encore plus loin : au lieu de clés et de valeurs de taille complète pour chaque token, il stocke une représentation latente compressée. La synthèse indique que DeepSeek-V2 a réduit son cache KV de 93,3 % grâce au MLA, par rapport au précédent modèle dense de 67B.

Ce que cela change

Le marché des LLM dépend de moins en moins de la seule taille des poids et de plus en plus du prix de la mémoire en contexte long. Pour les équipes qui construisent des services d'inférence, la conclusion est simple : le gain ne vient plus d'une technique miracle, mais d'un choix réfléchi entre éviction, quantification et architecture, selon la charge de travail, le SLA et le budget GPU.