Comment la mise en cache des prompts réduit-elle les coûts d’API?

La plupart des applications d’IA envoient le même texte encore et encore. Un robot d’aide à la clientèle envoie ses consignes complètes et une page de politiques avec chaque question. Un outil qui répond à des questions sur un contrat envoie tout le contrat chaque fois. Vous payez ces jetons d’entrée (les petits morceaux de texte que les API comptent et facturent) à chaque appel, même si rien n’y a changé.

La mise en cache des prompts (prompt caching) élimine ce gaspillage. Le fournisseur garde pendant quelques minutes la version traitée du début de votre prompt. Quand votre requête suivante commence exactement par le même texte, il réutilise ce travail au lieu de le refaire, et vous facture moins cher ces jetons. Les réponses ont aussi tendance à arriver plus vite. Les réponses elles-mêmes ne sont pas touchées : la mise en cache change la facture et la vitesse, pas ce que le modèle écrit.

Deux fournisseurs, deux approches

Anthropic a ouvert la mise en cache des prompts sur son API en bêta publique le 14 août 2024, pour deux modèles : Claude 3.5 Sonnet et le plus petit Claude 3 Haiku. Elle est facultative : vous indiquez où se termine la partie réutilisable de votre prompt avec un paramètre cache_control. Le premier appel qui stocke cette partie (une « écriture en cache ») coûte 25 % de plus que l’entrée normale. Chaque appel suivant qui la réutilise (une « lecture en cache ») ne coûte que 10 % du prix normal d’entrée. Le cache dure environ cinq minutes, et chaque utilisation remet ce compteur à zéro.

OpenAI a suivi le 1er octobre 2024. Sa version est automatique et ne demande aucune modification du code. Sur les versions récentes de GPT-4o et de GPT-4o mini, ainsi que sur les modèles de raisonnement o1-preview et o1-mini, tout prompt de plus de 1 024 jetons peut être mis en cache, et les jetons d’ouverture répétés sont facturés moitié prix. Les caches se vident habituellement après 5 à 10 minutes d’inactivité, et toujours en moins d’une heure.

Un exemple de coûts concret

Imaginez un robot de soutien technique pour une petite entreprise de logiciels. Son prompt système (les consignes fixes qui définissent le rôle et les règles du modèle) fait 3 000 jetons : lignes directrices sur le ton, renseignements sur les produits et une série d’exemples de réponses. Chaque question d’un client ajoute environ 200 jetons. Lors d’une journée chargée, le robot répond à 1 000 questions, assez rapprochées pour que le cache reste actif. Les chiffres ci-dessous sont donnés à titre d’exemple et ne comptent que l’entrée, puisque les prix de sortie ne changent pas.

Claude 3.5 Sonnet sans mise en cache : 1 000 appels × 3 200 jetons = 3,2 millions de jetons à 3,00 $ US = 9,60 $ US.

Claude 3.5 Sonnet avec mise en cache :

• Une écriture en cache : 3 000 jetons à 3,75 $ US par million = environ 0,01 $ US
• 999 lectures en cache : 2 997 000 jetons à 0,30 $ US par million = environ 0,90 $ US
• Les questions, qui changent : 200 000 jetons à 3,00 $ US par million = 0,60 $ US
• Total : environ 1,51 $ US, soit à peu près 84 % de moins.

GPT-4o avec mise en cache automatique : OpenAI met en cache par tranches de 128 jetons; environ 2 944 des 3 000 jetons fixes comptent donc comme mis en cache à chaque répétition. Cela donne environ 2,94 millions de jetons en cache à 1,25 $ US (environ 3,68 $ US) et 0,26 million de jetons à plein tarif à 2,50 $ US (environ 0,65 $ US), pour à peu près 4,32 $ US au lieu de 8,00 $ US.

La règle vaut en général : plus la partie fixe est longue et stable, et plus elle se répète souvent en quelques minutes, plus l’économie est grande. Un court prompt de moins de 1 024 jetons n’obtient aucun rabais.

Voici la version Claude en Python, avec l’assistant bêta de la bibliothèque anthropic, qui envoie pour vous l’en-tête bêta requis. Le texte du soutien technique est un espace réservé.

import anthropic

client = anthropic.Anthropic()  # lit ANTHROPIC_API_KEY dans l’environnement
HELP_DESK_RULES = open("help_desk_rules.txt").read()  # la partie fixe de 3 000 jetons

response = client.beta.prompt_caching.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[
        {
            "type": "text",
            "text": HELP_DESK_RULES,
            "cache_control": {"type": "ephemeral"},  # met en cache tout ce qui précède
        }
    ],
    messages=[{"role": "user", "content": "Comment réinitialiser mon mot de passe?"}],
)
print(response.usage)

L’affichage de usage vous dit ce qui s’est passé. Au premier appel, cache_creation_input_tokens indique les jetons écrits dans le cache. À l’appel suivant, dans les cinq minutes, cache_read_input_tokens indique les jetons servis à partir du cache. Avec OpenAI, cherchez cached_tokens dans prompt_tokens_details, dans le champ d’utilisation.

Comment structurer vos prompts pour profiter du cache?

Mettez ce qui ne change jamais en premier et ce qui change toujours en dernier. Les deux fournisseurs mettent en cache à partir du tout début du prompt : pour profiter du cache, le début doit correspondre exactement, caractère pour caractère. Un bon ordre : les définitions d’outils, puis le prompt système, puis les longs documents de référence et les exemples, puis la conversation et, enfin, la nouvelle question. La documentation d’Anthropic décrit le même ordre : outils, système, puis messages.

Gardez tout ce qui varie hors de la partie fixe. Une erreur courante consiste à commencer le prompt système par la date du jour, le nom de l’utilisateur ou un numéro de demande. Cette seule ligne changeante au début brise la correspondance pour tout ce qui suit. Déplacez ces détails à la fin, à côté de la question de l’utilisateur.

Envoyez les requêtes apparentées rapprochées dans le temps. Un cache qui reste inutilisé plus de cinq minutes environ disparaît, et l’appel suivant paie le plein tarif (ou, avec Claude, le prix d’écriture, légèrement plus élevé). Un trafic régulier le garde actif; une requête par heure n’en profitera pas.

Enfin, vérifiez au lieu de supposer. Surveillez les champs de cache dans les données d’utilisation pendant une journée. Si les lectures restent à zéro, quelque chose dans votre texte d’ouverture change d’un appel à l’autre, et comparer deux requêtes brutes côte à côte le révèle habituellement.