2025-05-06 · Mis à jour 2026-07-15

[!NOTE] Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

MLOps vs LLMOps : infrastructure pour les modèles fondamentaux et les systèmes LLM

Les modèles de fondation ont modifié plusieurs hypothèses sous-jacentes aux pratiques classiques de MLOps. Les équipes ont tendance à adapter ou à reprendre un modèle préentraîné au lieu d’entraîner chaque modèle à partir de zéro, tandis que les réponses générées et les actions des outils nécessitent une évaluation allant au-delà d’une simple métrique de prédiction fixe.

La discipline des MLOps reste applicable. Ce qui a changé, c’est l’unité opérationnelle : le comportement d’une application de modèle de langage peut dépendre de prompts, du décodage, de la récupération d’informations, des contrats de outils, des permissions, du routage et des politiques, ainsi que des poids du modèle. Cet article explique ce qui est resté pertinent et quels éléments ont été ajoutés par les systèmes LLM.

En résumé. Préserver la traçabilité MLOps, l’automatisation, la livraison par étapes, la surveillance ainsi que les mécanismes de rollback. Étendre le manifeste de déploiement pour y inclure les fournisseurs ou les poids, prompts, les schémas, l’état de récupération, les outils, le routage et les politiques définies. Valider ce manifeste au moyen d’évaluations progressives, puis utiliser des traces respectueuses de la vie privée afin de transformer les pannes en production en de nouveaux cas de test.

Ce que MLOps a déjà résolu

Les contrôles MLOps qui restent indispensables pour les systèmes de modèles fondamentaux

Les contrôles établis par MLOps ne deviennent pas obsolètes lorsque le modèle génère du texte :

Traçabilité allant des données, du code, de la configuration et du modèle jusqu’à une version finale
Entraînement ou compilation répétables pipelines
Validation hors ligne avant mise en production
Registres et identité immuable des artefacts
Déploiement par étapes, objectifs au niveau du service, mécanismes de réversion et gestion des incidents
Telemétrie des infrastructures et planification de la capacité
Politiques de contrôle d’accès, de conservation et d’audit pour les données

Les modèles de fondation ne suppriment pas ces besoins. Ils rendent l’expression ancienne « version du modèle » insuffisante.

L’unité de déploiement est devenue un manifeste système

L’unité de déploiement élargie, passant des MLOps aux LLMOps

Dans le cas d’un service de prédiction conventionnel, le code, la logique des caractéristiques et l’identité du modèle expliquent souvent la majeure partie des changements de comportement. Pour un système de modèle de base, il convient d’enregistrer au moins :

application code revision
model provider + model/revision + serving configuration
system and task prompts
response schema + decoding parameters
retrieval corpus snapshot + parser + chunker + embedding model + index
tool definitions + implementation revisions + permission policy
routing, fallback, caching, and budget policy
safety and business-rule revisions
evaluation dataset + scorer revisions

La liste exacte dépend du système. L’invariant est qu’un manifeste doit identifier chaque composant pouvant varier de manière indépendante et capable d’altérer le comportement visible par l’utilisateur.

L’alias du modèle d’un fournisseur n’est pas nécessairement un artefact immuable. Un hash checkpoint hébergé localement est plus précis, mais les paramètres de runtime, de quantification, de template ainsi que les configurations de parallélisme doivent néanmoins figurer dans le registre de déploiement.

Cinq surfaces de défaillance élargies

La différence entre MLOps et LLMOps apparaît plus clairement dans l’analyse des pannes que dans les listes d’outils.

1. Modèle et serving

Les modèles hébergés introduisent des aspects liés à la disponibilité du fournisseur, aux quotas, au traitement régional, aux modifications d’alias, ainsi qu’à un modèle économique basé sur le paiement par token. Les modèles auto-hébergés, quant à eux, impliquent des chaînes d’approvisionnement en poids, une capacité GPU, le regroupement des opérations, une politique de mise en cache, la quantification, et des architectures serving distribuées.

Les deux approches nécessitent un contrôle de la latence, des erreurs, du débit, de la saturation ainsi que des coûts. Aucun mode de déploiement ne dispense d’une évaluation de la qualité.

2. Prompt, schéma et orchestration

Un prompt est une configuration de type code, mais le texte pur prompt ne suffit pas à définir le comportement. L’ordre des messages, les descriptions des outils, le schéma de réponse, le décodage, les tentatives de réessai, la troncation ainsi que le code environnant jouent tous un rôle essentiel.

Versionnez la demande assemblée ainsi que la politique d’orchestration. Testez structured outputs à l’aide de parseurs et d’invariants métier, au lieu d’accepter que « JSON » valide comme signe de réussite de la tâche.

3. Récupération et contexte

La récupération d’informations crée un produit de données indépendant entre la source de vérité et le modèle :

RAG chemin des données et de l’évaluation

Le pipeline doit conserver la version de la révision source, les versions du analyseur et du chunker, l’identité embedding, le processus de construction de l’index, les métadonnées de contrôle d’accès ainsi que l’état de suppression. Il est nécessaire d’évaluer la récupération avant la génération : déterminer si le système a trouvé les preuves appropriées, si le filtrage d’autorisation a fonctionné correctement, et si la réponse utilise adéquatement les preuves fournies.

Un index vectoriel ne remplace pas un entrepôt de caractéristiques ou une base de données analytique. Il sert à la recherche de similarité ; les caractéristiques structurées en temps réel ainsi que les faits analytiques conservent des exigences différentes en matière de cohérence et de requêtes.

4. Outils et actions

Lorsqu’un modèle est capable d’appeler APIs, les défaillances de qualité peuvent devenir des effets secondaires. Les limites opérationnelles englobent désormais l’authentification des outils, le principe du moindre privilège, la validation des arguments, les délais d’expiration, l’idempotence, la politique d’approbation ainsi que les vérifications de post-condition.

Traçer quel outil a été proposé, sélectionné, invoqué, rejeté, réessayé et confirmé. Une réponse finale convaincante ne peut pas prouver que le parcours d’action était le bon.

5. Sécurité, protection et politiques

Les filtres de contenu ne constituent qu’un mécanisme de contrôle, et non une couche de protection complète. Les menaces incluent également prompt injection, le récupération entre locataires, la divulgation de secrets, un niveau d’agence excessif, du code de modèle ou de nœud non fiable, ainsi que des arguments d’outil dangereux.

Exprimez autant que possible les règles métier déterministes en dehors du modèle. Définissez les risques résiduels, testez des cas adverses, et désignez une personne responsable pour toute modification de la politique. Le profil génératif AI du NIST constitue un outil utile pour l’inventaire des risques, mais il ne remplace pas un test d’acceptation complet.

L’évaluation devient une porte de sortie pour la mise en production

Une sortie de type libre rend insuffisant un seul chiffre d’exactitude globale. Cela ne signifie pas pour autant que la qualité soit impossible à évaluer.

Construisez une pile d’évaluation comprenant plusieurs types de preuves :

Vérifications déterministes : validité du schéma, présence de citations, outils autorisés, contraintes sur les arguments, règles de politique, latence et budget.
Métriques des composants : rappel de récupération et classement, précision de la sélection d’outils, correction des arguments utilisés par les outils, et sélection des itinéraires.
Tâches bout en bout : entrées représentatives accompagnées de critères de succès explicites et d’étiquettes de segment.
Évaluation basée sur un modèle : jugements guidés par une grille d’évaluation, calibrés à l’aide d’étiquettes d’experts, et soumis à un suivi afin de détecter tout écart de jugement.
Révision humaine : cas ambigus, à fort impact, novateurs ou issus d’un échantillonnage, où l’automatisation n’est pas fiable.
Tests adversariaux : cas d’injection, de dépassement des limites des données, d’abus, de refus, ainsi que d’effets secondaires liés au modèle de menace.

Stockez les résultats par exemple, et non seulement les moyennes. Une nouvelle version peut améliorer la valeur moyenne tout en entraînant une dégradation pour une langue, un tenant, un type de document ou une classe d’action donnée.

La porte de déploiement compare le manifeste candidat avec la version actuelle du même ensemble logiciel versionné. Les seuils doivent prendre en compte simultanément la qualité, la sécurité, la latence et les coûts ; une solution moins chère qui échoue à cette évaluation ne constitue pas une optimisation.

Les traces relient la production à l’évaluation

Boucle opérationnelle traçage-évaluation

Les métriques d’infrastructure permettent de détecter une appel à un modèle lent. Elles ne permettent cependant pas de constater que la récupération a renvoyé un document non autorisé ou qu’une fonction a été appelée avec le compte incorrect.

Capturer une trace sur l’ensemble du chemin de décision :

Corrélation de l’identité du manifeste de déploiement et des requêtes
Appels au modèle et aux fournisseurs, latence, utilisation et état de finition
Requête de récupération, identifiants de documents, scores et décisions de filtrage
Révision du prompt/template sans stocker de manière indiscriminée des contenus sensibles
Offres d’outils, arguments, validations, résultats et identifiants d’effets secondaires
Décisions de politique, tentatives de réessai, solutions de secours et résultat final

Le suivi crée une nouvelle couche de gouvernance des données. Appliquez des mesures de minimisation, de censure, d’isolation par tenant, de chiffrement, d’échantillonnage, de conservation et de révision des accès avant de collecter l’intégralité des prompts ou des documents. Les conventions génératives-AI de OpenTelemetry peuvent favoriser l’interopérabilité, mais leurs schémas évoluent constamment ; il est donc nécessaire de fixer les versions des outils d’instrumentation et des collecteurs.

Le cycle d’amélioration est :

production trace → triaged failure → labeled regression case
                 → candidate change → offline comparison
                 → staged release → monitored outcome

Les retours des utilisateurs peuvent prioriser une investigation, mais un avis positif ne constitue pas une vérité absolue. Il convient de conserver la trace environnante et d’obtenir des étiquettes établies par des experts pour les cas à forte conséquence.

Le passage de contrôle serving constitue une frontière de politique

Passerelle d’inférence en tant que limite de politique et de routage

Un gateway permet de dissocier les clients d’application des fournisseurs ou des moteurs auto-hébergés. Ses responsabilités utiles peuvent inclure :

Authentification, budgets par utilisateur, quotas et limites de débit
Contrats stables pour les requêtes et les réponses
Sélection des routes en fonction des capacités, de la région, de la latence ou de la qualité évaluée
Tentatives limitées, disjoncteurs électriques et sémantique de fallback explicite
Partitionnement du cache et politique de gestion des données sensibles
Attribution de l’utilisation et propagation des manifestes de libération

Le mécanisme de fallback représente un changement de comportement, et non simplement un mécanisme de fiabilité. Lorsqu’un modèle plus petit, un fournisseur alternatif ou une quantité de contexte réduite altèrent la qualité de la tâche, il convient d’évaluer et de tracer ce scénario comme un parcours distinct.

Ne placez pas toutes les décisions d’orchestration dans le gateway. Conservez les règles de domaine près de l’application afin que la responsabilité en soit clairement identifiable.

Fine-tuning représente une seule intervention, et non une échelle de maturité

Sélectionnez l’intervention à appliquer en fonction de la panne observée :

Échec
Facts actuels ou privés manquants	retrait d’informations et synchronisation des sources
Format incorrect ou arguments invalides	schéma, sortie contrainte, validation
Comportement incohérent des tâches	prompt, exemples, sélection du modèle, puis données d’adaptation
Latence ou coût excessifs	route, contexte, cache, agrégation par lots, quantification
Action non autorisée ou dangereuse	permissions d’outil et politique déterministe
Le comportement du domaine ne peut pas être récupéré à partir du contexte.	fine-tuning ou un autre modèle spécialisé

LoRA ainsi que d’autres méthodes à faible consommation en paramètres permettent de réduire le nombre de paramètres entraînables ; elles n’éliminent pas pour autant les exigences relatives à la gouvernance dataset, à la licence du modèle de base, à l’évaluation, à la compatibilité serving, ni aux mécanismes de restauration en cas d’erreur.

Une séquence d’adoption pratique

Définir la tâche utilisateur, les limites de risque, les objectifs du service ainsi que le budget alloué.
Créer le manifeste de déploiement avant d’introduire un registre prompt, une base de données vectorielle ou un produit de passerelle.
Construire un petit ensemble d’évaluation segmenté ainsi que des tests de composants déterministes.
Instrumenter un suivi bout en bout avec des mécanismes de contrôle de la vie privée et des identités stables pour les déploiements.
Mettre en œuvre le déploiement progressivement via des stratégies de type shadow, canary ou avec un trafic limité, en prévoyant un mécanisme de réversion explicite.
Transformer les pannes observées en production en cas de régression et répéter le processus d’évaluation.

N’ajoutez des infrastructures que si elles permettent de gérer un mécanisme de contrôle spécifique ou de résoudre un goulot d’étranglement mesuré. La « plateforme LLMOps » n’est pas une exigence architecturale.

Conclusion

LLMOps correspond à l’application de MLOps à une unité comportementale plus vaste. Le modèle conserve son importance, mais prompts, les preuves récupérées, les permissions des outils, le routage ainsi que les politiques en vigueur peuvent influencer le résultat sans pour autant modifier les poids du modèle.

Versionner l’ensemble de l’unité, l’évaluer avant sa mise en production, la tracer en respectant les contraintes de confidentialité, puis la revenir en arrière en tant que système unique. C’est là la différence opérationnelle qui compte véritablement.