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

TL;DR — Choisir le « meilleur » LLM n’est pas une simple question de benchmark : tout dépend de ce que vous déployez, un chatbot, une API RAG/batch ou un agent IA. Chaque forme a une structure de prompt, un profil de taux de réussite, une adéquation au TTL et une tolérance à la latence différents, ce qui impose un appariement optimal différent entre modèle et stratégie de cache. Ce guide s’appuie sur les chiffres mesurés dans la Partie 3 — même passerelle, même SDK OpenAI, on change simplement le champ model à chaque appel.

Série : Partie 4 sur 4 · Précédemment : Partie 1 — Principes de mise en cache · Partie 2 — Comparaison et évaluation des fournisseurs · Partie 3 — Tutoriel de code opérationnel

0. La formule de coût universelle

Avant de plonger dans les cas d’usage, voici l’équation que chaque choix devrait optimiser :

per-call cost = (input_uncached × P_in)
              + (input_cached   × P_in × cache_discount)
              + (output × P_out)

per-call TTFT ≈ prefill_time × (1 - hit_rate)
              + decode_time

Quatre leviers :

1. Baisser le prix unitaire (P_in / P_out) → choisir un modèle moins cher.
2. Augmenter le taux de réussite → restructurer votre prompt ; aligner le TTL sur la cadence de votre trafic.
3. Baisser le coefficient de remise du cache → choisir un fournisseur avec une mise en cache plus performante.
4. Choisir un fournisseur dont le préremplissage en cache est le plus rapide → la latence compte pour l’UX.

Chaque cas d’usage ci-dessous actionne ces leviers différemment.

Cas d’usage 1 : chatbots, support client et assistants

Profil de trafic

• Chaque requête = long prompt système (persona + connaissances + règles) + historique multi-tours + nouveau message utilisateur.
• Contexte moyen : 4K–20K tokens.
• Les utilisateurs sont extrêmement sensibles au temps jusqu’au premier token (>2 s donne une impression de panne).
• Au sein d’une session, les requêtes s’enchaînent de quelques secondes à quelques minutes d’écart — largement dans le TTL du cache de n’importe quel fournisseur.

Pourquoi le chat se met en cache presque tout seul

Le chat est la charge de travail la plus propice à la mise en cache. Au sein d’une même session :

Request 1: [system: 8K] + [history: 0]   + [user: Q1]
Request 2: [system: 8K] + [history: 200] + [user: Q2]
Request 3: [system: 8K] + [history: 400] + [user: Q3]
           ↑──────── prefix is monotonically growing ────────↑

Si les intervalles entre messages restent sous le TTL (quelques minutes chez tous les fournisseurs), la partie du prompt système dépasse 90 % de taux de réussite sans effort. Vous n’avez pas besoin de keep-alive.

Recommandations de modèles (mesurées en 2026-05)

* Mesuré sur un prompt système stable de 7 300 tokens, exécution séquentielle unique, sans charge concurrente. Voir Partie 3 §6 pour le tableau complet.

Code de production minimal

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

def chat(history: list, user_msg: str):
    return client.chat.completions.create(
        model="gpt-5.4-mini",
        max_tokens=512,
        messages=[
            {"role": "system", "content": STABLE_SYSTEM_PROMPT},   # front
            *history,                                              # middle
            {"role": "user", "content": user_msg},                 # back
        ],
    )

C’est tout. La mise en cache est automatique pour tous les modèles listés ci-dessus ; aucun marqueur n’est requis. Lisez resp.usage.prompt_tokens_details.cached_tokens pour confirmer les hits pendant le développement.

Pièges des chatbots

• ❌ N’intégrez pas l’horodatage courant dans le prompt système ("Today is 2026-05-25 14:30:25"). La précision à la seconde invalide tout le cache.
• ❌ Ne reconstruisez pas l’historique à chaque tour — gardez l’ordre du tableau de messages identique octet par octet et en mode append-only.
• ✅ Mettez les données de persona utilisateur dans le premier message utilisateur, pas dans le prompt système — la variation par utilisateur n’empoisonne alors pas le préfixe partagé.
• ✅ Pour les sessions devenues froides au-delà du TTL, envoyez un ping keep-alive d’un token (voir Partie 3 §8.2) avant l’arrivée du prochain message de l’utilisateur.

Cas d’usage 2 : charges de travail API (RAG, génération de contenu, traitement par lots)

Profil de trafic

• Q&R RAG : entrée = système stable + documents récupérés variables + requête variable.
• Génération de contenu (textes marketing, code, traduction) : modèle stable, données variables.
• Traitement par lots (classification de documents, nettoyage de données) : même tâche à grand volume.
• La latence est secondaire ; le coût par appel domine.

Le problème épineux : la récupération réorganise votre préfixe

Le problème central de mise en cache du RAG : les documents récupérés changent d’un appel à l’autre, cassant le préfixe en plein milieu du prompt.

Request 1: [system: 3K] + [doc_A, doc_B, doc_C] + [user: Q1]
Request 2: [system: 3K] + [doc_B, doc_D, doc_A] + [user: Q2]
           ↑─ hits ─────↑  ↑──── miss ─────────↑

Trois correctifs, par complexité croissante :

Correctif A — Poussez les documents récupérés vers l’arrière, pas vers l’avant.

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},          # ~3K, stable
    {"role": "system", "content": INSTRUCTION_TEMPLATE},   # ~500, stable
    {"role": "user",   "content": f"References:\n{retrieved_docs}\n\nQuestion: {q}"},
]

Résultat : toute la partie system (les ~3,5K tokens stables) se met en cache. Seule la partie destinée à l’utilisateur rate à chaque appel. C’est suffisant pour la plupart des RAG en production. Taux de réussite mesuré sur ce schéma avec gpt-5.4-mini : plus de 80 % sur les tokens système.

Correctif B — Ordre de récupération déterministe. Triez les chunks récupérés selon une clé stable (doc_id croissant) plutôt que selon le score de pertinence. Les chunks fréquents restent à des positions cohérentes et le préfixe correspond plus souvent. Cela coûte une petite baisse de précision au ranker ; généralement sans incidence.

Correctif C — Marqueurs de cache explicites natifs via les SDK fournisseurs directs. Si vous êtes sur Anthropic Claude en direct (pas via cette passerelle), le schéma multi-cache_control permet de mettre en cache « ne change jamais » + « change rarement » + « change par tâche » comme points de rupture distincts. Excellent pour les RAG complexes quand vous pouvez embarquer un SDK supplémentaire.

Considérations de TTL pour les charges de travail API

• Trafic continu (endpoint RAG 24/7) : les TTL de 5 min conviennent — il y a toujours une requête suivante dans la fenêtre.
• En rafales / cron (batch quotidien à 09:00) : utilisez un fournisseur à TTL long (deepseek-v4-flash est le plus durable de notre panel de test) ou exécutez un ping keep-alive d’un token toutes les TTL/2 pendant la fenêtre d’exécution. Schéma dans la Partie 3 §8.2.

Recommandations de modèles par tâche

† Les marqueurs multi-cache_control de Claude sont inégalés pour le RAG en couches — utilisez le SDK anthropic pointé vers la passerelle, voir Partie 3 §2.

Esquisse de coût RAG (100K requêtes/jour)

3K système + 5K documents récupérés + requête de 200 tokens + sortie de 300 tokens. Les chiffres sont extrapolés des coûts par appel unique mesurés dans la Partie 3 §6 — mono-tenant, sans charge concurrente.

À considérer comme un ordre de grandeur. La production réelle comporte des appels concurrents, des rafales, et la distribution de la longueur de vos documents récupérés dominera le calcul.

Pièges RAG / API

• ❌ Ne triez pas les chunks récupérés par score de pertinence dynamique — chaque requête obtient un préfixe unique.
• ❌ Ne perdez pas les journaux d’usage en streaming — votre attribution de coût s’effondre. Passez stream_options={"include_usage": True} et stockez prompt_tokens_details.cached_tokens et usage.cost.
• ✅ Pour les tâches par lots, empilez les API Batch des fournisseurs (OpenAI Batch, Anthropic Message Batches) par-dessus la mise en cache pour ~50 % de remise supplémentaire — à faire en dehors de cette passerelle, en appelant le fournisseur directement.

Cas d’usage 3 : agents IA (raisonnement multi-étapes, usage d’outils, longues chaînes)

Profil de trafic

• Une tâche d’agent = de nombreux appels LLM, entrelacés avec des résultats d’outils.
• Contexte très long (système + outils + historique accumulé) : typiquement 30K–100K tokens à l’étape 10.
• Prompts hautement structurés : long préfixe stable, petite queue variable.
• La latence et le coût comptent tous deux — chaque seconde supplémentaire de préremplissage ajoute une attente visible, et un agent à 15 étapes multiplie cela par 15.

Pourquoi les agents dépendent de la mise en cache

Chaque étape s’ajoute à l’appel d’outil et au résultat de l’étape précédente. Sans cache, chaque étape repaie le préremplissage sur des dizaines de milliers de tokens.

Step 1: [system: 5K] + [tools: 3K]
Step 2: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
Step 3: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
                                   + [call_2: 1K] + [result_2: 5K]
        ↑──── prefix grows monotonically — perfect for caching ────↑

Règle critique : les appels d’outils et leurs résultats doivent être append-only et identiques octet par octet d’une étape à l’autre. Toute réécriture ou réorganisation tue le cache à partir de ce point. Le bug d’agent le plus courant est « j’ai nettoyé le résultat de l’outil avant de le renvoyer » → le taux de cache tombe à zéro → le coût et la latence sont multipliés.

Adéquation du TTL — le seul cas d’usage où ça compte

Une tâche d’agent typique dure 10 à 60 secondes ; à l’intérieur d’une seule tâche, les TTL par défaut de 5 min conviennent. Mais les agents qui attendent une approbation humaine (« examinez ce plan et répondez ») peuvent rester inactifs pendant des minutes. Si l’humain marque une pause de 10 minutes et que le cache est devenu froid, votre étape suivante repaie le préremplissage sur 50K tokens. Pour ces workflows, soit :

• Utilisez un fournisseur avec un TTL plus long (deepseek-v4-flash est le plus durable de notre panel de test), soit
• Envoyez un ping keep-alive toutes les TTL/2 pendant l’attente (voir Partie 3 §8.2).

Recommandations de modèles pour agents

Les agents exigent une capacité de raisonnement — choisissez d’abord sur la qualité, puis optimisez le coût.

† Le schéma à 4 marqueurs cache_control de Claude reste la meilleure configuration pour la mise en cache d’agents (remise cumulative sur le préfixe à travers plus de 10 étapes). Utilisez le SDK anthropic pointé vers la passerelle — voir Partie 3 §2 pour la forme exacte de la charge utile et les options de TTL.

Estimation de coût réelle : une tâche d’agent à 15 étapes

Supposons 5K système + 3K outils + ~3K ajoutés par étape, 15 étapes au total. Coût par appel issu de la Partie 3 §6 mis à l’échelle de la forme d’un agent :

Encore une fois, des chiffres indicatifs. La variable dominante est de savoir si vous gardez réellement le préfixe identique octet par octet d’une étape à l’autre.

Pièges des agents

• ❌ Ne reconstruisez pas la liste de messages à chaque étape — gardez le tableau identique octet par octet, en mode append-only.
• ❌ Ne rognez ni ne reformatez les résultats d’outils — tout changement d’octet invalide le cache en aval.
• ❌ Ne partagez pas une clé de cache entre instances d’agents concurrentes — leurs ordonnancements d’étapes divergent et se contaminent mutuellement.
• ✅ Surveillez cache_creation_tokens : cache_read_tokens par tâche — un ratio sain est de 1:50 ou mieux à l’étape 10.

La matrice de décision maîtresse

                            ┌─ Chinese-heavy ─→ deepseek-v4-flash + auto cache
                  ┌─ High ─→│
                  │          └─ Global users ──→ gpt-5.4-nano / claude-haiku-4-5
   Chatbot ──────→│
                  │          ┌─ Quality-first ─→ gpt-5.4-mini / claude-sonnet-4-5
                  └─ Mid ──→│
                            └─ Balanced ──────→ gemini-2.5-flash / qwen3-max

                            ┌─ Chinese RAG ───→ deepseek-v4-flash / qwen3-max
                  ┌─ Live ─→│
                  │          └─ English RAG ───→ gpt-5.4-mini / claude-sonnet-4-5†
   API ──────────→│
                  │          ┌─ Translation ───→ gpt-5.4-nano (template caches)
                  └─ Batch →│
                            └─ Doc review ────→ qwen3.5-flash + Batch APIs

                            ┌─ Simple ────────→ deepseek-v4-flash / qwen3-max
                  ┌─ China ─→│
                  │          └─ Complex ───────→ qwen3-max (plan) + deepseek (execute)
   Agent ────────→│
                  │          ┌─ Simple ────────→ gpt-5.4-mini + auto
                  └─ Global →│
                            └─ Complex ───────→ claude-sonnet-4-5† / gpt-5.5-pro

  † Claude with multi-`cache_control` breakpoints via the `anthropic` SDK pointed at the gateway (see Part 3 §2)

Référence rapide du TTL par cas d’usage

Ce que cette passerelle fait et ne fait pas

Pour fixer les attentes honnêtement :

Si vous avez besoin aujourd’hui de l’un des éléments de droite, faites-le dans votre couche applicative ou directement avec le SDK du fournisseur. La passerelle est un proxy léger plus une couche de tarification ; tout ce qui concerne la mise en cache se passe au niveau du modèle, en amont.

À retenir

La série en quatre parties se résume à quatre lignes :

La mise en cache, ce sont deux gains, pas un. Coût ET latence. Contenu stable d’abord, contenu volatil en dernier. La discipline de préfixe est gratuite, appliquez-la partout. Alignez modèle + comportement de cache sur le cas d’usage. Chat ≠ RAG ≠ Agents. Mesurez sur votre propre trafic. Les benchmarks en exécution unique sont un point de départ, pas la réponse.

Le chemin le plus rapide à partir d’ici : choisissez dans la matrice ci-dessus le cas d’usage le plus proche du vôtre, appliquez les changements structurels (préfixe stable d’abord, récupération déterministe, état d’agent identique octet par octet), journalisez cached_tokens et usage.cost pendant une semaine, puis réévaluez.

FAQ

Quel LLM est le moins cher pour un chatbot en langue chinoise ? deepseek-v4-flash et qwen3.5-flash sont un ordre de grandeur moins chers que les modèles optimisés pour l’anglais sur du texte chinois dans notre panel de test, tout en égalant gpt-5.4-mini en qualité sur des charges de chat typiques.

Quel est le meilleur LLM pour le RAG en 2026 ? Pour l’anglais : gpt-5.4-mini avec la disposition de prompt du Correctif A (tokens système à l’avant, références en bas) donne plus de 80 % de taux de réussite sur la portion stable. Pour le chinois : deepseek-v4-flash. Pour de très longs documents interrogés souvent : gemini-2.5-pro (gère nativement un contexte de plus d’un million de tokens).

Dois-je utiliser GPT ou Claude pour les agents ? Les deux sont solides ; le choix dépend de l’effort de discipline de cache que vous voulez investir. Le schéma à 4 marqueurs cache_control de Claude (via le SDK anthropic pointé vers la passerelle) est uniquement puissant pour les préfixes cumulatifs d’agents — ~90 % de réduction du coût d’entrée une fois le préfixe chaud, sur plus de 10 étapes. Si vous préférez rester sur le client au format OpenAI et accepter ~50 % d’économies de cache sans aucun marqueur, gpt-5.4-mini ou gpt-5.5-pro est le choix le moins contraignant.

Combien puis-je réellement économiser en passant d’un usage « naïf » à un usage « optimisé » du LLM ? Sur les exécutions mesurées dans cette série : 50–88 % de réduction de coût et 30–60 % de réduction du TTFT pour le même modèle. L’essentiel du gain vient du fait de porter votre taux de réussite au-dessus de 80 %, pas du choix d’un modèle différent.

Par où commencer ? Choisissez dans la matrice le cas d’usage le plus proche du vôtre. Appliquez les changements structurels de prompt. Mesurez cached_tokens et usage.cost pendant une semaine de trafic de production. Ce n’est qu’ensuite qu’il faut envisager de changer de modèle.

Sources et vérification : chiffres mesurés issus de la Partie 3 §6, https://synthorai.io/v1 le 2026-05-25, SDK openai 2.38.0. Pages de tarifs des fournisseurs : OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian.

← Retour au blog