Cache de prompt des LLM à poids ouverts : la loterie des fournisseurs

Avec un modèle fermé, le cache de prompt repose sur un contrat documenté unique. Claude utilise des points de rupture cache_control ; OpenAI et Gemini mettent automatiquement en cache les prompts dépassant un certain nombre de tokens ; les remises sont publiées et stables. Une page de documentation suffit.

Avec des poids ouverts, cette logique ne tient plus. Un même checkpoint Qwen ou Llama peut être servi par une douzaine d’hébergeurs, et le cache n’est pas une propriété du modèle, mais de l’endroit où il s’exécute. Pour mesurer l’ampleur du phénomène, nous avons envoyé six fois une requête identique, avec un prompt d’environ 4.7K tokens, au même modèle Qwen via un routeur multi-fournisseurs, sans imposer d’upstream :

Même modèle, même routeur, même prompt : la facture a varié de $0.0141 à $0.000286, soit un écart de 49×. La seule différence venait de l’upstream choisi par le routeur et de la présence éventuelle du préfixe dans son cache.

Résumé

• Pour les modèles à poids ouverts, le cache de prompt dépend du routage, pas du modèle. Le moteur d’inférence le fournit automatiquement et gratuitement, puis chaque couche supérieure peut le préserver ou le rendre inutilisable.
• Cinq couches : une fournit le cache, trois peuvent le casser. Le modèle (détermine la capacité à être mis en cache, mais ne fournit aucun cache) → le moteur d’inférence (cache gratuit) → l’hébergeur de calcul (le transforme en produit, avec des résultats inégaux) → la gateway (routage multi-clusters) → le routeur (répartition entre des fournisseurs dont les caches ne sont pas partagés).
• Mesures à l’appui. Une même requête, répartie par un routeur, a coûté 49× plus cher selon l’upstream choisi ; pour un même modèle, un hébergeur a accordé 59.6% de remise et un autre 0% ; les remises publiées sur les accès au cache vont de 0% à ~98% selon les modèles.
• Marche à suivre. Fixez la route pour que les préfixes répétés retrouvent le même cache chaud ; vérifiez l’écart de coût, pas le champ cached_tokens, qui reste souvent à 0 malgré un hit réel ; évaluez la latence séparément, car les prefills chauds sont 2–10× plus rapides même avec une remise proche de 0%.

Les chiffres réels ont été mesurés le 2026-06-14 sur un routeur multi-fournisseurs et notre propre gateway, avec un prompt fixe en anglais d’environ 4.7K tokens, un faible max_tokens et des exécutions séquentielles. Les tarifs documentés ont été vérifiés le même jour dans les sources primaires des fournisseurs, puis soumis à une contre-vérification contradictoire. Les ratios (remise en pourcentage, évolution de la latence) sont la partie transposable ; les montants absolus dépendent de la plateforme, du prompt et de la charge. Reproduisez les mesures avant de les citer.

Les types de cache que vous rencontrerez réellement

Avant d’examiner les différentes couches, clarifions le vocabulaire. Les hébergeurs de modèles à poids ouverts proposent quatre formes de cache distinctes, avec des modes de facturation différents.

1. Cache automatique des préfixes (sans marqueur). C’est le cas le plus courant. Le serveur calcule le hash du préfixe du prompt, réutilise l’état KV s’il correspond à une requête précédente et applique lui-même la remise. Aucun cache_control, aucune modification du code, et souvent aucun moyen de le désactiver. DeepSeek, Zhipu GLM et la plupart des hébergeurs de modèles à poids ouverts fonctionnent ainsi. Les écritures sont gratuites ; le cache peut rester quelques minutes en VRAM ou plusieurs jours sur disque. DeepSeek conserve les préfixes « de quelques heures à quelques jours ».

2. Cache explicite avec point de rupture (cache_control). C’est le fonctionnement d’Anthropic, également proposé par quelques hébergeurs de modèles à poids ouverts. Model Studio d’Alibaba accepte "cache_control": {"type": "ephemeral"} dans un bloc de message Qwen ; certaines plateformes d’inférence exposent un marqueur équivalent. Vous indiquez la limite, payez un surcoût d’écriture, puis bénéficiez d’une remise plus forte à la lecture.

3. Objets de cache loués (avec frais de stockage). C’est le cas à surveiller. Pour l’ancienne famille moonshot-v1, Moonshot impose un POST /v1/caching pour créer un cache, puis facture l’écriture, des frais de stockage par token et par minute et des frais par hit. Le cache explicite de Gemini chez Google repose sur le même principe : coût d’input plus stockage, à environ $1.00–$4.50 par 1M-tokens et par heure. Le cache est une ressource louée qu’il faut supprimer lorsqu’elle n’est plus utile.

4. Réutilisation du cache KV en auto-hébergement (gratuite). Si vous exécutez vous-même les poids, le moteur d’inférence gère automatiquement le cache sans frais supplémentaires. Pas de frais d’écriture, de tarif de lecture ni de location de stockage : un hit évite simplement le prefill.

Sur Model Studio, Qwen propose les modes automatique et explicite, avec un vrai compromis. En mode implicite, un hit est facturé à 20% du tarif d’input et les écritures sont gratuites. En mode explicite, un hit est facturé à 10% du tarif d’input, mais l’écriture coûte 125% et l’entrée expire au bout de 5 minutes. La remise est plus forte, mais il faut payer le remplissage du cache, puis de nouveau à chaque expiration.

Où se trouve le cache dans la stack

L’idée centrale est simple. Pour les modèles à poids ouverts, le cache de prompt est résolu à une seule couche, puis menacé par toutes les couches supérieures. Remontons la stack depuis les poids. À chaque niveau, il faut déterminer si la couche fournit le cache ou se contente de le transmettre, et si elle peut casser ce que la couche inférieure a déjà mis en place.

  request
     |
     v
  +--------------------------------------------------+
  | L5  router             scatters across vendors   |  can break it
  | L4  gateway            multi-cluster routing     |  can break it
  | L3  compute host       uneven delivery           |  can break it
  |==================================================|
  | L2  inference engine   CACHING LIVES HERE, free  |  <-- the cache is born here
  |==================================================|
  | L1  model              cacheability: MLA / GQA   |  sets the ceiling
  +--------------------------------------------------+

  A cache hit is born at L2 and must survive L3-L5 routing to reach you;
  every layer above L2 is a chance to land where your prefix isn't.

Couche 1 — Le modèle : la capacité à être mis en cache, pas le cache lui-même

C’est la couche à laquelle la plupart des utilisateurs attribuent le cache, en disant par exemple « DeepSeek gère le cache ». Il faut donc être précis. Un checkpoint est un ensemble de poids ; il exécute le même mécanisme d’attention, qu’un cache KV existe ou non. Il ne contient ni cache, ni remise, ni TTL, ni marqueur cache_control : ce sont des fonctions de la couche d’inférence. Au sens strict, les poids ne fournissent donc aucun produit de cache.

Les poids ne sont toutefois pas neutres, et DeepSeek l’illustre parfaitement. L’architecture d’attention du modèle détermine la taille du cache KV, et donc le coût minimal que le cache pourra atteindre :

• La Multi-head Latent Attention (MLA) de DeepSeek compresse le cache KV dans une représentation latente de faible rang, pour atteindre environ 4–14% de la taille d’un cache multi-head standard. Cette compression permet précisément à l’API DeepSeek de conserver les préfixes sur disque et de facturer leur lecture à environ 2% du tarif d’input. L’architecture rend cette optimisation possible ; le cache sur disque est un produit construit par-dessus.
• La Grouped-Query Attention (GQA), utilisée par Llama, Qwen, Mistral et DeepSeek, partage les têtes KV pour réduire la taille du cache selon le facteur de regroupement, soit ≈8× sur Llama-3.

La contribution de la couche 1 est donc la capacité à être mis en cache, pas le cache lui-même. L’architecture fixe le coût minimal que les couches supérieures peuvent atteindre, mais les poids ne servent jamais eux-mêmes un token depuis le cache. L’affirmation « DeepSeek gère le cache » confond deux éléments distincts : les poids de cette couche, qui fournissent MLA, et l’API ainsi que la stack d’inférence de DeepSeek, aux couches 2–3, qui fournissent le cache sur disque, la remise et les champs d’usage. Si vous téléchargez les poids ouverts et les exécutez vous-même, vous conservez le cache KV compact de MLA, mais le produit de cache sur disque reste sur les serveurs de DeepSeek. Vous dépendez alors de la couche 2 que vous déployez à sa place. La conclusion opérationnelle ne change pas : ne demandez plus si un modèle gère le cache, mais où il est servi. Cela ne signifie pas que l’architecture n’a aucune importance. Elle fixe le plafond ; le chemin emprunté détermine ce que vous obtenez réellement.

Couche 2 — Le moteur d’inférence : là où le cache est implémenté, gratuitement

À la couche suivante, le problème du cache est déjà résolu, gratuitement. Les moteurs d’inférence modernes mettent automatiquement les préfixes en cache :

• vLLM — Automatic Prefix Caching : calcule le hash de chaque bloc KV, réutilise tout bloc dont le hash de préfixe a déjà été vu et applique une éviction LRU. Activé par défaut dans V1.
• SGLang — RadixAttention : stocke le cache KV dans un arbre radix pour réutiliser chaque préfixe commun, avec un ordonnancement tenant compte du cache.
• TensorRT-LLM — réutilisation des blocs (enable_block_reuse, activée par défaut), avec possibilité de décharger des blocs KV vers la mémoire hôte.

Des projets comme LMCache vont plus loin : ils déchargent le KV vers le CPU ou le disque et le partagent entre plusieurs instances. C’est le début d’une réponse au problème de routage que nous allons rencontrer. Si vous auto-hébergez le modèle, le cache est déjà pris en charge. Il est automatique, ne coûte rien au-delà des GPU déjà en service, applique une éviction LRU et vous appartient. Un hit évite simplement le prefill, ce qui réduit le TTFT et augmente le débit. Aucun champ de facturation cached_tokens n’est nécessaire, puisqu’aucun token n’est facturé ; le gain apparaît dans vos propres métriques de latence. Avec un modèle fermé, vous louez le cache. Avec un modèle ouvert, vous pouvez le posséder. En contrepartie, il est éphémère dans le monde auto-hébergé : il réside en VRAM, avec une éviction LRU, et ne survit que tant que le préfixe reste chaud. Les couches supérieures doivent précisément préserver cette propriété.

Couche 3 — L’hébergeur de calcul : une transformation en produit aux résultats inégaux

Les hébergeurs d’inférence commerciaux encapsulent la couche 2 et exploitent des flottes de réplicas. Ils héritent du cache automatique gratuit. Reste à savoir s’ils l’exploitent correctement, et les résultats varient selon deux axes.

D’abord, l’exposition de la fonction et son prix varient fortement. Parmi les principaux hébergeurs de modèles à poids ouverts, l’un applique une remise fixe de 50% sur l’input en cache et exclut les tokens correspondants des rate limits ; un autre applique par défaut une remise de 50% en serverless ; un troisième fixe le tarif par modèle, par exemple environ 80% de remise pour une gamme Qwen, et expose un indicateur de clé de cache pour améliorer l’affinité ; un quatrième active toujours le cache sur les endpoints dédiés sans permettre de le désactiver. Même moteur sous-jacent, quatre politiques tarifaires.

Ensuite, c’est ici que le cache commence à casser : le problème des réplicas multiples. Votre préfixe chaud réside dans la VRAM du réplica qui a traité la requête froide. Le load balancer de l’hébergeur peut envoyer la requête suivante vers un autre réplica dont le cache est froid. C’est exactement ce que nous avons observé en fixant un même modèle Qwen sur un seul upstream à la fois, puis en exécutant une séquence froid→chaud :

Provider A a correctement utilisé et signalé le cache. Provider B, qui annonce pourtant un tarif de lecture du cache pour ce modèle, n’a appliqué aucune remise sur un appel froid suivi de deux appels chauds pendant notre test. Cela peut venir des critères d’éligibilité, de la répartition entre réplicas ou d’un préchauffage nécessitant plus de deux requêtes. Le résultat mesuré sur ce chemin reste nul. La fonction est maîtrisée à la couche 2 ; sa disponibilité réelle dépend de l’implémentation de la couche 3, qui varie selon l’hébergeur.

Couche 4 — La gateway : le problème multi-clusters

Une gateway se place devant un ou plusieurs upstreams et transforme le problème des réplicas en problème de clusters. Si elle distribue les requêtes en round-robin entre plusieurs clusters ou fournisseurs sans affinité de cache, le cache chaud devient structurellement inaccessible : chaque requête arrive là où le préfixe n’existe pas. Une gateway consciente du cache doit router selon le hash du préfixe, afin que les préfixes identiques restent attachés au même upstream, comme la couche 2 les associe aux mêmes blocs KV. Ce principe vaut aussi bien pour un logiciel que vous exploitez, comme LiteLLM, que pour un service hébergé. Les compromis opérationnels sont détaillés dans LiteLLM face à une gateway managée.

Nous avons exécuté une série de tests froid→chaud sur plusieurs modèles à poids ouverts via une gateway tierce, en lisant directement le cost de chaque requête :

DeepSeek-V4 a atteint 97–99%, ce qui montre que l’affinité fonctionnait de bout en bout. qwen3.5-plus et qwen3-max ont affiché environ 0% sur l’appel chaud, malgré la présence d’un tarif de lecture du cache dans le catalogue. Ce tableau révèle deux autres points concernant les gateways :

• Le champ d’usage peut mentir ; le coût, non. cached_tokens indiquait 0 pour tous les appels, y compris ceux dont le coût avait baissé de 99%. De nombreuses gateways compatibles OpenAI ne renseignent pas le champ des tokens en cache lorsque l’upstream applique un cache automatique. Contrôlez l’écart de cost entre un appel froid et un appel chaud, pas le champ de tokens. C’est la même méthode que pour auditer les affirmations d’une gateway sur son cache.
• La latence baisse même lorsque le coût ne change pas. Tous les appels chauds étaient 2–10× plus rapides, y compris ceux dont la remise était proche de 0%. qwen3.5-flash est passé de 10.2s à 1.0s. Un hit évite le prefill, quelle que soit la politique tarifaire de l’hébergeur. Le cache peut donc améliorer le TTFT via une gateway sans réduire la facture.

Une gateway qui ne préserve pas l’affinité vous donne un cache inaccessible ; si elle n’expose pas son coût, elle vous donne un cache invérifiable.

Couche 5 — Le routeur : répartition aléatoire entre fournisseurs

Tout en haut, un routeur multi-fournisseurs répartit un même ID de modèle entre les clusters de plusieurs entreprises. Chacun possède un cache distinct. Même une affinité parfaite chez un fournisseur ne suffit plus : si le premier appel arrive chez un fournisseur et le deuxième chez un autre, aucun cache n’est partagé. C’est la dispersion décrite au début de cet article. Elle amplifie le problème de la couche 4 : il ne s’agit plus seulement de clusters multiples, mais de fournisseurs différents, avec des états de cache et des tarifs distincts. Le choix le plus cher facturait 20× le tarif de base de l’upstream le moins cher. Le cache n’a commencé à fonctionner que lorsque le routage a fini par rester chez le même fournisseur.

La solution consiste à supprimer cette part d’aléatoire. Le routage doit être déterministe afin que les préfixes répétés retrouvent le même cache chaud :

# Pin the upstream; otherwise load-balancing scatters you across disjoint caches.
# (field names follow a common multi-provider router's API)
import requests

requests.post(f"{ROUTER_BASE}/chat/completions",
  headers={"Authorization": f"Bearer {API_KEY}"},
  json={
    "model": "qwen/qwen3.5-35b-a3b",
    "messages": messages,
    "usage": {"include": True},              # return cost + cached_tokens
    "provider": {                            # the part that makes caching work
        "order": ["<your-chosen-upstream>"],
        "allow_fallbacks": False,
    },
  })

Le routeur signalait correctement cached_tokens, avec 4,224 lors du hit, ainsi que le cost de chaque requête. Il permet donc de vérifier les deux, contrairement à la gateway de couche 4 qui renvoyait 0. Mais c’est à vous de contraindre le routage. Le cache est un problème de routage présenté comme une fonction tarifaire : il est gratuit à la couche 2, tandis que les couches 3, 4 et 5 offrent trois façons de plus en plus radicales de vous en éloigner.

Jusqu’où va la remise ? Elle varie énormément

Lorsque le routage est correctement aligné, combien économisez-vous ? Pour les modèles fermés, la remise sur la lecture du cache tourne généralement autour de 90%. Pour les poids ouverts, les tarifs publiés vont du geste symbolique à une remise presque totale, y compris au sein de la gamme d’un même fournisseur. Voici les tarifs publiés par les fournisseurs directs :

Le cache automatique sur disque de DeepSeek offre la remise la plus forte du marché. Pour deepseek-v4-flash, l’input en cache est facturé $0.0028/M contre $0.14/M en cas de miss, soit un rapport de 1:50. Notre test de couche 4 a reproduit une remise de 97.9%. Les hébergeurs tiers de ces mêmes poids ouverts fixent indépendamment le tarif des inputs en cache : certains appliquent environ 50% de remise à tous les modèles, tandis que d’autres proposent entre ~50% et ~90% selon le modèle. La remise dépend donc de l’hébergeur choisi, pas seulement du modèle. Une même fonction peut présenter un écart de 48 points.

Puisque la remise dépend de la plateforme, un même modèle présente des conditions économiques différentes selon l’endroit où il est servi. Pour deepseek-v4-pro, nous en avons relevé quatre :

« DeepSeek-V4-Pro prend en charge le cache » est exact, mais presque inutile. La vraie question opérationnelle est : « où le prend-il en charge, à quel tarif et avec quels champs de reporting ? »

Checklist de décision

• ✅ Le modèle fixe le plafond, pas le cache (couche 1). Son architecture d’attention, MLA ou GQA, détermine jusqu’où le coût du cache peut baisser, mais ne sert jamais elle-même un token en cache. Il faut donc toujours vérifier où le modèle est servi et ce que fait la stack de cet hébergeur.
• ✅ En auto-hébergement, le cache est déjà gratuit (couche 2). Vérifiez que le cache automatique des préfixes est actif, ce qui est le cas par défaut dans vLLM/SGLang, et surveillez le taux de hit des préfixes.
• ✅ Chez un hébergeur de calcul, vérifiez le résultat, pas la colonne tarifaire (couche 3). Un tarif de lecture du cache reste une promesse ; mesurez l’écart de coût entre un appel froid et un appel chaud. Utilisez un indicateur d’affinité de clé de cache lorsque l’hébergeur en propose un.
• ✅ Via une gateway, exigez un routage avec affinité de cache et un reporting des coûts (couche 4). Si les préfixes identiques ne restent pas attachés au même upstream, ou si le cost ne baisse pas sur un appel chaud, le cache est inaccessible ou invérifiable.
• ✅ Sur un routeur, fixez l’upstream (couche 5). Contraignez le routage, par exemple avec un ordre de fournisseurs et les fallbacks désactivés. Sinon, le load balancing entre caches distincts vous fait perdre les hits et peut vous envoyer vers un upstream 20–50× plus cher.
• ✅ Évaluez séparément la latence et le coût. Les prefills chauds sont 2–10× plus rapides même lorsque la remise est proche de 0.
• ✅ Surveillez les caches assortis de frais de stockage. Les caches loués, comme Moonshot moonshot-v1 et Gemini explicite, facturent le temps de conservation par token même lorsqu’ils sont inactifs ; les caches automatiques de préfixes n’ont pas de frais de stockage.

Conclusion

Pour un modèle fermé, la question « gère-t-il le cache ? » n’a qu’une réponse. Pour les poids ouverts, le problème est résolu depuis des années au niveau du moteur d’inférence : vLLM et SGLang mettent automatiquement et gratuitement chaque préfixe en cache. Toutes les couches supérieures ne sont que de la tuyauterie qui préserve le hit ou vous en éloigne : load balancer de réplicas chez l’hébergeur, routage entre clusters dans la gateway, répartition aléatoire entre fournisseurs dans le routeur. L’architecture du modèle fixe le coût minimal du cache. MLA et GQA apportent de vrais gains au niveau du modèle, mais le chemin suivi par la requête détermine le résultat réel. Traitez le comportement du cache comme une propriété du routage : mesurez son coût sur le chemin exact que vous utiliserez, fixez la route pour retrouver le cache que vous avez préchauffé et gardez en tête que la meilleure remise du marché ne vaut rien si la deuxième requête arrive là où la première n’est jamais passée.

Pour comprendre les mécanismes qui expliquent pourquoi un cache KV existe et comment fonctionnent les TTL, commencez par Comprendre le cache KV et les TTL ; pour contrôler les affirmations d’une gateway sur son cache, consultez Votre gateway LLM ment-elle sur son cache ?.

FAQ

Les modèles à poids ouverts prennent-ils en charge le cache de prompt ? Les poids déterminent jusqu’où le coût du cache peut baisser : les architectures d’attention comme MLA et GQA réduisent la taille du cache KV. Mais le cache lui-même, la remise et l’API viennent de la stack d’inférence. Le moteur d’inférence, comme vLLM, SGLang ou TensorRT-LLM, implémente le cache. Les hébergeurs de calcul en héritent, puis les gateways et routeurs le transmettent ou dispersent les requêtes. Déployez le même checkpoint chez trois hébergeurs et vous pourrez obtenir un cache automatique gratuit, aucun cache ou uniquement un mode explicite.

Pourquoi le même modèle a-t-il coûté 49× plus cher sur un appel que sur un autre ? Sur un routeur multi-fournisseurs, une requête dont l’upstream n’est pas fixé est répartie entre les clusters de plusieurs fournisseurs, avec des tarifs de base différents et des caches non partagés. Un appel froid est arrivé chez un fournisseur cher ; un autre appel chaud chez un fournisseur bon marché. Fixez l’upstream, en contraignant l’ordre des fournisseurs et en désactivant les fallbacks, pour maîtriser les deux.

Dois-je payer le cache si j’auto-héberge le modèle ? Non. Le cache automatique des préfixes dans vLLM, SGLang et TensorRT-LLM est activé par défaut et gratuit : un hit évite simplement le prefill. Vous payez uniquement les GPU déjà en service. Le cache vous appartient et les entrées sont évincées par LRU lorsque la VRAM est nécessaire.

L’API indique cached_tokens: 0, mais ma facture a baissé. Le cache a-t-il fonctionné ? Probablement. De nombreuses gateways ne renseignent pas cached_tokens pour les upstreams qui appliquent un cache automatique. Fiez-vous au champ cost : une forte baisse entre un appel froid et un appel chaud identique indique un hit.

Quel modèle à poids ouverts offre la meilleure remise sur le cache ? Le cache automatique sur disque de DeepSeek. Pour deepseek-v4-flash, l’input en cache coûte ~$0.0028/M contre $0.14/M hors cache, soit environ 98% de remise. Nos tests froid→chaud ont reproduit 97.9–99.2% sur la gamme V4. De nombreux hébergeurs tiers n’appliquent qu’une remise fixe d’environ 50%.

Les caches assortis de frais de stockage ont-ils un inconvénient ? Oui. Le cache explicite de Moonshot moonshot-v1 et celui de Gemini facturent la durée de conservation par token, soit environ $1–4.50 / 1M-tokens / heure pour Gemini. Un cache inactif que vous avez oublié de supprimer continue donc d’être facturé. Les caches automatiques de préfixes n’ont pas de frais de stockage.

Vérification : coûts et latences réels mesurés le 2026-06-14 sur un routeur multi-fournisseurs et notre propre gateway, avec un prompt fixe d’environ 4.7K tokens, un faible max_tokens et des exécutions séquentielles froid→chaud ; remises calculées à partir du cost renvoyé pour chaque requête. Les tarifs documentés et les mécanismes de cache ont été vérifiés le même jour dans les sources primaires des fournisseurs, puis soumis à une contre-vérification contradictoire. Certains tarifs, notamment ceux du cache explicite de Moonshot, changent souvent : vérifiez les valeurs actuelles avant de les citer. Vos résultats varieront selon le fournisseur, le prompt, la région et la charge.

Sources

• DeepSeek — Tarifs
• DeepSeek — Guide du cache KV et du cache de contexte
• Rapport technique DeepSeek-V3 — MLA et compression du cache KV
• GQA : entraînement de modèles Transformer Multi-Query généralisés (Ainslie et al.)
• Alibaba Cloud Model Studio — cache de contexte et tarifs
• Moonshot AI — Cache de contexte
• Zhipu / Z.AI — Tarifs et cache
• vLLM — Cache automatique des préfixes
• SGLang — RadixAttention et cache
• LMCache — Déchargement et partage du cache KV
• Google — Cache de contexte Gemini

Toutes les sources ont été vérifiées le 2026-06-14. Ceci ne constitue pas un conseil financier ; vérifiez les tarifs en vigueur avant de vous y fier.

← Retour au blog