Prompt caching chez OpenAI, Anthropic et Gemini : architecture et choix

Le prompt caching réutilise le calcul pour un début de requête identique : instructions système, tool schemas, exemples few-shot ou grand contexte partagé. Ce n’est pas un semantic cache de réponses terminées. Le modèle génère toujours un nouveau résultat pour la partie variable ; le cache ne doit donc pas remplacer les contrôles de qualité, de fraîcheur ou d’autorisation.

Une architecture utile comporte trois zones : un préfixe partagé durable, un contexte d’équipe ou de tenant versionné et une queue dynamique avec la requête utilisateur et les données fraîches. Placez le stable avant le variable. Un timestamp, un ID aléatoire, un ordre instable de champs JSON ou des données personnelles au début peuvent casser le match et transformer les économies attendues en cache writes répétés.

• Ne mettre en cache qu’un préfixe réutilisable suffisamment grand pour les règles du modèle choisi.
• Versionner instructions, tools, schemas et révisions du corpus plutôt que les modifier silencieusement.
• Mesurer reads, writes, misses, uncached input, latence et qualité séparément.
• Ne pas mélanger tenants ou niveaux d’accès pour améliorer le hit rate.
• Vérifier les règles actuelles de modèle, région, rétention et pricing avant le rollout.

OpenAI documente le caching automatique des préfixes exacts éligibles et expose la télémétrie des cached tokens ; les modèles récents proposent aussi cache keys, points de cache et contrôle de mode. Anthropic prend en charge l’automatic caching global et des cache breakpoints explicites via cache_control, avec comptage séparé des tokens de création et de lecture. Gemini propose un implicit caching et, dans l’API Generate Content compatible, un cached content explicite avec TTL géré ; la disponibilité dépend de l’API et du modèle.

Ne masquez pas ces différences derrière un indicateur générique cache=true. Un provider adapter doit décrire les capabilities : mode implicite ou explicite, préfixe minimal, breakpoints autorisés, TTL, billing write/read, télémétrie, région et contraintes de rétention. Si une capability est inconnue, exécutez une requête normale et marquez le statut comme unsupported ou unknown au lieu d’inventer un hit.

Assemblez la requête de façon déterministe : policy et instructions système immuables, tool definitions triées de façon stable, schemas, exemples validés, puis documents partagés et seulement ensuite input propre à l’utilisateur. La sérialisation doit rester byte-stable dans le contrat du provider. Même un JSON sémantiquement identique avec un ordre de champs différent peut ne pas correspondre au préfixe exact.

Dérivez la cache identity du provider, model family, prompt version, tool-schema version, policy version, locale, tenant ou access scope et corpus revision. Ne placez pas de texte secret dans les logs ou cache keys ; utilisez un digest opaque d’identifiants contrôlés. Un changement de modèle, de permissions, de system policy ou d’une source à révoquer immédiatement crée une nouvelle version ; l’ancien trafic de cache s’arrête et l’objet expire ou est supprimé via une API disponible.

Modélisez un cohort logique : cache-write tokens et storage, cache-read tokens, uncached input, output, nombre de réutilisations, time to first token et cost per successful task. Le break-even dépend des tarifs précis du modèle, du TTL et du nombre de réutilisations observé. Ne transposez pas le pourcentage de remise d’un provider ou modèle à un autre contrat et ne supposez pas un hit simplement parce que le texte semble identique.

Un hit rate faible indique souvent une mauvaise forme de workload plutôt qu’un service insuffisant : prompts courts, répétitions rares, cache keys fragmentées, changements fréquents près du préfixe ou burst parallèle avant la fin du premier write. Comparez des variantes contrôlées sur le même traffic slice. Si la canonicalization ajoute plus de complexité, de write spend ou de délai de revocation qu’elle n’économise, une requête normale sans cache est préférable.

Le cache reuse n’autorise pas à affaiblir l’authorization. Un préfixe partagé ne peut contenir que des données autorisées pour toutes les requêtes de son scope. Documents propres au tenant, données personnelles et résultats de tools avec ACL différentes exigent des identities séparées ou doivent rester après la frontière sûre. Un cache key est un indice de routing ou un identifiant de ressource, pas un mécanisme d’autorisation ; le serveur doit toujours autoriser la requête et construire le contexte permis.

Le caching explicite peut créer un état applicatif persistant pendant le TTL. Vérifiez data residency, compatibilité zero-data-retention, chiffrement, suppression et incident response dans la documentation et les contrats actuels. Pour legal hold ou revocation urgente, documentez le chemin : arrêter les nouveaux reads, changer version ou scope, supprimer le cache object si possible et vérifier que les traces suivantes n’utilisent plus la révision retirée.

Une trace doit enregistrer provider, model, cache mode, fingerprint sûr du préfixe, version, breakpoint, TTL demandé, nombres de tokens read/write/uncached, latence, outcome et miss reason sans stocker le prompt privé brut. Normalisez les champs provider en catégories communes, mais conservez le usage payload original dans une couche d’audit protégée pour vérifier la sémantique de billing.

Le dashboard doit montrer requêtes éligibles, hit rate parmi les requêtes éligibles, part de cached tokens, write amplification, cost per accepted outcome et latence des hits et misses. Alertez sur une chute brutale après deploy, un cross-scope fingerprint inattendu, des writes sans reads ultérieurs ou l’utilisation d’une version retirée. Le hit rate seul n’est pas un KPI de qualité : un system prompt inchangé mais faux se met lui aussi parfaitement en cache.

Mesurez d’abord la répétition des préfixes sans modifier le comportement. Activez ensuite canonical rendering et comparez les fingerprints exacts, tout en excluant les cohorts sensibles du cache. Le canary doit couvrir un provider/model et un workload à faible risque ; un quality eval doit confirmer que la réorganisation des blocs n’a modifié ni instruction precedence, ni comportement des tools, ni groundedness.

Le release gate doit exiger zéro défaut cross-tenant, une usage attribution correcte, une write amplification acceptable et aucune régression de task quality. Le rollback désactive breakpoints explicites ou références aux cache resources, restaure le renderer précédent et reroute le trafic vers des requêtes normales. Les anciens cache objects ne sont pas considérés supprimés sans provider evidence ; leur expiry ou deletion est suivi séparément du rollback applicatif.