La mise en cache des prompts peut réduire le coût et la latence des requêtes LLM répétées, mais seulement lorsque le workflow produit des préfixes stables, suffisamment de réutilisation et un comportement de cache-hit acceptable. Activer la fonctionnalité n’est pas la même chose que démontrer un retour sur investissement.
Ce guide fournit aux équipes d’ingénierie et de FinOps un workflow pratique de mise en cache des prompts : identifier le trafic éligible, structurer les prompts pour la réutilisation, instrumenter les métriques de cache, calculer les économies nettes et déployer sans masquer les régressions de qualité ou de fiabilité.
Qu’est-ce que la mise en cache des prompts ?
La mise en cache des prompts permet à un fournisseur de LLM de réutiliser le calcul pour le contenu de prompt qu’il a récemment traité. Au lieu de facturer et de traiter chaque jeton d’entrée répété au tarif normal, le fournisseur peut appliquer un tarif d’entrée mis en cache inférieur ou un prix distinct de lecture du cache pour la partie réutilisable.
Le contenu réutilisable est généralement un préfixe de prompt stable. Exemples courants :
- Un long prompt système et un bloc de politique.
- Des définitions d’outils partagées par chaque tour d’agent.
- Un document volumineux, une carte du dépôt ou un catalogue de produits interrogé à plusieurs reprises.
- Des exemples few-shot réutilisés dans une tâche de classification ou d’extraction.
- Un historique de conversation partagé par plusieurs actions suivantes possibles.
Les implémentations des fournisseurs diffèrent. OpenAI documente la mise en cache automatique pour les préfixes de prompt éligibles et expose les détails des jetons mis en cache dans l’utilisation de l’API. Anthropic prend en charge des points de rupture de cache explicites et plusieurs options de durée de conservation (TTL). Google Gemini prend en charge des caches de contexte explicites avec des frais de stockage, tandis que DeepSeek documente une mise en cache automatique du contexte sur disque avec des tarifs distincts pour les entrées en cache-hit et en cache-miss. Vérifiez toujours la prise en charge actuelle des modèles et la tarification dans la documentation officielle du fournisseur avant d’intégrer les économies à une prévision.
L’erreur de ROI : mesurer la remise au lieu du workflow
Une remise sur les jetons mis en cache n’est pas la même chose que des économies nettes. Le workflow peut également engendrer des frais d’écriture en cache, des frais de stockage, des requêtes supplémentaires, une complexité opérationnelle ou des régressions de qualité lorsque les équipes optimisent la structure du prompt de manière trop agressive.
Mesurez l’unité qui compte :
ROI net de mise en cache des prompts = coût d’entrée évité non mis en cache - coût d’écriture/stockage du cache - coût d’implémentation et d’exploitation
Pour les décisions de production, reliez ce résultat à un résultat accepté :
Coût par tâche acceptée = coût total des requêtes / tâches réussies validées
Cela évite un résultat trompeur où les dépenses en jetons diminuent mais où les nouvelles tentatives, les sorties rejetées ou la revue humaine augmentent. Cela aligne également la mise en cache des prompts avec un programme plus large d’optimisation des coûts des API d’IA plutôt que de traiter la mise en cache comme une astuce de facturation isolée.
Un workflow de mise en cache des prompts en six étapes
1. Identifier les charges de travail avec une réutilisation réelle du préfixe
Commencez par les traces de requêtes, pas par l’intuition. Regroupez le trafic par workflow et estimez combien de jetons d’entrée restent identiques du début d’une requête à la suivante.
Les bons candidats ont généralement quatre propriétés :
- Grande entrée répétée : le préfixe réutilisable est important par rapport au suffixe dynamique.
- Réutilisation fréquente : plusieurs requêtes font référence au même préfixe au sein de la durée de vie effective du cache du fournisseur.
- Ordonnancement stable : les instructions système, les outils, les exemples et le matériel de référence apparaissent dans le même ordre.
- Faible cardinalité : l'application réutilise un nombre gérable de variantes de prompt plutôt que de créer un préfixe unique pour chaque utilisateur.
Les workflows à fort potentiel incluent les agents de codage avec des schémas d'outils stables, les assistants de support ancrés dans un ensemble de connaissances partagé, les sessions de questions-réponses sur des documents, l'extraction par lots avec des exemples répétés et les agents de recherche multi-tours.
Les mauvais candidats incluent les prompts ponctuels courts, les préfixes hautement personnalisés, les requêtes qui modifient les définitions d'outils à chaque appel et les tâches à faible volume qui réutilisent rarement une entrée de cache.
Établissez un tableau de référence pour chaque workflow :
| Métrique | Pourquoi c'est important |
|---|---|
| Requêtes par jour | Détermine le volume de réutilisation |
| Jetons d'entrée moyens | Établit le coût total d'entrée |
| Jetons du préfixe réutilisable | Définit la surface pouvant être mise en cache |
| Variantes de préfixe | Révèle la fragmentation |
| Intervalle de réutilisation | Teste si les entrées restent utiles |
| Taux de tâches acceptées | Protège la qualité et la valeur commerciale |
| Latence P50/P95 | Mesure l'impact sur les performances |
2. Placez le contenu statique avant le contenu dynamique
La mise en cache des prompts dépend généralement de la correspondance du prompt à partir de son début. Une petite différence au début peut empêcher la réutilisation de tout ce qui suit.
Utilisez cet ordre lorsque le fournisseur et le SDK le permettent :
1. Instructions système stables
2. Règles de politique et de sécurité stables
3. Définitions d'outils stables
4. Matériel de référence ou exemples stables
5. Contexte de conversation semi-stable
6. Entrée utilisateur dynamique et valeurs d'exécution
Ne placez pas des horodatages, des identifiants de requête, des libellés spécifiques à l'utilisateur, du JSON ordonné aléatoirement ou des indicateurs de fonctionnalités qui changent fréquemment près du début du prompt. Normalisez les schémas d'outils et sérialisez le contenu structuré de manière déterministe.
Cela ne vous autorise pas à combiner des données sans lien dans un préfixe surdimensionné. Préservez les frontières entre locataires, les règles d'autorisation et les exigences de conservation des données. Un prompt moins coûteux ne vaut pas un échec de confidentialité ou d'isolation.
3. Définissez une identité de cache et une politique d'invalidation
Votre application a besoin d'un moyen explicite de raisonner sur les versions de prompt, même lorsque le fournisseur gère automatiquement le cache.
Une identité de cache pratique peut inclure :
workflow + prompt_version + tool_schema_version + knowledge_version + model_family
Suivez cette identité dans la télémétrie. Lorsque les instructions, les contrats d'outils ou les données de référence changent, incrémentez la version correspondante. Cela rend les changements de coût explicables et évite que les équipes confondent une invalidation attendue avec une panne du fournisseur.
Définissez une fenêtre de réutilisation en fonction du comportement de la charge de travail et du support du fournisseur. Un agent interactif de courte durée peut bénéficier de quelques minutes de réutilisation. Un workflow de recherche récurrent peut justifier un cache explicite plus long si le coût de stockage reste inférieur à celui d’un traitement répété des entrées.
4. Instrumentez les hits, les misses, les écritures et les résultats acceptés
Au minimum, journalisez ces champs pour chaque tentative :
- Fournisseur, modèle et workflow.
- Version du prompt et identité du cache.
- Total des tokens d’entrée, lus/cachés, d’écriture du cache et de sortie lorsque ceux-ci sont exposés.
- Statut de hit de cache ou hit inféré.
- Coût estimé d’entrée, de cache, de sortie et total.
- Latence, statut, numéro de tentative et chemin de repli.
- Résultat validé de succès ou de tâche acceptée.
Utilisez les champs d’utilisation renvoyés par le fournisseur comme source de vérité de la facturation lorsqu’ils sont disponibles. Si un fournisseur ne renvoie pas un indicateur clair de cache hit, déduisez-le prudemment à partir des comptes de tokens mis en cache ou des relevés de facturation et indiquez la métrique comme inférée.
La télémétrie du prompt caching doit appartenir à la même trace que les retries et le fallback de modèle. Sinon, une tempête de retries peut ressembler à une optimisation de cache réussie. La checklist d’implémentation de l’observabilité IA montre comment relier le coût par tentative aux résultats de l’application.
5. Calculez les économies et le volume de rentabilité
Utilisez un modèle qui correspond à la structure tarifaire du fournisseur.
Pour la mise en cache automatique avec un tarif de lecture réduit :
gross_savings = cache_read_tokens × (uncached_input_rate - cached_input_rate)
net_savings = gross_savings - incremental_operating_cost
Pour la mise en cache explicite avec des frais d’écriture et de stockage :
net_savings = avoided_uncached_cost
- cache_write_cost
- cache_storage_cost
- incremental_operating_cost
Vous pouvez estimer le nombre de réutilisations à l’équilibre pour un préfixe mis en cache :
break_even_reuses =
(cache_write_cost + storage_cost + implementation_cost_per_entry)
/ savings_per_cache_read
Arrondissez au nombre entier supérieur de réutilisations. Ajoutez ensuite une marge pour les misses, les invalidations et la variabilité du trafic.
Exemple de ROI chiffré
Supposons qu’un workflow présente :
- 40 000 requêtes par mois.
- 18 000 tokens d’entrée par requête.
- Un préfixe stable de 12 000 tokens.
- Un taux effectif de cache hit de 70 %.
- Un tarif d’entrée sans cache de 3 $ par million de tokens.
- Un tarif d’entrée mis en cache de 0,30 $ par million de tokens.
- 350 $ par mois de coût d’ingénierie et de surveillance amorti.
Tokens mis en cache mensuels :
40,000 × 12,000 × 70% = 336,000,000 cached input tokens
Économies brutes :
336 million × ($3.00 - $0.30) / 1 million = $907.20
Économies mensuelles nettes :
$907.20 - $350 = $557.20
Si le workflow produit 32 000 tâches acceptées, le caching contribue à environ 0,017 $ d’économies par tâche acceptée. Cela peut être significatif à grande échelle, mais le résultat est bien plus modeste que de simplement annoncer une remise de 90 % sur les entrées mises en cache.
Les tarifs ci-dessus sont donnés à titre illustratif et ne correspondent pas à un devis actuel d’un fournisseur. Remplacez-les par vos tarifs contractuels ou publiés et incluez, le cas échéant, les écritures de cache, le stockage, la tarification régionale, les niveaux de service et les frais de passerelle.
6. Déployez avec une expérience contrôlée
Mettez en œuvre la mise en cache comme un changement d’ingénierie avec un groupe témoin mesurable.
- Sélectionnez un workflow à forte réutilisation.
- Figez l’ensemble d’évaluation et les critères d’acceptation.
- Établissez les bases de référence du coût, de la latence et de la qualité sans cache.
- Recomposez uniquement le préfixe stable.
- Envoyez une petite partie du trafic de production via le chemin mis en cache.
- Comparez le taux de réussite du cache, le coût par tâche acceptée, la latence P95, les erreurs et les solutions de repli.
- N’étendez le déploiement que lorsque les économies restent positives après prise en compte des coûts d’exploitation.
Conservez les politiques de nouvelle tentative et de repli séparées de la logique de cache. Une requête ayant échoué peut être sûre à retenter, dangereuse à rejouer après un streaming partiel, ou mieux servie par un modèle équivalent. Utilisez une stratégie de repli de modèle définie plutôt que de traiter chaque cache miss ou timeout comme une même défaillance.
Tableau de bord KPI de mise en cache des prompts
Suivez les métriques suivantes par workflow et par version de prompt :
| KPI | Formule ou définition | Signal de décision |
|---|---|---|
| Ratio de jetons pouvant être mis en cache | Jetons du préfixe réutilisable / jetons d’entrée totaux | La surface d’optimisation est-elle suffisamment grande ? |
| Taux de succès du cache | Requêtes de lecture du cache / requêtes éligibles | La réutilisation se produit-elle réellement ? |
| Ratio de jetons mis en cache | Jetons d’entrée mis en cache / jetons d’entrée totaux | Quelle part de l’entrée bénéficie du tarif inférieur ? |
| Économies par requête | Coût de référence sans cache - coût observé | Chaque requête est-elle moins chère ? |
| Économies nettes | Économies brutes - écritures, stockage et coût d’exploitation | Le projet est-il financièrement positif ? |
| Coût par tâche acceptée | Coût total / tâches acceptées | L’économie ajustée à la qualité s’est-elle améliorée ? |
| Delta de latence P95 | P95 mis en cache - P95 de référence | Les performances visibles par l’utilisateur se sont-elles améliorées ? |
| Taux de motif de non-succès | Échecs par version, ordre, TTL ou fournisseur | Que doit corriger l’équipe d’ingénierie ensuite ? |
Un taux de succès élevé avec de faibles économies peut se produire lorsque le préfixe répété est petit. Un faible taux de succès avec un grand préfixe peut néanmoins indiquer une opportunité intéressante si la fragmentation du prompt peut être corrigée. Lisez les métriques ensemble.
Modes d’échec courants de la mise en cache des prompts
Valeurs dynamiques au début
Les horodatages, les identifiants et les métadonnées par utilisateur proches du début fragmentent le cache. Déplacez-les après le préfixe stable lorsque c’est possible.
Les schémas d’outils changent entre les requêtes
Les agents reconstruisent ou réorganisent souvent les définitions d’outils de manière dynamique. Normalisez l’ordre, supprimez les outils non pertinents et versionnez le schéma de manière explicite.
Les entrées de cache sont écrites mais rarement réutilisées
La création explicite du cache peut coûter plus qu’elle ne rapporte lorsque le trafic est faible ou que le TTL est trop long. Mesurez la réutilisation par identité de cache avant de prolonger la rétention.
Les équipes optimisent les jetons mais ignorent les sorties
Les jetons de sortie, les nouvelles tentatives et la revue humaine peuvent dominer le coût total. Continuez à mesurer la requête complète et le résultat accepté.
Le comportement du fournisseur est supposé être portable
La mise en cache automatique des préfixes, les points de rupture explicites, la facturation du stockage, les longueurs minimales des prompts, les modèles éligibles et les champs d’utilisation varient selon le fournisseur. Construisez un adaptateur de fournisseur et conservez l’indicateur métier indépendant du fournisseur.
Le fallback détruit la localité du cache
Le changement de fournisseur ou de famille de modèles peut supprimer la réutilisation, car les caches ne sont pas portables. Cela ne signifie pas qu’il faut désactiver le fallback. Cela signifie que la fiabilité et le coût doivent partager une politique : effectuer un basculement lorsque nécessaire, puis attribuer correctement le cache manqué et le coût incrémental.
Liste de vérification de l’implémentation côté fournisseur
Avant d’activer la mise en cache des prompts pour un modèle, confirmez :
- La mise en cache est-elle automatique, explicite ou les deux ?
- Quels modèles et points de terminaison API la prennent en charge ?
- Quelle longueur minimale de prompt s’applique ?
- Comment une préfixe correspondante est-elle définie ?
- Quelles options de TTL ou de rétention existent ?
- Les écritures, les lectures et le stockage du cache sont-ils facturés séparément ?
- Quels champs de réponse exposent les jetons mis en cache ou la création du cache ?
- Les paramètres de niveau de service, de région, de résidence des données ou de rétention zéro modifient-ils le comportement ?
- Les caches sont-ils isolés par projet, compte, organisation ou une autre limite ?
- Que se passe-t-il lorsque la requête bascule vers un autre modèle ou fournisseur ?
Utilisez le guide de mise en cache des prompts OpenAI, la documentation de mise en cache des prompts Anthropic, le guide de mise en cache du contexte Google Gemini et le guide de mise en cache du contexte DeepSeek pour obtenir les détails d’implémentation actuels. Les tarifs et l’éligibilité des modèles peuvent changer, alors revérifiez ces sources à chaque examen important des coûts.
Où s’insère une passerelle IA
Une passerelle IA unifiée ne rend pas les caches des fournisseurs portables. Chaque fournisseur contrôle toujours sa propre sémantique de cache et sa propre facturation. Une passerelle peut toutefois offrir aux équipes un point unique pour normaliser les identifiants de modèles, acheminer les charges de travail éligibles, enregistrer l’utilisation spécifique au fournisseur, comparer le coût par tâche acceptée et appliquer des politiques de basculement ou de budget.
Flatkey fournit un point de terminaison compatible OpenAI et un solde unifié pour accéder à plusieurs familles de modèles. Cela facilite l’évaluation comparative des workflows avec et sans cache sans reconstruire chaque intégration. Confirmez la prise en charge actuelle du cache par le modèle sélectionné et le comportement du fournisseur avant de considérer une route comme activée pour le cache.
Si vous consolidez d’abord des clients existants, utilisez la liste de vérification de migration vers une passerelle API compatible OpenAI et consultez l’accès actuel aux modèles et la tarification de Flatkey.
Questions fréquemment posées
Combien la mise en cache des prompts peut-elle faire économiser ?
Les économies dépendent du préfixe réutilisable, du taux de cache hit, de la tarification du fournisseur, des frais d’écriture ou de stockage et du coût d’implémentation. Calculez les économies nettes à partir des jetons mis en cache observés plutôt que d’appliquer la remise affichée à tous les jetons d’entrée.
Quel taux de cache hit est bon ?
Il n’existe pas d’objectif universel. Un taux de hit utile est celui qui génère des économies nettes positives et améliore ou préserve le coût par tâche acceptée. Les préfixes volumineux peuvent justifier des taux de hit plus faibles ; les petits préfixes peuvent nécessiter une réutilisation très élevée.
La mise en cache des prompts améliore-t-elle la latence ?
Elle peut réduire la latence de traitement des entrées pour les hits du cache, mais l’effet dépend du fournisseur, du modèle, de la taille du prompt, du chemin réseau et de la charge de travail. Suivez la latence P50 et P95 plutôt que de supposer une amélioration fixe.
Dois-je mettre en cache l’intégralité de la conversation ?
En général, vous devriez maximiser un préfixe stable, et non pas tout mettre en cache sans discernement. Les tours de conversation grandissent et changent. Conservez tôt les instructions stables, les outils et le contenu de référence, puis ajoutez ensuite l’historique changeant et l’entrée de l’utilisateur.
Les prompts mis en cache peuvent-ils être partagés entre fournisseurs ?
Non. Les caches de prompts côté fournisseur sont spécifiques à chaque fournisseur. Si le routage change de fournisseur ou de modèle, considérez la requête comme un probable échec de cache, sauf si le fournisseur documente explicitement une réutilisation compatible.
La mise en cache des prompts est-elle sûre pour les données sensibles ?
Examinez, pour votre compte et votre modèle, la gestion des données par le fournisseur, l’isolation du cache, la conservation, la résidence des données et les პირობes de rétention nulle. N’utilisez pas l’optimisation des coûts pour contourner les exigences de sécurité, de confidentialité ou d’isolation des locataires.
Commencez par un seul préfixe répété
Le meilleur workflow de mise en cache des prompts est volontairement étroit : choisissez une charge de travail coûteuse et fortement réutilisée ; placez le contenu stable au début ; versionnez-le ; mesurez les hits, les misses, la latence, la qualité et le coût ; puis calculez le ROI net.
Lorsque le résultat améliore le coût par tâche acceptée, étendez le modèle au workflow suivant. Lorsque ce n’est pas le cas, la télémétrie vous indiquera si le problème vient de la fragmentation des prompts, d’un volume insuffisant, d’une conservation trop courte, de la tarification du fournisseur ou d’une charge de travail qui n’était pas un bon candidat pour la mise en cache.
