monitoring LLM en production SaaS : guide technique pour CTO et lead dev

monitoring LLM en production SaaS : pourquoi c'est différent (et critique)

Déployer un modèle de langage (LLM) en production dans un SaaS, ce n'est pas seulement appeler une API. Il faut mesurer latence, coût, qualité des réponses, disponibilité, et surveiller les dérives (drift) ou les fuites de données. Ce guide technique explique comment architecturer un observability stack pour LLMs, quels métriques instrumenter, exemples concrets (Node.js / Python), règles d'alerte et bonnes pratiques pour CTO et lead dev.

Pour qui et résultat attendu

Persona : CTO / lead dev d'un SaaS qui expose des fonctionnalités alimentées par LLM (assistant, génération de texte, résumé, RAG). À la fin vous saurez : quelles métriques collecter, comment les exposer (Prometheus / OpenTelemetry), comment tracer les appels invocations + vector DB, construire des alertes SLO et suivre le coût par tenant.

1. architecture d'observabilité recommandée

Un stack minimal et robuste :

• Instrumentation applicative avec OpenTelemetry pour traces et métriques. (opentelemetry.io)
• Export métriques -> Prometheus ; visualisation -> Grafana. (prometheus.io, grafana.com)
• Logs structurés (JSON) centralisés (Elasticsearch / Loki / Cloud logging).
• Stockage des méta-métriques par tenant (ex: DB timeseries ou labels Prometheus + labels de coût).
• Instrumentation des composants RAG : vector DB (faiss/pgvector/annoy), retriever, prompt building, appel du LLM.

Pourquoi OpenTelemetry ?

OpenTelemetry permet traces distribués et métriques standardisées — utile quand vos appels traversent front, back, vector DB et service LLM.

2. quelles métriques instrumenter (liste priorisée)

1. latency_inference_ms : latence totale d'une requête utilisateur (100p, medianes, p95, p99).
2. latency_retrieval_ms : temps de recherche vectorielle/BDR.
3. tokens_sent et tokens_received par requête → pour coût. (token_count * tarif modèle).
4. inference_error_count et catégories d'erreur (timeout, 5xx, rate_limit).
5. requests_per_tenant avec labels tenant_id, plan (free/pro/enterprise).
6. cache_hit_ratio pour réponses mises en cache (important pour coûts et latence).
7. model_version_requests : trafic par version de modèle pour A/B et rollback.
8. retrieval_precision / retrieval_recall : métrique RAG pour mesurer qualité de la recherche vectorielle (ex.: taux de documents pertinents dans top-k).

3. exemple d'instrumentation rapide (Node.js + prom-client)

Exemple minimal pour exposer métriques Prometheus dans une app Express :

const express = require('express');
const client = require('prom-client');

const app = express();
const collectDefault = client.collectDefaultMetrics;
collectDefault({ prefix: 'my_saas_' });

const latency = new client.Histogram({
  name: 'llm_inference_latency_ms',
  help: 'Latency of LLM inference in ms',
  buckets: [50,100,200,500,1000,2000]
});
const tokenCounter = new client.Counter({
  name: 'llm_tokens_total',
  help: 'Tokens consumed per request',
  labelNames: ['tenant']
});

app.post('/api/assistant', async (req, res) => {
  const start = Date.now();
  const tenant = req.headers['x-tenant-id'] || 'unknown';
  try {
    // build prompt + call LLM
    const response = await callLLM(req.body.prompt);
    const duration = Date.now() - start;
    latency.observe(duration);
    tokenCounter.inc({ tenant }, response.usage.total_tokens);
    res.json(response);
  } catch (err) {
    // increment error metric (omitted)
    res.status(500).send('error');
  }
});

app.get('/metrics', async (req, res) => {
  res.set('Content-Type', client.register.contentType);
  res.end(await client.register.metrics());
});

app.listen(3000);

Points pratiques :

• Ajouter labels tenant_id et model_version pour segmentation.
• Ne pas exposer tenant_id en clair dans logs publics ; utilisez un identifiant interne.

4. traces distribuées (OpenTelemetry + exemple)

Tracez l’appel complet : frontend → API → retriever → vector DB → LLM provider. Exemple de spans : "http:receive", "prompt.build", "vector.search", "llm.request", "llm.deserialize". Avec OpenTelemetry vous obtiendrez timing et attributs (tokens, tenant_id, model).

Pour démarrer : suivez la doc OpenTelemetry pour Node.js / Python et exportez vers Jaeger ou Tempo. (documentation OpenTelemetry)

5. alerting et SLOs

Définissez SLOs simples et alertes Prometheus :

• SLO latence : p95 < 800 ms pour endpoints critiques.
• SLO disponibilité : taux d'erreur < 0.5% sur 30 jours.
• Alerte coût : explosion du coût tokens > threshold sur 24h pour un tenant (protéger contre usage frauduleux).

Exemple d'alerte Prometheus (simplifié) :

groups:
- name: llm.rules
  rules:
  - alert: HighInferenceLatency
    expr: histogram_quantile(0.95, sum(rate(llm_inference_latency_ms_bucket[5m])) by (le)) > 0.8
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "p95 latency > 800ms"

6. monitoring du coût par tenant (pratique)

Stratégie :

1. Collecter tokens_sent/received + model_version par requête.
2. Stocker séries temporelles agrégées par tenant (Prometheus labels ou DB dédiée si cardinalité élevée).
3. Calculer coût = tokens * tarif du modèle (récupéré depuis la facturation du provider ou configuré en interne).
4. Mettre en place alertes budget (ex: 80% du quota mensuel). Pour haute cardinalité, servez-vous d'un pipeline de batch (Kafka → ClickHouse) plutôt que Prometheus.

7. spécificités RAG et vectordb

Métriques additionnelles pour RAG :

• time_to_topk : latence de recherche vectorielle.
• topk_similarity_distribution : qualité des similarités (pour détecter dérive du vectordb).
• retrieval_fallback_rate : pourcentage de requêtes sans résultat pertinent (déclenche entrée en processus de réindex).

8. erreurs fréquentes et tips

• Erreur : labels de haute cardinalité (tenant_id trop fin) saturent Prometheus. Astuce : regrouper par plan ou shard tenant, ou exporter uniquement agrégats par minute.
• Erreur : logs contenant prompt complet → risque fuite de données sensibles. Redigez un policy de masquage et n'envoyez que hashes ou extraits.
• Tip perf : batcher les appels LLM quand possible, ou utiliser cache TTL pour prompts identiques.
• Tip coût : implémentez un pré-filtre côté produit pour éviter appels inutiles (ex: règles métier, heuristiques).

9. gouvernance, rétention et conformité

Conservez traces et logs selon vos obligations RGPD et politiques internes. Pour données sensibles : anonymisation ou suppression après délai. Documentez qui peut accéder aux métriques contenant tenant_id et tokens.

10. next steps opérationnels (checklist rapide)

1. Instrumenter métriques clés + labels (tenant, model_version).
2. Ajouter traces distribuées OpenTelemetry.
3. Déployer Prometheus + Grafana ou exporter vers votre observability cloud.
4. Créer dashboards : p95 latency, cost per tenant, error rate, retrieval precision.
5. Définir SLOs et règles d'alerte opérationnelles.
6. Plan de réponse : throttling, quota, circuit breaker sur provider LLM.

Ressources utiles

• OpenTelemetry : opentelemetry.io.
• Prometheus : prometheus.io.
• Grafana : grafana.com.

Exemples et aides Novane

Pour accompagner la mise en place (audit d'architecture, instrumentation, dashboards, déploiement sécurisé), voyez nos services dédiés : services IA, services SaaS et nos réalisations pour s'inspirer réalisations.

Conclusion

Le monitoring des LLM en production combine observabilité classique et mesures spécifiques (tokens, qualité de retrieval, coûts par tenant). Avec une instrumentation cohérente (OpenTelemetry), stockage adapté (Prometheus / timeseries) et règles d'alerte claires, vous maîtrisez latence, coût et qualité — indispensables pour scaler un SaaS fiable et rentable.

Besoin d'un audit ou d'un prototype d'observabilité pour vos LLMs ? Contactez-nous pour une séance de consulting.