1. Warum ML-Pipeline-Architektur wichtig ist
95% Accuracy im Notebook ist spannend. 1 Mio. Vorhersagen pro Tag stabil zu serven ist Ingenieursarbeit. Der Unterschied zwischen Research und Produktion ist Architektur—die Systeme, die Modelle trainieren, deployen, überwachen und laufend verbessern.
Die Produktionslücke
87% der ML-Projekte erreichen nie Produktion. Grund: Modelle ohne Deployment-, Monitoring- oder Retraining-Plan. Ein Modell ohne Infrastruktur ist ein teures Experiment.
Eine gute ML-Architektur liefert vier Ergebnisse:
Zuverlässige Vorhersagen
99,9% Uptime und <100ms Latenz. Keine "Model ist down"-Tickets mehr um 3 Uhr.
Kontinuierliche Verbesserung
Automatisierte Retraining-Pipelines halten Modelle frisch. Neue Versionen wöchentlich oder täglich ohne manuelle Eingriffe.
Observability
Accuracy, Drift und Business-Metriken in Echtzeit tracken. Degradierung erkennen, bevor User es merken.
Teamgeschwindigkeit
Data Scientists iterieren ohne auf Engineers zu warten. Geteilte Infra = schnellere Experimente.
Aus der Praxis
Teams mit großartigen Modellen scheitern ohne Serving-Infrastruktur. Teams mit durchschnittlichen Modellen gewinnen, weil sie 10x schneller deployen. Architektur ist Wettbewerbsvorteil.
2. Kernkomponenten einer ML-Pipeline
Jede produktionsreife ML-Lösung hat sieben Bausteine. Wie ein Fließband: Daten rein, Modelle trainieren, Vorhersagen raus. Das macht jeder Baustein.
Dateningestion
FundamentRohdaten aus Datenbanken, APIs, Events und Logs sammeln. In Data Lake (S3/GCS) oder Warehouse (Snowflake/BigQuery) ablegen.
Tools: Fivetran, Airbyte, Kafka, AWS Kinesis, dbt für Transformationen
Feature Engineering
KritischRohdaten in Features transformieren. Aggregationen, Encodings, Embeddings berechnen. Im Feature Store für Wiederverwendung speichern.
Tools: Feast, Tecton, Databricks Feature Store, eigene Pipelines (Spark/dbt)
Trainings-Pipeline
KernModelle auf historischen Daten trainieren. Experimente, Hyperparameter und Metriken tracken. Auf Holdout-Sets validieren.
Tools: MLflow, Weights & Biases, Kubeflow, Vertex AI, SageMaker Training
Modell-Registry
VersionierungTrainierte Modelle versionieren. Welches Modell läuft in Prod, Staging, Archiv? Metadaten speichern.
Tools: MLflow Model Registry, Vertex AI Model Registry, S3 + Metadaten-DB
Serving-Infrastruktur
ProduktionModelle als REST-APIs oder Batch-Jobs deployen. Scaling, Load Balancing und Failover automatisch handeln.
Tools: TensorFlow Serving, TorchServe, Seldon, KServe, AWS SageMaker, Vertex AI
Monitoring & Observability
OperationenModellperformance, Datendrift, Latenz und Fehler tracken. Alarmieren, wenn Qualität sinkt.
Tools: Arize, WhyLabs, Evidently AI, eigene Grafana + Prometheus Dashboards
Orchestrierung
AutomationTraining, Validierung, Deployment koordinieren. Retraining-Jobs planen. Abhängigkeiten managen.
Tools: Airflow, Prefect, Dagster, Kubeflow Pipelines, AWS Step Functions
| Komponente | Zweck | Latenz | Kritisch für |
|---|---|---|---|
| Ingestion | Rohdaten sammeln | Minuten bis Stunden | Datenaktualität |
| Feature Engineering | In Features transformieren | Batch: Stunden / Online: ms | Modellqualität |
| Training | Modelle erstellen | Stunden bis Tage | Accuracy |
| Registry | Modelle versionieren | Sofort | Governance |
| Serving | Vorhersagen erzeugen | <100ms | User Experience |
| Monitoring | Performance tracken | Echtzeit | Zuverlässigkeit |
| Orchestrierung | Workflows automatisieren | Variabel | Automation |
3. Häufige ML-Architektur-Patterns
Unterschiedliche ML-Cases brauchen unterschiedliche Architekturen. Empfehlungen vs. Fraud Detection haben andere Anforderungen. Diese fünf Patterns decken 90% der produktiven ML-Systeme ab.
Batch-Prediction-Pipeline
Vorhersagen über Nacht für alle Nutzer berechnen. In einer Datenbank speichern. Vorgefertigte Ergebnisse serven.
Am besten für
- Produktempfehlungen
- Churn Scores
- Email-Targeting-Listen
- Tägliche Risiko-Scores
Trade-offs
- Vorhersagen können 6-24h alt sein
- Keine Reaktion auf Events in Echtzeit
- Speicherbedarf für alle Predictions
Echtzeit-Serving-Pipeline
Bei Nutzeranfrage on-demand vorhersagen. Features in Echtzeit holen, Modell-API aufrufen, Ergebnis zurückgeben.
Am besten für
- Betrugserkennung
- Dynamische Preise
- Content-Personalisierung
- Kreditentscheidungen
Trade-offs
- Höhere Infrastrukturkosten
- Komplexe Feature-Serving-Schicht
- Modelle mit niedriger Latenz nötig
Online-Learning-Pipeline
Modelle kontinuierlich aktualisieren, sobald neue Daten ankommen. Kein Batch-Retraining—Modelle entwickeln sich in Echtzeit.
Am besten für
- Ad-Click-Prediction
- News-Empfehlungen
- Real-Time Bidding
- Anomalieerkennung
Trade-offs
- Komplex in der Umsetzung
- Begrenzt auf bestimmte Modelltypen
- Drift-Debugging schwieriger
Hybrid: Batch + Echtzeit
Schwere Features im Batch berechnen, schnelle Features in Echtzeit. Beide für Predictions kombinieren.
Am besten für
- E-Commerce-Suchranking
- Ride-Share-Pricing
- Kreditvergabe
- Komplexe Personalisierung
Trade-offs
- Am komplexesten zu bauen
- Zwei Feature-Pipelines zu pflegen
- Synchronisation herausfordernd
Edge-ML-Pipeline
Modelle auf Edge-Geräte (Phones, IoT, Browser) deployen. Vorhersagen lokal, ohne Server-Calls.
Am besten für
- Mobile Apps (Face Recognition)
- IoT (Predictive Maintenance)
- Offline-first Apps
- Privacy-sensitive Use Cases
Trade-offs
- Modellgrößen-Beschränkung (<10MB)
- Begrenzte Rechenleistung
- Modelle schwerer zu aktualisieren
Dein Pattern wählen
Starte mit Batch, wenn 6-24h Verzögerung ok sind: am einfachsten und günstigsten. Gehe zu Echtzeit, wenn Latenz fürs Business zählt. Füge Online Learning hinzu, wenn Daten schneller driften als tägliches Retraining. Meist: 80% Batch-Modelle, 20% Echtzeit.
4. Schritt-für-Schritt Design-Prozess
Ein ML-Pipeline-Design ist wie eine Reiseplanung: Start (Datenquellen), Ziel (Business-Metrik), Stopps (Features, Modell, Predictions). Hier ein erprobter 7-Schritte-Prozess.
Business-Ziel & Erfolgsmetriken definieren
Starte mit dem Business-Outcome, nicht mit dem Modell. Welche Entscheidung verbessert das System? Wie misst du Erfolg?
Beispiel: E-Commerce Such-Ranking
- Ziel: Mehr Käufe aus Suche
- Primäre Metrik: Conversion Rate Suche→Kauf
- Sekundär: CTR, Umsatz pro Suche
- Modell-Metrik: NDCG@10 (Ranking-Qualität)
Datenquellen & Verfügbarkeit mappen
Wo liegen die Daten und wie frisch müssen sie sein? Das bestimmt die Architektur.
Für Training
- User-Logs (S3)
- Produktkatalog (PostgreSQL)
- Kaufhistorie (Snowflake)
- Darf 1-7 Tage alt sein
Für Serving
- Echtzeit-Session-Kontext
- Produkt-Metadaten (Redis Cache)
- User-Profil (Feature Store)
- Ziel-Latenz <50ms
Feature-Pipeline designen
Plane, wie Rohdaten zu Features werden. Langsame (Batch) und schnelle (Online) Features trennen.
Batch-Features (täglich)
Käufe 30 Tage, Ø Warenkorb, Kategoriepräferenzen
Online-Features (on request)
Suchanfrage, aktueller Warenkorb, Tageszeit, Gerät
Trainings-Infrastruktur wählen
Wähle Tools nach Modellkomplexität, Datengröße und Retraining-Häufigkeit.
| Datengröße | Modelltyp | Infrastruktur |
|---|---|---|
| <10GB | XGBoost, LightGBM | Single VM, Jupyter |
| 10GB-1TB | Neural Nets, Ensembles | GPU VM, SageMaker |
| >1TB | Deep Learning | Distributed (Spark, Ray) |
Serving-Architektur designen
Batch-Vorhersagen (nachts) oder Echtzeit-API (on-demand) wählen.
Batch Serving
Für alle Nutzer vorhersagen → In DB speichern → App liest Scores
Best für: Tägliche Emails, Reports, Empfehlungslisten
Echtzeit-API
User-Request → Features holen → Modell aufrufen → Prediction (<100ms)
Best für: Fraud, dynamischer Content, Sofort-Entscheidungen
Monitoring & Alerts implementieren
Drei Kategorien tracken: Modellmetriken, Systemgesundheit, Business-Impact.
Modellmetriken
Accuracy, Precision, Recall, AUC
System Health
Latenz, Error Rate, Durchsatz
Business KPIs
Conversion, Umsatz, Engagement
Retraining & Deployment automatisieren
Orchestrierung aufsetzen, die bei Performance-Verlust oder nach Plan automatisch retrainiert.
02:00: Features extrahieren → Modell trainieren → Accuracy validieren
→ Wenn Accuracy > Schwelle: nach Staging deployen
→ A/B Test (10% Traffic)
→ Wenn Conversion steigt: in Produktion promoten
Einfach starten, dann iterieren
Baue nicht alles auf einmal. Starte mit manuellem Training + Batch-Predictions. Echtzeit hinzufügen, wenn nötig. Automatisches Retraining erst nach Basis-Monitoring. Jede Stufe: 1-2 Wochen.
5. ML-Architektur Best Practices
Diese Patterns unterscheiden Produktionssysteme von Prototypen. Gelernt von Teams mit hunderten Modellen im Einsatz.
Feature Stores für Konsistenz nutzen
Hauptursache für Prod-Fehler: Training-Serving-Skew. Feature Stores zentralisieren Definitionen und berechnen sie konsistent.
Regel: Features einmal definieren. Offline für Training (Spark Batch), online für Serving (Redis/DynamoDB) berechnen. Gleiches Code, andere Engine.
Datendrift monitoren, nicht nur Modellmetriken
Accuracy kann hoch bleiben, während Predictions wertlos werden, weil sich Input-Daten verändern. Feature-Verteilungen überwachen und bei Drift alarmieren.
Tracken: Mittelwert, Std-Abweichung, Nulls, Ausreißer je Feature. Prod vs Training wöchentlich vergleichen.
Alles versionieren: Daten, Features, Modelle, Code
Bei Fehlern musst du den exakten Trainingslauf reproduzieren können. Daten-Snapshots, Feature-Transformationen, Modell-Binaries und Code zusammen versionieren.
Pattern: Jede Modellversion verlinkt Daten-Snapshot (S3-Pfad), Feature-Commit (SHA), Code-Version, Hyperparameter.
Rollback mitplanen, nicht nur Rollout
Neue Modelle werden scheitern. Vorherige Version bereit halten. 90% Traffic alt, 10% neu. Bei Metrik-Abfall: sofort zurück.
Pattern: Shadow → 10% Canary → 50% Test → 100% Prod. Rollback ist ein Button, kein 2h-Einsatz.
Auf Inferenzkosten optimieren, nicht Trainingskosten
Trainierst du einmal, inferierst du Millionen Mal. Ein Modell für 100$ Training, aber 10.000$/Monat Serving ist schlecht. Früh an Größe, Latenz, GPU denken.
Decision Tree: Erreicht ein kleineres Modell (z.B. DistilBERT) 95% Accuracy für 1/10 der Kosten? Meist ja.
Circuit Breaker & Fallbacks einbauen
Modelle sind keine Datenbanken—sie fallen kreativ aus. Immer ein Fallback: Regelbasiert, gecachte Predictions oder graceful Degradation.
Beispiel: Fraud-Modell timeout → Heuristiken. Ranking fällt aus → Popularitäts-Results zeigen. Nie Fehler an Nutzer ausliefern.
6. ML-Pipeline Tools & Plattformen
Das ML-Tooling ist riesig. Hier eine kuratierte Liste nach Komponente, die wirklich zählt.
Feature Stores
Open Source
- Feast: Leichtgewichtig, super für Startups. Offline (S3/Snowflake) + Online (Redis) Features.
- Feathr (LinkedIn): Enterprise, komplexer Setup. Stark für große Batch-Features.
Managed
- Tecton: Best-in-Class, teuer. Echtzeit, Monitoring, Lineage integriert.
- Databricks Feature Store: Ideal bei Databricks-Stack. Delta Lake Integration.
Training & Experiment Tracking
Experiment Tracking
- MLflow: Standard, kostenlos. Experimente, Modelle, Deployments.
- Weights & Biases: Beste UI für Research. Realtime Visuals.
- Neptune.ai: Enterprise Features, Metadaten-Organisation.
Trainingsplattformen
- AWS SageMaker: End-to-End AWS. Training, Tuning, Serving integriert.
- Google Vertex AI: GCP-Äquivalent. Starkes AutoML.
- Azure ML: Azure-Integration. Starke Enterprise-Features.
Model Serving
Open Source
- TensorFlow Serving: Produktionsreif für TF-Modelle. gRPC + REST.
- TorchServe: Offiziell für PyTorch. Multi-Modell, A/B.
- KServe (Kubeflow): Kubernetes-native. Autoscaling, Canary.
Managed
- SageMaker Endpoints: Autoscaling, Multi-Modell. Teuer aber einfach.
- Vertex AI Prediction: GCP Managed Serving. Batch + Online.
- Seldon Deploy: Enterprise MLOps. Fortgeschrittene Deploy-Strategien.
Monitoring & Observability
Spezialisiertes ML-Monitoring
- Arize AI: Drift, Explainability, Root Cause.
- WhyLabs: Leicht und günstig. Stark für Data Quality.
- Evidently AI: Open Source. Drift-Reports, Dashboard-Integration.
Allgemeine Observability
- Prometheus + Grafana: Standard-Stack. Custom ML-Metriken + Alerts.
- Datadog: All-in-one APM. ML-spezifische Integrationen.
- New Relic: Gute ML-Features in aktuellen Versionen.
Orchestrierung
Generell
- Apache Airflow: Bewährt, großes Ökosystem. Python DAGs.
- Prefect: Moderne Airflow-Alternative. Besser für dynamische Flows.
- Dagster: Data-aware Orchestrierung. Top für Data+ML.
ML-spezifisch
- Kubeflow Pipelines: K8s-native ML-Pipelines. Steile Lernkurve.
- AWS Step Functions: Serverless Orchestrierung für SageMaker.
- Vertex AI Pipelines: GCP Managed Pipelines. TFX oder Kubeflow Backend.
Tools auswählen
Starte mit: MLflow (Tracking), SageMaker/Vertex (Training + Serving), Airflow (Orchestrierung), Prometheus (Monitoring). Deckt 80% ab. Spezialtools (Feast, Tecton, Arize) erst hinzufügen, wenn der Schmerz klar ist.
7. ML-Architektur Checkliste
Nutze diese Checkliste, um dein Design vor dem Bau zu validieren. Jeder Punkt verhindert einen typischen Prod-Ausfall.
Business-Metriken definiert
Primär (Conversion, Umsatz), Modell-Metrik (AUC, RMSE), Verbindung dokumentiert
Datenquellen dokumentiert
Trainingsdaten-Ort, Frische, Zugriffsrechte, Datenqualitäts-SLAs
Feature-Pipeline entworfen
Batch vs Online getrennt, Feature Store gewählt, Code wiederverwendbar
Trainings-Infrastruktur gewählt
Plattform (SageMaker/Vertex), Compute sizing, Tracking konfiguriert
Serving-Architektur definiert
Batch vs Echtzeit entschieden, Latenz-Ziel, Serving-Plattform
Modell-Registry implementiert
Versionen, Metadaten, Promotion-Workflow (Dev→Staging→Prod)
Monitoring konfiguriert
Modellmetriken, Drift, System-Health, Business KPIs + Alerts
Retraining automatisiert
Zeitplan (täglich/wöchentlich), Trigger, Validierungen vor Deployment
Rollback-Strategie vorhanden
Rücksprung auf Vorgänger in <5 Minuten, Canary, Blue-Green
Dokumentation geschrieben
Architekturdiagramm, Datenfluss, API-Contracts, Runbooks
8. Häufige Fragen
Was sind die Kernkomponenten einer ML-Pipeline?
Ingestion, Feature Engineering, Training, Modell-Registry, Serving, Monitoring und Orchestrierung.
Unterschied zwischen Trainings- und Serving-Pipeline?
Training verarbeitet historische Daten im Batch (Stunden bis Tage). Serving beantwortet Requests in Millisekunden. Training optimiert Genauigkeit, Serving Latenz/Verfügbarkeit.
Batch oder Echtzeit-Serving?
Batch (nachts) für Empfehlungen, Risikoscores, nicht dringende Fälle. Echtzeit für Fraud, dynamische Preise, User-Features. Oft eine Kombination.
Wie Feature Engineering in Produktion handhaben?
Feature Store nutzen, um Definitionen zu zentralisieren und Features in Training und Produktion konsistent bereitzustellen. Einmal definieren, offline + online berechnen.
Wie oft Modelle retrainieren?
Hängt von Drift ab. E-Commerce: täglich/wöchentlich. Fraud: alle paar Stunden. Kredit: monatlich/vierteljährlich. Retraining triggern, wenn Performance unter Schwelle fällt.
Größter Fehler in ML-Architektur?
Für das Modell statt fürs Business bauen. Monate für 1% mehr Accuracy statt schneller Iteration. Starte einfach: Batch, manuelles Retraining, Basic Monitoring. Komplexität nur bei klarem Bedarf.
Deine ML-Pipeline-Architektur entwerfen
Beschreibe dein ML-System in Klartext und erhalte in Sekunden ein professionelles Architekturdiagramm. Perfekt für Dokus, Präsentationen und Team-Alignment.
Verwandte Guides
Pipeline-Dokumentation
Pipelines verständlich und wartbar dokumentieren
Data-Lineage Best Practices
Datenfluss von Quelle bis Modell tracken
Data Quality Best Practices
Datenqualitäts-Monitoring für ML-Features
Databricks Plattform Diagramm
Databricks-Architekturen für ML Workloads
Medallion Architektur
Features mit Bronze/Silver/Gold strukturieren