Prompt caching en pratique : implementation pas a pas

Maintenant que vous connaissez la theorie, voyons comment implementer concretement le prompt caching dans vos applications. L’objectif : rendre vos requetes API plus rapides et moins couteuses quand vous envoyez repetivement le meme contenu.

Rappel du fonctionnement

Quand vous activez le caching :

1. La premiere requete ecrit le contenu dans un cache qui vit 1 heure
2. Les requetes suivantes lisent depuis ce cache au lieu de tout retraiter

C’est particulierement rentable quand vous envoyez :

• Un prompt systeme long (par exemple 6000 tokens pour un assistant de code)
• Des schemas d’outils complexes (environ 1700 tokens pour plusieurs outils)
• Du contenu de messages repete

Mettre en cache les schemas d’outils

Pour cacher vos schemas d’outils, ajoutez le champ cache_control au dernier outil de votre liste. Voici la bonne facon de le faire sans modifier vos definitions originales :

if tools:
    # Creer des copies pour ne pas modifier les originaux
    tools_clone = tools.copy()
    last_tool = tools_clone[-1].copy()
    last_tool["cache_control"] = {"type": "ephemeral"}
    tools_clone[-1] = last_tool
    params["tools"] = tools_clone

Pourquoi faire des copies ? Si vous modifiez directement tools[-1]["cache_control"], vous risquez des problemes en cas de reordonnancement ulterieur de vos outils. La copie est une precaution simple et efficace.

Mettre en cache le prompt systeme

Pour le prompt systeme, il faut le transformer en bloc structure avec le champ cache_control :

if system:
    params["system"] = [
        {
            "type": "text",
            "text": system,
            "cache_control": {"type": "ephemeral"}
        }
    ]

On passe d’une simple chaine de caracteres a un format structure qui supporte le caching.

Comprendre le comportement du cache

Quand vous executez des requetes avec le caching active, les metriques d’utilisation dans la reponse vous indiquent ce qui se passe :

Le cache est extremement sensible : changer ne serait-ce qu’un seul caractere dans vos outils ou votre prompt systeme invalide tout le cache pour ce composant.

Ordre du cache et breakpoints multiples

Vous pouvez definir plusieurs breakpoints dans une meme requete. L’ordre de traitement est important :

1. Outils (si fournis)
2. Prompt systeme (si fourni)
3. Messages

Consequence pratique : si vous changez votre prompt systeme mais gardez les memes outils, vous verrez une lecture partielle du cache (pour les outils) et une ecriture (pour le nouveau prompt systeme). Ce caching granulaire signifie que vous ne payez le retraitement que pour les parties qui ont reellement change.

Considerations pratiques

Le prompt caching est le plus efficace quand vous avez :

• Des schemas d’outils stables entre les requetes
• Des prompts systeme constants
• Des applications qui font de nombreuses requetes avec un contexte similaire

N’oubliez pas que le cache ne dure qu’une heure : c’est concu pour des applications avec une utilisation API relativement frequente, pas pour du stockage a long terme.

Exercice : implementer le caching

Prenez une de vos applications existantes qui utilise l’API Claude et :

1. Identifiez les parties du prompt qui restent identiques entre les requetes (prompt systeme, outils)
2. Ajoutez les cache_control breakpoints aux endroits strategiques
3. Comparez les metriques cache_creation_input_tokens vs cache_read_input_tokens dans les reponses successives
4. Mesurez l’amelioration du temps de reponse et du cout