• Souveränitätsprinzipien
  • Keine harte Abhängigkeit von US-Cloud-Kontroll-Ebenen (Identity, Policy, Observability lokal).
  • Artefakt-Repositories, Container-Registry (z.B. Harbor) und Paketspiegel on-prem; SBOM- und Vulnerability-Scanning.
  • Air-Gap-taugliche Upgrades und Reproducibility (Infra-as-Code, deterministische Builds).

Diese Maßnahmen sind keine Kür – sie reduzieren Integrationsreibung, Auditkosten und rechtliche Risiken.

4) MLOps in der Industrie: trainieren, deployen, überwachen – mit Produktionsreife

MLOps muss an Produktionsrealität angepasst sein. Das gilt für Computer Vision am Band ebenso wie für Text-/LLM-Agenten in Instandhaltungs-Workflows.

Daten- und Experimentmanagement

  • Datenversionierung: LakeFS/DVC über dem Lakehouse; Snapshots machen Datenschnitte für Trainings reproduzierbar.

  • Feature Store: offline auf Iceberg/Parquet, online auf Redis/SQLite/PG nahe am Einsatzort. Konsistenz über Feature-Views und feste Join-Keys.

  • Experiment-Tracking: selbstgehostet (z.B. MLflow), Artefakt-Registries und Model Registry mit Stufen (Staging/Prod), Freigabeworkflows.

CI/CD und Qualität

  • GitOps-Pipelines (GitLab CI + ArgoCD) bauen Container, validieren Modelle, führen Regression-/Bias-/Robustheitstests aus.

  • Daten- und Modell-Unit-Tests gehören in denselben PR-Gate wie Code.

  • Champion/Challenger-Rollouts und reproduzierbare Promotion mit signierten Artefakten.

Deployment-Modelle

  • Batch-Scoring: periodisch auf dem Lake, ergebnisgetrieben (Reworks, Wartungsplanung).

  • Streaming-Inferenz: KServe/Triton, asynchrone Pufferung, Backpressure-Strategien.

  • Edge-Deployment: signierte Container/Modelle, Offline-Fallback, sichere Remote-Updates über Maintenance-Fenster.

Monitoring und Observability

  • Systemmetriken (Prometheus/Grafana), Logs (Loki/ELK), Traces (OpenTelemetry) – einheitlicher Stack.

  • ML-spezifisches Monitoring: Daten-/Konzeptdrift, Outlier-Raten, Qualitätsmetriken aus der Domäne (z.B. False Rejects in der Qualitätskontrolle).

  • LLM-Agenten: Prompt-/Tool-Aufrufe, Response-Attribution, Offline-Evaluationssuiten, Guardrails und Policy-Enforcement. Hierfür braucht es eine Governance-Schicht, die Agentenverhalten messbar und auditierbar macht. In stark regulierten Setups setzen wir dafür eine on-prem Observability- und Governance-Plattform ein (z.B. Alpi-M), die ohne externen Cloud-Zugriff auskommt.

Safety und Betrieb

  • Rollbacks sind First-Class: deterministische Re-Deployments, immutable Releases, klarer Pfad zurück.

  • Change-Management integriert Freigaben (Vier-Augen-Prinzip), Wartungsfenster und Notfallprozesse.

  • Dokumentation ist Teil der Pipeline: automatisch generierte Model Cards und Data Cards aus Metadaten.

Anti-Pattern vermeiden

  • Historian als Feature Store zu missbrauchen.

  • Ein „One-Size-MLOps-Tool“, das Portabilität killt.

  • Monitoring nachträglich „dranzubauen“.

5) On-Prem GPU-Cluster vs Cloud-Training: eine nüchterne Abwägung

Es gibt kein Dogma – aber es gibt harte Rahmenbedingungen, die die Wahl diktieren.

On-Prem-Cluster sind sinnvoll, wenn

  • Datenbewegung verboten, teuer oder riskant ist (Air-Gap, Exportkontrolle, personenbezogene Qualitätsdaten).

  • Workloads planbar kontinuierlich sind (ständige CV-Trainings, Retrainings, Inferenz in Nähe zur Linie).

  • Sie Kontrolle über Software-Stack und Latenz brauchen (Treiber, Kernel, Echtzeit-Anforderungen).

Cloud-Training ist hilfreich, wenn

  • kurzzeitig massiv skaliert werden muss (Hyperparameter-Sweeps, Foundation-Modell-Feintuning unter Zeitdruck).

  • Sie Explorationsspitzen haben, die on-prem wirtschaftlich keinen Sinn ergeben.

  • Sie bewusst nicht-sensible Public-Daten für Vortrainings nutzen.

Technische Designentscheidungen on-prem

  • Scheduling: Kubernetes + NVIDIA GPU Operator für gemischte Workloads und Inferenz; Slurm für klassische HPC-Trainings; Hybrid ist üblich. Kubernetes mit Batch-Scheduler (z.B. Volcano) schlägt oft die Brücke.

  • Multi-Tenancy: MIG/Time-Slicing, Quotas, isolierte Namespaces/Queues, GPU-Reservationen für deterministische Performance.

  • Storage: schnelles Shared-Dateisystem (BeeGFS/Lustre) für verteiltes Training; Object Store plus Dataset-Caching (z.B. Alluxio) für große Korpora; lokales NVMe für Zwischenschritte.

  • Netzwerk: 100GbE/RoCEv2 oder Infiniband für AllReduce-lastige Trainings, QoS-konform zur OT-Segmentierung.

  • Artefakte: on-prem Registry (Harbor), signierte Images, SBOM-Scans, Lizenzen eindeutig geklärt. Model-Transfer aus der Cloud über dedizierte Quarantäne und Scans, kein direkter Produktionspfad.

  • Energie/Thermik/Platz: früh mit Facilities planen; thermische Budgetierung und Redundanzen sind kein nachträgliches Detail.

Die elegante Lösung ist oft ein Hybrid: Exploratives Pre-Training in der Cloud mit klarer Trennung und kuratiertem Transfer der Ergebnisse; produktionsnahe Feintunes und Inferenz on-prem.

6) Ein referenzierbares Blueprint für Brownfield-Industrie

Ein funktionierender Pfad von 0 auf produktionsreif vermeidet Big Bangs und setzt klare Meilensteine.

Phase 0 – Rahmenwerk

  • Identitäts- und Rechtemodell festlegen (zentrale IAM).

  • Datenprodukte schneiden, Eigentümer benennen, Datenverträge grob definieren.

  • Lakehouse-Format wählen (Iceberg/Delta), Katalog- und Lineage-Tooling aufsetzen.

Phase 1 – Ingest und Lakehouse

  • Streaming- und Batch-Ingestion mit Schema-Validierung, Idempotenz, Checksummen.

  • Objektstorage bereitstellen, Storage-Klassen und Bucket-Policies definieren.

  • Bronze/Silver/Gold-Schichten etablieren, Qualitätsgates dazwischen.

  • Lineage erfassen, Katalog pflegen, erste Domänenprodukte (z.B. Qualitätsdaten, Instandhaltung).

Phase 2 – MLOps-Kern

  • Experiment-Tracking, Feature Store, Model Registry einführen.

  • CI/CD-Pipelines für Daten- und Modelläufe, inklusive Tests und Signatur.

  • Batch-Inferenz betreiben (z.B. Risikoscoring für Anlagen, wöchentlicher Planungsinput).

  • DSGVO-Bausteine scharf stellen: Pseudonymisierung, Löschprozesse, Audit.

Phase 3 – Echtzeit, Edge, GPU

  • Streaming-Inferenz und On-Prem-GPU-Cluster für CV/LLM-Workloads.

  • Edge-Deployments mit signierten Artefakten, Offline-Fallback.

  • LLM-Agenten-Governance ergänzen (Observability, Guardrails, Tool-Use-Policies).

  • Betriebsprozesse verankern: Incident-Response, Rollback, Kapazitätsplanung.

Steuerungsmesszahlen (ohne Vanity-Metrics)

  • Lead Time für ein neues Datenprodukt (Commit bis konsumierbar in Gold).

  • MTTD für Daten-/Modell-Drift.

  • Zeit bis Modell-Rollback (Alarm bis Rückkehr zu Champion).

  • SLA für DSGVO-Löschanfragen (Annahme bis technische Vollumsetzung).

  • Anteil automatisierter Qualitäts-Gates, die Fehler vor Production-Promotion abfangen.

7) Häufige Fehltritte und wie man sie vermeidet