Observabilité, coûts et SLA

Pourquoi l'observabilité change de nature en local

Tant qu'un LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire tourne sur l'API d'un fournisseur externe, l'essentiel de l'observabilité est déléguée : le fournisseur garantit une disponibilité, publie (parfois) des temps de réponse indicatifs, et facture à l'usage. La seule chose que l'entreprise pilote, c'est sa consommation.

Dès qu'un modèle est déployé en interne — sur Ollama pour des usages ponctuels, sur vLLM pour du service à plusieurs équipes — cette délégation disparaît. L'entreprise devient son propre fournisseur d'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire. Elle hérite donc de toutes les responsabilités qui vont avec : mesurer la latence perçue par les utilisateurs, détecter la saturation avant qu'elle ne provoque des erreurs, budgétiser un coût qui n'est plus une ligne de facturation mensuelle mais une infrastructure à amortir, et définir un niveau de service qu'elle est réellement en mesure de tenir.

Un 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 local sans observabilité n'est pas un service, c'est un serveur qui répond la plupart du temps. La différence entre les deux se joue dans la capacité à détecter une dégradation avant qu'un utilisateur ne la signale.

Les métriques qui comptent réellement

Il existe une tentation classique en début de déploiement : instrumenter tout ce qui est mesurable. En pratique, un socle restreint de métriques couvre la quasi-totalité des besoins de pilotage. Les développer dans l'ordre a du sens, car chacune répond à une question opérationnelle précise.

Latence : p50, p95, p99

La latence moyenne est une métrique trompeuse pour l'inférence LLM, car la distribution des temps de réponse est fortement asymétrique. Une requête courte (résumé de 50 tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire) et une requête longue (génération de 2000 tokens) n'ont rien de comparable, et le batching dynamique de vLLM introduit une variance supplémentaire selon la charge concurrente au moment de la requête.

C'est pourquoi on raisonne en percentiles :

• p50 (médiane) : donne une idée de l'expérience « typique »
• p95 : capture l'expérience des utilisateurs dans les 5 % de requêtes les plus lentes — c'est souvent le chiffre qui figure dans un SLA
• p99 : révèle les cas extrêmes, souvent liés à une contention 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 ou à une file d'attente qui se remplit

Il faut par ailleurs distinguer deux temps bien différents dans une réponse LLM :

• le TTFT (time to first token), qui mesure la latence perçue avant que l'utilisateur ne voie apparaître le premier mot — déterminant pour l'expérience en streaming
• l'ITL (inter-token latency), le temps entre deux tokens consécutifs une fois la génération lancée, qui détermine la vitesse de lecture perçue

Un déploiement peut avoir un TTFT excellent (file d'attente courte) et un ITL dégradé (GPU saturé par du batching agressif) : les deux métriques racontent des histoires différentes et doivent être suivies séparément.

Pour un usage conversationnel interne, viser un TTFT p95 sous 1,5 seconde et un débit de génération supérieur à 15-20 tokens/s par requête donne une expérience jugée fluide par la majorité des utilisateurs. En dessous de 8-10 tokens/s, les retours utilisateurs deviennent négatifs de façon quasi systématique.

Débit en tokens : entrée et sortie séparément

Le débit (throughput) global du serveur s'exprime en tokens par seconde, mais il faut le décomposer en tokens d'entrée (promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire) et tokens de sortie (génération), car leur coût de calcul n'est pas symétrique. Le traitement du prompt (prefill) est parallélisable et rapide ; la génération token par token (decode) est séquentielle et constitue le vrai goulot d'étranglement GPU.

Suivre ce ratio entrée/sortie dans le temps permet aussi de détecter des dérives d'usage : une équipe qui se met à envoyer des prompts de 8000 tokens (documents entiers collés dans 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) change radicalement le profil de charge, même sans augmentation du nombre de requêtes.

Utilisation GPU et VRAM

Deux métriques distinctes, souvent confondues :

• l'utilisation de calcul (SM utilization) indique si les cœurs GPU sont actifs
• l'occupation VRAM indique combien de mémoire est retenue par les poids du modèle, le KV-cache et les buffers d'inférence

Un GPU peut afficher 95 % d'utilisation VRAM tout en étant sous-exploité en calcul — signe fréquent d'un KV-cache mal dimensionné qui monopolise la mémoire sans que le débit ne suive. À l'inverse, une VRAM confortable mais un calcul saturé signale généralement qu'il est temps d'ajouter une instance plutôt que d'augmenter la taille du batch.

nvidia-smi seul ne suffit pas à un pilotage sérieux : il donne un instantané, pas une série temporelle exploitable en alerting. vLLM expose nativement des métriques Prometheus (vllm:gpu_cache_usage_perc, vllm:num_requests_running, vllm:num_requests_waiting, vllm:time_to_first_token_seconds) qu'il faut scraper et conserver dans le temps. S'appuyer uniquement sur des captures manuelles au moment d'un incident revient à diagnostiquer un accident de la route après avoir jeté la boîte noire.

Out-of-memory (OOM) : le signal d'alerte le plus sous-estimé

Un OOM sur un serveur d'inférence n'est presque jamais un événement isolé : il traduit un dimensionnement de KV-cache trop optimiste par rapport à la longueur réelle des contextes envoyés, ou une concurrence de requêtes supérieure à ce que la VRAM disponible permet d'absorber. Contrairement à un service web classique où un OOM tue un processus et en relance un autre en quelques secondes, un OOM sur un LLM local implique souvent un rechargement complet du modèle en mémoire — plusieurs dizaines de secondes, parfois plusieurs minutes pour les modèles de grande taille — pendant lesquelles le service est indisponible.

Le nombre d'OOM par jour doit figurer comme métrique de premier plan, au même titre que le taux d'erreur HTTP. Un OOM occasionnel peut être toléré en phase de rodage ; un OOM récurrent signale un problème de capacité qu'aucun ajustement de code applicatif ne résoudra — seule une révision du gpu_memory_utilization, du nombre maximal de séquences concurrentes, ou l'ajout de VRAM y remédie.

Construire un tableau de bord minimal

Un tableau de bord surchargé n'est consulté par personne en dehors des incidents. L'objectif est un socle de 6 à 8 panneaux, lisible en moins de trente secondes par une personne d'astreinte qui n'a pas suivi le projet au quotidien.

Ce socle repose typiquement sur la pile Prometheus + Grafana : les exporteurs dcgm-exporter (métriques GPU NVIDIA) et les métriques natives de vLLM ou du proxy placé devant Ollama alimentent Prometheus, Grafana assure la visualisation et l'alerting peut être délégué à Alertmanager ou à un outil déjà en place dans l'organisation.

- alert: LLMLatencyP95Degraded
  expr: histogram_quantile(0.95, rate(vllm_time_to_first_token_seconds_bucket[5m])) > 2
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "TTFT p95 au-dessus de 2s depuis 10 minutes"
- alert: LLMOOMRecurrent
  expr: increase(vllm_num_requests_oom_total[1h]) > 3
  labels:
    severity: critical

La fenêtre for: 10m évite de déclencher une alerte sur un pic transitoire ; le seuil de 3 OOM par heure distingue l'incident isolé du problème de capacité structurel.

Le coût réel : construire un TCO honnête

La comparaison entre un déploiement local et une API SaaS est souvent biaisée dans un sens ou dans l'autre, selon qui la présente. Un calcul de TCO honnête intègre des postes que les argumentaires commerciaux omettent volontiers.

Ce qu'inclut un TCO complet

Le poste le plus souvent sous-estimé est le temps ingénieur : mise en place initiale, montée de version des moteurs d'inférence, gestion des incidents, ajustement des paramètres de batching. Sur une petite équipe, ce temps peut représenter l'équivalent d'un quart à un mi-temps sur les six premiers mois.

À l'inverse, le poste le plus souvent surestimé côté SaaS est la stabilité tarifaire : les prix par token ont beaucoup baissé ces dernières années, mais rien ne garantit qu'ils continueront de baisser au même rythme, ni que les conditions d'usage (rétention des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, limites de débit) resteront inchangées.

Pour un volume de plusieurs millions de tokens traités par jour, un déploiement local sur GPU dédié (achat ou location longue durée) devient généralement compétitif face à une API SaaS équivalente entre 12 et 24 mois, à condition que le taux d'utilisation du GPU reste élevé. En dessous de ce seuil de volume, le SaaS reste presque toujours plus économique — la sous-utilisation du matériel local est le facteur qui détruit le calcul le plus souvent.

Chargeback : faire porter le coût à qui consomme

Sans mécanisme de refacturation interne, un service d'inférence local est perçu comme gratuit par les équipes utilisatrices, ce qui encourage des usages peu optimisés (prompts surdimensionnés, appels redondants, absence de mise en cache). Le chargeback consiste à répartir le coût réel de l'infrastructure entre les équipes consommatrices, au prorata de leur usage mesuré en tokens.

La mise en œuvre la plus simple repose sur un identifiant d'équipe ou de projet propagé dans chaque requête (en-tête HTTP ou clé API dédiée), agrégé ensuite par une requête Prometheus ou un export périodique vers un tableur de suivi budgétaire. Il n'est pas nécessaire de reproduire la granularité d'une facturation cloud : un rapport mensuel par équipe, avec un coût par token calculé sur l'amortissement du matériel et l'électricité, suffit à responsabiliser les usages sans complexité excessive.

Définir un SLA interne réaliste

Un SLA copié sur les standards d'un fournisseur cloud (99,9 % de disponibilité, latence garantie sous 500 ms) est presque toujours intenable pour une infrastructure locale gérée par une petite équipe, sans redondance multi-site ni astreinte 24/7. Promettre un tel niveau, c'est se garantir de le violer et de perdre la confiance des équipes utilisatrices dès le premier incident.

Un SLA interne réaliste part des contraintes réelles :

1. Fenêtre de service : un service utilisé en heures ouvrées peut assumer une fenêtre de disponibilité garantie de 8h à 20h en semaine, avec une maintenance planifiée hors de cette fenêtre — plutôt qu'un objectif 24/7 non tenable.
2. Disponibilité cible cohérente avec la redondance réelle : sans instance de secours, viser 99 % (environ 7h d'indisponibilité cumulée par mois) est plus honnête que 99,9 %, et laisse une marge pour les mises à jour.
3. Latence par catégorie d'usage, pas un chiffre unique : un TTFT p95 sous 2 secondes pour du chat interactif, un délai de complétion sous 30 secondes pour des tâches de traitement par lots.
4. Procédure de dégradation explicite : que se passe-t-il en cas de saturation — file d'attente avec délai annoncé, bascule vers un modèle plus petit, ou refus temporaire de nouvelles requêtes ? Ce choix doit être décidé à froid, pas improvisé en plein incident.

Annoncer un SLA ambitieux pour rassurer la direction au moment du lancement, sans disposer de l'historique de métriques permettant de savoir si ce niveau est atteignable. Il est préférable de fonctionner plusieurs semaines en observation, de mesurer les percentiles réels de latence et le taux d'incidents, puis de formaliser un SLA aligné sur ces données. Un SLA basé sur des mesures vaut plus qu'un SLA basé sur des intentions.

Boucler la boucle : de la métrique à la décision

L'observabilité n'a de valeur que si elle informe des décisions concrètes. Quelques exemples de boucles de rétroaction utiles à formaliser dès la mise en production :

• File d'attente qui croît en tendance sur plusieurs jours → décision d'ajouter une instance ou d'augmenter max_num_seqs, pas seulement de surveiller.
• Ratio de tokens d'entrée qui augmente sans hausse du nombre de requêtes → investigation côté produit, souvent révélatrice d'un nouvel usage (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 mal optimisé, prompts systèmes trop longs).
• Coût par équipe qui dépasse le budget alloué → conversation avec l'équipe concernée, éventuellement ajustement du modèle utilisé (un modèle plus petit pour les usages non critiques).
• OOM récurrents sur une fenêtre horaire précise → indice d'un usage collectif concentré (script planifié, batch nocturne) à lisser dans le temps plutôt qu'à absorber par plus de matériel.

Ces boucles transforment un tableau de bord passif en outil de pilotage actif, et c'est cette transformation — plus que l'accumulation de métriques — qui distingue une infrastructure LLM opérée sérieusement d'un déploiement laissé à lui-même après sa mise en service.