MLOps vs LLMOps : qu'est-ce qui change lorsque le modèle est un LLM

MLOps est la discipline d'ingénierie permettant de développer, déployer, versionner et exploiter de manière fiable des systèmes d'apprentissage automatique ; LLMOps étend cette discipline aux applications construites autour de grands modèles de langage, où le comportement en production dépend non seulement d'un artefact de modèle mais aussi des prompts, du contexte, de la récupération, des versions de fournisseur/modèle, des appels d'outils, des contrôles de sécurité et des pipelines d'évaluation. LLMOps ne remplace pas MLOps. Il fait passer l'unité opérationnelle de « un modèle plus un pipeline de service » vers « une application LLM en évolution dont le comportement émerge de plusieurs composants évoluant indépendamment ».

Ce que MLOps signifie réellement

MLOps applique la discipline du génie logiciel et de l'exploitation aux systèmes d'apprentissage automatique. Le défi de la production est plus large que l'entraînement d'un modèle : la collecte de données, la validation des données, l'expérimentation, la reproductibilité, l'évaluation des modèles, le déploiement, l'infrastructure et la surveillance doivent tous fonctionner ensemble.

Les recommandations d'architecture MLOps de Google structurent la discipline autour de l'intégration continue, de la livraison continue et de l'entraînement continu. L'IC valide non seulement le code mais aussi les données, les schémas et les modèles ; la LC déploie les pipelines ML et les services de prédiction ; l'EC peut réentraîner et redéployer les modèles lorsque les données ou les implémentations changent.

Les recommandations AWS ajoutent les mêmes préoccupations opérationnelles sous un autre angle : la traçabilité des modèles, la traçabilité modèle/version, la surveillance de la dérive et la surveillance de la qualité en production sont des éléments essentiels pour maintenir la fiabilité des systèmes ML après le déploiement.

Ce qui change lorsque le modèle est un LLM

Les grands modèles de langage modifient le problème de production car l'application ne possède souvent pas l'intégralité du cycle de vie d'entraînement du modèle. Une équipe peut appeler une API de modèle hébergé, exécuter un modèle ouvert localement, basculer entre fournisseurs ou utiliser plusieurs modèles pour différentes tâches.

Le modèle n'est donc qu'une seule dépendance versionnée au sein d'un système comportemental plus vaste. Les prompts, les résultats de récupération, l'ordre du contexte, les outils, l'instantané du modèle, les paramètres de température/raisonnement, les filtres de sécurité et l'orchestration d'exécution peuvent tous modifier la sortie.

Cela crée une question opérationnelle plus large : quelle combinaison de modèle, contexte, données, prompt, outils et environnement d'exécution a produit ce comportement ? LLMOps existe pour rendre cette question répondable et la réponse suffisamment reproductible pour le travail d'ingénierie.

L'exemple le plus simple

Supposons qu'une application réponde à des questions de politique interne.

Dans un cadre ML classique, vous pourriez versionner un classifieur entraîné, le déployer et surveiller la qualité des prédictions. Dans une application LLM, la réponse peut dépendre d'un instantané de modèle hébergé, d'un prompt système, d'un modèle d'embedding, d'un index vectoriel, de filtres de récupération, d'un reranker et du contexte final sélectionné.

Modifier l'un de ces composants peut changer la réponse finale même si le point de terminaison de l'application et la question de l'utilisateur restent identiques.

Où l'exemple simple s'arrête

Certains systèmes LLM entraînent ou affinent encore leurs propres modèles, de sorte que les pratiques MLOps traditionnelles telles que les pipelines d'entraînement, le registre de modèles et la traçabilité des données restent directement pertinentes.

D'autres systèmes utilisent uniquement des API de modèles de fondation externes et n'exécutent jamais d'entraînement continu. Leur principale charge de travail opérationnelle est l'évaluation des applications, la gestion des changements de modèle/fournisseur, la gestion des versions de prompt/contexte, la qualité de récupération et l'observabilité.

Il n'existe donc pas de « pipeline LLMOps » universel unique. Le cycle de vie exact dépend de si vous entraînez, affinez, hébergez vous-même, récupérez des connaissances externes, exécutez des agents ou dépendez d'API de modèles gérées.

MLOps vs LLMOps

LLMOps étend MLOps plutôt que de le remplacer

Les principes opérationnels fondamentaux ne disparaissent pas : le contrôle de source, CI/CD, la reproductibilité, la traçabilité, les contrôles de déploiement, la surveillance, le retour en arrière et les critères d'acceptation mesurables restent essentiels.

L'extension est que davantage d'artefacts définissant le comportement se trouvent désormais en dehors des poids du modèle. Un modèle de fondation géré peut changer de comportement via des mises à niveau de snapshot, tandis que la sortie de l'application peut changer via des modifications de prompt ou de récupération sans aucun réentraînement du modèle.

C'est pourquoi la hiérarchie utile est généralement DevOps → MLOps → LLMOps/GenAIOps en tant que préoccupations opérationnelles de plus en plus spécialisées, et non trois pratiques mutuellement exclusives.

Que faut-il versionner dans LLMOps ?

Les snapshots de modèle deviennent des dépendances de publication

Avec les LLM hébergés, l'équipe peut ne pas contrôler l'entraînement du modèle, mais elle contrôle toujours quel modèle ou snapshot l'application appelle.

Les directives actuelles de l'API d'OpenAI avertissent explicitement que le comportement de prompt peut changer entre les snapshots de modèle et recommandent d'épingler les applications de production à des snapshots spécifiques là où la cohérence importe, puis d'exécuter des évaluations lors de la mise à niveau.

La conséquence opérationnelle est simple : les mises à niveau de modèle doivent être traitées comme des publications d'application, et non comme une maintenance d'infrastructure invisible.

Le cycle de vie du fournisseur fait partie des opérations

Les applications LLM dépendent souvent des limites de débit des fournisseurs, des calendriers de dépréciation, de la sémantique des API, des limites de contexte, des règles de traitement des données et de la tarification.

Un fournisseur peut déprécier un modèle alors que le code de votre application reste inchangé. Le calendrier de dépréciation actuel d'OpenAI, par exemple, inclut des dates de retrait en 2026 pour d'anciens snapshots de modèles et surfaces de plateforme.

LLMOps nécessite donc un suivi du cycle de vie des fournisseurs, des tests de migration et des décisions de repli en plus de la surveillance de la qualité des modèles.

Les prompts se comportent comme du code de production

Les prompts sont une configuration comportementale exécutable. De petits changements peuvent altérer la qualité de sortie, la sélection d'outils et l'interprétation des politiques.

Les recommandations actuelles d'OpenAI préconisent de stocker les prompts de production dans le code de l'application, de réviser les modifications de prompts via des pull requests, d'utiliser des entrées typées et de couvrir les changements par des tests et des contrôles d'évaluation.

Cela rend le versionnage des prompts moins semblable à la modification d'un texte marketing et plus à la modification d'une fonction dont la sortie est probabiliste et dépendante du modèle.

L'ingénierie du contexte devient une préoccupation opérationnelle

Le modèle de production ne reçoit que rarement un simple prompt statique. Il peut recevoir l'historique de conversation, des documents récupérés, des sorties d'outils, de la mémoire, l'état actuel de l'application et des instructions de politique.

LLMOps doit donc observer l'assemblage du contexte : quelles preuves ont été sélectionnées, quelle version de l'état était active, si une troncature a eu lieu et si des instructions importantes ont survécu à la compaction.

Une régression du modèle et une régression du contexte peuvent sembler identiques dans la réponse finale. C'est en traçant le chemin réel du contexte que l'équipe peut les distinguer.

Le RAG crée son propre cycle de vie opérationnel

Un système RAG introduit un second pipeline de production à côté de l'inférence du modèle : ingestion, extraction, découpage, métadonnées, embeddings, index, récupération, reclassement et sélection du contexte.

Le corpus de connaissances peut changer chaque jour même lorsque le modèle et le prompt ne changent pas. Un index obsolète ou un filtre de métadonnées défectueux peut donc dégrader la qualité des réponses sans aucune dérive du modèle.

LLMOps pour le RAG devrait suivre la version du corpus/index, le modèle d'embedding, la politique de découpage, la configuration de récupération, la fraîcheur des sources et les métriques de récupération séparément de la qualité de génération.

Les évaluations remplacent « ça me semble bon » par des preuves de mise en production

Les sorties génératives sont souvent ouvertes, de sorte que les tests de correspondance exacte sont insuffisants pour de nombreuses tâches. LLMOps ajoute des jeux de données d'évaluation et des évaluateurs capables de mesurer la réussite de la tâche, l'exactitude, la sécurité, l'ancrage, le style ou des critères d'acceptation spécifiques au domaine.

La pile d'évaluation GenAI actuelle de MLflow prend en charge les jeux de données d'évaluation versionnés, les comparaisons de prompts/modèles, les évaluateurs personnalisés et l'évaluation sur des traces complètes.

La pratique la plus solide est le développement guidé par l'évaluation : définir des cas représentatifs et des critères d'acceptation avant ou parallèlement aux modifications, puis comparer les versions par rapport aux mêmes preuves.

Le LLM comme juge est utile mais ne constitue pas une vérité de référence

Les juges LLM peuvent mettre à l'échelle l'évaluation pour des qualités coûteuses à encoder sous forme d'assertions déterministes, telles que la pertinence, le ton ou l'ancrage factuel.

Cependant, le juge est un autre modèle avec ses propres biais, version et prompt. La configuration du juge doit donc être versionnée et calibrée par rapport à des cas de référence humains ou déterministes lorsque les conséquences sont importantes.

Une évaluation en production peut combiner des vérifications déterministes, des métriques basées sur des références, des juges modèles et une revue humaine plutôt que de demander à une seule métrique de représenter toutes les dimensions de qualité.

Le traçage devient plus important que les journaux de point de terminaison

Les journaux d'API traditionnels peuvent vous indiquer qu'une requête a pris deux secondes et a renvoyé HTTP 200. Ils ne peuvent pas vous dire quels segments récupérés ont été sélectionnés, quel outil l'agent a appelé ou quelle portée de modèle a consommé le plus de tokens.

Le traçage GenAI actuel de MLflow capture les prompts, les récupérations, les appels d'outils et les portées applicatives, et son flux d'évaluation en production peut noter les informations de trajectoire intermédiaires plutôt que seulement le texte final.

Il s'agit d'un changement majeur dans le LLMOps : l'observabilité suit le graphe comportemental de l'application, et non plus seulement le point de terminaison de service.

Les agents étendent le LLMOps aux opérations d'exécution

Une application agentique peut effectuer plusieurs appels de modèle, invocations d'outils et transitions d'état avant de produire un résultat.

L'exploitation d'agents nécessite donc des comptages d'étapes, des traces d'appels d'outils, des refus de permission, des tentatives, une détection de boucles, des approbations humaines et un état final vérifié, en plus des métriques ordinaires de latence et de tokens du modèle.

Une réponse finale correcte peut masquer une mauvaise trajectoire, l'évaluation d'un agent doit donc inspecter le chemin autant que le résultat.

Les tokens, les appels de modèle et le contexte deviennent des variables de coût

Le coût d'inférence ML classique est souvent dominé par l'infrastructure de service ou le calcul par prédiction. Les applications LLM peuvent ajouter la tarification des tokens du fournisseur, les appels d'agents répétés, les appels d'embedding, le reranking et les frais généraux d'outils/d'exécution.

Le coût doit donc être attribué à la tâche ou à la trace, et non seulement à un point de terminaison. Un flux de travail qui effectue huit appels de modèle cachés peut être fonctionnellement correct mais opérationnellement inacceptable.

La latence se comporte de la même manière : la latence du modèle, la récupération, le reranking et les outils externes se composent en une latence utilisateur de bout en bout.

La mise en cache devient sémantique, pas seulement technique

Les systèmes LLM peuvent mettre en cache des prompts, des embeddings, des résultats de récupération ou des réponses complètes, mais la clé de cache doit refléter la sémantique qui peut modifier le résultat.

Un cache de réponses qui ignore la version du modèle, le locataire, les autorisations ou la fraîcheur des sources peut renvoyer une réponse techniquement valide mais sémantiquement invalide.

LLMOps traite donc l'invalidation du cache comme faisant partie du versionnage modèle/contexte/données plutôt que comme une simple optimisation d'infrastructure.

La sécurité et les autorisations deviennent des critères de mise en production

Les systèmes génératifs peuvent produire du texte non borné et les agents peuvent déclencher des actions externes. Les tests de sécurité se rapprochent donc davantage du CI/CD ordinaire que dans de nombreux systèmes ML prédictifs classiques.

Les contrôles d'autorisation, les tests d'injection de prompt, les tests d'isolation des locataires et les approbations d'effets de bord devraient être des tests de régression reproductibles là où ces risques existent.

Le modèle peut suggérer une opération, mais l'exécution doit toujours appliquer l'autorisation. LLMOps est responsable des preuves que ces contrôles continuent de fonctionner après des changements de modèle, de prompt ou d'outil.

À quoi ressemble le CI dans LLMOps

À quoi ressemble le CD dans LLMOps

Une mise en production peut ne déployer aucun nouvel artefact de modèle. Elle peut simplement livrer un nouveau prompt, une configuration de récupération, un ensemble d'outils ou un mappage de fournisseur.

Le bundle de mise en production devrait donc identifier la configuration complète définissant le comportement plutôt que seulement l'image de conteneur de l'application.

Les feature flags, le déploiement progressif, l'évaluation en shadow, le trafic canari et le rollback sont utiles car le comportement des LLM peut régresser de manières que les tests de contrat statiques ne détectent pas.

L'entraînement continu devient optionnel ; l'évaluation continue devient centrale

Le MLOps traditionnel met souvent l'accent sur l'entraînement continu lorsque de nouvelles données ou une dérive justifient un réentraînement.

De nombreuses applications LLM n'entraînent jamais le modèle de fondation. Leur boucle continue équivalente est l'évaluation continue : collecter les échecs et les cas de production représentatifs, les ajouter aux jeux de données d'évaluation, tester les modifications candidates de prompt/modèle/récupération et redéployer uniquement lorsque les preuves s'améliorent.

Le fine-tuning peut réintroduire un cycle de vie d'entraînement, mais il doit s'inscrire dans le même processus global d'évaluation et de publication.

Que faut-il surveiller en production ?

Les traces de production peuvent devenir des données d'évaluation

L'un des modèles LLMOps modernes les plus utiles consiste à transformer des traces de production échantillonnées en enregistrements d'évaluation.

MLflow prend actuellement en charge la récupération des traces de production et l'évaluation non seulement des sorties mais aussi des spans intermédiaires tels que les trajectoires de récupération ou d'appel d'outils.

Cela ferme la boucle entre l'observabilité et le développement : les échecs réels peuvent devenir des cas de régression dans la prochaine version plutôt que de disparaître dans les journaux.

La reproductibilité devient conditionnelle plutôt qu'exacte

La reproductibilité classique en ML vise souvent à recréer un modèle à partir de code, de données, d'environnement et de paramètres d'entraînement versionnés.

Les applications LLM hébergées ne peuvent pas toujours reproduire une sortie identique jeton par jeton car la génération est probabiliste et les fournisseurs peuvent contrôler l'infrastructure.

LLMOps vise donc une reproductibilité comportementale : enregistrer suffisamment de modèle/fournisseur/version, de prompt, d'entrées de contexte, d'état de récupération et de configuration d'exécution pour reproduire les conditions et valider le comportement dans les tolérances attendues.

La lignée s'étend de la lignée du modèle à la lignée de l'application

Les conseils MLOps d'AWS considèrent la lignée du modèle comme l'historique du code, des données, du modèle et des artefacts d'infrastructure nécessaires au diagnostic et à la reproductibilité.

Pour les applications LLM, la lignée doit en outre relier les prompts, les jeux de données d'évaluation, les versions de récupération/index, les schémas d'outils, la configuration de l'agent/d'exécution et les instantanés de fournisseur/modèle.

La question cible devient : quelle configuration exacte de l'application a produit cette trace ?

Le routage multi-fournisseur et multi-modèle crée une politique opérationnelle

Une fois qu'une application peut utiliser plusieurs fournisseurs ou modèles locaux, le routage devient une politique opérationnelle plutôt qu'une simple chaîne de modèle.

Le routage peut dépendre de la capacité, de la latence, du coût, de la confidentialité, de la longueur du contexte, de la disponibilité, de la prise en charge des outils ou de la localisation. Un repli peut préserver la disponibilité tout en modifiant la qualité des réponses ou les hypothèses de traitement des données.

LLMOps doit donc journaliser la route réellement sélectionnée et évaluer les routes indépendamment plutôt que de traiter chaque point de terminaison compatible comme comportementalement interchangeable.

Preuves d'implémentation originales

Aaasaasa AI Client : fournisseur, modèle et environnement d'exécution sont des objets opérationnels distincts

Aaasaasa AI Client sépare l'agent/client, le fournisseur, le modèle, l'emplacement d'exécution et les autorisations. Son AI Hub prend en charge Ollama, LM Studio/les points de terminaison compatibles OpenAI et d'autres protocoles de fournisseurs plutôt que de traiter « le modèle » comme un paramètre global unique.

L'implémentation inclut la découverte dynamique des modèles locaux, le streaming, la sortie de réflexion et des contrôles explicites de chargement/déchargement et de préchauffage Ollama. C'est une preuve opérationnelle que le service LLM local introduit des préoccupations de cycle de vie des ressources au-delà d'un nom de modèle d'API.

L'état du fournisseur est interrogé via des adaptateurs de fournisseur, et les types de connexion distinguent les chemins locaux, API cloud, adossés à un compte, agent distant et client web. Ce sont des dimensions opérationnelles concrètes qu'une plateforme consciente des LLM doit exposer.

Le dépôt préserve également une frontière importante : un environnement d'exécution local n'est pas automatiquement une inférence locale. L'emplacement du fournisseur, du modèle et de l'environnement d'exécution sont des préoccupations versionnées ou configurables qui affectent la confidentialité, la latence, le coût et la disponibilité.

Source of Truth Research Engine : l'état d'une application LLM s'étend au-delà du modèle

Le Source of Truth Research Engine combine recherche lexicale, embeddings optionnels, instantanés de sources, identité SHA-256, affirmations, provenance et suivi des contradictions autour d'une recherche assistée par modèle local.

C'est une preuve LLMOps utile car changer le modèle seul ne définit pas le système de recherche. La récupération, l'acquisition de sources, la classification des preuves et la provenance persistante sont des artefacts opérationnels indépendants.

L'implémentation traite délibérément la similarité sémantique comme une découverte plutôt que comme une preuve, montrant pourquoi l'observabilité LLMOps doit distinguer le comportement de récupération de la validité des affirmations.

Modes de défaillance LLMOps courants

Idées fausses courantes

Une séquence de conception LLMOps pratique

Liste de contrôle d'architecture LLMOps

Cas limites et limitations

Une application simple qui appelle un modèle hébergé fixe sans récupération ni outils peut ne nécessiter qu'un LLMOps léger : code de prompt versionné, évaluations, épinglage de modèle, traçage de base et surveillance du fournisseur.

Un modèle auto-hébergé affiné peut nécessiter presque toute la pile MLOps classique plus une évaluation applicative spécifique aux LLM, rendant la frontière entre MLOps et LLMOps intentionnellement floue.

Une plateforme d'agents peut avoir des opérations d'entraînement de modèle minimales mais des opérations d'exécution substantielles car les défaillances surviennent dans la sélection d'outils, l'état et l'orchestration.

Un système fortement basé sur RAG peut être opérationnellement dominé par l'ingestion de documents et la qualité de récupération plutôt que par le service de modèle.

La terminologie continuera d'évoluer. La question architecturale durable n'est pas de savoir quelle étiquette « Ops » l'emporte, mais quels artefacts produisent le comportement et doivent donc être versionnés, évalués, observés et gouvernés.

Qu'est-ce qui changerait cette réponse ?

Si les fournisseurs de modèles de fondation standardisaient un comportement de modèle parfaitement stable et un support de version à long terme, la gestion des fournisseurs/snapshots pourrait devenir moins significative opérationnellement.

Si les applications prennent de plus en plus en charge l'affinage ou l'entraînement, les préoccupations MLOps classiques redeviennent plus centrales.

Le principe opérationnel resterait : chaque composant pouvant modifier matériellement le comportement en production appartient à la lignée, aux tests, à l'observabilité et au contrôle des changements.

Connaissances canoniques associées

LLMOps se situe sous AI Governance et Enterprise AI Architecture : la gouvernance définit quels changements nécessitent des preuves et une approbation, tandis que LLMOps fournit la machinerie opérationnelle pour versionner, évaluer, déployer et observer ces changements.

Context Engineering et RAG sont des sous-domaines opérationnels au sein de nombreuses applications LLM car le contexte et la récupération peuvent modifier le comportement indépendamment du modèle.

Agentic AI étend LLMOps plus loin dans les opérations de trajectoire, de permissions et de runtime d'outils.

Questions fréquentes

Glossaire

Conclusion

MLOps et LLMOps partagent le même objectif d'ingénierie : rendre les systèmes d'IA suffisamment reproductibles, suffisamment testables et suffisamment observables pour fonctionner de manière fiable en production.

La différence réside dans la forme du système. Le MLOps classique se concentre souvent sur l'entraînement et la mise en service d'artefacts de modèle ; LLMOps doit exploiter une pile comportementale dans laquelle les instantanés de modèle, les prompts, le contexte, la récupération, les outils, les permissions et les fournisseurs peuvent changer indépendamment.

La règle utile la plus courte est : versionner, évaluer et observer tout ce qui peut modifier matériellement le comportement de l'application LLM — pas seulement le modèle.

Sources primaires et documentation actuelle

Les sources ci-dessous fondent la base MLOps et les modèles opérationnels actuels pour les applications LLM et agents. Les sections du projet sont des preuves d'implémentation originales et sont intentionnellement plus étroites que les affirmations concernant une plateforme LLMOps complète.