Dérive des fournisseurs : quand le routage par défaut gonfle le coût des LLM

Vous avez activé le prompt caching. Le compteur de hits s’incrémente de temps en temps, mais votre facture ne baisse presque pas. Avant d’accuser la structure de vos prompts, examinez une information que le dashboard masque : quel backend a réellement traité chaque requête.

Les gateways multi-fournisseurs répartissent un même modèle entre plusieurs fournisseurs en amont et en choisissent un à chaque requête. Les prompt caches sont propres à chaque fournisseur, et souvent à chaque nœud chez un même fournisseur. Si votre deuxième requête, pourtant identique, arrive sur un autre backend que la première, elle produit un cache miss alors que votre prompt n’a pas changé d’un octet. C’est la dérive des fournisseurs. Avec une tarification au token, elle multiplie discrètement les coûts.

TL;DR

• Avec le routage configuré par défaut, une gateway multi-fournisseurs a réparti 20 appels identiques entre 9 backends et n’a obtenu que 4 hits sur le prompt cache.
• Une gateway reposant sur un seul backend a obtenu 19 hits sur 20 avec la même charge. La dérive a multiplié le coût du test par environ 3,9 ($0.0102 contre $0.0026).
• Sur le modèle de la famille DeepSeek testé, un cache miss coûtait environ 4 fois plus cher qu’un hit ($0.00062 contre une médiane de $0.00015 par appel).
• La dérive dépend du modèle : sur la même gateway, un modèle de classe GPT a été routé vers un seul backend pour les 20 appels et a obtenu 19 hits sur 20.

Les deux conditions qui déclenchent la dérive

Vous n’avez pas choisi une mauvaise configuration. C’est le comportement fourni par défaut :

1. Routage automatique par défaut. La requête est envoyée au modèle sans imposer de backend. La gateway en choisit donc un à chaque appel.
2. Tri des fournisseurs par défaut = « default (balanced) ». La gateway répartit la charge entre les backends éligibles au lieu de rester sur le même.

Ce sont les réglages d’usine. La dérive ne nécessite aucune intervention ; c’est pour l’éviter qu’il faut modifier la configuration.

À quoi ressemblent 20 requêtes identiques

Nous avons envoyé exactement le même préfixe d’environ 8K tokens 20 fois de suite à une gateway multi-fournisseurs populaire, avec les réglages par défaut ci-dessus. À chaque appel, nous avons demandé les champs indiquant le fournisseur et l’état du cache tels que rapportés par le backend. Pour un modèle de la famille DeepSeek utilisant un cache disque :

• Les 20 appels ont été traités par 9 backends distincts : N***a, S***w, M***h, D***a, A***L, P***l, S***e, V***e, A***d.
• Taux de hit du cache : 4/20 (20 %). Un hit ne se produisait que lorsque l’appel tombait par hasard sur un backend qui avait déjà mis le préfixe en cache.

Sur une gateway avec un seul backend — un modèle, un backend, aucun équilibrage — les mêmes 20 appels atteignent un taux de hit de 19/20 (95 %). Même modèle, même prompt, même nombre d’appels. La seule variable est la dérive du routage.

À titre de comparaison, sur cette même gateway multi-fournisseurs, un modèle de classe GPT a été routé vers un seul backend (A***e) pendant les 20 appels et a obtenu 19/20. La dérive n’est pas uniforme. Elle touche les modèles que la gateway répartit entre plusieurs backends. Lors de ce test, c’était le modèle de la famille DeepSeek.

Conclusion A : le coût attendu face au coût réel

Sur le modèle soumis à la dérive, le coût par appel se séparait clairement selon le résultat du cache :

Sur ce modèle, un miss coûte environ 4 fois plus cher qu’un hit. L’écart publié sur les seuls tokens d’entrée est encore plus important, autour de 50 fois. Voici le total pour les 20 appels :

Même modèle, même prompt, mêmes 20 requêtes. La dérive des fournisseurs a rendu le test environ 3,9 fois plus cher. Le cache est resté activé pendant toute l’opération, mais la couche de routage a facturé la plupart des tokens au tarif d’un miss. Sur un endpoint de production qui réutilise toute la journée un long préfixe stable, cet écart représente l’essentiel des dépenses liées aux tokens d’entrée.

Conclusion B : sans cache, aucun gain de latence

Le cache ne réduit pas seulement les coûts. Avec un prefill déjà en cache, le premier token arrive plus vite. Lorsque la dérive rend le cache inaccessible, ce gain disparaît lui aussi. Nous avons mesuré le délai avant le premier token (TTFT) sur plusieurs appels identiques :

Modèle de classe GPT (routé systématiquement vers le même backend, cache accessible) :

Le cache accélère l’arrivée du premier token d’environ 36 %, avec des résultats réguliers : tous les appels à chaud restent dans une plage étroite.

Modèle de la famille DeepSeek (dérive par défaut, cache rarement accessible) :

• Hits du cache sur 10 appels répétés : 0.
• Le TTFT variait de ~1000 ms à ~4500 ms d’un appel à l’autre, avec parfois des réponses vides.

Comme presque chaque requête aboutit sur un nouveau backend, la latence reste celle d’un prefill à froid, à laquelle s’ajoute la variabilité du fournisseur qui répond. Grâce à un cache accessible, le modèle GPT a réduit son TTFT de 36 %. Le modèle soumis à la dérive n’a bénéficié d’aucune amélioration, et son appel le plus lent a pris 4,5 fois plus de temps que le plus rapide.

Auditez votre configuration en cinq minutes

Ne vous fiez pas à ces chiffres, ni à ceux de qui que ce soit. Envoyez plusieurs fois le même long préfixe et surveillez deux champs. Aucun domaine n’est codé en dur : utilisez les variables d’environnement pour cibler votre propre gateway.

import os, uuid
from openai import OpenAI

client = OpenAI(api_key=os.environ["GW_KEY"], base_url=os.environ["GW_BASE"])
SYS = f"[probe {uuid.uuid4().hex}]\n\n" + ("You are a support assistant. " * 300)

seen, hits = {}, 0
for i in range(20):
    r = client.chat.completions.create(
        model=os.environ["GW_MODEL"], max_tokens=16,
        messages=[{"role": "system", "content": SYS},
                  {"role": "user", "content": f"q{i}"}],
        extra_body={"usage": {"include": True}})
    d = r.model_dump()
    det = r.usage.prompt_tokens_details
    cached = (getattr(det, "cached_tokens", 0) or 0) if det else 0
    seen[d.get("provider")] = seen.get(d.get("provider"), 0) + 1   # populated when exposed
    hits += 1 if cached else 0

print(f"hit rate {hits}/20; upstreams seen: {len(seen)}")

Si un même modèle passe par plusieurs backends, il y a dérive. Si le taux de hit est nettement inférieur à ce que permet la stabilité de vos prompts, cette dérive vous coûte de l’argent. La méthode complète est décrite dans Votre gateway LLM ment-elle sur le cache ?.

Points à vérifier

La solution est structurelle : pour un modèle donné, routez les requêtes vers un backend stable afin que le cache chaud reste accessible lors de l’appel suivant. Évitez de répartir chaque appel vers un nouveau backend qui n’a jamais vu votre préfixe. Pour évaluer une gateway, envoyez 20 fois le même préfixe et comptez les backends. Un seul est le résultat recherché. Neuf représentent un surcoût.

Le prompt caching reste toutefois un mécanisme best-effort. Sur les modèles utilisant un cache disque, le taux de hit diminue après de longues périodes d’inactivité, même avec un seul backend. Supprimer la dérive ne rend pas le cache infini. Cela élimine simplement la principale source de miss inutiles, celle que vous n’avez pas choisie et que vous ne pouvez pas voir.

Conclusion

« Prend en charge le prompt caching » et « votre cache est accessible » sont deux affirmations différentes. Une gateway peut répartir un modèle sur une série de backends et annoncer honnêtement la prise en charge du cache, tout en ne fournissant que 20 % de hits, une facture multipliée par environ 4 et un délai avant le premier token variant d’un facteur 4,5. Ne surveillez pas seulement la prise en charge annoncée du cache. Mesurez votre taux de hit et le nombre de backends touchés par des requêtes identiques. Exécutez le test et fiez-vous aux données.

Pour la méthode d’audit complète, consultez Votre gateway LLM ment-elle sur le cache ?. Pour comprendre le rôle des caches, consultez Fonctionnement du KV cache et du TTL.

FAQ

S’agit-il d’une mauvaise configuration de mon côté ? Non. Ce comportement se produit avec les réglages d’usine : routage automatique et tri des fournisseurs laissé sur « default (balanced) ». Pour éviter la dérive, vous devez explicitement imposer un backend.

Imposer un seul backend suffit-il ? Cela supprime la dérive entre fournisseurs, mais un backend unique exécute souvent plusieurs réplicas sans affinité de préfixe. Les hits peuvent donc encore être irréguliers. Mesurez les résultats après avoir imposé le backend au lieu de partir du principe que le problème est réglé.

Pourquoi le modèle de classe GPT n’a-t-il pas subi de dérive ? Lors de ce test, la gateway l’a routé vers un seul backend. La dérive dépend du modèle et du nombre de backends éligibles entre lesquels la gateway répartit la charge. Elle n’est pas uniforme.

L’écart de coût est-il vraiment d’environ 4 fois ? D’après les coûts totaux par appel que nous avons mesurés, un miss coûtait environ 4 fois plus cher qu’un hit. D’après les tarifs publiés des tokens d’entrée pour cette catégorie de modèles, l’écart entre hit et miss est plutôt proche de 50 fois. Dans les deux cas, transformer des hits attendus en miss est ce qui coûte cher.

Quelle métrique faut-il surveiller en priorité ? Le taux de hit du cache par modèle dans le temps, avec le nombre de backends distincts utilisés par chaque modèle. Si le taux de hit baisse ou si le nombre de backends augmente, votre coût effectif par token vient d’augmenter.

← Retour au blog