Prompt caching en pratique

Les règles sont posées ; cette leçon les transforme en méthode de travail. Le bon réflexe s’installe d’emblée : le cache se vérifie, il ne se suppose pas.

Une méthode en quatre temps

Repérer ce qui se répète : prompt système, définitions d’outils, début de l’historique, documents interrogés plusieurs fois.
Placer les points de cache juste après le contenu stable, avant ce qui change à chaque requête.
Vérifier la longueur minimale : 512 tokens avant chaque point de cache sur Claude Haiku 5.5.
Mesurer : temps de réponse, tokens lus et écrits dans le cache.

Mesurer avec `usage`

D'après la documentation AWS (Prompt caching, API Converse).

Chaque réponse de Converse indique dans usage les tokens écrits dans le cache et lus depuis le cache :

import time


def timed_converse(messages, system):
    start = time.perf_counter()
    response = client.converse(modelId=model_id, messages=messages, system=system)
    usage = response["usage"]
    print(
        f"{time.perf_counter() - start:.2f} s | entrée : {usage['inputTokens']} | "
        f"lus en cache : {usage.get('cacheReadInputTokens', 0)} | "
        f"écrits en cache : {usage.get('cacheWriteInputTokens', 0)}"
    )
    return response


system = [{"text": long_system_prompt}, {"cachePoint": {"type": "default"}}]
for question in ["Résume la politique de remboursement.", "Quels sont les délais de livraison ?"]:
    messages = [{"role": "user", "content": [{"text": question}]}]
    timed_converse(messages, system)

La première requête écrit le prompt système dans le cache ; la seconde, qui commence par le même prompt système, le lit. Les deux champs du cache sont facultatifs dans la réponse, d’où le get(..., 0).

Où le cache paie le plus

Les assistants conversationnels : l’historique grandit à chaque tour, mais son début reste identique.
L’analyse de documents : le même document est interrogé plusieurs fois.
Les outils : les schémas sont renvoyés à chaque requête et ne changent pas.
Les longs prompts système : des consignes détaillées, souvent plusieurs milliers de tokens.

Si vous devez choisir par où commencer : le prompt système et les outils d’abord, parfaitement stables d’une requête à l’autre ; l’historique et les documents ensuite, qui demandent de faire avancer le point de cache au fil de la conversation.

Le symptôme à connaître

Des écritures en cache à chaque requête, sans jamais de lecture, trahissent un contenu qu’on croit stable et qui ne l’est pas : une date, un identifiant de session, un ordre d’outils qui varie. Cherchez ce qui change avant le point de cache. Autre cause fréquente : des requêtes espacées de plus de 5 minutes, qui laissent le cache expirer.

À vous de jouer

Votre tableau de bord. Ajoutez timed_converse à l’assistant de rappels, avec un point de cache après les outils et un autre après le prompt système. Lancez cinq questions à la suite et notez, pour chacune, le temps de réponse et les tokens lus en cache. À partir de quelle requête le cache sert-il ?

Sources officielles : Prompt caching for faster model inference et API Converse (documentation AWS : champs de usage) · Prompt caching (documentation Claude)

Points clés à retenir