Einführung

Machine Learning hört nicht beim Modelltraining auf. In produktionsreifen ML-Projekten brauchen wir Logging, Versionskontrolle, reproduzierbare Pipelines, Deployment, Monitoring und Governance – kurz: MLOps.

Was ist MLOps und brauche ich es? Stellst du dir diese Frage, kann ich dir folgende Zusammenfassung empfehlen: https://neptune.ai/blog/mlops

Zwei populäre Tools, die MLOps-Anforderungen erfüllen, sind MLflow und Vertex AI. Doch sie verfolgen grundlegend verschiedene Philosophien.

In diesem Artikel analysieren wir die beiden Tools aus technischer Sicht – mit Fokus auf Architektur, Integrationsfähigkeit, Pipelines und Real-World-Deployment.

Der Anfang des Artikels gibt einen kleinen Überblick über die beiden Produkte, sodass ich in den folgenden Themen eigene Erfahrungswerte und Probleme aufgreifen kann.

Du kennst dich bereits gut mit beiden Tools aus, dann springe direkt nach unten zu meinen Learnings.

Architektur im Überblick

MLflow

MLflow ist ein Open-Source-Framework, das ursprünglich von Databricks entwickelt wurde. Es ist flexibel, leichtgewichtig und lässt sich in verschiedenste ML-Stacks integrieren. Es besteht aus vier Kernkomponenten:

• Tracking

  Logging-API für Metriken, Parameter, Artefakte. Unterstützt sowohl lokale Runs als auch Remote-Tracking-Server (z. B. über mlflow server). Backends: Dateisystem, SQL DB (z. B. SQLite, MySQL, PostgreSQL).

• Projects

  Strukturierung von Code als wiederverwendbare ML-Pakete mit MLproject YAML-Datei. Unterstützt Conda und Docker Environments.

• Models

  Standardformat zur Modellpersistenz (mlflow.pyfunc als generisches Interface). Export in z. B. ONNX, TensorFlow SavedModel oder sogar zu AWS SageMaker und Azure ML möglich.

• Model Registry

  HTTP-API und UI zur Modellversionierung, Staging/Production-Promotion, CI/CD-Integration.

MLflow ist nicht auf ein Ökosystem beschränkt. Du kannst z. B. mit PyTorch, Scikit-learn oder HuggingFace arbeiten – lokal, on-prem oder in der Cloud.

Vorteile:

• Open Source und lokal einsetzbar
• Cloud-agnostisch
• Große Community und viele Integrationen (PyTorch, TensorFlow, XGBoost, etc.)

Nachteile:

• Kein integriertes Compute-Backend oder AutoML
• Skalierung und Hosting muss selbst organisiert werden

Vertex AI

→ One Platform to Rule Them All

Vertex AI ist eine vollständig verwaltete MLOps-Plattform von Google Cloud, die zahlreiche ML-Dienste unter einer konsolidierten Oberfläche vereint. Sie unterstützt den gesamten Machine-Learning-Lifecycle – von der Datenvorbereitung über das Training bis hin zum Deployment und Monitoring.

Vertex AI bietet sechs zentrale Komponenten:

• Workbench

  JupyterLab-basierte Entwicklungsumgebung für das Prototyping und Training – wahlweise über Notebook-Instanzen oder benutzerdefinierte Container. Enge Integration mit GCP-Diensten wie GCS und BigQuery.

• Training

  Flexibles Training mit manuellen Jobs oder AutoML. Unterstützung für benutzerdefinierte Trainingspipelines (z. B. mit TensorFlow, PyTorch). Ausführung auf skalierbaren, serverlosen Ressourcen.

• Pipelines

  Workflow-Orchestrierung basierend auf dem Kubeflow Pipelines SDK, TFX oder TFData. Ermöglicht wiederholbare und versionierte ML-Prozesse mit GCP-nativer Integration.

• Model Registry

  Zentrale Verwaltung und Versionierung von Modellen. Unterstützung für Staging, Deployment und Modellfreigaben. Automatische Integration in CI/CD-Workflows möglich.

• Prediction

  Managed Online- und Batch-Inferenz mit automatischem Skalieren. Modelle können als AutoML-Output oder in benutzerdefinierten Containern deployt werden.

• Model Monitoring & Explainability

  Integrierte Überwachung von Predictions (z. B. Datadrift, Outlier Detection) sowie Tools zur erklärbaren KI (Feature Attribution, Bias Detection).

Vertex AI ist tief in das Google Cloud Ökosystem eingebettet – u. a. mit GCP IAM, dem Vertex Feature Store, Cloud Logging, GCS und Pub/Sub – und basiert auf einer Kubernetes-nativen Architektur.

Vorteile:

• Vollständig integriert in Google Cloud
• Skalierbare Infrastruktur „out of the box"
• Unterstützt sowohl Code-First als auch No-Code-Ansätze

Nachteile:

• Starke Google-Cloud-Bindung
• Komplexer Einstieg für kleinere Teams
• Abhängig vom GCP-Preismodell

Komponenten unter der Lupe

In den folgenden Kapiteln werde ich etwas aus der Praxis berichten. Ich habe sowohl lokale MLflow-Setups als auch MLFlow in Databricks-Umgebungen genutzt. Auf der anderen Seite gab es Projekte, die vollständig mit VertexAI umgesetzt wurden, da die Datengrundlage bereits Teil der Google Cloud Infrastruktur ist.

1. Betrieb und Skalierung

Architektur

MLflow

Der MLflow-Tracking-Server kann relativ einfach lokal installiert und getestet werden. Für den produktiven Einsatz sollte man ihn jedoch nicht verwenden. Stattdessen empfiehlt sich ein Deployment mit Kubernetes und einer SQL-Datenbank im Hintergrund (z. B. PostgreSQL oder MySQL).

Da ich bereits Erfahrungen mit Kubernetes hatte, war dies mein erster Ansatz. Dieser verlief jedoch nur teilweise erfolgreich. Zwar ließ sich MLflow relativ einfach nutzen, allerdings verursachte die gesamte Infrastruktur einen erheblichen Overhead. Einige Funktionen von MLflow konnten in einem lokalen Deployment zudem nicht umgesetzt werden – mehr dazu in den folgenden Kapiteln.

Der klare Favorit ist die Nutzung von MLflow ist Databricks. Da MLflow ein Databricks-Produkt ist, besteht eine nahtlose Integration in die Databricks-Plattform. Databricks übernimmt dabei die gesamte Infrastruktur und Skalierung, was die Arbeit deutlich vereinfacht, jedoch auch einen entscheidenden Nachteil mit sich bringt, auf den später noch eingegangen wird.

Vertex AI

Vertex AI ist nativ in die Google-Infrastruktur eingebunden und vollständig verwaltet. Es läuft auf einer Kubernetes-nativen Struktur bei Google.

Die Inbetriebnahme ist dabei sehr einfach: Man wählt lediglich Region und Zone (oder sogar mehrere Regionen), um das Load Balancing kümmert sich Google. Ebenso übernimmt die Plattform die Skalierung der Instanzen und passt diese bei Bedarf automatisch an.

Kosten

MLflow

Da MLflow selbst Open Source ist, entstehen keine direkten Lizenzkosten. In einer eigenen Infrastruktur fallen jedoch Kosten für Compute, Speicher & Netzwerk an.

Bei einer verwalteten Instanz von Databricks gilt ein Abrechnungsmodell pro Cluster bzw. Job. Die Kosten sind sehr variabel und abhängig von dem jeweiligen Nutzungsumfang.

Im Kapitel "Lessens Learned" gehe ich auf diesen Punkt etwas detaillierter ein.

Vertex AI

Das Kostenmodell bei Google basiert in der Regel auf dem Pay-as-you-go-Prinzip. Dabei werden sämtliche Dienste wie Training, Speicher, Pipelines und Endpoints einzeln abgerechnet. Daher ist von Beginn an eine saubere Konfiguration notwendig, um zu verhindern, dass dauerhaft laufende GPU-Instanzen die Kosten in die Höhe treiben. Dasselbe gilt selbstverständlich auch für den Managed Service bei Databricks.

Pipelines

MLflow

MLflow verfügt über keine eingebaute Pipeline-Orchestrierung. Databricks zielt darauf ab, die Orchestrierung von MLflow in der eigenen Plattform zu nutzen, indem Notebooks in Databricks-Jobs eingebunden und orchestriert werden können. Ich habe MLflow jedoch gerne mit Airflow kombiniert, da bestehende Workflows bereits damit umgesetzt wurden.

Alternativ können auch Lösungen wie Prefect oder Dagster eingesetzt werden. Logging und Monitoring müssen dabei gegebenenfalls eigenständig implementiert werden.

Vertex AI

Vertex AI Pipelines basieren auf Kubeflow Pipelines und sind eng in die Google Cloud Platform (GCP) integriert. Jede Pipeline besteht aus containerisierten Komponenten, was die Wiederverwendbarkeit fördert.

Monitoring, Logging und Modellregistrierung sind dabei automatisch angebunden.

2. Data Governance und Feature Management

Feature Store

MLflow

Ein Feature Store kann in großen Projekten eine sinnvolle Ergänzung sein, um Konsistenz und Datenqualität sicherzustellen. Es sollte sorgfältig abgewogen werden, ob dafür externe Tools erforderlich sind. In vielen Fällen können einfache Tabellen bereits eine ausreichende und unkomplizierte Datengrundlage bieten.

Ein Feature Store lässt sich unabhängig von MLflow integrieren. Externe Lösungen wie Feast oder Hopsworks sind dafür gut geeignet. In einer verwalteten MLflow-Umgebung wie Databricks kann zudem der hauseigene Feature Store genutzt werden, der nahtlos mit MLflow zusammenarbeitet.

Vertex AI

Vertex AI verfügt über einen eigenen Feature Store mit integrierter Unterstützung für Online- und Offline-Zugriffe. Dadurch lässt sich der gesamte Feature-Prozess gut zentralisieren. Allerdings sollte auch hier sorgfältig abgewogen werden, ob der Einsatz eines Feature Stores im konkreten Projekt wirklich notwendig ist.

Positiv hervorzuheben ist, dass sich die Plattform automatisch darum kümmert, dass die Features beim Training und zur Inferenzzeit synchron bleiben. Das reduziert mögliche Feature Drifts deutlich – und spart im Alltag eine Menge Kopfschmerzen.

Data Lineage und Reproduzierbarkeit

MLflow

Über das MLproject-Format und den Git SHA kannst du nachvollziehen, welche Codeversion zu welchem Run gehört. So lässt sich der Code gut zurückverfolgen.

Daten wie CSVs oder Parquet-Dateien musst du separat versionieren – z. B. mit Git. In Databricks kannst du dafür direkt Delta Lake verwenden.

Vertex AI

Vertex AI ist eng mit GCS und BigQuery verbunden – damit kannst du deine Datensätze relativ einfach versionieren.

Jeder Schritt in einer Vertex-AI-Pipeline schreibt automatisch Metadaten mit. Das macht es deutlich leichter, die einzelnen Transformationen nachzuvollziehen.

Ich erwähne es hier einmal bereits: Vertex AI funktioniert am besten, wenn die Datengrundlage auch in BigQuery oder in einem Lake ist.

3. CI/CD und automatisiertes Deployment

Automatische Modell-Promotion

MLflow

Über die MLflow Model Registry kannst du Modelle versionieren (z.B. Champion/Challenger) und gezielt in Staging oder Production überführen.

CI/CD lässt sich mit Tools wie Jenkins oder GitLab CI umsetzen. In Databricks sollten unter anderem auch Databricks Asset Bundles genutzt werden.

In einer Databricks-Umgebung kannst du Modelle direkt auf einem Managed MLflow Serving Endpoint deployen – oder alternativ exportieren, z. B. für einen SageMaker- oder Azure-ML-Endpoint.

Vertex AI

Auch Vertex AI bietet mit der Model Registry eine vergleichbare Lösung zur Modellverwaltung.

Automatisierte CI/CD-Pipelines – etwa mit Cloud Build oder GitHub Actions – können neue Modell-Endpoints bereitstellen und nach erfolgreicher Validierung die bestehende Version ablösen.

Ein Rollback ist unkompliziert: entweder per Klick in der Konsole oder über ein kurzes Skript. Die zugrunde liegende Infrastruktur wird dabei komplett von Google gemanagt.

💡 DISCLAMER: Bevor ein Modell in Produktion geht, sollten valide Qualitätssicherungen greifen!

Validierungsschritte wie Accuracy, Precision, oder Drift Checks helfen dabei, nur robuste Modelle weiterzuleiten. Das gilt besonders, wenn die Datenlage stark schwankt oder sich Schemata regelmäßig ändern – hier lohnen sich gezielte Modell- und Datentests, z. B. mit Great Expectations, Deepchecks oder eigenen Pytest-Erweiterungen.

Die gesamte Pipeline lässt sich automatisieren – vom Code-Change bis zum Rollback:

Code-Änderung → Training → Evaluation → Registry → Canary Deployment → Monitoring → ggf. Rollback.

4. Monitoring

MLflow

MLflow bringt von Haus aus nur grundlegende Funktionen fürs Experiment-Tracking mit – etwa für Metriken während des Trainings.

Für echtes Modell-Monitoring in Produktion – etwa zur Erkennung von Drift oder Ausreißern – brauchst du externe Systeme wie Prometheus, Grafana oder den ELK Stack. Diese lassen sich über eigene Pipelines oder Inferenz-Services integrieren.

In Databricks kannst du zusätzlich auf Jobs, Delta Live Tables und das integrierte Monitoring für Cluster-Ressourcen zurückgreifen. Für tiefgreifendere Metrik-Analysen im laufenden Betrieb sind aber auch hier externe Tools nötig.

Du musst in Databricks jedoch nicht das eigene Logging nutzen. Wir haben in einigen Projekten auch Metriken, Features oder Modellbeschreibungen in eigene Tabellen extrahiert, sodass der Überblick nicht verloren geht.

Vertex AI

Vertex AI bietet ein integriertes Monitoring – inklusive automatischer Erkennung von Data und Concept Drift.

Die Plattform analysiert statistische Veränderungen und stellt Alerts direkt über Cloud Monitoring & Logging bereit.

Ein Feature fande ich in meinem Alltag immer hilfreich: Die integrierte Explainability auf Basis von SHAP zeigt, welche Features aktuell am meisten zur Vorhersage beitragen – auch im laufenden Betrieb.

5. Multi-Cloud- und Hybrid-Szenarien

MLflow

Ein großer Vorteil von MLflow ist die Unabhängigkeit von der Infrastruktur. Du kannst Modelle in AWS trainieren, sie On-Prem validieren und anschließend ganz woanders deployen – ohne das Tooling wechseln zu müssen.

Die Artefaktspeicher wie S3, GCS oder Azure Blob lassen sich flexibel austauschen. Auch das Backend-Tracking (z. B. SQLite, MySQL, PostgreSQL) ist frei wählbar – je nach Umgebung und Anforderungen.

Databricks bringt MLflow nativ mit und unterstützt den Multi-Cloud-Betrieb auf AWS, Azure und GCP. Die Funktionen bleiben weitgehend gleich – Unterschiede gibt's vor allem bei der Einrichtung von Storage und Compute.

Vertex AI

Vertex AI kann grundsätzlich auch mit On-Prem-Datenquellen umgehen – etwa über VPC Peering, Cloud VPN oder Private Service Connect.

Trotzdem findet das Deployment immer in der Google Cloud statt. Du hast nur begrenzt Kontrolle über die darunterliegenden Komponenten. Für Hybrid- oder Multi-Cloud-Strategien kann das Einschränkungen mit sich bringen. Multi-cloud- oder hybrid-orientiert sollte mit Vertex AI nicht angegangen werden.

6. Best Practices

Teamstrukturen & Organisationskultur

MLflow

In Projekten, in denen ich MLflow eingesetzt habe, lag oft viel Verantwortung direkt bei den Data Scientists und DevOps-Teams. Wir mussten Security, Monitoring und CI/CD selbst aufbauen – was mehr Freiheit, aber auch mehr Koordinationsaufwand bedeutet hat.

Der Open-Source-Charakter war dabei ein echter Vorteil: Wir konnten schnell auf Community-Lösungen zurückgreifen oder eigene Standards etablieren. Gerade in agilen Teams mit viel Eigenverantwortung hat das gut funktioniert. Viel Freiheit und wenig Standards bringen jedoch auch Probleme. Es hat sich häufig eher wie Bastelei angefühlt.

Vertex AI

Bei Projekten mit Vertex AI war meist ein zentrales Cloud-Team involviert – insbesondere in größeren Enterprise-Setups.

Das Onboarding war hier oft steiler, vor allem wegen der komplexeren IAM- und Netzwerk-Konfigurationen. Aber sobald die GCP-Prozesse sauber aufgesetzt waren, konnten mehrere Teams effizient auf dieselben Services und Ressourcen zugreifen. Das hat sich langfristig ausgezahlt.

Für kleinere Projekte mit viel Freitheit würde ich immer auf Vertex AI setzen. Es ist eine perfekte All-in-One-Lösung für den schnellen Erfolg.

Lessons Learned & Stolpersteine

MLflow

Was ich bei MLflow früh gelernt habe: Ohne saubere Namenskonventionen wird das Tracking schnell unübersichtlich – besonders bei vielen Runs und Experimenten.

In selbst gehosteten Setups mussten wir uns intensiv mit Sicherheits- und Netzwerkthemen beschäftigen. Das ist die Arbeitszeit häufig nicht wert, vor allem in kleineren Teams.

Auf Databricks war vieles deutlich entspannter, da viele Dinge out-of-the-box funktionieren. Aber auch hier sollte man die Kosten im Blick behalten – gerade bei mehreren gleichzeitig laufenden Clustern kann's schnell teuer werden.

Vertex AI

Bei Vertex AI habe ich erlebt, wie leicht man in Kostenfallen geraten kann – zum Beispiel durch falsch gewählte Instanztypen oder vergessene Endpoints, die im Hintergrund weiterlaufen.

Ein weiterer Punkt: Bei sehr komplexen Pipelines ist das Debugging manchmal tricky. Die starke Abstraktion von Google erleichtert viel, aber sie kann das Troubleshooting auch erschweren, wenn mal was nicht wie erwartet läuft.

Performance Tuning

MLflow

Wenn viele Experimente parallel laufen, lohnt es sich, auf Batch-Logging umzustellen. In einem Projekt mit tausenden Runs hat das die Performance spürbar verbessert.

Auch das Tuning der zugrundeliegenden Datenbank (z. B. PostgreSQL) oder der Data Stores war bei größeren Setups ein entscheidender Faktor. Wir haben z. B. mit Partitionen gearbeitet, um die Probleme beim Zugriff zu reduzieren.

Vertex AI

In Vertex AI hat sich für mich gezeigt: Die Wahl der richtigen Hardware ist entscheidend. Eine teure GPU bringt nichts, wenn das Modell sie nicht ausnutzt.

Für skalierbares Training habe ich gute Erfahrungen mit verteilten Trainingsjobs gemacht – etwa mit TensorFlow auf mehreren VMs. Wichtig war dabei immer: Erst die Skalierung sauber planen, dann hochfahren – sonst wird's unnötig teuer.

Praxis-Tipp aus Projekterfahrung

Bevor du dich für eine Plattform entscheidest, lohnt sich ein kleiner Proof of Concept. Ich habe gute Erfahrungen damit gemacht, eine einfache Pipeline aufzusetzen, ein kleines Modell zu versionieren und dabei gezielt auf folgende Punkte zu achten:

• Wie aufwendig ist die Einrichtung?
• Wie transparent sind die Kosten?
• Wie gut lässt sich die Security konfigurieren?
• Wie fühlt sich das Handling im Alltag an?

Gerade bei komplexeren MLOps-Projekten zeigt sich oft erst beim konkreten Aufbau, welches Tool wirklich zu deinem Team und zur bestehenden Infrastruktur passt. Der Implementierungsaufwand ist dabei oft entscheidender als Features.

Fazit: Dein Anwendungsfall entscheidet

MLflow eignet sich besonders für:

• Startups oder kleine Teams mit eigener Infrastruktur
• Projekte mit hoher Flexibilitätsanforderung
• Teams, die unabhängig von einem Cloudanbieter bleiben wollen

Vertex AI ist ideal für:

• Unternehmen, die bereits stark in GCP investiert sind
• Projekte mit hohen Skalierungsanforderungen
• Teams, die ein voll integriertes MLOps-Ökosystem benötigen