cache_control :
cache_control. Cela permet de réutiliser ce grand texte dans plusieurs appels API sans le retraiter à chaque fois. Modifier uniquement le message utilisateur vous permet de poser diverses questions sur le livre tout en utilisant le contenu mis en cache, ce qui entraîne des réponses plus rapides et une meilleure efficacité.
Comment fonctionne la mise en cache des invites
Lorsque vous envoyez une demande avec la mise en cache des invites activée :- Le système vérifie si un préfixe d’invite, jusqu’à un point de rupture de cache spécifié, est déjà mis en cache à partir d’une requête récente.
- S’il est trouvé, il utilise la version mise en cache, réduisant le temps de traitement et les coûts.
- Sinon, il traite l’invite complète et met en cache le préfixe une fois que la réponse commence.
- Les invites avec de nombreux exemples
- De grandes quantités de contexte ou d’informations générales
- Les tâches répétitives avec des instructions cohérentes
- Les longues conversations multi-tours
tools, system et messages (dans cet ordre) jusqu’à et y compris le bloc désigné avec cache_control.Tarification
La mise en cache des invites introduit une nouvelle structure tarifaire. Le tableau ci-dessous montre le prix par million de jetons pour chaque modèle pris en charge :| Model | Base Input Tokens | 5m Cache Writes | 1h Cache Writes | Cache Hits & Refreshes | Output Tokens |
|---|---|---|---|---|---|
| Claude Opus 4.1 | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
| Claude Opus 4 | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
| Claude Sonnet 4.5 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Sonnet 4 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Sonnet 3.7 (deprecated) | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Haiku 4.5 | $1 / MTok | $1.25 / MTok | $2 / MTok | $0.10 / MTok | $5 / MTok |
| Claude Haiku 3.5 | $0.80 / MTok | $1 / MTok | $1.6 / MTok | $0.08 / MTok | $4 / MTok |
| Claude Opus 3 (deprecated) | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
| Claude Haiku 3 | $0.25 / MTok | $0.30 / MTok | $0.50 / MTok | $0.03 / MTok | $1.25 / MTok |
- Les jetons d’écriture de cache de 5 minutes coûtent 1,25 fois le prix des jetons d’entrée de base
- Les jetons d’écriture de cache d’1 heure coûtent 2 fois le prix des jetons d’entrée de base
- Les jetons de lecture du cache coûtent 0,1 fois le prix des jetons d’entrée de base
Comment implémenter la mise en cache des invites
Modèles pris en charge
La mise en cache des invites est actuellement prise en charge sur :- Claude Opus 4.1
- Claude Opus 4
- Claude Sonnet 4.5
- Claude Sonnet 4
- Claude Sonnet 3.7
- Claude Haiku 4.5
- Claude Haiku 3.5
- Claude Haiku 3
- Claude Opus 3 (obsolète)
Structurer votre invite
Placez le contenu statique (définitions d’outils, instructions système, contexte, exemples) au début de votre invite. Marquez la fin du contenu réutilisable pour la mise en cache à l’aide du paramètrecache_control.
Les préfixes de cache sont créés dans l’ordre suivant : tools, system, puis messages. Cet ordre forme une hiérarchie où chaque niveau s’appuie sur les précédents.
Comment fonctionne la vérification automatique des préfixes
Vous pouvez utiliser un seul point de rupture de cache à la fin de votre contenu statique, et le système trouvera automatiquement le préfixe correspondant le plus long. Comprendre comment cela fonctionne vous aide à optimiser votre stratégie de mise en cache. Trois principes fondamentaux :-
Les clés de cache sont cumulatives : Lorsque vous mettez explicitement en cache un bloc avec
cache_control, la clé de hachage du cache est générée en hachant tous les blocs précédents dans la conversation de manière séquentielle. Cela signifie que le cache pour chaque bloc dépend de tout le contenu qui l’a précédé. - Vérification séquentielle rétroactive : Le système vérifie les accès au cache en travaillant à rebours à partir de votre point de rupture explicite, en vérifiant chaque bloc précédent dans l’ordre inverse. Cela garantit que vous obtenez l’accès au cache le plus long possible.
-
Fenêtre de recherche rétroactive de 20 blocs : Le système ne vérifie que jusqu’à 20 blocs avant chaque point de rupture
cache_controlexplicite. Après avoir vérifié 20 blocs sans correspondance, il arrête la vérification et passe au point de rupture explicite suivant (le cas échéant).
cache_control uniquement sur le bloc 30 :
- Si vous envoyez le bloc 31 sans modifications aux blocs précédents : Le système vérifie le bloc 30 (correspondance !). Vous obtenez un accès au cache au bloc 30, et seul le bloc 31 nécessite un traitement.
- Si vous modifiez le bloc 25 et envoyez le bloc 31 : Le système vérifie à rebours du bloc 30 → 29 → 28… → 25 (pas de correspondance) → 24 (correspondance !). Puisque le bloc 24 n’a pas changé, vous obtenez un accès au cache au bloc 24, et seuls les blocs 25-30 nécessitent un retraitement.
-
Si vous modifiez le bloc 5 et envoyez le bloc 31 : Le système vérifie à rebours du bloc 30 → 29 → 28… → 11 (vérification #20). Après 20 vérifications sans trouver de correspondance, il arrête la recherche. Puisque le bloc 5 est au-delà de la fenêtre de 20 blocs, aucun accès au cache ne se produit et tous les blocs nécessitent un retraitement. Cependant, si vous aviez défini un point de rupture
cache_controlexplicite sur le bloc 5, le système continuerait à vérifier à partir de ce point de rupture : bloc 5 (pas de correspondance) → bloc 4 (correspondance !). Cela permet un accès au cache au bloc 4, démontrant pourquoi vous devriez placer des points de rupture avant le contenu modifiable.
Quand utiliser plusieurs points de rupture
Vous pouvez définir jusqu’à 4 points de rupture de cache si vous souhaitez :- Mettre en cache différentes sections qui changent à des fréquences différentes (par exemple, les outils changent rarement, mais le contexte se met à jour quotidiennement)
- Avoir plus de contrôle sur exactement ce qui est mis en cache
- Assurer la mise en cache du contenu plus de 20 blocs avant votre point de rupture final
- Placer des points de rupture avant le contenu modifiable pour garantir des accès au cache même lorsque des modifications se produisent au-delà de la fenêtre de 20 blocs
Limitations du cache
La longueur minimale d’invite pouvant être mise en cache est :- 1024 jetons pour Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4.5, Claude Sonnet 4, Claude Sonnet 3.7 (obsolète) et Claude Opus 3 (obsolète)
- 4096 jetons pour Claude Haiku 4.5
- 2048 jetons pour Claude Haiku 3.5 et Claude Haiku 3
cache_control. Toute demande de mise en cache de moins que ce nombre de jetons sera traitée sans mise en cache. Pour voir si une invite a été mise en cache, consultez les champs d’utilisation de la réponse.
Pour les demandes concurrentes, notez qu’une entrée de cache ne devient disponible qu’après le début de la première réponse. Si vous avez besoin d’accès au cache pour les demandes parallèles, attendez la première réponse avant d’envoyer les demandes suivantes.
Actuellement, « ephemeral » est le seul type de cache pris en charge, qui a par défaut une durée de vie de 5 minutes.
Comprendre les coûts des points de rupture de cache
Les points de rupture de cache eux-mêmes n’ajoutent aucun coût. Vous êtes facturé uniquement pour :- Écritures de cache : Lorsque du nouveau contenu est écrit dans le cache (25 % de plus que les jetons d’entrée de base pour TTL de 5 minutes)
- Lectures de cache : Lorsque le contenu mis en cache est utilisé (10 % du prix des jetons d’entrée de base)
- Jetons d’entrée réguliers : Pour tout contenu non mis en cache
cache_control n’augmente pas vos coûts - vous payez toujours le même montant en fonction du contenu réellement mis en cache et lu. Les points de rupture vous donnent simplement le contrôle sur les sections qui peuvent être mises en cache indépendamment.
Ce qui peut être mis en cache
La plupart des blocs de la demande peuvent être désignés pour la mise en cache aveccache_control. Cela inclut :
- Outils : Définitions d’outils dans le tableau
tools - Messages système : Blocs de contenu dans le tableau
system - Messages texte : Blocs de contenu dans le tableau
messages.content, pour les tours utilisateur et assistant - Images et documents : Blocs de contenu dans le tableau
messages.content, dans les tours utilisateur - Utilisation d’outils et résultats d’outils : Blocs de contenu dans le tableau
messages.content, dans les tours utilisateur et assistant
cache_control pour activer la mise en cache pour cette partie de la demande.
Ce qui ne peut pas être mis en cache
Bien que la plupart des blocs de demande puissent être mis en cache, il y a quelques exceptions :-
Les blocs de réflexion ne peuvent pas être mis en cache directement avec
cache_control. Cependant, les blocs de réflexion PEUVENT être mis en cache aux côtés d’autre contenu lorsqu’ils apparaissent dans les tours assistant précédents. Lorsqu’ils sont mis en cache de cette façon, ils COMPTENT comme des jetons d’entrée lorsqu’ils sont lus à partir du cache. - Les blocs de sous-contenu (comme les citations) eux-mêmes ne peuvent pas être mis en cache directement. À la place, mettez en cache le bloc de niveau supérieur. Dans le cas des citations, les blocs de contenu de document de niveau supérieur qui servent de matériel source pour les citations peuvent être mis en cache. Cela vous permet d’utiliser la mise en cache des invites avec les citations efficacement en mettant en cache les documents que les citations référenceront.
- Les blocs de texte vides ne peuvent pas être mis en cache.
Ce qui invalide le cache
Les modifications du contenu mis en cache peuvent invalider une partie ou la totalité du cache. Comme décrit dans Structurer votre invite, le cache suit la hiérarchie :tools → system → messages. Les modifications à chaque niveau invalident ce niveau et tous les niveaux suivants.
Le tableau suivant montre quelles parties du cache sont invalidées par différents types de modifications. ✘ indique que le cache est invalidé, tandis que ✓ indique que le cache reste valide.
| Ce qui change | Cache des outils | Cache système | Cache des messages | Impact |
|---|---|---|---|---|
| Définitions d’outils | ✘ | ✘ | ✘ | Modifier les définitions d’outils (noms, descriptions, paramètres) invalide l’intégralité du cache |
| Basculement de recherche Web | ✓ | ✘ | ✘ | L’activation/désactivation de la recherche Web modifie l’invite système |
| Basculement des citations | ✓ | ✘ | ✘ | L’activation/désactivation des citations modifie l’invite système |
| Choix d’outil | ✓ | ✓ | ✘ | Les modifications du paramètre tool_choice n’affectent que les blocs de messages |
| Images | ✓ | ✓ | ✘ | L’ajout/suppression d’images n’importe où dans l’invite affecte les blocs de messages |
| Paramètres de réflexion | ✓ | ✓ | ✘ | Les modifications des paramètres de réflexion étendue (activation/désactivation, budget) affectent les blocs de messages |
| Résultats non-outils transmis aux demandes de réflexion étendue | ✓ | ✓ | ✘ | Lorsque des résultats non-outils sont transmis dans les demandes tandis que la réflexion étendue est activée, tous les blocs de réflexion précédemment mis en cache sont supprimés du contexte, et tous les messages en contexte qui suivent ces blocs de réflexion sont supprimés du cache. Pour plus de détails, consultez Mise en cache avec les blocs de réflexion. |
Suivi des performances du cache
Surveillez les performances du cache à l’aide de ces champs de réponse API, dansusage dans la réponse (ou événement message_start si streaming) :
cache_creation_input_tokens: Nombre de jetons écrits dans le cache lors de la création d’une nouvelle entrée.cache_read_input_tokens: Nombre de jetons récupérés du cache pour cette demande.input_tokens: Nombre de jetons d’entrée qui n’ont pas été lus ou utilisés pour créer un cache.
Meilleures pratiques pour une mise en cache efficace
Pour optimiser les performances de la mise en cache des invites :- Mettez en cache le contenu stable et réutilisable comme les instructions système, les informations générales, les grands contextes ou les définitions d’outils fréquentes.
- Placez le contenu mis en cache au début de l’invite pour de meilleures performances.
- Utilisez les points de rupture de cache de manière stratégique pour séparer différentes sections de préfixe pouvant être mises en cache.
- Définissez les points de rupture de cache à la fin des conversations et juste avant le contenu modifiable pour maximiser les taux d’accès au cache, en particulier lorsque vous travaillez avec des invites ayant plus de 20 blocs de contenu.
- Analysez régulièrement les taux d’accès au cache et ajustez votre stratégie selon les besoins.
Optimisation pour différents cas d’utilisation
Adaptez votre stratégie de mise en cache des invites à votre scénario :- Agents conversationnels : Réduisez le coût et la latence pour les conversations prolongées, en particulier celles avec de longues instructions ou des documents téléchargés.
- Assistants de codage : Améliorez l’autocomplétion et les questions-réponses sur la base de code en gardant les sections pertinentes ou une version résumée de la base de code dans l’invite.
- Traitement de grands documents : Incorporez du matériel long complet, y compris des images, dans votre invite sans augmenter la latence de réponse.
- Ensembles d’instructions détaillées : Partagez des listes étendues d’instructions, de procédures et d’exemples pour affiner les réponses de Claude. Les développeurs incluent souvent un ou deux exemples dans l’invite, mais avec la mise en cache des invites, vous pouvez obtenir des performances encore meilleures en incluant 20+ exemples divers de réponses de haute qualité.
- Utilisation d’outils agentiques : Améliorez les performances pour les scénarios impliquant plusieurs appels d’outils et des modifications de code itératives, où chaque étape nécessite généralement un nouvel appel API.
- Parlez à des livres, des articles, de la documentation, des transcriptions de podcasts et d’autres contenus longs : Donnez vie à n’importe quelle base de connaissances en intégrant le ou les documents entiers dans l’invite, et laissez les utilisateurs poser des questions.
Dépannage des problèmes courants
Si vous rencontrez un comportement inattendu :- Assurez-vous que les sections mises en cache sont identiques et marquées avec cache_control aux mêmes emplacements dans tous les appels
- Vérifiez que les appels sont effectués dans la durée de vie du cache (5 minutes par défaut)
- Vérifiez que
tool_choiceet l’utilisation d’images restent cohérents entre les appels - Validez que vous mettez en cache au moins le nombre minimum de jetons
- Le système vérifie automatiquement les accès au cache aux limites des blocs de contenu précédents (jusqu’à ~20 blocs avant votre point de rupture). Pour les invites avec plus de 20 blocs de contenu, vous devrez peut-être ajouter des paramètres
cache_controlsupplémentaires plus tôt dans l’invite pour assurer que tout le contenu peut être mis en cache - Vérifiez que les clés de vos blocs de contenu
tool_useont un ordre stable car certains langages (par exemple Swift, Go) randomisent l’ordre des clés lors de la conversion JSON, ce qui casse les caches
tool_choice ou la présence/absence d’images n’importe où dans l’invite invalideront le cache, nécessitant la création d’une nouvelle entrée de cache. Pour plus de détails sur l’invalidation du cache, consultez Ce qui invalide le cache.Mise en cache avec les blocs de réflexion
Lorsque vous utilisez la réflexion étendue avec la mise en cache des invites, les blocs de réflexion ont un comportement spécial : Mise en cache automatique aux côtés d’autre contenu : Bien que les blocs de réflexion ne puissent pas être explicitement marqués aveccache_control, ils sont mis en cache dans le cadre du contenu de la demande lorsque vous effectuez des appels API ultérieurs avec des résultats d’outils. Cela se produit généralement lors de l’utilisation d’outils lorsque vous transmettez les blocs de réflexion pour continuer la conversation.
Comptage des jetons d’entrée : Lorsque les blocs de réflexion sont lus à partir du cache, ils comptent comme des jetons d’entrée dans vos métriques d’utilisation. C’est important pour le calcul des coûts et la budgétisation des jetons.
Modèles d’invalidation du cache :
- Le cache reste valide lorsque seuls les résultats d’outils sont fournis en tant que messages utilisateur
- Le cache est invalidé lorsque du contenu utilisateur non-résultat d’outil est ajouté, ce qui entraîne la suppression de tous les blocs de réflexion précédents
- Ce comportement de mise en cache se produit même sans marqueurs
cache_controlexplicites
Stockage et partage du cache
- Isolation organisationnelle : Les caches sont isolés entre les organisations. Différentes organisations ne partagent jamais les caches, même si elles utilisent des invites identiques.
- Correspondance exacte : Les accès au cache nécessitent une correspondance à 100 % des segments d’invite, y compris tout le texte et les images jusqu’à et y compris le bloc marqué avec le contrôle de cache.
- Génération de jetons de sortie : La mise en cache des invites n’a aucun effet sur la génération de jetons de sortie. La réponse que vous recevez sera identique à ce que vous obtiendriez si la mise en cache des invites n’était pas utilisée.
Durée du cache d’1 heure
Si vous trouvez que 5 minutes est trop court, Anthropic propose également une durée de cache d’1 heure à un coût supplémentaire. Pour utiliser le cache étendu, incluezttl dans la définition cache_control comme ceci :
cache_creation_input_tokens actuel est égal à la somme des valeurs dans l’objet cache_creation.
Quand utiliser le cache d’1 heure
Si vous avez des invites utilisées à un rythme régulier (c’est-à-dire des invites système utilisées plus fréquemment que toutes les 5 minutes), continuez à utiliser le cache de 5 minutes, car celui-ci continuera à être actualisé sans frais supplémentaires. Le cache d’1 heure est mieux utilisé dans les scénarios suivants :- Lorsque vous avez des invites susceptibles d’être utilisées moins fréquemment que toutes les 5 minutes, mais plus fréquemment que toutes les heures. Par exemple, lorsqu’un agent auxiliaire agentique prendra plus de 5 minutes, ou lorsque vous stockez une longue conversation de chat avec un utilisateur et vous vous attendez généralement à ce que cet utilisateur ne réponde pas dans les 5 prochaines minutes.
- Lorsque la latence est importante et que vos invites de suivi peuvent être envoyées au-delà de 5 minutes.
- Lorsque vous souhaitez améliorer votre utilisation des limites de débit, car les accès au cache ne sont pas déduits de votre limite de débit.
Mélanger différents TTL
Vous pouvez utiliser à la fois les contrôles de cache d’1 heure et de 5 minutes dans la même demande, mais avec une contrainte importante : Les entrées de cache avec un TTL plus long doivent apparaître avant les TTL plus courts (c’est-à-dire qu’une entrée de cache d’1 heure doit apparaître avant toute entrée de cache de 5 minutes). Lors du mélange des TTL, nous déterminons trois emplacements de facturation dans votre invite :- Position
A: Le nombre de jetons au plus haut accès au cache (ou 0 s’il n’y a pas d’accès). - Position
B: Le nombre de jetons au plus haut bloccache_controld’1 heure aprèsA(ou égal àAs’il n’en existe pas). - Position
C: Le nombre de jetons au dernier bloccache_control.
B et/ou C sont supérieurs à A, ils seront nécessairement des accès manqués au cache, car A est l’accès au cache le plus élevé.- Jetons de lecture du cache pour
A. - Jetons d’écriture de cache d’1 heure pour
(B - A). - Jetons d’écriture de cache de 5 minutes pour
(C - B).
Exemples de mise en cache des invites
Pour vous aider à démarrer avec la mise en cache des invites, nous avons préparé un livre de recettes de mise en cache des invites avec des exemples détaillés et des meilleures pratiques. Ci-dessous, nous avons inclus plusieurs extraits de code qui présentent divers modèles de mise en cache des invites. Ces exemples démontrent comment implémenter la mise en cache dans différents scénarios, vous aidant à comprendre les applications pratiques de cette fonctionnalité :Exemple de mise en cache de grand contexte
Exemple de mise en cache de grand contexte
input_tokens: Nombre de jetons dans le message utilisateur uniquementcache_creation_input_tokens: Nombre de jetons dans l’intégralité du message système, y compris le document juridiquecache_read_input_tokens: 0 (pas d’accès au cache à la première demande)
input_tokens: Nombre de jetons dans le message utilisateur uniquementcache_creation_input_tokens: 0 (pas de nouvelle création de cache)cache_read_input_tokens: Nombre de jetons dans l’intégralité du message système mis en cache
Mise en cache des définitions d'outils
Mise en cache des définitions d'outils
cache_control est placé sur l’outil final (get_time) pour désigner tous les outils comme faisant partie du préfixe statique.Cela signifie que toutes les définitions d’outils, y compris get_weather et tous les autres outils définis avant get_time, seront mis en cache en tant que préfixe unique.Cette approche est utile lorsque vous avez un ensemble cohérent d’outils que vous souhaitez réutiliser dans plusieurs demandes sans les retraiter à chaque fois.Pour la première demande :input_tokens: Nombre de jetons dans le message utilisateurcache_creation_input_tokens: Nombre de jetons dans toutes les définitions d’outils et l’invite systèmecache_read_input_tokens: 0 (pas d’accès au cache à la première demande)
input_tokens: Nombre de jetons dans le message utilisateurcache_creation_input_tokens: 0 (pas de nouvelle création de cache)cache_read_input_tokens: Nombre de jetons dans toutes les définitions d’outils et l’invite système mises en cache
Continuation d'une conversation multi-tours
Continuation d'une conversation multi-tours
cache_control afin que la conversation puisse être progressivement mise en cache. Le système recherchera automatiquement et utilisera le préfixe précédemment mis en cache le plus long pour les messages de suivi. C’est-à-dire que les blocs qui ont été précédemment marqués avec un bloc cache_control ne sont pas marqués ultérieurement, mais ils seront toujours considérés comme un accès au cache (et aussi une actualisation du cache !) s’ils sont atteints dans les 5 minutes.De plus, notez que le paramètre cache_control est placé sur le message système. Ceci est pour assurer que s’il est évincé du cache (après ne pas avoir été utilisé pendant plus de 5 minutes), il sera rajouté au cache à la prochaine demande.Cette approche est utile pour maintenir le contexte dans les conversations en cours sans retraiter à plusieurs reprises les mêmes informations.Lorsque ceci est configuré correctement, vous devriez voir ce qui suit dans la réponse d’utilisation de chaque demande :input_tokens: Nombre de jetons dans le nouveau message utilisateur (sera minimal)cache_creation_input_tokens: Nombre de jetons dans les nouveaux tours assistant et utilisateurcache_read_input_tokens: Nombre de jetons dans la conversation jusqu’au tour précédent
Tout mettre ensemble : Points de rupture de cache multiples
Tout mettre ensemble : Points de rupture de cache multiples
-
Cache des outils (point de rupture de cache 1) : Le paramètre
cache_controlsur la dernière définition d’outil met en cache toutes les définitions d’outils. - Cache des instructions réutilisables (point de rupture de cache 2) : Les instructions statiques dans l’invite système sont mises en cache séparément. Ces instructions changent rarement entre les demandes.
- Cache du contexte RAG (point de rupture de cache 3) : Les documents de la base de connaissances sont mis en cache indépendamment, vous permettant de mettre à jour les documents RAG sans invalider le cache des outils ou des instructions.
-
Cache de l’historique de conversation (point de rupture de cache 4) : La réponse de l’assistant est marquée avec
cache_controlpour activer la mise en cache progressive de la conversation au fur et à mesure qu’elle progresse.
- Si vous mettez à jour uniquement le message utilisateur final, les quatre segments de cache sont réutilisés
- Si vous mettez à jour les documents RAG mais conservez les mêmes outils et instructions, les deux premiers segments de cache sont réutilisés
- Si vous modifiez la conversation mais conservez les mêmes outils, instructions et documents, les trois premiers segments sont réutilisés
- Chaque point de rupture de cache peut être invalidé indépendamment en fonction de ce qui change dans votre application
input_tokens: Jetons dans le message utilisateur finalcache_creation_input_tokens: Jetons dans tous les segments mis en cache (outils + instructions + documents RAG + historique de conversation)cache_read_input_tokens: 0 (pas d’accès au cache)
input_tokens: Jetons dans le nouveau message utilisateur uniquementcache_creation_input_tokens: Tous les nouveaux jetons ajoutés à l’historique de conversationcache_read_input_tokens: Tous les jetons précédemment mis en cache (outils + instructions + documents RAG + conversation précédente)
- Les applications RAG avec de grands contextes de documents
- Les systèmes d’agents qui utilisent plusieurs outils
- Les conversations longues qui doivent maintenir le contexte
- Les applications qui doivent optimiser différentes parties de l’invite indépendamment
FAQ
Ai-je besoin de plusieurs points de rupture de cache ou un seul à la fin suffit-il ?
Ai-je besoin de plusieurs points de rupture de cache ou un seul à la fin suffit-il ?
- Vous avez plus de 20 blocs de contenu avant votre point de cache souhaité
- Vous souhaitez mettre en cache des sections qui se mettent à jour à des fréquences différentes indépendamment
- Vous avez besoin d’un contrôle explicite sur ce qui est mis en cache pour l’optimisation des coûts
Les points de rupture de cache ajoutent-ils un coût supplémentaire ?
Les points de rupture de cache ajoutent-ils un coût supplémentaire ?
- L’écriture de contenu dans le cache (25 % de plus que les jetons d’entrée de base pour TTL de 5 minutes)
- La lecture à partir du cache (10 % du prix des jetons d’entrée de base)
- Les jetons d’entrée réguliers pour le contenu non mis en cache
Quelle est la durée de vie du cache ?
Quelle est la durée de vie du cache ?
Combien de points de rupture de cache puis-je utiliser ?
Combien de points de rupture de cache puis-je utiliser ?
cache_control) dans votre invite.La mise en cache des invites est-elle disponible pour tous les modèles ?
La mise en cache des invites est-elle disponible pour tous les modèles ?
Comment fonctionne la mise en cache des invites avec la réflexion étendue ?
Comment fonctionne la mise en cache des invites avec la réflexion étendue ?
Comment activer la mise en cache des invites ?
Comment activer la mise en cache des invites ?
cache_control dans votre demande API.Puis-je utiliser la mise en cache des invites avec d'autres fonctionnalités de l'API ?
Puis-je utiliser la mise en cache des invites avec d'autres fonctionnalités de l'API ?
Comment la mise en cache des invites affecte-t-elle la tarification ?
Comment la mise en cache des invites affecte-t-elle la tarification ?
Puis-je effacer manuellement le cache ?
Puis-je effacer manuellement le cache ?
Comment puis-je suivre l'efficacité de ma stratégie de mise en cache ?
Comment puis-je suivre l'efficacité de ma stratégie de mise en cache ?
cache_creation_input_tokens et cache_read_input_tokens dans la réponse de l’API.Qu'est-ce qui peut casser le cache ?
Qu'est-ce qui peut casser le cache ?
Comment la mise en cache des invites gère-t-elle la confidentialité et la séparation des données ?
Comment la mise en cache des invites gère-t-elle la confidentialité et la séparation des données ?
- Les clés de cache sont générées à l’aide d’un hachage cryptographique des invites jusqu’au point de contrôle de cache. Cela signifie que seules les demandes avec des invites identiques peuvent accéder à un cache spécifique.
- Les caches sont spécifiques à l’organisation. Les utilisateurs au sein de la même organisation peuvent accéder au même cache s’ils utilisent des invites identiques, mais les caches ne sont pas partagés entre différentes organisations, même pour des invites identiques.
- Le mécanisme de mise en cache est conçu pour maintenir l’intégrité et la confidentialité de chaque conversation ou contexte unique.
-
Il est sûr d’utiliser
cache_controln’importe où dans vos invites. Pour l’efficacité des coûts, il est préférable d’exclure les parties très variables (par exemple, l’entrée arbitraire de l’utilisateur) de la mise en cache.
Puis-je utiliser la mise en cache des invites avec l'API Batches ?
Puis-je utiliser la mise en cache des invites avec l'API Batches ?
- Rassemblez un ensemble de demandes de messages qui ont un préfixe partagé.
- Envoyez une demande de lot avec juste une seule demande qui a ce préfixe partagé et un bloc de cache d’1 heure. Cela sera écrit dans le cache d’1 heure.
- Dès que c’est terminé, soumettez le reste des demandes. Vous devrez surveiller le travail pour savoir quand il se termine.
Pourquoi je vois l'erreur `AttributeError: 'Beta' object has no attribute 'prompt_caching'` en Python ?
Pourquoi je vois l'erreur `AttributeError: 'Beta' object has no attribute 'prompt_caching'` en Python ?
Pourquoi je vois l'erreur 'TypeError: Cannot read properties of undefined (reading 'messages')'?
Pourquoi je vois l'erreur 'TypeError: Cannot read properties of undefined (reading 'messages')'?