🤖 machine learning

Cache-Aware Prompt Compression:A Two-Tier Cost Model for LLM API Caching

Ce document introduit la compression de prompts sensible au cache (CAPC), une stratégie qui combine la compression agnostique à la requête avec un contrôle explicite du cache et des limites de préservation de paliers pour surmonter les limites des méthodes dépendantes de la requête, atteignant des réductions de coûts significatives (jusqu'à 90 %) tout en maintenant la qualité à travers divers flux de travail de LLM en production.

Auteurs originaux : Yan Song

Publié 2026-07-20

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Yan Song

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous dirigez une bibliothèque massive et ultra-intelligente où un bibliothécaire très coûteux (une IA) vous aide à trouver des réponses. Pour économiser de l'argent, la bibliothèque utilise deux astuces spéciales. Premièrement, il y a un « Salon VIP » (le cache) : si vous interrogez le bibliothécaire sur le même chapitre de livre encore et encore, il n'a pas besoin de relire tout le chapitre dans les rayons de la bibliothèque ; il lui suffit de jeter un coup d'œil à ses notes, ce qui est beaucoup moins cher. Deuxيèmement, il y a un « Résumeur » (la compression) : au lieu de donner au bibliothécaire un roman de 500 pages, vous lui donnez un résumé de 50 pages, ce qui est également moins cher à traiter.

Pendant longtemps, on a pensé que ces deux astuces devaient être utilisées séparément. Soit vous utilisiez le Salon VIP pour les gros livres ennuyeux, soit vous utilisiez le Résumeur pour les questions courtes et complexes. Mais voici le hic : le Résumeur modifie généralement l'histoire légèrement à chaque nouvelle question pour qu'elle s'adapte mieux. Le problème est que le Salon VIP est un adepte du respect strict des règles. Si l'histoire change ne serait-ce qu'un tout petit peu, le bibliothécaire dit : « Désolé, c'est un nouveau livre ! » et jette ses notes, vous obligeant à payer le prix fort pour tout relire. Cette étude pose une question simple : pouvons-nous utiliser les deux astuces en même temps sans briser les règles ?

Les chercheurs de PayPal ont décidé de tester cela sur un système d'IA réel appelé Sonnet 4.6. Ils ont découvert que le Salon VIP n'est pas aussi parfait que tout le monde le pensait. Il possède une « zone chaude » pour les notes courtes et une « zone persistante » pour les longues, et si vous devenez trop astucieux avec vos résumés, vous expulsez accidentellement vos notes de la zone chaude coûteuse. Ils ont découvert que l'ancienne méthode — changer le résumé pour chaque question — gaspille en réalité de l'argent car elle empêche le bibliothécaire d'utiliser les notes bon marché.

Pour corriger cela, ils ont inventé une nouvelle stratégie appelée CAPC (Compression de Prompt Sensible au Cache). Voyez cela comme ceci : au lieu de réécrire l'histoire pour chaque question, ils créent un résumé compressé parfait des parties ennuyeuses une seule fois et le verrouillent dans le Salon VIP. Ensuite, pour chaque nouvelle question, ils ajoutent simplement la question spécifique à ce résumé verrouillé sans modifier le résumé lui-même. C'est comme avoir un script pré-écrit qui ne change jamais, afin que le bibliothécaire puisse réutiliser ses notes bon marché à chaque fois.

Les résultats ont été surprenants. Lors de tests sur 16 types différents de documents, cette nouvelle méthode a été l'option la moins chère à chaque fois, économisant environ 49 % par rapport à l'utilisation du seul Salon VIP et 64 % par rapport à l'ancienne méthode de « changement de résumé ». Ils l'ont également testée sur des tâches réelles, comme un robot utilisant des outils pour réparer du code informatique et un système qui parcourt d'immenses graphes de connaissances. Dans un cas, ils ont économisé plus de 50 % sur les coûts sans perdre en qualité. Dans un autre, ils ont prouvé que l'ancienne méthode de « changement de résumé » coûtait en fait 40 % de plus que de ne rien faire du tout car elle cassait systématiquement le cache. L'article conclut qu'en étant intelligent sur le quand compresser et le quoi mettre en cache, nous pouvons rendre l'IA beaucoup moins chère à utiliser sans la rendre moins intelligente.

Résumé technique : Compression de prompt sensible au cache (CAPC)

Énoncé du problème

Les déploiements modernes de Grands Modèles de Langage (LLM) reposent de plus en plus sur deux primitives distinctes de réduction des coûts : la mise en cache de prompts (stockage des états KV d'un préfixe pour facturer des tarifs réduits lors des lectures ultérieures) et la compression de prompts (réduction du nombre de tokens de l'entrée). Historiquement, ces techniques ont été traitées comme des optimisations séparées. Cependant, la littérature dominante sur la compression de prompts repose sur des méthodes sensibles à la requête (query-aware), qui génèrent un préfixe compressé unique pour chaque requête spécifique.

Ce choix de conception crée un conflit fondamental avec les mécanismes de mise en cache stricts sur préfixe (par exemple, le cache_control d'Anthropic). Parce que le préfixe compressé change à chaque requête, la clé du cache est invalidée à chaque appel. Par conséquent, le système paie le tarif complet de l'entrée non mise en cache pour chaque requête, annulant ainsi les économies réalisées grâce à la fois la compression et la mise en cache. Bien que la littérature existante suppose souvent un taux de réussite de cache idéal ( $\rho = 1,0$ ), cette hypothèse ne tient pas compte de la réalité économique des API du monde réel, où le comportement du cache est non trivial et où la compression sensible à la requête peut entraîner un retour sur investissement (ROI) net négatif.

Méthodologie et caractérisation empirique

Les auteurs abordent cette lacune par une combinaison de mesures empiriques, de modélisation des coûts et de conception algorithmique.

1. Caractérisation empirique de Anthropic Sonnet 4.6

Le papier caractérise d'abord le comportement de mise en cache de l'API Anthropic Sonnet 4.6 via des expériences contrôlées ( $n=3$ essais, coût total 1,91 $). Les conclusions clés incluent :

Architecture à deux niveaux : Le cache n'est pas uniforme. Il présente un seuil marqué près de 3 500 tokens.
- Niveau chaud (Hot Tier < 3,5k tokens) : Le taux de réussite ( $\rho$ ) plafonne à environ 0,83 (spécifiquement 0,833 pour 2k tokens) même après 30 appels. Il n'est pas de 1,0.
- Niveau persistant (Persistent Tier > 3,5k tokens) : Le taux de réussite est effectivement de 1,0 à partir du deuxième appel.
Invalidation stricte par token : L'invalidation du cache est stricte par rapport à la séquence de tokens. Même des mutations mineures (ex: un changement d'un seul caractère) entraînent un échec de cache (cache miss), bien que les espaces blancs de tête ou de queue soient normalisés par le tokenizer.
Structure de prix : L'API facture une prime pour les écritures de cache ( $c_w$ ) par rapport aux entrées non mises en cache ( $p_{in}$ ), et une réduction significative pour les lectures de cache ( $c_r$ ). Sur Sonnet 4.6, $c_w \approx 1,25 \times p_{in}$ et $c_r \approx 0,10 \times p_{in}$ .

2. Modélisation des coûts et analyse de croisement

Les auteurs dérivent un modèle de coût par appel pour quatre stratégies :

A (Vanilla) : Pas de cache, pas de compression.
B (Cache-only) : Préfixe complet mis en cache, pas de compression.
C (Query-aware Compression) : Compressé par requête, pas de cache (échec de cache à chaque fois).
D (CAPC) : Compression agnostique à la requête + mise en cache.

Le modèle définit un seuil de croisement ( $\rho_{cross}$ ) où le coût de la mise en cache (Stratégie B) est égal au coût de la compression sensible à la requête (Stratégie C) :
$\rho_{cross}(r) = \frac{c_w - p_{in}/r}{c_w - c_r}$
L'analyse révèle que pour des ratios de compression élevés ( $r \ge 6$ ), le taux de réussite requis pour que la mise en cache soit plus rentable que la compression sensible à la requête dépasse le plateau empirique du niveau chaud de Sonnet 4.6 ( $\rho \approx 0,89$ ). Ainsi, dans des conditions réalistes, la compression sensible à la requête est souvent moins chère que la mise en cache naïve, contredisant la sagesse conventionnelle.

3. L'algorithme CAPC

La solution proposée, la Compression de Prompt Sensible au Cache (CAPC), combine trois composants :

Compression agnostique à la requête : Un document statique est compressé une seule fois (ex: via la sélection de phrases) en un préfixe fixe $D'$ , garantissant que la clé du cache reste constante entre les requêtes.
Limite de ratio préservant le niveau (Tier-Preserving Ratio Bound) : Pour éviter qu'une sur-compression ne pousse le préfixe dans le "niveau chaud" (où $\rho < 1$ ), le ratio de compression $r$ est borné par $r_{max} = \lfloor |D| / 3500 \rfloor$ . Cela garantit que le préfixe compressé reste dans le niveau persistant ( $\rho \approx 1,0$ ).
AdaptiveCacheBoundary : Pour les documents évolutifs, une sous-routine classifie les positions de phrases comme STATIC, QUASI ou DYNAMIC en fonction des taux de mutation à travers les versions, ne mettant en cache que le préfixe stable.

Résultats clés

1. Benchmarks synthétiques LongBench-v2

Sur 16 configurations (4 tailles de documents $\times$ 4 ratios), CAPC a été la stratégie la moins chère dans 16/16 cas.

Économies : Économies moyennes de 49 % par rapport au cache seul, 64 % par rapport à la compression sensible à la requête, et 90 % par rapport au mode vanilla.
Qualité : CAPC a maintenu une qualité proche de la ligne de base non compressée (à 0,05 près) aux ratios préservant le niveau.
Validation du croisement : À $r=6$ , la compression sensible à la requête était moins chère que le cache seul dans 4/4 configurations, validant la prédiction du modèle de croisement.

2. Validation en production : Assistant d'entreprise utilisant des outils

Validé sur un préfixe statique de 94k tokens (prompt système + 287 définitions d'outils MCP).

Réduction des coûts : CAPC à $r=3$ a obtenu une réduction de coût de 51,7 % par rapport au mode vanilla.
Qualité : La qualité de sélection d'outils correspond à celle du cache seul (0,700 contre 0,703).
Insight : La compression sensible à la requête à $r=3$ a en fait moins bien performé (0,603) sur la sélection d'outils car elle écartait des définitions d'outils pertinentes pour la requête. L'approche agnostique de CAPC a préservé le catalogue complet, prouvant sa supériorité pour les agents augmentés par des outils.
Mise en cache implicite : L'étude a révélé qu'Anthropic met en cache implicitement les tableaux tools= volumineux même sans marqueurs explicites, réduisant le bénéfice marginal de la mise en cache explicite pour les stratégies vanilla, mais ne l'annulant pas pour les gains de compression de CAPC.

3. RAG par graphe de connaissances (Graphify)

Intégré avec graphify pour l'indexation de code source (dépôts FastAPI et httpx).

Architecture : La Couche 1 (mise en cache, agnostique à la requête) contient les métadonnées du graphe ; la Couche 2 (par requête) récupère le code source.
Performance : CAPC a délivré une réduction de coût de 9,3x sur FastAPI et de 2,4x sur httpx par rapport au mode "cache-all" (squelette complet du graphe), tout en maintenant des taux de réussite de cache stables de plus de 85 %.
Qualité : CAPC a surpassé les requêtes natives de graphify et les lignes de base de RAG par embedding, particulièrement sur les bases de code où le modèle avait des connaissances préalables plus faibles (httpx), délivrant une amélioration de qualité de 142 % par rapport au mode vanilla.

4. Benchmark public : $\tau$ -Bench Retail

Évalué sur 50 tâches déterministes avec récompenses basées sur l'état de la base de données (pas de juge LLM).

Résultat : CAPC était la stratégie la moins chère, économisant 7,9 % par rapport au mode vanilla tout en atteignant exactement le même taux de complétion de tâche (36/50) que le mode vanilla ( $z=0,00, p=1,00$ ).
ROI négatif du Query-Aware : La compression sensible à la requête était 40,1 % plus coûteuse que le mode vanilla, fournissant la première confirmation en production que les méthodes sensibles à la requête peuvent avoir un ROI négatif sur les benchmarks publics.

Signification et revendications

Le papier affirme fournir la première caractérisation systématique de l'économie de la mise en cache de prompts, allant au-delà de l'hypothèse idéalisée de $\rho=1,0$ . Ses principales contributions sont :

Réalité empirique : Démontrer que les caches de LLM possèdent une architecture à deux niveaux avec un plateau de taux de réussite non trivial en dessous d'un certain seuil de tokens.
Inversion théorique : Prouver qu'à des ratios de compression élevés, la compression sensible à la requête est souvent moins chère que la mise en cache naïve, inversant la hiérarchie de conception conventionnelle.
Algorithme pratique : Introduire CAPC, qui unifie la compression agnostique à la requête avec la mise en cache explicite et une contrainte de préservation de niveau.
Validation en production : Valider ces découvertes à travers des benchmarks synthétiques, des agents d'utilisation d'outils en entreprise, des pipelines RAG de graphes de connaissances et des benchmarks publics déterministes.

Les auteurs soulignent que CAPC n'est pas un remplacement pour les indexeurs (comme graphify) mais une couche complémentaire de "livraison du dernier kilomètre" qui optimise le coût économique de la livraison du contexte dérivé de l'index vers un LLM. Le coût total de tous les travaux empiriques de ce papier a été de 98,96 $, démontant que ces conclusions sont reproductibles avec des ressources modestes.