Optimiser les coûts LLM : les 10 leviers, du modèle mental au code

Ton premier pilote IA coûtait 40 € par mois. Le second, 400 €. Le troisième — celui avec des agents — est passé à 4 000 € en trois semaines, et personne n'est capable de dire quel workflow a brûlé quoi. Ce n'est pas un problème de fournisseur ni de modèle : c'est un problème de tokens envoyés que personne ne lit, d'appels qu'on aurait pu ne pas faire, et de facture que personne n'attribue.

Ce guide fait le tour complet. La première moitié est pour le DSI : le modèle mental, les leviers classés par famille, la matrice impact/effort et l'ordre dans lequel les activer. La seconde moitié est pour ton équipe technique : chaque levier avec le code Python correspondant, les pièges, et un cas chiffré sur un pipeline réel. Tu peux lire l'une sans l'autre.

1. Le modèle mental : d'où vient la facture

Avant de toucher au moindre levier, il faut comprendre ce qu'on paye. Un appel LLM facture trois choses, et la plupart des équipes n'en voient qu'une.

Trois observations en découlent, et elles structurent tout le reste du guide.

L'entrée est dominée par ce qui ne change pas. Ton prompt système, tes définitions d'outils, tes exemples few-shot, ta documentation injectée : tout ça est renvoyé à l'identique à chaque appel. Sur un agent qui fait 30 tours, tu payes 30 fois le même préfixe. C'est le premier gisement, et c'est celui que le prompt caching attaque.

La sortie coûte 4 à 5 fois plus cher que l'entrée. Un modèle qui répond « Bien sûr ! Voici les informations que vous avez demandées, présentées de manière claire et structurée : » avant de donner le JSON que tu attendais vient de te facturer 25 tokens de politesse au tarif le plus cher. Sur un million d'appels, c'est un salaire.

Le multiplicateur est invisible sur la grille tarifaire. Le fournisseur affiche un prix par million de tokens. Il n'affiche pas que ton agent va refaire l'appel 12 fois parce que le JSON était invalide au premier tour, ni que ton pattern évaluateur-optimiseur double mécaniquement chaque requête. Ce multiplicateur est là où les pilotes dérapent.

2. Les 10 leviers, classés par famille

L'infographie qui circule sur LinkedIn liste douze techniques à plat. C'est un inventaire, pas une stratégie. Voici la même matière organisée par ce qu'elle fait à la formule ci-dessus.

Tu remarqueras que deux leviers de l'infographie d'origine ont été fusionnés (quantization et distillation, qui répondent à la même question : « ai-je besoin d'un modèle aussi gros ? ») et que le décodage spéculatif est relégué en fin de liste. Ce n'est pas qu'il est inefficace — c'est qu'il ne concerne que les organisations qui hébergent leurs propres GPU, soit une minorité des lecteurs de ce guide. On y revient en section 5.

Ce que chaque famille demande comme effort

La question qu'un DSI doit se poser n'est pas « lequel de ces leviers marche ? » (ils marchent tous) mais « lequel je peux activer cette semaine avec les gens que j'ai ? ».

3. L'ordre de bataille : 30, 60, 90 jours

Voici la séquence que je recommande pour une DSI qui découvre une facture LLM en dérive. Elle part du principe que tu n'as pas d'équipe dédiée et que chaque levier doit prouver son gain avant le suivant.

J+30 — Voir. Tu instrumentes chaque appel (quel workflow, quel agent, quel client interne, combien de tokens, combien d'euros), tu actives le prompt caching sur tout ce qui a un préfixe stable, tu forces la sortie structurée, et tu poses un plafond de dépense dur par agent. Ce dernier point n'est pas un levier de coût : c'est une assurance. Un agent qui boucle sans plafond peut dépenser en une nuit ce que tu voulais économiser en un trimestre.

J+60 — Trier. Avec 30 jours de données, tu sais quels workflows coûtent cher. Tu mets en place une gateway (LiteLLM, Portkey, OpenRouter, ou un simple module Python maison) qui route chaque requête vers le modèle le moins cher qui satisfait la qualité. Tu bascules tout ce qui n'est pas temps réel (enrichissement, classification nocturne, rapports) vers la Batch API. Tu fixes un budget de tokens par étape de pipeline et tu coupes l'historique.

J+90 — Structurer. C'est là que tu décides si un cache sémantique a du sens (seulement si ton trafic est répétitif), si ton RAG mérite un reranker, si une tâche étroite à fort volume justifie un petit modèle dédié, et si ton volume est tel que l'auto-hébergement devient rentable. Cette dernière question a une réponse chiffrée : en dessous de quelques dizaines de millions de tokens par jour, presque jamais.

4. Les leviers en code

La suite s'adresse à l'équipe qui va implémenter. Chaque levier suit le même format : ce qu'il fait, le code minimal, le piège qui fait échouer la mise en œuvre. Les exemples utilisent le SDK Anthropic ; les concepts sont transposables sans surprise.

4.1 Observabilité : instrumenter avant d'optimiser

Le principe : chaque appel LLM porte des métadonnées (workflow, agent, utilisateur ou segment) et son coût calculé. Tu les envoies vers Langfuse, Helicone, ou un simple OpenTelemetry vers ta stack existante. Le plus simple pour démarrer est un décorateur maison.

import time, functools
from anthropic import Anthropic

client = Anthropic()

# Prix par million de tokens — à externaliser dans une config, vérifier régulièrement
PRICES = {
    "claude-haiku-4-5": {"in": 1.00, "out": 5.00, "cache_read": 0.10, "cache_write": 1.25},
    "claude-sonnet-4-5": {"in": 3.00, "out": 15.00, "cache_read": 0.30, "cache_write": 3.75},
}

def cost_eur(model: str, usage) -> float:
    p = PRICES[model]
    cached = getattr(usage, "cache_read_input_tokens", 0) or 0
    written = getattr(usage, "cache_creation_input_tokens", 0) or 0
    fresh = usage.input_tokens - cached - written
    usd = (fresh * p["in"] + cached * p["cache_read"] + written * p["cache_write"]
           + usage.output_tokens * p["out"]) / 1_000_000
    return usd * 0.92  # taux de change à sortir en config

def traced(workflow: str, agent: str):
    def deco(fn):
        @functools.wraps(fn)
        def wrapper(*args, **kwargs):
            t0 = time.perf_counter()
            resp = fn(*args, **kwargs)
            record = {
                "workflow": workflow, "agent": agent,
                "model": resp.model, "latency_ms": round((time.perf_counter() - t0) * 1000),
                "in": resp.usage.input_tokens, "out": resp.usage.output_tokens,
                "cache_read": getattr(resp.usage, "cache_read_input_tokens", 0),
                "cost_eur": cost_eur(resp.model, resp.usage),
                "segment": kwargs.get("segment", "unknown"),
            }
            emit(record)  # → Langfuse / OTel / ta table PostgreSQL
            return resp
        return wrapper
    return deco

@traced(workflow="support-triage", agent="classifier")
def classify(ticket: str, segment: str = "b2b"):
    return client.messages.create(
        model="claude-haiku-4-5", max_tokens=50,
        messages=[{"role": "user", "content": ticket}],
    )

Le piège : instrumenter le coût par appel et s'arrêter là. Ce qui te fait prendre des décisions, c'est l'agrégation par workflow et par tour d'agent. Une requête qui coûte 0,002 € est invisible ; un workflow qui en fait 800 par jour avec 15 tours chacun ne l'est plus.

4.2 Prompt caching : payer le préfixe une fois

Le principe : le fournisseur garde en mémoire le préfixe stable de ton prompt (outils, système, exemples, documents) et te facture sa relecture à une fraction du prix — chez Anthropic, 10 % du prix d'entrée pour une lecture, 125 % pour l'écriture initiale. Le cache est rentable dès la deuxième lecture dans la fenêtre (5 minutes par défaut, extensible à une heure).

SYSTEM = open("prompts/support_system.md").read()        # 3 000 tokens, stable
KNOWLEDGE = open("kb/politique_retours.md").read()       # 8 000 tokens, stable

def answer(history: list[dict], question: str):
    return client.messages.create(
        model="claude-sonnet-4-5", max_tokens=600,
        system=[
            {"type": "text", "text": SYSTEM},
            {"type": "text", "text": KNOWLEDGE,
             "cache_control": {"type": "ephemeral"}},   # ← tout ce qui précède est caché
        ],
        messages=history + [{"role": "user", "content": question}],
    )

resp = answer([], "Je peux retourner un article acheté en promo ?")
u = resp.usage
print(u.input_tokens, u.cache_creation_input_tokens, u.cache_read_input_tokens)
# 1er appel :  11 060  |  11 000 écrits  |  0 lus
# 2e appel  :  11 075  |  0              |  11 000 lus  → l'entrée coûte ~12 % du prix

Les pièges, par ordre de fréquence :

• Un élément variable dans le préfixe. La date du jour, un identifiant de session, le nom de l'utilisateur dans le prompt système : chacun invalide le cache. Tout ce qui varie va dans messages, après le point de rupture.
• L'ordre des blocs. Le cache s'applique à un préfixe. Si tu changes l'ordre des outils entre deux appels, le préfixe diffère et rien n'est réutilisé.
• Un préfixe trop court. Sous le seuil minimum, le marqueur est ignoré silencieusement. Tu crois cacher, tu ne caches rien. Vérifie cache_read_input_tokens dans les usages, pas ton intuition.
• Une fenêtre qui expire. Sur un workflow qui tourne une fois par heure, le cache de 5 minutes ne sert à rien. Soit tu passes en TTL d'une heure (écriture à 200 %), soit tu regroupes les appels.

Chez OpenAI, le caching est automatique sur les préfixes identiques au-delà d'un seuil, avec une remise de 50 à 90 % selon les modèles — pas de marqueur à placer, mais la même discipline sur la stabilité du préfixe. Chez Mistral et Google, le mécanisme est explicite et proche de celui d'Anthropic.

4.3 Sortie structurée : arrêter de payer la politesse

Le principe : forcer le modèle à répondre dans un schéma (JSON typé) plutôt qu'en prose. Double effet : moins de tokens de sortie (le poste le plus cher), et zéro retry pour « le JSON était invalide ». La façon la plus fiable de l'obtenir chez tous les fournisseurs est de définir un outil avec un schéma strict et d'imposer son usage.

EXTRACT_TOOL = {
    "name": "extract_ticket",
    "description": "Extrait les champs structurés d'un ticket support.",
    "input_schema": {
        "type": "object",
        "properties": {
            "category": {"type": "string", "enum": ["billing", "bug", "feature", "other"]},
            "urgency": {"type": "integer", "minimum": 1, "maximum": 5},
            "product": {"type": "string"},
            "summary": {"type": "string", "maxLength": 200},
        },
        "required": ["category", "urgency", "summary"],
        "additionalProperties": False,
    },
}

def extract(ticket: str) -> dict:
    resp = client.messages.create(
        model="claude-haiku-4-5", max_tokens=200,
        tools=[EXTRACT_TOOL],
        tool_choice={"type": "tool", "name": "extract_ticket"},   # ← pas de prose possible
        messages=[{"role": "user", "content": ticket}],
    )
    return next(b.input for b in resp.content if b.type == "tool_use")

Sur un ticket moyen, la version prose produisait 180 tokens de sortie (« Voici l'analyse de ce ticket… ») ; la version outil en produit 45. À 5 € le million de tokens de sortie et 20 000 tickets par mois, c'est 13 € au lieu de 54 €. Ce n'est pas énorme en soi — mais c'est à multiplier par chaque étape de chaque pipeline, et c'est surtout la disparition des retries qui compte : un tour en moins sur un agent, c'est tout le contexte en moins.

4.4 Batch API : la remise de 50 % que personne n'utilise

Le principe : tout ce qui n'a pas besoin d'une réponse dans la seconde (enrichissement de données, classification nocturne, génération de rapports, évaluation de qualité) part dans un lot traité sous 24 heures, à moitié prix. Chez Anthropic, OpenAI et Google, la remise est de 50 % sur l'entrée et la sortie, cumulable avec le prompt caching.

from anthropic.types.message_create_params import MessageCreateParamsNonStreaming
from anthropic.types.messages.batch_create_params import Request

def enrich_batch(articles: list[dict]):
    requests = [
        Request(
            custom_id=a["id"],
            params=MessageCreateParamsNonStreaming(
                model="claude-haiku-4-5", max_tokens=300,
                system=[{"type": "text", "text": ENRICH_SYSTEM,
                         "cache_control": {"type": "ephemeral"}}],   # cache + batch se cumulent
                tools=[ENRICH_TOOL],
                tool_choice={"type": "tool", "name": "enrich_article"},
                messages=[{"role": "user", "content": a["text"]}],
            ),
        )
        for a in articles
    ]
    batch = client.messages.batches.create(requests=requests)
    return batch.id

# Plus tard (polling ou cron) :
def collect(batch_id: str):
    b = client.messages.batches.retrieve(batch_id)
    if b.processing_status != "ended":
        return None
    return {r.custom_id: r.result for r in client.messages.batches.results(batch_id)}

Le piège est organisationnel, pas technique : le batch impose de découpler l'ingestion de l'inférence. Ton pipeline doit accepter qu'un article ingéré à 8h soit enrichi à 14h. Sur un pipeline de veille comme celui de nAIvigate (11 sources, 4 passages par jour), c'est parfaitement acceptable pour la traduction et le scoring de pertinence ; ça ne l'est pas pour la réponse à un utilisateur qui attend.

4.5 Routing par complexité : le bon modèle pour chaque requête

Le principe : la majorité des requêtes d'un système en production sont des tâches simples (classification, extraction, reformulation) qu'un modèle de la classe Haiku traite aussi bien que le modèle frontière, pour 10 à 20 fois moins cher. Le routing consiste à classifier chaque requête, puis à l'envoyer vers le modèle le moins cher qui satisfait la qualité. Une gateway transforme ce choix en configuration plutôt qu'en code.

import re

TIERS = {
    "simple":  "claude-haiku-4-5",
    "medium":  "claude-sonnet-4-5",
    "complex": "claude-opus-4-1",   # à réserver au raisonnement multi-étapes
}

def route(task: str, text: str) -> str:
    """Règles d'abord (gratuit), petit modèle seulement en cas de doute."""
    if task in {"classify", "extract", "translate", "summarize_short"}:
        return TIERS["simple"]
    if task in {"plan", "audit", "multi_step"} or len(text) > 12_000:
        return TIERS["complex"]
    if re.search(r"`{3}|def |SELECT |import ", text):        # présence de code
        return TIERS["medium"]
    # Cas ambigu : demander à Haiku de trancher (coût négligeable)
    verdict = client.messages.create(
        model=TIERS["simple"], max_tokens=5,
        system="Réponds uniquement par: simple, medium ou complex.",
        messages=[{"role": "user", "content": text[:2000]}],
    ).content[0].text.strip().lower()
    return TIERS.get(verdict, TIERS["medium"])

Le piège : router sans évaluer. Le routing suppose que tu sais mesurer la qualité par tier. Avant de basculer 70 % du trafic vers un petit modèle, tu prends 200 requêtes représentatives, tu les fais traiter par les deux tiers, et tu compares (juge LLM ou vérité terrain). Si le petit modèle est à 97 % de la qualité du gros sur ta tâche, tu bascules. S'il est à 80 %, tu ne bascules pas — ou tu affines la tâche jusqu'à ce qu'il y arrive.

4.6 Compaction de contexte : 40 à 60 % de tokens que le modèle ignore

Le principe : à chaque appel, le contexte contient de l'historique périmé, du boilerplate, des résultats d'outils verbeux dont seule une ligne compte. Le modèle les lit (tu payes), puis les ignore. La compaction fixe un budget de tokens par étape de pipeline et l'applique avant chaque appel : on garde le système, on résume l'historique ancien, on ne conserve que les N derniers tours en clair, on tronque les sorties d'outils.

def compact(history: list[dict], budget_tokens: int, keep_last: int = 6) -> list[dict]:
    """Applique un budget au contexte : résumé de l'ancien, derniers tours en clair."""
    count = lambda msgs: client.messages.count_tokens(
        model="claude-haiku-4-5", messages=msgs).input_tokens

    if count(history) <= budget_tokens:
        return history

    old, recent = history[:-keep_last], history[-keep_last:]
    summary = client.messages.create(
        model="claude-haiku-4-5", max_tokens=400,
        system="Résume cet échange en faits et décisions, sans commentaire. Max 300 mots.",
        messages=old + [{"role": "user", "content": "Résume."}],
    ).content[0].text

    compacted = [{"role": "user", "content": f"[Résumé des échanges précédents]\n{summary}"},
                 {"role": "assistant", "content": "Compris, je reprends à partir de là."}] + recent
    return compacted

def truncate_tool_result(text: str, max_chars: int = 2000) -> str:
    """Un résultat d'outil de 40 Ko n'a jamais 40 Ko d'information utile."""
    return text if len(text) <= max_chars else text[:max_chars] + f"\n…[tronqué, {len(text)} car. au total]"

Le piège : compacter à l'aveugle et perdre l'information qui comptait. Le résumé doit être orienté « faits et décisions », pas « ambiance ». Et sur un agent, la meilleure compaction n'est pas un résumé mais une mémoire externe : l'agent écrit son plan et ses conclusions dans un fichier ou une base, et le contexte ne contient que le pointeur. C'est le pattern décrit dans notre formation sur les systèmes agentiques.

4.7 Retrieval affûté : le RAG est un générateur de tokens

Le principe : dans un RAG, le coût est directement piloté par taille des chunks × nombre de chunks retournés. Retourner 10 chunks de 1 000 tokens à chaque question, c'est 10 000 tokens d'entrée dont 8 000 sont du bruit. Trois réglages : des chunks plus petits et sémantiquement cohérents (300 à 800 tokens), un top-k généreux à la recherche puis un reranker qui ne garde que les 3 à 5 vraiment pertinents, et une recherche hybride (BM25 + vecteurs) qui réduit le bruit à la source.

def retrieve(query: str, top_k_search: int = 20, top_k_final: int = 4) -> list[str]:
    # 1. Hybride : union des candidats lexicaux et vectoriels
    lexical = bm25_index.search(query, k=top_k_search)
    vector = vector_index.search(embed(query), k=top_k_search)
    candidates = dedupe(lexical + vector)

    # 2. Reranking : un cross-encoder (bge-reranker, Cohere Rerank, etc.)
    scored = reranker.score(query, [c.text for c in candidates])
    best = sorted(zip(scored, candidates), reverse=True)[:top_k_final]

    # 3. Seuil : si rien n'est pertinent, n'envoie rien (et dis-le au modèle)
    return [c.text for s, c in best if s > 0.35]

Avec ce pipeline, un contexte RAG passe typiquement de 8 à 10 000 tokens à 2 à 3 000, pour une qualité de réponse égale ou meilleure — le modèle n'a plus à trier lui-même le bruit. Le piège classique : un reranker mal calibré qui coupe trop et laisse le modèle halluciner faute de contexte. Le seuil se règle sur un jeu de questions de test, pas au doigt mouillé.

4.8 Cache sémantique : ne pas appeler du tout

Le principe : avant d'appeler le LLM, tu calcules l'embedding de la question, tu cherches dans un index vectoriel une question passée suffisamment proche (similarité cosinus au-dessus d'un seuil), et si tu la trouves tu renvoies la réponse stockée. Coût : un embedding (quelques centièmes de centime) au lieu d'une génération.

import numpy as np

class SemanticCache:
    def __init__(self, store, threshold: float = 0.93, ttl_s: int = 86_400):
        self.store, self.threshold, self.ttl = store, threshold, ttl_s

    def get(self, tenant: str, question: str):
        q = embed(question)
        hit = self.store.nearest(tenant, q, k=1)          # (score, answer, created_at)
        if hit and hit.score >= self.threshold and not expired(hit.created_at, self.ttl):
            return hit.answer
        return None

    def put(self, tenant: str, question: str, answer: str):
        self.store.add(tenant, embed(question), answer)

cache = SemanticCache(store=RedisVectorStore("faq"))

def ask(tenant: str, question: str) -> str:
    if (cached := cache.get(tenant, question)):
        return cached
    answer = llm_answer(question)
    cache.put(tenant, question, answer)
    return answer

Trois règles non négociables : scope par tenant (le cache d'un client ne doit jamais servir à un autre — c'est une fuite de données, pas une optimisation), TTL (une politique de retours change, la réponse cachée aussi), et exclusion des réponses personnalisées (« où en est ma commande ? » ne se cache pas, quelle que soit la similarité). Mesure le hit rate pendant deux semaines avant de conclure : sur un support répétitif il monte à 40 à 60 %, sur un assistant métier il peut rester sous 10 %, et dans ce cas retire-le.

5. Les leviers d'infrastructure (auto-hébergé uniquement)

Si tu consommes des API, cette section ne te concerne pas : le fournisseur fait déjà tout ça de son côté, et c'est inclus dans le prix. Si tu héberges tes propres modèles (souveraineté, volume, données sensibles), voici les trois réglages qui changent la facture GPU.

Quantization. Un modèle en poids INT8 ou INT4 occupe 2 à 4 fois moins de mémoire que sa version 16 bits, avec une perte de qualité négligeable sur la plupart des tâches (mesurable sur le raisonnement long). Concrètement, un 70B qui demandait deux GPU de 80 Go tient sur un seul. Avec Ollama, c'est le suffixe du tag (llama3.3:70b-instruct-q4_K_M) ; avec vLLM, un flag au lancement. La quantization du KV cache (la mémoire de travail pendant la génération) est un second levier, plus récent, qui permet de servir plus de requêtes simultanées par GPU.

# vLLM : poids quantizés AWQ + KV cache en FP8
vllm serve Qwen/Qwen3-32B-AWQ \
  --quantization awq \
  --kv-cache-dtype fp8 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92

# Ollama : le tag choisit la quantization
ollama pull qwen3:32b-q4_K_M

Distillation / petit modèle dédié. Pour une tâche étroite à fort volume (classifier 50 000 tickets par jour en 12 catégories), un modèle de 3 à 8 milliards de paramètres fine-tuné sur les sorties du modèle frontière fait aussi bien pour une fraction du coût, et tourne sur un GPU modeste ou même sur CPU. C'est un projet (jeu de données, entraînement, évaluation, maintenance), pas un réglage — à réserver aux tâches dont le volume le justifie. Notre comparateur de modèles locaux te donne les candidats par palier de matériel.

Décodage spéculatif et désagrégation. Le décodage spéculatif fait proposer plusieurs tokens par un petit modèle « brouillon », que le grand modèle vérifie en un seul passage : 1,5 à 3 fois plus de tokens par seconde, sans changer la sortie. La désagrégation prefill/decode sépare sur des GPU différents la lecture du prompt (gourmande en calcul) de la génération (gourmande en mémoire), pour une meilleure utilisation du matériel. Les deux sont des réglages de serveur d'inférence (vLLM, SGLang, TensorRT-LLM), pertinents à partir de plusieurs GPU en production. En dessous, l'effort ne se justifie pas.

6. Cas chiffré : un pipeline de veille

Prenons un cas réel de structure : un pipeline qui ingère 11 sources d'actualité 4 fois par jour, filtre, puis enrichit chaque article retenu (traduction du titre, score de pertinence, extraction de 3 points clés). Environ 200 articles enrichis par jour. Avant optimisation, chaque enrichissement est un appel direct à un modèle de classe Sonnet, avec un prompt système de 1 200 tokens, l'article (500 tokens en moyenne) et une réponse en prose de 350 tokens.

Le détail du calcul, avec des prix relatifs (entrée = 1, sortie = 5 pour Sonnet ; Haiku à un tiers) :

• Départ : 200 × (1 700 tokens d'entrée × 1 + 350 de sortie × 5) = 200 × 3 450 = 690 000 unités. Base 100.
• Sortie structurée : la réponse passe de 350 à 90 tokens (JSON typé avec 3 champs). 200 × (1 700 + 450) = 430 000. Indice 62 — mais on garde 73 dans le graphe pour tenir compte de quelques retries résiduels sur les articles mal formés qui disparaissent seulement à l'étape suivante. Sois conservateur dans tes propres projections.
• Prompt caching : les 1 200 tokens de système sont lus à 10 % du prix (les 4 passages quotidiens sont regroupés dans la fenêtre). L'entrée passe à 120 + 500 = 620. Indice 52.
• Routing vers Haiku : la tâche (traduire un titre, scorer, extraire trois points) est évaluée à 96 % de la qualité de Sonnet sur 200 articles de test. Division par 3 du prix moyen. Indice 17.
• Batch API : l'enrichissement n'a pas besoin d'être instantané. -50 %. Indice 9.
• Trim : on n'envoie que le chapeau et les deux premiers paragraphes (300 tokens au lieu de 500) — le reste n'améliore pas le score. Indice 7.

Aucun de ces leviers n'a demandé plus d'une demi-journée de travail. Le gain est de 93 %, sur une tâche qui — c'est important — s'y prête particulièrement bien : répétitive, non urgente, à sortie structurée. Un assistant conversationnel temps réel avec des réponses longues ne verra pas 93 %. Il verra 40 à 60 %, ce qui reste considérable.

7. Teste ta compréhension

Questions fréquentes

Le prompt caching et la Batch API se cumulent-ils ? Oui, chez Anthropic les deux remises s'appliquent : un préfixe lu depuis le cache dans un batch coûte 10 % × 50 % = 5 % du prix d'entrée standard.

Le routing dégrade-t-il la qualité ? Seulement si tu routes sans évaluer. Le protocole : 200 requêtes représentatives, traitées par chaque tier, comparées. Tu bascules quand le petit modèle est à plus de 95 % de la qualité du gros sur ta tâche.

Par quoi commencer si je n'ai qu'une journée ? Observabilité minimale (le décorateur de la section 4.1) et prompt caching sur ton plus gros préfixe. Tu verras le gain le lendemain dans les usages.

Faut-il une gateway dès le départ ? Non. Un module Python de 30 lignes suffit pour une équipe et un fournisseur. La gateway devient pertinente quand plusieurs équipes ou plusieurs fournisseurs entrent en jeu.

L'auto-hébergement est-il un levier de coût ? Rarement en dessous de plusieurs dizaines de millions de tokens par jour. C'est un levier de souveraineté ou de confidentialité, et il doit être chiffré honnêtement, ingénierie et astreinte comprises.

Pour aller plus loin

La compaction de contexte et la mémoire externe sont traitées en profondeur dans notre formation sur l'architecture des systèmes agentiques, et le pattern orchestrateur/workers — avec son plafond de dépense — dans le guide pratique multi-agents. Pour choisir un modèle local par palier de matériel et comparer les prix API entre fournisseurs, le comparateur nAIvigate intègre un calculateur de coût mensuel par volume de tokens.

Si ta facture LLM est déjà en dérive et que tu veux un diagnostic chiffré de tes workflows — où va l'argent, quels leviers activer, dans quel ordre — c'est précisément ce que couvre un Radar IA.