Quel cache de prompt LLM coûte le moins cher ? Comparatif de 5 fournisseurs (2026)
Sommaire
- 1. Typologie des caches de prompt LLM
- 1.1 Contrôle : explicite, implicite ou hybride
- 1.2 Persistance : en mémoire ou sur disque
- 1.3 Granularité : précision de la correspondance
- 1.4 Modèle objet : marqueurs par appel ou objets de cache nommés
- 2. Analyse détaillée par fournisseur
- 2.1 Anthropic Claude — Explicite, en mémoire, granularité de 1,024 tokens
- 2.2 OpenAI GPT-5.x — Automatique, en mémoire, granularité de 1,024 tokens
- 2.3 Google Gemini — Hybride, en mémoire, objets de cache nommés
- 2.4 DeepSeek-v4 — Automatique, sur disque, granularité de 64 tokens
- 2.5 Alibaba Qwen3 — Hybride, en mémoire, objets de cache nommés et mode implicite
- 3. Comparatif synthétique
- 3.1 Structure des remises selon la documentation des fournisseurs, 2026-05
- 3.2 TTL, granularité et persistance
- 3.3 Latence mesurée sur un préfixe de 7K tokens (2026-05-25)
- 4. Grille d’évaluation en 5 dimensions
- 4.1 Coût effectif par million de tokens, pondéré par le taux de hit
- 4.2 Prévisibilité du taux de hit
- 4.3 Adéquation entre TTL et rythme du trafic
- 4.4 Latence en cas de miss
- 4.5 Ergonomie de l’API et coût de migration
- 5. Recommandations rapides selon le workload
- 6. Points à prévoir pour une migration
- 7. Évolution dans le temps
- FAQ
TL;DR — Les cinq principaux fournisseurs de LLM proposent des mécanismes de cache de prompt très différents : marqueurs explicites chez Claude, fonctionnement entièrement automatique avec GPT-5.x et DeepSeek-v4, modèle hybride implicite et explicite chez Gemini et Qwen, ou encore cache persistant sur disque grâce à l’architecture MLA de DeepSeek. Cet article les compare fonctionnalité par fonctionnalité et fournit une grille d’évaluation en 5 dimensions pour les noter selon votre charge de travail : coût, prévisibilité du taux de hit, latence, adéquation du TTL et ergonomie de l’API. Les principes d’architecture sont présentés dans la partie 1 : principes du cache. Les mesures et le code Python fonctionnel se trouvent dans la partie 3 : tutoriel.
Série : partie 2 sur 5 · Précédemment : partie 1 — Principes du cache · Suite : partie 3 — Tutoriel avec code fonctionnel · Partie 4 — Meilleur LLM par cas d’usage · Partie 5 — Intégration avec LangChain
1. Typologie des caches de prompt LLM
Avant de passer en revue chaque fournisseur, il faut distinguer quatre axes de conception.
1.1 Contrôle : explicite, implicite ou hybride
- Explicite — le développeur indique les parties du prompt à mettre en cache avec
cache_controlchez Anthropic Claude. Ce mode offre un contrôle maximal, mais nécessite de modifier le code. - Implicite / automatique — le fournisseur détecte automatiquement les préfixes identiques, comme OpenAI avec GPT-5.x et DeepSeek avec DeepSeek-v4. Aucune modification du code, mais aucun moyen de forcer un hit.
- Hybride — les deux modes sont disponibles et peuvent être choisis à chaque appel chez Gemini et Qwen.
1.2 Persistance : en mémoire ou sur disque
Ce comportement dépend de l’architecture du cache KV du fournisseur, pas de l’API exposée.
- En mémoire (HBM) — les caches résident dans la mémoire des GPU, durent peu de temps, généralement quelques minutes, et imposent de gros blocs minimaux de 1,024 tokens. C’est le fonctionnement par défaut de la plupart des fournisseurs.
- Sur disque — les caches sont conservés sur SSD/NVMe, avec des TTL beaucoup plus longs et une granularité plus fine. DeepSeek exploite cette approche à grande échelle grâce à la compression Multi-head Latent Attention (MLA), qui réduit le cache KV d’environ 4× (DeepSeek-AI, 2024).
1.3 Granularité : précision de la correspondance
Quelle est la longueur minimale d’un préfixe donnant droit à une remise ?
- 64 tokens — DeepSeek, la granularité la plus fine du marché
- 128 tokens — OpenAI, pour chaque incrément de correspondance
- 1,024 tokens — taille minimale d’un bloc pouvant être mis en cache chez Claude, OpenAI, Gemini et Qwen
Une granularité plus fine permet de bénéficier d’une correspondance même si seule une partie du préfixe est identique. Les petites variations du prompt sont donc mieux tolérées.
1.4 Modèle objet : marqueurs par appel ou objets de cache nommés
- Marqueurs par appel — chaque requête contient directement les données à mettre en cache, puis le fournisseur les hache. C’est le cas de Claude, OpenAI, DeepSeek et du mode implicite de Qwen.
- Objets de cache nommés — le développeur crée un cache via un appel d’API distinct, récupère un
cache_id, puis le référence dans les appels suivants. Gemini et Qwen utilisent ce modèle pour leur mode explicite. Il alourdit l’intégration, mais donne un contrôle direct sur le cycle de vie.
Ces quatre axes se combinent. L’offre de chaque fournisseur se définit par sa position sur chacun d’eux. La section suivante les détaille un par un.
2. Analyse détaillée par fournisseur
2.1 Anthropic Claude — Explicite, en mémoire, granularité de 1,024 tokens
Modèles principaux (2026-05) : claude-haiku-4-5, claude-sonnet-4-5 / 4-6, claude-opus-4-5 / 4-6 / 4-7.
Mise à jour GPT-5.6 (2026-06) : les règles ci-dessous ont changé avec la famille GPT-5.6. Les écritures dans le cache sont désormais facturées à 1.25x le tarif d’entrée, un
prompt_cache_keyest nécessaire pour obtenir une correspondance fiable, et des points de rupture explicites avec un TTL de 30 minutes ont été ajoutés. Les lignes de cet article décrivent le comportement de GPT-5.5/5.4. Pour la version 5.6, consultez le guide des coûts de GPT-5.6 et nos mesures des seuils minimaux du cache.
API de cache. Vous pouvez placer jusqu’à quatre points de rupture cache_control dans le tableau des messages ou dans le system prompt. Un hit coûte environ 10 % du tarif d’entrée de base. Une écriture coûte 125 %, soit un surcoût de 25 %. Le TTL par défaut est de 5 minutes en mode glissant : chaque hit le réinitialise. Une option de 1 heure est aussi disponible.
Structure tarifaire. Anthropic publie les tarifs par million de tokens pour chaque modèle. La remise liée au cache reste la même dans toute la gamme. Avec un system prompt de 8,000 tokens et 100K appels par jour sur claude-sonnet-4-5, le coût par appel est divisé par environ 8 à 10 une fois le préfixe en cache. Le seuil de rentabilité est atteint dès le premier hit.
Comportement du TTL. Le TTL par défaut est glissant et dure 5 minutes : chaque hit repousse l’expiration de 5 minutes. Le TTL de 1 heure double le coût d’écriture, mais devient indispensable dès que la charge comporte des périodes d’inactivité supérieures à 5 minutes.
Granularité. Le minimum est de 1,024 tokens. Le hash porte sur la séquence exacte de tokens. La modification d’un seul caractère au début invalide tout le préfixe.
Ergonomie de l’API. C’est la meilleure des fournisseurs comparés. Grâce aux différents points de rupture, les sections qui ne changent jamais, celles qui changent rarement et celles propres à chaque tâche peuvent être mises en cache séparément. Ce mécanisme est particulièrement adapté aux agents et aux workloads RAG, dont les différentes sections du prompt évoluent à des rythmes distincts.
Points d’attention.
- Sans
cache_control, il n’y a aucune mise en cache. Contrairement à GPT ou DeepSeek, aucun mécanisme implicite ne prend le relais. - Le hash du cache dépend de l’ordre, y compris dans les tableaux de tools et de fonctions. Triez-les de manière déterministe.
- Sans keep-alive explicite, le TTL de 5 minutes convient mal aux batchs irréguliers.
- Si vous appelez Claude via une gateway, vérifiez qu’elle prend en charge la route native Anthropic
/v1/messageset ses marqueurscache_control. La route compatible OpenAI/chat/completionsne les transmet généralement pas. Utilisez le SDK Anthropic en lui indiquant l’URL de base de la gateway.
Cas d’usage idéal. Agents avec long contexte, chat multi-tour avec system prompt stable, RAG structuré avec plusieurs niveaux de cache.
2.2 OpenAI GPT-5.x — Automatique, en mémoire, granularité de 1,024 tokens
Modèles principaux (2026-05) : gpt-5.4-nano, gpt-5.4-mini, gpt-5.2, gpt-5.4-pro, gpt-5.5-pro. Variantes Codex pour le code : gpt-5.2-codex, gpt-5.3-codex.
API de cache. Il n’y a rien à faire : le cache s’active automatiquement pour toutes les requêtes d’au moins 1,024 tokens. Les hits sont facturés à 50 % du tarif d’entrée, sans surcoût à l’écriture. La correspondance progresse par incréments de 128 tokens.
Structure tarifaire. OpenAI publie les tarifs par million de tokens. Les tokens d’entrée en cache bénéficient d’une remise de 50 %. Le prix des tokens de sortie reste inchangé.
Mesures (2026-05-25, system prompt d’environ 6,900 tokens) :
| Modèle | Coût total, miss | Coût total, hit | Taux de cache sur hit | TTFT en streaming sur hit |
|---|---|---|---|---|
gpt-5.4-nano | $0.00131 | $0.00074 (−44%) | 5,888 / 6,887 (85%) | 1.00 s |
gpt-5.4-mini | $0.00267 | $0.00257* | 6,400 / 6,887 (93%) | 0.73 s |
* La completion du passage avec hit de gpt-5.4-mini était beaucoup plus courte que celle du passage avec miss. L’écart de coût mélange donc la remise du cache et la variation de longueur de la completion. La latence divisée par 5 (3.63 → 0.73 s) constitue un indicateur plus fiable.
Comportement du TTL. La durée exacte n’est pas documentée. D’après les retours observés, elle varie entre 5 et 60 minutes selon la charge et la popularité du préfixe. Les préfixes partagés les plus utilisés restent en cache plus longtemps, car la politique LRU les favorise.
Ergonomie de l’API. L’intégration est immédiate : le code existant continue de fonctionner. Journalisez prompt_tokens_details.cached_tokens pour mesurer le taux de hit.
Points d’attention.
- Impossible de forcer un hit. Si chaque requête produit un préfixe unique, le cache n’apporte rien.
- La remise de 50 % est moins élevée que les 90/75 % de Claude et DeepSeek, et proche des ~25 % du cache implicite de Gemini.
- En streaming, les hits ne sont parfois signalés que dans le dernier chunk. Instrumentez ce cas correctement et passez
stream_options={"include_usage": True}.
Cas d’usage idéal. Bases de code utilisant déjà GPT, lorsque le coût d’une migration dépasse les économies supplémentaires. Trafic en rafales avec une forte répétition naturelle des préfixes.
2.3 Google Gemini — Hybride, en mémoire, objets de cache nommés
Modèles principaux (2026-05) : gemini-2.5-flash, gemini-2.5-pro, gemini-3-flash-preview, gemini-3.1-pro-preview, gemini-3.1-flash-lite-preview.
API de cache. Deux modes :
- Implicite : automatique, comme GPT. Les tokens en cache sont facturés à environ 25 % du tarif d’entrée. Aucun coût de stockage ni configuration.
- Explicite : créez un objet
cachedContentvia un appel d’API distinct, puis référencez-le par son nom dans les requêtes suivantes. Les tokens en cache sont facturés à environ 10 %, mais des frais de stockage horaires par million de tokens s’ajoutent.
Structure tarifaire. Le long contexte est l’un des points forts de Gemini. Le tarif dépend de la taille du contexte, avec des paliers inférieurs et supérieurs à 200K tokens, et un prix par token plus élevé au-delà de ce seuil.
Mesures (2026-05-25) :
| Modèle | Coût, miss | Coût, hit en streaming | Taux de cache sur hit |
|---|---|---|---|
gemini-2.5-flash | $0.00198 | $0.00024 (−88%) | 7,140 / 7,322 (97%) |
gemini-2.5-pro | $0.00824 | $0.00205 (−75%) | 6,120 / 7,328 (84%) |
Comportement du TTL. Implicite : quelques minutes, durée non publiée. Explicite : configuré par le développeur, 1 heure par défaut et jusqu’à 24 heures.
Ergonomie de l’API. Le cache explicite nécessite deux étapes : création, puis référence. La gestion du cycle de vie de cachedContent, notamment la création, la mise à jour du TTL et la suppression, vous incombe.
Points d’attention.
- Les frais de stockage rendent les caches explicites peu intéressants à faible volume. Calculez toujours le seuil de rentabilité à partir de votre fréquence d’appel.
- Le taux de hit du cache implicite varie. Ne l’utilisez pas comme hypothèse fixe dans vos estimations de coût.
- Les objets de cache sont liés à une région. Une application multi-région doit créer plusieurs caches.
gemini-*-proest un modèle de reasoning. Avec unmax_tokensfaible, le raisonnement masqué consomme toute la completion et vous obtenezcompletion_tokens=0. Utilisezmax_tokens≥256 sur tous les parcours exposés aux utilisateurs.
Cas d’usage idéal. Un document volumineux de plus de 20K tokens interrogé au moins 10 fois par heure. Questions-réponses sur des vidéos. RAG multimodal sur des PDF d’entreprise.
2.4 DeepSeek-v4 — Automatique, sur disque, granularité de 64 tokens
Modèles principaux (2026-05) : deepseek-v4-flash pour les usages généralistes et les workloads de code de cette génération.
API de cache. Le fonctionnement est automatique, comme chez GPT, mais repose sur la compression MLA. Le cache devient ainsi assez compact pour être conservé sur disque. Les hits sont facturés à environ 25 % du tarif d’entrée, sans surcoût à l’écriture. La correspondance minimale est de 64 tokens.
Structure tarifaire. DeepSeek publie ses tarifs en yuans. En pratique, un hit réduit le coût d’entrée d’environ 75 %.
Mesures (2026-05-25) :
| Modèle | Coût, miss | Coût, hit | Taux de cache sur hit | TTFT sur hit |
|---|---|---|---|---|
deepseek-v4-flash | $0.00091 | $0.00023 (−74%) | 6,784 / 7,101 (96%) | 2.93 s |
Comportement du TTL. Plusieurs heures, voire davantage pour les préfixes très utilisés. Le stockage sur disque permet aux caches de résister à la pression sur la mémoire GPU, qui provoquerait leur éviction chez les fournisseurs utilisant uniquement la mémoire.
Granularité. Le minimum de 64 tokens est le plus bas du marché. Après de petites modifications du prompt, la majeure partie du préfixe reste valide, contrairement aux fournisseurs imposant des blocs de 1,024 tokens.
Ergonomie de l’API. L’API reprend le format OpenAI : il suffit de changer l’URL de base. Le champ standard prompt_tokens_details.cached_tokens est disponible.
Points d’attention.
- Ce cache fonctionne uniquement avec les modèles de la famille DeepSeek. Il n’est pas utilisable avec d’autres familles.
- La qualité en anglais est excellente, mais reste inférieure à Claude et GPT-5.x sur les benchmarks de reasoning les plus difficiles.
Cas d’usage idéal. Workloads en chinois pour réduire les coûts. Workloads avec des préfixes très fréquents où la granularité est importante, notamment le RAG dont l’ordre des résultats varie. Batchs sensibles au coût.
2.5 Alibaba Qwen3 — Hybride, en mémoire, objets de cache nommés et mode implicite
Modèles principaux (2026-05) : qwen3-max, qwen3.5-plus, qwen3.5-flash. Variantes vision : qwen3-vl-plus, qwen3-vl-flash.
API de cache. Deux modes :
- Implicite : toujours actif, comme chez GPT. La partie en cache est facturée à environ 20 % du tarif d’entrée.
- Explicite : création d’un cache via l’API avec un TTL personnalisé. Les hits sont facturés à environ 10 % et les écritures à 125 %.
Mesures (2026-05-25) :
| Modèle | Coût, miss | Coût, hit | Taux de cache sur hit | TTFT sur hit | Remarques |
|---|---|---|---|---|---|
qwen3-max | $0.00553 | $0.00549 | 7,040 / 7,234 (97%) | 1.53 s | Hit signalé, mais le champ de coût de la gateway ne reflétait pas la remise à cette date. À vérifier en production |
Comportement du TTL. La valeur par défaut est de 5 minutes et peut être configurée pour chaque objet de cache. Le mode explicite utilise une fenêtre glissante, tandis que le mode implicite applique un TTL fixe et court.
Ergonomie de l’API. Le mode implicite reprend le format GPT et ne demande aucun travail. Le mode explicite nécessite deux étapes ainsi qu’une gestion du cycle de vie du cache.
Points d’attention.
- Pour le moment, seuls
qwen3-maxetqwen3.5-plusprennent en charge le cache explicite. - Le déploiement multi-région à Singapour et aux États-Unis est en cours. Vérifiez la région avant de l’utiliser pour des données situées hors de Chine.
- La documentation reste moins complète que celles d’Anthropic et d’OpenAI. Des tests empiriques sont recommandés.
Cas d’usage idéal. Workloads d’entreprise en chinois nécessitant un contrôle précis du cache. Clients déjà présents sur Alibaba Cloud.
3. Comparatif synthétique
3.1 Structure des remises selon la documentation des fournisseurs, 2026-05
| Fournisseur | Surcoût d’écriture dans le cache | Tarif des entrées en cache | Remise effective |
|---|---|---|---|
| Anthropic Claude | +25% | 10% du tarif de base | ~90% de remise |
| OpenAI GPT-5.5 / 5.4 | aucun | 50% du tarif de base | 50% de remise |
| Google Gemini (implicite) | aucun | ~25% du tarif de base | ~75% de remise |
| Google Gemini (explicite) | aucun, mais frais de stockage horaires | ~10% du tarif de base | ~90% de remise après amortissement |
| DeepSeek-v4 | aucun | ~25% du tarif de base | ~75% de remise |
| Alibaba Qwen3 (implicite) | aucun | ~20% du tarif de base | ~80% de remise |
| Alibaba Qwen3 (explicite) | +25% | ~10% du tarif de base | ~90% de remise |
3.2 TTL, granularité et persistance
| Fournisseur | TTL par défaut | TTL maximal | Persistance | Unité minimale de correspondance |
|---|---|---|---|---|
| Claude | 5 min, glissant | 1 heure | En mémoire (HBM) | 1,024 tok |
| GPT-5.5 / 5.4 | ~5 min | ~60 min | En mémoire (HBM) | 1,024 tok / incréments de 128 tok |
| Gemini (implicite) | quelques minutes | non publié | En mémoire | 1,024 tok |
| Gemini (explicite) | 1 heure | 24 heures | En mémoire | 1,024 tok |
| DeepSeek-v4 | plusieurs heures | plusieurs heures ou plus | Disque (SSD) | 64 tok |
| Qwen3 | 5 min | configurable | En mémoire | ~1,024 tok |
3.3 Latence mesurée sur un préfixe de 7K tokens (2026-05-25)
| Fournisseur / modèle | Temps total sur miss | TTFT en streaming sur hit | Gain de latence |
|---|---|---|---|
claude-haiku-4-5 † | ~3.0 s | 1.31 s | ~2× |
claude-sonnet-4-5 † | ~2.0 s | 1.76 s | ~1.2× |
claude-opus-4-5 † | ~2.2 s | 2.08 s | ~1.05× |
gpt-5.4-mini | ~3.6 s | 0.73 s | ~5× |
gpt-5.4-nano | ~2.2 s | 1.00 s | ~2× |
gemini-2.5-flash | ~2.5 s | ~1.4 s | ~1.8× |
gemini-2.5-pro | ~3.0 s | ~1.8 s | ~1.7× |
deepseek-v4-flash | ~4.0 s | 2.93 s | ~1.4× |
qwen3-max | ~4.8 s | 1.53 s | ~3× |
† Les lignes Claude ont été mesurées avec des marqueurs cache_control via l’endpoint natif Anthropic /v1/messages, comme expliqué dans la partie 3 §2. Le principal avantage de Claude porte sur le coût, avec une remise d’environ 88 à 89 % sur les entrées. Le tableau complet se trouve dans la partie 3 §2. D’après les chiffres publiés par Anthropic, le gain de TTFT augmente fortement pour les prompts de 100K tokens ou plus.
Ces chiffres proviennent d’une seule exécution séquentielle, sans charge concurrente. Ils varieront selon la région, l’heure et la charge des autres tenants.
4. Grille d’évaluation en 5 dimensions
Les annonces comme « Claude permet d’économiser 90 % » attirent l’attention, mais ne suffisent généralement pas pour choisir. Notez chaque fournisseur sur ces cinq dimensions selon votre workload, puis pondérez les résultats en fonction de vos priorités.
4.1 Coût effectif par million de tokens, pondéré par le taux de hit
Ne comparez pas les tarifs de base. Comparez le coût attendu avec votre taux de hit réel. Saisissez vos chiffres dans le calculateur de coût LLM ou consultez le comparatif actualisé des tarifs LLM entre fournisseurs :
effective_cost = base × (1 - hit_rate × (1 - discount)) + write_premium × write_rate
Exemple avec 70 % de répétition des préfixes, valeur courante pour un chatbot :
- Claude : remise de ~90% × 0.7 hit + écriture à 25% × 0.3 → coût effectif ≈ tarif de base × 0.45
- GPT-5.5 : ~50% × 0.7 + 0 → coût effectif ≈ tarif de base × 0.65
- Gemini implicite : ~75% × 0.7 + 0 → coût effectif ≈ tarif de base × 0.48
- DeepSeek-v4 : ~75% × 0.7 + 0 → coût effectif ≈ tarif de base × 0.48
Multipliez ensuite ce résultat par le tarif de base réel de chaque fournisseur, car il varie d’un service à l’autre, afin d’obtenir un coût comparable en dollars. Pour la notation : calculez effective_cost pour votre workload ; plus il est faible, meilleur est le résultat.
4.2 Prévisibilité du taux de hit
- Caches explicites chez Claude, Qwen en mode explicite et Gemini en mode explicite : forte prévisibilité. Si les données sont marquées et que le TTL n’a pas expiré, le hit se produit.
- Caches automatiques chez GPT-5.x, DeepSeek-v4, Gemini en mode implicite et Qwen en mode implicite : le résultat dépend à la fois de la similarité des préfixes et de la charge du fournisseur, qui influence l’éviction LRU.
Si vos SLA dépendent du coût, privilégiez un cache explicite. Pour une optimisation best effort, le mode automatique suffit.
4.3 Adéquation entre TTL et rythme du trafic
| Profil de trafic | Besoin |
|---|---|
| Continu, avec quelques secondes entre les appels | Le TTL par défaut de tous les fournisseurs convient |
| Lié à une session, sur quelques minutes | TTL de 5 à 60 min avec Claude, GPT-5.x ou Qwen |
| En rafales espacées de plusieurs heures | TTL d’au moins 1 heure avec Claude 1h, Gemini explicite ou DeepSeek-v4 |
| Irrégulier, avec quelques requêtes par jour | TTL de 24 heures avec Gemini explicite, ou accepter des écritures à froid |
4.4 Latence en cas de miss
Un fournisseur rapide sur les hits mais lent sur les miss reste problématique si votre taux de hit est faible. Comparez les deux valeurs de la section §3.3 et pondérez-les avec votre taux de hit attendu.
4.5 Ergonomie de l’API et coût de migration
- Migration la plus simple : GPT-5.x ↔ DeepSeek-v4, car les deux utilisent un format OpenAI et un cache automatique.
- Intermédiaire : GPT-5.x → Gemini implicite. Le SDK change, mais aucun code de cache n’est à réécrire.
- Élevé : GPT-5.x → Claude. Il faut ajouter
cache_controlet restructurer les différentes couches du prompt. - Le plus élevé : passer d’un fournisseur unique à plusieurs sans gateway, car il faut gérer plusieurs API de cache.
5. Recommandations rapides selon le workload
| Workload | Choix | Raison |
|---|---|---|
| Chat en anglais, utilisateurs répartis dans le monde | claude-haiku-4-5 ou gpt-5.4-nano | Remise importante sur le cache et modèle petit et rapide |
| Chat en chinois, Chine continentale | deepseek-v4-flash ou qwen3.5-flash | Cache de plusieurs heures et faible coût en chinois |
| RAG en anglais, haute qualité | claude-sonnet-4-5 + plusieurs points de rupture | La structure en couches du prompt se met efficacement en cache |
| RAG en chinois, sensible au coût | deepseek-v4-flash | La granularité de 64 tokens tolère les changements d’ordre des résultats |
| Questions-réponses sur de longs documents, usage irrégulier | gemini-2.5-pro explicite | TTL de 24 heures, conçu pour cet usage |
| Base de code GPT existante, sans réécriture | gpt-5.4-mini sans changement | Environ 50% d’économies sans effort |
| Agents complexes, 15 étapes ou plus | claude-sonnet-4-5 + cache_control avec 4 points de rupture | Taux de hit supérieur à 85% sur le trafic des agents |
| Portabilité entre plusieurs fournisseurs | Gateway, n’importe quel modèle | Un seul SDK et un seul header d’authentification |
6. Points à prévoir pour une migration
Si votre évaluation indique qu’il faut changer de fournisseur, trois aspects doivent être anticipés.
Transfert des données. Les préfixes en cache ne sont pas transférables d’un fournisseur à l’autre. Chaque migration démarre donc à froid. Prévoyez plusieurs heures de coûts supérieurs à la normale pendant le warm-up.
Restructuration des prompts. Les différents points de rupture d’Anthropic encouragent une organisation du prompt en couches. Cette structure est aussi plus efficace chez les autres fournisseurs. Une seule refactorisation améliore donc également les parcours qui n’utilisent pas Claude.
Répartition via une gateway. Si le choix n’est pas encore arrêté, faites transiter le trafic par une Token Gateway. Vous conservez la possibilité de changer de fournisseur sans vous engager auprès d’un seul, au prix d’un saut réseau supplémentaire et, selon la gateway, d’une éventuelle perte d’accès aux réglages de cache propres à chaque fournisseur. La partie 3 §9 détaille ce que fait réellement la gateway Synthorai et les affirmations à prendre avec recul.
7. Évolution dans le temps
Les chiffres de cet article vont évoluer. Le cache est devenu un argument tarifaire important et les fournisseurs mettent à jour leurs offres tous les quelques mois. Deux évolutions sont à surveiller :
- Allongement des TTL. L’option 1 heure d’Anthropic est disponible en GA. Gemini pourrait passer à plusieurs jours. Le TTL devrait progressivement devenir moins contraignant.
- Granularité. OpenAI et Anthropic finiront probablement par abaisser leur minimum de 1,024 tokens. Le seuil de 64 tokens établi par DeepSeek constitue désormais la nouvelle référence.
Quand les remises convergeront, l’ergonomie de l’API et la latence feront la différence, plutôt que le pourcentage d’économie annoncé.
À suivre : la partie 3 — Tutoriel sur le cache de prompt avec du code Python fonctionnel transforme l’architecture présentée ci-dessus en code exécutable. Elle reproduit aussi le tableau de latence de la section §3.3 sous forme de benchmark que vous pourrez lancer vous-même.
FAQ
Quel fournisseur de LLM propose globalement le cache de prompt le moins cher ?
À taux de hit identique, autour de 75 %, deepseek-v4-flash pour les workloads en chinois et le cache implicite de gemini-2.5-flash pour l’anglais présentent le coût effectif par million le plus faible dans nos mesures de 2026-05. claude-sonnet-4-5 offre la plus forte remise sur un appel, autour de 90 %, mais son tarif de base est plus élevé. Il devient le plus intéressant lorsque le taux de hit dépasse 85 %. Appliquez votre propre taux de hit à la formule de la section §4.1.
Pourquoi Gemini coûte-t-il plus cher pour les workloads à faible volume ? Avec les caches explicites, les frais de stockage horaires absorbent la remise si le cache n’est pas interrogé fréquemment. À faible volume, utilisez le cache implicite de Gemini, sans frais de stockage et avec une remise d’environ 25 %.
Puis-je utiliser le cache_control de Claude avec OpenAI ?
Pas directement, car il s’agit de deux implémentations de cache distinctes. Sur l’endpoint compatible OpenAI /chat/completions, ce champ n’a généralement aucun effet avec les modèles non Anthropic, qui utilisent de toute façon leur propre cache automatique. Pour Claude, utilisez l’endpoint natif Anthropic /v1/messages avec les marqueurs.
L’architecture MLA de DeepSeek est-elle propriétaire ? L’article de recherche de DeepSeek-AI publié en 2024 est public. D’autres fournisseurs pourraient adopter une compression KV inspirée de MLA, mais cela impose de réentraîner le modèle de base. Ce n’est pas une option activable à l’exécution. En 2026-05, DeepSeek reste le seul grand fournisseur à l’utiliser en production.
Qu’en est-il des modèles open source auto-hébergés ? vLLM, SGLang et d’autres moteurs d’inférence prennent nativement en charge le cache de préfixes, sur la base de l’article PagedAttention. Si vous auto-hébergez sur des H100/H200, vous pouvez mettre en place un cache sur disque avec LMCache ou un outil similaire. L’analyse tarifaire de cet article ne concerne que les services managés. L’économie de l’auto-hébergement est totalement différente. Pour router les requêtes vers plusieurs fournisseurs sans exploiter vous-même le routeur, une alternative managée à LiteLLM permet de conserver une seule API tout en préservant le cache chez les mêmes fournisseurs. La répartition du support du cache entre les modèles à poids ouverts et les hébergeurs qui le proposent comme fonctionnalité est détaillée dans le cache de prompt pour les LLM à poids ouverts.
Pourquoi Mistral, Cohere et les fournisseurs d’API Llama ne figurent-ils pas dans ce comparatif ? En 2026-05, leurs offres de cache sont moins matures. Le cache de Mistral est en accès anticipé, Cohere n’expose pas de cache explicite, et la prise en charge varie fortement entre les fournisseurs d’API Llama comme Groq, Together et Replicate. Il faudra réévaluer ces offres une fois leurs fonctionnalités stabilisées.
Sources : Cache de prompt Anthropic · Cache de prompt OpenAI · Cache de contexte Google Gemini · Cache KV de DeepSeek · Cache de contexte Alibaba Bailian · Article DeepSeek-V2 / MLA · PagedAttention / vLLM (Kwon et al. 2023). Mesures effectuées sur https://synthorai.io/v1 le 2026-05-25.