Aller au contenu

Trouver le défaut de cache derrière votre facture OpenAI

Mis à jour September 26, 2026 · première publication September 26, 2026

Réponse rapide: Un tableau de bord du cache de prompts peut vous dire que la réutilisation a chuté. Il ne peut pas, à lui seul, vous dire quel changement de requête a provoqué la chute ni combien elle a coûté. La...

Un tableau de bord du cache de prompts peut vous dire que la réutilisation a chuté. Il ne peut pas, à lui seul, vous dire quel changement de requête a provoqué la chute ni combien elle a coûté. La version du 8 septembre 2026 d'OpenAI a rendu Prompt Cache Diagnostics généralement disponible dans la Responses API pour GPT-5.6 et les modèles compatibles ultérieurs. Le bon réflexe FinOps consiste à transformer une baisse de tokens en cache en une enquête courte et reproductible.

Comparez la requête qui a échoué

Enregistrez l'ID d'une réponse récente et terminée dont vous attendiez que le préfixe soit réutilisé. Sur la requête comparable suivante à la Responses API, depuis la même organisation, définissez prompt_cache_options.comparison_response_id avec cet ID. Lisez ensuite prompt_cache_diagnostics dans la nouvelle réponse, avec usage.input_tokens_details.cached_tokens. L'option de comparaison demande un diagnostic ; elle ne charge pas la conversation précédente et ne modifie pas le comportement du cache. Le guide des diagnostics d'OpenAI contient des exemples de requêtes fonctionnels.

const next = await client.responses.create({
  model: model,
  instructions: stableInstructions,
  input: nextInput,
  tools: stableTools,
  prompt_cache_options: { comparison_response_id: baseline.id }
});
console.log(next.prompt_cache_diagnostics);
console.log(next.usage.input_tokens_details.cached_tokens);

L'extrait suppose que baseline est une réponse récente et terminée, et que les autres variables sont les données de votre propre requête. Conservez un préfixe stable assez long pour être mis en cache : OpenAI documente un minimum de 1,024 tokens pour GPT-5.6 et les versions ultérieures. Un prompt court ou radicalement différent n'est pas un test de défaut de cache pertinent.

Corrigez la cause, pas la métrique

Un résultat cache_miss peut pointer vers un changement de modèle, de niveau de service, de définitions ou d'ordre des outils, de clé de cache, de format de réponse, d'effort de raisonnement, de verbosité ou de contexte compacté. Par exemple, le renommage d'un schéma d'outil, d'apparence anodine, peut invalider le préfixe réutilisable. Comparez la configuration de la requête et les premiers octets du prompt, rétablissez la stabilité là où le changement était accidentel, puis relancez la comparaison avec la même référence. OpenAI signale la première cause qu'il trouve : une autre peut donc apparaître après la première correction.

Ne forcez pas un succès si le changement était délibéré. Un autre modèle peut réduire le coût total de la tâche même en perdant la réutilisation du cache ; la compaction peut réduire le contexte futur. Jugez l'ensemble de la requête et de la tâche, pas le pourcentage de succès du cache isolément. Une référence expirée ou un résultat unavailable est non concluant, et ne prouve pas que le cache a échoué.

Traduisez le constat en argent

cache_missed_tokens estime les tokens réutilisables perdus par rapport à la réponse de comparaison. Ce n'est pas un nombre de tokens facturés. De même, un résultat cache_hit n'établit pas d'économie en dollars. Pour le coût d'entrée réalisé, collectez le total de input_tokens, cached_tokens et cache_write_tokens de chaque réponse, puis appliquez le tarif en vigueur pour ce modèle et ce niveau de traitement. Pour GPT-5.6 et les versions ultérieures, le guide du prompt caching d'OpenAI indique que les lectures de cache coûtent 0.1 fois le tarif d'entrée hors cache et les écritures de cache 1.25 fois ce tarif.

ordinary = input_tokens - cached_tokens - cache_write_tokens
weighted_input = ordinary + 0.1 * cached_tokens + 1.25 * cache_write_tokens
input_cost = weighted_input * input_price_per_million / 1_000_000

Ces catégories de tokens sont exclusives : n'ajoutez pas de surcoût d'écriture de cache à des tokens déjà comptés au tarif d'écriture. Cette formule ne couvre que l'entrée ; incluez la sortie, les outils, les nouvelles tentatives et les autres frais pour calculer le coût par tâche réussie. Utilisez la grille tarifaire actuelle du fournisseur plutôt qu'un prix figé repris de cet article.

Un contrôle hebdomadaire utile

  1. Regroupez le trafic comparable par charge de travail, modèle et niveau de service ; tracez la part de tokens en cache et le coût d'entrée par tâche terminée.
  2. Échantillonnez une régression soudaine, comparez-la à une référence récente et consignez la raison du diagnostic ainsi que le changement de code responsable.
  3. Corrigez la dérive accidentelle du préfixe ou de la configuration ; conservez les changements volontaires de qualité ou de routage si l'économie globale de la tâche s'améliore.
  4. Validez le résultat sur un trafic de production représentatif et rapprochez les économies observées de la facturation.

Les diagnostics eux-mêmes n'entraînent aucun frais supplémentaire de fonctionnalité, mais les requêtes de test additionnelles sont facturées normalement. L'enjeu n'est pas un joli graphique de taux de succès. C'est une explication défendable de la raison pour laquelle le coût d'entrée d'une charge de travail donnée a changé, et de la capacité de la correction proposée à réduire réellement sa facture.

Questions que se posent les équipes

Un diagnostic cache-hit prouve-t-il qu'une requête a coûté moins cher ?

Non. Il indique qu'aucun défaut n'a été détecté par rapport à la référence choisie. Vérifiez les cached_tokens réels et les catégories de tokens tarifées de la requête avant d'annoncer des économies.

Les diagnostics peuvent-ils comparer deux requêtes OpenAI quelconques ?

Non. Utilisez une référence récente et terminée de la même organisation, et n'attendez ce flux que sur les modèles compatibles de la Responses API à partir de GPT-5.6. Un enregistrement de comparaison peut expirer.

Faut-il supprimer chaque défaut de cache ?

Non. Un changement de modèle, un autre niveau de service ou un contexte compacté peuvent être volontaires. Comparez qualité, latence et coût par tâche réussie avant d'annuler le changement.

À lire aussi


Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit →

Retour à finopsllm.com