Meilleur LLM selon le cas d’usage (2026) : matrice des coûts pour chat, RAG et agents

TL;DR — Le « meilleur » LLM ne se choisit pas à partir d’un seul benchmark. Tout dépend de ce que vous déployez : un chatbot, une API RAG/batch ou un agent IA. Ces trois types de charge ont des structures de prompt, des taux de hit, des besoins de TTL et des contraintes de latence différents. Le bon couple modèle + stratégie de cache n’est donc pas le même. Ce guide reprend les mesures de la Partie 3 : même gateway, même SDK OpenAI, seul le champ model change à chaque appel.

Série : Partie 4 sur 5 · Précédemment : Partie 1 — Principes du cache · Partie 2 — Comparaison et évaluation des fournisseurs · Partie 3 — Tutoriel avec du code fonctionnel · Suite : Partie 5 — Intégration à LangChain

0. La formule universelle du coût

Avant de passer aux cas d’usage, voici l’équation que chaque choix doit chercher à 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. Réduire le prix unitaire (P_in / P_out) → choisir un modèle moins cher.
2. Augmenter le taux de hit → restructurer le prompt et adapter le TTL au rythme du trafic.
3. Réduire le coefficient de remise du cache → choisir un fournisseur dont le cache est plus avantageux.
4. Choisir un fournisseur dont le prefill en cache est le plus rapide → la latence compte pour l’UX.

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

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

Profil du trafic

• Chaque requête = long prompt système (persona + connaissances + règles) + historique multi-tour + nouveau message utilisateur.
• Contexte moyen : 4K–20K tokens.
• Les utilisateurs sont très sensibles au time-to-first-token (>2 s donne l’impression que le service ne répond plus).
• Dans une même session, les requêtes sont espacées de quelques secondes à quelques minutes, donc largement dans le TTL de cache de chaque fournisseur.

Pourquoi le chat se met presque tout seul en cache

Le chat est la charge la plus favorable au cache. Dans 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 ────────↑

Tant que l’intervalle entre les messages reste inférieur au TTL, soit quelques minutes chez tous les fournisseurs, la partie système du prompt dépasse 90 % de taux de hit sans effort particulier. Aucun keep-alive n’est nécessaire.

Modèles recommandés (mesures de 2026-05)

* Mesuré avec un prompt système stable de 7,300 tokens, sur une seule exécution séquentielle, sans charge concurrente. Le tableau complet se trouve dans la Partie 3 §6.

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. Le cache est automatique pour tous les modèles listés ci-dessus, sans marker. Pendant le développement, consultez resp.usage.prompt_tokens_details.cached_tokens pour confirmer les hits.

Pièges à éviter pour les chatbots

• ❌ N’intégrez pas l’horodatage courant dans le prompt système ("Today is 2026-05-25 14:30:25"). Une précision à la seconde invalide le cache à chaque requête.
• ❌ Ne reconstruisez pas l’historique à chaque tour. Conservez un ordre de messages identique octet par octet et ajoutez seulement les nouveaux éléments à la fin.
• ✅ Placez les données de persona propres à l’utilisateur dans le premier message utilisateur, pas dans le prompt système. Les variations par utilisateur ne contaminent alors pas le préfixe partagé.
• ✅ Quand une session reste inactive au-delà du TTL, envoyez un ping keep-alive de 1 token (voir la Partie 3 §8.2) avant l’arrivée du prochain message utilisateur.

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

Profil du trafic

• Questions-réponses RAG : entrée = système stable + documents récupérés variables + requête variable.
• Génération de contenu (texte marketing, code, traduction) : template stable, données variables.
• Traitement batch (classification de documents, nettoyage de données) : même tâche à gros volume.
• La latence est secondaire ; le coût par appel domine.

Le principal problème : la recherche réordonne le préfixe

Le problème central du cache en RAG est simple : les documents récupérés changent d’un appel à l’autre et cassent le préfixe au 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 solutions, par ordre de complexité :

Solution A — Placer les documents récupérés à la fin, pas au début.

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, soit environ 3.5K tokens stables, passe en cache. Seule la partie utilisateur génère un miss à chaque appel. Cela suffit pour la plupart des systèmes RAG en production. Avec ce pattern et gpt-5.4-mini, nous avons mesuré plus de 80 % de hits sur les tokens système.

Solution B — Rendre l’ordre de recherche déterministe. Triez les chunks récupérés selon une clé stable (doc_id croissant), plutôt que selon leur score de pertinence. Les chunks fréquents restent aux mêmes positions et le préfixe correspond plus souvent. La perte de précision du ranker est faible et généralement négligeable.

Solution C — Utiliser les markers de cache explicites natifs via les SDK des fournisseurs. Si vous utilisez directement Anthropic Claude, sans passer par cette gateway, le pattern avec plusieurs cache_control permet de définir des breakpoints séparés pour ce qui « ne change jamais », « change rarement » et « change à chaque tâche ». C’est une excellente solution pour les RAG complexes si vous acceptez de gérer un SDK supplémentaire.

Gestion du TTL pour les charges API

• Trafic continu (endpoint RAG 24/7) : un TTL de 5 min suffit. Une nouvelle requête arrive toujours avant son expiration.
• Trafic en rafales / cron (batch quotidien à 09:00) : utilisez un fournisseur avec un TTL long (deepseek-v4-flash est celui qui tient le plus longtemps parmi les modèles testés), ou envoyez un keep-alive de 1 token toutes les TTL/2 pendant la fenêtre d’exécution. Le pattern est présenté dans la Partie 3 §8.2.

Modèles recommandés selon la tâche

† Les markers multi-cache_control de Claude restent sans équivalent pour les RAG en plusieurs couches. Utilisez le SDK anthropic en le faisant pointer vers la gateway ; voir la Partie 3 §2.

Estimation du coût RAG (100K requêtes/jour)

3K tokens système + 5K tokens de documents récupérés + requête de 200 tokens + sortie de 300 tokens. Les chiffres sont extrapolés à partir des coûts par appel mesurés dans la Partie 3 §6 : un seul tenant, sans charge concurrente. Pour votre propre charge, estimez la facture avec le calculateur de coût LLM et consultez les tarifs actuels dans le comparatif des prix des modèles.

Ces chiffres donnent un ordre de grandeur. En production, les appels concurrents, les pics de trafic et surtout la distribution de longueur des documents récupérés auront le plus d’impact sur le calcul.

Pièges à éviter pour le RAG et les API

• ❌ Ne triez pas les chunks récupérés selon un score de pertinence dynamique. Chaque requête produirait un préfixe unique.
• ❌ Ne supprimez pas les logs d’usage en streaming, sinon l’attribution des coûts devient impossible. Passez stream_options={"include_usage": True} et stockez prompt_tokens_details.cached_tokens ainsi que usage.cost.
• ✅ Pour les traitements batch, combinez le cache avec les Batch APIs des fournisseurs (OpenAI Batch, Anthropic Message Batches) afin d’économiser encore environ 50 %. Cela se fait hors de cette gateway, en appelant directement le fournisseur.

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

Profil du trafic

• Une tâche agent = plusieurs appels LLM entrecoupés de résultats d’outils.
• Contexte très long (système + outils + historique accumulé) : généralement 30K–100K tokens à l’étape 10.
• Prompts très structurés : long préfixe stable, courte partie variable à la fin.
• La latence et le coût comptent tous les deux. Chaque seconde de prefill supplémentaire rallonge visiblement l’attente, et un agent en 15 étapes multiplie ce délai par 15.

Pourquoi les agents dépendent du cache

Chaque étape ajoute l’appel d’outil et son résultat à l’étape précédente. Sans cache, le prefill de dizaines de milliers de tokens est refacturé à chaque étape.

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 impérative : les appels d’outils et leurs résultats doivent être ajoutés uniquement à la fin et rester identiques octet par octet d’une étape à l’autre. Toute réécriture ou permutation invalide le cache à partir de ce point. Le bug le plus fréquent avec les agents consiste à « nettoyer le résultat de l’outil avant de le renvoyer ». Le taux de cache tombe alors à zéro, tandis que le coût et la latence explosent.

Adéquation du TTL : le seul cas où elle devient critique

Une tâche agent standard dure entre 10 et 60 secondes. Dans une même tâche, le TTL par défaut de 5 min suffit. Les agents qui attendent une validation humaine (« vérifiez ce plan et répondez ») peuvent toutefois rester inactifs plusieurs minutes. Si la personne attend 10 minutes et que le cache expire, l’étape suivante refacture le prefill de 50K tokens. Pour ces workflows :

• utilisez un fournisseur proposant un TTL plus long (deepseek-v4-flash est celui qui tient le plus longtemps parmi les modèles testés), ou
• envoyez un ping keep-alive toutes les TTL/2 pendant l’attente (voir la Partie 3 §8.2).

Modèles recommandés pour les agents

Les agents exigent de bonnes capacités de raisonnement. Choisissez d’abord selon la qualité, puis optimisez les coûts.

† Le pattern à 4 markers cache_control de Claude reste la configuration la plus efficace pour mettre en cache les agents, avec une remise cumulative sur le préfixe au-delà de 10 étapes. Utilisez le SDK anthropic en le faisant pointer vers la gateway. La Partie 3 §2 fournit la structure exacte du payload et les options de TTL.

Estimation réelle du coût : une tâche agent en 15 étapes

Hypothèse : 5K tokens système + 3K tokens d’outils + environ 3K tokens ajoutés à chaque étape, sur 15 étapes. Coût par appel tiré de la Partie 3 §6 et extrapolé à cette structure d’agent :

Là encore, ce sont des estimations. La variable principale reste la capacité à conserver un préfixe strictement identique octet par octet d’une étape à l’autre.

Pièges à éviter pour les agents

• ❌ Ne reconstruisez pas la liste de messages à chaque étape. Conservez un tableau identique octet par octet et ajoutez seulement les nouveaux éléments à la fin.
• ❌ Ne tronquez pas et ne reformatez pas les résultats d’outils. Le moindre octet modifié invalide la suite du cache.
• ❌ Ne partagez pas une clé de cache entre plusieurs instances concurrentes d’un agent. L’ordre de leurs étapes diverge et les caches se contaminent.
• ✅ Surveillez le ratio cache_creation_tokens : cache_read_tokens pour chaque tâche. À l’étape 10, un ratio sain est de 1:50 ou mieux.

Matrice de décision complète

                            ┌─ 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)

Guide rapide du TTL selon le cas d’usage

Ce que fait cette gateway, et ce qu’elle ne fait pas

Pour clarifier son périmètre :

Si vous avez besoin aujourd’hui de l’une des fonctions de la colonne de droite, implémentez-la dans votre couche applicative ou utilisez directement le SDK du fournisseur. La gateway est un proxy léger auquel s’ajoute une couche tarifaire. Tout ce qui concerne le cache est géré en amont, au niveau du modèle.

Conclusion

Toute la série tient en quatre lignes :

Le cache apporte deux gains, pas un seul. Coût ET latence. Le contenu stable d’abord, le contenu variable à la fin. La discipline de préfixe ne coûte rien : appliquez-la partout. Adaptez le modèle et le comportement du cache au cas d’usage. Chat ≠ RAG ≠ Agents. Mesurez sur votre propre trafic. Une mesure sur une seule exécution donne un point de départ, pas une réponse définitive.

Pour avancer rapidement, choisissez dans la matrice le cas d’usage le plus proche du vôtre. Appliquez les changements structurels : préfixe stable en premier, recherche déterministe et état d’agent identique octet par octet. Enregistrez ensuite cached_tokens et usage.cost pendant une semaine, puis réévaluez votre choix.

FAQ

Quel LLM est le moins cher pour un chatbot en chinois ? deepseek-v4-flash et qwen3.5-flash coûtent dix fois moins que les modèles optimisés pour l’anglais sur les textes chinois de notre jeu de test, tout en offrant une qualité comparable à gpt-5.4-mini sur les charges de chat classiques.

Quel est le meilleur LLM pour le RAG en 2026 ? Pour l’anglais, gpt-5.4-mini avec la structure de prompt de la solution A, tokens système au début et références à la fin, dépasse 80 % de hits sur la partie stable. Pour le chinois : deepseek-v4-flash. Pour de très longs documents consultés fréquemment : gemini-2.5-pro, qui gère nativement un contexte de plus de 1M tokens.

Faut-il choisir GPT ou Claude pour les agents ? Les deux sont performants. Le choix dépend surtout des efforts que vous êtes prêt à consacrer à la gestion du cache. Le pattern de Claude à 4 markers cache_control, via le SDK anthropic connecté à la gateway, est particulièrement efficace pour les préfixes cumulatifs des agents : environ 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 un client au format OpenAI et obtenir environ 50 % d’économies sans aucun marker, gpt-5.4-mini ou gpt-5.5-pro demandent moins d’intégration.

Combien peut-on réellement économiser en passant d’un usage « naïf » à un usage optimisé des LLM ? Sur les exécutions mesurées dans cette série : 50–88 % de réduction des coûts et 30–60 % de réduction du TTFT avec le même modèle. L’essentiel du gain vient d’un taux de hit supérieur à 80 %, pas du changement de modèle.

Par où commencer ? Choisissez dans la matrice le cas d’usage le plus proche du vôtre. Modifiez la structure des prompts. Mesurez cached_tokens et usage.cost pendant une semaine de trafic en production. Envisagez seulement ensuite de changer de modèle.

Comment comparer les prix des API LLM entre fournisseurs ? La page des modèles de Synthorai compare les prix en temps réel. Vous pouvez filtrer par fournisseur et trier selon le prix d’entrée ou de sortie par million de tokens. Les données restent synchronisées avec les tarifs effectivement appliqués par la gateway. La matrice ci-dessus indique le type de modèle adapté à votre cas d’usage ; la page des modèles indique son prix actuel.

Sources et vérification : mesures tirées de la Partie 3 §6, https://synthorai.io/v1 au 2026-05-25, SDK openai 2.38.0. Pages tarifaires des fournisseurs : OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian.

← Retour au blog