Mise en cache des prompts LLM : le guide complet 2026 (réduisez le coût d’entrée de 50 à 90 %)

Si vous développez un chatbot, une application RAG ou un agent IA reposant sur un grand modèle de langage, la mise en cache des prompts est l’optimisation qui permet de réduire le coût d’entrée de 50 à 90 % et le time-to-first-token d’un facteur 3 à 10, sans dégrader la qualité. Ce n’est pas une astuce ajoutée après coup : elle découle directement de la définition de l’attention des Transformers. Une fois ce principe compris, le reste s’enchaîne naturellement : TTL, différences entre fournisseurs et structure des prompts.

TL;DR

• La mise en cache des prompts réduit le coût d’entrée de 50 à 90 % et accélère le time-to-first-token d’un facteur 3 à 10, sans dégrader la qualité.
• Mesures du 2026-05-25 : les marqueurs cache_control de Claude ont réduit le coût d’entrée de 88 à 89 % ; l’auto-cache de GPT-5.4-mini a fait passer le TTFT de 3.6s à 0.73s ; DeepSeek-v4-flash a accordé une remise de 74 % grâce à un cache persistant sur disque.
• Les TTL sont courts parce que l’état KV occupe énormément de mémoire : environ 10 Go pour un contexte de 32K tokens sur un modèle de classe 70B.
• DeepSeek met en cache par blocs de 64 tokens, contre un seuil habituel de 1,024 tokens. Les correspondances partielles de préfixe bénéficient donc elles aussi d’une remise.

Cette page sert d’index à une série de cinq articles. Elle part de la théorie, aboutit à une matrice de décision pour la production, puis descend jusqu’à la couche framework où les prompts sont réellement assemblés. Commencez par la partie adaptée à vos connaissances.

Par où commencer

Chaque partie peut se lire séparément, mais leur ordre permet de construire une vue d’ensemble sans répétitions.

Partie 1 — Fonctionnement de la mise en cache des prompts LLM

Fonctionnement de la mise en cache des prompts LLM : KV cache et TTL expliqués →

L’article consacré à l’architecture. Il présente la self-attention sous la forme d’une seule équation, explique pourquoi les vecteurs K et V d’un préfixe stable sont mathématiquement réutilisables, puis montre comment le compromis entre mémoire et calcul détermine le comportement des TTL que chaque développeur doit prendre en compte.

À retenir :

• La mise en cache des prompts n’est pas une optimisation ajoutée par-dessus le modèle : elle découle directement de l’attention à masque causal. À la position i, K/V est une fonction déterministe des tokens 1…i. Deux préfixes identiques produisent donc des K/V identiques bit à bit.
• Le cache économise le prefill, limité par la puissance de calcul et de complexité O(N²). Le décodage, limité par la bande passante mémoire et de complexité O(N) par token, est déjà optimisé par tous les moteurs d’inférence.
• Les TTL existent parce que le KV cache est immense : ~10 Go pour un contexte de 32K tokens sur un modèle 70B. Cinq minutes correspondent à la limite imposée par la pression sur la mémoire GPU. Des durées de plusieurs heures ou jours ne sont possibles qu’avec un cache persistant sur disque, comme avec l’architecture MLA de DeepSeek.
• La mise en cache réduit à la fois le coût (50 à 90 % de remise sur l’entrée en cas de cache hit) et la latence (TTFT divisé par 3 à 10 pour des prompts de 5 à 10K tokens, et bien davantage au-delà de 100K).

Partie 2 — Comparatif de la mise en cache des prompts LLM selon les fournisseurs

Comparatif de la mise en cache des prompts : Claude, GPT-5, Gemini, DeepSeek et Qwen (2026) →

Le guide de sélection. Cinq fournisseurs proposent cinq approches très différentes : marqueurs explicites avec Claude, fonctionnement entièrement automatique avec GPT-5 et DeepSeek-v4, mode hybride implicite et explicite avec Gemini et Qwen, ou persistance sur disque intégrée à l’architecture MLA de DeepSeek. L’article compare chaque fonctionnalité et propose une grille d’évaluation en 5 dimensions pour noter les fournisseurs selon votre workload.

À retenir :

• Ne comparez pas les tarifs de base. Comparez le coût effectif pondéré par votre taux de cache hit, à l’aide de la formule de la §4.1. Le comparatif des prix des LLM mis à jour en temps réel et le calculateur de coûts permettent de l’appliquer concrètement à votre workload.
• Claude offre la remise la plus élevée sur un appel unique, autour de 90 %, mais impose des marqueurs cache_control explicites.
• DeepSeek-v4 est le seul fournisseur à proposer des caches persistants sur disque à grande échelle. Comme la granularité est de 64 tokens au lieu de 1,024, les correspondances partielles de préfixe bénéficient aussi d’une remise.
• Le cache explicite de Gemini entraîne des frais de stockage horaires. Le seuil de rentabilité dépend de la fréquence des appels.
• À taux de cache hit égal, cinq dimensions différencient réellement les fournisseurs : ergonomie de l’API, prévisibilité du taux de cache hit, adéquation du TTL, latence en cas de cache miss et coût de migration.

Partie 3 — Tutoriel Python fonctionnel

Mise en cache des prompts LLM en Python : tutoriel avec du code fonctionnel →

L’article pratique. Un SDK OpenAI et un SDK Anthropic utilisent la même gateway. Les mesures du 2026-05-25 couvrent toute la gamme Claude, de haiku-4-5 à opus-4-7, ainsi que GPT-5.x, Gemini 2.5, DeepSeek-v4 et Qwen3.

À retenir :

• Claude avec des marqueurs cache_control : les mesures montrent une réduction uniforme des coûts de 88 à 89 % sur les familles haiku/sonnet/opus 4-x. Utilisez le SDK Anthropic avec base_url="https://synthorai.io/".
• Auto-cache de GPT-5.4-mini : TTFT accéléré d’un facteur 5, de 3.6 s à 0.73 s sur un prompt de 7K tokens, avec un taux de cache hit de 93 % sur les tokens système.
• Cache implicite de Gemini 2.5-flash : réduction des coûts de 88 % sur les cache hits lorsque l’usage en streaming est correctement récupéré.
• DeepSeek-v4-flash : remise de 74 % et persistance sur disque, le cache restant disponible après plusieurs heures d’inactivité.
• Patterns adaptés au TTL : heartbeat de maintien en vie pour les tâches cron, règles de stabilité du préfixe et données à journaliser pour chaque appel.

Partie 4 — Meilleur modèle selon le cas d’usage

Meilleur LLM pour le chat, le RAG et les agents : matrice de décision 2026 par modèle et coût →

L’article d’aide à la décision. Chaque workload joue différemment sur les coûts et la latence. Le chat se prête naturellement à la mise en cache. Le RAG se heurte au problème de stabilité du préfixe. Les agents dépendent d’une gestion rigoureuse des préfixes cumulatifs. L’article recommande un modèle selon la forme du workload, avec des estimations de coûts.

À retenir :

• Chatbots : tout modèle avec auto-cache convient, car les sessions génèrent naturellement des cache hits. Choisissez selon le coût et la qualité. gpt-5.4-nano est le moins cher, gpt-5.4-mini offre le TTFT en cache le plus rapide et claude-haiku-4-5 suit le mieux les instructions, moyennant un léger surcoût.
• RAG : réordonner les documents récupérés supprime les cache hits au milieu du prompt. Trois solutions : placer les références à la fin, utiliser un ordre déterministe pour les chunks ou définir plusieurs points d’arrêt cache_control avec Claude.
• Agents : les appels d’outils et leurs résultats doivent être ajoutés uniquement en fin de contexte et rester identiques octet par octet d’une étape à l’autre. claude-sonnet-4-5, avec 4 marqueurs cache_control, offre la meilleure remise sur les préfixes cumulatifs. gpt-5.4-mini fonctionne sans modification du code et réduit les coûts de 50 %.
• Choix du TTL : 5 min pour le chat, 1 heure pour les agents comportant des étapes human-in-the-loop, et cache persistant sur disque pour les batchs sporadiques.

Partie 5 — Intégration avec LangChain

Mise en cache des prompts avec LangChain : les configurations qui touchent réellement le cache →

L’article consacré au framework. Les parties 1 à 4 supposent que vous maîtrisez les octets du prompt. LangChain les assemble à votre place, et sa syntaxe la plus pratique désactive silencieusement le cache de Claude. Les mesures ont été réalisées avec langchain-core 1.4.8 et un préfixe système comportant un marqueur.

À retenir :

• Le template sous forme de tuple de chaînes ("system", "...") ne peut pas transmettre cache_control : les mesures ne montrent aucune activité du cache sur des appels identiques. Il faut utiliser un SystemMessage contenant des blocs de contenu.
• L’ordre du prompt détermine le taux de cache hit. Placer le contexte RAG récupéré avant les règles statiques a transformé chaque appel en écriture à froid. Avec le surcoût d’écriture de Claude, cela coûte plus cher que de ne pas utiliser le cache.
• Un marqueur placé sur le bloc système couvre aussi les outils liés. bind_tools produit une sérialisation stable octet par octet, et un marqueur présent dans un dictionnaire d’outil au format Anthropic est transmis tel quel.
• Agents multi-tours : déplacez le marqueur jusqu’au dernier message. À chaque tour, tout le préfixe précédent est relu et seul le delta est écrit. Mesures : 1,864 en lecture, 15 en écriture.
• Sur les modèles à cache automatique comme GPT, GLM et DeepSeek, un mauvais ordre échoue silencieusement : aucun surcoût, aucune erreur, mais aucune remise. Surveillez les champs d’usage.

Comment lire cette série

• Vous découvrez le sujet en tant qu’ingénieur : lisez les articles dans l’ordre. L’architecture présentée dans la partie 1 permet de comprendre immédiatement les parties 2 à 4.
• Vous êtes PM ou architecte et devez choisir un fournisseur : passez directement aux parties 2 et 4. Revenez à la partie 1 si un membre de l’équipe demande pourquoi les TTL existent.
• Vous devez mettre en production un workload précis aujourd’hui : commencez par la partie 4 pour trouver la ligne correspondante dans la matrice, puis utilisez le code exact de la partie 3.
• Vous utilisez déjà LangChain : allez directement à la partie 5. Les patterns du SDK brut présentés dans la partie 3 restent applicables, mais les pièges liés aux templates de chaînes, au placement des variables et aux noms des champs d’usage sont propres au framework.
• Vous optimisez une application existante : reproduisez le benchmark multi-fournisseurs de la partie 3 §6 avec votre propre prompt. L’exercice prend une journée, pas plusieurs semaines de migration.

Mesures utilisées dans cette série

Les mesures des parties 1 à 4 ont été réalisées le 2026-05-25, et celles de LangChain dans la partie 5 le 2026-07-04, via la gateway Synthorai (https://synthorai.io/v1 pour la compatibilité OpenAI, https://synthorai.io/ pour l’API Anthropic native), en environnement single-tenant, sur une seule exécution séquentielle et sans charge concurrente. Les résultats varient selon la région, l’heure et la charge générée par les autres tenants. Utilisez-les comme point de départ et reproduisez les mesures sur votre propre trafic avant de les citer.

Les tableaux tarifaires et le comportement des TTL correspondent à la documentation publique des fournisseurs en 2026-05. Les fournisseurs les mettent à jour tous les quelques mois. Le raisonnement architectural de la partie 1 reste valable, tandis que les chiffres comparatifs des parties 2 et 3 évoluent.

← Retour au blog