Coûts, latence et capacity planning

Pourquoi ce chapitre est le plus rentable à lire

Un pipeline RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire qui répond juste mais met huit secondes à répondre, ou qui coûte plus cher par requête que la valeur qu'il génère, ne reste pas longtemps en production — soit les utilisateurs l'abandonnent, soit la facture cloud finit par alerter quelqu'un en interne. La qualité de la réponse est une condition nécessaire à la mise en production ; elle n'est pas suffisante. Ce chapitre traite l'autre moitié du problème : où part l'argent à chaque requête, où part le temps de réponse, et comment dimensionner l'infrastructure pour tenir un engagement de service dans la durée — pas seulement le jour de la démo.

Ces trois contraintes — coût, latence, capacité — sont liées plus étroitement qu'il n'y paraît. Réduire la latence en enrichissant le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire envoyé au modèle augmente le coût. Réduire le coût en traitant les requêtes par lot augmente la latence perçue. Absorber un pic de trafic sans dégrader la latence exige une capacité de réserve qui coûte de l'argent même hors pic. Piloter un système RAG en production revient à arbitrer en continu entre ces trois axes, pas à optimiser l'un d'eux isolément.

Les chapitres précédents ont traité la pertinence des réponses — chunkingChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire, embeddingsembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire, retrieval, rerank, grounding. Celui-ci part du principe que ces briques fonctionnent, et se concentre sur ce qu'il faut mesurer et arbitrer avant d'exposer ce pipeline à un trafic réel. Un pipeline précis mais impossible à opérer économiquement n'est pas prêt pour la production : il est prêt pour la démo.

Anatomie du coût par requête

Décomposer le coût d'une requête RAG révèle une hiérarchie que l'intuition trompe souvent. On imagine volontiers que le retrieval vectoriel, avec ses millions de documents indexés, pèse lourd dans la facture. En réalité, c'est presque toujours la génération qui domine.

La raison de ce déséquilibre tient à la structure même d'un pipeline RAG : le contexte envoyé au modèle de génération contient le prompt système, les instructions, et surtout les passages retrievés — souvent 5 à 10 passages de 200 à 500 tokens chacun, soit 2000 à 5000 tokens d'entrée pour une requête utilisateur qui, elle, ne fait que quelques dizaines de tokens. Les tokens de sortie coûtent généralement 3 à 5 fois plus cher à l'unité que les tokens d'entrée, mais le volume d'entrée — dominé par le contexte retrievé — l'emporte largement en valeur absolue dès que la réponse reste courte à modérée. Sur un pipeline RAG typique, la génération représente ainsi 80 à 95 % du coût total par requête : les optimisations doivent donc cibler en priorité ce qui entre dans le prompt — nombre et taille des passages injectés, longueur du prompt système — avant d'optimiser le retrieval ou le rerank, dont le coût marginal reste largement inférieur.

Le budget de latence : construire la cascade

Mesurer la latence par sa moyenne est une erreur fréquente et trompeuse. La moyenne lisse les cas dégradés qui, en production, sont précisément ceux qui déterminent l'expérience perçue par une partie significative des utilisateurs. La pratique standard consiste à raisonner en percentiles : le P50 (latence médiane, la moitié des requêtes fait mieux), le P95 (95 % des requêtes font mieux, 5 % font pire) et le P99 (le centile le plus exigeant, souvent utilisé pour dimensionner les cas limites).

Un pipeline RAG additionne les latences de plusieurs étages séquentiels avant de produire une réponse. La figure suivante détaille cette cascade pour une requête interactive typique.

Le streaming (afficher les tokens au fur et à mesure de leur génération) réduit la latence perçue — le temps jusqu'au premier token — sans réduire la latence totale : le modèle consomme les mêmes ressources de calcul pendant toute la génération. C'est un levier d'expérience utilisateur, pas un levier de coût ou de capacité.

La latence d'un fournisseur de LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire en API varie fortement selon la contention sur son infrastructure — requêtes concurrentes, longueur variable des réponses, effets de file d'attente aux heures de pointe. Un P50 confortable à 1,2 seconde peut coexister avec un P99 à 8 ou 10 secondes. Ne jamais dimensionner un engagement de service (SLA) sur la médiane seule : c'est la queue de distribution qui détermine si les utilisateurs les plus mal servis abandonnent le produit.

Réduire la facture : cache, batch, compression de contexte

Quatre leviers permettent de réduire coût et latence sans dégrader la pertinence des réponses, à condition de les utiliser à bon escient.

Cache de prompt (prompt caching). Une partie du contexte envoyé au modèle — instructions système, exemples few-shotFew-shotIATechnique de prompt où l'on fournit quelques exemples entrée-sortie pour guider le modèle sans réentraînement.Voir dans le glossaire, documents de référence statiques — se répète à l'identique d'une requête à l'autre. Les fournisseurs de LLM proposent une mise en cache de ce préfixe côté serveur : le premier appel paie un coût d'écriture légèrement supérieur au tarif normal, les appels suivants qui réutilisent ce préfixe dans une fenêtre de temps donnée (typiquement quelques minutes) paient un tarif de lecture très réduit, souvent 90 % moins cher que le tarif d'entrée standard. Cela réduit à la fois le coût et la latence, puisque le modèle n'a pas à retraiter ce préfixe.

Cache sémantique. Contrairement au cache de prompt, qui exige une correspondance exacte, le cache sémantique stocke l'embedding et la réponse de requêtes passées, et sert directement une réponse en cache si une nouvelle requête dépasse un seuil de similarité avec une requête déjà traitée. Il cible les requêtes récurrentes reformulées différemment — utile sur un support client ou une FAQ, beaucoup moins sur une recherche exploratoire où chaque requête est réellement nouvelle. Son risque principal : servir une réponse devenue obsolète si le corpus source a changé depuis sa mise en cache. Sur les domaines à forte fraîcheur (actualité, tarifs, stock), un TTLTTLRéseauxCompteur porté par chaque paquet IP, décrémenté à chaque routeur traversé. À zéro, le paquet est détruit — ce qui évite les boucles infinies et permet à traceroute de cartographier un chemin.Voir dans le glossaire court et une invalidation systématique à chaque mise à jour du corpus sont indispensables — l'économie réalisée ne vaut rien si elle produit des réponses fausses.

Traitement par batch. Les fournisseurs proposent souvent une tarification réduite — de l'ordre de 50 % — pour les appels asynchrones traités par lot, avec un délai de restitution de quelques minutes à quelques heures. Ce mode convient à l'ingestion, au ré-embedding d'un corpus ou à l'évaluation offline d'un pipeline, jamais à un chat en temps réel où le délai induit le rend inutilisable.

Compression de contexte. Réduire le nombre de passages injectés (top-k), résumer les passages longs avant insertion, ou dé-dupliquer des chunks redondants issus de sources proches réduit directement le volume de tokens d'entrée — donc le coût — sans dégrader la qualité si la compression est bien calibrée.

Si un prompt système fait 3000 tokens et est réutilisé à chaque requête, la mise en cache réduit son coût d'environ 90 % dès le deuxième appel effectué dans la fenêtre de cache. Le seuil de rentabilité est atteint dès que ce préfixe est réutilisé plus de quelques fois par fenêtre — presque toujours le cas sur un service à trafic soutenu.

Un service de support client traite 50 000 requêtes par jour, avec un prompt système statique de 2000 tokens et un contexte retrievé moyen de 3000 tokens. La mise en cache du prompt système réduit le coût de ce segment fixe d'environ 90 %. Un cache sémantique qui intercepte 30 % des requêtes — largement des questions récurrentes de type FAQ — évite entièrement l'appel de génération sur cette part. Combinés, ces deux leviers réduisent le coût total de génération d'environ 35 à 40 %, sans aucun changement du retrieval ni de la qualité perçue.

SLOs et SLAs : engager sans se piéger

Trois notions distinctes structurent tout engagement de service. Le SLI (Service Level Indicator) est une mesure — par exemple, la latence P95 des requêtes de génération sur une fenêtre glissante d'une heure. Le SLO (Service Level Objective) est un objectif interne fixé sur ce SLI — par exemple, « P95 < 3 secondes ». Le SLA (Service Level Agreement) est un engagement contractuel externe, généralement assorti de pénalités, construit à partir d'un ou plusieurs SLO — souvent avec une marge de sécurité par rapport au SLO interne, pour absorber l'incertitude de mesure.

Fixer un SLO trop ambitieux transforme chaque incident mineur en violation contractuelle. Un SLO doit refléter ce qui est réellement tenable en régime de charge normal, avec une marge pour les pics — pas une aspiration marketing.

Un SLO de disponibilité à 99,5 % sur un mois autorise environ 3 heures 40 d'indisponibilité cumulée. Ce budget d'erreur est un outil d'arbitrage, pas une contrainte à éviter à tout prix : tant qu'il n'est pas épuisé, il est légitime de déployer des changements risqués ou d'expérimenter. Une fois consommé, la priorité bascule vers la stabilité jusqu'au mois suivant. C'est ce mécanisme qui évite à la fois l'immobilisme excessif et les déploiements imprudents.

Capacity planning : dimensionner l'infrastructure

La loi de Little donne une relation simple et robuste entre trafic, latence et concurrence : le nombre moyen de requêtes traitées simultanément est égal au débit (requêtes par seconde) multiplié par la latence moyenne de traitement. Un service qui reçoit 10 requêtes par seconde avec une latence moyenne de 2,5 secondes doit pouvoir absorber environ 25 requêtes en cours de traitement simultanément — avant même de compter la marge nécessaire pour les pics de trafic.

Conséquence directe et souvent sous-estimée : tout ce qui rallonge la latence par requête augmente mécaniquement le nombre de requêtes concurrentes que l'infrastructure doit supporter à débit constant — donc le nombre d'instances, de connexions et de quotas API à provisionner.

Quelques principes pratiques pour dimensionner un pipeline RAG en production :

• Autoscaler sur la profondeur de file d'attente, pas uniquement sur l'utilisation CPU. Un composant de rerank auto-hébergé peut avoir un CPU peu chargé tout en accumulant une file d'attente croissante si le débit dépasse sa capacité de traitement par seconde.
• Maintenir un pool chaud minimal pour les composants nécessitant un chargement de modèle coûteux (rerankers ou embeddings sur GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire) : le cold start d'une nouvelle instance peut atteindre plusieurs dizaines de secondes, incompatible avec un pic soudain. Le coût fixe de ce pool est presque toujours inférieur à celui d'une dégradation de latence perçue par les utilisateurs.
• Respecter les limites de débit (rate limits) des fournisseurs de LLM externes, souvent le facteur limitant réel avant même la capacité de calcul propre — un plan de capacité doit inclure une négociation de quota anticipée si le trafic prévu approche ces limites.
• Prévoir une dégradation contrôlée (backpressure) plutôt qu'un échec complet en cas de saturation : file d'attente avec délai annoncé, réponse partielle, ou basculement vers un modèle plus léger, plutôt qu'une erreur brute renvoyée à l'utilisateur.

Pièges fréquents

• Optimiser le retrieval alors que la génération domine le coût. Réduire la latence d'un index vectorielbase vectorielleIABase spécialisée qui indexe des embeddings pour retrouver rapidement les passages les plus proches d'une requête (cœur du RAG).Voir dans le glossaire de 30 à 15 millisecondes n'a aucun effet perceptible si la génération prend 1800 millisecondes juste après.
• Dimensionner sur la moyenne plutôt que sur les percentiles. Une latence moyenne acceptable peut masquer un P99 qui rend le service inutilisable pour une fraction significative des utilisateurs aux heures de pointe.
• Cache sémantique sans stratégie d'invalidation. Un cache qui économise de l'argent en servant des réponses obsolètes transforme une optimisation de coût en risque de confiance envers le produit.
• SLA calqué sur les performances observées en test, sans marge. Les conditions de charge réelle en production — trafic concurrent, contention chez le fournisseur de LLM — dégradent systématiquement les latences mesurées en environnement contrôlé.
• Absence de suivi du coût par requête dans le temps. Un modèle, un prompt système ou un volume de contexte qui évoluent progressivement peuvent faire dériver le coût unitaire sans alerte si ce coût n'est pas suivi comme une métrique à part entière.

Checklist avant mise en production

• Le coût moyen par requête est mesuré et décomposé par étage (embedding, retrieval, rerank, génération), pas seulement estimé a priori.
• Le budget de latence est défini en percentiles (P50, P95, P99), pas en moyenne, et mesuré en conditions de charge réaliste.
• Le cache de prompt est activé sur les segments statiques et répétés du contexte (instructions système, documents de référence fixes).
• Un cache sémantique, s'il est utilisé, dispose d'une stratégie d'invalidation explicite adaptée à la fraîcheur du domaine.
• Les tâches non interactives (ingestion, ré-embedding, évaluation offline) passent par une API batch plutôt que par des appels synchrones un par un.
• Les SLO sont fixés à partir de mesures réelles de capacité, pas d'une aspiration commerciale, et un budget d'erreur explicite encadre les arbitrages vélocité/stabilité.
• La capacité est dimensionnée selon la loi de Little (débit × latence moyenne = concurrence), avec une marge pour les pics de trafic.
• Un mécanisme de dégradation contrôlée existe en cas de saturation, plutôt qu'un échec brut renvoyé à l'utilisateur.

En résumé

Un pipeline RAG pertinent qui n'a pas été pensé pour son coût et sa latence en production reste un prototype, quelle que soit la qualité de ses réponses. La génération domine presque toujours la facture et le temps de réponse : c'est là que doivent porter en priorité les efforts de cache et de compression de contexte. Les percentiles, pas la moyenne, doivent guider le dimensionnement de la latence et de la capacité. Et un engagement de service — SLO comme SLA — n'a de valeur que s'il reflète ce que l'infrastructure peut réellement tenir sous charge réelle, pas ce qu'elle a démontré une fois en environnement contrôlé.