LLMOps : déployer et monitorer des LLM en production

Qu'est-ce que le LLMOps ?

Le LLMOps (Large Language Model Operations) est l'ensemble des pratiques DevOps appliquées au cycle de vie complet des grands modèles de langage : de l'expérimentation et du fine-tuning jusqu'au déploiement, la surveillance continue et l'optimisation en conditions de production. C'est une discipline qui émerge à l'intersection du MLOps traditionnel et des spécificités propres aux LLM — latence non-déterministe, coûts au token, hallucinations, et gestion des prompts comme artefacts versionnés.

Si le MLOps classique s'appuyait sur des métriques bien définies (précision, recall, AUC), les LLM introduisent des métriques subjectives — qualité de la réponse, fidélité, pertinence — qui nécessitent de nouveaux outils d'évaluation. Cette complexité supplémentaire est au cœur du défi LLMOps.

Les défis spécifiques aux LLM en production

Latence variable et imprévisible

Un appel à GPT-4o peut prendre de 300 ms à 30 secondes selon la charge du fournisseur, la longueur du prompt et la longueur de la complétion demandée. Cette variabilité rend difficile la définition de SLOs (Service Level Objectives) stricts. Les solutions incluent le streaming (affichage token par token pour améliorer la perception de la latence), le caching sémantique (réponses mises en cache pour les requêtes similaires), et le timeout avec fallback vers un modèle plus rapide.

Hallucinations et fiabilité

Les modèles de langage peuvent produire des réponses fausses mais formulées avec assurance. En production, cela peut avoir des conséquences graves — fausses informations médicales, données financières incorrectes, bugs dans du code généré. La détection automatique des hallucinations repose sur des techniques comme la vérification croisée (poser la même question différemment), le grounding sur des sources vérifiables via RAG, et l'évaluation par LLM-as-judge (un autre modèle évalue la réponse).

Coûts imprévisibles

Sans rate-limiting et budget caps, les coûts peuvent exploser. Un contexte de 100 000 tokens à $15/M tokens représente $1,50 par requête — multiplié par 10 000 requêtes/jour, on atteint $15 000/jour. La maîtrise des coûts passe par : la compression du contexte, le choix du modèle le moins cher adapté à la tâche, le caching des prompts système répétitifs, et des alertes de coût par service.

Versionnage des prompts

Un prompt est un artefact logiciel à part entière. Un changement de formulation, même mineur, peut modifier radicalement le comportement du modèle. Les prompts doivent être versionnés dans Git, testés (avec des suites d'évaluation), et déployés via des pipelines CI/CD — exactement comme du code applicatif.

Architecture LLMOps de référence

Utilisateur
    │
    ▼
API Gateway (rate-limit, auth, logging)
    │
    ▼
LLM Proxy (liteLLM)  ──▶  Cache sémantique (Redis)
    │
    ├──▶ AWS Bedrock (Claude 3.5 Sonnet)   ← tâches complexes
    ├──▶ OpenAI (GPT-4o mini)              ← tâches simples
    └──▶ Ollama (Llama 3 local)            ← données sensibles
    │
    ▼
Observabilité (LangSmith / Helicone)
    │
    ▼
Alerting (Prometheus → Alertmanager → PagerDuty)

L'élément central de cette architecture est le LLM Proxy. liteLLM, en particulier, implémente une interface compatible OpenAI qui route les requêtes vers n'importe quel provider backend. Cela permet de changer de modèle sans modifier le code applicatif, et d'implémenter une logique de fallback (si Claude est surchargé, basculer sur GPT-4o).

Observabilité : les métriques indispensables

L'observabilité d'un système LLM doit couvrir trois niveaux :

Métriques techniques

• TTFT (Time To First Token) : cible < 500 ms au P95 pour les interfaces conversationnelles
• Latence totale : P50, P95, P99 — à monitorer par modèle et par type de tâche
• Taux d'erreur : erreurs provider (5xx), timeouts, dépassements de context window
• Tokens/seconde : indicateur de débit pour le dimensionnement

Métriques financières

• Coût par requête : input tokens × prix_input + output tokens × prix_output
• Coût par session utilisateur : pour identifier les conversations coûteuses
• Budget burn rate : alerter à 80 % du budget mensuel

Métriques qualité

• Score de pertinence : évaluation automatique par LLM-as-judge sur un échantillon
• Taux de refus : trop élevé = guardrails trop restrictifs ; trop bas = risque de contenu inapproprié
• Taux d'hallucination estimé : via vérification croisée ou grounding score RAG

Gestion des versions et déploiement des prompts

Traitez vos prompts comme du code. Voici notre workflow :

# prompts/deployment-analyzer/v2.3.0.md
---
version: 2.3.0
model: claude-3-5-sonnet
temperature: 0.1
max_tokens: 2048
---
Tu es un expert en déploiements Kubernetes. Analyse le manifest YAML suivant
et identifie les problèmes de sécurité, de performance et de fiabilité.
Format de réponse : JSON structuré avec severity (critical/high/medium/low).

{{manifest}}

# Évaluation automatique avant merge
pytest tests/prompts/test_deployment_analyzer.py
# → 47 cas de test, score moyen 8.4/10 sur le dataset de référence

Fine-tuning vs RAG vs In-context learning

Choisir la bonne technique d'adaptation du modèle est une décision architecturale importante :

• In-context learning : fournir des exemples dans le prompt. Simple, pas de coût d'entraînement, mais limité par la context window et coûteux en tokens.
• RAG (Retrieval-Augmented Generation) : récupérer dynamiquement les informations pertinentes depuis une base vectorielle. Idéal pour les bases de connaissances évolutives, sans risque de mémorisation de données sensibles.
• Fine-tuning : adapter les poids du modèle sur vos données. Donne les meilleures performances sur des tâches très spécifiques, mais coûteux (temps et argent) et nécessite une gouvernance stricte des données d'entraînement.

Notre règle générale : commencez par le RAG. N'envisagez le fine-tuning que si le RAG atteint ses limites après optimisation.

Sécurité et gouvernance

Les LLM introduisent de nouveaux vecteurs d'attaque. Les plus critiques :

• Prompt injection : un utilisateur malveillant injecte des instructions dans son input pour contourner les guardrails. Mitigation : parser et sanitiser les inputs, utiliser des templates de prompt stricts.
• Data leakage : le modèle peut révéler des informations sensibles présentes dans son contexte. Mitigation : ne jamais inclure de données sensibles dans le prompt système, utiliser des guardrails PII.
• Jailbreaking : techniques pour forcer le modèle à ignorer ses instructions de sécurité. Mitigation : guardrails côté applicatif (indépendants du modèle), monitoring des patterns suspects.

Conclusion

Le LLMOps est une discipline qui mûrit rapidement. Les équipes qui investissent dès maintenant dans une infrastructure robuste — observabilité, versionnage des prompts, caching sémantique, guardrails — seront les mieux positionnées pour scaler leurs produits IA de manière fiable et économique. Commencez par l'observabilité : sans elle, vous pilotez à l'aveugle. Puis adressez les coûts, puis la qualité. Le tout orchestré via vos pipelines CI/CD existants — le LLMOps n'est pas une rupture avec le DevOps, c'est son extension naturelle vers les systèmes d'IA.