Vous activez le cache de prompt en attendant que la facture baisse et que la latence diminue, et la plupart du temps c’est ce qui se produit. Mais la première étude contrôlée multi-fournisseurs du cache sur des tâches d’agent à long horizon a trouvé un cas que le discours commercial passe sous silence : le cache naïf du contexte complet peut rendre une requête plus lente, pas plus rapide 1. Le cache n’est pas un interrupteur que l’on bascule une fois ; c’est une décision d’architecture de prompt, et la variable qui décide du signe du gain est la part de votre prompt qui reste identique octet pour octet d’un tour à l’autre.
Où se trouve réellement l’économie
Le gain vient entièrement du préremplissage réutilisé. Quand le serveur détient déjà les tenseurs clé-valeur d’un préfixe calculé au tour précédent, il évite de les recalculer : un taux de succès du cache KV de 90 pour cent épargne 90 pour cent du travail de préremplissage et réduit le coût de calcul effectif par requête de 80 à 90 pour cent 2. Ce chiffre est le plafond de ce que le cache peut vous rapporter, et il dépend d’une seule chose : la longueur du préfixe identique au tour précédent. Le levier n’est pas l’interrupteur. C’est l’endroit où tombe la frontière du cache, car cette frontière se place au premier jeton qui a changé.
Le cas qui fait perdre
Voici la preuve par l’existence qui casse la croyance des gains monotones. La même étude rapporte un vrai bénéfice sous discipline, de 41 à 80 pour cent de coût en moins et de 13 à 31 pour cent de temps de réponse initial en moins, mais uniquement avec un contrôle stratégique des blocs de cache : placer le contenu dynamique à la fin du prompt système et tenir les résultats d’outils changeants hors du segment mis en cache 1. Le mécanisme est implacable. Placez tôt dans le contexte un résultat d’outil ou une définition de fonction qui change à chaque tour, et chaque tour déplace la frontière du cache vers l’avant ; vous recalculez le suffixe et payez la prime d’écriture de cache sans aucun bénéfice de lecture. Dans une boucle d’agent, où les sorties d’outils et l’état arrivent dans le contexte à chaque étape, la disposition par défaut est exactement celle qui casse le cache. Voilà le mode de défaillance : du contenu volatil intercalé dans le préfixe, qui l’invalide à chaque tour.
« Active-le, le fournisseur s’en charge »
L’objection honnête : les fournisseurs mettent de plus en plus en cache à votre place. OpenAI fait du cache de préfixe automatique, Gemini propose un cache implicite, et le guide de chaque fournisseur vous dit déjà de placer le contenu statique en tête. Si le conseil se résume à « mettez le volatil à la fin », c’est une bonne pratique documentée, pas une découverte. Deux choses y répondent. D’abord, la régression mesurée est la réfutation : si le cache ne pouvait qu’aider ou ne rien changer, une étude contrôlée ne le verrait pas augmenter la latence 1. La croyance sous laquelle opèrent la plupart des équipes, que la facture ne fait que baisser, est tout simplement fausse. Ensuite, le cache automatique ne sauve pas un prompt mal ordonné. Le cache de plateforme ne reconnaît que le plus long préfixe identique octet pour octet ; donc si votre contenu volatil est placé tôt, le cache implicite ne peut pas le dépasser, et en retirant le point de coupure explicite il vous laisse moins de contrôle sur l’emplacement de la frontière. L’automatisation croissante des fournisseurs rend donc l’ordre du prompt plus décisif, pas moins.