Coût, latence et LLMOps

L’économie des tokens

Les modèles hébergés sont facturés au token, le plus souvent avec un prix par million de tokens, et des prix distincts pour les tokens d’entrée (tout ce qui est envoyé : prompt système, définitions d’outils, documents récupérés, historique de la conversation et message de l’utilisateur) et les tokens de sortie (tout ce qui est généré). Les tokens de sortie coûtent généralement plusieurs fois plus cher que les tokens d’entrée, car l’entrée est traitée en parallèle en une seule passe (le prefill), alors que la sortie est générée un token à la fois, chacun nécessitant sa propre passe dans le modèle (le decode). Les modèles de raisonnement (section 12.1) facturent aussi leurs tokens de raisonnement internes comme des tokens de sortie, même lorsqu’ils ne sont pas affichés : une même question peut donc coûter des montants très différents selon la durée de réflexion du modèle.

Le coût d’un appel est simplement : tokens d’entrée × prix d’entrée + tokens de sortie × prix de sortie. Les surprises architecturales tiennent à ce qui détermine le nombre de tokens. Dans un chat, tout l’historique est normalement renvoyé à chaque tour : l’entrée grossit donc à chaque tour, et le total sur une conversation croît à peu près comme le carré de sa longueur. Les définitions d’outils et un long prompt système se paient à chaque appel. La récupération ajoute des milliers de tokens par question, et les agents qui enchaînent les outils en boucle (section 12.4) font plusieurs appels par requête de l’utilisateur. Dans la plupart des assistants en production, les tokens d’entrée dominent la facture, même si chacun coûte moins cher.

Auto-héberger un modèle à poids ouverts change la forme du coût sans le supprimer : vous payez le temps GPU qu’il soit utilisé ou non, si bien que le coût par token dépend du taux d’utilisation et du nombre de requêtes que le serveur peut traiter ensemble. Les habitudes FinOps de la section 10.8 s’appliquent directement : exprimez le coût par unité de valeur métier (par conversation, par ticket résolu, par document traité), comparez-le à l’alternative (le coût de traitement par un conseiller humain) et imputez-le aux fonctionnalités et aux équipes. Les prix de cette section sont des chiffres donnés à titre d’illustration, choisis pour faciliter le calcul, et non des prix catalogue actuels ; les prix réels varient d’un fournisseur à l’autre et ont fortement baissé au fil du temps.

Latence : délai jusqu’au premier token et vitesse de génération

La latence d’une réponse de modèle comporte deux parties principales. Le délai jusqu’au premier token (TTFT) couvre tout ce qui précède l’arrivée du premier token de sortie : votre propre prétraitement (garde-fous d’entrée, récupération, re-ranking), le réseau, la mise en file d’attente chez le fournisseur et le prefill, qui croît avec le nombre de tokens d’entrée. Ensuite, la sortie arrive à la vitesse de génération du modèle, mesurée en tokens de sortie par seconde ; le temps total vaut donc à peu près TTFT + tokens de sortie ÷ tokens par seconde. Les modèles de raisonnement ajoutent une phase de réflexion avant le premier token visible, qui peut durer des secondes, voire des minutes.

Il en découle deux conséquences. D’abord, la longueur de la sortie est en général le levier le plus important sur la latence : diviser par deux une réponse de 400 tokens fait gagner plus de temps que n’importe quelle optimisation réseau. Demander des réponses concises, fixer une longueur de sortie maximale et utiliser des sorties structurées plutôt que de la prose sont autant d’aides. Ensuite, chaque appel d’outil est un aller-retour supplémentaire complet, avec son propre prefill et son propre decode : un agent qui fait quatre appels d’outils avant de répondre est quatre fois plus lent qu’un appel unique, quelle que soit la vitesse du modèle. Spécifiez et surveillez la latence en percentiles, pas en moyennes (section 2.4) : TTFT au p95 et temps total par tour au p95, car la mise en file d’attente chez les fournisseurs de modèles rend la queue de distribution bien plus longue que la médiane aux heures chargées.

Streaming

Le streaming envoie les tokens au client au fur et à mesure de leur génération, généralement sous forme de server-sent events sur HTTP. Il ne fait pas terminer la réponse plus tôt, mais les utilisateurs jugent la réactivité surtout au moment où quelque chose commence à se produire : une réponse de 4 secondes qui commence après 1 seconde paraît bien plus rapide qu’une réponse qui s’affiche d’un coup. Le streaming a des coûts architecturaux. Chaque proxy, gateway et équilibreur de charge sur le chemin doit laisser passer le flux sans le mettre en mémoire tampon et garder ouvertes des connexions de longue durée. Les garde-fous de sortie (section 12.6) ne peuvent plus inspecter toute la réponse avant que l’utilisateur la voie : soit ils vérifient les fragments au passage (et peuvent devoir retirer du texte déjà affiché), soit ils retardent le flux d’une phrase environ. Les sorties structurées qui déclenchent des actions ne peuvent être exploitées qu’une fois complètes et validées : diffusez donc la prose à l’utilisateur en streaming et gardez les actions pour la fin. La facturation, la journalisation et le traçage doivent gérer les flux que le client abandonne en cours de route.

Mise en cache des prompts et cache sémantique

La mise en cache des prompts (prompt caching, aussi appelée mise en cache des préfixes ou du contexte) réutilise l’état interne déjà calculé par le fournisseur pour un préfixe de prompt identique traité récemment. Les tokens d’entrée en cache sont facturés avec une forte remise (certains fournisseurs facturent environ un dixième du prix d’entrée normal, d’autres accordent une remise moindre, et certains facturent un supplément pour écrire dans le cache), et le prefill de cette partie est sauté, ce qui réduit aussi le TTFT. C’est l’optimisation des coûts la plus efficace pour les assistants dotés d’instructions longues et stables. Elle ne fonctionne que si le préfixe est identique octet pour octet : l’agencement du prompt devient donc une préoccupation architecturale. Placez d’abord le contenu statique (prompt système, définitions d’outils, politiques, exemples few-shot), puis le contenu qui change lentement (historique de la conversation), et en dernier le contenu propre à chaque requête (documents récupérés, nouveau message). Un horodatage ou un nom d’utilisateur en tête du prompt système neutralise le cache sans que personne ne le remarque. Les serveurs d’inférence auto-hébergés comme vLLM offrent la même technique, appelée automatic prefix caching (mise en cache automatique des préfixes).

Le cache sémantique est différent : il stocke des réponses entières indexées par le sens de la question, à l’aide d’embeddings, et renvoie une réponse stockée lorsqu’une nouvelle question est suffisamment similaire, sans appeler le modèle du tout. Il peut faire économiser beaucoup sur des questions répétitives et non personnelles (quels sont vos horaires de livraison ?), mais il est plus risqué qu’il n’y paraît. Des questions similaires peuvent appeler des réponses différentes (puis-je annuler ma commande ? et annulez ma commande), le seuil de similarité arbitre entre le taux de succès et les mauvaises réponses, et les règles de la section 7.6 s’appliquent toujours : la clé doit inclure tout ce qui change la réponse, les réponses en cache deviennent périmées quand les politiques changent, et rien de personnel ne doit jamais être servi depuis un cache partagé. Mesurez le taux de faux succès sur un échantillon étiqueté avant de vous y fier. Un simple cache à correspondance exacte pour les appels déterministes, comme la classification à température 0, est plus simple et sûr.

Traitement par lots

Tous les appels de modèle n’ont pas besoin d’une réponse en quelques secondes. La synthèse nocturne, l’étiquetage d’un arriéré de tickets, la génération d’embeddings pour une réindexation et l’exécution de suites d’évaluation peuvent tous attendre. La plupart des grands fournisseurs proposent des interfaces d’inférence par lots (batch) qui acceptent un fichier de requêtes et renvoient les résultats de façon asynchrone dans un délai annoncé (souvent jusqu’à 24 heures), avec une remise substantielle, souvent de l’ordre de la moitié du prix normal, et des limites de débit distinctes et plus élevées. Sur le plan architectural, c’est le traitement asynchrone fondé sur des files d’attente de la section 9.3 : concevez la tâche pour qu’elle soit idempotente, suivez le statut de chaque requête et gérez les échecs partiels.

Avec des modèles auto-hébergés, le traitement par lots a lieu dans le serveur d’inférence : le batching continu entrelace les étapes de decode de nombreuses requêtes concurrentes sur un même GPU, ce qui multiplie le débit. Le compromis est le compromis habituel entre débit et latence : des lots plus gros donnent des tokens moins chers mais des réponses individuelles plus lentes ; le trafic interactif et le trafic hors ligne sont donc souvent servis par des pools séparés aux réglages différents.

Choix du modèle et cascades pour réduire les coûts

La décision de coût la plus importante est de savoir quel modèle traite chaque tâche, et la réponse est en général le plus petit qui réussit la suite d’évaluation de cette tâche (section 12.5). Les prix des petits et des grands modèles diffèrent couramment d’un facteur dix ou plus, alors que de nombreuses tâches (classer une intention, extraire un numéro de commande, répondre à une question de statut à partir de données structurées) n’ont pas besoin d’un grand modèle. Le routage envoie chaque requête vers un modèle adapté sur la base d’une classification bon marché ; une cascade de modèles essaie d’abord un petit modèle et passe à un plus grand lorsque la sortie échoue à la validation ou que le petit modèle signale une faible confiance (section 12.2). FrugalGPT (Chen, Zaharia et Zou, 2023) a montré des cascades atteignant la qualité du modèle le plus puissant pour une fraction du coût sur leurs benchmarks.

Le coût attendu d’une cascade à deux étapes est le coût du petit modèle plus le taux d’escalade multiplié par le coût du grand modèle. Les cascades ne sont donc rentables que si la plupart des requêtes restent sur le petit modèle, et elles cachent un piège en matière de latence : les requêtes escaladées paient les deux tentatives, si bien que la queue de distribution ralentit alors même que la moyenne s’améliore. Un routage en amont évite la double tentative mais dépend de la précision du routeur. D’autres réductions de tokens coûtent souvent encore moins : raccourcir le prompt système, récupérer moins de fragments mais de meilleure qualité, résumer les tours de conversation plus anciens, plafonner la longueur de la sortie, réduire l’effort de raisonnement des modèles de raisonnement pour les tâches faciles et, pour une tâche unique à très gros volume, envisager le fine-tuning ou la distillation d’un petit modèle.

Quotas, limites de débit et échelles de repli

Les fournisseurs de modèles imposent des limites de débit : requêtes par minute, tokens d’entrée et de sortie par minute, requêtes concurrentes et parfois plafonds quotidiens, signalées par des réponses HTTP 429, généralement accompagnées d’un en-tête Retry-After. Votre propre gateway doit aussi imposer des quotas, par utilisateur, par locataire (tenant) et par fonctionnalité, à la fois pour partager équitablement la capacité et pour vous protéger du risque de consommation illimitée de la section 12.6. Les patrons de résilience de la section 9.4 s’appliquent : des délais d’expiration sur chaque appel, des nouvelles tentatives avec backoff exponentiel et jitter uniquement pour les erreurs qui s’y prêtent, des disjoncteurs, un cloisonnement qui empêche une fonctionnalité bruyante d’épuiser le quota partagé, et une dégradation gracieuse (une réponse toute faite et un lien vers l’assistance humaine valent mieux qu’un indicateur de chargement qui tourne sans fin).

Une échelle de repli (fallback ladder) liste d’autres modèles et fournisseurs à essayer dans l’ordre lorsque le premier choix échoue, est soumis à une limite de débit ou renvoie un résultat invalide. Une bonne échelle a un budget de temps total, pour que l’utilisateur ne patiente pas à travers tous les échelons ; elle met un échelon au repos aussi longtemps que le fournisseur le demande après une réponse 429 au lieu de le marteler ; elle traite une réponse illisible ou non conforme au schéma comme un échec qui fait passer à l’échelon suivant ; et elle garde des prompts portables d’un modèle à l’autre. Chaque échelon doit réussir la suite d’évaluation : un modèle de repli non testé est une baisse de qualité silencieuse, précisément au moment où le système est sous tension. Les fonctionnalités d’IA de ce cours fonctionnent ainsi. ArchitectBot et le correcteur des tests essaient une échelle de modèles à poids ouverts hébergés, avec un délai d’expiration par modèle et un budget de temps global, mettent un modèle en pause après une réponse de limitation de débit pendant le temps demandé par le fournisseur, et se replient sur un second fournisseur en dernier recours ; les recherches web ont des plafonds quotidiens et mensuels, et les visiteurs sont soumis à une limitation de débit.

LLMOps : versionnage, traçage et suivi des coûts

Le LLMOps est l’ensemble des pratiques permettant de construire, mettre en production et exploiter des applications fondées sur de grands modèles de langage ; il adapte le MLOps et le DevOps à des composants dont le comportement est défini par des prompts, des modèles et des données autant que par du code. Sa première règle est que tout ce qui façonne le comportement est un artefact versionné : les gabarits de prompts (conservés dans le dépôt ou dans un registre de prompts avec des identifiants de version immuables), les identifiants de modèles épinglés sur des versions datées plutôt que sur des alias flottants, les schémas d’outils, les paramètres de récupération, le modèle d’embedding et la version de l’index (changer de modèle d’embedding impose de recalculer les embeddings de tout le corpus), les règles des garde-fous et les jeux de données d’évaluation. Une version est une combinaison précise de ces éléments, déployée par le même pipeline, les mêmes feature flags et les mêmes déploiements canari que le code (section 10.5), avec ses résultats d’évaluation joints.

La deuxième règle est que chaque appel de modèle est tracé. Chaque appel devient un span dans la trace distribuée de la requête de l’utilisateur (section 9.6), portant le modèle, la version du prompt, le nombre de tokens d’entrée et de sortie, la latence, le TTFT, le coût et le résultat, avec des spans enfants pour la récupération et les appels d’outils, afin qu’une réponse lente ou fausse puisse être suivie pas à pas. Les conventions sémantiques d’OpenTelemetry pour l’IA générative normalisent les noms, comme gen_ai.operation.name, gen_ai.provider.name, gen_ai.request.model et gen_ai.usage.input_tokens, ainsi que des métriques pour la durée des opérations et l’utilisation des tokens. En octobre 2026, ces conventions ont toujours le statut Development et viennent d’être déplacées dans leur propre dépôt ; des noms ont changé d’une version à l’autre (gen_ai.system est devenu gen_ai.provider.name, par exemple, et les métriques de tokens sont en cours de réorganisation) : épinglez donc la version qu’émet votre instrumentation. L’enregistrement du texte des prompts et des complétions est optionnel (opt-in) dans les conventions, et pour une bonne raison : il capture des données à caractère personnel et exige donc les contrôles de conservation et d’accès de la section 12.8.

La troisième règle est que le coût se surveille comme la latence. Imputez les dépenses en tokens par fonctionnalité, locataire, modèle et version de prompt ; fixez des budgets avec des alertes à la fois sur la dépense absolue et sur le coût unitaire (coût par conversation) ; et guettez les signatures des problèmes : une modification de prompt qui a doublé les tokens d’entrée, un agent coincé dans une boucle d’outils, un taux de succès du cache qui s’est effondré après un déploiement, ou un compte qui génère un dixième de tout le trafic. Enfin, l’évaluation s’exécute dans le pipeline (section 12.5), afin que le coût, la latence et la qualité soient jugés ensemble pour chaque version.

from opentelemetry import trace

tracer = trace.get_tracer("support-assistant")

def ask_model(client, messages, model="medium-2026-05", prompt_version="refund-v14"):
    with tracer.start_as_current_span(f"chat {model}") as span:
        span.set_attribute("gen_ai.operation.name", "chat")
        span.set_attribute("gen_ai.provider.name", "example-provider")
        span.set_attribute("gen_ai.request.model", model)
        span.set_attribute("app.prompt.version", prompt_version)  # our own attribute
        reply = client.chat(model=model, messages=messages, max_tokens=300)
        span.set_attribute("gen_ai.usage.input_tokens", reply.usage.input_tokens)
        span.set_attribute("gen_ai.usage.output_tokens", reply.usage.output_tokens)
        return reply