Mise en cache des prompts

Modifier une requête ne supprime pas nécessairement une entrée existante du cache. Ce qui compte, c’est qu’une requête ultérieure ait le même préfixe et puisse trouver un point d’arrêt admissible correspondant. Voici les principaux paramètres à vérifier :

Pour GPT-5.6 et les modèles ultérieurs, les écritures dans le cache coûtent 1,25× le tarif standard des tokens d’entrée non mis en cache. Ce surcoût est avantageux lorsque vous savez qu’un préfixe sera réutilisé, car les lectures suivantes ne coûtent que 0,1× ce tarif. Écrire un préfixe une fois et le réutiliser intégralement une fois coûte 1,35× son coût d’entrée habituel, contre 2× pour le traiter deux fois sans mise en cache. Les économies augmentent à chaque lecture supplémentaire du cache : sur dix requêtes, une écriture et neuf lectures complètes coûtent 2,15×, contre 10× sans mise en cache.

La mise en cache implicite et la mise en cache explicite sont toutes deux prises en charge. La mise en cache explicite vous permet de mieux contrôler les parties du contexte écrites dans le cache.

Mode explicite : Vous choisissez où placer les points d’arrêt de cache en fonction de votre gestion du contexte.

• Définissez prompt_cache_options.mode sur explicit pour utiliser uniquement les points d’arrêt choisis par le développeur, puis marquez chaque point d’arrêt souhaité en ajoutant prompt_cache_breakpoint: { "mode": "explicit" } à un bloc de contenu pris en charge dans un message d’entrée.
• Lorsqu’aucun point d’arrêt explicite n’est placé, la requête n’utilise pas la mise en cache des prompts et n’effectue aucune écriture dans le cache.
• Le mode exclusivement explicite vous permet de choisir où s’arrêtent les écritures dans le cache. Le contenu situé après le dernier point d’arrêt sélectionné est traité au tarif des tokens d’entrée non mis en cache, sans frais d’écriture dans le cache. Vous pouvez ainsi éviter d’y écrire du contenu variable qui a peu de chances d’être réutilisé.
• Plusieurs points d’arrêt explicites permettent de conserver des préfixes qui changent à des fréquences différentes. Chaque requête peut effectuer jusqu’à quatre écritures dans le cache.
• Les éléments d’entrée additional_tools n’acceptent pas prompt_cache_breakpoint pour le moment.

Mode implicite : OpenAI choisit automatiquement des emplacements de points d’arrêt adaptés à la plupart des cas d’utilisation.

• Lorsque prompt_cache_options.mode vaut implicit, OpenAI place un point d’arrêt à la fin du dernier message admissible. Les messages admissibles sont :
  • les messages utilisateur
  • la dernière réponse d’outil d’un groupe de réponses d’outils consécutives
  • le dernier message développeur du groupe initial de messages développeur consécutifs.
• Vous pouvez ajouter des points d’arrêt explicites sans désactiver le point d’arrêt implicite. Celui-ci utilise l’un des quatre emplacements d’écriture dans le cache, ce qui laisse trois emplacements disponibles pour les écritures explicites.

Seule la mise en cache implicite est prise en charge. OpenAI place les points d’arrêt implicites à des intervalles qui dépendent du modèle, à partir du début du message système masqué d’OpenAI. Seuls les points d’arrêt qui atteignent ou dépassent la longueur minimale de mise en cache (comptée à partir de la fin du contexte masqué) sont admissibles.

La valeur cached_tokens renvoyée est calculée en soustrayant les tokens système masqués du nombre de tokens jusqu’au dernier point d’arrêt correspondant, puis en arrondissant le résultat au multiple de 128 inférieur le plus proche.

Utilisez prompt_cache_options.ttl pour définir la durée de vie minimale du cache. La seule valeur prise en charge, 30m, est aussi la valeur par défaut. Un préfixe mis en cache reste réutilisable pendant 30 minutes après sa dernière écriture ou réutilisation, mais OpenAI peut le conserver plus longtemps.

Utilisez prompt_cache_retention, dont les valeurs prises en charge dépendent du modèle :

• in_memory : les entrées restent généralement actives pendant environ 5 à 10 minutes d’inactivité, et jusqu’à une heure.
• 24h : la conservation prolongée maintient généralement les entrées disponibles pendant environ 30 minutes et peut les conserver jusqu’à 24 heures.

Paramètres de conservation par défaut et politique de non-conservation des données

La mise en cache des prompts peut stocker des tenseurs clé/valeur chiffrés dans le stockage local du GPU en tant qu’état de l’application. Pour les modèles qui prennent en charge à la fois in_memory et 24h, la valeur par défaut dépend de la politique de conservation des données de votre organisation :

• Les organisations sans politique de non-conservation des données activée utilisent 24h par défaut.
• Les organisations avec une politique de non-conservation des données activée utilisent in_memory par défaut.

Vérifiez les politiques de conservation disponibles pour votre modèle et votre organisation avant de choisir une valeur.

Sur les modèles antérieurs à GPT-5.6, utilisez une valeur prompt_cache_key stable pour les requêtes qui partagent un préfixe réutilisable afin de faciliter leur routage vers le même cache. Pour les groupes à fort trafic, visez environ 15 requêtes par minute au total pour chaque clé, tous préfixes confondus. Répartissez les volumes de trafic plus élevés sur plusieurs clés à l’aide d’une correspondance stable et déterministe. Conservez la même valeur prompt_cache_key pour les requêtes liées afin qu’elles puissent réutiliser le cache associé. Les clés influencent le routage ; elles ne lient pas les requêtes à une machine et ne garantissent pas un accès au cache réussi.

Sur GPT-5.6 et les modèles ultérieurs, OpenAI gère automatiquement le routage vers le cache ; la clé n’est pas nécessaire pour optimiser la mise en cache. Vous pouvez utiliser des clés distinctes pour comptabiliser séparément l’utilisation du cache des clients ou des utilisateurs de votre application.

L’utilisation de clés distinctes peut faciliter l’explication de l’utilisation et de la facturation des tokens mis en cache pour chaque client ou utilisateur. Par exemple, des clés distinctes contribuent à empêcher qu’un utilisateur sonde le cache d’un autre en soumettant des prompts de test et en observant les accès au cache réussis pour déterminer si un contenu correspondant a déjà été mis en cache. Consultez Comptabilisez séparément l’utilisation du cache à l’aide de clés.

Dans les applications à plusieurs tours de conversation, réutiliser l’historique qui s’allonge peut économiser davantage de tokens d’entrée que la seule mise en cache des instructions initiales. Préservez les messages précédents et les résultats des outils pour que les tours suivants puissent réutiliser l’intégralité du préfixe partagé.

• Gardez un préfixe stable. Placez les instructions développeur stables et les documents de référence partagés en premier. Si ces instructions ou documents contiennent des horodatages, du contenu propre à l’utilisateur ou d’autres éléments dynamiques, placez ces éléments à la fin plutôt qu’au début, ou déplacez-les dans des messages ultérieurs de la conversation.
• Préservez l’historique de la conversation. Ajoutez de nouveaux messages à la suite plutôt que de réécrire les tours précédents. La synthèse, le compactage ou la troncature du contexte peuvent modifier le préfixe et interrompre la réutilisation du cache.
• Modifiez l’effort de raisonnement sans réécrire le préfixe. Avec GPT-6 Astra, ajoutez un élément d’entrée configuration_update à la suite pour modifier l’effort de raisonnement entre les réponses, tout en conservant la valeur de reasoning.effort au niveau de la requête. Le préfixe d’origine reste ainsi réutilisable depuis le cache. Consultez Modifiez le raisonnement en cours de conversation pour découvrir des exemples et les limites de compatibilité.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26{
  "model": "gpt-5.6",
  "reasoning": { "effort": "low", "context": "all_turns" },
  "text": { "verbosity": "medium" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Stable instructions and shared reference material...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    {
      "role": "developer",
      "content": "Dynamic developer instructions, such as user-specific content and timestamps..."
    },
    {
      "role": "user",
      "content": "The user's current question..."
    }
  ]
}

Avec les modèles GPT-6 et ultérieurs compatibles, ajoutez un élément d’entrée configuration_update à la suite pour modifier l’effort de raisonnement en cours de conversation tout en préservant le préfixe précédemment mis en cache. Conservez la valeur d’origine de reasoning.effort au niveau supérieur, car modifier ce paramètre peut entraîner la réécriture de certaines instructions système masquées.

La dernière mise à jour de configuration détermine l’effort de raisonnement pour les réponses suivantes. Par exemple, ajoutez cet élément à la fin du tableau input existant pour passer au niveau de raisonnement high lors des requêtes suivantes :

1
2
3
4{
  "type": "configuration_update",
  "reasoning": { "effort": "high" }
}

Lorsque les outils nécessaires à votre application varient d’une requête à l’autre, modifiez les outils pouvant être appelés tout en gardant leurs définitions stables afin de préserver les préfixes réutilisables.

• Gardez les outils stables. Préservez leurs définitions, leur ordre et leurs schémas.
• Désactivez l’utilisation des outils pour une requête. Définissez tool_choice sur "none" plutôt que de supprimer les définitions des outils.
• Activez uniquement les outils sélectionnés. Utilisez allowed_tools pour limiter les outils pouvant être appelés tout en gardant la liste tools fournie inchangée.
• Chargez les outils au besoin. Utilisez la recherche d’outils avec defer_loading: true pour réduire le nombre de tokens d’entrée consacrés aux définitions des outils lors des premières requêtes d’une conversation à plusieurs tours. Les outils découverts sont ajoutés à la fin du contexte, ce qui préserve le contenu réutilisable déjà présent.
• Préservez l’historique de chargement des outils. Utilisez un élément d’entrée additional_tools avec le rôle développeur pour ajouter des outils au fil d’une conversation selon la logique de votre application.

Avec GPT-5.6 et les modèles ultérieurs, deux paramètres déterminent l’emplacement des points de coupure du cache : prompt_cache_options.mode sélectionne la mise en cache implicite ou exclusivement explicite, et prompt_cache_breakpoint marque une limite de votre choix.

• Placez les points de coupure automatiquement. Utilisez la mise en cache implicite pour placer un point de coupure à la fin du dernier message éligible. Cette méthode est pratique pour les conversations à plusieurs tours qui ajoutent du contenu à la suite du contexte existant.
• Choisissez soigneusement les points de coupure. Placez des marqueurs explicites à la fin du contenu stable. Utilisez le mode exclusivement explicite pour éviter les écritures en cache inutiles des suffixes variables.

Sur GPT-5.6 et les modèles ultérieurs, utilisez prompt_cache_key lorsque vous souhaitez comptabiliser séparément l’utilisation du cache des clients, des utilisateurs ou des espaces de travail de votre application. Cela peut faciliter l’explication de l’utilisation et de la facturation des tokens mis en cache au sein de chaque groupe. La clé est facultative et n’est pas nécessaire pour optimiser la mise en cache sur ces modèles.

• Choisissez comment séparer la comptabilisation de l’utilisation du cache. Attribuez une clé distincte à chaque client ou utilisateur dont l’utilisation du cache doit être comptabilisée séparément. Par exemple, support:customer_123 et support:customer_456 permettent de comptabiliser séparément l’utilisation du cache de deux clients, même lorsque leurs requêtes contiennent le même préfixe.
• Gardez les clés stables au sein de chaque groupe. Réutilisez la même clé pour les requêtes liées d’un client. Ne générez une clé distincte pour une session ou une conversation que si son utilisation du cache doit être comptabilisée séparément.
• Appliquez les clés de façon cohérente. Utilisez la clé du client dans toutes ses requêtes pour comptabiliser séparément son utilisation du cache. Cela contribue également à empêcher un client de sonder les accès au cache d’autres clients.

Sur les modèles antérieurs à GPT-5.6, prompt_cache_key joue un rôle important dans l’optimisation des taux de succès des accès au cache. Utilisez une clé stable pour les requêtes qui partagent un préfixe réutilisable afin de faciliter leur routage vers le même cache. Pour les groupes à fort trafic, suivez les recommandations pour répartir le trafic sur davantage de clés.

Pour les modèles antérieurs, privilégiez la valeur "24h" pour prompt_cache_retention afin de prolonger la conservation lorsque le modèle et vos exigences de conservation des données le permettent. Consultez Durée de vie du cache pour connaître les paramètres pris en charge et les valeurs par défaut.

Si de nombreuses requêtes réutilisent les mêmes instructions développeur et définitions d’outils, mais que ce préfixe partagé reste inférieur à la longueur minimale de mise en cache du modèle, envisagez de le raccourcir ou de l’allonger avec des instructions, des exemples ou des documents de référence utiles et stables. Mesurez si la réutilisation du cache compense les tokens d’entrée supplémentaires et les éventuels frais d’écriture en cache, et vérifiez que les évaluations et le comportement restent stables.

Le graphique illustre le piège des coûts liés à la longueur minimale de mise en cache : un préfixe court non mis en cache peut coûter plus cher qu’un préfixe allongé jusqu’au nombre minimal de tokens requis pour la mise en cache.

• Mesurez les performances réelles du cache. Suivez usage.input_tokens_details.cached_tokens, usage.input_tokens_details.cache_write_tokens, le nombre de tokens d’entrée, la latence et le coût effectif. Suivez le taux de succès du cache en tokens en divisant le nombre total de tokens lus depuis le cache par le nombre total de tokens d’entrée, après avoir agrégé ces deux nombres par utilisateur, espace de travail, jour ou tout autre regroupement pertinent.
• Calculez le coût des tokens d’entrée. Utilisez les nombres de tokens dans response.usage et les tarifs par million de tokens du modèle.
• Utilisez le tableau de bord de mise en cache des prompts. Surveillez les taux de succès du cache dans le tableau de bord de mise en cache des prompts.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18function calculateInputCost(
  usage,
  inputPricePerMillion,
  cacheInputMultiplier = 0.1,
  cacheWriteMultiplier = 1.25
) {
  const inputTokens = usage.input_tokens;
  const cachedTokens = usage.input_tokens_details.cached_tokens;
  const cacheWriteTokens = usage.input_tokens_details.cache_write_tokens;
  const ordinaryInputTokens = inputTokens - cachedTokens - cacheWriteTokens;

  const weightedInputTokens =
    ordinaryInputTokens +
    cachedTokens * cacheInputMultiplier +
    cacheWriteTokens * cacheWriteMultiplier;
  const inputCost = (weightedInputTokens * inputPricePerMillion) / 1_000_000;
  return inputCost;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21from openai.types.responses import ResponseUsage


def calculate_input_cost(
    usage: ResponseUsage,
    input_price_per_million: float,
    cache_input_multiplier: float = 0.1,
    cache_write_multiplier: float = 1.25,
) -> float:
    input_tokens = usage.input_tokens
    cached_tokens = usage.input_tokens_details.cached_tokens
    cache_write_tokens = usage.input_tokens_details.cache_write_tokens
    ordinary_input_tokens = input_tokens - cached_tokens - cache_write_tokens

    weighted_input_tokens = (
        ordinary_input_tokens
        + cached_tokens * cache_input_multiplier
        + cache_write_tokens * cache_write_multiplier
    )
    input_cost = weighted_input_tokens * input_price_per_million / 1_000_000
    return input_cost

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17def calculate_input_cost(
  usage,
  input_price_per_million,
  cache_input_multiplier = 0.1,
  cache_write_multiplier = 1.25
)
  input_tokens = usage.input_tokens
  details = usage.input_tokens_details
  cached_tokens = details.cached_tokens
  cache_write_tokens = details.cache_write_tokens
  ordinary_input_tokens = input_tokens - cached_tokens - cache_write_tokens

  weighted_input_tokens = ordinary_input_tokens +
                          (cached_tokens * cache_input_multiplier) +
                          (cache_write_tokens * cache_write_multiplier)
  (weighted_input_tokens * input_price_per_million) / 1_000_000
end

• Conservez les préfixes stables existants.
• Si vous utilisez prompt_cache_key, conservez les valeurs existantes pour maintenir une comptabilisation distincte de l’utilisation du cache par client ou utilisateur.
• Remplacez prompt_cache_retention par prompt_cache_options.ttl.
• Vérifiez que les préfixes réutilisables atteignent la longueur minimale permettant la mise en cache du modèle.
• Si le point d’arrêt par défaut inclut du contenu qui change d’une requête à l’autre, ajoutez un point d’arrêt explicite après le préfixe stable.
• Utilisez prompt_cache_options.mode: "explicit" lorsque le contenu qui suit ne mérite pas d’être écrit dans le cache.
• Comparez cached_tokens, cache_write_tokens, la latence et le coût total avant et après la migration.

Prenons un LLM utilisé comme juge en un seul tour pour déterminer si une interaction terminée avec un chatbot présente des signes de satisfaction de l’utilisateur. Chaque requête utilise la même grille d’évaluation et les mêmes exemples few-shot étiquetés pour évaluer une interaction différente.

• Préservation du préfixe : La grille fixe et les exemples sont placés en premier. Leur longueur cumulée est volontairement maintenue juste au-dessus de la longueur minimale permettant la mise en cache du modèle, à l’aide de contenu qui contribue à calibrer le juge. L’interaction à évaluer est placée en dernier.
• Mode de mise en cache et point d’arrêt : La mise en cache exclusivement explicite est activée, avec un point d’arrêt après la grille fixe et les exemples. La conversation entre l’utilisateur et le chatbot à évaluer est placée après ce point d’arrêt et n’est pas écrite dans le cache. Cela évite de facturer une écriture dans le cache pour du contenu peu susceptible d’être réutilisé.

Un exemple de déploiement appliquant ces principes a enregistré un taux de succès du cache en tokens d’environ 70 %. Ce chiffre illustre un résultat possible. Les taux de succès maximaux réellement atteignables dépendront de votre contexte et de l’utilisation de votre application.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Judge whether the completed interaction provides evidence that the user is satisfied. Return true or false. Full grading rubric and labeled few-shot examples...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    {
      "role": "user",
      "content": "Completed interaction to evaluate..."
    }
  ]
}

Prenons un agent à plusieurs tours avec de longues instructions développeur partagées et des appels d’outils fréquents. Dans un usage typique, les utilisateurs exécutent plusieurs sessions simultanément avec l’agent et forkent souvent les fils de discussion.

• Préservation du préfixe : chaque tour ajoute de nouveaux messages, appels d’outils et résultats sans réécrire le contexte antérieur. Le préfixe réutilisable s’allonge donc au fil du temps.
• Clé de cache des prompts facultative : Cet exemple utilise agent_123_v1:user_456 pour comptabiliser séparément l’utilisation du cache de l’utilisateur 456, ce qui facilite l’explication de sa consommation de tokens lus depuis le cache et de sa facturation. Cela aide aussi à empêcher un utilisateur de sonder les succès du cache d’autres utilisateurs. La clé reste identique pour toutes les sessions et tous les forks de cet utilisateur avec l’agent. Omettez-la si votre application n’a pas besoin de cette séparation.
• Mode de mise en cache implicite : La mise en cache implicite est activée afin que le dernier message utilisateur ou d’outil admissible fournisse un point d’arrêt.
• Points d’arrêt explicites : Un point d’arrêt est ajouté après chaque résultat d’outil pour préserver les préfixes réutilisables antérieurs et améliorer l’efficacité du cache lors de la création de forks.

Un exemple de déploiement appliquant ces principes a enregistré un taux de succès du cache en tokens >90 %. Ce chiffre illustre un résultat possible. Les taux de succès maximaux réellement atteignables dépendront de votre contexte et de l’utilisation de votre application.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "medium" },
  "prompt_cache_key": "agent_123_v1:user_456",
  "prompt_cache_options": { "mode": "implicit" },
  "tools": [
    {
      "type": "function",
      "name": "function_name",
      "description": "Function description",
      "parameters": { "...": "..." }
    }
  ],
  "input": [
    {
      "role": "developer",
      "content": "Stable developer instructions and reference material..."
    },
    { "role": "user", "content": "Can you do...?" },
    {
      "type": "function_call",
      "call_id": "call_123",
      "name": "function_name",
      "arguments": "..."
    },
    {
      "type": "function_call_output",
      "call_id": "call_123",
      "output": [
        {
          "type": "input_text",
          "text": "Tool result...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "assistant", "content": "Assistant response..." },
    { "role": "user", "content": "Can you also do...?" }
  ]
}

Ce problème est particulièrement fréquent lors de la migration de modèles antérieurs vers GPT-5.6 ou une version ultérieure, en raison du changement de comportement de la mise en cache implicite. Si des requêtes partagent un long préfixe mais ont des suffixes différents, la mise en cache de la première requête complète en mode uniquement implicite ne rend pas réutilisable le préfixe commun plus court.

Prenons des requêtes contenant chacune un message développeur statique suivi d’un message utilisateur dynamique. Une telle requête écrit dans le cache jusqu’à la fin du contenu dynamique. Si ce contenu change dans la requête suivante, celle-ci ne correspond plus au long préfixe mis en cache, et aucun point de rupture distinct ne marque la fin du contenu statique.

1
2
3
4
5
6
7
8
9
10{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "implicit" },
  "input": [
    { "role": "developer", "content": "Static content..." },
    { "role": "user", "content": "Dynamic content..." }
  ]
}

Pour y remédier, placez un point de rupture explicite après le contenu statique dans les deux requêtes. La première requête écrit le préfixe réutilisable dans le cache ; la suivante peut le réutiliser même si le contenu dynamique change. Cet exemple utilise le mode uniquement explicite pour éviter d’écrire le contenu dynamique dans le cache.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "Static content...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "Dynamic content..." }
  ]
}

Supposons que la requête 1 utilise le mode implicite et mette en cache un préfixe allant jusqu’à la fin d’un message utilisateur, puis que la requête 2 conserve ce préfixe mais passe à prompt_cache_options.mode: "explicit". Comme l’explique la section Fonctionnement de la correspondance des préfixes, la requête 2 vérifie uniquement les points de rupture explicites de sa propre entrée. Elle ne réutilisera donc pas le préfixe implicite enregistré par la requête 1, sauf si l’un de ses points de rupture explicites correspond à la fin du préfixe mis en cache par la requête 1.

▼ = breakpoint

- Request 1: implicit mode
  [Developer message][User message] ▼

- Request 2: explicit-only mode. Does not hit cache.
  [Developer message][User message][Follow-up] ▼

Pour réutiliser le préfixe implicite de la requête 1, placez un point de rupture explicite à la limite du bloc de contenu correspondant dans la requête 2, ou gardez le mode implicite activé pour que la fin du message admissible précédent reste une borne de recherche possible.

Même lorsque les deux requêtes utilisent le mode implicite, conserver les mêmes tokens initiaux ne suffit pas toujours. Supposons que la requête 1 se termine par un message utilisateur contenant Content A, puis que la requête 2 prolonge ce même message pour qu’il contienne Content A + Content B. L’ancienne limite située après Content A se trouve désormais à l’intérieur d’un message, et non à sa fin. Comme l’explique la section Fonctionnement de la correspondance des préfixes, sans point de rupture explicite à cette limite, la requête 2 ne réutilise pas le préfixe enregistré à cet endroit.

▼ = breakpoint

- Request 1: implicit mode
  [Developer message][User message: Content A] ▼

- Request 2: implicit mode. Cannot reuse the prefix through Content A.
  [Developer message][User message: Content A + Content B] ▼

Lorsque la structure de la conversation le permet, conservez le message d’origine et ajoutez plutôt un nouveau message à la suite. Sinon, gardez le texte réutilisable dans un bloc de contenu distinct et placez un point de rupture explicite après ce bloc dans les deux requêtes.

En mode implicite, les messages développeur situés après le bloc initial de messages développeur consécutifs ne servent pas automatiquement de bornes de recherche dans le cache. Ajoutez un point de rupture explicite à la fin du message développeur réutilisable et conservez-le dans les requêtes suivantes pour qu’OpenAI puisse rechercher un préfixe correspondant dans le cache.

Un préfixe pouvant être mis en cache avec un modèle peut être trop court avec un autre. Consultez le comparatif des modèles et mesurez le préfixe réutilisable avec le modèle et les paramètres que vous utilisez réellement. Lorsque vous changez de modèle, répétez cette vérification au lieu de supposer que le seuil du modèle précédent s’applique toujours.

Le compactage remplace le contexte antérieur de la conversation par une représentation plus courte. Cela peut modifier le préfixe : la première requête après le compactage peut donc réutiliser une plus petite partie du cache précédent, même si la conversation reste logiquement identique.

Gardez les instructions réutilisables et les documents de référence inchangés dans la mesure du possible, puis laissez les tours suivants s’appuyer sur le contexte compacté. Comparez le coût total des entrées avant et après le compactage : réduire le nombre de tokens d’entrée peut permettre des économies même si le taux de succès du cache diminue.

Non. La mise en cache des prompts ne change pas la façon dont le modèle génère les tokens de sortie. Le modèle génère une nouvelle réponse à partir du préfixe mis en cache : des requêtes identiques ne produisent donc pas nécessairement des sorties identiques.

Non. Il n’est actuellement pas possible de vider le cache manuellement. Les entrées du cache expirent en fonction de la durée de vie du cache et des paramètres de conservation du modèle.

Oui. Les tokens d’entrée mis en cache restent pris en compte dans les limites de tokens par minute. La mise en cache des prompts ne change pas le calcul des limites de débit.