MLflow est une plateforme d'ingénierie d'IA open source lancée par Databricks hébergée par Linux Foundation. Il couvre le suivi des agents/LLM, l'évaluation, la passerelle IA de gestion des mots d'invite, ainsi que le suivi des expériences de ML traditionnelles, l'enregistrement et le déploiement de modèles. Il a été téléchargé plus de 30 millions de fois par mois et est utilisé par des milliers d’entreprises pour la livraison en production d’applications d’IA.

MLflow

Paramètres et statistiques de base

MLflow est actuellement la plus grande plateforme d'ingénierie d'IA open source au monde (Type D - productivité/application métier), officiellement positionnée comme « la plateforme d'ingénierie d'IA open source pour les agents, les LLM et les modèles ». Il couvre le lien complet entre l'observabilité des agents/LLM et le cycle de vie traditionnel du ML. Il ne s'agit pas simplement d'un outil de suivi des expériences, mais unifie le suivi, l'évaluation, la gestion des mots d'invite, la passerelle IA et le déploiement de modèles dans une plateforme open source.

Projets	Informations publiques
Positionnement officiel	La plateforme d'ingénierie d'IA Open Source pour les agents, les LLM et les modèles
Ligne de compétences de base	Observabilité des agents/LLM, évaluation, passerelle IA de gestion des mots d'invite, suivi des expériences, enregistrement du modèle, déploiement du modèle
Méthode de déploiement	Version open source auto-hébergée / Service d'hébergement Databricks
Licence Open Source	Apache2.0
Taille de la communauté	GitHub 27,1 000 étoiles, 6 000 fourchettes, plus de 1 091 contributeurs
Dernière version	MLflow 3.14.0 (2026-06-17)
Téléchargements mensuels	Plus de 30 millions de fois (données publiques officielles)
Plateforme d'assistance	Web, ordinateur de bureau, API
Attribution	États-Unis (LF AI & Data Foundation)
Langues prises en charge	Python, TypeScript/JavaScript, Java, R

Un bref commentaire : MLflow n'est pas un autre framework ML ou un outil de gestion d'expériences, mais une "surface de contrôle d'ingénierie unifiée pour les projets d'IA" - intégrant l'évaluation LLM de suivi des agents, la gestion des versions de mots rapides, l'enregistrement et le déploiement du modèle dans un lien d'ingénierie traçable, résolvant le problème du "manque d'infrastructure standardisée entre le développement et la production de l'IA".

Communauté et rythme d'itération : GitHub affiche 171 versions. Depuis 2026, la version officielle a été poussée dans un cycle d'environ 3 semaines (3.11.1→3.12.0→3.13.0→3.14.0), plus la version candidate rc pour former un rythme de livraison stable. L'équipe de maintenance principale vient de Databricks, mais il y a plus de 1 091 contributeurs communautaires, ce qui indique qu'elle a dépassé le stade de domination d'une seule entreprise et est entrée dans la phase de développement écologique de la gouvernance des fondations.

Dimension de la plate-forme par rapport aux outils MLOps traditionnels : différent de se concentrer sur un seul outil segmenté (tel que le suivi expérimental partiel de W&B et l'observabilité LLM partielle de Langfuse), MLflow tente de couvrir l'ensemble du lien d'ingénierie de l'IA dans le cadre de l'open source. Cette stratégie « à guichet unique » réduit les coûts de changement d'outil, mais signifie également que chaque sous-module peut ne pas avoir autant de profondeur qu'un lecteur dédié.

Reconnaissance des utilisateurs et du marché de MLflow

MLflow est à la tête de la plate-forme d'ingénierie d'IA open source en termes de reconnaissance du marché, et ses données d'adoption ont deux points d'ancrage vérifiables : les métriques de la communauté GitHub et les téléchargements/adoptions par l'entreprise officiellement divulgués.

Popularité de la communauté GitHub : 27,1K étoiles, 6K Forks, 1091+ contributeurs, appartenant au premier échelon des projets open source dans le domaine de l'infrastructure IA/ML. Comparaison de produits similaires : Kubeflow compte environ 14 000 étoiles, Kedro compte environ 10 000 étoiles et Langfuse compte environ 8 000 étoiles. Le nombre d'étoiles en lui-même n'est pas une preuve de capacité, mais reflète l'attention de la communauté, la vitesse de réponse aux problèmes et l'activité de l'écosystème de plug-in/intégration - MLflow est leader dans ces trois dimensions.

Téléchargements et adoption par les entreprises : les téléchargements mensuels officiellement divulgués dépassent 30 millions de fois (à partir de gestionnaires de packages tels que PyPI), et les entreprises clientes incluent Databricks, Microsoft, Meta, MosaicML, Zillow, Toyota, Booking.com, Wix, Accenture, ASML, et plus encore. Ces logos d'entreprises publiques apparaissent sur le site officiel, mais la profondeur d'utilisation spécifique et les données de conversion payante de chaque entreprise ne sont pas divulguées.

Changements de positionnement de l'industrie : avant 2024, MLflow était principalement considéré comme un outil MLOps ; en 2026, son positionnement officiel est entièrement passé à « AI Engineering Platform », et le récit principal est passé de la gestion des expériences ML à l'observabilité des agents/LLM. Ce changement reflète à la fois un changement dans la demande du marché et signifie qu'il devra concurrencer de front les outils d'observabilité LLM tels que Langfuse, Braintrust, LangSmith et autres.

Prérequis : La vraie valeur de MLflow sera révélée lorsque l'équipe disposera déjà d'un processus de développement d'IA faisant collaborer plusieurs personnes. Les avantages de l'utilisation de MLflow au stade expérimental par une seule personne sont limités et peuvent même entraîner des coûts supplémentaires d'exploitation et de maintenance du serveur.

Avantage de coût de MLflow : hiérarchie des services open source gratuits et hébergés

L'avantage de coût de MLflow repose sur le modèle hiérarchique du « service d'hébergement de base open source gratuit + paiement à l'utilisation ». La différence de coût réelle entre les différentes voies d'adoption réside principalement dans l'exploitation et la maintenance plutôt que dans la licence.

Développeurs côté C/individuels : La version open source est entièrement gratuite (licence Apache 2.0) et peut être démarrée localement ou sur un seul serveur via pip install mlflow + mlflow server. Il s’agit d’un seuil zéro pour l’expérimentation personnelle, la recherche universitaire et la vérification de prototypes en petite équipe. Cependant, dans un scénario auto-hébergé, les individus doivent supporter le coût de l'infrastructure d'exécution de MLflow Server (un serveur cloud peut exécuter des instances légères pour environ 50 à 200 yuans/mois), ainsi que les coûts cachés de la base de données (SQLite est la valeur par défaut, PostgreSQL/MySQL est recommandé pour la production) et du stockage (stockage d'objets local ou cloud).

API/Développeur : Il n'y a pas de frais d'appel API pour la version open source. Le prix de la version hébergée par Databricks de MLflow est basé sur la page de tarification officielle de Databricks (non affichée sur le site officiel de MLflow) et est généralement facturé en fonction des ressources informatiques (DBU) et du volume de stockage. Les développeurs peuvent également effectuer une intégration programmatique via l'API REST sur des serveurs auto-hébergés. Les points de terminaison de l'API sont entièrement open source et n'ont aucun contrôle de fréquence ni limite de volume d'appels.

Entreprise/Privé : la version open source prend en charge un déploiement entièrement privé sans frais de licence. Les fonctionnalités de niveau entreprise (telles que la gestion des autorisations RBAC, l'authentification unique du journal d'audit) ont été fournies directement dans la version open source après MLflow 3.13.0 (basées sur le nouveau système d'autorisation de rôle) et ne sont plus limitées à la version hébergée par Databricks. Cela signifie que les entreprises peuvent obtenir des fonctionnalités complètes de gestion des droits sans payer de frais de licence logicielle. Mais le véritable coût du déploiement en entreprise est le suivant : l'infrastructure (déploiement multi-nœuds de niveau production + base de données haute disponibilité + stockage d'objets), la main-d'œuvre opérationnelle (mises à niveau, sauvegardes, surveillance) et les efforts d'intégration avec les CI/CD et l'infrastructure existants. Pour les équipes qui disposent déjà de clusters Kubernetes, le Helm Chart officiel fourni par MLflow 3.13+ peut réduire considérablement la complexité du déploiement.

Structure de coûts réelle : pour la plupart des équipes, le coût caché de MLflow ne réside pas dans le logiciel lui-même, mais dans « l'intégration et la maintenance » - l'investissement initial requis pour migrer une équipe de « l'absence de plate-forme d'ingénierie d'IA unifiée » à « l'utilisation de MLflow pour gérer l'intégralité du lien », y compris : l'adaptation et la transformation des flux de travail existants, la conception de stratégies de stockage d'artefacts, la planification de modèles d'autorisations utilisateur et l'amarrage aux pipelines CI/CD existants (tels que Jenkins, GitHub Actions). Cet investissement est généralement bien supérieur au coût de fonctionnement du serveur MLflow lui-même.

Principales fonctions de MLflow

Le système de capacités de MLflow peut être compris sous deux dimensions : « pour les scénarios Agent/LLM » et « pour les scénarios ML traditionnels ». Les deux partagent le même ensemble d’infrastructures (Tracking Server, Model Registry, UI), mais les modules de fonctionnalités se développent indépendamment.

Scénario Agent/LLM

• Observabilité/Traçage : construit sur la base d'OpenTelemetry, capture automatiquement le lien d'appel complet des applications d'agent et LLM - y compris chaque entrée d'invite, la réponse LLM d'appel d'outil, les étapes intermédiaires et la consommation de jetons. Prend en charge plusieurs langages tels que Python, TypeScript/JavaScript et Java, et implémente la journalisation automatique en un clic (AutoLogging) avec plus de 60 frameworks. Différences par rapport aux produits concurrents : Tracing de MLflow est intégré à la plate-forme open source plutôt qu'à un produit indépendant, ce qui signifie que les données de trace, le suivi expérimental et l'enregistrement du modèle partagent le même stockage et le même backend, et qu'il n'est pas nécessaire de passer d'un système à l'autre pour le dépannage.
• Évaluation : fournit plus de 50 indicateurs de notation intégrés et un évaluateur LLM-as-Judge, prenant en charge la logique d'évaluation définie par l'utilisateur. La balise pytest @mlflow.test introduite dans la version 3.14.0 permet aux développeurs d'écrire des tests de régression directement dans le pipeline CI, et chaque soumission déclenche automatiquement une inspection qualité et l'envoie à l'interface utilisateur MLflow. Conseils de mise en œuvre : le goulot d'étranglement des résultats d'évaluation est généralement la « qualité des annotations de l'ensemble de données de test » plutôt que l'outil d'évaluation lui-même. Il est recommandé d'investir du temps dès le début pour créer un ensemble de données d'annotation couvrant les scénarios de base.
• Invites et optimisation : Prompt Registry effectue la gestion des versions des invites et prend en charge les mises à niveau des tests à la production (Staging → Production). Moteur d'optimisation d'invite intégré, utilisant des algorithmes tels que MemAlign pour optimiser automatiquement les effets de mots d'invite. Le nouveau LLM Playground de la version 3.14.0 permet d'itérer des mots d'invite directement dans le navigateur et de comparer les effets des différentes versions en temps réel.
• AI Gateway : une couche proxy unifiée compatible OpenAI qui prend en charge le routage multimodèle, la limitation de débit, le repli tolérant aux pannes, le contrôle budgétaire et la gestion des droits d'accès. Peut être connecté à plus de 20 fournisseurs de modèles (OpenAI, Anthropic, Gemini, Bedrock, Ollama, Groq, DeepSeek, etc.) et prend en charge les contrôles de sécurité et de conformité avant et après les demandes via le mécanisme Guardrails. Emplacement de l'architecture : LLM → AI Gateway → Fournisseur de modèles, Gateway sert d'entrée unifiée pour tous les appels de modèles afin d'assurer le contrôle des coûts, l'audit et la gouvernance des accès.
• **UN

gent Server** : solution d'hébergement d'agent basée sur FastAPI introduite dans la version 3.14.0. L'application agent peut être déployée en tant que point de terminaison HTTP de niveau production avec une seule commande, avec réponse en streaming intégrée, vérification des demandes et suivi automatique.

Scénario de ML traditionnel

• Suivi des expériences : enregistre le dictionnaire de paramètres, la courbe indicatrice, la version du code et les artefacts de sortie (poids du modèle, graphiques visuels, etc.) de chaque formation, et fournit une liste d'expériences triables, filtrables et comparables via l'interface utilisateur. Collaboration de base : lien entre le suivi des expériences et le registre des modèles : les exécutions de haute qualité (Runs) dans les expériences peuvent être mises à niveau vers des versions de modèles enregistrées en un seul clic, éliminant ainsi le besoin de déplacer manuellement les fichiers de poids.
• Model Registry : un entrepôt de gestion centralisé pour les versions de modèles, prenant en charge les étiquettes d'étape (Staging→Production→Archived), les descriptions de versions, la traçabilité du lignage et les workflows d'approbation. Convient à la gestion des versions de modèles et aux scénarios de tests A/B.
• Déploiement de modèle : emballez le modèle au format MLflow en tant que point de terminaison d'API REST, prenant en charge plusieurs plates-formes cibles telles que Docker, Kubernetes, Amazon SageMaker, Azure ML, Nebius, etc. La commande mlflow models serve peut rapidement démarrer le service d'inférence de modèle localement.
• Model Evaluation (ML Evaluation) : un outil d'évaluation automatique, intégré au processus de suivi des expériences, prenant en charge les calculs d'indicateurs standardisés pour la classification, la régression, le classement et d'autres tâches. Partage la même infrastructure d’évaluation que le module d’évaluation LLM.

Modèle MLflow et évolution des versions

Le numéro de version de MLflow a complété la transition majeure de la version de 2.x à 3.x de fin 2025 à début 2026, marquant un changement complet dans le positionnement du produit de la « gestion du cycle de vie ML » à la « plateforme d'ingénierie IA ». Voici un résumé des nœuds de version clés par étape :

Ère 1.x : jeter les bases de la gestion des expériences ML (2020-2022)

• MLflow 1.0 (~2020-06) : la première version stable, établissant les quatre modules principaux de suivi, de projets, de modèles et de registre, et utilisant un concept de conception léger et indépendant du framework pour la différencier des plates-formes lourdes telles que Kubeflow.
• MLflow 1.x Series (2020-2022) : améliorez progressivement l'API REST, les spécifications d'empaquetage des projets MLflow, l'intégration approfondie avec Apache Spark et les capacités de gestion des étapes de Model Registry. La base d'utilisateurs principale se trouve dans les équipes de science des données et d'ingénierie ML.

L'ère 2.x : LLM et mise à l'échelle du déploiement (2023-2026)

• MLflow 2.0 (~2023-03) : refactorisation architecturale majeure, introduction d'une nouvelle interface utilisateur de suivi, prise en charge des scénarios LLM (tels que le suivi des invites), options de déploiement de modèles plus riches (SageMaker, Azure ML, etc.) et meilleure gestion des artefacts de fichiers volumineux.
• MLflow 2.18 (~2026-04) : la version finale de la série 2.x, améliorant encore les capacités de suivi et d'évaluation LLM, ouvrant la voie à une transition complète vers 3.x. 2.x a connu un total d'environ 20+ mises à jour de version, et le rythme d'itération est d'environ une version officielle par mois.

Ère 3.x : transformation de la plateforme d'ingénierie de l'IA (de 2026 à aujourd'hui)

• MLflow 3.11.1 (08/04/2026) : introduction de la détection automatique des problèmes (détection des problèmes AI), de la vue graphique Trace d'alarme budgétaire de passerelle, de la prise en charge native de la convention sémantique OpenTelemetry GenAI et de l'identification des dépendances du modèle de gestionnaire de packages UV. Dans le même temps, nous avons commencé à supprimer les dépendances tierces telles que LiteLLM et à nous tourner vers un routage de fournisseur auto-construit.
• MLflow 3.12.0 (06/05/2026) : pièces jointes de suivi multimodal (les images, les audios et les fichiers sont directement stockés dans Trace), mécanisme de garde-corps AI Gateway de suivi de l'agent de codage Codex/Gemini/Qwen (Guardrails). Les noms des packages du SDK TypeScript ont été déplacés vers la portée de l'organisation @mlflow/.
• MLflow 3.13.0 (02/06/2026) : système de gestion des autorisations de rôle RBAC et interface utilisateur d'administration - Il s'agit d'une étape importante pour la version open source. La gouvernance des autorisations au niveau de l'entreprise ne repose plus sur la version hébergée de Databricks. La même version introduit l'archivage automatique Trace vers le stockage objet, le déploiement officiel de Helm Chart pour K8 et la prise en charge de l'agent Hermes.
• MLflow 3.14.0 (2026-06-17) : la dernière version actuelle. Accès à l'agent en un clic (commande mlflow agent setup), suivi de la persistance à faible latence Claude Code (basé sur Write-Ahead-Log), file d'attente de révision des traces (Review Queues), intégration des tests de régression pytest (@mlflow.test), plateforme d'itération de mots d'invite LLM Playground. Changement radical : le format de sérialisation par défaut de sklearn et PyTorch passe de pickle à skops / pt2 pour améliorer la sécurité.

Avantages techniques de MLflow

L'avantage technique de MLflow ne réside pas dans une seule innovation algorithmique, mais dans « l'unité de la plateforme » et « l'ouverture écologique » dans la conception architecturale – ces deux points déterminent sa valeur réelle dans les scénarios de collaboration multi-outils.

Philosophie de conception légère et indépendante du framework : MLflow a adhéré à la philosophie "pas un framework, pas une plateforme, mais une bibliothèque" dès le premier jour - tant que vous pouvez écrire des scripts de formation en Python/R/Java/TypeScript, vous pouvez utiliser import mlflow pour y accéder. Comparé à Kubeflow (qui nécessite le cluster Kubernetes Pipeline DSL et un processus DevOps complet), le seuil de déploiement de MLflow est extrêmement bas : un seul serveur ou même un seul ordinateur portable peut exécuter des services complets de suivi des expériences et d'enregistrement de modèles. Le prix de cette conception est le suivant : lorsque l'équipe évolue et nécessite une isolation multi-tenant et des autorisations affinées, la configuration par défaut de la version open source (SQLite + système de fichiers local) atteint rapidement un goulot d'étranglement et doit être déplacée vers une base de données et un magasin d'objets de niveau production.

Architecture d'observabilité basée sur OpenTelemetry : le module Tracing de MLflow est construit directement sur le standard OpenTelemetry au lieu de développer un protocole auto-développé. Cela signifie qu'il peut interagir avec n'importe quel outil de collecte, d'exportateur et de visualisation de l'écosystème OTel. 3.11.1+ prend en charge l'exportation de contrat sémantique OTel GenAI, afin que les données Trace puissent être consommées par les plates-formes OTel standard (telles que Grafana, Datadog). Mécanisme→Effet : les équipes n'ont pas besoin de choisir entre le format de traçage de MLflow et l'infrastructure observable existante. MLflow Trace peut entrer dans un système de surveillance unifié dans le cadre du flux de données OTel.

Modèle de données unifié : les entités telles que Expérience, Exécution, Version du modèle et Trace partagent le même ensemble de stockage principal (base de données SQL + stockage d'objets), ce qui signifie que vous pouvez directement passer de Trace à l'expérience correspondante exécutée dans l'interface utilisateur et remonter de la version du modèle à l'exécution qui l'a entraîné. Ce type de fonctionnalité de « traçabilité unidirectionnelle » est très critique lors du dépannage des problèmes de production : lorsque la qualité d'une certaine version d'un modèle diminue en ligne, l'opérateur peut retracer l'intégralité des paramètres et des indicateurs de l'expérience de formation directement à partir du registre des modèles.

Conception décentralisée d'AI Gateway : 3.11.1+ commence à supprimer la dépendance à l'égard de LiteLLM et intègre à la place l'implémentation du fournisseur natif de chaque fournisseur de modèle (OpenAI, Anthropic, Bedrock, Vertex AI, Ollama, xAI, etc.). Cela signifie qu'AI Gateway peut fonctionner de manière indépendante, sans dépendances externes, réduisant ainsi la complexité du déploiement et les risques potentiels liés à la sécurité de la chaîne d'approvisionnement. Gateway prend également en charge un backend Redis pour le suivi du budget dans les déploiements distribués, ainsi que des contrôles de sécurité avant et après demande basés sur Guardrails.

Explication des pièges et limites du projet :

• Extension des données de trace : après avoir activé le traçage dans un environnement de production, si le taux d'échantillonnage et la politique de rétention ne sont pas définis, la quantité de données de trace écrites peut rapidement dépasser la capacité de charge de la base de données SQL. Le mécanisme d'archivage automatique Trace de MLflow 3.13+ (déplacement des données froides vers le stockage objet) est une fonctionnalité nécessaire, mais la stratégie d'archivage (durée d'archivage, délai de requête après l'archivage) doit être planifiée à l'avance en fonction de l'ampleur réelle de Trace.
• Coût de migration du workflow existant : lors de la migration d'outils existants (par exemple W&B, MLflow 1.x) vers la dernière version de MLflow 3.x, la compatibilité des API et les options de migration des données doivent être évaluées. La version 3.x a introduit des modifications majeures (telles que la reconstruction du système d'autorisations, la modification par défaut du format de sérialisation) et la vérification de la compatibilité doit être effectuée dans le contexte de préparation avant de mettre à niveau le contexte de production.
• Différences de maturité du SDK multilingue : le SDK Python possède les fonctions les plus complètes, le SDK TypeScript (0.2.0) est toujours en itération rapide et la couverture des fonctions du SDK Java et R est considérablement en retard. Pour les équipes qui utilisent principalement des langages autres que Python, vous devez confirmer au préalable si les fonctions requises sont disponibles dans le SDK correspondant.

Comment utiliser MLflow

MLflow fournit plusieurs méthodes d'accès, couvrant différents besoins, des expériences personnelles au déploiement au niveau de l'entreprise.

Comment utiliser	Convient aux personnes	Comment commencer	Coût
Version open source auto-hébergée	Développeurs individuels, équipes techniques	pip install mlflow + serveur mlflow	Gratuit (propre infrastructure)
Édition hébergée Databricks	Utilisateurs de Databricks d'entreprise	Activé via l'espace de travail Databricks	Facturé au tarif Databricks
Accès rapide à l'agent de codage	Développeur d'agents	uvx mlflow@dernière configuration de l'agent	Gratuit
Assistant MLflow	Exploitation et maintenance de la plateforme	Démarrez via CLI ou backend Ollama/OpenAI	Gratuit (les frais d'appel LLM sont à vos frais)

Guide de démarrage rapide (auto-hébergé) :

# 1. Installez MLflow
pip installer mlflow

# 2. Démarrez le serveur de suivi (backend SQLite par défaut + stockage d'artefacts local)
serveur mlflow --hôte 0.0.0.0 --port 5000

# 3. Intégrer le suivi dans le code de formation
importmlflow
à partir de sklearn.ensemble importer RandomForestClassifier
à partir de sklearn.metrics, importez précision_score

mlflow.set_tracking_uri("http://localhost:5000")

avec mlflow.start_run() :
    # Paramètres d'enregistrement
    mlflow.log_param("n_estimateurs", 100)
    mlflow.log_param("max_profondeur", 10)

    #Modèle de train
    modèle = RandomForestClassifier (n_estimators=100, max_degree=10)
    modèle.fit (X_train, y_train)
    preds = modèle.predict(X_test)

    # Indicateurs d'enregistrement
    acc = précision_score (y_test, preds)
    mlflow.log_metric("précision", acc)

    # Enregistrer le modèle
    mlflow.sklearn.log_model(modèle, "modèle")

Accès rapide au suivi des agents/LLM (MLflow 3.14+) :

# Installez les compétences MLflow et démarrez le suivi des agents en un seul clic
uvx mlflow@dernière configuration de l'agent

# Démarrez MLflow Server (comme ci-dessus)
serveur mlflow --hôte 0.0.0.0 --port 5000

importmlflow

mlflow.set_tracking_uri("http://localhost:5000")
# Activez le suivi automatique OpenAI en un seul clic
mlflow.openai.autolog()

depuis openai importer OpenAI
client = OpenAI()
réponse = client.responses.create(
    modèle="gpt-5-mini",
    input="Bonjour !",
)

Chemin d'utilisation typique : il est recommandé d'accéder progressivement dans l'ordre "d'abord le suivi de l'expérience locale → puis l'enregistrement du modèle → puis le déploiement". Au cours de la première semaine, ajoutez « mlflow.start_run() » et les enregistrements d'indicateurs de paramètres de base au projet, puis introduisez le processus d'enregistrement et d'évaluation du modèle après avoir confirmé que les exigences sont remplies. Assurez-vous de terminer la migration de la base de données principale (de SQLite vers PostgreSQL/MySQL) et la configuration du stockage d'artefacts (du système de fichiers local vers S3/MinIO/ABS) avant le déploiement en production.

Prix des produits pour MLflow

La tarification de MLflow est basée sur le principe selon lequel « les fonctionnalités de base open source sont gratuites + les services d'hébergement sont payants à l'utilisation » et il n'y a pas de paywall basé sur les fonctionnalités.

Version Open source (toutes les fonctions sont gratuites) : licence Apache 2.0, couvrant toutes les fonctions telles que le suivi des agents/LLM, l'évaluation, la gestion des mots d'invite AI Gateway, le suivi des expériences, l'enregistrement et le déploiement de modèles, etc. Il n'y a aucune restriction de fonction, aucune limite d'utilisateurs et aucune limite d'appels API. La version open source 3.13.0+ inclut déjà des fonctionnalités de niveau entreprise telles que l'interface utilisateur d'administration de gestion des autorisations RBAC, et vous n'avez plus besoin de payer pour passer à la version gérée.

Databricks Hosted Edition : pour les équipes qui ne souhaitent pas créer leur propre infrastructure. La logique de tarification est cohérente avec la plateforme Databricks : vous payez en fonction de la consommation des ressources informatiques (DBU) et du volume de stockage. Le prix spécifique est basé sur la page de tarification officielle de Databricks (non divulguée sur le site officiel de MLflow). La version gérée est entièrement compatible avec l'API et le SDK de la version open source, et le coût de commutation est faible.

Assistance : Open Source Edition offre une assistance communautaire via les problèmes GitHub, Slack, les listes de diffusion communautaires et les heures de bureau régulières. La prise en charge Enterprise SLA est achetée via Databricks.

Rappel des coûts cachés (précédemment développé) : Le coût caché le plus important n'est pas le logiciel lui-même, mais "la migration des processus + l'exploitation et la maintenance de l'infrastructure" - pour une petite équipe sans DevOps dédié, la maintenance d'un serveur MLflow au niveau de la production (base de données haute disponibilité, stockage d'objets, stratégie de sauvegarde, mise à niveau de version) nécessite un réel investissement humain. Il est recommandé, avant de décider de s'auto-héberger, d'exécuter MLflow sur une seule machine sur un serveur cloud léger pour découvrir les fonctions de base, puis de planifier un plan de déploiement au niveau de la production après avoir confirmé la valeur et la demande.

Scénarios d'application de MLflow

Les scénarios de mise en œuvre de MLflow couvrent les trois étapes typiques de l'ingénierie de l'IA (développement et débogage, assurance qualité et livraison en production) et sont répartis dans les quatre types de scénarios suivants :

• Développement et débogage d'applications agent/LLM : utilisez MLflow Tracing pour capturer la trace complète de chaque appel d'agent, y compris le raisonnement en plusieurs étapes, la réponse LLM à l'appel d'outil et l'état intermédiaire. Les développeurs peuvent afficher les détails de l'étendue de Trace, la consommation des jetons et la distribution des délais dans l'interface utilisateur, et localiser rapidement « à quelle étape l'agent a commis une erreur » ou « quel appel d'outil a pris le plus de temps ». Déduction quantitative : sans traçage, il faut en moyenne 30 à 60 minutes pour résoudre le comportement anormal d'un agent (ajout répété de journaux et relecture de scénarios) ; après avoir accédé à MLflow Tracing, le temps nécessaire pour localiser le même type de problème peut être réduit à 5 à 10 minutes. Remarque : Cette déduction est basée sur des modèles d'utilisation internes et ne constitue pas un engagement officiel.
• Évaluation de la qualité LLM et tests de régression : intégrez plus de 50 indicateurs d'évaluation intégrés et un juge LLM personnalisé dans le pipeline CI - effectuez automatiquement une évaluation après chaque invite ou mise à jour du modèle et comparez les tendances de changement de qualité dans l'interface utilisateur. La balise pytest @mlflow.test dans la version 3.14.0 permet aux évaluations d'être directement contrôlées en tant que CI (par exemple : la construction échoue si la précision est < 90 %). Limite de collaboration homme-machine : la détermination « réussite/échec » de l'évaluation peut être 100 % automatisée, mais la création et la maintenance de l'ensemble de données d'évaluation, ainsi que l'« annotation des cas extrêmes » nécessitent une intervention manuelle. Il est recommandé d'automatiser 80 % des tests de régression réguliers et de réserver 20 % des scénarios à haut risque pour une révision manuelle (attribuée à des réviseurs désignés via les files d'attente de révision).
• Gestion des versions de modèle et déploiement en production : les data scientists promouvront en un clic les exécutions d'expériences de haute qualité dans Model Registry, les marqueront comme Staging pour la vérification préalable à la publication, et après avoir réussi la vérification, ils seront promus en production et déployés sur le point final de production par l'équipe MLOps. La méthode de déploiement prend en charge les conteneurs Docker, Kubernetes (Helm Chart), SageMaker, etc. Conseil d'implémentation : Il est préférable de lier le processus d'amélioration par étapes de Model Registry avec le pipeline CI/CD (par exemple : l'amélioration de Staging→Production déclenche des scripts de déploiement automatiques) pour éviter le risque de confusion de version causée par des opérations manuelles.
• Audit de gouvernance et de conformité de l'IA : les données de trace et expérimentales de MLflow fournissent

Lien d'audit complet de "données de formation → version du modèle → inférence de production". Pour les équipes qui doivent répondre aux exigences de conformité SOC2, RGPD ou de l'industrie, le système RBAC de 3.13.0+ permet le contrôle d'accès par rôle et par granularité d'utilisateur, et le mécanisme d'archivage Trace garantit que les données froides sont traçables mais n'occupent pas un stockage en ligne illimité. Limitations : la version open source ne fournit pas de fonctionnalités de désensibilisation des données et de détection des informations personnelles (celles-ci doivent être complétées via Gateway Guardrails ou des outils externes), et les équipes de conformité doivent s'évaluer elles-mêmes. Si les dossiers d’audit de MLflow répondent aux exigences réglementaires du secteur.

Groupes applicables de MLflow

La stratégie de « plateforme unifiée » de MLflow détermine qu'elle sert les équipes qui ont besoin d'une collaboration entre les rôles, plutôt qu'un seul outil de développement individuel. Les trois types de rôles suivants constituent les groupes d'utilisateurs principaux :

• Ingénieurs ML/AI et data scientists : utilisez le suivi des expériences pour enregistrer les paramètres et indicateurs de formation, comparer les effets de différentes expériences via l'interface utilisateur et enregistrer le modèle optimal dans l'entrepôt de modèles en un seul clic. Prérequis : Des compétences de base en programmation Python sont requises ; une certaine compréhension de l'API de suivi de MLflow et du format de modèle MLflow. Pour les utilisateurs qui utilisent uniquement les plates-formes AutoML ou ML sans code, le modèle d'intégration d'API de MLflow ajoute des coûts d'apprentissage supplémentaires.
• Développeur d'applications LLM/Agent : utilisez Tracing pour capturer les liens d'appel d'agent, évaluez la qualité de sortie LLM via le module d'évaluation et utilisez AI Gateway pour gérer les coûts et les autorisations d'appel multimodèles. Prérequis : Vous devez comprendre les concepts de base d'OpenTelemetry (Span, Trace) et la topologie appelante de l'application Agent. Pour les scénarios simples dans lesquels un seul modèle est utilisé (comme l'appel direct de l'API OpenAI), les gains d'observabilité de MLflow sont limités : la complexité de la chaîne d'outils ne peut être véritablement reflétée que lorsque "plusieurs modèles + plusieurs agents + collaboration multi-personnes".
• Équipe d'ingénierie MLOps/Platform : responsable du déploiement et de la maintenance du serveur MLflow, de la configuration des autorisations RBAC, des politiques d'archivage de trace et des règles de routage AI Gateway, et de l'intégration de MLflow dans les systèmes CI/CD et de surveillance existants. Prérequis : Vous devez disposer de capacités de base en matière de gestion de bases de données (PostgreSQL/MySQL), de configuration de stockage d'objets (S3/MinIO) et d'orchestration de conteneurs (Docker/K8s). Pour les petites équipes de 5 à 10 personnes sans équipe d'infrastructure dédiée, Databricks Hosted est recommandé plutôt que l'auto-hébergement.

Ne correspond pas aux limites :

• Ne convient pas aux utilisateurs non techniques qui ont besoin de fonctionnalités AutoML de bout en bout (MLflow est une plateforme d'ingénierie, pas un service AutoML).
• Ne convient pas aux scénarios qui nécessitent uniquement des enregistrements expérimentaux au niveau personnel (vous pouvez utiliser des outils plus légers tels que W&B Free ou TensorBoard).
• Ne convient pas aux scénarios qui ont des exigences extrêmes en matière de souveraineté des données et ne peuvent accepter aucun composant externe (MLflow nécessite une base de données et un stockage back-end, et n'est pas un outil d'enregistrement de fichier unique).
• Ne convient pas à la surveillance pure des modèles de production (les capacités de surveillance de MLflow sont axées sur le traçage et l'évaluation, et il lui manque les fonctions de détection de dérive et d'alarme en temps réel de la surveillance de modèle traditionnelle - cette partie nécessite une coopération avec des outils de surveillance spéciaux tels que Arize/PourquoiLabs).

Résumé et Outlook

L'évolution du positionnement de MLflow reflète clairement deux tendances sur le marché de l'ingénierie de l'IA : Premièrement, « l'observabilité LLM/Agent » remplace la « gestion des expériences ML » comme besoin le plus urgent de l'équipe ; Deuxièmement, la bataille entre « une plate-forme unifiée et la meilleure combinaison d'outils » s'intensifie. MLflow a choisi la première solution - couvrant autant de détails que possible sur une plate-forme open source et utilisant la « fermeture de données traçables » (Expérience → Modèle → Déploiement → Trace → Évaluation) pour réduire le coût de friction des sauts entre outils.

Sa principale compétitivité réside dans trois points : la stratégie open source sous licence Apache 2.0 élimine les problèmes de dépendance vis-à-vis du fournisseur ; l'architecture d'observabilité basée sur OpenTelemetry permet de l'intégrer dans l'écosystème de surveillance existant ; et l'écosystème d'intégration soutenu par plus de 1091 contributeurs (plus de 60 frameworks en un clic et plus de 20 passerelles de fournisseurs de modèles). Ces avantages sont particulièrement importants dans les scénarios où les équipes nécessitent une collaboration entre rôles, une gestion multimodèle et sont sensibles au verrouillage du fournisseur.

Limites et incertitudes actuelles :

1. Profondeur vs largeur du sous-module : MLflow continue d'investir dans le traçage et l'évaluation, mais sa gestion rapide et AI Gateway ne sont toujours pas aussi matures que Langfuse (axé sur l'observabilité LLM) et LiteLLM (axé sur Gateway). Si l’équipe n’a besoin que d’une seule fonctionnalité (telle que la gestion des invites uniquement), un outil professionnel peut offrir une meilleure expérience.
2. Risque de modifications cassantes dans la version 3.x : La version intensive de 3.11→3.14 a apporté un certain nombre de modifications cassantes (réécriture du système d'autorisations, changement par défaut du format de sérialisation, migration du nom du package TypeScript). Pour les équipes qui ont déployé un environnement de production 2.x, la mise à niveau vers 3.x nécessite des tests et des vérifications suffisants.
3. Écologie et documentation chinoises : la documentation et l'interface utilisateur de MLflow sont actuellement uniquement en anglais, et les ressources de la communauté chinoise et les documents localisés sont relativement limités. Pour les équipes dont la langue de travail principale est le chinois, des investissements supplémentaires dans la traduction de documents et la formation interne peuvent être nécessaires.
4. Incertitude liée à la commercialisation : l'itération rapide de la version open source de MLflow repose-t-elle sur la force motrice commerciale de Databricks ? Bien que l'hébergement de la Linux Foundation garantisse que le projet ne sera pas contrôlé par une seule entreprise, une proportion relativement élevée d'employés de Databricks figure parmi les principaux contributeurs. Si l'orientation commerciale de Databricks change, il reste incertain si la communauté pourra maintenir le rythme d'itération actuel.

Évaluation des risques d'approvisionnement/d'adoption : il est recommandé d'adopter la stratégie de « vérification open source d'abord, puis de mise à niveau à la demande » : déployez d'abord la version open source de MLflow sur de petits projets de 1 à 2 équipes, et utilisez 2 à 4 semaines pour vérifier si le traçage et l'évaluation sont conformes au flux de travail de l'équipe ; après avoir réussi la vérification, planifiez le déploiement au niveau de la production (PostgreSQL + Object Storage + K8s Helm Chart) et évaluez s'il est nécessaire d'acheter la version hébergée via Databricks pour réduire la charge d'exploitation et de maintenance. Les entreprises doivent se concentrer sur la vérification avant d'acheter : ① La différence annuelle de TCO entre les versions auto-hébergées et hébergées ; ② Si le modèle d'autorisation RBAC 3.x couvre les exigences de conformité de l'organisation ; ③ Si le taux d'échantillonnage et la stratégie d'archivage de LLM Tracing peuvent répondre aux exigences de période de conservation des données d'audit.

Outils associés : Visage câlin, replicate

Informations de version

• MLflow 3.14.0 ：Présentation de l'assistant d'accès à l'agent en un clic (configuration de l'agent mlflow), du suivi persistant à faible latence de Claude Code, des tests de régression pytest de la file d'attente d'examen des traces, de la plate-forme d'itération de mots d'invite LLM Playground intégrée et de la prise en charge des pièces jointes de suivi multimodal. （2026-06-17）
• MLflow 3.13.0 ：Présentation de la gestion des autorisations de rôle RBAC et de l'interface utilisateur d'administration, de l'archivage automatique du suivi vers le stockage d'objets Helm Chart, du déploiement K8 au niveau de la production et de la prise en charge du traçage de l'agent Hermes. （2026-06-02）
• MLflow 3.12.0 ：Attachement de suivi multimodal Codage Codex/Gemini/Qwen Le suivi de l'agent prend en charge la pagination du tableau de trace du garde-corps AI Gateway. Il n'y a pas encore de date officielle précise, veuillez vous référer aux versions de GitHub. （2026-05-06）
• MLflow 3.11.1 ：La détection automatique des problèmes (AI Issues Detection), l'alarme budgétaire de la passerelle et la vue graphique Trace de limite, ainsi que la convention sémantique native OpenTelemetry GenAI prennent en charge l'identification du gestionnaire de packages UV. （2026-04-08）
• MLflow 2.18.0 ：La version finale de la série 2.x, améliorant les capacités de suivi et de déploiement LLM. Il n’y a pas encore de date officielle précise. （~2026-04）
• MLflow 2.0.0 ：Refactorisation architecturale majeure, introduction de la prise en charge LLM, d'options de déploiement plus riches et d'une nouvelle interface utilisateur de suivi. Il n’y a pas encore de date officielle précise. （~2023-03）
• MLflow 1.0.0 ：La première version stable établit trois fonctionnalités principales : le suivi des expériences, l'enregistrement des modèles et le déploiement. Il n’y a pas encore de date officielle précise. （~2020-06）