Geler le décodeur lors de la compression du KV-cache divise la mémoire par 3, mais n'améliore pas la précision

Les chercheurs à l'origine du préprint arXiv 2610.10552 montrent qu'une conclusion répandue, « lors de la compression du KV-cache, il ne faut affiner que l'encodeur et geler le décodeur », reposait sur une erreur méthodologique. Avec un learning rate commun, la variante encodeur battait les alternatives avec une signification statistique apparente sur plusieurs seeds. Une fois un learning rate propre réglé pour chaque variante, l'écart disparaît. Ce qui reste est réellement mesuré : trois fois moins de paramètres entraînables et trois fois moins de mémoire pour l'état de l'optimiseur, à qualité égale.

Comment naît un avantage illusoire

Voici le contexte. L'adaptation d'un modèle existant à un cache compressé fonctionne ainsi : les matrices des clés et des values sont décomposées par SVD en deux facteurs. Le premier, la down-projection, est appelé encodeur par les auteurs. Il comprime la représentation dans un espace latent de faible rang. Le second, la up-projection, est appelé décodeur. Il redéploie le latent vers l'espace d'origine. On obtient un cache dans l'esprit de multi-head latent attention, mais sans entraînement from scratch. La troncature du rang dégrade la précision ; un court fine-tuning, la « guérison » (healing), suit donc.

Où se situe l'erreur de comparaison ? Les variantes de healing diffèrent fortement par leur nombre de paramètres entraînables : encodeur seul, décodeur seul, ou les deux facteurs. Si l'on impose le même learning rate à toutes, il convient à la plus petite variante et pénalise les plus grandes. D'après la description des auteurs, les grandes variantes obtiennent alors une moyenne sous-estimée et une variance surestimée. Il en ressort un avantage important, d'apparence reproductible, pour le plus petit jeu de paramètres. Aucun effet réel ne se cache derrière.

Ce qui a été testé et ce qui en ressort

L'expérience principale a été menée sur le modèle multimodal Qwen2.5-VL-3B-Instruct. Le learning rate a été réglé séparément pour chaque variante, avec trois seeds par configuration. Le résultat a été reproduit sur un banc d'essai textuel avec deux modèles de base différents.

• Méthode : factorisation SVD des poids key/value en encodeur et décodeur, suivie d'un court fine-tuning.
• Variantes comparées : healing de l'encodeur seul, du décodeur seul et des deux facteurs.
• Protocole : réglage individuel du learning rate, trois seeds par configuration.
• Résultat sur la qualité : la variante encodeur atteint la parité avec les alternatives.
• Résultat sur les ressources : 3 fois moins de paramètres entraînables et 3 fois moins de mémoire pour l'état de l'optimiseur.
• Limite : la vérification sur VLM ne couvre qu'un seul taux de compression.

La réserve sur le taux de compression figure dans l'abstract même et ne doit pas être éludée. La parité n'est confirmée qu'en un seul point ; son extension à des degrés de compression plus agressifs reste une hypothèse. La réplication sur des modèles textuels renforce la confiance, mais les modèles y sont petits et l'étude ne fournit aucune donnée à plus grande échelle.

Ce qu'il faut changer en pratique

Pour les équipes qui convertissent des modèles déjà entraînés vers un cache compressé, la conclusion est pratique. Ne soigner que l'encodeur a du sens, mais pour des raisons d'économie : un décodeur gelé retire à l'optimiseur deux tiers de la charge en paramètres et en mémoire. Cela se remarque quand le fine-tuning tourne sur un nombre limité de GPU et que le modèle occupe déjà presque toute la mémoire. En revanche, il ne faut pas en attendre de gain de précision.

La seconde recommandation est plus large et concerne toute comparaison de recettes de fine-tuning, y compris les schémas de type LoRA. Si les variantes ont un nombre différent de paramètres entraînables, un learning rate commun ne peut pas être considéré comme une condition neutre. Il fausse discrètement le résultat en faveur de l'un des participants. L'hygiène minimale : un sweep de learning rate distinct pour chaque variante et plusieurs seeds. La petite variante ne récolte alors pas une gloire imméritée, et l'équipe ne perd pas des semaines à reproduire un effet qui n'existe pas.

Si vous comptez appliquer la méthode avec un autre taux de compression, mieux vaut revérifier la parité sur vos propres données. Un run supplémentaire avec un learning rate ajusté coûtera moins cher qu'un mauvais choix de recette en production.