Un KV cache (cache clé-valeur) est le tampon qu'un transformer conserve, pendant une seule requête, des « clés » et « valeurs » d'attention qu'il a déjà calculées pour chaque token du contexte jusqu'ici. Quand le modèle génère le token suivant, il ne recalcule pas l'attention sur tout le prompt depuis zéro — il réutilise ces clés et valeurs stockées et ne calcule que les nouvelles. C'est toute l'astuce qui rend la génération autorégressive traitable au lieu d'être quadratiquement pénible.Je trouve que c'est l'élément des rouages internes des LLM que les gens facturés au token confondent le plus souvent avec le prompt caching. Ils sont liés mais ne sont pas la même chose, et la distinction compte dès que vous payez de l'argent réel.
Pourquoi le KV cache compte en 2026
Il compte parce que le KV cache est l'endroit où votre context window vit physiquement au moment de l'inférence, et il croît linéairement avec le nombre de tokens en circulation. Chaque token que vous gardez en contexte est une ligne dans ce cache occupant de la mémoire GPU pendant toute la durée du tour. Une longue session agentic avec un gros system prompt, une pile de définitions de tools, et trois fichiers que l'agent a relus pour rien n'est pas seulement coûteuse sur la facture — c'est un morceau de HBM que le fournisseur doit garder ouvert pour vous, et ce coût vous est répercuté.C'est aussi le mécanisme qui rend le prompt caching possible au niveau de l'API. Quand un fournisseur vous laisse réutiliser un préfixe stable, ce qu'il fait réellement, c'est persister le KV cache de ce préfixe d'une requête à l'autre pour ne pas avoir à le « prefill » de nouveau. C'est pourquoi les cache reads sont facturés à environ 10 % du tarif input plutôt que gratuitement : les clés et valeurs doivent toujours être chargées et attendues, elles n'ont simplement pas à être recalculées. Sur Claude Opus 4.8, cela transforme un préfixe input à $5/MTok en environ $0.50/MTok lors d'un hit — cela vaut la peine de structurer votre contexte pour le mériter.L'enseignement pratique est le même que celui sur lequel je reviens sans cesse : le token le moins cher est celui que vous ne mettez jamais dans le cache. Élaguer ce que l'agent lit — via la semantic code search plutôt que des dumps de fichiers entiers, et l'output filtering sur les logs de commandes bruyants — réduit le KV cache, la facture et la latence en même temps. C'est le levier que Tokenade actionne automatiquement, et vous pouvez voir les tokens économisés s'accumuler sur le dashboard.
Quand le KV cache est la mauvaise chose à optimiser
Quand le vrai problème est trop de contexte, pas le caching. Si votre agent est lent et coûteux parce qu'il charge tout à chaque tour, aucune stratégie de caching ne vous sauve — il faut mettre moins de choses dans la window. Corrigez d'abord l'input ; voir context engineering.
Pour les appels one-shot sans préfixe partagé. Une seule requête isolée construit son KV cache, l'utilise une fois, puis le jette. Il n'y a rien à réutiliser et rien à régler ; le cache n'est qu'un détail d'implémentation que vous ne sentirez jamais.
Quand vous le géreriez à la main vous-même. À moins de faire tourner votre propre stack d'inférence, vous ne contrôlez pas le KV cache directement — vous l'influencez par ce que vous envoyez. Misez sur le prompt caching et un contexte plus petit, pas sur des boutons que l'API n'expose pas.