Model Deployment

Le déploiement de modèles consiste à mettre en production un modèle d’apprentissage automatique entraîné, afin que les applications lui transmettent de nouvelles données et exploitent ses prédictions. Il couvre le choix de l’environnement d’exécution du modèle, sa conversion dans un format pris en charge par l’environnement d’exécution cible, sa connexion aux entrées et aux sorties au moyen d’une API ou d’une application, la publication sécurisée de nouvelles versions et le suivi de son comportement une fois qu’il est utilisé par de vrais utilisateurs. Un modèle qui obtient de bons scores dans un notebook reste une expérience tant qu’il n’est pas déployé. Le déploiement est l’étape des opérations d’apprentissage automatique (MLOps) où la science des données se confronte aux contraintes du génie logiciel, notamment la latence, le coût, la disponibilité et la sécurité.

Où déployer les modèles#

• Déploiement dans le cloud : le modèle s’exécute sur des serveurs derrière un point de terminaison REST ou gRPC, généralement via un système de service de modèles qui regroupe les requêtes et ajuste le nombre de réplicas en fonction de la demande. Cette solution convient aux grands modèles et au trafic variable, mais chaque requête implique un aller-retour réseau.
• Déploiement en périphérie : le modèle s’exécute sur l’appareil qui capture les données, par exemple un téléphone, une caméra, un robot ou un module NVIDIA Jetson. Les entrées ne quittent jamais l’appareil, ce qui protège la confidentialité, et le modèle continue de fonctionner hors ligne ; toutefois, la mémoire et la puissance limitées imposent généralement l’utilisation d’un modèle compressé.
• Déploiement sans serveur : la plateforme lance des instances à la demande et ramène leur nombre à zéro lorsqu’elles sont inactives. Cette solution implique un délai de démarrage à froid lors de la première requête, mais aucun coût lorsque les requêtes cessent.
• Déploiement par lots : une tâche planifiée évalue un grand jeu de données en une seule fois, par exemple pour générer chaque nuit des recommandations de produits, lorsque le débit compte davantage que la vitesse par requête.

Ultralytics Platform déploie un modèle YOLO entraîné sur un point de terminaison dédié dans l’une des 42 régions, chacune avec sa propre URL et sa propre surveillance ; les points de terminaison utilisant la taille de ressource par défaut passent à zéro lorsqu’ils sont inactifs. Le choix de la cible découle de quelques questions sur l’application, que la leçon de l’Ultralytics Academy Choisir une cible de déploiement examine en détail :

Préparer un modèle pour la production#

Les frameworks d’entraînement sont conçus pour être flexibles ; les modèles de production sont donc généralement exportés dans un format qu’un moteur d’inférence peut exécuter efficacement, comme ONNX pour la portabilité, TensorRT pour les GPU NVIDIA, OpenVINO pour le matériel Intel, ou LiteRT et Core ML pour les téléphones. La quantification du modèle et l’élagage du modèle le réduisent encore lorsque la cible est de petite taille. Le modèle exporté et son code de prétraitement sont ensuite empaquetés avec des dépendances épinglées, généralement dans un conteneur Docker qui fonctionne de la même manière sur un ordinateur portable, un serveur ou un cluster Kubernetes. Voici à quoi ressemble l’exportation d’un détecteur entraîné, suivie du chargement du fichier exporté pour une vérification rapide avant la publication :

from ultralytics import YOLO

# Load a trained model (replace with your own best.pt)
model = YOLO("yolo26n.pt")

# Export to ONNX, a portable format that many inference engines run
path = model.export(format="onnx")
print(f"Deployable model: {path}")

# Smoke-test the exported file with the same API before shipping it
onnx_model = YOLO(path)
results = onnx_model("https://ultralytics.com/images/bus.jpg")
results[0].save(filename="bus_onnx.jpg")

L’appel d’exportation renvoie le chemin du nouveau fichier yolo26n.onnx, et l’image enregistrée confirme que le fichier exporté se charge correctement et produit des détections. Les équipes comparent également la précision et la vitesse du modèle exporté à celles du modèle d’origine sur un jeu de validation, car la conversion de format et la réduction de précision peuvent légèrement modifier les sorties.

Publier de nouvelles versions du modèle#

Une nouvelle version du modèle est enregistrée dans un registre de modèles et publiée progressivement, car les métriques hors ligne ne couvrent pas toutes les conditions de production. Lors d’un déploiement en mode fantôme, le nouveau modèle reçoit une copie du trafic en direct tandis que le modèle actuel continue de répondre aux utilisateurs ; les deux peuvent ainsi être comparés sans risque. Une publication canari dirige ensuite une petite part du trafic réel vers la nouvelle version et l’augmente seulement tant que les taux d’erreur, la latence et la qualité des prédictions restent satisfaisants. Les tests A/B mesurent l’effet sur les résultats commerciaux. Garder la version précédente prête à être déployée permet de revenir en arrière en modifiant la configuration plutôt qu’en reconstruisant le système dans l’urgence :

Déploiement de modèles et notions associées#

• Entraînement de modèles : apprend les poids du modèle à partir d’un jeu de données. Le déploiement commence avec les poids obtenus.
• Service de modèles : couche d’exécution qui répond aux requêtes de prédiction. C’est l’une des composantes du déploiement, qui comprend également l’empaquetage, la publication et le suivi.
• Latence d’inférence : temps que met le modèle déployé à calculer chaque prédiction individuellement ; c’est l’une des principales exigences auxquelles un déploiement doit répondre.

Suivi après le déploiement#

Un modèle déployé se dégrade sans que cela se remarque lorsque le monde change. Le suivi du modèle surveille les indicateurs opérationnels tels que la latence, le débit, les taux d’erreur et l’utilisation du matériel, souvent à l’aide d’outils comme Prometheus et Grafana, ainsi que les statistiques des entrées et des prédictions. Lorsque le suivi signale un problème, les équipes annotent les nouveaux cas d’échec, réentraînent le modèle et soumettent la nouvelle version au même processus de publication. Les statistiques des entrées fournissent les premiers signes d’alerte : le dérive des données, c’est-à-dire une modification de la distribution des entrées, comme le déplacement d’une caméra vers un nouvel angle ou le passage à l’éclairage hivernal, apparaît plusieurs jours ou semaines avant l’arrivée des étiquettes de vérité terrain des données de production nécessaires pour mesurer la précision.