Qu'est-ce que le cache de prompt ? Comment un prompt répété est réutilisé

Le cache de prompt signifie que l'API mémorise le début de votre requête et le réutilise la prochaine fois que vous envoyez le même début. Vous envoyez toujours le texte complet à chaque appel, mais le fournisseur peut éviter de relire la partie répétée, et certains fournisseurs facturent cette partie à un tarif réduit. Cela ne fonctionne que sur le début de la requête, et uniquement si ce début est identique.

Le bot de support qui relit sans cesse la même page#

Imaginez un bot de support qui traite 2 000 tickets par jour. Chaque requête commence par les mêmes 3 000 tokens : ton de voix, règles de remboursement, politique d'expédition. Vient ensuite le message du client sur une ligne, du genre « Où est ma commande ? » (Si les tokens restent flous, commencez par qu'est-ce qu'un token.)

Sans cache, le fournisseur relit les 3 000 tokens de règles pour le ticket numéro 1, le ticket numéro 2 et le ticket numéro 2 000. La même page, lue 2 000 fois. Avec le cache, la première requête paie le prix plein de cette lecture, et les requêtes suivantes qui commencent par le même texte peuvent réutiliser le travail.

Le guide de l'API DeepSeek (vérifié le 24 octobre 2026) décrit exactement cela : le cache de contexte est activé par défaut, ne nécessite aucune modification de code, et une requête ultérieure avec un préfixe qui se recoupe compte comme un « cache hit ». Seule l'entrée est mise en cache. La réponse est générée à nouveau à chaque fois.

Ce qui compte comme « le même » : la règle du préfixe#

Le cache fait correspondre à partir du premier caractère. Dès que votre requête diffère de celle mise en cache, tout ce qui suit ce point est nouveau. C'est pourquoi l'ordre de votre requête compte plus que sa longueur.

Voici l'erreur qui tue discrètement le cache. Un développeur veut que le bot connaisse l'heure et la place en tête :

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

L'heure change chaque seconde, donc la toute première ligne diffère à chaque requête, et rien de ce qui suit ne peut correspondre. La solution est de déplacer ce qui change à la fin :

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

Maintenant les 3 000 tokens de règles viennent en premier et restent identiques. La même logique couvre les deux autres cas courants : une longue conversation renvoie tout son historique à chaque tour, donc les anciens messages constituent un début répétitif tout prêt (voir pourquoi une longue conversation coûte plus cher), et un agent répète ses définitions d'outils et ses instructions à chaque étape.

Le cache est aussi du meilleur effort. DeepSeek indique que le cache met quelques secondes à se construire, qu'un hit nécessite une correspondance complète avec une unité de préfixe de cache existante, qu'aucun taux de hit n'est garanti, et que les caches inutilisés sont purgés, généralement en quelques heures à quelques jours. Ainsi, une deuxième requête lancée une demi-seconde après la première peut ne pas encore toucher le cache, et le hit peut couvrir moins que tout votre préfixe.

Comment le voir : les champs de cache dans usage#

Pas besoin de deviner si cela a fonctionné. Chaque fournisseur le rapporte dans la partie usage de la réponse, sous ses propres noms de champs.

DeepSeek utilise deux champs :

• prompt_cache_hit_tokens — tokens d'entrée trouvés dans le cache
• prompt_cache_miss_tokens — tokens d'entrée qui ne l'étaient pas

Supposons que votre premier ticket de support revienne avec prompt_cache_hit_tokens: 0 et prompt_cache_miss_tokens: 3200, et qu'un ticket une minute plus tard affiche prompt_cache_hit_tokens: 3000 et prompt_cache_miss_tokens: 200. Les 3 000 tokens de règles ont été réutilisés ; seuls le nouveau message client et quelques tokens ont été lus de zéro. Si le nombre de hits reste à zéro à chaque appel, regardez le début de votre requête : quelque chose y change.

Anthropic fonctionne différemment, car vous marquez ce qu'il faut mettre en cache. Vous ajoutez cache_control avec le type ephemeral à la requête ou à un bloc de contenu :

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Selon la documentation d'Anthropic sur le cache de prompt (vérifiée le 24 octobre 2026), la réponse rapporte trois nombres : cache_creation_input_tokens (écrit dans le cache maintenant), cache_read_input_tokens (lu depuis celui-ci), et input_tokens (ce qui vient après le dernier point de rupture de cache). Supposons que le premier appel affiche cache_creation_input_tokens: 10000, cache_read_input_tokens: 0 ; le second affiche 0 et 10000. C'est une écriture de cache suivie d'une lecture de cache.

Il y a un piège à l'écran. Les prompts plus courts que le minimum du modèle (512, 1 024 ou 4 096 tokens, selon le modèle) sont traités sans mise en cache et sans erreur. Vous verrez des zéros dans les deux champs de cache et aucun avertissement. La durée de vie par défaut est de 5 minutes, rafraîchie gratuitement à chaque utilisation ; un ttl optionnel de 1h la prolonge.

Ce que cela fait à votre facture#

Le cache modifie le prix de la partie répétée, donc cela vaut la peine de compter une fois. Anthropic liste des multiplicateurs sur le prix d'entrée de base : une écriture de cache avec la durée de vie de 5 minutes coûte 1,25×, une lecture coûte 0,1× (0,05× pour Opus 5.5 et Sonnet 5.5). Prenons un préfixe de 10 000 tokens réutilisé dans 20 requêtes dans la fenêtre de 5 minutes, avec la lecture standard à 0,1× :

10 000 × 20 = 200 000 tokens au prix de base sans cache

10 000 × 1,25 = 12 500 pour la première requête qui écrit le cache

19 × 10 000 × 0,1 = 19 000 pour les 19 requêtes qui le lisent

12 500 + 19 000 = 31 500 équivalents-tokens avec cache

Ainsi, la partie répétée coûte bien moins d'un cinquième du montant sans cache. Le piège : si les 5 minutes s'écoulent entre les requêtes, la suivante réécrit le cache à 1,25×, et un préfixe rarement utilisé peut finir par coûter plus cher que sans cache.

Maintenant le bot du début, comme référence simple au prix plein. 2 000 requêtes par jour, 3 000 tokens d'entrée et environ 300 tokens de sortie chacune :

2 000 × 3 000 = 6 000 000 tokens d'entrée par jour

2 000 × 300 = 600 000 tokens de sortie par jour

Le tableau chiffre la charge de travail de cette journée sur chaque modèle CheapTokens disponible, à côté d'OpenRouter :

DeepSeek-V4-Flash est moins cher qu'OpenRouter au total, entrée et sortie comptées ensemble, et la charge de travail tient facilement : 380K de contexte et jusqu'à 32 768 tokens de sortie par réponse. C'est le coût au prix plein de la charge de travail : tokens d'entrée × prix par token. C'est sur un long préfixe stable que cette part d'entrée est la plus importante.

Essayez vous-même en cinq minutes#

Le plan : envoyer deux fois le même long prompt système avec des questions différentes et regarder usage. Mettez votre propre texte de règles dans support_rules.txt (une page ou deux de texte suffisent). Le point de terminaison est l'API CheapTokens compatible OpenAI, et vous pouvez prendre la clé depuis votre compte.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

Ce qu'il faut vérifier dans la sortie : prompt_tokens vous indique la taille de votre requête. Les deux requêtes portent le même texte SYSTEM, donc la majeure partie de ce nombre se répète d'une requête à l'autre — approximativement la taille de votre fichier de règles. Ce début répété est la partie qu'un fournisseur avec cache, comme l'API DeepSeek ou Anthropic ci-dessus, peut réutiliser. Maintenant un exercice sur l'ordre : ajoutez une ligne avec l'heure actuelle (datetime.now()) en tête de SYSTEM et relancez. Les deux requêtes ne partagent plus de début, car elles diffèrent dès la toute première ligne. Placez la même ligne à la fin du prompt et le début partagé revient.

Une courte liste de vérification pour vos propres prompts :

1. Texte stable en premier : instructions, règles, définitions d'outils, exemples.
2. Texte changeant en dernier : date, nom d'utilisateur, dernier message.
3. Gardez le préfixe identique octet pour octet — même un espace supplémentaire compte.
4. Vérifiez la taille minimale du fournisseur avant de vous demander pourquoi rien n'est mis en cache.
5. Regardez les champs d'usage après un changement, pas avant.

Pour chiffrer votre propre charge de travail, ouvrez la page de tarifs et saisissez vos tailles d'entrée et de sortie, ou partez de la page DeepSeek. Une fois la première requête fonctionnelle, la même estimation prend une minute pour n'importe quel prompt que vous écrivez. Pour ce que coûtent les deux côtés d'une requête, voir tokens d'entrée vs de sortie.