MLOps côté ops : registre, artefacts et scheduling GPU

La demande arrive presque toujours sous la même forme : l'équipe data a besoin d'un serveur avec un GPU. On le provisionne, ça tourne, tout le monde est content. Six mois plus tard, la même équipe a produit quarante modèles de classification, personne ne sait lequel tourne en production, le disque du serveur est plein de fichiers model_final_v3_ok.pkl, et le data scientist qui a entraîné le modèle de scoring est parti.

C'est à ce moment-là qu'on appelle les ops. Et à ce moment-là, le problème n'est plus matériel, il est de plateforme.

Le papier de référence sur le sujet a onze ans et n'a pas pris une ride. Sculley et ses coauteurs, chez Google, montraient dès 2015 que la boîte de code réellement consacrée à l'apprentissage ne représente qu'une fraction minuscule d'un système ML en production. Tout le reste, c'est de la collecte, de la configuration, de la glue, du service, du monitoring. La dette technique ne vit pas dans le modèle, elle vit autour.

Côté ops, ça se traduit par une règle simple : ce qu'on doit être capable de reconstruire, ce n'est pas un fichier de poids, c'est la chaîne complète qui l'a produit. Le jeu de données à un instant T, le code de préparation, les hyperparamètres, la version du framework, l'image du conteneur, le matériel. Si un seul maillon manque, le modèle en production est une boîte noire qu'on ne peut ni auditer ni reproduire. Et un modèle qu'on ne peut pas reproduire, on ne peut pas non plus le corriger quand il se met à dériver.

Le piège classique, c'est de croire que Git suffit. Git versionne le code, pas les 400 Go de parquet qui ont servi à l'entraînement, ni le checkpoint de 12 Go qui en sort. Il faut un endroit pour les métadonnées, un endroit pour les octets, et un lien immuable entre les deux.

MLflow est le standard de fait sur ce créneau. Son Model Registry est un store centralisé qui porte le lignage (quelle expérience, quel run a produit ce modèle), les versions, les alias et les tags. Une nouvelle entrée démarre en version 1, chaque enregistrement suivant incrémente automatiquement. C'est le point d'entrée unique qu'on cherche : plus de model_final_v3_ok.pkl.

Là où les équipes se plantent, c'est sur l'installation. Un mlflow ui lancé sur le poste d'un data scientist utilise un backend SQLite et un répertoire local. Ça marche en démo, ça ne survit pas à deux personnes. Un déploiement sérieux exige deux briques distinctes que les ops doivent opérer :

• Un backend store relationnel pour les métadonnées, runs, paramètres, métriques, versions de modèles. En pratique, PostgreSQL. C'est une base transactionnelle classique, avec les mêmes exigences que n'importe quelle base de production : sauvegarde, restauration testée, supervision de la réplication.
• Un artifact store objet pour les octets, poids, checkpoints, matrices de confusion, artefacts de run. En pratique, du S3-compatible.

Ces deux briques n'ont ni le même profil de charge ni le même profil de sauvegarde, et c'est exactement pour ça qu'il ne faut pas les héberger sur le même volume. La base pèse quelques gigaoctets et se sauvegarde toutes les heures. L'artifact store pèse plusieurs téraoctets et se sauvegarde par politique de rétention.

Deuxième point à connaître, parce qu'il casse les procédures écrites il y a trois ans : les stages MLflow (Staging, Production, Archived) sont dépréciés au profit des alias. Un alias est une référence mutable vers une version précise. On pose champion sur la version 17, le service d'inférence charge models:/scoring-risque@champion, et un rollback consiste à repointer l'alias sur la version 16. Aucun redéploiement, aucune modification de configuration applicative. C'est la mécanique la plus proche d'un tag de conteneur mobile, et elle mérite le même traitement : qui a le droit de bouger l'alias, et est-ce que ce mouvement est tracé.

C'est le poste que personne ne budgète et qui finit par coûter le plus cher. Un entraînement qui sauvegarde un checkpoint toutes les 500 itérations, sur un modèle de 2 Go, sur une campagne de 200 runs, produit très vite plusieurs téraoctets d'objets dont 95 % ne seront jamais relus.

L'approche qu'on applique est celle de n'importe quel bucket de production. Un backend S3-compatible qu'on maîtrise, MinIO déployé sur Kubernetes ou une alternative distribuée, avec les garde-fous habituels : versioning activé, chiffrement au repos, et surtout une politique de cycle de vie qui bascule ou supprime automatiquement les objets selon leur âge et leur préfixe. Les checkpoints intermédiaires d'un run terminé n'ont aucune raison de rester en stockage chaud plus de trente jours.

Trois règles de terrain sur ce bucket :

1. Séparer les préfixes par nature. runs/ pour les artefacts d'expérimentation, jetables et soumis à lifecycle agressif. models/ pour les versions enregistrées dans le registre, immuables et sauvegardées. Une seule politique de rétention pour les deux, et vous supprimez soit trop, soit rien.
2. Interdire l'écriture directe au registre. MLflow sait servir de proxy vers l'artifact store, ce qui évite de distribuer des credentials S3 à chaque poste de data scientist. C'est le même raisonnement que pour un registre de conteneurs avec Harbor : on ne donne pas les clés du stockage, on donne un accès au service qui l'encapsule.
3. Mesurer avant de dimensionner. Un mois de production réelle donne un volume mensuel exploitable. Extrapoler à partir d'un run de test donne un chiffre faux d'un facteur dix.

Un pipeline reproductible, ça se prouve. Le test qu'on fait passer aux équipes : prendre une version de modèle enregistrée il y a quatre mois, relancer son entraînement à partir des seules informations du registre, et comparer les métriques. Si l'écart dépasse le bruit statistique, le pipeline n'est pas reproductible, quoi qu'en dise la documentation interne.

Ce qui fait échouer ce test, dans l'ordre de fréquence constatée :

• L'image de conteneur non pinnée. Un FROM pytorch/pytorch:latest dans le Dockerfile d'entraînement, et le résultat dépend de la date du build. Toujours un digest, jamais un tag mobile.
• Les données non versionnées. Le modèle a été entraîné sur une table qui a été mise à jour depuis. Il faut un snapshot immuable du dataset, référencé par son hash, ou au minimum une requête horodatée sur une source append-only.
• Le non-déterminisme GPU. Certaines opérations CUDA ne sont pas déterministes par défaut. Fixer les seeds ne suffit pas, il faut activer explicitement les modes déterministes du framework, et accepter la pénalité de performance qui va avec.

Côté outillage, l'entraînement doit se déclencher depuis la même chaîne que le reste : un pipeline GitLab CI qui pousse des jobs sur Kubernetes, avec l'image buildée et signée en amont. Un entraînement lancé à la main dans un tmux sur un serveur GPU n'est pas un pipeline, c'est un incident en attente.

Le GPU est la ressource la plus chère du cluster et la plus mal exploitée. Un data scientist qui réserve une carte pour un notebook de préparation de données la garde huit heures et l'utilise trois minutes. Trois options existent, avec des propriétés très différentes.

Découper la carte elle-même (time-slicing best-effort ou MIG avec isolation matérielle réelle) est une question de device plugin Kubernetes, pas de pipeline MLOps : le détail des deux mécanismes, leurs pièges respectifs et les cas où choisir l'un plutôt que l'autre sont traités dans notre guide dédié au partage de GPU sous Kubernetes. Ce qui relève vraiment du MLOps, c'est ce qui se passe au-dessus du découpage matériel.

La file d'attente est la brique que la plupart des clusters oublient. Kueue s'intercale en amont du scheduler Kubernetes, garde les jobs suspendus tant que la capacité n'est pas disponible, et gère les quotas par équipe avec emprunt entre cohortes. Surtout, il fait du gang scheduling : un entraînement distribué qui demande huit GPU ne démarre que quand les huit sont réservables simultanément. Sans ça, un job qui a obtenu cinq cartes sur huit les immobilise en attendant les trois autres, pendant qu'un autre job attend. C'est le mécanisme le plus rentable de toute la stack, et il s'applique par-dessus MIG ou le time-slicing, pas à leur place.

La règle qu'on applique : Kueue systématiquement dès qu'il y a plus d'une équipe sur le cluster, quel que soit le mode de partage GPU choisi par ailleurs. Le choix des cartes elles-mêmes, la densité par rack et le refroidissement relèvent d'un autre chantier, traité dans notre guide de dimensionnement d'une infrastructure GPU, et si l'entraînement passe par de la virtualisation, le GPU passthrough sous Proxmox impose ses propres contraintes.

Trois modes de défaillance reviennent, et aucun n'est un problème de modèle.

La dérive silencieuse. Le modèle continue de répondre, avec des scores de confiance qui ont l'air normaux, mais la distribution des données d'entrée a bougé. Sans supervision des features en entrée, personne ne le voit avant que le métier ne remonte des décisions absurdes. Il faut instrumenter la distribution des entrées comme on instrumente une latence : des métriques, des seuils, des alertes.

Le modèle orphelin. Le service d'inférence charge un fichier depuis un chemin qui n'existe plus dans le registre, ou pointe une version supprimée par un ménage trop zélé. Un artifact store sans versioning et sans immuabilité sur le préfixe models/ transforme un mc rm malheureux en incident de production.

Le stockage qui étrangle le calcul. Des GPU à 700 W qui attendent des données sur un NFS saturé, c'est du budget brûlé en chaleur. Le débit vers le dataset doit être dimensionné en même temps que le calcul, pas après.

Une plateforme MLOps, c'est une base de données, un stockage objet, un ordonnanceur et une chaîne CI. Aucune de ces briques n'est spécifique à l'apprentissage automatique, et c'est précisément la bonne nouvelle : ce sont des objets d'exploitation classiques, qui se sauvegardent, se supervisent et se restaurent avec les méthodes existantes. Si vos data scientists entraînent des modèles sur des serveurs qu'ils administrent eux-mêmes, on peut reprendre la plateforme et l'opérer : registre, stockage objet avec rétention, ordonnancement GPU et supervision, sur les infrastructures que nous opérons dans le DC Fullsave de Toulouse et le site TDF de Bordeaux.

• MLflow Model Registry : documentation officielle sur le lignage, les versions, les alias et la dépréciation des stages.
• Hidden Technical Debt in Machine Learning Systems : papier NeurIPS 2015 de Sculley et al., référence sur la part réelle du code d'apprentissage dans un système ML.
• Kueue, Kubernetes-native Job Queueing : projet Kubernetes SIG, files d'attente, quotas par cohorte et gang scheduling pour les workloads d'entraînement.
• Improve GPU utilization with Kueue : retour Red Hat sur le gang scheduling et l'immobilisation de GPU par des jobs partiellement admis.