Déployez des modèles de ML en production avec mise à l'échelle automatique

Le fossé du déploiement en production : pourquoi la plupart des modèles de ML ne quittent jamais le notebook

Un modèle entraîné dans un notebook et un modèle répondant à des requêtes en direct sont des problèmes d'ingénierie différents. Le second est un environnement de déploiement avec des exigences de disponibilité, de latence et de mise à l'échelle, et c'est là que la plupart des modèles de machine learning en production stagnent.

Ce qu'il faut pour servir un modèle à grande échelle (cluster, entrée, mise à l'échelle automatique, surveillance)

La sélection et l'entraînement du modèle sont des problèmes en amont. Le chemin classique pour servir des modèles en production est un processus séparé, un processus qui nécessite un cluster, un contrôleur d'entrée, une politique de mise à l'échelle, une pile de surveillance et un pipeline de publication. Chacun est une décision nécessitant un responsable. Un data scientist ayant terminé le développement d'un modèle a désormais besoin d'un réseau de cluster, de règles d'équilibrage de charge et d'un backend de métriques avant qu'un seul utilisateur ne voie une prédiction.

La liste de contrôle : un runtime de conteneur, des règles d'entrée, des politiques de mise à l'échelle, la gestion des secrets et des données, l'expédition des journaux, des pipelines de publication, ainsi qu'une chaîne d'outils pour maintenir chacun d'eux. Chaque élément est essentiel, nécessite une responsabilité technique, et aucun de ces outils n'améliore le modèle.

Pour une petite équipe, cela représente des semaines de travail avant qu'une quelconque valeur commerciale n'apparaisse, et cela ne s'arrête pas au lancement. Le résultat est familier : le développement du modèle réussit, le déploiement stagne et l'artefact attend une infrastructure que personne n'a le temps de construire.

Pourquoi le bricolage VM + Flask + nginx échoue sous un trafic réel

Le raccourci est une machine virtuelle exécutant une application Flask derrière nginx. Cela fonctionne en test et échoue en production. Un serveur est un point de défaillance unique. L'absence de mise à l'échelle automatique signifie qu'un pic de charge met les requêtes en file d'attente jusqu'à ce que la latence soit inacceptable. L'absence de rolling release signifie que chaque nouvelle version implique un temps d'arrêt.

Cela masque également un problème de coût : l'instance fonctionne en continu, que l'endpoint serve mille requêtes par jour ou aucune, et quelqu'un doit toujours corriger l'OS et renouveler les certificats. Efficace à mettre en place, coûteux à maintenir.

Le coût caché des instances GPU inactives sur les endpoints des hyperscalers

Les endpoints d'inférence gérés sur les grands hyperscalers résolvent le problème de la disponibilité mais maintiennent l'instance de calcul en fonctionnement 24h/24. Un endpoint GPU dimensionné pour un pic en journée est toujours facturé à 3 heures du matin sans rien à servir, et le temps d'inactivité représente la majeure partie de la journée.

L'utilisation est la métrique qui compte. Un endpoint servant quelques milliers de requêtes par jour sur un GPU dimensionné pour le pic peut utiliser une petite fraction de ce qu'il paie, chaque jour, pendant des mois. Les instances GPU cloud sont pertinentes lorsque la charge est constante, mais une instance à l'heure est l'unité inadaptée pour une demande qui arrive par pics.

Facturation par réplique et par minute au lieu d'instances toujours actives

La facturation se fait par réplique et par minute. Un déploiement conservant une réplique pendant la nuit et huit à midi coûte la somme des minutes pendant lesquelles chaque réplique a fonctionné, et non huit instances pendant 24 heures. La facturation de l'autoscaling est calculée sur le nombre minimum de répliques que vous définissez, avec une capacité de pointe uniquement pendant son exécution. La prévision est simple : votre base est le minimum multiplié par le temps, tout ce qui dépasse suit la demande, et la facture logicielle conserve la forme de la courbe de charge.

Tarifs indicatifs : CPU uniquement à partir de 0,04 € par cœur et par heure pour les modèles classiques tels que scikit-learn ou XGBoost ; GPU L4 à partir de 0,91 € par réplique et par heure pour l'inférence 7B, la vision et la classification ; GPU A100 environ 1,52 € à 1,85 € pour 7B à 30B ; GPU H100 PCIe à partir de 3,10 € pour les modèles plus larges et les fenêtres de contexte longues. Confirmez les tarifs actuels sur la page de tarification.

Mise à l'échelle à zéro lorsque le trafic diminue, montée en charge lors des pics réels

La mise à l'échelle à zéro est généralement disponible : un déploiement tombe automatiquement à zéro réplique lorsqu'aucune requête ne l'appelle, et le coût d'inactivité devient nul. C'est la différence économique clé entre un point de terminaison géré évolutif et une instance fixe que vous gérez vous-même. Cela implique un compromis honnête. Le retour depuis zéro signifie un démarrage à froid pendant que le conteneur démarre et charge les poids, donc la première requête après une période d'inactivité est lente. Pour un traitement par lots ou un outil interne, c'est acceptable. Pour une application orientée utilisateur avec un budget de latence, gardez un minimum d'une réplique et acceptez le coût plancher.

Mise à l'échelle statique vs autoscaling (CPU/RAM) vs autoscaling sur métrique personnalisée

Trois stratégies de mise à l'échelle, et le choix suit la forme de votre trafic.

Sondes de préparation et mises à niveau progressives sans interruption

Une sonde de préparation est un chemin HTTP que la plateforme interroge avant d'envoyer du trafic à un réplica. C'est ainsi que vous vous assurez que le modèle est prêt : pointez-la vers votre route /health et le point de terminaison n'achemine aucune requête tant que le modèle n'est pas chargé. Sans elle, un réplica accepte une requête pendant le chargement des poids et renvoie une erreur que votre client perçoit comme une requête échouée.

Les mises à jour progressives utilisent la même vérification. Déployez une nouvelle version et appliquez la mise à jour, et les nouveaux réplicas réussissent la vérification de préparation avant que les anciens ne soient retirés. Les utilisateurs ne voient aucune requête échouée, et une version dont la sonde échoue ne reçoit jamais de trafic. Chaque version est adressable, ainsi les mises en production quotidiennes et un retour arrière d'urgence partagent un mécanisme unique.

Surveillance en temps réel du GPU, du CPU et du réseau par réplica

Le tableau de bord expose un ensemble de métriques en temps réel par réplica : une métrique GPU, une métrique mémoire et une métrique réseau, chacune limitée à un réplica plutôt que moyennée, ainsi que les journaux d'application dans le panneau de contrôle.

Cet ensemble répond à la question de savoir si le déploiement est sain, si la métrique de mise à l'échelle se déclenche et où se situe la latence. Il ne répond pas à la question de savoir si les prédictions sont toujours correctes. Pour cela, vous avez besoin d'une métrique d'application que vous définissez, la précision sur un échantillon étiqueté étant le choix habituel. Les équipes qui maintiennent des modèles en production partagent généralement un tableau de bord entre la science des données et l'ingénierie de plateforme, afin que les deux voient les mêmes chiffres. Cette fonctionnalité de surveillance est standard sur chaque application.

Étape 1 : Empaquetez le modèle dans une image Docker (ou utilisez-en une pré-construite)

La conteneurisation est un prérequis, pas une option supplémentaire. L'image de conteneur peut provenir de Docker Hub, de Managed Private Registry ou de GitHub Packages. Trois exigences comptent : créer le répertoire de travail dans le Dockerfile, cibler linux/amd64 et servir sur le port 8080 à moins d'en déclarer un autre explicitement, comme le fait vLLM sur le port 8000.

Les équipes sans expertise en conteneurs peuvent commencer avec le catalogue d'images pré-construites d'OVHcloud avec PyTorch, TensorFlow, HuggingFace ou FastAI déjà installés. Cela réduit le travail ; cela ne supprime pas l'exigence. Déployer l'apprentissage automatique de cette manière est une valeur par défaut efficace pour la plupart des applications, et déployer des modèles de ML directement à partir d'une image du catalogue est encore plus rapide, et l'expérience de maintenir sa propre couche de base en vaut rarement la peine au début.

Étape 2 : Configurez les ressources, la mise à l'échelle et l'accès via le panneau de contrôle, l'API ou l'interface de ligne de commande ovhai

Créez le déploiement depuis le panneau de contrôle, l'API ou l'interface en ligne de commande ovhai. Choisissez vos ressources de calcul, définissez la stratégie de mise à l'échelle, pointez la sonde de préparation vers votre chemin et port de santé, puis définissez comment le point de terminaison est atteint.

Lors de l'accès, une règle : un point de terminaison public est réservé aux tests uniquement. Les déploiements en production utilisent un accès restreint, avec des identifiants utilisateur AI Platform ou un jeton, et des politiques d'accès que vous gérez vous-même. Chaque point de terminaison se trouve également derrière une protection DDoS native, et chaque point de terminaison conserve ses propres identifiants.

ovhai app run --gpu 1 --default-http-port 8080 \
  --probe-path /health \
  --unsecure-http false \
  my-registry/my-model-server:v2

Étape 3 : Choisissez la stratégie de mise à l'échelle adaptée à votre modèle de trafic

Adaptez la politique à la charge de travail. Scoring interne stable : statique, une ou deux répliques, une valeur par défaut efficace pour les applications internes et les outils à faible volume. Une API orientée client avec des pics quotidiens : mise à l'échelle automatique sur une métrique d'utilisation, minimum une réplique pour éviter les démarrages à froid. Scoring par lots occasionnel : mise à l'échelle automatique avec réduction à zéro. Le travail par lots est le domaine où cette décision est la plus facile, car personne ne regarde une barre de progression. Chaque exécution par lots est un coût que vous avez déjà évalué.

Définissez le maximum délibérément. Cela plafonne le débit et la facture en même temps, et le plafond est de 10 répliques par application.

Étape 4 : Surveillez l'inférence avec le tableau de bord et l'architecture de référence MKS.

Commencez par le tableau de bord intégré pour les métriques de ressources et les journaux. Pour les percentiles de latence, le débit ou la précision au niveau du modèle, ajoutez une pile externe : Service Kubernetes géré exécutant Prometheus et Grafana, récupérant les données de votre point de terminaison. OVHcloud publie ceci en tant qu'architecture de référence.

Deux choses à surveiller en continu : les signaux d'infrastructure qui vous indiquent si la mise à l'échelle fonctionne, et la performance du modèle en production, qui vous indique si le modèle fait toujours son travail. La surveillance de la performance sur le second point est ce qui permet de détecter une régression silencieuse, et les métriques de performance issues d'un jeu de données d'entraînement ne vous en avertiront pas. La dérive apparaît dans le second bien avant le premier. Exportez une semaine de métriques en ligne vers un fichier avant d'optimiser un seuil, en vous assurant que le changement suit la charge observée. Définissez une alerte sur chacun pour vous assurer qu'une régression soit détectée par vos propres analyses plutôt que par un client, assurez-vous que le seuil est basé sur une référence réelle, et assurez-vous qu'il a un responsable.

Étape 5 : Déployez une nouvelle version avec une mise à jour progressive sans temps d'arrêt.

Construisez et poussez la nouvelle version, puis exécutez ovhai app update ou appliquez le changement depuis le Panneau de contrôle. La plateforme démarre de nouvelles répliques, attend la disponibilité, bascule le trafic et retire les anciennes. Aucun temps d'arrêt, aucune fenêtre de maintenance.

Le Dockerfile est du code : conservez-le dans le contrôle de version et maintenez la base à jour, car une couche de base obsolète est une cause fréquente d'échec de déploiement. Utilisez des tags versionnés plutôt que de réutiliser latest. Le contrôle de version sur chaque version est ce qui fait d'un retour en arrière une opération à une seule commande au lieu d'une investigation.

Pourquoi le CPU/RAM est un mauvais indicateur de la charge LLM.

L'inférence en deep learning est une charge de travail computationnelle avec une file d'attente, et non une boucle liée au CPU, donc la pratique standard de mise à l'échelle basée sur le matériel échoue. Un serveur LLM traite les requêtes simultanées par lots sur le GPU. L'utilisation du CPU reste faible pendant que la file d'attente augmente, donc ce seuil se déclenche tardivement ou jamais. Le signal qui vous importe est le nombre de requêtes en cours, et une métrique matérielle ne peut pas le voir.

Mise à l'échelle sur vllm:num_requests_running avec Prometheus et Grafana sur MKS

vLLM expose vllm:num_requests_running sur son point de terminaison de métriques. Récupérez-la avec Prometheus et effectuez une mise à l'échelle automatique sur cette valeur plutôt que sur un proxy matériel. Les réplicas arrivent lorsque la concurrence réelle augmente et partent lorsque la file d'attente se vide, maintenant la latence dans le budget sans surprovisionnement.

Généralement disponible et documenté en tant qu'architecture de référence. Cela nécessite Prometheus et Grafana en plus de votre déploiement, considérez donc cela comme une approche avancée, et non par défaut.

Temps de configuration, coût d'inactivité et expertise opérationnelle

L'autogestion de l'inférence implique le provisionnement du cluster, des pools de nœuds, d'un contrôleur d'entrée et d'un autoscaler horizontal, ce qui prend généralement une à deux semaines, en plus de l'expertise DevOps et MLOps nécessaire pour le maintenir en fonctionnement. Vous êtes responsable des politiques de mise à l'échelle, des pipelines de déploiement, des fichiers manifestes et des stratégies de surveillance, et vous le restez après le lancement. Les meilleures pratiques du secteur sont documentées et les outils sont matures, mais dans ce domaine, une pratique documentée ne constitue pas un système opérationnel robuste. Le nœud GPU fonctionne généralement en continu, même en l'absence de trafic.

AI Deploy nécessite une image et une commande. La configuration prend moins d'une heure, une expertise MLOps suffit et la mise à l'échelle à zéro supprime entièrement les coûts d'inactivité.

Les prix et les chiffres sont indicatifs. Confirmez les tarifs en vigueur sur la page de tarification d'OVHcloud avant toute publication.

Aucune exposition au CLOUD Act sur les données d'inférence

Les données d'entraînement ne sont pas les seules données sensibles. Chaque requête vers un point de terminaison de production contient des données utilisateur ou professionnelles, chaque requête est journalisée quelque part, chaque requête est une entrée que vous n'avez pas choisie, et le trafic du point de terminaison est continu plutôt qu'un transfert ponctuel. Si le point de terminaison s'exécute chez un fournisseur dont le siège est aux États-Unis, ces données relèvent de la juridiction américaine, quelle que soit la région qui les héberge.

OVHcloud est européen, sans société mère américaine et sans exposition structurelle au CLOUD Act. Les données d'inférence restent sous juridiction européenne, conformément au droit européen.

RGPD, HDS et ISO 27701 pour les charges de travail réglementées

OVHcloud détient les certifications ISO 27001, ISO 27017, ISO 27018 et ISO 27701, est certifié SOC 2 et détient la certification HDS pour les données de santé en France, pertinente pour l'inférence médicale. Le traitement au sein de l'UE simplifie une analyse d'impact relative à la protection des données (AIPD), et les engagements de confidentialité des données que vous avez pris envers vos propres utilisateurs deviennent plus simples à justifier. Le support peut répondre à une question de confidentialité sans escalade.

Une limite à énoncer clairement : AI Deploy fournit une infrastructure de service souveraine. Les obligations liées à l'IA Act européen au niveau du modèle, les fiches de modèle, les journaux d'audit et la détection des biais restent de votre responsabilité en tant que développeur du système. L'infrastructure souveraine facilite la conformité ; elle ne la garantit pas.