MLOps

KAPITEL 16 · KI & ENGINEERING

MLOps

Machine Learning Operations – die Brücke zwischen Data Science und Production. Erfahren Sie, wie ML-Modelle zuverlässig entwickelt, deployed, überwacht und im Enterprise-Maßstab betrieben werden.

Versioning CI/CD for ML Monitoring Governance Toolchain

Was ist MLOps?

Definition

MLOps (Machine Learning Operations) ist eine Disziplin, die Machine Learning, DevOps und Data Engineering vereint, um den gesamten Lebenszyklus von ML-Modellen zu automatisieren und zu standardisieren. Ziel ist es, Modelle zuverlässig, reproduzierbar und skalierbar in Produktion zu bringen und dort kontinuierlich zu betreiben.

Während traditionelle Software deterministisch ist („gleicher Input = gleicher Output"), sind ML-Systeme probabilistisch und datenabhängig. Das bedeutet: Nicht nur der Code ändert sich, sondern auch die Daten und das Modell selbst. MLOps adressiert diese einzigartige Komplexität durch spezialisierte Praktiken und Tools.

DevOps

  • Deterministischer Code
  • Versionierung: Code + Config
  • Testing: Unit, Integration, E2E
  • Deployment: Statisch nach Build
  • Monitoring: Logs, Metrics, Uptime
  • Artefakte: Container, Binaries
VS

MLOps

  • Probabilistisches Modell + Daten
  • Versionierung: Code + Daten + Modell
  • Testing: + Datenqualität, Modell-Performance
  • Deployment: + Retraining-Trigger
  • Monitoring: + Drift, Fairness, Accuracy
  • Artefakte: + Modellgewichte, Datasets

Der MLOps-Lebenszyklus

MLOps umfasst den gesamten Lebenszyklus eines ML-Systems – von der Datenerfassung bis zum kontinuierlichen Monitoring in Produktion.

End-to-End ML Pipeline

1
Daten erfassen

Ingestion & Validation

2
Experimentieren

Training & Tracking

3
Evaluieren

Testing & Validation

4
Registrieren

Model Registry

5
Deployen

CI/CD & Serving

6
Überwachen

Monitoring & Drift

7
Retrainieren

Feedback Loop

Kernpraktiken im MLOps

Die sechs fundamentalen Praktiken, die ein robustes MLOps-System ausmachen.

Versionierung

Nicht nur Code, sondern auch Daten und Modelle müssen versioniert werden. Nur so sind Experimente reproduzierbar und Rollbacks möglich.

DVC MLflow LakeFS Git LFS

Experiment Tracking

Jedes Training wird automatisch protokolliert: Hyperparameter, Metriken, Artefakte und Code-Version. Ermöglicht Vergleich und Reproduktion.

MLflow W&B TensorBoard Neptune

CI/CD für ML

Automatisierte Pipelines für Code-Tests, Modell-Training, Evaluation und Deployment. Drei Ebenen: CI, CD für Code, CD für Modelle.

GitHub Actions Kubeflow Airflow ZenML

Model Monitoring

Kontinuierliche Überwachung von Data Drift, Concept Drift, Performance-Degradation und Fairness in Produktion. Trigger für Retraining.

Evidently Arize Fiddler Prometheus

Model Registry

Zentraler Katalog für Modelle mit Versionierung, Stage-Management (Staging, Production), Metadaten und Approval-Workflows.

MLflow Registry Vertex AI SageMaker BentoML

Governance & Compliance

Audit-Trails, Zugriffskontrolle, Modell-Dokumentation (Model Cards), Bias-Testing und Regulatory Compliance (EU AI Act).

Model Cards AIF360 Credo AI OpenLineage

MLOps Toolchain

Das Ökosystem der wichtigsten MLOps-Tools, kategorisiert nach Funktion.

Tools nach Kategorie

MLflow
Tracking & Registry

Open-Source-Plattform für Experiment-Tracking, Model Registry und Deployment. De-facto-Standard.

Weights & Biases
Experiment Tracking

Premium-Tool für Experiment-Tracking mit hervorragender Visualisierung und Team-Kollaboration.

Vertex AI
Managed ML Platform

Googles vollständig verwaltete ML-Plattform auf GCP. End-to-End von Training bis Serving.

SageMaker
Managed ML Platform

AWS-Ökosystem für ML. Umfassende Services für jeden Schritt des ML-Lebenszyklus.

Kubeflow
Orchestration (K8s)

Kubernetes-native ML-Plattform. Ideal für On-Premise und hybride Cloud-Setups.

DVC
Data Versioning

Git-ähnliche Versionierung für große Datensätze und ML-Modelle. Open Source.

Airflow
Pipeline Orchestration

Apache-Projekt für Workflow-Orchestration. Standard für DAG-basierte ML-Pipelines.

Evidently AI
Monitoring & Drift

Open-Source-Tool für Data/Concept-Drift-Erkennung und Modell-Performance-Monitoring.

MLOps Reifegrade

Google definiert drei Reifegrade für MLOps, die den Automatisierungsgrad beschreiben.

Level 0

Manuell

Alle Schritte werden manuell ausgeführt. Data Scientists trainieren Modelle in Notebooks und deployen sie per Hand.

  • Manuelles Training & Evaluation
  • Kein Experiment-Tracking
  • Manuelles Deployment
  • Kein Monitoring
  • Hohes Risiko, nicht skalierbar
Level 1

ML Pipeline Automation

Training und Evaluation sind automatisiert. Experiment-Tracking und Model Registry sind etabliert.

  • Automatisiertes Training & Validation
  • Experiment-Tracking aktiv
  • Model Registry vorhanden
  • Manuelles Deployment
  • Reproduzierbare Experimente
Level 2

CI/CD Pipeline Automation

Vollständig automatisierte CI/CD-Pipelines für Code, Modelle und Daten. Kontinuierliches Monitoring und automatisches Retraining.

  • CI für Code + CT für Daten/Modelle
  • CD für automatisches Deployment
  • Kontinuierliches Monitoring
  • Automatische Retraining-Trigger
  • Full Governance & Audit Trail

Empfehlung für Unternehmen

Starten Sie mit Level 1 (Experiment-Tracking + Model Registry) und arbeiten Sie schrittweise Richtung Level 2. Versuchen Sie nicht, alles auf einmal zu automatisieren. Die meisten Teams erreichen Level 2 erst nach 12–24 Monaten iterativer Verbesserung.

FAQ – Häufige Fragen & Antworten

Häufige Fragen zu MLOps

Braucht jedes ML-Projekt MLOps?

Nicht sofort, aber langfristig ja. Für Prototypen und Proof-of-Concepts reicht ein Notebook. Sobald ein Modell in Produktion geht oder regelmäßig aktualisiert werden muss, ist MLOps essenziell. Faustregel: Wenn mehr als eine Person am Modell arbeitet oder es länger als 3 Monate lebt → MLOps einführen.

Was ist der Unterschied zwischen Data Drift und Concept Drift?

Data Drift: Die Verteilung der Eingabedaten ändert sich (z.B. Kundenverhalten nach COVID). Das Modell sieht Daten, die es beim Training nicht gesehen hat.

Concept Drift: Die Beziehung zwischen Input und Output ändert sich (z.B. Immobilienpreise nach Zinsänderung). Die gleichen Eingabedaten führen zu anderen korrekten Vorhersagen.

Beide erfordern Monitoring und ggf. Retraining.

Welche Rolle spielt Feature Store im MLOps?

Ein Feature Store ist eine zentrale Plattform zur Verwaltung, Speicherung und Bereitstellung von Features. Er löst drei kritische Probleme:

  • Konsistenz: Gleiche Features für Training und Serving (verhindert Training-Serving Skew)
  • Wiederverwendbarkeit: Features werden über Projekte geteilt
  • Performance: Low-Latency-Feature-Serving für Echtzeit-Inferenz

Tools: Feast, Tecton, Hopsworks, AWS SageMaker Feature Store

Wie unterscheidet sich MLOps bei LLMs / Foundation Models?

LLMOps erweitert MLOps um spezifische Herausforderungen großer Sprachmodelle:

  • Prompt Versioning: Prompts statt klassischer Features versionieren
  • RAG-Pipelines: Retrieval-Augmented Generation als zusätzlicher Pipeline-Schritt
  • Evaluation: LLM-as-Judge, Human Eval statt klassischer Metriken
  • Guardrails: Content-Filtering und Safety-Layer in Produktion
  • Kosten-Monitoring: Token-Verbrauch und API-Kosten tracken
Cloud vs. On-Premise MLOps – was ist besser?

Cloud (AWS/GCP/Azure): Schnellster Start, managed Services, elastische GPU-Ressourcen. Ideal für Teams ohne eigene Infrastruktur. Nachteil: Vendor Lock-in, laufende Kosten.

On-Premise (Kubeflow/ZenML): Volle Kontrolle, Datenschutz, keine laufenden Cloud-Kosten. Ideal für regulierte Branchen (Finanz, Gesundheit). Nachteil: Höherer Setup-Aufwand, eigenes Ops-Team nötig.

Hybrid: Training in der Cloud (GPU), Serving On-Premise. Beste Kombination für viele Enterprise-Szenarien.

Was ist Training-Serving Skew und wie vermeide ich ihn?

Training-Serving Skew tritt auf, wenn die Datenverarbeitung beim Training und beim Serving unterschiedlich ist. Das Modell wurde mit anderen Features trainiert als es in Produktion erhält → Performance-Einbruch.

Lösungen:

  • Feature Store für konsistente Transformationen
  • Identische Preprocessing-Pipeline für Training & Serving
  • Unit Tests für Feature-Transformationen
  • Schema-Validierung vor der Inferenz
Wie starte ich mit MLOps in meinem Team?

Schritt-für-Schritt-Einführung:

  1. Woche 1-2: MLflow oder W&B für Experiment-Tracking einführen
  2. Monat 1: Model Registry etablieren, DVC für Daten-Versionierung
  3. Monat 2-3: Erste CI-Pipeline für Modell-Validation
  4. Monat 3-6: CD-Pipeline für automatisches Deployment
  5. Monat 6+: Monitoring, Drift-Detection, Governance

Wichtig: Nicht alles auf einmal. Jeder Schritt liefert sofort Mehrwert.

Zusammenfassung

Die wichtigsten Punkte

  • MLOps vereint ML, DevOps und Data Engineering für zuverlässige ML-Systeme in Produktion
  • Kernpraktiken: Versionierung (Code + Daten + Modell), Experiment Tracking, CI/CD, Monitoring, Registry, Governance
  • Lebenszyklus: Daten → Experiment → Evaluation → Registry → Deployment → Monitoring → Retraining
  • Reifegrade: Level 0 (manuell) → Level 1 (Pipeline-Automation) → Level 2 (volle CI/CD)
  • Tools: MLflow, W&B, Kubeflow, Airflow, DVC, Evidently, Vertex AI, SageMaker
  • Monitoring: Data Drift, Concept Drift, Performance-Degradation, Fairness
  • LLMOps: Erweiterung für LLMs mit Prompt-Versioning, RAG, Guardrails
  • Start: Iterativ vorgehen – zuerst Tracking, dann Registry, dann CI/CD

Nächste Schritte

MLOps ist kein Produkt, sondern eine organisatorische Fähigkeit. Beginnen Sie klein, messen Sie den Fortschritt und skalieren Sie schrittweise. Das Ziel ist nicht perfekte Automatisierung, sondern zuverlässige, reproduzierbare ML-Systeme, die Geschäftswert liefern.

Weiterführende Themen

LLM Grundlagen

Architektur, Training und Einsatz großer Sprachmodelle verstehen.

Zu LLM Grundlagen
Prompt Engineering

Effektive Prompts schreiben, Chain-of-Thought, Few-Shot Learning.

Zu Prompt Engineering
RAG

Retrieval-Augmented Generation – externe Wissensbasen mit LLMs verbinden.

Zu RAG
KI-Sicherheit

Adversarial Attacks, Prompt Injection, Safety und Responsible AI.

Zur KI-Sicherheit