Surveillance de l'inférence des LLM en production (2026) : Prometheus & Grafana pour vLLM, TGI et llama.cpp

L’inférence LLM ressemble à « une API comme les autres » — jusqu’à ce que les pics de latence apparaissent, les files d’attente s’allongent et que vos GPU atteignent 95 % de mémoire sans explication évidente.

La surveillance devient critique dès que vous dépassez une configuration à nœud unique ou commencez à optimiser le débit. À ce stade, les métriques API traditionnelles ne suffisent pas. Vous avez besoin de visibilité sur les tokens, le comportement du batch, le temps d’attente en file d’attente et la pression sur le cache KV - les véritables goulots d’étranglement des systèmes LLM modernes.

Cet article fait partie de mon guide plus large sur l’observabilité et la surveillance, où je couvre les fondamentaux de la surveillance par rapport à l’observabilité, l’architecture Prometheus et les meilleures pratiques de production. Ici, nous nous concentrerons spécifiquement sur la surveillance des charges d’inférence LLM.

(Si vous devez choisir une infrastructure, consultez mon guide sur l’hébergement LLM en 2026. Si vous souhaitez une analyse approfondie des mécanismes de batch, des limites VRAM et des compromis entre débit et latence, consultez le guide d’ingénierie de performance LLM.)

Contrairement aux services REST typiques, le service LLM est façonné par les tokens, le batching continu, l’utilisation du cache KV, la saturation GPU/CPU et la dynamique des files d’attente. Deux requêtes avec des tailles de charge utiles identiques peuvent avoir des latences radicalement différentes selon max_new_tokens, la concurrency et la réutilisation du cache.

Ce guide est une démonstration pratique axée sur la production pour construire une surveillance d’inférence LLM avec Prometheus et Grafana :

• Ce qu’il faut mesurer (latence p95/p99, tokens/sec, durée de la file d’attente, utilisation du cache, taux d’erreur)
• Comment extraire /metrics des serveurs courants (vLLM, Hugging Face TGI, llama.cpp)
• Exemples PromQL pour les percentiles, la saturation et le débit
• Modèles de déploiement avec Docker Compose et Kubernetes
• Dépannage des problèmes qui n’apparaissent que sous une charge réelle

Les exemples sont délibérément neutres vis-à-vis des fournisseurs. Que vous ajoutiez plus tard un traçage OpenTelemetry, un redimensionnement automatique ou un maillage de services, le même modèle de métriques s’applique.

Pourquoi vous devez surveiller l’inférence LLM différemment

La surveillance API traditionnelle (RPS, latence p95, taux d’erreur) est nécessaire mais insuffisante. Le service LLM ajoute des axes supplémentaires :

1) La latence a deux significations

• Latence E2E : temps de la réception de la requête → au dernier token retourné.
• Latence inter-token : temps par token pendant le décodage (critique pour l’UX en streaming).

Certains serveurs exposent les deux. Par exemple, TGI expose la durée de la requête et le temps moyen par token sous forme d’histogrammes.

2) Le débit est en tokens, pas en requêtes

Un service « rapide » qui retourne 5 tokens n’est pas comparable à un autre qui en retourne 500. Votre « RPS » devrait souvent être « tokens/sec ».

3) La file d’attente est le produit

Si vous utilisez le batching continu, la profondeur de la file d’attente est ce que vous vendez. Surveiller la durée de la file d’attente et la taille de la file d’attente vous indique si vous répondez aux attentes des utilisateurs.

4) La pression du cache est un précurseur de panne

L’épuisement (ou la fragmentation) du cache KV se manifeste souvent par des pics de latence soudains et des dépassements de délai. vLLM expose l’utilisation du cache KV sous forme de jauge.

Checklist de métriques pour la surveillance de l’inférence LLM

Utilisez ceci comme boussole. Vous n’avez pas besoin de tout dès le premier jour, mais vous voudrez probablement la plupart de ces éléments à terme.

Signaux d’or (à la sauce LLM)

• Trafic : requêtes/sec, tokens/sec
• Erreurs : taux d’erreur, timeouts, OOM, 429 (limitation de débit)
• Latence : durée de requête p50/p95/p99 ; latence prefill vs decode ; latence inter-token
• Saturation : utilisation GPU, utilisation mémoire, utilisation cache KV, taille de la file d’attente

Si vous avez besoin d’une visibilité de bas niveau sur l’utilisation de la mémoire GPU, la température et l’utilisation en dehors de Prometheus (pour le débogage ou les configurations à nœud unique), consultez mon guide sur les applications de surveillance GPU sous Linux / Ubuntu.

Pour une vue plus large de l’observabilité LLM au-delà des métriques — incluant le traçage, les logs structurés, les tests synthétiques, le profilage GPU et la conception des SLO — consultez mon guide approfondi sur l’observabilité pour les systèmes LLM.

Dimensions utiles (labels)

Gardez la cardinalité des labels faible. Bons labels :

• model, endpoint, method (prefill/decode), status (success/error), instance

Évitez les labels comme :

• prompt brut, user_id brut, identifiants de requête — ceux-ci explosent le nombre de séries.

Exposition des métriques : points de terminaison /metrics intégrés (vLLM, TGI, llama.cpp)

Le chemin le plus simple est : utilisez les métriques que le serveur expose déjà.

vLLM : /metrics compatible Prometheus

vLLM expose un point de terminaison /metrics compatible Prometheus (via son journal de métriques Prometheus) et publie des métriques serveur/requête avec le préfixe vllm:, incluant des jauges comme les requêtes en cours et l’utilisation du cache KV.

Pour la configuration de conteneur, le service compatible OpenAI et l’optimisation de temps d’exécution orientée débit, consultez Début rapide vLLM : Service LLM haute performance.

Exemples de métriques que vous verrez typiquement :

• vllm:num_requests_running
• vllm:num_requests_waiting
• vllm:kv_cache_usage_perc

Hugging Face TGI : /metrics avec file d’attente + histogrammes de requêtes

TGI expose de nombreuses métriques de niveau production sur /metrics, incluant la taille de la file d’attente, la durée de la requête, la durée de la file d’attente et le temps moyen par token.

Les plus notables :

• tgi_queue_size (jauge)
• tgi_request_duration (histogramme, latence E2E)
• tgi_request_queue_duration (histogramme)
• tgi_request_mean_time_per_token_duration (histogramme)

La configuration opérationnelle — Docker, GPU, drapeaux de lancement et les échecs qui apparaissent comme des extractions vides ou trompeuses — est couverte dans TGI - Text Generation Inference - Installation, Configuration, Dépannage.

Serveur llama.cpp : activer le point de terminaison des métriques

Le serveur llama.cpp prend en charge un point de terminaison de métriques compatible Prometheus qui doit être activé avec un drapeau (par exemple, --metrics).

Pour les chemins d’installation, les drapeaux de temps d’exécution clés et l’utilisation du serveur compatible OpenAI, consultez Début rapide llama.cpp avec CLI et Serveur.

Si vous exécutez llama.cpp derrière un proxy, extrayez le serveur directement autant que possible (pour éviter que la latence au niveau du proxy ne masque le comportement réel d’inférence).

Configuration Prometheus : extraction de vos serveurs d’inférence

Cet exemple suppose :

• vLLM à http://vllm:8000/metrics
• TGI à http://tgi:8080/metrics
• llama.cpp à http://llama:8080/metrics
• intervalle d’extraction ajusté pour un retour rapide

prometheus.yml

global:
  scrape_interval: 5s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "vllm"
    metrics_path: /metrics
    static_configs:
      - targets: ["vllm:8000"]

  - job_name: "tgi"
    metrics_path: /metrics
    static_configs:
      - targets: ["tgi:8080"]

  - job_name: "llama_cpp"
    metrics_path: /metrics
    static_configs:
      - targets: ["llama:8080"]

Si vous débutez avec Prometheus ou souhaitez une explication plus approfondie des configurations d’extraction, des exportateurs, du relabeling et des règles d’alerte, consultez mon guide complet sur la configuration de surveillance Prometheus.

Astuce pro : ajoutez un “label de service”

Si vous exécutez plusieurs modèles/réplicas, ajoutez un relabeling pour inclure un label service stable pour les tableaux de bord.

relabel_configs:
  - target_label: service
    replacement: "llm-inference"

Exemples PromQL que vous pouvez copier/coller

Taux de requêtes (RPS)

sum(rate(tgi_request_count[5m]))

Pour vLLM, utilisez ses compteurs de requêtes (les noms varient selon la version), mais le motif est le même : sum(rate(<compteur>[5m])).

Taux d’erreur (%)

Si vous avez des compteurs *_success, calculez le ratio d’échec :

1 - (
  sum(rate(tgi_request_success[5m]))
  /
  sum(rate(tgi_request_count[5m]))
)

Latence p95 pour les métriques histogramme (Prometheus)

Les histogrammes Prometheus sont des comptes par buckets ; utilisez histogram_quantile() sur rate() des buckets. Prometheus documente ce modèle et les compromis histogramme vs résumé.

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_duration_bucket[5m]))
)

Temps de file d’attente p99

histogram_quantile(
  0.99,
  sum by (le) (rate(tgi_request_queue_duration_bucket[5m]))
)

Temps moyen par token (latence inter-token)

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_mean_time_per_token_duration_bucket[5m]))
)

La latence inter-token est souvent contrainte par les goulots d’étranglement de décodage et la bande passante mémoire - des sujets couverts en détail dans le guide d’optimisation de performance LLM.

Profondeur de file d’attente (instant)

max(tgi_queue_size)

Utilisation du cache KV vLLM (instant)

max(vllm:kv_cache_usage_perc)

Tableaux de bord Grafana : des panneaux qui aident réellement en appel

Grafana peut visualiser les histogrammes de plusieurs manières (percentiles, cartes thermiques, distributions de buckets). Grafana Labs propose un guide détaillé sur la visualisation d’histogrammes Prometheus.

Une mise en page de tableau de bord minimale à fort signal :

Ligne 1 — Expérience utilisateur

1. Latence de requête p95 (série temporelle)
2. Latence inter-token p95 (série temporelle)
3. Taux d’erreur (série temporelle + stat)

Ligne 2 — Capacité et saturation

4. Taille de la file d’attente (série temporelle)
5. Requêtes en cours vs en attente (empilé)
6. Utilisation du cache KV % (jauge)

Ligne 3 — Débit

7. Requêtes/sec
8. Tokens générés/requête (p50/p95)

Si vous avez du streaming, ajoutez un panneau pour la « latence du premier token » (TTFT) lorsque disponible.

Exemples de requêtes Grafana

• Panneau de latence p95 : la requête histogram_quantile(0.95, …) ci-dessus
• Panneau de carte thermique : grapher les taux de buckets (*_bucket) comme une carte thermique (Grafana prend en charge cette approche)

Option de déploiement 1 : Docker Compose (rapide local + nœud unique)

Si vous hésitez entre des architectures d’inférence locales, auto-hébergées ou cloud, consultez l’analyse complète dans mon guide de comparaison d’hébergement LLM.

Créez un dossier comme :

monitoring/
  docker-compose.yml
  prometheus/
    prometheus.yml
  grafana/
    provisioning/
      datasources/datasource.yml
      dashboards/dashboards.yml
    dashboards/
      llm-inference.json

docker-compose.yml

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning
      - ./grafana/dashboards:/var/lib/grafana/dashboards
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

Si vous préférez une installation Grafana manuelle plutôt que Docker, consultez mon guide étape par étape sur l’installation et l’utilisation de Grafana sur Ubuntu.

Provisionnement de source de données Grafana (grafana/provisioning/datasources/datasource.yml)

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

Provisionnement de tableaux de bord (grafana/provisioning/dashboards/dashboards.yml)

apiVersion: 1
providers:
  - name: "LLM"
    folder: "LLM"
    type: file
    disableDeletion: true
    options:
      path: /var/lib/grafana/dashboards

Option de déploiement 2 : Kubernetes (Prometheus Operator + ServiceMonitor)

Si vous utilisez kube-prometheus-stack (Prometheus Operator), extrayez les cibles via ServiceMonitor.

Pour les compromis d’infrastructure entre Kubernetes, Docker à nœud unique et fournisseurs d’inférence gérés, consultez mon guide d’hébergement LLM en 2026.

1) Exposez votre déploiement d’inférence avec un Service

apiVersion: v1
kind: Service
metadata:
  name: tgi
  labels:
    app: tgi
spec:
  selector:
    app: tgi
  ports:
    - name: http
      port: 8080
      targetPort: 8080

2) Créer un ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: tgi
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: tgi
  endpoints:
    - port: http
      path: /metrics
      interval: 5s

Répétez pour les services vLLM et llama.cpp. Cela évolue proprement lorsque vous ajoutez des réplicas.

3) Alerting : règles de style SLO (exemple)

Voici de bonnes alertes de démarrage :

• Latence p95 élevée (taux de consommation)
• Durée de file d’attente p99 trop élevée (utilisateurs en attente)
• Taux d’erreur > 1%
• Utilisation du cache KV > 90% soutenue (cliff de capacité)

Exemple de règle (durée de requête p95) :

- alert: LLMHighP95Latency
  expr: histogram_quantile(0.95, sum by (le) (rate(tgi_request_duration_bucket[5m]))) > 3
  for: 10m
  labels:
    severity: page
  annotations:
    summary: "TGI p95 latency > 3s (10m)"

Dépannage : échecs courants Prometheus + Grafana dans les stacks LLM

1) Cible Prometheus « DOWN »

Symptômes

• UI Prometheus → Cibles affiche DOWN
• « context deadline exceeded » ou connexion refusée

Checklist

• Le serveur expose-t-il réellement /metrics ?
• Mauvais port ? Mauvais schéma (http vs https) ?
• Kubernetes : le Service sélectionne-t-il les pods ? Le label release du ServiceMonitor est-il correct ?

Test rapide

curl -sS http://tgi:8080/metrics | head

2) Vous pouvez extraire les métriques, mais les panneaux sont vides

Causes les plus courantes

• Mauvais nom de métrique (version du serveur changée)
• Le tableau de bord s’attend à _bucket mais vous n’avez qu’une jauge/compteur
• Intervalle d’extraction Prometheus trop long pour des fenêtres courtes (ex. [1m] avec extraction 30s peut être bruité)

Correction

• Utilisez Grafana Explore pour rechercher les préfixes de métriques (ex. tgi_ / vllm:)
• Augmentez la fenêtre de plage de [1m] → [5m]

3) Les percentiles d’histogramme semblent « plats » ou incorrects

Les histogrammes Prometheus nécessitent une agrégation correcte :

• utilisez rate(metric_bucket[5m])
• puis sum by (le) (et optionnellement d’autres labels stables)
• puis histogram_quantile()

Prometheus documente le modèle de buckets et le calcul de quantile côté serveur.
Le guide de visualisation d’histogramme de Grafana inclut des motifs de panneaux pratiques.

4) Explosion de cardinalité (pics de mémoire Prometheus)

Symptômes

• Utilisation RAM de Prometheus augmente
• Erreurs « too many series »

Cause racine typique

• Vous avez ajouté prompt, user_id ou des IDs de requête comme labels dans un exportateur personnalisé.

Correction

• Supprimez les labels à haute cardinalité
• Pré-agrégé en labels à faible cardinalité (model, endpoint, status)
• Envisagez d’utiliser des logs/traçages pour le débogage par requête plutôt que des labels

5) « Nous avons des métriques, mais aucune idée pourquoi c’est lent »

Les métriques sont nécessaires, mais parfois vous avez besoin de corrélation :

• Ajoutez des logs structurés avec les métadonnées de la requête (model, compte de tokens, TTFT)
• Ajoutez du traçage (OpenTelemetry) autour de votre passerelle + serveur d’inférence
• Utilisez des exemplaires (lorsque pris en charge) pour sauter d’un pic de latence à un traçage

Un bon flux de travail : pic sur le tableau de bord Grafana -> cliquez sur Explore -> affinez par instance/model -> vérifiez les logs/traçages pour cette période.

Cela suit le modèle classique métriques -> logs -> traçages décrit dans le guide d’architecture d’observabilité et de surveillance.

6) Quirks de métriques vLLM / multi-processus

Si votre stack de service s’exécute dans plusieurs processus, vous pouvez avoir besoin de la configuration multi-processus de Prometheus (dépend de la façon dont le processus expose les métriques). Les docs vLLM insistent sur l’exposition des métriques via /metrics pour le polling Prometheus ; vérifiez le mode de métriques du serveur lors du déploiement.

Un tableau de bord et un ensemble d’alertes pratiques « jour 1 »

Si vous voulez une configuration légère qui fonctionne toujours en production, commencez par :

Panneaux de tableau de bord

1. Latence de requête p95
2. Temps moyen p95 par token
3. Taille de la file d’attente
4. Durée de file d’attente p95
5. Taux d’erreur
6. Utilisation du cache KV %

Alertes

• Latence de requête p95 > X pendant 10m
• Durée de file d’attente p99 > Y pendant 10m
• Taux d’erreur > 1% pendant 5m
• Utilisation du cache KV > 90% pendant 15m
• Cible Prometheus down (toujours)

Guides d’observabilité connexes

• Guide d’observabilité : Prometheus, Grafana et surveillance de production
• Surveillance Prometheus : Configuration et meilleures pratiques
• Installer et utiliser Grafana sur Ubuntu : Guide complet

Guides d’infrastructure LLM connexes

• Hébergement LLM en 2026 : Comparaison Local, Auto-hébergé et Cloud
• Performance LLM en 2026 : Benchmarks et Optimisation

Notes de conclusion

Prometheus + Grafana vous donne une vue « toujours activée » de la santé de l’inférence. Une fois que vous avez les bases, les prochaines grandes victoires proviennent généralement de :

• SLO par modèle / locataire
• façonnage des requêtes (max tokens, limites de concurrence)
• redimensionnement automatique lié au temps de file d’attente et à la marge du cache KV

Pour une explication plus large de la surveillance par rapport à l’observabilité, des fondamentaux Prometheus et des modèles de production, consultez mon guide d’observabilité complet.