Observabilité des systèmes LLM : métriques, traces, journaux et tests en production

Les systèmes LLM échouent de manière que la surveillance d’API traditionnelle ne peut pas révéler : les files d’attente se remplissent silencieusement, la mémoire GPU sature bien avant que le CPU ne semble occupé, et la latence explose au niveau de la mise en lot plutôt qu’au niveau de l’application.

Ce guide couvre une stratégie d’observabilité pour l’inférence LLM et les applications LLM : quoi mesurer, comment l’instrumenter avec Prometheus, OpenTelemetry et Grafana, et comment déployer le pipeline de télémétrie à grande échelle.

Les piles d’assistants complètes ajoutent la récupération, les appels d’outils et le routage par-dessus l’inférence brute ; Architecture des assistants IA montre où l’observabilité s’insère parmi ces couches.

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

Les systèmes LLM se dégradent de manière que la surveillance classique « latence HTTP + taux d’erreur » ne peut pas expliquer. Une Observabilité pour les systèmes LLM de qualité production 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 passé (mise en file d’attente vs mise en lot 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 cache KV/file d’attente, tokenisation CPU).
• Comment le coût et la capacité dérivent (jetons par demande, jetons/seconde par GPU, taux de réussite du cache, générations gaspillées).
• Si la télémétrie est sûre à stocker (les invites 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 multi-signaux :

• Métriques pour la détection rapide et la planification de 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 des métadonnées à faible cardinalité.
• Profilage pour les points chauds CPU/mémoire et la latence de queue (Grafana Pyroscope).
• Tests synthétiques et de charge pour détecter les régressions avant les utilisateurs (Grafana k6 ; sondage de type boîte noire).
• SLOs pour mesurer les résultats utilisateur et conduire des alerting actionnables (budgets d’erreur ; style taux de combustion).

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

Note de portée : le framework LLM cible est non spécifié. Les exemples de cet article couvrent les serveurs/frameworks courants (Triton, vLLM, TGI, LangChain/LangSmith) et restent applicables à d’autres piles 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 : les comptes de jetons (entrée/sortie) varient largement, donc « demandes par seconde » peut sembler stable tandis que le débit de jetons s’effondre. TGI et vLLM exportent explicitement la télémétrie liée aux jetons et à la latence des jetons pour soutenir ce style de surveillance.
• Mise en file d’attente + mise en lot continue : le débit dépend des disciplines de mise en lot/file d’attente ; la taille de la file d’attente et la taille du lot deviennent des indicateurs de première classe (TGI expose les deux).
• UX en streaming : les utilisateurs se soucient de TTFT et de la latence inter-jeton au moins autant que du 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 de défaillance : l’utilisation GPU et la mémoire GPU (y compris la mémoire utilisée) sont centrales à la fiabilité ; l’exportateur DCGM de NVIDIA existe spécifiquement pour exposer la télémétrie GPU à un point de terminaison Prometheus /metrics.
• Pipelines multi-é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 traçage distribué et la conception métrique minutieuse essentiels.

Des exemples concrets de serveurs d’inférence populaires soulignent ceci :

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

Tâches d’observabilité de base et télémétrie LLM requise

L’observabilité pour les systèmes LLM est plus facile à implémenter lorsque vous mappez tâches → signaux → outils, puis contraignez la cardinalité et l’échantillonnage dès le premier jour.

Métriques : Pour les systèmes de service en ligne, les propres guides 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, débit/latence par jeton, longueur de file d’attente, taille de lot et utilisation GPU.

Traces : Les traces sont le moyen d’attribuer la latence et les échecs à travers les étapes de récupération/outils/sécurité/inférence ; OpenTelemetry cadre les traces/exportateurs comme un moyen neutre en termes de fournisseur d’émettre et d’envoyer la télémétrie aux collecteurs ou backends.

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

Profilage : Le profilage 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 de test de charge open-source, et Grafana note que la Surveillance Synthétique est alimentée par k6 et s’étend au-delà des simples vérifications de protocole.

SLOs : Les guides SRE de Google définissent un SLO comme une valeur/plage cible pour un niveau de service mesuré par un SLI, et fournissent des conseils pour l’alerting sur les SLOs (compromis précision/rappel/temps de détection).

Schéma des métriques LLM clés

Conventions sémantiques OpenTelemetry GenAI pour la standardisation

OpenTelemetry fournit des conventions sémantiques GenAI (statut : « Développement ») avec un nommage standard pour les 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 « surveillance des modèles LLM avec OpenTelemetry » portables : émettre une fois et router la même télémétrie vers des backends OSS ou vendeurs plus tard.

Conception du pipeline de télémétrie

Pull vs push

Prometheus est pull-first. Les processus exposent des métriques dans un format d’exposition pris en charge, et Prometheus les ramasse selon les tâches de ramassage configurées.

Push 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 push), et le README du Pushgateway souligne qu’il ne peut pas « transformer Prometheus en un système de surveillance basé sur le push ».

Motif pratique spécifique aux LLM :

• Utilisez pull pour les serveurs d’inférence/exportateurs (points de terminaison de métriques Triton/vLLM/TGI ; exportateur DCGM ; métriques nœud).
• Utilisez push OTLP pour les traces/journaux/métriques OTel (le Protocole OpenTelemetry définit le transport/encodage/livraison entre les sources, collecteurs et backends).
• Utilisez l’écriture distante lors de la mise à l’échelle au-delà d’un seul Prometheus (Prometheus fournit des conseils de réglage pour l’écriture distante ; Mimir/Thanos/Cortex fournissent des options de stockage à long terme et/ou HA).

Collecteurs Agent vs sidecar vs gateway

OpenTelemetry documente un motif de déploiement d’agent, où la télémétrie est envoyée à un Collecteur fonctionnant aux côtés 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 de bon sens pragmatique pour les piles LLM :

• Utilisez un agent DaemonSet pour l’enrichissement au niveau de l’hôte et les pipelines partagés entre de nombreux pods.
• Utilisez un sidecar lorsque vous avez besoin d’une isolation stricte par charge de travail ou d’un filtrage local dédié (courant lorsque les invites peuvent contenir des données sensibles).
• Utilisez un collecteur gateway pour l’échantillonnage de queue centralisé, la mise en lot, les tentatives et la diffusion d’exportation.

Échantillonnage et contrôle de la cardinalité

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

Les conseils d’instrumentation de Prometheus mettent en garde contre la surutilisation des étiquettes, fournissent une règle de bon sens pour maintenir une faible cardinalité, et conseillent de repenser les métriques si la cardinalité potentielle dépasse ~100.

« Pièges de cardinalité » spécifiques aux LLM à bannir tôt :

• Texte d’invite, texte de réponse, ID de conversation, ID de demande comme étiquettes/attributs.
• Bolo d’arguments d’outils comme attributs de span.
• Étiquettes « user_id » non bornées.

Privilégiez 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 UI au sein d’Elastic Stack.
• OpenSearch Dashboards fournit des outils de visualisation de données pour OpenSearch.
• La documentation d’InfluxData positionne Chronograf comme le composant de visualisation au sein de l’écosystème Influx.

Prometheus vs alternatives pour les backends de métriques

• Stockage local Prometheus par défaut : si les drapeaux de rétention ne sont pas définis, la rétention est par défaut à 15d (planifiez la rétention/coût tôt).
• Grafana Mimir est décrit comme un stockage à long terme multi-locataire HA scalable horizontalement pour les métriques Prometheus et OpenTelemetry.
• Thanos est décrit comme une configuration Prometheus haute disponibilité avec capacités de stockage à long terme.
• Cortex se décrit comme une solution de stockage à long terme multi-locataire HA scalable horizontalement pour les métriques Prometheus et OpenTelemetry.
• VictoriaMetrics Cloud documente l’intégration d’écriture distante Prometheus pour le stockage à long terme.
• Amazon Managed Service for Prometheus décrit une offre gérée qui évolue avec les besoins d’ingestion/requête et prend en charge PromQL et l’écriture distante.

Livre de recettes d’implémentation pratique

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

Les conventions sémantiques OpenTelemetry GenAI (statut : Développement) définissent des noms de métriques sur lesquels vous pouvez vous 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 ramasser dès maintenant :

• Le point de terminaison Prometheus de vLLM inclut des compteurs (ex. total des jetons de génération) 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 le temps moyen par jeton.
• Triton documente l’exposition /metrics et les bascules de métriques.

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

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

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

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

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

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

Les conseils d’histogramme de Prometheus 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 spécifiant comment la télémétrie est encodée/transmise entre les sources, collecteurs et backends.
• La documentation de configuration du SDK OpenTelemetry documente les variables d’environnement telles que OTEL_EXPORTER_OTLP_ENDPOINT (et options de protocole) pour l’exportation de la télémétrie.
• OpenTelemetry Python contrib documente le support d’instrumentation FastAPI pour l’instrumentation automatique et manuelle.
• Les conventions sémantiques GenAI incluent un mécanisme de stabilité opt-in via OTEL_SEMCONV_STABILITY_OPT_IN pour la migration des conventions GenAI.

Exemple Python court : métriques + traces + journaux

Le fragment ci-dessous démontre :

• Exposition des métriques Prometheus (/metrics) pour « surveillance de l’inférence LLM avec Prometheus »
• Traces OpenTelemetry exportées via OTLP (neutre en termes de fournisseur)
• Journaux structurés corrélés au contexte de trace, avec une valeur par défaut sûre pour la vie privée (ne pas journaliser les invites brutes)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (métriques basées sur le pull)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (traces OTLP)
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="API d'Inférence LLM", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- Journalisation (valeur par défaut sûre pour la vie privée) ---
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",
    "Total des demandes LLM",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "Latence bout-en-bout de la demande LLM (secondes)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Fournisseur de traceur 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())  # configurez via les variables d'environnement OTEL_EXPORTER_OTLP_*
)
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:
        # Évitez de journaliser l'invite complète ; émettez des métadonnées sûres
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Remplacez par l'appel LLM réel (client Triton/vLLM/TGI)
        time.sleep(0.15)
        output = "Bonjour du modèle."

        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),
                # N'incluez PAS l'invite/sortie brute sauf si la politique l'autorise.
            }
        )

        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, le temps de rétention est par défaut à 15j.
• Écriture distante Prometheus : Prometheus documente le réglage de l’écriture distante pour la mise à l’échelle au-delà des « valeurs par défaut saines ».
• Grafana Tempo : positionné comme un backend de traçage à grande échelle et peut générer des métriques à partir de spans en utilisant le générateur de métriques (écritures distantes vers une source de données Prometheus).
• Stockage Loki : la documentation de Loki met l’accent sur l’indexation des étiquettes uniquement et le stockage de blocs compressés (stockage d’objets), rendant la stratégie d’étiquettes centrale pour l’échelle et le coût.

Sécurité et vie privée : les invites peuvent contenir des données personnelles

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

Le modèle de sécurité de Prometheus met en garde que les points de terminaison Prometheus ne doivent pas être exposés à des réseaux accessibles au public (comme 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 » sûre :

• Par défaut, ne journalisez pas les invites/réponses brutes ; journalisez les comptes de jetons, le nom du modèle, la latence et les ID de trace à la place.
• Anonymisez/supprimez les attributs sensibles dans les collecteurs/pipelines (le filtrage au niveau du collecteur est une approche courante dans les écosystèmes).
• Appliquez RBAC et des politiques de rétention pour les journaux/traces ; envisagez des scanners de données sensibles si approprié (ex. les vendeurs documentent des scanners pour la télémétrie).

Liste de contrôle de dépannage

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

• Santé de l’ingestion
  • Prometheus : validez le succès du ramassage et la sémantique de configuration (la configuration Prometheus définit les tâches/instances de ramassage).
  • OTLP : confirmez la configuration du point de terminaison de l’exportateur (les SDKs utilisent OTEL_EXPORTER_OTLP_ENDPOINT, paramètres de protocole).
• Incompatibilité de schéma
  • Le tableau de bord s’attend à model, mais votre serveur émet model_name (vLLM documente explicitement les étiquettes model_name).
• Explosion de la cardinalité
  • Quelqu’un a étiqueté par ID de demande/hachages d’invite ; Prometheus met en garde que les ensembles d’étiquettes augmentent les coûts RAM/CPU/disque/réseau et fournit des conseils de 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.
• Lacunes d’échantillonnage de trace
  • Si vous échantillonnez la tête trop agressivement, les traces lentes/erreur rares disparaissent ; l’échantillonnage de queue conserve les traces « importantes » basées sur des critères de trace complets.
• Problèmes de métriques de span Tempo
  • Si vous utilisez le générateur de métriques Tempo et les métriques de span, confirmez qu’il est activé et réglé (Tempo documente les processeurs générateur de métriques et métriques de span ; le dépannage existe pour les problèmes de générateur).
• Métriques GPU absentes
  • Confirmez que l’exportateur DCGM est déployé et que /metrics est accessible (l’exportateur DCGM expose les métriques GPU sur HTTP pour Prometheus).

Liens utiles

• Agents de sondage dans les assistants IA : 11 modèles d’implémentation — la section liste de contrôle d’observabilité couvre exactement quelles métriques d’agent en arrière-plan, champs de journal et vues administrateur instrumenter pour les systèmes de sondage de production
• Observabilité : Guide de surveillance, métriques, Prometheus & Grafana
• A2A vs MCP : Les agents IA ont-ils vraiment besoin des deux protocoles ? — les sections observabilité et sécurité couvrent ce qu’il faut tracer dans les systèmes multi-agents qui combinent les deux protocoles
• Modèles d’orchestration multi-agents — la section observabilité couvre les exigences de traçage distribué spécifiques à chaque modèle : lecture du tableau blanc pour l’essaim, attribution des coûts par agent et surveillance de la convergence pour le maillage
• Protocole A2A de Google en 2026 : Adoption, Hype et Réalité — les sections sécurité et erreurs courantes couvrent exactement l’observabilité dont vous avez besoin lors du déploiement d’agents au-delà des limites A2A
• Qu’est-ce que le protocole A2A ? Cartes d’agent et tâches expliquées — la section observabilité explique ce qu’une trace de tâche inter-agent doit capturer : changements d’état de tâche, chaînes de délégation, artefacts et messages agent-à-agent
• Surveillance Prometheus : Configuration & Meilleures Pratiques
• Performance LLM : Benchmarks, Goulots d’étranglement & Optimisation
• Hébergement LLM : Local, Auto-hébergé & Infrastructure Cloud Comparés
• Tutoriel étape par étape RAG
• Docs de configuration Prometheus
• Formats d’exposition Prometheus
• Meilleures pratiques d’instrumentation Prometheus
• Nomination des métriques Prometheus
• Histogrammes et résumés Prometheus
• Règles d’alerting Prometheus
• Aperçu de l’alerting Prometheus
• Configuration Alertmanager
• Modèle JSON de tableau de bord Grafana
• Provisionnement Grafana
• Métriques NVIDIA Triton Inference Server
• API de métriques TorchServe
• Exportateur NVIDIA DCGM
• Charte Helm kube-prometheus-stack
• Opérateur Prometheus prise en main
• Spécification de l’exportateur Prometheus OpenTelemetry
• Guide Prometheus pour la réception OTLP
• Traçage LangSmith avec OpenTelemetry