Rentabilisez chaque heure de GPU : suivi de la progression dans Red Hat OpenShift AI

Nous sommes un vendredi soir. Priya, ingénieure en apprentissage automatique (ML) au sein d'une entreprise de services financiers, met en file d'attente une tâche de réglage fin pour la détection des fraudes sur un cluster GPU coûtant 55 USD par heure. L'exécution devrait prendre environ 40 heures, soit environ 2 200 USD de ressources de calcul. Elle revérifie les hyperparamètres, soumet la tâche et rentre chez elle pour le week-end.

Lundi matin, elle ouvre son ordinateur portable. Le modèle avait cessé d'apprendre au cours de la nuit de vendredi, mais la tâche a continué à s'exécuter, consommant deux jours complets de temps GPU pour un entraînement qui n'aboutissait à rien. Cela représente plus de 1 500 USD de gaspillage de ressources de calcul, et elle doit recommencer.

Si cette situation vous semble familière, vous n'êtes pas seul. Chaque spécialiste ayant exécuté une tâche d'entraînement de plusieurs jours connaît ces questions embarrassantes :

• Le modèle apprend-il réellement quelque chose ?
• Devrais-je arrêter la tâche prématurément et essayer d'autres hyperparamètres ?
• Se terminera-t-elle avant la revue avec les parties prenantes de mardi ?

Le coût de cette ignorance est bien réel. Les clusters GPU à la demande peuvent coûter plus de 50 USD par heure. Une seule exécution d'entraînement de plusieurs jours peut facilement coûter des milliers de dollars, et une exécution mal configurée peut gaspiller tout un week-end de ressources de calcul avant que quelqu'un ne s'en aperçoive. Dans les clusters partagés, l'impact se multiplie : une tâche bloquée ne gaspille pas seulement le budget d'une équipe, elle empêche également d'autres équipes d'accéder aux GPU dont elles ont besoin. L'exécution à l'aveugle d'une équipe entraîne du retard pour une autre. Le problème n'est pas que les équipes manquent de rigueur. C'est qu'elles travaillent à l'aveugle. Chaque heure de GPU compte, et sans visibilité en temps réel sur la progression de l'entraînement, trop d'entre elles sont gaspillées.

Le déficit d'observabilité

Voici une vérité dérangeante : du point de vue de la plateforme, une tâche d'entraînement qui converge parfaitement et une autre complètement bloquée semblent identiques. Dans les deux cas, il s'agit de pods à l'état running qui consomment les mêmes ressources et affichent le même indicateur d'état vert. Kubernetes n'a aucun moyen de savoir si votre modèle apprend.

Aujourd'hui, surveiller la progression de l'entraînement est possible, mais c'est plus difficile que cela ne devrait l'être.

• Les journaux sont dispersés et difficiles à utiliser : Dans une tâche d'entraînement distribuée, les journaux sont répartis sur plusieurs pods. La recherche de la sortie pertinente implique de savoir quel pod examiner, comment y accéder et comment interpréter les formats de journaux spécifiques à chaque framework. Cela nécessite une expertise en Kubernetes, un ensemble de compétences supplémentaires que la plupart des data scientists et des ingénieurs en IA ne devraient pas avoir à acquérir simplement pour surveiller leurs exécutions d'entraînement. Les journaux de mauvaise qualité et non structurés ne sont pas facilement lisibles par les machines, ils ne peuvent donc pas servir de base à l'automatisation.
• Les outils externes résolvent les problèmes d'observabilité, mais ajoutent des frais de gestion : Les plateformes de suivi d'expériences comme MLflow et Weights & Biases sont excellentes dans leur domaine. Cependant, elles nécessitent une infrastructure supplémentaire pour le déploiement et la maintenance, des clés d'API et des contrôles d'accès pour la gestion, et elles fonctionnent au-dessus de la couche plateforme. Elles sont également déconnectées de l'API Kubernetes, ce qui rend plus difficile leur intégration à des workflows natifs Kubernetes et à des opérateurs personnalisés. Elles vous indiquent ce qui se passe dans la boucle d'entraînement, mais ne peuvent pas en informer la plateforme.
• Chaque framework procède différemment : PyTorch DDP, FSDP, DeepSpeed, JAX, chacun possède ses propres conventions de journalisation, ses propres formats de métriques et sa propre façon de signaler la progression. L'absence de cohérence entre les frameworks empêche les équipes de plateforme gérant un environnement d'entraînement hétérogène de disposer d'une vue unifiée.
• Il n'existe pas d'API standard : Jusqu'à présent, les tâches d'entraînement n'avaient aucun moyen standardisé de signaler leur progression à la plateforme. Par conséquent, les administrateurs de plateforme qui gèrent des clusters GPU partagés doivent deviner quelles tâches progressent, lesquelles sont bloquées et lesquelles sont sur le point de se terminer. Sans cette visibilité, la planification de la capacité et le dépannage relèvent de la conjecture.

Combler le fossé : suivi de la progression dans Red Hat OpenShift AI

Red Hat OpenShift AI inclut désormais un suivi de la progression prêt pour la production pour les tâches d'entraînement distribuées, intégré à Kubeflow Trainer v2 et disponible à grande échelle à partir de Red Hat OpenShift AI 3.4. Vous pouvez voir ce qui se passe en temps réel et agir avant qu'il ne soit trop tard. Cette fonctionnalité comble directement le déficit d'observabilité en offrant aux data scientists, aux ingénieurs ML et aux administrateurs de plateforme une visibilité en temps réel sur les performances des tâches d'entraînement.

Cette visibilité repose sur trois piliers :

1. Visualisation dans le tableau de bord : Les métriques de progression en temps réel sont visibles directement dans le tableau de bord Red Hat OpenShift AI. En un coup d'œil, vous pouvez visualiser le pourcentage de progression, l'étape actuelle et le nombre total d'étapes, l'époque actuelle, le temps restant estimé, la perte d'entraînement ainsi que les métriques d'évaluation de vos TrainJobs. Aucun outil distinct, aucune configuration supplémentaire.
2. Intégration du SDK : Les mêmes données de progression sont disponibles par programmation via le SDK Kubeflow. Cela permet aux équipes de créer des pipelines automatisés qui réagissent à la progression de l'entraînement, en déclenchant un arrêt précoce, en envoyant des notifications ou en réallouant des ressources selon les métriques en temps réel.
3. Cohérence entre les frameworks : Le suivi de la progression fonctionne de la même manière, que vous utilisiez PyTorch DDP, FSDP, DeepSpeed ou JAX. Il prend également en charge le code d'entraînement personnalisé via l'API CustomTrainer. Cela offre une expérience unifiée quel que soit le framework utilisé.

Visualiser vos entraînements en cours

La meilleure façon de comprendre le suivi de la progression est de découvrir concrètement comment il s'utilise. Trois étapes sont essentielles.

1. Démarrez votre tâche d'entraînement : Vous soumettez une tâche d'entraînement depuis un notebook à l'aide du SDK Kubeflow, exactement comme vous le feriez aujourd'hui. Si vous utilisez HuggingFace Transformers, le suivi de la progression est automatique, sans aucune modification de code. L'intégration détecte l'environnement Kubeflow et commence à signaler les métriques de votre boucle d'entraînement.
2. Surveillez sa progression : À mesure que l'entraînement s'exécute, des métriques en temps réel apparaissent dans le tableau de bord Red Hat OpenShift AI : pourcentage de progression, estimation du temps restant, étapes terminées, époques, norme de gradient, perte d'entraînement et taux d'apprentissage. Plus besoin de suivre les journaux, de se connecter aux pods par SSH ou de configurer des outils externes.

Figure 1 : Le tableau de bord Red Hat OpenShift AI affiche une liste de tâches avec une barre de progression indiquant 40 % d'achèvement pour une TrainJob en cours.

Figure 2  :  Un panneau latéral détaillé affiche la progression de la tâche et les métriques en temps réel.

3. Agissez en fonction de ce que vous voyez : C'est ici que le suivi de la progression vous permet réellement de gagner du temps et d'économiser des ressources de calcul. Vous remarquez que la perte ne s'améliore pas ? Arrêtez la tâche prématurément pour économiser des heures de temps GPU. Une exécution converge plus vite que prévu ? Libérez des ressources pour vos collègues. Sachez exactement quand une tâche se terminera pour mieux vous organiser : vous n'aurez plus à deviner si les résultats seront prêts pour la revue avec les parties prenantes de mardi.

Les caractéristiques clés qui rendent cette fonctionnalité pratique :

• Aucune configuration : Aucune infrastructure supplémentaire, aucune dépendance externe, aucune configuration additionnelle. Le suivi de la progression est prêt à l'emploi.
• Un impact minimal sur les ressources : Les métriques sont signalées aux points de contrôle naturels de l'entraînement sans en affecter les performances.
• Compatibilité avec tous les frameworks : Que vous utilisiez PyTorch DDP, FSDP, DeepSpeed, JAX ou du code d'entraînement personnalisé, l'expérience reste la même.

À qui profite cette fonctionnalité ?

Les data scientists et les ingénieurs ML/IA visualisent en temps réel la perte d'entraînement, le pourcentage de progression et l'ETA sans avoir à se connecter aux pods par SSH ou à suivre les journaux. La détection précoce d'une divergence ou d'un arrêt de l'entraînement (par exemple, repérer une tâche bloquée le samedi matin plutôt que le lundi) permet d'économiser des heures de temps GPU. Comparez les exécutions d'entraînement en un clin d'œil depuis le tableau de bord pour identifier rapidement la configuration d'hyperparamètres la plus performante.

Les administrateurs de plateforme disposent d'une vue unique sur le tableau de bord pour toutes les tâches d'entraînement du cluster. Ils visualisent des métriques cohérentes, que la tâche utilise DDP, FSDP ou DeepSpeed, et prennent de meilleures décisions de planification de la capacité en identifiant les tâches qui progressent, celles qui sont bloquées et celles qui sont presque terminées.

Dans les environnements GPU multi-tenants où plusieurs équipes partagent le même cluster, cette visibilité favorise directement une meilleure utilisation des ressources et un meilleur retour sur investissement (ROI). Pour les organisations qui mettent en place un modèle de GPU-as-a-Service, le suivi de la progression comble une lacune critique, transformant la « boîte noire de l'utilisation des GPU » en un système observable et gérable. En fin de compte, cela permet aux équipes de plateforme d'éliminer les goulots d'étranglement de l'infrastructure et de fournir en toute confiance aux data scientists les ressources nécessaires pour accélérer l'innovation en IA.

Au-delà de la surveillance : Établir les bases d'un entraînement plus intelligent

Le suivi de la progression est plus qu'une simple fonctionnalité de surveillance, c'est un fondement. Dès lors que la plateforme a accès aux données de progression de l'entraînement en temps réel, toute une série de comportements plus intelligents devient possible. Bien que ces capacités avancées ne constituent pas encore des engagements produits de Red Hat, le socle est en place. La communauté Kubeflow Trainer en amont explore activement plusieurs pistes :

• Optimisation intelligente des hyperparamètres : Aujourd'hui, les moteurs d'optimisation d'hyperparamètres comme Katib s'appuient sur l'analyse de journaux avec des modèles regex fragiles pour évaluer les performances des essais. Avec les métriques d'entraînement disponibles directement dans l'API Kubernetes, Katib peut lire l'état de l'entraînement de manière native, ce qui permet une intégration plus étroite et une orchestration plus efficace des essais. Il s'agit du KEP en cours de discussion au sein de la communauté en amont.
• Mise à l'échelle élastique : La vitesse de convergence et les données ETA pourraient éclairer les décisions de mise à l'échelle. Un modèle qui converge rapidement pourrait libérer des GPU pour d'autres équipes, tandis qu'un modèle qui plafonne pourrait demander des ressources supplémentaires. La communauté en amont explore la prise en charge élastique de PyTorch dans TrainJob pour rendre cela possible.
• Visibilité de la progression via l'interface en ligne de commande (CLI) : la commande kubectl get trainjob avec une colonne PROGRESS % intégrée permettrait d'afficher la progression de l'entraînement directement dans la ligne de commande, offrant aux opérateurs une visibilité instantanée sans recourir au tableau de bord ou au SDK.
• Création de points de contrôle (checkpointing) plus intelligente : Bien que OpenShift AI prenne déjà en charge la création de points de contrôle périodiques et juste-à-temps pour les modèles, la disponibilité de l'ETA et des données de progression permettrait à la plateforme de prendre des décisions plus intelligentes sur le moment opportun pour créer un point de contrôle, par exemple en enregistrant l'état automatiquement en fonction de l'ETA de la tâche. La communauté en amont explore la création de points de contrôle GPU transparents avec CRIU pour améliorer la tolérance aux pannes et la résilience de TrainJob.

Ces domaines font l'objet d'une exploration active dans le projet Kubeflow. Bien qu'il ne s'agisse pas d'engagements produits, ils illustrent pourquoi le suivi de la progression est important au-delà de la fonctionnalité immédiate : il crée la couche de données sur laquelle toute la pile d'entraînement peut s'appuyer.

Le suivi de la progression pour l'entraînement distribué est disponible à grande échelle dans Red Hat OpenShift AI 3.4. Pour plus d'informations, consultez la documentation de Red Hat OpenShift AI. Vous pouvez également en faire l'expérience par vous-même en commençant un essai de 60 jours de Red Hat OpenShift AI.