Vertex Pipelines - Vertex AI vs. AI-Plattform
Vor kurzem hat Google sein neuestes Angebot an ML-Tools auf der Google Cloud Platform, Vertex AI, vorgestellt. Kurz gesagt soll die neue Plattform die Tools, die zuvor von separaten Diensten auf der GCP angeboten wurden, wie AI Platform und AutoML, in einem einzigen Dienst zusammenfassen. Die Integration dieser bisher getrennten Dienste bringt den Nutzern Vorteile, da sie mit all diesen Tools über einen einzigen Satz von APIs, SDKs und Clients interagieren können.
Einen detaillierteren Überblick über die Ziele und Funktionen von Vertex AI als Ganzes finden Sie in diesen früheren ML6 Blog Post. In diesem Blog-Beitrag werden wir uns in erster Linie auf Vertex AIs Antwort auf AI Platform Pipelines, Vertex Pipelines, konzentrieren. ML-Pipeline-Technologien wie Vertex Pipelines sind für jedes MLOps-Team wichtig, da sie die vielen beweglichen Teile von komplexen Trainings- und Vorhersageaufträgen in großem Umfang orchestrieren. Sie sind ein Schlüsselelement der Infrastruktur, die die Fähigkeiten des maschinellen Lernens in eine Produktionsumgebung bringt.
AI-Plattform-Pipelines
Früher gab es in AI Platform, der früheren Plattform für maschinelles Lernen von Google, AI Platform Pipelines. Dabei handelte es sich um einen Dienst, der die Bereitstellung von Kubeflow-Pipelines, dem MLOps-Pipeline-Toolkit von Kubeflow, auf Google Cloud Platform-Ressourcen erleichtern sollte. Der Arbeitsablauf für die Bereitstellung einer Kubeflow-Pipeline mit AI Platform sah in etwa wie folgt aus;
1. Kubernetes Cluster mit Google Kubernetes Engine einrichten
Der erste Schritt bei der Bereitstellung von Pipelines auf AI Platform war die Einrichtung eines Clusters, auf dem unser Kubeflow Pipelines Client gehostet wird. Obwohl wir bei ML6 unseren Kunden immer raten, ihre Infrastruktur mit Tools wie Terraform zu automatisieren, war die Bereitstellung eines Clusters mit GKE über die übersichtlichen Benutzeroberflächen der GKE-Konsole sehr einfach.
2. Bereitstellen des Kubeflow-Clients auf dem GKE-Cluster
Nachdem unser Cluster eingerichtet und in Betrieb war, konnten wir mit der AI Platform Pipelines UI in der GCP-Konsole problemlos Kubeflow Pipelines-Instanzen bereitstellen. Die Erstellung einer neuen Bereitstellung war so einfach wie die Auswahl Ihres GKE-Clusters aus einer Dropdown-Liste und das Ausfüllen einiger Konfigurationsdaten in einem einfachen Formular. Standardmäßig werden die Knoten im Kubernetes-Cluster zum Hosten von MySQL- und MinIO-Diensten verwendet, der Standard von Kubeflow für die Speicherung von Artefakten und Metadaten. Durch Angabe von Verbindungsdetails bei der Einrichtung können jedoch GCS und Cloud Storage als skalierbarere und zuverlässigere Alternativen verwendet werden.
3. Pipelines mit Notebooks entwickeln
Nach der Einrichtung des Clusters und der Erstellung der Kubeflow-Instanz konnten wir die Notebooks von AI Platform als sichere Entwicklungsumgebungen für die Arbeit mit dem Kubeflow Pipelines SDK zur Entwicklung unserer Pipelines verwenden. In AI Platform verwenden wir einfach Vanilla-Kubeflow-Pipelines-Tools auf GCP-Ressourcen, sodass alle Standardfunktionen des Kubeflow-SDK genau so funktionieren, als würden Sie eine Kubeflow-Pipelines-Instanz auf einem lokalen Kubernetes-Cluster erstellen.
4. Verwalten von Pipelines und Läufen in der Kubeflow-Client-Benutzeroberfläche
Die entwickelten Pipelines könnten dann auf den Kubeflow-Client hochgeladen werden, wo Sie alle zuvor hochgeladenen Pipelines sehen, Läufe dieser Pipelines starten und die DAG und die Ausgaben laufender und abgeschlossener Pipeline-Läufe anzeigen können. Das Hochladen von Pipelines und das Starten/Überwachen von Läufen kann auch über die Kubeflow-Client-API mit Hilfe der im Python-SDK definierten Funktionen erfolgen.
Dieser Workflow machte es sehr einfach, mit Kubeflow-Pipelines in Google-Ressourcen zu arbeiten. Die Bereitstellung dauerte nur 5 Minuten (wenn man die Zeit nicht mitrechnet, die GCP für das Hochfahren der Ressourcen im Hintergrund benötigt). Dank GKE war die Verwaltung von Kubernetes-Clustern so einfach wie nie zuvor, und dank AI Platform Pipelines war die Bereitstellung von Kubeflow-Instanzen auf diesen Clustern sogar noch einfacher! Trotzdem mussten ML-Teams über Kubernetes-Kenntnisse verfügen, um fundierte Entscheidungen zu treffen, ihren Cluster richtig zu konfigurieren und generell die KI-Plattform-Pipelines und den GKE-Cluster, auf dem sie bereitgestellt werden sollten, optimal zu nutzen.
Vertex AI & Vertex Pipelines
Eines der ersten Dinge, die man beim Wechsel von AI Platform Pipelines zu Vertex Pipelines bemerken könnte, ist, dass diese Extrapolation der Ressourcenverwaltung weg vom Benutzer fortgesetzt wurde, was die übliche Verringerung des täglichen Aufwands bei der Verwaltung von Konfigurationsdateien mit sich bringt.
Ein wichtiger Indikator dafür ist, dass die Benutzer nicht mehr verpflichtet sind, über GKE einen dedizierten Kubernetes-Cluster zu erstellen, auf dem sie ihre Pipelines ausführen können. Stattdessen verwendet Vertex AI einen scheinbar serverlosen Ansatz zur Ausführung von Pipelines, die mit der Kubeflow Pipelines DSL geschrieben wurden. Stattdessen werden die Kubernetes-Cluster und die darauf laufenden Pods im Hintergrund von Vertex AI verwaltet.
Im folgenden Screenshot, der die Vertex Pipelines UI zeigt, bekommen Sie einen Eindruck von diesem Ansatz. Anstelle eines Speichers für Pipelines und historische Läufe, mit dem Sie vielleicht vertraut sind, wenn Sie die Kubeflow Pipelines UI zuvor verwendet haben, haben wir einfach eine Liste historischer Läufe. Läufe können durch Hochladen einer aus einem Pipelineskript kompilierten Auftragsspezifikation gestartet werden, entweder über die Benutzeroberfläche oder den Python-Client. Hier bekommen wir ein Gefühl für den "Pipelines-as-a-Service"-Ansatz, den Vertex Pipelines anzustreben scheint.
Dies deutet auch auf einen weiteren wichtigen konzeptionellen Unterschied zwischen den beiden Tools hin: Vertex AI führt keine Instanz eines Kubeflow-Clients aus. Stattdessen ist Vertex Pipelines eine eigene Version der Infrastruktur, die normalerweise von Kubeflow Pipelines bereitgestellt wird (d. h. Container Workflow Orchestration), die mit dem Kubeflow SDK spezifizierte Pipelines ausführen kann.
Ein wesentlicher Vorteil dieses neuen Ansatzes ist, dass Vertex Pipelines GCS für die Speicherung von Artefakten nativ nutzt und sogar einen eigenen Metadatenserver in Form von Vertex AI Metadata einsetzt. Die standardmäßige Bereitstellung dieser verwalteten Dienste ist definitiv zu begrüßen, da unserer Erfahrung nach die Standardoptionen in AI Platform Pipelines (Kubernetes-Knoten und PVCs, die MySQL- und MinIO-Dienste hosten) nicht ganz so gut skalieren wie ihre von Google verwalteten Gegenstücke.
Ein weiterer Vorteil, den die Benutzer mit dem neuen Ansatz begrüßen werden, ist die Kostenreduzierung durch das Pay-as-you-go-Modell, das dieser "Pipelines-as-a-Service"-Ansatz bietet. Anstatt für die kontinuierliche Betriebszeit des erforderlichen K8s-Clusters zu bezahlen, zahlen die Benutzer jetzt nur noch 0,03 US-Dollar pro Lauf, zuzüglich der Rechenressourcen, die die Pipeline während ihrer Ausführung verbraucht.
Kubeflow in Vertex-Pipelines
Angesichts dieses neuen Ansatzes für die Implementierung von Kubeflow-Pipelines in Vertex AI sind bei der Entwicklung von Workflows mit dem KFP SDK einige Unterschiede zu beachten.
Die erste ist, dass Vertex AI eine völlig neue Version des Kubeflow SDK, Version 2.0, benötigt. Dieses SDK wird mit Versionen von Kubeflow-Pipelines nach Version 1.6 gebündelt. Wenn Sie diese Version installiert haben, können Sie mit der Erstellung von SDK v2.0-kompatiblen Pipelines beginnen.
Diese neue Version des SDK ist in erster Linie dazu gedacht, die Pipeline-Metadaten und die Artefakt-Verfolgungswerkzeuge von ML Metadata zu nutzen, einem Open-Source-Metadaten-Verfolgungswerkzeug, das vom Tensorflow Extended Team entwickelt wurde. Vertex AI implementiert seine eigene Version davon in Vertex ML Metadata, die das Basiswerkzeug TFX ML Metadata nutzt.
Während die Entwicklung mit der neuen Version des SDK weitgehend identisch mit dem traditionellen Kubeflow-SDK sein wird, gibt es einige Unterschiede, die man bei der Arbeit mit dem neuen Standard beachten muss.
Erstens schreibt das KFP SDK v2.0 für die Erstellung von Komponenten vor, dass alle Komponentenparameter mit ihrem Datentyp annotiert werden müssen. Darüber hinaus wird nun zusätzlich zwischen Komponenten-Eingaben, die Parameter sind, und solchen, die Artefakte sind, unterschieden. Komponentenparameter sind solche, die als String-, Integer-, Float-, Boolean-, Dictionary- oder List-Typ übergeben werden können und daher in der Regel kleinere Datenstücke sind. Artefakte sind größere Dateneinheiten, z. B. Datensätze oder Modelle, und werden stattdessen als Pfad übergeben, der auf den Speicherort der Artefakte verweist. Parameterwerte und Artefakt-Metadaten können unter ML-Metadaten eingesehen werden.
Der Unterschied zwischen Artefakten und Parametern ist in der Komponentenspezifikation in den component.yaml-Dateien unserer Komponenten festgelegt. Unten sehen Sie eine einfache component.yaml-Datei, wie sie in der alten Version des SDK ausgesehen haben könnte. Darunter sehen wir die component.yaml, wie sie nach der neuen Spezifikation aussehen würde.
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}`.
Bei der Erstellung von Pipelines bringt die neue SDK-Version eine Reihe von Änderungen mit sich. Erstens müssen Pipeline-Parameter-Definitionen, wie bei Komponenten, mit ihren Datentypen annotiert werden. Zweitens müssen Pipelines mit dem Dekorator `@kfp.dsl.pipeline` dekoriert werden. Innerhalb des Pipeline-Dekorators können wir den Pipeline-Namen (die ID, die für die Abfrage von ML-Metadaten nach Informationen über Ihren Lauf verwendet wird), die Beschreibung (die optional ist) und pipeline_root angeben, die den Speicherort für die Pipeline-Ausgaben angibt. Der Parameter "pipeline_root" ist in Kubeflow-Pipelines optional, da MinIO Artifact Storage verwendet wird, wenn kein Stamm definiert ist. Da Vertex Pipelines jedoch GCS für die Speicherung von Artefakten verwendet, muss "pipeline_root" angegeben werden (entweder im Pipeline-Dekorator oder beim Aufruf der Methode create_run_from_job_spec des Python-Clients).
Kubeflow SDK v2.0 Beschränkungen
Zusätzlich zu diesen Überlegungen zum SDK v2.0, die Benutzer bei der Entwicklung von Kubeflow-Pipelines für Vertex-Pipelines beachten müssen, gibt es einige zusätzliche Einschränkungen, die sich aus den praktischen Gegebenheiten der Implementierung von Vertex-Pipelines ergeben.
Die erste ist die Zwischenspeicherung von Pipeline-Komponentenausführungen. In Kubeflow-Pipelines konnte festgelegt werden, dass der Zwischenspeicher einer Komponentenausführung nach einer bestimmten Zeitspanne abläuft; vorher würden Komponenten, die mit identischen Konfigurationen ausgeführt werden, die zwischengespeicherte Ausgabe früherer Ausführungen verwenden. In Vertex Pipelines kann der Zeitrahmen, nach dem Caches ablaufen, nicht angegeben werden, aber wir können den Parameter "enable_caching" der create_run_from_job_spec-Methode des Clients verwenden, um die Verwendung von Caches in Vertex Pipeline-Ausführungen zu aktivieren/deaktivieren.
Neben der Zwischenspeicherung ist der rekursive Aufruf von Komponenten eine weitere Funktion von Kubeflow Pipelines, die Vertex Pipelines derzeit nicht unterstützt. Die Google-Dokumentation dazu verwendet die gleiche Formulierung "Derzeit unterstützt Vertex Pipelines nicht...", was darauf hindeutet, dass dies etwas ist, das sie möglicherweise in Zukunft unterstützen wollen.
Ein weiterer wesentlicher Unterschied zwischen Kubeflow-Pipelines und Vertex-Pipelines besteht darin, dass mehr von Google verwaltete Ressourcen wie GCS in Ihren Pipelines verwendet werden können. In Vertex Pipelines können Nutzer beispielsweise direkt auf GCS zugreifen, als wäre es ein gemountetes Speichervolumen mit Cloud Storage FUSE. In Kubeflow-Pipelines hingegen interagierten die Benutzer bisher mit Kubernetes-Ressourcen wie Persistent Volume Claims (PVCs). Ein weiteres Indiz dafür ist die Vielzahl von Google Cloud-spezifischen vordefinierten Komponenten, die zur Unterstützung der Interaktion von Pipelines und Google Cloud/Vertex AI-Ressourcen veröffentlicht wurden.
Fazit
Zusammenfassend lässt sich sagen, dass Vertex AI Pipelines einige nette Änderungen gegenüber der vorherigen AI Platform Pipelines-Implementierung mit sich bringt, die die Entwicklung und Ausführung von MLOps-Workflows auf GCP insgesamt sehr viel einfacher machen werden. Der Schritt, die zugrundeliegenden Ressourcen besser zu verwalten als in der vorherigen Lösung, ist zu begrüßen und beschleunigt und vereinfacht gleichzeitig den Prozess der Inbetriebnahme von Pipelines in GCP. Es ist erwähnenswert, dass sich dieses Produkt noch in einer Art Vorschauphase befindet, aber die wichtigsten Tools sind bereits vorhanden, um mit der Nutzung dieses Produkts zu beginnen, und es ist sicherlich eine vielversprechende Verbesserung im Vergleich zu dem, was vorher war. Diejenigen, die sich noch nicht sicher sind, ob sie AI Platform verwenden oder direkt mit Vertex Pipelines einsteigen sollen, sollten dem neuen Produkt eine Chance geben.