Mise en cache des LLM open-weight : pourquoi la vôtre est une roulette de fournisseurs

Avec un modèle fermé, la mise en cache des prompts est un contrat documenté unique. Claude dispose de points d’arrêt cache_control ; OpenAI et Gemini mettent en cache automatiquement au-delà d’un seuil de tokens ; les remises sont publiées et stables. Vous lisez une page et c’est réglé.

Les poids ouverts brisent cette hypothèse. Le même checkpoint Qwen ou Llama est servi par une douzaine d’hébergeurs, et la mise en cache n’est pas une propriété du modèle — c’est une propriété de l’endroit où le modèle s’exécute. Pour montrer jusqu’où cela va, voici une requête mesurée — un prompt identique d’environ 4 700 tokens envoyé au même modèle Qwen via un routeur multi-fournisseurs six fois, sans épinglage d’upstream :

Même modèle, même routeur, même prompt : la facture a varié de $0.0141 à $0.000286 — un écart de 49× — uniquement selon l’upstream choisi par le routeur et selon que cet upstream avait le préfixe en cache chaud.

Résumé

• La mise en cache des prompts pour les modèles open-weight est un résultat du routage, pas une fonctionnalité du modèle. Elle est implémentée — gratuitement et automatiquement — dans le moteur d’inférence, puis préservée ou détruite par chaque couche au-dessus.
• Cinq couches : une fournit la mise en cache, trois peuvent la briser. Le modèle (définit la mise en cache, ne sert aucun cache) → le moteur d’inférence (mise en cache, gratuite) → l’hébergeur de calcul (la commercialise, de façon inégale) → la passerelle (routage multi-cluster) → le routeur (disperse entre fournisseurs avec des caches disjoints).
• Mesuré. Une requête identique, dispersée par un routeur, a coûté 49× plus cher sur un choix que sur un autre ; sur un modèle, un hébergeur a livré 59,6 % de remise et un autre 0 % ; les remises de cache publiées s’étendent de 0 % à ~98 % selon les modèles.
• Que faire. Épinglez votre route pour que les préfixes répétés atteignent le même cache chaud ; auditez par le delta de coût, pas par le champ cached_tokens (qui affiche souvent 0 lors d’un vrai hit) ; évaluez la latence séparément — les préfills chauds s’exécutent 2 à 10× plus vite même à ~0 % de remise sur le coût.

Les chiffres en direct ont été mesurés le 2026-06-14 sur un routeur multi-fournisseurs et notre propre passerelle, avec un prompt anglais fixe d’environ 4 700 tokens, un petit max_tokens, des exécutions séquentielles. La tarification documentée a été vérifiée contre les docs primaires des fournisseurs le même jour et contre-vérifiée de façon contradictoire. Les ratios (pourcentage de remise, variation de latence) constituent la partie portable ; les dollars absolus dépendent du lieu, de votre prompt et de la charge. Reproduisez avant de citer.

Les types de cache que vous rencontrerez vraiment

Avant d’aborder la pile, quelques définitions. Parmi les hébergeurs de modèles open-weight, il existe quatre formes distinctes de cache, chacune avec sa propre facturation.

1. Cache de préfixe automatique (sans marqueurs). Le modèle dominant. Le serveur hache votre préfixe de prompt, réutilise l’état KV s’il correspond à une requête antérieure, et applique la remise de lui-même — pas de cache_control, pas de modification de code, souvent impossible à désactiver. DeepSeek, Zhihu GLM et la plupart des hébergeurs open-weight fonctionnent ainsi. Les écritures sont gratuites ; le cache vit de la VRAM (quelques minutes) au disque (DeepSeek conserve les préfixes « quelques heures à quelques jours »).

2. Cache à point d’arrêt explicite (cache_control). Le modèle Anthropic, que quelques hébergeurs open-weight proposent également. Le Model Studio d’Alibaba accepte "cache_control": {"type": "ephemeral"} sur un bloc de message Qwen ; certaines plateformes de service exposent un marqueur équivalent. Vous définissez la frontière, payez un surcoût à l’écriture, et obtenez en retour une remise plus importante à la lecture.

3. Objets de cache loués (avec frais de stockage). Celui à surveiller. La famille legacy moonshot-v1 de Moonshot vous oblige à faire un POST /v1/caching pour créer un cache, puis facture des frais d’écriture, des frais de stockage par token par minute, et des frais par appel en cas de hit. Le cache explicite de Gemini chez Google repose sur la même idée — coût d’entrée plus stockage à environ 1,00–4,50 $ par million de tokens par heure. Le cache est une ressource que vous louez et devez gérer vous-même.

4. Réutilisation KV en auto-hébergement (gratuit). Exécutez les poids vous-même et le moteur d’inférence met en cache automatiquement et gratuitement. Pas de frais d’écriture, pas de tarif de lecture, pas de location de stockage — un hit se contente de sauter le prefill.

Qwen sur Model Studio propose les deux modes, automatique et explicite, avec un vrai compromis : le mode implicite facture un hit à 20 % de l’entrée avec des écritures gratuites ; le mode explicite facture un hit à 10 % de l’entrée mais applique 125 % sur l’écriture et limite l’entrée à un TTL de 5 minutes. Remise plus profonde, mais vous payez pour alimenter le cache et payez à nouveau à chaque expiration.

La place du cache dans la pile

Voici l’idée clé. Le cache de prompt pour les modèles open-weight est résolu à exactement une couche et menacé à chaque couche au-dessus. Parcourez la pile depuis les poids vers le haut, et à chaque couche demandez-vous : cette couche fournit-elle du cache, ou se contente-t-elle de le transmettre — et peut-elle briser ce que la couche en dessous a déjà fait ?

  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é de mise en cache, pas un cache

C’est la couche dans laquelle la plupart des gens pensent que la mise en cache réside — « DeepSeek a un cache » — c’est donc la première sur laquelle il faut être précis. Un checkpoint est un ensemble de poids ; il exécute la même attention qu’un cache KV existe ou non. Il ne fournit aucun cache, aucune remise, aucun TTL, aucun marqueur cache_control — ce sont des fonctionnalités de la couche de service. Dans ce sens strict, les poids ne fournissent aucun produit de mise en cache.

Mais les poids ne sont pas neutres, et DeepSeek est l’exemple parfait pour illustrer pourquoi. L’architecture d’attention du modèle détermine la taille du cache KV, et donc le coût minimal que la mise en cache pourra jamais atteindre :

• La Multi-head Latent Attention (MLA) de DeepSeek compresse le cache KV en un latent de faible rang — à environ 4–14 % d’un cache multi-têtes standard. C’est précisément cette compression qui permet à l’API de DeepSeek de persister les préfixes sur disque et de facturer une lecture de cache à ~2 % du prix de l’entrée. L’architecture est le facteur habilitant ; le cache 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 le cache par le facteur de groupe (≈8× sur Llama-3).

La contribution de la Couche 1 est donc la capacité de mise en cache, pas un cache : l’architecture fixe le plafond de ce que chaque couche supérieure peut rendre bon marché en matière de mise en cache, mais les poids ne servent jamais eux-mêmes un token mis en cache. Et « DeepSeek a un cache » amalgame discrètement deux choses différentes portant le même nom — les poids (cette couche, qui vous donnent la MLA) et la pile API et de service de DeepSeek (Couches 2–3, qui vous donnent le cache disque, la remise et les champs d’utilisation). Téléchargez les poids ouverts et exécutez-les vous-même : vous conservez le petit cache KV de la MLA, mais le produit cache disque reste sur les serveurs de DeepSeek — vous héritez de la Couche 2 que vous déployez à la place. La conclusion opérationnelle reste donc valable : cessez de demander si un modèle met en cache et commencez à demander où il est servi — mais ne confondez pas cela avec le fait que l’architecture n’a pas d’importance. Elle fixe le plafond ; le chemin détermine ce que vous obtenez réellement.

Couche 2 — Le moteur d’inférence : là où la mise en cache est construite, et gratuite

Une couche plus haut, la mise en cache n’est pas seulement présente — elle est résolue, et gratuite. Les moteurs d’inférence modernes mettent en cache les préfixes automatiquement :

• vLLM — Automatic Prefix Caching : hache chaque bloc KV, réutilise tout bloc dont il a déjà vu le hash de préfixe, éviction par LRU. Activé par défaut dans la V1.
• SGLang — RadixAttention : stocke le cache KV dans un arbre radix afin que tout préfixe partagé soit réutilisé, avec une planification tenant compte du cache.
• TensorRT-LLM — réutilisation de blocs (enable_block_reuse, activé par défaut), avec déchargement optionnel des blocs KV vers la mémoire hôte.

Des projets comme LMCache vont encore plus loin — déchargeant le KV vers le CPU/disque et le partageant entre instances, ce qui constitue l’ébauche d’une solution au problème de routage que nous allons bientôt aborder. Le point essentiel : si vous hébergez vous-même, c’est terminé. La mise en cache est automatique, ne coûte rien au-delà des GPU que vous faites déjà tourner, s’évince par LRU, et vous en êtes propriétaire — un hit saute simplement le prefill, réduisant le TTFT et augmentant le débit. Il n’existe pas de champ de facturation cached_tokens car rien n’est facturé ; le bénéfice apparaît dans vos propres métriques de latence. Pour un modèle fermé, vous louez la mise en cache ; pour un modèle ouvert, vous pouvez en être propriétaire. L’inconvénient est l’inverse du monde hébergé : le cache est éphémère (VRAM, LRU), il ne survit donc que tant que le préfixe reste chaud — ce qui est précisément ce que les couches supérieures doivent préserver.

Couche 3 — L’hôte de calcul : productisation inégale

Les hôtes d’inférence commerciaux encapsulent la couche 2 et font tourner des flottes de réplicas. Ils héritent du cache automatique gratuit — la question est de savoir s’ils l’implémentent bien, et la réponse est mitigée sur deux axes.

Premièrement, l’exposition et les prix varient énormément. Parmi les principaux hôtes de modèles open-weight : l’un applique un tarif fixe de 50 % sur les entrées mises en cache et permet aux tokens mis en cache de ne pas compter dans les limites de débit ; un autre applique par défaut 50 % de réduction en mode serverless ; un troisième facture les entrées mises en cache selon le modèle (par exemple un palier Qwen à environ 80 % de réduction) et expose un indice de clé de cache pour améliorer l’affinité ; un quatrième rend le cache toujours actif et non divulgable sur les endpoints dédiés. Même moteur sous-jacent, quatre philosophies tarifaires.

Deuxièmement — et c’est le premier endroit où le cache se casse — le problème des réplicas multiples. Votre préfixe chaud réside dans la VRAM du seul réplica qui a traité la requête froide. Le load balancer de l’hôte peut envoyer votre prochaine requête vers un réplica différent avec un cache froid. Nous avons observé exactement cela : en épinglant le même modèle Qwen sur un seul upstream à la fois et en exécutant des séquences froid→chaud :

Le fournisseur A a mis en cache proprement et l’a signalé. Le fournisseur B — qui annonce pourtant un prix de lecture du cache pour ce modèle — n’a retourné aucune réduction sur un appel froid et deux appels chauds lors de notre test. Que ce soit dû à des critères d’éligibilité, à la distribution sur plusieurs réplicas, ou à un temps de préchauffage supérieur à deux requêtes, le résultat mesuré sur ce chemin était nul. La capacité est résolue au niveau de la couche 2 ; la recevoir effectivement est un détail d’exécution de la couche 3, et il diffère selon l’hôte.

Couche 4 — La passerelle : le problème multi-cluster

Une passerelle se place devant un ou plusieurs services amont et transforme le problème de réplicas en problème de cluster. Si elle distribue les requêtes en round-robin entre clusters ou fournisseurs sans affinité de cache, le cache chaud devient structurellement inaccessible — chaque requête atterrit là où le préfixe n’existe pas. Une passerelle consciente du cache doit router par hachage de préfixe, afin que les préfixes identiques soient toujours dirigés vers le même service amont, de la même façon que la Couche 2 les ancre aux mêmes blocs KV.

Nous avons effectué une batterie de tests froid→chaud sur des modèles open-weight via une passerelle tierce, en lisant directement le champ cost par requête :

DeepSeek-V4 a atteint 97–99 % (affinité fonctionnelle de bout en bout) ; qwen3.5-plus et qwen3-max ont renvoyé ~0 % lors de l’appel chaud, malgré un tarif de lecture de cache affiché dans le catalogue. Deux autres enseignements sur les passerelles se cachent dans ce tableau :

• Le champ usage ment ; le coût, non. cached_tokens affichait 0 sur chaque appel ici, y compris pour les baisses de coût à 99 %. De nombreuses passerelles compatibles OpenAI ne renseignent pas le champ de tokens mis en cache pour les services amont qui cachent automatiquement. Auditez via le delta de cost entre un appel froid et un appel chaud, et non via le champ de tokens — même leçon qu’en auditant les déclarations de cache d’une passerelle.
• La latence s’améliore même quand le coût ne bouge pas. Chaque appel chaud était 2 à 10 fois plus rapide — qwen3.5-flash est passé de 10,2s à 1,0s — y compris pour ceux affichant ~0 % de remise. Un hit de cache court-circuite le prefill quelle que soit la façon dont l’hébergeur le facture, donc le cache peut être rentable en TTFT sur une passerelle qui ne vous accorde rien sur la facture.

Une passerelle qui ne préserve pas l’affinité vous offre un cache que vous ne pouvez pas atteindre ; une passerelle qui ne remonte pas le coût du cache vous en offre un que vous ne pouvez pas vérifier.

Couche 5 — Le routeur : distribution aléatoire entre fournisseurs

Au sommet, un routeur multi-fournisseurs répartit la charge d’un même identifiant de modèle sur des clusters d’entreprises différentes — chacun disposant d’un cache séparé. Même une affinité parfaite au sein d’un fournisseur ne peut plus vous sauver : si l’appel 1 est acheminé vers un vendeur et l’appel 2 vers un autre, il n’existe aucun cache partagé à exploiter. C’est la dispersion évoquée en début d’article, et elle s’ajoute à la Couche 4 — non seulement plusieurs clusters, mais plusieurs vendeurs avec un état de cache disjoint et des tarifs disjoints (le choix le plus coûteux facturé 20× le tarif de base de l’upstream le moins cher). Le cache ne s’est activé qu’au moment où le routage s’est retrouvé fixé sur un seul fournisseur.

La solution consiste à éliminer l’aléatoire — rendre le routage déterministe afin que les préfixes répétés atterrissent sur 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,
    },
  })

À son crédit, le routeur a bien renvoyé cached_tokens (4 224 lors du hit) ainsi qu’un cost par requête, ce qui permet de vérifier les deux — mieux que la passerelle de Couche 4 qui affichait 0. Mais c’est à vous de contraindre le routage. Le cache est un problème de routage déguisé en fonctionnalité tarifaire : le cache est gratuit à la Couche 2, et les Couches 3, 4 et 5 sont trois façons progressivement plus graves de s’en éloigner par le routage.

Quelle est la profondeur de la remise ? C’est très variable

Lorsque le routage s’aligne correctement, combien économisez-vous ? Pour les modèles fermés, la remise sur la lecture en cache se concentre autour de 90 %. Pour les poids ouverts, le prix publié de lecture en cache va d’un geste symbolique à la quasi-totalité, même au sein de la gamme d’un seul vendeur. Tarifs publiés en première partie :

Le cache disque automatique de DeepSeek est le plus avantageux du marché — deepseek-v4-flash lit l’entrée mise en cache à 0,0028 $/M contre 0,14 $/M en cas de miss, soit un ratio de 1:50, que notre test de Couche 4 a reproduit à 97,9 %. Les hébergeurs tiers de ces mêmes poids ouverts tarifent l’entrée mise en cache de manière indépendante — certains appliquent un taux fixe d’environ 50 %, d’autres varient de ~50 % à ~90 % selon le modèle — si bien que la remise obtenue dépend de l’hébergeur sur lequel vous atterrissez, pas seulement du modèle. Même nom de fonctionnalité, 48 points d’écart.

La remise étant une propriété de la plateforme, un même modèle présente des économies de cache différentes partout où il est servi. deepseek-v4-pro, quatre façons :

« DeepSeek-V4-Pro prend en charge le cache » est vrai et presque inutile ; la vraie question opérationnelle est : « prend en charge le cache où, à quel taux, rapporté comment ».

Une liste de contrôle décisionnelle

• ✅ Le modèle fixe le plafond, pas le cache (Couche 1). Son architecture d’attention (MLA, GQA) détermine à quel point la mise en cache peut être économique, mais elle ne sert jamais un token mis en cache — demandez donc toujours où il est servi et ce que fait la pile de cet hôte.
• ✅ Auto-hébergement ? Vous l’avez déjà gratuitement (Couche 2). Confirmez que la mise en cache automatique des préfixes est activée (c’est le cas par défaut dans vLLM/SGLang) et surveillez votre taux de succès de préfixe.
• ✅ Sur un hôte de calcul, vérifiez la livraison, pas la colonne des prix (Couche 3). Un prix de lecture de cache est une affirmation ; mesurez un delta de coût froid→chaud. Utilisez un indice d’affinité de clé de cache là où l’hôte en propose un.
• ✅ Via une passerelle, exigez un routage par affinité de cache et des rapports de coûts (Couche 4). Si des préfixes identiques ne sont pas acheminés vers le même upstream, ou si cost ne diminue pas lors d’un appel chaud, le cache est inaccessible ou invérifiable.
• ✅ Sur un routeur, fixez l’upstream (Couche 5). Contraignez le routage (par exemple, un champ d’ordre de fournisseur avec les basculements désactivés), sinon vous perdez des succès au profit d’un équilibrage de charge entre des caches disjoints — et risquez un upstream 20 à 50× plus coûteux.
• ✅ Évaluez la latence séparément du coût. Les préfills chauds sont 2 à 10× plus rapides, même lorsque la remise en dollars est ~0.
• ✅ Méfiez-vous des types de cache à frais de stockage. Les caches loués (Moonshot moonshot-v1, Gemini explicite) facturent par token-temps pour un cache inactif ; les caches automatiques de préfixes, non.

Conclusion

Pour les modèles fermés, « est-ce qu’il met en cache ? » a une seule réponse. Pour les poids ouverts, la capacité a été résolue il y a des années au niveau du moteur d’inférence — vLLM et SGLang mettent en cache chaque préfixe, gratuitement, automatiquement. Tout ce qui se trouve au-dessus de cette couche est de la plomberie qui soit préserve le succès, soit vous en éloigne : l’équilibreur de répliques d’un hôte de calcul, le routage de cluster d’une passerelle, la répartition aléatoire d’un routeur entre fournisseurs. L’architecture du modèle fixe le plafond de l’économie possible de la mise en cache — MLA et GQA sont de vraies avancées au niveau du modèle — mais le chemin emprunté par votre requête détermine ce que vous obtenez réellement. Traitez le comportement du cache comme une propriété de routage — mesurez-le en termes de coût sur le chemin exact que vous utiliserez, fixez la route pour que le cache que vous avez préchauffé soit celui que vous atteignez, et rappelez-vous que la remise la plus profonde du monde ne vaut rien si la deuxième requête atterrit là où la première n’a jamais été.

Pour comprendre pourquoi un cache KV existe et comment fonctionnent les TTL, commencez par How KV Cache & TTL Work ; pour auditer les affirmations de cache d’une passerelle, consultez Does Your LLM Gateway Lie About Cache?.

FAQ

Les modèles open-weight supportent-ils le prompt caching ? Les poids déterminent le coût minimal du cache — les architectures d’attention comme MLA et GQA réduisent le KV cache — mais le cache lui-même, la remise, et l’API proviennent de la couche de service. Le caching est implémenté dans le moteur d’inférence (vLLM, SGLang, TensorRT-LLM), hérité par les hôtes de calcul, et transmis (ou dispersé) par les passerelles et les routeurs. Déployez le même checkpoint sur trois hôtes et vous pouvez obtenir un caching automatique gratuit, aucun caching, ou un caching explicite uniquement.

Pourquoi le même modèle a-t-il coûté 49× plus cher lors d’un appel que lors d’un autre ? Sur un routeur multi-fournisseur, une requête non épinglée est répartie entre les clusters de différents fournisseurs avec des prix de base différents et des états de cache disjoints. Un appel a touché un fournisseur coûteux à froid ; un autre a touché un fournisseur bon marché à chaud. Épinglez l’upstream (contraignez l’ordre des fournisseurs, désactivez les fallbacks) pour contrôler les deux.

Si je m’auto-héberge, dois-je payer pour le caching ? Non. Le caching automatique de préfixe dans vLLM, SGLang et TensorRT-LLM est activé par défaut et gratuit — un hit évite simplement le prefill. Vous payez uniquement pour les GPU que vous faites déjà tourner, et le cache vous appartient, évincé par LRU lorsque la VRAM est nécessaire.

L’API indique cached_tokens: 0 mais ma facture a baissé — le caching a-t-il fonctionné ? Probablement oui. De nombreuses passerelles ne renseignent pas cached_tokens pour les upstreams qui cachent automatiquement. Fiez-vous au champ cost : une forte baisse entre un appel à froid et un appel à chaud identique signifie que le cache a été touché.

Quel modèle open-weight offre la remise de cache la plus importante ? Le cache disque automatique de DeepSeek : deepseek-v4-flash lit les entrées cachées à ~$0.0028/M contre $0.14/M sans cache (~98% de réduction), reproduit à 97,9–99,2% sur toute la gamme V4 dans nos tests cold→warm. De nombreux hôtes tiers appliquent un forfait de ~50% à la place.

Y a-t-il un inconvénient avec les caches qui facturent des frais de stockage ? Oui — le cache explicite moonshot-v1 de Moonshot et le cache explicite de Gemini facturent par token-temps pour maintenir le cache actif (Gemini ~$1–4,50 / 1M-tokens / heure). Un cache inactif que vous avez oublié de supprimer continue de facturer. Les caches à préfixe automatique n’ont pas de frais de stockage.

Vérification : les chiffres de coût/latence en direct ont été mesurés le 2026-06-14 sur un routeur multi-fournisseur et notre propre passerelle, en utilisant un prompt fixe de ~4,7K tokens, un petit max_tokens, des exécutions séquentielles cold→warm ; les remises sont calculées à partir du cost par requête retourné. La tarification documentée et les mécanismes de cache ont été vérifiés auprès des docs des fournisseurs primaires le même jour et contre-vérifiés de manière contradictoire ; quelques chiffres de fournisseurs (notamment les frais de cache explicite de Moonshot) évoluent fréquemment — confirmez les valeurs actuelles avant de les citer. Vos chiffres varieront selon le fournisseur, le prompt, la région et la charge.

Sources

• DeepSeek — Pricing
• DeepSeek — KV cache / Context Caching guide
• DeepSeek-V3 Technical Report — MLA (KV-cache compression)
• GQA: Training Generalized Multi-Query Transformer Models (Ainslie et al.)
• Alibaba Cloud Model Studio — context cache & pricing
• Moonshot AI — Context Caching
• Zhipu / Z.AI — pricing & caching
• vLLM — Automatic Prefix Caching
• SGLang — RadixAttention / cache
• LMCache — KV cache offloading & sharing
• Google — Gemini context caching

Tous vérifiés le 2026-06-14. Ceci ne constitue pas un conseil financier ; vérifiez les tarifs actuels avant de vous y fier.

← Retour au blog