3 min read

Das Wichtigste in Kürze

• Nur 53% der ML-Projekte schaffen es vom Prototyp in die Produktion.
• MLOps automatisiert Training, Deployment und Monitoring von ML-Modellen.
• Feature Stores eliminieren redundante Feature-Engineering-Arbeit über Teams hinweg.
• Model Monitoring erkennt Data Drift und Performance-Degradation in Echtzeit.
• Managed MLOps-Plattformen (SageMaker, Vertex AI) senken die Einstiegshürde deutlich.

---

Das Training eines Machine-Learning-Modells ist der einfache Teil. Der schwierige Teil beginnt danach: Wie bringt man das Modell zuverlässig in Produktion, hält es aktuell und erkennt, wann es nicht mehr funktioniert? MLOps – die Disziplin an der Schnittstelle von ML und DevOps – liefert die Antworten. Cloud-Plattformen machen diese Antworten endlich zugänglich.

Warum ML-Projekte in der Produktion scheitern

Die Statistik ist ernüchternd: Laut Gartner schaffen nur 53% der ML-Projekte den Sprung vom Prototyp in die Produktion. Die Gründe sind selten algorithmisch – sie sind operativ. Data Scientists arbeiten in Notebooks, Deployment ist manuell, Monitoring existiert nicht, und wenn sich die Eingangsdaten ändern, bemerkt es niemand.

Das Resultat sind Modelle, die im Jupyter Notebook brillieren und in der Produktion versagen. Der Gap zwischen Experiment und Production ist das zentrale Problem, das MLOps löst.

Die MLOps-Architektur: Von Feature Store bis Model Registry

Eine robuste MLOps-Pipeline besteht aus fünf Kernkomponenten:

Feature Store: Zentrale Ablage für vorberechnete Features, die von mehreren Modellen wiederverwendet werden. Feast (Open Source) und die nativen Feature Stores von SageMaker und Vertex AI eliminieren redundantes Feature Engineering.

Training Pipeline: Automatisierte, reproduzierbare Training-Jobs mit Versioning für Code, Daten und Hyperparameter. Kubeflow Pipelines, SageMaker Pipelines und Vertex AI Pipelines sind die gängigen Implementierungen.

Model Registry: Versioniertes Repository für trainierte Modelle mit Metadaten, Metriken und Lineage. MLflow Model Registry und die nativen Registries der Cloud-Provider sind der Standard.

Serving Infrastructure: Skalierbare Inferenz über REST APIs oder Batch Processing. Auto-Scaling, A/B-Testing und Canary Deployments für Modelle funktionieren analog zu klassischen Microservices.

Model Monitoring: Kontinuierliche Überwachung von Input-Daten (Data Drift), Vorhersagequalität (Model Drift) und operativen Metriken (Latenz, Throughput).

Data Drift: Das unsichtbare Risiko

ML-Modelle werden auf historischen Daten trainiert. Wenn sich die Verteilung der Produktionsdaten ändert – etwa durch saisonale Effekte, neue Kundengruppen oder externe Schocks – , degradiert die Modellqualität schleichend. Ohne Monitoring bemerkt man das erst, wenn Business-Metriken einbrechen.

Moderne Drift-Detection nutzt statistische Tests (Kolmogorov-Smirnov, Population Stability Index) auf Feature-Ebene und Prediction-Ebene. Wenn Drift erkannt wird, triggert die Pipeline automatisch ein Re-Training mit aktuellen Daten. SageMaker Model Monitor und Vertex AI Model Monitoring implementieren dieses Pattern out-of-the-box.

Managed vs. Self-Hosted: Die Build-or-Buy-Entscheidung

Managed MLOps-Plattformen wie SageMaker, Vertex AI und Azure ML senken die Einstiegshürde dramatisch. Training, Serving und Monitoring sind integriert, Infrastruktur wird abstrahiert. Für Teams, die schnell in Produktion wollen, ist das der empfohlene Weg.

Self-Hosted-Stacks auf Basis von Kubeflow, MLflow, Seldon und Prometheus bieten mehr Flexibilität und Portabilität, erfordern aber erhebliche Engineering-Kapazität. Dieser Weg lohnt sich für Unternehmen mit großen ML-Teams und spezifischen Anforderungen an Datenhoheit oder Multi-Cloud-Portabilität.

Praktischer Einstieg: MLOps in drei Reifegraden

Level 0 – Manual: Modelle werden manuell trainiert und deployed. Monitoring basiert auf Dashboards. Dieser Level ist akzeptabel für erste Proof-of-Concepts.

Level 1 – Pipeline Automation: Training ist automatisiert und reproduzierbar. Modelle werden über CI/CD deployed. Data Drift wird überwacht. Die meisten Unternehmen sollten hier starten.

Level 2 – Full Automation: Continuous Training bei Drift-Detection, automatisierte A/B-Tests, Feature Stores, automatisiertes Rollback. Dieses Level ist für Teams mit vielen Modellen in Produktion relevant.

Read more auf cloudmagazin.com

• SaaS-Management-Plattformen: Schatten-IT in der Cloud unter Kontrolle bringen
• AIOps: Wie KI den Cloud-Betrieb automatisiert und Ausfälle verhindert
• FinOps: Wie Unternehmen Cloud-Kosten endlich in den Griff bekommen

Frequently Asked Questions

Was ist der Unterschied zwischen MLOps und DevOps?

DevOps automatisiert den Software-Lifecycle (Code → Build → Test → Deploy). MLOps erweitert diesen um ML-spezifische Anforderungen: Daten-Versionierung, Experiment-Tracking, Feature Engineering, Model Training, Model Registry und Model Monitoring. Die Grundprinzipien (Automation, Monitoring, Reproduzierbarkeit) sind identisch.

Welche Cloud-Plattform eignet sich am besten für MLOps?

SageMaker (AWS) hat das breiteste Feature-Set und die größte Community. Vertex AI (GCP) integriert hervorragend mit BigQuery und bietet starke AutoML-Features. Azure ML punktet in Microsoft-Ökosystemen. Die Wahl hängt vom bestehenden Cloud-Provider und dem Team-Skillset ab.

Wie viele ML Engineers braucht man für MLOps?

Für den Einstieg (Level 1) reichen 1-2 ML Engineers, die die Pipeline aufsetzen. Managed Services reduzieren den Bedarf erheblich. Für Level 2 mit vielen Modellen in Produktion rechnet man mit 1 ML Engineer pro 5-10 produktive Modelle.

Was kostet MLOps in der Cloud?

Die Plattform-Kosten variieren stark nach Modellkomplexität und Inferenz-Volumen. Ein typisches Setup mit täglichem Training und Real-Time-Serving liegt bei 500-2.000 €/Monat für die Infrastruktur. Der größere Kostenfaktor sind die Engineering-Stunden für Setup und Wartung.

Braucht man MLOps für LLM-Anwendungen?

Ja, aber mit Anpassungen. LLMs werden selten selbst trainiert – der Fokus liegt auf Prompt Management, RAG-Pipeline-Optimierung, Evaluation und Monitoring von Halluzinationen. LLMOps als Sub-Disziplin adressiert diese spezifischen Anforderungen.

Quelle des Titelbildes: Pexels / Google DeepMind

More from the MBF Media Network

SecurityToday | MyBusinessFuture | Digital Chiefs