Monitoring et observabilité d'un cluster d'inférence LLM local : métriques Prometheus, dashboards Grafana et alertes VRAM

Faire tourner un modèle de langage sur un GPU de test avec un script interactif est à la portée de n’importe quel ingénieur. Maintenir un cluster d’inférence LLM souverain en production 24 heures sur 24, 7 jours sur 7, pour plusieurs centaines de collaborateurs sans interruption de service est un défi d’ingénierie d’une tout autre envergure.

En production, les pannes d’un cluster d’IA ne ressemblent pas aux pannes des serveurs web traditionnels :

• L’asphyxie invisible du KV Cache : La mémoire VRAM ne s’épuise pas brutalement ; le cache de pagination (PagedAttention) se remplit progressivement jusqu’à ce que les nouvelles requêtes soient mises en pause (Request Preemption) ou abandonnées ;
• La dérive silencieuse de la latence : Si la charge concurrente augmente, le temps d’attente du premier token (Time-To-First-Token - TTFT) peut dériver de 300 ms à 12 secondes sans qu’aucune erreur HTTP 500 ne soit levée ;
• L’emballement thermique des cartes GPU : Un ventilateur encrassé ou une température ambiante élevée dans la baie informatique peut déclencher le bridage thermique (Thermal Throttling) des processeurs graphiques, divisant par trois le débit de calcul sans préavis.

Pour garantir un Accord de Niveau de Service (SLA) strict supérieur à 99,9 %, les équipes SRE et DevOps doivent instrumenter leur infrastructure d’IA locale avec les standards de l’observabilité moderne : Prometheus, Grafana et Alertmanager.

Ce guide fournit la configuration complète, les métriques indispensables exposées par le moteur vLLM au sein de Yevi Core v1.0, et les règles d’alerting indispensables pour prévenir les incidents.

flowchart LR
    A[Cluster vLLM / Yevi Core v1.0] -->|Exposition /metrics Port 8000| B[Serveur de Scraping Prometheus]
    C[Nvidia GPU Exporter / DCGM] -->|Métriques Température & VRAM| B
    B --> D[Tableaux de Bord Visuels Grafana]
    B --> E[Moteur d'Alerte Alertmanager]
    E -->|Notification Seuil VRAM > 90% ou TTFT > 4s| F[Slack / PagerDuty / Email DSI]

    style A fill:#10b981,stroke:#047857,color:#fff
    style B fill:#3b82f6,stroke:#1d4ed8,color:#fff
    style D fill:#f59e0b,stroke:#b45309,color:#fff
    style F fill:#f87171,stroke:#b91c1c,color:#fff

---

1. Les 6 métriques indispensables d’un cluster d’inférence vLLM

Le moteur d’inférence de Yevi Core v1.0 (vLLM) expose nativement un endpoint standard Prometheus accessible sur le port HTTP 8000/metrics.

Voici les six métriques critiques à surveiller en priorité absolue :

1. vllm:gpu_cache_usage_factor (Jauge de saturation VRAM)

Indique la fraction de mémoire VRAM allouée au cache de clés/valeurs (KV Cache) actuellement utilisée par les requêtes en cours de génération (valeur comprise entre 0.0 et 1.0).

• Seuil nominal : Entre 0.2 et 0.7 ;
• Seuil d’alerte : Si la valeur dépasse 0.85 (85 %) de manière continue pendant 5 minutes, le serveur est au bord de la saturation de contexte.

2. vllm:num_requests_waiting (Taille de la file d’attente)

Nombre de requêtes utilisateur en attente de calcul dans la file d’attente du planificateur (Scheduler).

• Seuil nominal : 0 (toutes les requêtes sont traitées immédiatement en Continuous Batching) ;
• Seuil critique : Si num_requests_waiting > 5, vos capacités de calcul GPU sont sous-dimensionnées face à l’afflux d’utilisateurs.

3. vllm:time_to_first_token_seconds (Histogramme de latence TTFT)

Temps écoulé avant l’émission du premier token de réponse.

• SLA recommandé : Le 95e percentile ($P_{95}$) doit rester inférieur à 1,5 seconde. Si $P_{95} > 4 \text{ s}$, les utilisateurs ressentent une lenteur anormale.

4. vllm:time_per_output_token_seconds (Vitesse de streaming)

Vitesse de génération des tokens successifs.

• SLA recommandé : Doit correspondre à une vitesse comprise entre 25 et 50 ms par token (soit 20 à 40 tokens/seconde).

5. vllm:num_preemptions_total (Compteur d’évictions forcées)

Nombre de fois où le planificateur a dû suspendre temporairement une requête longue pour libérer de la mémoire VRAM au profit d’une autre.

• Objectif : Zéro éviction en conditions normales. Tout incrément de ce compteur indique que le contexte global est trop vaste pour la mémoire allouée.

6. DCGM_FI_DEV_GPU_TEMP (Température matérielle Nvidia)

Température de jonction des cœurs graphiques remontée par le démon Nvidia Data Center GPU Manager (DCGM).

• Seuil critique : Alerte dès que la température atteint 83 °C pour éviter le bridage thermique (Thermal Throttling).

---

2. Configuration Prometheus de scraping (prometheus.yml)

Pour collecter les métriques du cluster Yevi et des cartes GPU physiques :

global:
  scrape_interval: 5s       # Scraping haute résolution pour capturer les pics d'inférence
  evaluation_interval: 5s

scrape_configs:
  # Scraping des métriques logicielles d'inférence vLLM
  - job_name: 'yevi_vllm_engine'
    static_configs:
      - targets: ['192.168.1.150:8000']
    metrics_path: '/metrics'

  # Scraping des sondes matérielles GPU (Nvidia DCGM Exporter)
  - job_name: 'nvidia_gpu_telemetry'
    static_configs:
      - targets: ['192.168.1.150:9400']

---

3. Règles d’alerting automatiques pour Alertmanager (rules.yml)

Ces règles déclenchent des alertes préventives avant même que les utilisateurs ne constatent une dégradation de service :

groups:
  - name: yevi_llm_production_alerts
    rules:
      # Alerte de saturation imminente de la mémoire VRAM
      - alert: LLM_VRAM_KVCache_Near_Exhaustion
        expr: vllm:gpu_cache_usage_factor > 0.88
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Saturation critique du KV Cache GPU sur l'instance Yevi"
          description: "Le cache VRAM est utilisé à plus de 88 % depuis 2 minutes. Risque d'éviction ou d'erreurs Out-of-Memory."

      # Alerte d'engorgement de la file d'attente
      - alert: LLM_Scheduler_Queue_Backlog
        expr: vllm:num_requests_waiting > 8
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "File d'attente d'inférence en souffrance"
          description: "Plus de 8 requêtes en attente simultanée. Envisager d'activer le load-balancing sur un second GPU."

      # Alerte de dérive de latence TTFT (Expérience utilisateur dégradée)
      - alert: LLM_High_Time_To_First_Token
        expr: histogram_quantile(0.95, sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le)) > 3.5
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "Latence du premier token supérieure au SLA de 3.5s"
          description: "Le P95 TTFT dépasse 3.5 secondes pour les collaborateurs."

      # Alerte de surchauffe matérielle du GPU
      - alert: GPU_Thermal_Throttling_Risk
        expr: DCGM_FI_DEV_GPU_TEMP > 82
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Température GPU anormale dans la baie"
          description: "Le processeur graphique dépasse 82 °C. Vérifier immédiatement la ventilation de la baie informatique."

---

4. Tableau de bord Grafana recommandé (Dashboard Layout)

Un monitoring d’inférence d’entreprise efficace organise ses écrans en quatre zones visuelles :

[ DASHBOARD GRAFANA - YEVI CLUSTER SOUVERAIN ]
┌─────────────────────────────────┬─────────────────────────────────┐
│ 1. Statut Global & Débit        │ 2. Mémoire & Cache KV           │
│ - Requêtes actives : 12         │ - Jauge VRAM KV Cache : 64 %    │
│ - Débit cumulé : 485 tokens/sec │ - Requêtes en attente : 0       │
│ - Total requêtes 24h : 18 420   │ - Évictions (Preemptions) : 0   │
├─────────────────────────────────┼─────────────────────────────────┤
│ 3. Latence & Performance        │ 4. Métriques Matérielles Baie   │
│ - TTFT P50 : 280 ms / P95 : 1.2s│ - Charge GPU : 82 %             │
│ - Vitesse médiane : 36 tok/s    │ - Température : 68 °C           │
│ - Temps de calcul RAG : 45 ms   │ - Puissance consommée : 340 W   │
└─────────────────────────────────┴─────────────────────────────────┘

---

5. Résilience opérationnelle : le redémarrage automatique en conteneur durci

Même avec un monitoring optimal, une défaillance exceptionnelle de pilote CUDA ou un bug de mémoire résiduelle peut survenir.

Yevi Core v1.0 est orchestré sous conteneurs avec une politique de redémarrage automatique et un Healthcheck actif :

# Extrait docker-compose.yml de production
services:
  yevi-engine:
    image: odoun/yevi-core:v1.0-secure
    restart: always
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 10s
      timeout: 3s
      retries: 3
      start_period: 30s
    environment:
      - VLLM_LOGGING_LEVEL=INFO
      - GPU_MEMORY_UTILIZATION=0.90

Si le Healthcheck échoue trois fois consécutivement (ex: blocage d’un thread CUDA), le conteneur est redémarré en moins de 15 secondes sans intervention humaine, et une alerte est transmise à l’équipe d’astreinte MCO (découvrir nos prestations de maintenance).

---

🛠️ Ressources & Documentation SRE

• 🎯 Demander un Audit d’Infrastructure et d’Observabilité GPU (30 min)
• 💻 Accéder aux templates de dashboards Grafana sur GitHub (Licence MIT)
• 📄 Lire notre guide complet d’installation on-premise
• 🧮 Calculer la VRAM et le dimensionnement électrique sur notre Simulateur