890 octets par token : comprendre la compression du KV Cache de DeepSeek
Le coût des longs contextes bute souvent sur la mémoire, pas sur les poids. DeepSeek V4.1 Flash ramène le KV Cache à environ 890 octets par token. Le besoin en HBM tombe au quart et celui en SSD au huitième par rapport à la génération précédente.

Quand un modèle traite un long document, il doit conserver la Key et la Value de l'attention pour chaque token du contexte. Ce résultat intermédiaire, c'est le KV Cache. Il grandit linéairement avec la longueur du contexte et détermine combien de longues sessions une carte peut faire tourner en parallèle. Voilà pourquoi le coût des longs contextes bute souvent sur la mémoire et non sur les poids.
Pour mesurer la place que prend le KV Cache, on peut poser le calcul sur un modèle public. Avec la configuration publique de Qwen3-8B, en BF16 ou FP16 et 2 octets par valeur, chaque token demande 147456 octets de données KV, soit environ 147 Ko. Le calcul : 2 jeux K/V fois 36 couches, fois 8 têtes KV, fois 128 dimensions par tête, fois 2 octets. Les surcoûts de gestion du cache ne sont pas comptés.
Sur le V4.1 Flash, DeepSeek compresse. La comparaison officielle : face à la génération précédente, le besoin en HBM tombe au quart et le besoin en SSD au huitième. Face au modèle initial, le KV Cache a déjà été réduit de 437 fois. En croisant les descriptions officielles et d'autres sources, le KV Cache du V4.1 Flash tourne autour de 890 octets par token.
Pourquoi s'attacher à ce chiffre ? Parce que le coût des hits de cache pèse lourd dans les tâches de type agent. Une tâche d'agent de codage relit sans cesse du code, consulte des ressources, lance des tests, et l'historique s'accumule. Quand la mémoire vidéo ne suffit plus, le système efface une partie du cache. Au tour suivant, il faut refaire le Prefill, et l'attente du premier token s'allonge.
La sortie technique passe par la hiérarchisation. Les données en cours de génération restent en HBM. Celles qui peuvent resservir à court terme vont dans la DDR côté CPU. Celles qui n'ont pas été lues depuis longtemps descendent vers le SSD ou le stockage distant. Le KV Offloading de vLLM permet ainsi de décharger des blocs de cache vers la mémoire CPU, avec un niveau de stockage secondaire configurable, la récupération passant par la couche de cache côté CPU.
890 octets n'est donc pas qu'un nombre. Cela signifie que la même mémoire vidéo supporte plus de longues sessions simultanées, et que les équipes qui hébergent leur propre service d'inférence achètent moins de cartes. Pour les achats et l'exploitation, la taille du KV Cache compte désormais autant que les performances du modèle, et mérite une ligne dans la grille de sélection.
Sources
3Tous les chiffres et citations de ce texte proviennent des sources citées ci-dessous.
Les contenus ont été préparés par l'équipe de rédaction, assistée par l'IA.
Commentaires
0- Aucun commentaire — soyez le premier.