Mise en cache des prompts LLM : le guide complet 2026

Si vous déployez un chatbot, une application RAG ou un agent IA face à un grand modèle de langage, la mise en cache des prompts est l’unique optimisation qui vous restitue 50 à 90 % du coût d’entrée et 3 à 10× sur le temps jusqu’au premier token sans aucune perte de qualité. Ce n’est pas une astuce rapportée : elle découle directement de la façon dont est définie l’attention des Transformers. Une fois cela compris, le reste de la pile (TTL, différences entre fournisseurs, structure des prompts) s’aligne proprement.

Cette page est l’index d’une série en quatre parties qui vous mène de la théorie à une matrice de décision pour la production. Choisissez votre point d’entrée selon ce que vous savez déjà.

Par où commencer

Chaque partie se suffit à elle-même, mais elles sont écrites de sorte que les lire dans l’ordre construise l’ensemble sans redondance.

Partie 1 — Comment fonctionne la mise en cache des prompts LLM

Mise en cache des prompts LLM #1 : comment fonctionnent le cache KV et le TTL →

L’article architectural. Il parcourt l’auto-attention sous la forme d’une équation unique, explique pourquoi les vecteurs K et V d’un préfixe stable sont mathématiquement réutilisables, et montre comment le compromis mémoire/calcul produit le comportement de TTL autour duquel chaque développeur doit concevoir.

Points clés :

• La mise en cache des prompts n’est pas une optimisation ajoutée par-dessus — c’est une conséquence directe de l’attention à masque causal. Le K/V à la position i est une fonction déterministe des tokens 1…i, si bien que des préfixes identiques donnent des K/V identiques au bit près.
• Le prefill (limité par le calcul, O(N²)) est ce que le cache fait économiser ; le decode (limité par la bande passante mémoire, O(N) par token) est ce que tout moteur d’inférence optimise déjà.
• Les TTL existent parce que le cache KV est énorme (~10 Go pour un contexte de 32K sur un modèle 70B). 5 minutes, c’est l’horizon de pression mémoire du GPU ; des durées de plusieurs heures à plusieurs jours ne sont possibles qu’avec des caches sur disque (l’architecture MLA de DeepSeek).
• Le cache gagne à la fois sur le coût (50 à 90 % de réduction sur l’entrée en cas de cache hit) et sur la latence (le TTFT chute de 3 à 10× pour des prompts de l’ordre de 5 à 10K tokens, et bien davantage au-delà de 100K).

Partie 2 — Comparer la mise en cache des prompts LLM entre fournisseurs

Mise en cache des prompts LLM #2 : comparer Claude, GPT, Gemini, DeepSeek →

Le guide d’achat. Cinq fournisseurs exposent la mise en cache des prompts sous cinq formes très différentes — marqueurs explicites (Claude), entièrement automatique (GPT-5, DeepSeek-v4), hybride implicite+explicite (Gemini, Qwen), ou support disque architectural (la MLA de DeepSeek). L’article propose une comparaison fonctionnalité par fonctionnalité ainsi qu’un cadre d’évaluation à 5 dimensions pour les noter selon votre charge de travail spécifique.

Points clés :

• Ne comparez pas les prix de base — comparez le coût effectif pondéré par votre taux de cache hit (formule en §4.1).
• Claude offre la remise la plus profonde sur un appel unique (~90 %) mais exige des marqueurs cache_control explicites.
• DeepSeek-v4 est le seul fournisseur avec des caches sur disque à grande échelle ; les correspondances partielles de préfixe donnent droit à des remises car la granularité est de 64 tokens au lieu de 1 024.
• Le cache explicite de Gemini facture des frais de stockage horaires — le seuil de rentabilité dépend de la fréquence des appels.
• L’ergonomie de l’API, la prévisibilité du taux de cache hit, l’adéquation du TTL, la latence en cas de miss et le coût de migration sont les cinq dimensions qui distinguent réellement les fournisseurs une fois le taux de cache hit neutralisé.

Partie 3 — Tutoriel Python fonctionnel

Mise en cache des prompts LLM #3 : tutoriel Python fonctionnel →

L’article pratique. Un SDK OpenAI + un SDK Anthropic face à une passerelle unique, avec des chiffres mesurés le 2026-05-25 sur toute la famille Claude (de haiku-4-5 à opus-4-7), GPT-5.x, Gemini 2.5, DeepSeek-v4 et Qwen3.

Points clés :

• Claude avec marqueurs cache_control : réduction de coût de 88 à 89 % mesurée de façon uniforme sur haiku/sonnet/opus 4-x. Utilisez le SDK Anthropic avec base_url="https://synthorai.io/".
• Cache automatique de GPT-5.4-mini : amélioration du TTFT de 5× (3,6 s → 0,73 s sur un prompt de 7K tokens), 93 % de taux de cache hit sur les tokens système.
• Cache implicite de Gemini 2.5-flash : réduction de coût de 88 % en cas de cache hit lorsque l’usage en streaming est capturé.
• DeepSeek-v4-flash : 74 % de réduction, support disque (le cache survit à des inactivités de l’ordre de l’heure).
• Schémas conscients du TTL : heartbeat keep-alive pour les cron, règles de stabilité du préfixe, quoi journaliser à chaque appel.

Partie 4 — Le meilleur modèle par cas d’usage

Mise en cache des prompts LLM #4 : le meilleur modèle pour le chat, le RAG et les agents →

L’article de décision. Des charges de travail différentes actionnent différemment les leviers de coût/latence — le chat est naturellement favorable au cache, le RAG se bat contre le problème de stabilité du préfixe, les agents dépendent d’une discipline de préfixe cumulatif. L’article fournit une recommandation de modèle par forme de charge de travail avec des estimations de coût.

Points clés :

• Chatbots : tout modèle doté du cache automatique fonctionne ; les sessions font cache hit naturellement. Choisissez selon le coût/qualité. gpt-5.4-nano est le moins cher, gpt-5.4-mini a le TTFT en cache le plus rapide, claude-haiku-4-5 offre le meilleur suivi des instructions moyennant une prime modeste.
• RAG : la réorganisation des documents récupérés détruit les cache hits en milieu de prompt. Trois correctifs — repousser les références à la fin, un ordre de chunks déterministe, ou les points de rupture multi-cache_control de Claude.
• Agents : les appels d’outils et leurs résultats doivent être en ajout seul et identiques au bit près d’une étape à l’autre. claude-sonnet-4-5 avec 4 marqueurs cache_control offre la remise de préfixe cumulatif la plus forte ; gpt-5.4-mini fonctionne sans modification de code avec 50 % d’économies.
• Adéquation du TTL : 5 min pour le chat, 1 heure pour les agents avec étapes à intervention humaine, support disque pour le traitement par lots sporadique.

Comment lire cette série

• Ingénieur novice sur le sujet : lisez dans l’ordre. L’architecture de la Partie 1 fait instantanément cliquer les Parties 2 à 4.
• PM ou architecte effectuant une sélection de fournisseur : sautez à la Partie 2 + la Partie 4. Reportez-vous à la Partie 1 si un collègue demande « mais pourquoi le TTL existe ».
• Ingénieur avec une charge de travail spécifique à livrer aujourd’hui : la Partie 4 d’abord (trouvez votre ligne dans la matrice), puis la Partie 3 pour le code exact.
• Toute personne optimisant une application existante : le benchmark inter-fournisseurs de la Partie 3 §6 — reproduisez-le sur votre propre prompt ; c’est l’affaire d’une journée, pas d’une migration de plusieurs semaines.

Les chiffres de cette série

Tous les chiffres mesurés ont été relevés le 2026-05-25 face à la passerelle Synthorai (https://synthorai.io/v1 pour la compatibilité OpenAI, https://synthorai.io/ pour Anthropic natif), mono-locataire, en une seule exécution séquentielle, sans charge concurrente. Vos chiffres varieront selon la région, l’heure de la journée et la charge des locataires concurrents — considérez-les comme un point de départ et reproduisez-les sur votre propre trafic avant de les citer.

Les grilles tarifaires et le comportement du TTL reflètent la documentation publique des fournisseurs en date de 2026-05. Les fournisseurs les mettent à jour tous les quelques mois ; le raisonnement architectural (Partie 1) est stable, les chiffres comparatifs (Parties 2 et 3) dérivent.

← Retour au blog