Lab 4 : coût, performance, SLO et alertes

Durée : 1 h 35, plus le temps d’attente des alertes (jusqu’à 30 minutes pour la règle de qualité). Prérequis : labs 1 à 3.

En cours de validation en lab

Configuration pas encore exécutée de bout en bout dans un lab : les noms, versions et paramètres peuvent demander des ajustements.

Les prix changent vite et varient selon les contrats : ce guide n’en donne pas ; utilisez la grille datée de votre fournisseur.

Étape 1 : trafic simulé (15 min)

cd app && python lab4_cost_quality.py

Le script simule 80 requêtes mélangeant 4 clients, 6 modèles et 4 fonctionnalités. Aucun modèle n’est appelé : jetons, latences et erreurs sont tirés au hasard. Options : --n (nombre de requêtes), --interval (secondes entre deux requêtes), --tenant (tout le trafic sur un client), --token-factor (multiplie les jetons tirés, comme un contexte qui gonfle), --latency-factor, --error-rate, --prices (grille de prix, voir plus bas).

Les jetons d’entrée sont tirés uniformément entre 80 et 1 200 (640 en moyenne), ceux de sortie entre 40 et 600 (320 en moyenne) : 960 jetons par requête réussie. Une requête en erreur (1,5 % par défaut) ne consomme aucun jeton, d’où environ 946 jetons par requête en moyenne, erreurs comprises.

Mesurer en jetons, convertir en euros avec votre grille

Le budget et les SLO du lab sont exprimés en jetons : c’est l’unité dans laquelle la plupart des fournisseurs d’API facturent, elle mesure aussi la charge d’un modèle autohébergé et elle ne dépend d’aucun tarif. Sans grille de prix, le lab fonctionne entièrement et n’exporte aucune métrique de coût.

Pour obtenir un coût en euros, copiez prices.example.json (à la racine du kit, sans aucune valeur) en prices.json, renseignez la version, la date d’effet, la source, le nombre de jetons auquel s’appliquent les prix et un prix d’entrée et de sortie pour chacun des six modèles simulés, puis :

cd app && python lab4_cost_quality.py --prices ../prices.json

Le script calcule alors, pour chaque requête réussie, coût = t_in x p_in + t_out x p_out, où t_in et t_out sont les jetons d’entrée et de sortie, p_in et p_out vos prix ramenés au jeton. Il exporte mttl_client_cost_total avec le label mttl_pricing_version (version et date de la grille) : on sait ainsi quelle grille a produit un coût passé. Une grille incomplète ou non datée est refusée, plutôt que de produire un coût partiel. Un modèle autohébergé n’a pas de prix par jeton mais un coût d’infrastructure : indiquez votre coût interne ramené au jeton, ou 0 si vous le répartissez à part.

Étape 2 : le tableau de bord Cost & Quality (25 min)

Identifiez le client le plus consommateur, la fonctionnalité qui consomme le plus de jetons et le nombre moyen de jetons par requête : environ 950 avec les réglages par défaut. Les panneaux en euros, en bas du tableau de bord, restent vides tant que vous n’avez pas fourni de grille. Question à discuter : comment rapprocheriez-vous cette consommation du score de qualité des labs 2 et 3 ? (le kit ne relie pas encore les deux)

Étape 3 : définir les SLO (20 min)

Les SLO du lab, pour un assistant de support client. Ce sont les mêmes valeurs que le dictionnaire SLO du script et que les seuils des alertes :

Indicateur	Objectif	Alerte ou contrôle associé
Latence p95 des opérations chat	3 s au plus	plus de 3 s pendant 10 min
Score qualité (SLO pédagogique simplifié)	0,6 de fidélité moyenne sur 1 h, au moins	sous 0,6 pendant 30 min
Taux d’erreur	2 % sur 15 min, au plus	plus de 2 % pendant 15 min
Jetons moyens par requête (entrée et sortie)	2 000 au plus	panneau du tableau de bord, rouge au-delà de 2 000
Budget de jetons par client	1 000 000 par heure glissante	plus de 1 000 000 de jetons sur la dernière heure, pendant 5 min

La latence simulée suit une loi log-normale de paramètres 0,2 et 0,4 : médiane d’environ 1,2 s, p95 d’environ 2,4 s, sous l’objectif. Un modèle local sur un poste sans GPU (labs 1 à 3) peut dépasser 3 s : l’alerte de latence peut alors se déclencher sur ces labs et c’est un vrai constat. Dans un contrat, ajoutez une colonne d’engagement client, plus large que l’objectif interne. Si vous suivez aussi le coût en euros, fixez ce budget dans votre devise à partir de votre grille et gardez le budget en jetons, qui ne bouge pas quand les prix changent.

Pour voir le SLO de jetons par requête tomber, lancez python lab4_cost_quality.py --token-factor 2.5 : la moyenne attendue passe à 946 x 2,5, soit environ 2 360 jetons par requête et le tableau final du script affiche « HORS SLO » (sur vingt tirages de 80 requêtes, la moyenne observée est restée entre 2 180 et 2 630).

La ligne qui distingue ce tableau d’un jeu de SLO classique est celle de la qualité. Sans elle, les SLO ne voient aucune des défaillances propres à un LLM : un service disponible, rapide et dans son budget peut très bien répondre faux.

Un SLO pédagogique simplifié

Le SLO de qualité du lab est un seuil sur une moyenne : il suffit pour déclencher une alerte et voir la dérive, mais ce n’est pas un SLO de qualité de production. Une moyenne ne dit pas combien de réponses sont mauvaises et ne fournit pas de budget d’erreur. En production, le SLI de qualité est une proportion (part des réponses échantillonnées dont le score atteint un seuil) et on compare à la cible sa borne inférieure de confiance (borne de Wilson), ce qui permet un budget d’erreur et un burn rate. La définition complète et le dimensionnement de l’échantillon sont dans la partie IV de la méthode.

Étape 4 : cinq alertes de référence (15 min, plus l’attente)

Les règles de grafana/provisioning/alerting/alerts.yaml sont chargées au démarrage de Grafana (dossier MTTL). Grafana les évalue chaque minute ; une règle passe en alerte quand sa condition reste vraie pendant toute la durée indiquée. Le script doit donc tourner assez longtemps : c’est le rôle de --interval.

Alerte	Condition	Action	Comment la déclencher
Latence p95	plus de 3 s pendant 10 min	vérifier la charge GPU et la taille des prompts	python lab4_cost_quality.py --n 960 --interval 1 --latency-factor 2
Budget de jetons par client	plus de 1 000 000 de jetons sur la dernière heure, pendant 5 min	contacter le client, vérifier la taille des contextes et la limitation de débit	python lab4_cost_quality.py --n 2000 --interval 0.2 --tenant acme-corp
Qualité dégradée	score moyen sous 0,6 sur 1 h, pendant 30 min	suspecter une dérive, lancer un juge sur échantillon	python lab3_drift_detection.py --phase data --repeat 2
Taux d’erreur	plus de 2 % sur 15 min, pendant 15 min	analyse d’incident, vérifier le modèle	python lab4_cost_quality.py --n 1200 --interval 1 --tenant acme-corp --error-rate 0.1
Dérive	au moins 3 événements du même type en 30 min, pendant 5 min	revue du pipeline et du prompt, A/B contrôlé	python lab3_drift_detection.py --phase data --repeat 4

Le calcul derrière chaque commande :

• Latence : avec --latency-factor 2, chaque latence est doublée ; médiane vers 2,4 s, p95 vers 4,7 s. Estimé à partir des bornes d’histogramme du kit (2,56 et 5,12 s), le p95 vaut environ 5,0 s, au-dessus de 3 s. La requête porte sur 5 minutes glissantes : 960 requêtes à une par seconde font 16 minutes de trafic, de quoi tenir la condition 10 minutes.
• Budget de jetons : environ 946 jetons par requête, erreurs comprises ; 2 000 requêtes sur un seul client donnent environ 2 000 x 946, soit 1 890 000 jetons, près du double du seuil de 1 000 000. L’alerte lit gen_ai_client_token_usage_sum, la somme de l’histogramme des jetons, que l’exportateur prometheusremotewrite 0.108.0 nomme sans suffixe d’unité (l’unité {token}, entre accolades, est ignorée) ; ce client y compte 48 séries (6 modèles, 4 fonctionnalités, 2 types de jetons). À une requête toutes les 0,2 s, les 2 000 requêtes s’étalent sur environ 7 minutes, donc sur de nombreux exports de métriques (un toutes les 5 s). La somme dépasse 1 000 000 après environ 1 060 requêtes (1 000 000 / 946), soit vers 3 min 30 ; même si la première valeur de chacune des 48 séries n’était pas comptée, il manquerait quelques dizaines de milliers de jetons, soit quelques secondes de trafic. Grafana constate le dépassement à l’évaluation suivante, puis attend 5 minutes : l’alerte part entre 9 et 10 minutes après le lancement et la somme reste au-dessus du seuil pendant l’heure qui suit.
• Erreurs : 10 % d’erreurs tirées, sur un seul client. Le taux lu par VictoriaMetrics est un peu plus bas, car rate() ignore la première valeur de chaque nouvelle série, mais il reste plusieurs fois au-dessus de 2 % pendant les 20 minutes du lancement.
• Qualité : la phase de dérive de données du lab 3 pose des questions hors domaine, dont la fidélité tombe en général sous 0,6 (la valeur dépend du modèle). La moyenne porte sur l’heure écoulée : lancez la commande sur une pile sans autre trafic de qualité dans l’heure, puis attendez environ 30 minutes.
• Dérive : chaque passage de la phase de données en dérive émet un événement ; quatre passages dans le même processus en donnent quatre, au-dessus du seuil de trois même si la première valeur exportée n’entre pas dans l’augmentation calculée.

Le budget de jetons compte aussi les jetons des labs 1 à 3, qui portent le même label de client : sur une pile partagée, lancez la commande sur un client que ces labs n’ont pas utilisé dans l’heure, ou tenez compte de leur consommation.

Couper Ollama ne déclenche rien au lab 4 : son trafic est simulé. Pour voir des erreurs réelles, arrêtez Ollama pendant le lab 1 (étape 5).

Vérifiez que chaque alerte est routée vers le bon destinataire.

Étape 5 : votre plan à 30, 60 et 90 jours (20 min)

Rédigez votre plan sur la grille du module 5.

Récapitulatif du lab

Notion	Ce que le lab montre
Budget	en jetons, par requête et par client : il ne dépend d’aucun prix
Coût en euros	calculé côté application seulement avec votre grille de prix, versionnée et datée
SLO	toujours un SLO qualité en plus des classiques ; celui du lab est un SLO pédagogique simplifié
Alertes	chaque alerte a un responsable et une procédure
Ordre	instrumenter, puis évaluer, puis alerter

Révisé le 2 octobre 2026, prix retirés : encadré sur l’état du kit, une seule définition des SLO (script, leçon, alertes), budget et SLO en jetons, alerte de budget de jetons par client à la place de l’alerte de coût, coût en euros seulement avec une grille de prix datée fournie par l’utilisateur, options du simulateur (--n, --interval, --tenant, --token-factor, --latency-factor, --error-rate, --prices) et calcul de chaque déclenchement, alerte d’erreurs limitée à un client à cause de rate(), question coût et qualité présentée comme ouverte.

Révisé le 4 octobre 2026 : le SLO de qualité du lab est désigné comme SLO pédagogique simplifié (seuil sur une moyenne), encadré sur le SLO de qualité de production (proportion, borne de Wilson) avec renvoi à la partie IV de la méthode.

Marquer comme lue