Aller au contenu

Prompt Caching KV Cache + RAG vs CAG — deep dive technique

Resume

Deux articles techniques lies de @_avichawla (708K + 486K vues) couvrant le prompt caching en profondeur.

Article 1 : Prompt caching, clearly explained

Etude de cas sur Claude Code : 92% cache hit rate, 81% reduction de cout sur une session de 30 minutes.

Mecanisme du KV Cache : - Pendant le prefill (traitement du prompt entier), le transformer calcule des vecteurs Query, Key, Value pour chaque token - Les tenseurs Key/Value ne dependent que des tokens precedents et ne changent jamais une fois calcules - Sans cache : ces tenseurs sont recalcules a chaque requete. Avec cache : persistes sur les serveurs d'inference, indexes par hash cryptographique de la sequence de tokens - Reduction de complexite : O(n²) → O(n) par token genere

Economie : - Cache reads : 0.1x le prix de base (90% de reduction) - Cache writes : 1.25x (25% de premium) - Extended 1h caching : 2.0x

Session Claude Code type (30 min) : - Minute 0 : chargement system prompt + tools + CLAUDE.md (~20K tokens) — le plus cher - Minutes 1-25 : le prefix est lu depuis le cache a $0.30/MTok au lieu de $3.00/MTok - Resultat : 2M tokens traites, 1.84M en cache reads → $1.15 au lieu de $6.00

Article 2 : RAG vs CAG

Cache-Augmented Generation (CAG) : pour les donnees statiques (policies, definitions, reference docs), pre-charger dans le KV cache au lieu de requeter un vector DB a chaque query. Le vector DB reste pour les donnees dynamiques.

Distinction cold/hot data : - Hot (change rarement) : policies, definitions, frameworks → CAG (pre-charge dans le cache) - Cold (change souvent) : tickets, conversations, logs → RAG (vector DB)

Analyse critique

Le meilleur article technique que j'ai vu sur le prompt caching. Rarement les details d'implementation du KV cache sont expliques aussi clairement.

Les 3 regles de fragilite du cache sont critiques :

  1. Ne pas modifier les tools mid-session : les definitions de tools font partie du prefix cache — ajouter/supprimer un tool invalide tout le downstream
  2. Ne jamais switcher de modele mid-session : les caches sont model-specific, switcher = recalculer le cache entier
  3. Ne jamais muter le prefix pour mettre a jour l'etat : au lieu d'editer le system prompt, appender un reminder tag au prochain message user

Le point contre-intuitif : "1 + 2 = 3" est un cache hit mais "2 + 1 = 3" est un miss. Le hash est sur la sequence entiere depuis le debut — meme l'ordre de 2 elements suffit a invalider.

Exemples de casse de cache en prod : - Un timestamp dans le system prompt → hash unique a chaque requete - Un serialiseur JSON qui trie les cles differemment entre requetes - Un AgentTool dont les parametres sont mis a jour mid-session

Le concept CAG est pertinent : pour les reviews de gate, les specs/plans/contracts sont des donnees "hot" (ne changent pas pendant la gate). Les pre-charger dans le cache au lieu de les reinjecter a chaque iteration est exactement l'architecture cache-first documentee dans CLAUDE.md.

Monitoring recommande : 3 champs dans la reponse API Anthropic : - cache_creation_input_tokens — tokens ecrits dans le cache - cache_read_input_tokens — tokens lus depuis le cache - input_tokens — tokens traites sans cache - Efficacite = cache_read / (cache_read + cache_creation)

Pertinence ProbatioVault

Validation technique directe de l'architecture cache-first documentee dans CLAUDE.md :

Ce qu'on fait deja bien : - Step 6b : spec + plan + contracts en prefix (cache entre agents sequentiels) - Gates iteratives : template de review + documents d'entree en prefix (cache entre v1/v2/v3) - System prompt byte-identical entre appels d'une meme phase - Sections du bloc partage jamais reordonnees

Ce qu'on pourrait ameliorer : - Monitorer les 3 champs API response pour mesurer le taux de hit reel (cf. fiche caching dashboard du meme jour) - Verifier que le TTL de 5 min est respecte entre agents sequentiels step 6b — si un agent prend plus de 5 min, le cache du prefix est invalide pour le suivant - Appliquer le concept CAG : les specs/plans/contracts pourraient etre pre-charges dans un cache long (1h, 2.0x) pour toute la duree de la story, plutot que recrees a chaque etape

Synergie avec la fiche caching dashboard : le dashboard dans la Developer Console permettrait de verifier si les optimisations ci-dessus ont un impact mesurable.