Observabilité des systèmes LLM : Métriques, traces, logs et tests en production

Les systèmes LLM échouent de manière que le suivi classique des API ne peut pas révéler — les files d’attente se remplissent silencieusement, la mémoire GPU atteint sa capacité bien avant que le CPU ne semble chargé, et la latence explose au niveau du regroupement plutôt qu’au niveau de l’application. Ce guide couvre une stratégie complète d’observabilité pour l’inférence LLM et les applications LLM : ce qu’il faut mesurer, comment l’instrumenter avec Prometheus, OpenTelemetry et Grafana, et comment déployer le pipeline de télémétrie à grande échelle.

TL;DR (Résumé exécutif)

Les systèmes LLM se dégradent de manière que le suivi classique « latence HTTP + taux d’erreur » ne peut pas expliquer. L’observabilité de niveau de production pour les systèmes LLM doit répondre rapidement et de manière défendable :

• Si l’expérience utilisateur se dégrade (latence de queue, temps jusqu’au premier jeton, latence inter-jeton, erreurs et interruptions).
• Où le temps est dépensé (file d’attente vs regroupement vs exécution du modèle ; récupération/outils/filtres de sécurité vs inférence).
• Ce qui sature en premier (utilisation GPU et pression mémoire, pression de la file d’attente/cache KV, tokenisation CPU).
• Comment le coût et la capacité dérivent (tokens par demande, tokens/sec par GPU, taux de hits de cache, générations gaspillées).
• Si la télémétrie est sûre à stocker (les prompts peuvent contenir des données personnelles ; empêcher la fuite de données sensibles dans les journaux/attributs).

La conception la plus résiliente est un pipeline à plusieurs signaux :

• Métriques pour une détection rapide et la planification de la capacité (Prometheus + PromQL ; stockage à long terme optionnel via Thanos/Cortex/Mimir/VictoriaMetrics).
• Traces pour la causalité au niveau de la demande (OpenTelemetry avec OTLP ; backends tels que Tempo/Jaeger/Zipkin/Elastic APM).
• Journaux pour le contexte, corrélés aux traces (Loki/Elastic/OpenSearch), conçus pour les métadonnées à faible cardinalité.
• Profiling pour les points chauds CPU/mémoire et la latence de queue (Grafana Pyroscope).
• Tests synthétiques + tests de charge pour détecter les régressions avant les utilisateurs (Grafana k6 ; sondages de type blackbox).
• SLOs pour mesurer les résultats utilisateur et diriger les alertes actionnables (budget d’erreur ; style de taux de combustion).

Ce qui rend l’observabilité des systèmes LLM différente

Remarque sur la portée : le cadre LLM cible est non spécifié. Les exemples de cet article couvrent des serveurs/stacks courants (Triton, vLLM, TGI, LangChain/LangSmith) et restent applicables à d’autres stacks en substituant des métriques et des spans équivalents.

Les LLM introduisent des comportements opérationnels qui diffèrent des services web conventionnels :

• Travail variable par demande : le nombre de jetons (entrée/sortie) varie largement, donc « demandes par seconde » peuvent sembler stables alors que le débit de jetons s’effondre. TGI et vLLM exportent explicitement des métriques et des latences liées aux jetons pour soutenir ce type de suivi.
• File d’attente + regroupement continu : le débit dépend des disciplines de regroupement/file d’attente ; la taille de la file d’attente et la taille du lot deviennent des indicateurs de premier plan (TGI expose les deux).
• UX de streaming : les utilisateurs s’intéressent au TTFT et à la latence inter-jeton au moins autant qu’au temps de réponse complet ; OpenTelemetry standardise même les métriques serveur TTFT/temps par jeton sous les conventions sémantiques GenAI.
• La pression GPU domine les modes d’échec : l’utilisation GPU et la mémoire GPU (y compris la mémoire utilisée) sont centrales à la fiabilité ; l’exporteur DCGM de NVIDIA existe spécifiquement pour exposer la télémétrie GPU à un point de terminaison Prometheus /metrics.
• Pipelines à plusieurs étapes : la récupération, les appels d’outils, les filtres de sécurité et le post-traitement signifient que la latence bout en bout est une composition de plusieurs spans/files d’attente — rendant le suivi distribué et une conception soigneuse des métriques essentiels.

Des exemples concrets à partir de serveurs d’inférence populaires illustrent cela :

• Serveur d’inférence NVIDIA Triton expose des métriques sous forme de texte brut via /metrics (généralement :8002/metrics) et fournit des drapeaux pour activer/désactiver les métriques et sélectionner un port métrique.
• vLLM expose un point de terminaison Prometheus /metrics étendu avec un préfixe vllm: ; sa documentation inclut des compteurs pour les jetons générés et des histogrammes tels que temps jusqu’au premier jeton.
• TGI de Hugging Face documente un point de terminaison /metrics avec la taille de la file d’attente, la taille du lot, la durée totale de la demande, les jetons générés et la durée de la file d’attente.

Tâches principales d’observabilité et télémétrie LLM requises

L’observabilité des systèmes LLM est la plus facile à mettre en œuvre lorsque vous mappez les tâches → signaux → outils, puis contraindre la cardinalité et le sondage dès le départ.

Métriques : Pour les systèmes de service en ligne, les propres conseils d’instrumentation de Prometheus mettent en avant le nombre de requêtes, les erreurs et la latence comme métriques clés ; les LLM étendent cela avec TTFT, le débit/latence par jeton, la longueur de la file d’attente, la taille du lot et l’utilisation GPU.

Traces : Les traces sont la manière dont vous attribuez la latence et les échecs à travers les étapes de récupération/outils/sécurité/inférence ; OpenTelemetry cadre les traces/exporteurs comme une manière neutre de l’entreprise pour émettre et envoyer la télémétrie vers des collecteurs ou des backends.

Journaux : Les journaux fournissent un contexte lisible par l’homme et « pourquoi », mais ne restent utiles à grande échelle que si vous évitez d’indexer des valeurs non bornées (exemple : Loki indexe uniquement les étiquettes et stocke des morceaux de journaux compressés dans le stockage objet).

Profiling : Le profiling continu capture le comportement CPU/mémoire en production avec un échantillonnage à faible surcharge ; Grafana Pyroscope est explicitement positionné pour cela.

Tests synthétiques et tests de charge : Grafana k6 est un outil open source de test de charge, et Grafana note que le Monitoring Synthétique est alimenté par k6 et dépasse les vérifications de protocole simples.

SLOs : Le guide SRE de Google définit un SLO comme une valeur/étendue cible pour un niveau de service mesuré par un SLI, et fournit des conseils pour alerter sur les SLOs (compromis de précision/rappel/temps de détection).

Plan d’architecture des métriques LLM clés

Conventions sémantiques GenAI d’OpenTelemetry pour la standardisation

OpenTelemetry fournit des conventions sémantiques GenAI (statut : « Développement ») avec un nom standard pour des métriques GenAI telles que :

• gen_ai.client.token.usage et gen_ai.client.operation.duration
• gen_ai.server.request.duration, gen_ai.server.time_per_output_token, et gen_ai.server.time_to_first_token

Cette standardisation est un levier pratique pour des stratégies portables de « surveillance des modèles LLM avec OpenTelemetry » : émettez une seule fois et routez la même télémétrie plus tard vers des backends OSS ou des fournisseurs.

Conception du pipeline de télémétrie

Tirer vs pousser

Prometheus est basé sur le tirage. Les processus exposent des métriques dans un format d’exposition pris en charge, et Prometheus les collecte selon les tâches de collecte configurées.

Pousser est pour les exceptions. Le guide « Quand utiliser le Pushgateway » de Prometheus recommande explicitement le Pushgateway uniquement dans des cas limités (pas comme un remplacement général du pousser), et le README du Pushgateway souligne qu’il ne peut pas « transformer Prometheus en système de surveillance basé sur le pousser ».

Modèle pratique spécifique aux LLM :

• Utilisez le tirage pour les serveurs d’inférence/exporters (points de terminaison de métriques de Triton/vLLM/TGI ; exporteur DCGM ; métriques de nœud).
• Utilisez le pousser OTLP pour les traces/journaux/métriques OTel (le protocole OTLP définit le transport/encodage/délivrance entre les sources, les collecteurs et les backends).
• Utilisez l’écriture distante lors de l’échelle au-delà d’un seul Prometheus (Prometheus fournit des conseils pour l’écriture distante ; Mimir/Thanos/Cortex fournissent des options de stockage à long terme et/ou de haute disponibilité).

Agent vs sidecar vs collecteur de passerelle

OpenTelemetry documente un modèle de déploiement agent, où la télémétrie est envoyée à un collecteur exécuté à côté de l’application ou sur le même hôte (sidecar/DaemonSet), puis exportée.

Pour Kubernetes, l’injection de sidecar est prise en charge via l’Opérateur OpenTelemetry (injection basée sur les annotations).

Règle d’expérience pragmatique pour les stacks LLM :

• Utilisez un agent DaemonSet pour l’enrichissement au niveau de l’hôte et les pipelines partagés à travers de nombreux pods.
• Utilisez un sidecar lorsque vous avez besoin d’isolation stricte par charge de travail ou de filtrage local dédié (fréquent lorsque les prompts peuvent contenir des données sensibles).
• Utilisez un collecteur de passerelle pour le sondage de queue centralisé, le regroupement, les réessais et la distribution d’export.

Échantillonnage et contrôle de la cardinalité

OpenTelemetry clarifie que l’échantillonnage de queue permet des décisions d’échantillonnage basées sur des critères dérivés d’une trace (non possible avec l’échantillonnage de tête seul).

Les conseils d’instrumentation de Prometheus avertissent contre l’utilisation excessive d’étiquettes, fournissent une règle d’expérience pour garder la cardinalité basse et conseillent de réviser les métriques si la cardinalité potentielle dépasse ~100.

Pièges spécifiques aux LLM à bannir tôt :

• Le texte du prompt, le texte de la réponse, les ID de conversation, les ID de demande comme étiquettes/attributs.
• Les blocs d’arguments d’outil comme attributs de span.
• Les étiquettes non bornées « user_id ».

Préférez des dimensions bornées : model, model_family, endpoint, region, status_code, deployment, tenant (uniquement si borné).

Comparaison des outils d’observabilité LLM

Outils mappés aux tâches d’observabilité

Grafana vs alternatives pour la visualisation

• Les tableaux de bord Grafana sont composés de panneaux qui interrogent des sources de données (y compris Loki et Mimir) pour produire des graphiques et des visualisations.
• Kibana fournit des tableaux de bord/visualisations comme couche d’interface utilisateur dans le stack Elastic.
• Les outils de visualisation OpenSearch Dashboards offrent des outils de visualisation pour OpenSearch.
• La documentation d’InfluxData positionne Chronograf comme composant de visualisation dans l’écosystème Influx.

Prometheus vs alternatives pour les backends de métriques

• Stockage local par défaut de Prometheus : si les drapeaux de rétention ne sont pas définis, la rétention par défaut est de 15d (planifiez la rétention/coût tôt).
• Grafana Mimir est décrit comme un stockage à grande échelle, hautement disponible, multi-locataire à long terme pour les métriques Prometheus et OpenTelemetry.
• Thanos est décrit comme une configuration Prometheus hautement disponible avec des capacités de stockage à long terme.
• Cortex décrit lui-même comme une solution de stockage à grande échelle, hautement disponible, multi-locataire pour les métriques Prometheus et OpenTe乐.
• VictoriaMetrics Cloud documente l’intégration de l’écriture distante Prometheus pour le stockage à long terme.
• Le service géré Amazon Prometheus décrit une offre gérée qui s’adapte aux besoins d’ingestion/interrogation et prend en charge PromQL et l’écriture distante.

Recette pratique d’implémentation

Noms et types de métriques à implémenter aujourd’hui

Les conventions sémantiques GenAI d’OpenTelemetry (statut : Développement) définissent des noms de métriques que vous pouvez standardiser immédiatement :

• gen_ai.client.token.usage
• gen_ai.client.operation.duration
• gen_ai.server.request.duration
• gen_ai.server.time_per_output_token
• gen_ai.server.time_to_first_token

Exemples côté serveur que vous pouvez collecter dès maintenant :

• Le point de terminaison Prometheus de vLLM inclut des compteurs (ex. : total de jetons générés) et des histogrammes (TTFT) et documente une stratégie d’étiquette model_name.
• TGI documente des métriques incluant la taille de la file d’attente, la durée de la demande, les jetons générés et la durée moyenne par jeton.
• Triton documente l’exposition /metrics et les commutateurs de métrique.

Exemples PromQL pour les tableaux de bord de latence et de débit LLM

# p95 de latence bout en bout pour un histogramme d'application
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# Taux d'erreur en pourcentage (5xx)
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# Jetons/sec (sortie) à travers tous les modèles
sum(rate(llm_tokens_total{direction="out"}[5m]))

# Taille de file d'attente TGI (jauge)
max(tgi_queue_size) by (instance)

# p95 TTFT vLLM
histogram_quantile(
  0.95,
  sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le, model_name)
)

Les conseils de Prometheus sur les histogrammes expliquent que les quantiles d’histogramme sont calculés côté serveur à partir des buckets en utilisant histogram_quantile().

Notes d’instrumentation OpenTelemetry pour les systèmes LLM

• OTLP est le protocole OpenTelemetry qui spécifie comment la télémétrie est encodée/transmise entre les sources, les collecteurs et les backends.
• La documentation de configuration de l’SDK OpenTelemetry documente des variables d’environnement telles que OTEL_EXPORTER_OTLP_ENDPOINT (et options de protocole) pour exporter la télémétrie.
• La documentation OpenTelemetry Python contrib documente le support d’instrumentation automatique et manuelle pour FastAPI.
• Les conventions sémantiques GenAI incluent un mécanisme d’opt-in de stabilité via OTEL_SEMCONV_STABILITY_OPT_IN pour la migration des conventions GenAI.

Exemple court en Python : métriques + traces + journaux

Le fragment suivant démontre :

• Exposition des métriques Prometheus (/metrics) pour « surveiller l’inférence LLM avec Prometheus »
• Traces exportées via OTLP (neutres par rapport aux fournisseurs)
• Journaux structurés corrélés au contexte de trace, avec une valeur par défaut sécurisée (ne pas journaliser les prompts bruts)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Métriques Prometheus (pull-based)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (OTLP traces)
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

app = FastAPI(title="LLM Inference API", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- Logging (default sécurisé) ---
logger = logging.getLogger("llm")
logging.basicConfig(level=logging.INFO, format="%(message)s")

def trace_id_hex() -> str:
    span = trace.get_current_span()
    ctx = span.get_span_context()
    return format(ctx.trace_id, "032x") if ctx.is_valid else ""

# --- Métriques Prometheus ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "LLM requests total",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "End-to-end LLM request latency (seconds)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Fournisseur de trace OpenTelemetry ---
resource = Resource.create({"service.name": "llm-inference-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # configure via OTEL_EXPORTER_OTLP_* env vars
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "unspecified"
    max_tokens: int = 256

class GenerateResponse(BaseModel):
    model: str
    output: str
    latency_ms: int

@app.post("/v1/generate", response_model=GenerateResponse)
async def generate(req: GenerateRequest, request: Request):
    route = "/v1/generate"
    start = time.perf_counter()

    with tracer.start_as_current_span("llm.generate") as span:
        # Éviter de journaliser le prompt complet ; émettre des métadonnées sécurisées
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Remplacer par l'appel réel LLM (client Triton/vLLM/TGI)
        time.sleep(0.15)
        output = "Hello from the model."

        latency_s = time.perf_counter() - start
        LLM_LATENCY.labels(route=route, model=req.model).observe(latency_s)
        LLM_REQUESTS.labels(route=route, status_code="200", model=req.model).inc()

        logger.info(
            {
                "msg": "llm_request_complete",
                "trace_id": trace_id_hex(),
                "model": req.model,
                "latency_ms": int(latency_s * 1000),
                # Ne pas inclure le prompt/outputs brut sauf si la politique le permet.
            }
        )

        return GenerateResponse(model=req.model, output=output, latency_ms=int(latency_s * 1000))

@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

Déploiement, mise à l’échelle, sécurité et dépannage

Options de déploiement

Mise à l’échelle et rétention : contraintes pratiques

• Stockage local Prometheus : sans drapeaux de taille/temps explicites, la durée de rétention par défaut est de 15d.
• Écriture distante Prometheus : Prometheus documente l’ajustement de l’écriture distante pour dépasser les « valeurs par défaut raisonnables ».
• Grafana Tempo : positionné comme backend de suivi à grande échelle et peut générer des métriques à partir des spans en utilisant le générateur de métriques (écritures distantes vers une source de données Prometheus).
• Stockage Loki : les docs Loki mettent l’accent sur l’indexation uniquement des étiquettes et le stockage de morceaux compressés (stockage objet), rendant la stratégie d’étiquette centrale à l’échelle et au coût.

Sécurité et confidentialité : les prompts peuvent contenir des données personnelles

Les conseils de sécurité d’OpenTelemetry soulignent que la collecte de télémétrie peut accidentellement capturer des informations sensibles/personnelles ; vous êtes responsable de les gérer correctement.

Les modèles de sécurité de Prometheus avertissent que les points de terminaison Prometheus ne devraient pas être exposés à des réseaux publiquement accessibles (comme l’internet) car ils servent des informations sur les systèmes surveillés.

Contrôles opérationnels de confidentialité qui maintiennent « l’observabilité pour les systèmes LLM » en sécurité :

• Par défaut, ne pas journaliser les prompts/réponses bruts ; journaliser le nombre de jetons, le nom du modèle, la latence et les IDs de trace à la place.
• Masquer/supprimer les attributs sensibles dans les collecteurs/pipelines (le filtrage au niveau du collecteur est une approche courante à travers les écosystèmes).
• Appliquer des RBAC et des politiques de rétention pour les journaux/traces ; envisager des scanners de données sensibles là où approprié (ex. : les fournisseurs documentent des scanners pour la télémétrie).

Checklist de dépannage

Si votre tableau de bord Grafana pour la latence LLM semble incorrect, déboguez dans cet ordre :

• Santé de l’ingestion
  • Prometheus : valider le succès de collecte et les sémantiques de configuration (la configuration Prometheus définit les tâches de collecte/instances).
  • OTLP : confirmer la configuration du point de terminaison de l’exporteur (les SDK utilisent OTEL_EXPORTER_OTLP_ENDPOINT, paramètres de protocole).
• Mauvaise correspondance de schéma
  • Le tableau de bord attend model, mais votre serveur émet model_name (vLLM documente explicitement les étiquettes model_name).
• Explosion de cardinalité
  • Quelqu’un a étiqueté par ID de demande/hachage de prompt ; Prometheus avertit que les ensembles d’étiquettes augmentent les coûts RAM/CPU/disk/network et fournit des conseils sur la cardinalité.
• Mauvaise utilisation des histogrammes
  • Assurez-vous de calculer les quantiles à partir des séries _bucket avec rate() et le ; Prometheus explique les compromis de calcul des quantiles d’histogramme.
• Gaps d’échantillonnage des traces
  • Si vous échantillonnez trop agressivement en tête, les traces lentes/erronées rares disparaissent ; l’échantillonnage en queue conserve les « traces importantes » basées sur des critères de trace complets.
• Problèmes de métriques de spans Tempo
  • Si vous utilisez le générateur de métriques et les métriques de spans de Tempo, confirmez qu’il est activé et ajusté (Tempo documente le générateur de métriques et les processeurs de métriques de spans ; le dépannage existe pour les problèmes de générateur).
• Métriques GPU absentes
  • Confirmez que l’exporteur DCGM est déployé et que /metrics est accessible (l’exporteur DCGM expose les métriques GPU via HTTP pour Prometheus).

Liens utiles

• Observabilité : Guide de surveillance, métriques, Prometheus & Grafana
• Surveillance Prometheus : Configuration & Bonnes pratiques
• Performance LLM : Benchmarks, goulets d’étranglement & Optimisation
• Hébergement LLM : Comparaison de l’hébergement local, auto-hébergé et cloud
• Tutoriel pas à pas RAG
• Docs de configuration Prometheus
• Formats d’exposition Prometheus
• Bonnes pratiques d’instrumentation Prometheus
• Nommage des métriques Prometheus
• Histogrammes et résumés Prometheus
• Règles d’alerte Prometheus
• Vue d’ensemble des alertes Prometheus
• Configuration d’Alertmanager
• Modèle JSON des tableaux de bord Grafana
• Provisioning Grafana
• Métriques du serveur d’inférence NVIDIA Triton
• API de métriques TorchServe
• Exporteur DCGM NVIDIA
• Chart Helm kube-prometheus-stack
• Getting started avec Prometheus Operator
• Spécification de l’exporteur Prometheus d’OpenTelemetry
• Guide Prometheus pour recevoir OTLP
• Suivi LangSmith avec OpenTelemetry