Optimiser le taux de cache

Structurer vos prompts pour le cache

Le cache de l’API Grok fonctionne par correspondance de préfixe. Les tokens sont mis en cache dans l’ordre, du premier vers le dernier, et la correspondance s’arrête au premier caractère qui diffère. La conséquence est brutale : modifiez un token au milieu de votre prompt, et tout ce qui suit perd son cache, même si le reste est identique au mot près. Un horodatage de vingt caractères en tête de prompt suffit à faire payer le tarif plein sur les 50 000 tokens qui viennent derrière. Structurer ses prompts n’est donc pas une coquetterie d’ingénieur, c’est ce qui sépare une facture de $200 d’une facture de $1 000 pour le même service rendu.

La règle d’or : ne pas modifier l’historique

Le piège le plus courant en production consiste à retoucher l’historique des messages entre deux requêtes. Reformater un message précédent, réordonner les tours, injecter une date courante ou un identifiant de session dans le prompt système : chacun de ces gestes, anodin en apparence, invalide le cache à partir du point modifié. Le cas le plus répandu tient en une ligne de code :

# MAUVAIS : horodatage dans le system prompt
messages = [
    {"role": "system", "content": f"Date: {datetime.now()}. Vous etes un assistant."},
    # ...
]

Ce timestamp change à chaque appel. Comme il se trouve dans le tout premier message, la correspondance de préfixe échoue dès le premier token et l’intégralité du prompt est facturée au tarif standard, conversation après conversation. Si votre modèle a réellement besoin de connaître la date, placez-la dans le dernier message utilisateur, là où elle ne coûte que quelques dizaines de tokens non cachés.

La version saine du même prompt garde un en-tête strictement figé, un historique en ajout seul, et concentre toute la nouveauté à la fin :

# BON : contenu statique en premier, variables a la fin
messages = [
    {"role": "system", "content": "Vous êtes un assistant spécialisé en support client."},
    # Historique de conversation INCHANGÉ
    {"role": "user", "content": "Question precedente..."},
    {"role": "assistant", "content": "Réponse precedente..."},
    # Seul le dernier message est nouveau
    {"role": "user", "content": "Nouvelle question de l'utilisateur"}
]

Une architecture de prompt qui se cache bien

Le principe tient en une phrase : du plus stable au plus variable. Concrètement, quatre couches se succèdent dans cet ordre.

1. System prompt (stable) : instructions générales, persona, règles
2. Contexte de référence (stable) : documentation, base de connaissances
3. Historique de conversation (incrémental) : ajout uniquement, jamais de modification
4. Message courant (variable) : la nouvelle requête de l’utilisateur

Avec cette disposition, les couches 1 à 3 tombent dans le cache et seule la couche 4 est facturée au tarif standard. Sur une application dont le prompt système et le référentiel pèsent 8 000 tokens, une question utilisateur de 60 tokens ne fait payer que ces 60 tokens au tarif plein.

Cette logique se prolonge sur des cas moins évidents. Si votre application repose sur un long contexte de référence — documentation produit, FAQ, spécifications techniques — placez-le juste après le prompt système : il sera caché dès la deuxième requête de chaque conversation. Et contrairement à ce qu’on suppose souvent, le bénéfice n’est pas confiné à une seule session : deux conversations distinctes qui partagent le même préfixe, même prompt système et même contexte de référence, se cachent mutuellement. Dans une application multi-utilisateurs à prompt commun, chaque utilisateur profite du trafic des autres, ce qui rend un prompt système long et stable bien moins coûteux qu’il n’y paraît.

Le réflexe qui casse tout : tronquer l’historique

Quand une conversation s’allonge et approche de la limite de contexte, l’instinct est de couper les premiers messages. C’est exactement ce qu’il ne faut pas faire : en supprimant le début, vous déplacez tout le reste et détruisez la correspondance de préfixe. Vous économisez quelques milliers de tokens et vous en repayez cinquante mille au tarif plein. Préférez le résumé, qui condense les anciens échanges dans un prompt système réécrit une seule fois, en laissant intacts les messages récents :

# Au lieu de tronquer l'historique :
# messages = messages[-10:]  # MAUVAIS: casse le cache

# Résumez les anciens messages dans le system prompt :
messages = [
    {"role": "system", "content": "Instructions... Resume des échanges précédents: ..."},
    # Messages recents non modifies
    {"role": "user", "content": "..."},
    {"role": "assistant", "content": "..."},
    {"role": "user", "content": "Nouvelle question"}
]

Mesurer et améliorer

Suivez le taux de cache quotidien comme un indicateur de production à part entière, au même titre qu’un taux d’erreur. Voici comment interpréter la valeur que vous relevez.

L’intérêt de ce suivi est surtout différentiel. Une valeur stable à 65 % qui tombe à 20 % du jour au lendemain vous désigne le déploiement fautif à quelques heures près : dans la quasi-totalité des cas, une variable vient d’être introduite en tête de prompt. Testez-le vous-même sur votre application actuelle — relevez le taux moyen sur cent requêtes, déplacez un élément variable vers la fin du prompt, et comparez.

Points clés à retenir

• Le cache fonctionne par correspondance de préfixe : ne modifiez jamais les tokens en début de prompt
• Structurez vos prompts du plus stable au plus variable
• N’ajoutez jamais de données variables (horodatage, identifiants) dans le system prompt
• Préférez le résumé à la troncature pour conserver le cache des conversations longues
• Surveillez votre taux de cache quotidien comme indicateur de performance financière