Vertex Pipelines - Vertex AI vs AI Platform
Récemment, Google a dévoilé sa dernière offre d'outils ML sur sa Google Cloud Platform, Vertex AI. En bref, la nouvelle plateforme cherche à combiner les outils offerts précédemment par des services distincts sur GCP, tels que AI Platform et AutoML, en un seul service. L'intégration de ces services auparavant séparés apporte des avantages aux utilisateurs en leur donnant la possibilité d'interagir avec tous ces outils en utilisant un seul ensemble d'API, de SDK et de clients.
Pour un aperçu plus détaillé des objectifs et des caractéristiques de Vertex AI dans son ensemble, consultez ce précédent billet de blog du ML6. Dans cet article de blog, nous nous concentrerons principalement sur la réponse de Vertex AI aux pipelines de la plateforme d'IA, Vertex Pipelines. Les technologies ML Pipeline telles que Vertex Pipelines sont importantes pour toute équipe MLOps, car elles permettent d'orchestrer les nombreux éléments mobiles des tâches complexes de formation et de prédiction à l'échelle. Elles constituent un élément clé de l'infrastructure qui permet d'intégrer les capacités d'apprentissage automatique dans un environnement de production.
Pipelines de la plateforme d'IA
Auparavant, dans AI Platform, l'ancienne plateforme d'apprentissage automatique de Google, nous avions AI Platform Pipelines. Il s'agissait d'un service visant à faciliter le déploiement de pipelines Kubeflow, la boîte à outils de pipelines MLOps de Kubeflow, sur les ressources de Google Cloud Platform. Le flux de travail pour déployer un pipeline Kubeflow avec AI Platform ressemblait à peu près à ce qui suit ;
1. Configurer un cluster Kubernetes avec le moteur Kubernetes de Google
La première étape du déploiement de Pipelines sur AI Platform a été la mise en place d'un cluster sur lequel sera hébergé notre client Kubeflow Pipelines. Bien que ML6 conseille toujours à ses clients d'automatiser leur infrastructure à l'aide d'outils tels que Terraform, le provisionnement d'un cluster avec GKE a été très facile grâce aux interfaces utilisateur soignées de la console GKE.
2. Déployer le client Kubeflow sur le cluster GKE
Une fois notre cluster opérationnel, nous avons pu déployer facilement des instances Kubeflow Pipelines à l'aide de l'interface utilisateur AI Platform Pipelines de la console GCP. Pour créer un nouveau déploiement, il suffisait de sélectionner votre cluster GKE dans une liste déroulante et de remplir quelques éléments de configuration dans un formulaire simple. Le comportement par défaut était d'utiliser les nœuds du cluster Kubernetes pour héberger les services MySQL et MinIO, la valeur par défaut de Kubeflow pour le stockage des artefacts et des métadonnées, mais en fournissant les détails de connexion dans la configuration, GCS et Cloud Storage peuvent être utilisés comme des alternatives plus évolutives et fiables.
3. Développer des pipelines avec les Notebooks
Une fois le cluster configuré et l'instance Kubeflow créée, nous avons pu utiliser les Notebooks d'AI Platform comme environnements de développement sécurisés pour travailler avec le Kubeflow Pipelines SDK afin de développer nos pipelines. Dans AI Platform, nous utilisons simplement les outils vanilla Kubeflow Pipelines sur des ressources GCP, de sorte que toutes les fonctionnalités standard du Kubeflow SDK fonctionnent exactement comme si vous lanciez une instance Kubeflow Pipelines sur un cluster Kubernetes sur site.
4. Gérer les pipelines et les cycles dans l'interface client de Kubeflow
Les pipelines développés pourraient ensuite être téléchargés vers le client Kubeflow, où vous pourriez voir tous les pipelines précédemment téléchargés, lancer des exécutions de ces pipelines, et voir le DAG et les sorties des exécutions de pipelines en cours et terminées. Les pipelines peuvent également être téléchargés et les exécutions lancées/suivies via l'API du client Kubeflow en utilisant les fonctions définies dans le SDK python.
Ce flux de travail a permis de travailler très facilement avec les pipelines Kubeflow dans les ressources Google, le déploiement prenant 5 minutes (si vous n'incluez pas le temps nécessaire à GCP pour faire tourner les ressources en arrière-plan). Grâce à GKE, la gestion des clusters Kubernetes n'a jamais été aussi simple, et grâce à AI Platform Pipelines, le déploiement d'instances Kubeflow sur ces clusters était encore plus facile ! Malgré cela, les équipes ML devaient toujours avoir des compétences en matière de Kubernetes afin de prendre des décisions éclairées, de configurer correctement leur cluster et, plus généralement, d'utiliser au mieux les pipelines AI Platform et le cluster GKE sur lequel ils seraient déployés.
Vertex AI & Vertex Pipelines
L'une des premières choses que l'on peut remarquer en passant des AI Platform Pipelines aux Vertex Pipelines, c'est que cette extrapolation de la gestion des ressources à l'extérieur de l'utilisateur s'est poursuivie, entraînant la réduction habituelle des tracas quotidiens liés à la gestion des fichiers de configuration.
Un grand indicateur de cela est que les utilisateurs ne sont plus tenus de créer un cluster Kubernetes dédié via GKE sur lequel ils peuvent exécuter leurs pipelines. Au lieu de cela, Vertex AI utilise une approche apparemment sans serveur pour exécuter les pipelines écrits avec le DSL Kubeflow Pipelines. Les clusters Kubernetes et les pods qui y sont exécutés sont gérés en coulisse par Vertex AI.
La capture d'écran ci-dessous, qui montre l'interface utilisateur de Vertex Pipelines, vous donne une idée de cette approche. Au lieu d'un magasin de pipelines et d'exécutions historiques, comme vous le savez peut-être si vous avez déjà utilisé l'interface utilisateur de Kubeflow Pipelines, nous avons simplement une liste d'exécutions historiques. Les exécutions peuvent être lancées en téléchargeant un Job Spec compilé à partir d'un script de pipeline, soit via l'interface utilisateur, soit via le client Python. Ici, nous commençons à avoir une idée de l'approche "pipelines en tant que service" que Vertex Pipelines semble viser.
Cela laisse également entrevoir une autre différence conceptuelle clé entre les deux outils : Vertex AI n'exécute pas une instance d'un client Kubeflow. Au lieu de cela, Vertex Pipelines est sa propre version du type d'infrastructure généralement fournie par Kubeflow Pipelines (c'est-à-dire Container Workflow Orchestration), qui peut exécuter des pipelines spécifiés à l'aide du Kubeflow SDK.
L'un des principaux avantages de cette nouvelle approche est que Vertex Pipelines fait un usage intensif de GCS pour le stockage des artefacts en mode natif, et utilise même son propre serveur de métadonnées sous la forme de Vertex AI Metadata. La mise en place par défaut de ces services gérés est vraiment la bienvenue, car selon notre expérience, les options par défaut de AI Platform Pipelines (nœuds Kubernetes et PVC hébergeant les services MySQL et MinIO) ne s'adaptent pas aussi bien que leurs homologues gérés par Google.
Un autre avantage de cette nouvelle approche pour les utilisateurs est la réduction des coûts grâce au modèle de paiement à l'utilisation que cette approche de "pipelines en tant que service" est capable de fournir. Au lieu de payer pour le temps de fonctionnement continu du cluster K8s nécessaire, les utilisateurs ne paieront désormais que 0,03 USD par exécution, plus les ressources de calcul consommées par le pipeline pendant son fonctionnement.
Kubeflow dans les pipelines de sommets
Compte tenu de cette nouvelle approche de la mise en œuvre des pipelines Kubeflow dans Vertex AI, il y a quelques différences à noter lors du développement de flux de travail avec le SDK KFP.
La première est que Vertex AI nécessite une toute nouvelle version du Kubeflow SDK, la version 2.0. Ce SDK est fourni avec les versions de Kubeflow Pipelines postérieures à la v1.6. Une fois cette version installée, vous êtes donc prêt à commencer à construire des pipelines conformes au SDK v2.0.
Cette nouvelle version du SDK est conçue principalement pour utiliser les outils de suivi des métadonnées des pipelines et des artefacts de ML Metadata, un outil de suivi des métadonnées open source développé par l'équipe Tensorflow Extended. Vertex AI implémente sa propre version de cet outil dans Vertex ML Metadata, qui utilise l'outil de base TFX ML Metadata.
Si le développement avec la nouvelle version du SDK sera en grande partie identique à celui du SDK Kubeflow traditionnel, il existe quelques différences qu'il faudra garder à l'esprit en travaillant avec la nouvelle norme.
Tout d'abord, en ce qui concerne les composants de construction, KFP SDK v2.0 exige que tous les paramètres des composants soient annotés avec leur type de données. En outre, une distinction supplémentaire est désormais faite entre les entrées de composants qui sont des paramètres et celles qui sont des artefacts. Les paramètres des composants sont ceux qui peuvent être transmis sous forme de chaîne de caractères, d'entier, de flottant, de booléen, de dictionnaire ou de liste et sont donc généralement de petits éléments de données. Les artefacts sont des données plus importantes, par exemple des ensembles de données ou des modèles, et sont transmis sous forme de chemin d'accès faisant référence à l'emplacement des artefacts. Les valeurs des paramètres et les métadonnées des artefacts peuvent être consultées dans ML Metadata.
La différence entre les artefacts et les paramètres est réellement spécifiée dans la spécification du composant dans les fichiers component.yaml de nos composants. Ci-dessous, nous pouvons voir un fichier component.yaml de base tel qu'il pouvait se présenter avec l'ancienne version du SDK. En dessous, nous avons le fichier component.yaml tel qu'il se présenterait avec les nouvelles spécifications.
Inspecting these component specifications carefully, one will notice that for input values in the ‘command’ portion of the ‘implementation’, we previously would have used `{inputValue: variable_name}` for Artifacts and Parameters. In the new version, we specify Artifacts with `{inputPath: variable_name}` and Parameters with `{inputValue: variable_name}`.
Lors de la construction de pipelines, la nouvelle version du SDK apporte quelques changements. Premièrement, comme pour les composants, les définitions des paramètres des pipelines doivent être annotées avec leurs types de données. Deuxièmement, les pipelines doivent être décorés avec le décorateur `@kfp.dsl.pipeline`. Dans le décorateur Pipeline, nous pouvons spécifier le nom du pipeline (l'ID utilisé pour interroger les métadonnées ML pour obtenir des informations sur votre exécution), la description (qui est facultative) et pipeline_root, qui spécifie l'emplacement dans lequel stocker les sorties du pipeline. Le paramètre "pipeline_root" est facultatif dans Kubeflow Pipelines car il utilisera le stockage d'artefacts MinIO si une racine n'est pas définie. Cependant, étant donné que Vertex Pipelines utilisera GCS pour le stockage des artefacts, il est nécessaire de spécifier 'pipeline_root' (soit dans le décorateur Pipeline, soit lors de l'appel de la méthode create_run_from_job_spec du client Python).
Limites de Kubeflow SDK v2.0
En plus de ces considérations relatives au SDK v2.0 que les utilisateurs doivent garder à l'esprit lorsqu'ils développent des pipelines Kubeflow pour Vertex Pipelines, il existe quelques contraintes supplémentaires compte tenu des aspects pratiques de la mise en œuvre de Vertex Pipelines.
La première est la mise en cache des exécutions des composants du pipeline. Dans Kubeflow Pipelines, nous pouvions spécifier que le cache de l'exécution d'un composant expirerait après un certain temps ; avant cela, les composants exécutés avec des configurations identiques utiliseraient les résultats mis en cache des exécutions précédentes. Dans Vertex Pipelines, nous ne pouvons pas spécifier le délai d'expiration des caches, mais nous pouvons utiliser le paramètre "enable_caching" de la méthode create_run_from_job_spec du client pour activer/désactiver l'utilisation des caches dans les exécutions Vertex Pipeline.
En plus de la mise en cache, les composants appelés récursivement sont une autre caractéristique de Kubeflow Pipelines que Vertex Pipelines ne prend pas en charge actuellement. La documentation de Google à ce sujet utilise le même langage : "Actuellement, Vertex Pipelines ne prend pas en charge...", ce qui indique que c'est quelque chose qu'ils cherchent potentiellement à prendre en charge à l'avenir.
Une autre différence essentielle entre Kubeflow Pipelines et Vertex Pipelines est la possibilité d'utiliser davantage de ressources gérées par Google, telles que GCS, dans vos pipelines. Par exemple, dans Vertex Pipelines, les utilisateurs peuvent accéder directement à GCS comme s'il s'agissait d'un volume de stockage monté à l'aide de Cloud Storage FUSE. En revanche, auparavant, dans Kubeflow Pipelines, les utilisateurs interagissaient avec des ressources Kubernetes telles que les PVC (Persistent Volume Claims). Un autre indicateur de ce phénomène est la multitude de composants prédéfinis spécifiques à Google Cloud qui ont été publiés pour prendre en charge l'interaction des pipelines et des ressources Google Cloud/ Vertex AI.
Conclusion
En résumé, Vertex AI Pipelines introduit quelques changements intéressants par rapport à l'implémentation précédente de AI Platform Pipelines, ce qui facilitera grandement le développement et l'exécution de flux de travail MLOps sur GCP. La décision de mieux gérer les ressources sous-jacentes que dans la solution précédente est la bienvenue, car elle accélère et simplifie le processus de mise en œuvre de Pipelines sur GCP. Il convient de noter que ce produit est encore dans une sorte de phase d'avant-première, mais les outils clés sont déjà là pour commencer à utiliser ce produit et il s'agit certainement d'une amélioration prometteuse par rapport à ce qui existait auparavant. Pour ceux qui ne savent pas encore s'ils doivent utiliser AI Platform ou se lancer directement dans Vertex Pipelines, je vous recommande de donner une chance au petit dernier.