LLMOps

LLMOps (opérations liées aux grands modèles de langage) désigne l’ensemble des pratiques et outils servant à créer, publier et exécuter en production des applications reposant sur des grands modèles de langage (LLM). Ces pratiques couvrent la gestion des versions des invites et des choix de modèles, l’évaluation du texte généré avant et après publication, le traçage des requêtes à plusieurs étapes au fil de la récupération et des appels d’outils, le contrôle de la latence et du coût des tokens, ainsi que la protection contre des problèmes comme les hallucinations et l’injection d’invite. LLMOps est la branche des opérations d’apprentissage automatique (MLOps) consacrée à ces applications ; le terme s’est largement répandu en 2023, lorsque les entreprises ont transformé leurs prototypes de chatbots en produits. La plupart des équipes adaptent un modèle fondamental hébergé ou à poids ouverts au moyen de l’ingénierie des invites, de la génération augmentée par récupération (RAG) ou du réglage fin, plutôt que d’en entraîner un depuis zéro ; l’essentiel du travail opérationnel passe ainsi des pipelines d’entraînement à tout ce qui entoure le modèle.

Différences entre LLMOps et MLOps#

L’unité de publication dépasse un simple ensemble de poids. Une modification peut toucher le modèle d’invite, le nom et la version du modèle, les paramètres d’échantillonnage, l’index de récupération et les définitions des outils ; chaque élément est versionné, car chacun peut modifier le comportement. Les outils de gestion des invites stockent les modèles avec des numéros de version qu’une application récupère à l’exécution : une modification d’invite peut donc être déployée et annulée sans publier de code. Les modèles hébergés peuvent également changer sous une application ; les équipes épinglent donc les instantanés datés proposés par les fournisseurs et relancent leurs tests avant de changer de version. Le travail sur les données évolue lui aussi : une application RAG versionne les documents, les paramètres de découpage et le modèle d’intégration vectorielle associés à son index de recherche ; changer de modèle d’intégration vectorielle exige de recalculer les représentations de tout le corpus. Les variantes ajustées sont souvent stockées sous forme de petits adaptateurs LoRA, qu’un serveur charge par-dessus un modèle de base partagé.

L’évaluation est plus difficile, car le texte généré a rarement une seule bonne réponse. Les équipes conservent un jeu de données de référence composé d’entrées représentatives accompagnées de réponses de référence ou de grilles d’évaluation, puis notent les sorties à l’aide de vérifications exactes, d’une revue humaine ou de l’évaluation par un LLM arbitre, où un modèle puissant note les réponses. Dans l’article de 2023 Judging LLM-as-a-Judge, Lianmin Zheng et ses collègues ont constaté que GPT-4 concordait avec les préférences humaines plus de 80 % du temps, soit aussi souvent que les humains entre eux. Chaque version candidate passe par la même batterie de tests, et le trafic de production continue d’ajouter des cas :

Les coûts et la latence sont gérés requête par requête. Les modèles hébergés facturent chaque token ; les équipes réduisent donc les dépenses grâce à la mise en cache des invites, à la mise en cache sémantique et au routage des modèles, qui dirige les requêtes simples vers des modèles plus petits. Une approche connexe place un modèle peu coûteux devant un modèle onéreux : le modèle YOLO → VLM Monitor d’Ultralytics Platform Agents exécute d’abord YOLO26 et n’appelle le modèle vision-langage que pour les images dans lesquelles YOLO détecte une personne ; l’utilisation du modèle de langage est facturée sur la clé du fournisseur propre à l’espace de travail. La sécurité est prise en charge en parallèle : les garde-fous d’IA filtrent les entrées et les sorties à chaque requête, et l’équipe rouge recherche des tentatives de contournement avant chaque publication.

Traçage, passerelles et service#

L’observabilité des applications LLM repose sur des traces. Chaque requête devient un arbre de segments couvrant l’invite, chaque appel de modèle, chaque récupération depuis une base de données vectorielle et chaque appel d’outil par un agent d’IA, avec le nombre de tokens, la latence et le coût associés. Les conventions sémantiques pour l’IA générative d’OpenTelemetry normalisent les noms d’attributs des modèles et de l’utilisation des tokens ; des outils comme LangSmith, Langfuse, Arize Phoenix et MLflow Tracing stockent et recherchent les traces. Celles-ci alimentent aussi l’évaluation en ligne : des réponses de production échantillonnées sont notées à l’aide des mêmes juges et grilles que la batterie hors ligne, et le pouce vers le haut ou vers le bas de chaque utilisateur est associé à la trace qui a produit la réponse.

Une passerelle d’IA se place entre les applications et les fournisseurs de modèles pour gérer les clés API et appliquer en un seul endroit les limites de débit, les solutions de repli et les budgets de dépenses. Les équipes qui hébergent des modèles à poids ouverts les exécutent sur des serveurs d’inférence comme vLLM et SGLang, qui utilisent le traitement par lots continu et la mémoire paginée de KV cache pour traiter de nombreuses requêtes simultanées sur chaque GPU.