MLOps vs LLMOps : infrastructure pour les foundation models

Viacheslav Dubrov

2025-05-06 · Mis à jour 2026-07-15 · 9 min · Infrastructure IA

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

Lorsqu’une release de foundation model régresse, le fichier de poids peut être inchangé : le prompt, l’index de retrieval, les permissions d’un outil, le routage ou la policy peuvent être les éléments qui ont évolué. Pour les ingénieurs ML, plateforme et applications AI qui opèrent déjà un MLOps conventionnel, l’artefact pratique est donc un manifeste de release qui nomme ces dépendances et indique le premier contrôle à inspecter lorsqu’une défaillance apparaît.

Il s’agit d’un modèle opératoire éditorial, et non de l’affirmation que chaque application a besoin de la même plateforme. Conservez la lineage MLOps, la livraison par étapes, le monitoring et le rollback ; élargissez l’unité que vous versionnez lorsque les réponses générées ou les actions d’outils font dépendre le comportement d’autre chose que des poids.

TL;DR. Conservez la lineage MLOps, l’automatisation, la livraison par étapes, le monitoring et le rollback. Étendez le manifeste de release pour y inclure le provider ou les poids, les prompts, les schémas, l’état du retrieval, les outils, le routage et la policy. Faites progresser ce manifeste au moyen d’évaluations en plusieurs couches, puis utilisez des traces respectueuses de la vie privée pour transformer les défaillances de production en nouveaux tests.

Ce que le MLOps a déjà résolu

Le MLOps a établi des contrôles qui ne deviennent pas obsolètes lorsque le modèle génère du texte :

• lineage des données, du code, de la configuration et du modèle jusqu’à une release
• pipelines d’entraînement ou de build reproductibles
• validation offline avant promotion
• registries et identité immuable des artefacts
• déploiement progressif, objectifs de niveau de service, rollback et réponse aux incidents
• télémétrie de l’infrastructure et planification de capacité
• contrôle des accès, rétention et policy d’audit pour les données

Les foundation models ne suppriment pas ces besoins. Ils rendent simplement l’ancienne expression « version du modèle » trop limitée.

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

Pour un système fondé sur un foundation model, je recommande un manifeste qui consigne au minimum :

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. La règle éditoriale consiste à identifier chaque composant qui évolue indépendamment et qui peut modifier le comportement visible par l’utilisateur.

Considérez le nom d’un modèle fourni par un provider comme susceptible de changer, sauf si le provider documente une révision immuable. Le hash d’un checkpoint aide à identifier des poids auto-hébergés, mais je consignerais également le runtime, la quantization, le template et la configuration du parallélisme.

Cinq surfaces de défaillance élargies

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

1. Modèle et serving

Pour la planification, séparez les sujets liés aux modèles hébergés (disponibilité du provider, quotas, traitement régional et coût d’utilisation) des sujets liés à l’auto-hébergement (disponibilité des poids, capacité GPU, batching, policy de cache, quantization et serving). Les contrôles pertinents dépendent du déploiement choisi.

Dans les deux modes, incluez la latence, les erreurs, le débit, la saturation, le coût et les contrôles de qualité des tâches dans la décision de release.

2. Prompt, schéma et orchestration

Pour un système qui assemble les requêtes au runtime, versionnez la requête assemblée plutôt que le seul texte du prompt : l’ordre des messages, les descriptions des outils, le schéma de réponse, le décodage, les retries, la troncature et le code environnant peuvent chacun modifier le comportement.

Traitez un JSON analysable comme un contrôle de transport, puis testez séparément les invariants métier de la tâche.

3. Retrieval et contexte

Le retrieval ajoute un produit de données indépendant entre la source de vérité et le modèle :

Pour un système augmenté par retrieval, conservez la révision de la source, les versions du parser et du chunker, l’identité de l’embedding, le build de l’index, les métadonnées de contrôle d’accès et l’état des suppressions. La conception originale du RAG sépare le retrieval de la génération ; utilisez cette séparation pour tester indépendamment la récupération des éléments probants, le filtrage des autorisations et l’utilisation de ces éléments. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks décrit l’architecture retrieve-then-generate.

N’utilisez pas un index vectoriel en remplacement d’un feature store ou d’un data warehouse : la recherche par similarité, les features point-in-time et les faits analytiques ont des besoins différents en matière de requêtes et de cohérence.

4. Outils et actions

Lorsqu’un modèle peut appeler des APIs, incluez l’authentification des outils, le principe du moindre privilège, la validation des arguments, les timeouts, l’idempotence, la policy d’approbation et les contrôles de postconditions dans le périmètre opérationnel. Le Generative AI Profile du NIST recense les risques liés au contenu nuisible, à la vie privée et à la sécurité ; les contrôles listés constituent une recommandation d’ingénierie ciblée, et non un catalogue complet de contrôles.

Tracez quel outil a été proposé, sélectionné, appelé, rejeté, rejoué et exécuté. Une réponse finale fluide ne peut pas prouver que le chemin d’action était correct.

5. Safety, sécurité et policy

Les filtres de contenu constituent un contrôle parmi d’autres, et non une couche de guardrails complète. Les menaces comprennent également la prompt injection, le retrieval inter-tenant, la divulgation de secrets, l’excès d’autonomie, l’exécution de code provenant d’un modèle ou d’un nœud non fiable, ainsi que les arguments dangereux transmis aux outils.

Exprimez les règles métier déterministes en dehors du modèle lorsque c’est possible. Définissez les risques résiduels, testez les cas adversariaux et désignez un responsable des changements de policy. Le Generative AI Profile du NIST constitue un inventaire utile des risques, et non un test d’acceptation clé en main.

L’évaluation devient une gate de release

Pour décider d’une release produisant des sorties libres, ne vous appuyez pas sur un unique nombre d’exactitude agrégé. Utilisez plusieurs types d’éléments probants et définissez lequel fait autorité pour chaque mode de défaillance.

Construisez une stack d’évaluation réunissant plusieurs types d’éléments probants :

1. Contrôles déterministes : validité du schéma, présence des citations, outils autorisés, contraintes sur les arguments, règles de policy, latence et budget.
2. Métriques des composants : rappel et classement du retrieval, exactitude de la sélection des outils, correction des arguments des outils et sélection de la route.
3. Tâches end-to-end : entrées représentatives avec des critères de réussite explicites et des labels de slice.
4. Scoring par modèle : évaluations guidées par une rubric, calibrées sur des labels d’experts et surveillées pour détecter la dérive du judge.
5. Revue humaine : cas ambigus, conséquents, nouveaux ou échantillonnés lorsque l’automatisation ne fait pas autorité.
6. Tests adversariaux : injection, frontières de données, abus, refus et effets de bord liés au threat model.

Stockez les résultats par exemple, et pas uniquement les moyennes, afin que la revue de release puisse examiner les régressions par langue, tenant, type de document ou classe d’action.

Pour une gate de déploiement, comparez un manifeste candidat à la release actuelle sur la même suite versionnée. Fixez ensemble les seuils de qualité, de sécurité, de latence et de coût ; une route moins chère qui échoue sur la tâche n’est pas une optimisation.

Les traces relient la production à l’évaluation

Les métriques d’infrastructure peuvent montrer qu’un appel au modèle est lent. Elles ne peuvent pas montrer que le retrieval a renvoyé un document non autorisé ou qu’un outil a été appelé avec le mauvais compte. La documentation du tracing de MLflow décrit des traces qui capturent les étapes intermédiaires et les métadonnées nécessaires à l’inspection de ce chemin.

Capturez une trace couvrant le chemin de décision :

• identité du manifeste de release et corrélation de la requête
• appels au modèle et au provider, latence, usage et état de fin
• requête de retrieval, identifiants des documents, scores et décisions de filtrage
• révision du prompt/template sans stocker de manière indiscriminée du contenu sensible
• propositions d’outils, arguments, approbations, résultats et identifiants des effets de bord
• décisions de policy, retries, fallbacks et résultat final

Le tracing crée une nouvelle surface de gouvernance des données. Appliquez la minimisation, la redaction, l’isolation des tenants, le chiffrement, l’échantillonnage, la rétention et la revue des accès avant de collecter des prompts ou des documents complets. Les conventions sémantiques GenAI d’OpenTelemetry peuvent contribuer à l’interopérabilité, mais elles sont encore en développement. Épinglez la version de la convention ou du schéma, ainsi que les versions de l’instrumentation et du collector.

La boucle d’amélioration est la suivante :

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

Les retours utilisateurs peuvent aider à prioriser les investigations, mais un pouce levé ne constitue pas une ground truth. Préservez la trace environnante et obtenez des labels d’experts pour les cas conséquents.

La serving gateway est une frontière de policy

Une gateway peut découpler les clients applicatifs des providers ou des moteurs auto-hébergés. Parmi les responsabilités qui méritent d’y être placées :

• authentification, budgets par tenant, quotas et rate limits
• contrats stables de requête et de réponse
• sélection de la route selon la capacité, la région, la latence ou la qualité évaluée
• retries bornés, circuit breakers et sémantique explicite des fallbacks
• partitionnement du cache et policy relative aux données sensibles
• attribution de l’usage et propagation du manifeste de release

Un fallback constitue un changement de comportement autant qu’un mécanisme de fiabilité. Si un modèle plus petit, un autre provider ou un contexte réduit modifie la qualité de la tâche, évaluez et tracez cette branche comme une route distincte.

Ne placez pas toutes les décisions d’orchestration dans la gateway. Gardez les règles métier près de l’application et rendez les responsabilités visibles.

Le fine-tuning est une intervention parmi d’autres, pas une échelle de maturité

Choisissez l’intervention à partir de la défaillance observée :

LoRA gèle les poids préentraînés et ajoute des matrices low-rank entraînables, ce qui réduit le nombre de paramètres entraînables pour la tâche downstream. Cette optimisation ne supprime ni la gouvernance des datasets, ni les licences du modèle de base, ni les exigences d’évaluation, de compatibilité du serving ou de rollback.

Une séquence d’adoption pratique

1. Définissez la tâche utilisateur, les limites de préjudice, les objectifs de service et l’enveloppe de coût.
2. Créez le manifeste de release avant d’introduire un produit de prompt registry, de vector database ou de gateway.
3. Constituez un petit jeu d’évaluation découpé en slices et des tests déterministes des composants.
4. Instrumentez une trace end-to-end avec des contrôles de confidentialité et des identités de release stables.
5. Faites progresser la release via du shadow traffic, un canary ou un trafic limité, avec un déclencheur de rollback explicite.
6. Transformez les défaillances de production examinées en cas de régression, puis recommencez.

N’ajoutez de l’infrastructure que lorsqu’elle prend en charge un contrôle nommé ou élimine un bottleneck mesuré. Une « plateforme LLMOps » n’est pas une exigence d’architecture.

Conclusion

Le LLMOps est du MLOps appliqué à une unité comportementale plus large. Le modèle reste important, mais les prompts, les éléments probants récupérés, les permissions des outils, le routage et la policy peuvent modifier le résultat sans changer les poids.

Versionnez l’ensemble de cette unité, évaluez-la avant la release, tracez-la avec des frontières de confidentialité et faites-la revenir en arrière comme un système unique.

Références

• MLflow: évaluation des traces de production - Réutiliser les traces de production pour l’évaluation et scorer les informations intermédiaires des traces.
• MLflow: tracing des LLM et des agents - Capturer les étapes intermédiaires et les métadonnées de tracing pour les investigations.
• Conventions sémantiques GenAI d’OpenTelemetry - Conventions actuellement en développement pour les spans, métriques, événements et données spécifiques aux providers GenAI.
• NIST AI 600-1 : Generative AI Profile - Catégories de risques liées à la prompt injection, à la vie privée, à la sécurité et aux problématiques connexes de l’AI générative.
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks - Architecture originale retrieve-then-generate.
• LoRA: Low-Rank Adaptation of Large Language Models - Poids préentraînés gelés et matrices low-rank entraînables pour l’adaptation downstream.