Model Registry
Découvre comment un registre de modèles gère les versions, la gouvernance et le déploiement des modèles de ML. Explore la plateforme Ultralytics pour centraliser l’entraînement, la gestion, la surveillance et la reproductibilité.
Un registre de modèles est un système centralisé qui permet d'organiser, de versionner, de gouverner et de récupérer des modèles de machine learning tout au long de leur cycle de vie. Il relie les fichiers de modèles, tels que les poids de modèle appris, aux métadonnées décrivant la manière dont chaque modèle a été entraîné, évalué, approuvé et déployé. En tant que composant essentiel des opérations de machine learning, un registre fournit aux équipes une source fiable pour décider quelle version de modèle doit traiter le trafic en production.
Fonctionnement d'un registre de modèles#
L'enregistrement d'un modèle commence après qu'une exécution d'entraînement a produit un modèle candidat. Le registre crée une entrée nommée, attribue une version et consigne les informations nécessaires pour comprendre et reproduire l'artefact. Une entrée classique comprend notamment :
- Artefact du modèle : Les poids sérialisés, la logique de prétraitement, les fichiers de configuration ou une référence vers leur emplacement de stockage.
- Version : Un identifiant immuable qui distingue un candidat d'un autre.
- Métriques et paramètres : La précision de validation, la précision, le rappel, la latence, les informations sur le jeu de données, les hyperparamètres et autres mesures.
- Lignage : Les liens entre le modèle, son code source, son exécution d'entraînement et les données.
- État : Des libellés tels que candidat, approuvé, rejeté, champion ou archivé.
- Informations de déploiement : Les environnements et les endpoints qui utilisent actuellement la version.
Les plateformes mettent ces concepts en œuvre de différentes manières. Le workflow du registre de modèles MLflow utilise des modèles enregistrés, des versions, des alias et des balises, tandis que le registre de modèles Amazon SageMaker prend en charge les groupes de modèles, les états d'approbation, le lignage et l'automatisation du déploiement. Certains systèmes enregistrent également une signature de modèle : le schéma d'entrée et de sortie attendu, décrit dans la documentation sur les signatures de modèles Snowflake.
Des alias tels que champion ou production fournissent des noms stables qui peuvent être déplacés entre des versions immuables. Comme l'explique le guide des alias de modèles Vertex AI, une application peut demander un alias sans coder en dur un numéro de version.
Registre de modèles et concepts associés#
Un registre de modèles recoupe plusieurs outils ML, mais remplit une fonction distincte :
- Suivi des expériences consigne les exécutions d'entraînement, notamment les paramètres, les métriques et les artefacts intermédiaires. Un registre reçoit les résultats sélectionnés de ces expériences et les gère comme des candidats à la mise en production.
- Stockage des artefacts conserve les fichiers volumineux. Un registre peut stocker directement ces fichiers, mais il peut également servir d'index de métadonnées pointant vers un stockage d'objets externe. L'architecture du registre de modèles Kubeflow illustre cette conception centrée sur les métadonnées.
- Contrôle de version versionne le code, tandis qu'un registre de modèles versionne les artefacts entraînés et leurs métadonnées spécifiques au ML. Le registre de modèles GitLab peut relier les versions des modèles aux tâches CI/CD, aux journaux, aux métriques et aux paramètres.
- Déploiement de modèles rend un modèle sélectionné disponible pour l'inférence. Le registre identifie l'artefact approuvé ; le système de déploiement l'exécute.
- Surveillance des modèles observe le comportement en production après la mise en production. Les résultats de la surveillance peuvent déclencher l'évaluation, le réentraînement, l'enregistrement et la promotion d'une version de remplacement.
Un registre sert donc de point de contrôle entre l'expérimentation et la production, plutôt que de remplacer chacun des composants qui l'entourent.
Applications concrètes#
Dans un système d'inspection industrielle, les ingénieurs peuvent réentraîner un détecteur de défauts chaque fois que les caméras, les matériaux ou les conceptions des produits changent. Le registre peut conserver la référence au jeu de données de chaque modèle, sa précision moyenne, sa latence d'inférence et son format matériel pris en charge. Après que les tests ont confirmé que la version 12 améliore la détection des rayures sans augmenter les fausses alertes, une personne habilitée peut la promouvoir et conserver la version 11 pour permettre un retour en arrière immédiat.
Dans l'analyse d'images médicales, plusieurs équipes peuvent évaluer des candidats à la détection de tumeurs. L'enregistrement conserve les résultats de validation, la configuration d'entraînement, le responsable et l'historique des approbations de chaque version. Les applications de production peuvent être limitées aux modèles examinés, tandis que les versions antérieures restent disponibles pour les audits et la reproductibilité. Des contrôles basés sur les rôles, tels que ceux décrits pour la gouvernance du registre de modèles Snowflake, contribuent à empêcher le remplacement ou l'inspection non autorisés d'artefacts sensibles.
Enregistrement des modèles dans les workflows Ultralytics#
Ultralytics Platform fournit une gestion centralisée des modèles pour annoter les jeux de données, entraîner, comparer les résultats, exporter, déployer et surveiller les modèles de vision par ordinateur. Son workflow documenté de gestion des modèles Platform prend en charge les poids .pt importés ainsi que les modèles produits par un entraînement dans le cloud ou à distance.
Le workflow documenté ci-dessous entraîne Ultralytics YOLO26 localement tout en envoyant le modèle obtenu, la configuration, les métriques et les journaux vers un projet Platform nommé :
import os
from ultralytics import YOLO
# Authenticate remote training with Ultralytics Platform
os.environ["ULTRALYTICS_API_KEY"] = "YOUR_API_KEY"
model = YOLO("yolo26n.pt")
model.train(
data="coco8.yaml",
epochs=3,
project="username/model-registry-demo",
name="candidate-001",
)Le nom du projet et celui de l'exécution permettent de retrouver le candidat parmi les modèles associés. Les équipes peuvent l'évaluer, utiliser l'intégration Ultralytics MLflow pour consigner des expériences supplémentaires ou appliquer l'exportation de modèles YOLO lorsqu'un modèle enregistré doit s'exécuter sur un matériel cloud ou edge spécifique.
Conseils pratiques pour les registres#
Considère chaque version enregistrée comme immuable. Utilise des alias lisibles pour le déploiement, conserve les éléments probants de validation et définis des exigences claires pour la promotion. Une politique de nommage fondée sur le versionnage sémantique peut communiquer les changements de compatibilité, même si les versions incrémentées automatiquement sont également efficaces.
Plus important encore, enregistre des packages de modèles complets plutôt que des fichiers de poids dépourvus d'explications. L'absence de règles de prétraitement, de noms de classes, de schémas d'entrée, de dépendances ou de références aux jeux de données peut rendre un modèle apparemment valide impossible à reproduire ou dangereux à déployer. Les contrôles d'accès, les tests automatisés, les étapes d'approbation, les journaux d'audit et les procédures de retour en arrière transforment un registre de modèles, qui ne serait autrement qu'un catalogue de fichiers, en une protection fiable pour la production.









