Réduire la mémoire d'un modèle de langage : les économies sont plus faibles que ne le suggèrent les articles

Lorsqu'un modèle de langage traite un long prompt, il stocke une clé et une valeur pour chaque token. Cet ensemble forme le cache KV. Pour 32 000 tokens, il occupe 2,4 Go par requête sur le modèle testé. De nombreux articles proposent d'en supprimer la majeure partie et de ne conserver que les tokens importants. Nous avons testé cette approche sur un GPU accessible gratuitement en posant deux questions rarement étudiées ensemble : le modèle retrouve-t-il encore les informations nécessaires ? Et la mémoire est-elle réellement libérée ?

Réponse courte : à 25 % et 12,5 % du cache, chaque méthode testée a perdu les faits nécessaires presque à chaque fois.

Le modèle était Qwen3-4B-Instruct sur un T4 Kaggle gratuit. La tâche était synthétique : plusieurs fiches projets (« Project X has status S and codeword C ») cachées parmi des documents sans rapport, puis une question sur un, deux ou les trois. Les réponses étaient notées par correspondance exacte du mot de code. Les prompts faisaient 8k, 16k et 32k tokens, 6 cas chacun. L'exécution a été arrêtée à une limite de temps convenue, donc le niveau 32k compte 3 cas sur 6. Il reste 255 résultats enregistrés sur 306 prévus. Chaque politique et budget ci-dessous compte 15 questions.

Nous avons comparé six façons de choisir quoi garder : aucune éviction, une fenêtre glissante, des tokens aléatoires, un score key-norm et nos propres réimplémentations des idées de scoring SnapKV et H2O. Chacune a été exécutée au niveau token et au niveau page (blocs de 16 tokens).

Source : résultats enregistrés de l'exécution, 255 enregistrements. Le budget de 12,5 % est pire : 0 ou 1 bonne réponse sur 15 pour chaque méthode.

Avec le cache complet, le modèle a répondu 15 sur 15. Avec un quart, les meilleures méthodes ont obtenu 2 sur 15. La mauvaise réponse typique gardait le nom du projet mais inventait les chiffres, par exemple « cobalt-381 » au lieu de « cobalt-2609 ». Notre lecture : le scoring garde le sens d'un token et abandonne le nombre rare qui porte la réponse. C'est une hypothèse issue de ces exécutions, pas un mécanisme testé.

Les serveurs d'inférence stockent le cache en pages de 16 tokens. Une page ne peut être réutilisée que lorsque ses 16 tokens ont disparu. Si l'on supprime des tokens dispersés, on libère bien moins qu'on ne le pense. Nous avons simulé cette comptabilité sur les mêmes exécutions. Les méthodes alignées sur les pages libèrent presque tout, mais elles ont aussi perdu la réponse. Les méthodes qui gardaient un peu de précision libéraient beaucoup moins.

Source : comptabilité simulée des pages en blocs de 16 sur les exécutions enregistrées (moyenne de 30 cas par méthode). Pas une mesure sur un vrai serveur paginé. Chaque méthode fondée sur un score a logiquement retiré environ 1962 Mo par question, donc 320 Mo libérés représentent 16 % de cela. La méthode fenêtre a logiquement retiré 2376 Mo par question, dont 2373 Mo sont devenues des pages entières (la valeur tracée). Pourquoi elle retire plus que les autres méthodes n'a pas été vérifié ; à comparer avec prudence.

Un résultat de plus. Dans le cache statique Hugging Face que nous avons utilisé, le décodage n'a pas accéléré après l'éviction (environ 1510 à 1640 ms par token). Cela indique que la bibliothèque applique toujours l'attention sur toute la largeur. Cela ne dit pas qu'un serveur paginé se comporterait pareil.

• Un modèle ouvert de 4B sur un T4 gratuit. Cela ne dit rien des modèles de pointe.
• SnapKV et H2O sont ici nos réimplémentations, sans comparaison avec les chiffres publiés.
• Les pages libérées sont simulées. Seule l'allocation du cache a été mesurée sur le GPU.
• Le niveau 32k est à moitié terminé. Tous les cas 32k terminés ont aussi échoué.
• Une seule charge de travail artificielle. Les tâches réelles pourraient être moins sensibles à ces pertes.

Ces résultats soulèvent une question qui mérite une évaluation rigoureuse : une méthode devrait sélectionner des pages entières tout en conservant les nombres et les noms. Nous n'avons pas encore construit une telle méthode.