• Netzwerkeinschränkungen: Kein Internetzugang aus Produktionszonen. Alle Abhängigkeiten müssen gespiegelt, reproduzierbar, offline installierbar sein.
  • Langlebigkeit: Modelle müssen über Jahre wartbar bleiben (Reproduzierbarkeit, Artefaktversionierung, Abhängigkeiten eingefroren).
  • Safety und Verfügbarkeit: Fallback‑Verhalten definiert; Degradationsmodi ohne Produktionsstillstand.

Bewährte Architekturbausteine für industrielles MLOps:

  • Versionsführung:

  • Code in Git, Daten/Artefakte versioniert (z. B. objektbasiert im Lake mit Commit‑Semantik; Dataset‑Versionierung via Manifesten).

  • Feature‑Pipelines definieren Contracts; Online/Offline‑Feature‑Parität sicherstellen.

  • Pipeline‑Orchestrierung:

  • Reproduzierbare DAGs (Container‑basiert), klare Trennung von Build/Train/Evaluate/Deploy.

  • CI/CD mit Staging‑Umgebungen; für Models: Canary/Shadow Deployments, explizite Promotion‑Gates (Qualitätsmetriken, Bias‑Checks, Drift‑Checks).

  • Model Registry und Governance:

  • Modellartefakte mit Metadaten (Trainingsdaten‑Version, Hyperparameter, Evaluationsmetriken, Gültigkeitsbereich).

  • Auditierbare Freigabeprozesse mit 4‑Augen‑Prinzip.

  • Inferenz‑Deployment:

  • Zentral (Kubernetes/KServe‑Prinzip) für IT‑nahe Services.

  • Edge‑Inference für Latenz/Verfügbarkeit (z. B. optimiert mit ONNX‑Runtime/TensorRT‑Prinzipien, Quantisierung, INT8‑Kalibrierung). Offline‑Fallback definieren.

  • Observability:

  • Telemetrie (OpenTelemetry‑Prinzip), Metriken (Prometheus‑Stil), Logs, Traces über den gesamten Pfad: Datenqualität → Feature‑Drift → Modellleistung → Ressourcen.

  • Daten‑ und Konzeptdrift‑Detektion mit Alarmierungs‑Workflows; Sampling‑Strategien für Ground‑Truth‑Nachbeschriftung aus der Produktion.

  • Sicherheit:

  • Signierte Container/Artefakte (Supply‑Chain‑Security, SBOMs).

  • Isolierte GPU‑Workloads; Ressourcenquoten; Secrets‑Management im Cluster.

  • Dokumentation:

  • Modellkarten, Betriebs‑Handbücher, Notfallprozeduren. Schulung der Instandhaltung, wie Edge‑Geräte sicher upzudaten sind.

Für Computer Vision in der Qualitätssicherung ist Dataset‑Management der Engpass:

  • Annotationen sind Datenprodukte mit eigenem Lebenszyklus.

  • Train/Validation/Test‑Splits müssen Produktionsvarianten repräsentieren (Schicht, Linie, Lieferant, Charge).

  • Kontinuierliches Learning braucht klare Regeln gegen Datenleckage und „catastrophic forgetting“.

Für LLM‑gestützte Assistenz (z. B. SOP‑Suche, Störungssuche) gilt:

  • RAG‑Pipelines strikt on‑prem: Dokumente (SOPs, Tickets, Logs) werden im Lake indiziert, Embeddings lokal erzeugt, Vektorsuche im internen Speicher. Keine Calls ins Internet.

  • Observability/Guardrails für Agenten: Pro Prompt Trace, Tool‑Nutzung, Antwortquellen, Policy‑Checks (keine personenbezogenen Daten ausgeben, nur freigegebene Dokumente zitieren). Fehlermodi müssen nachvollziehbar sein.

4) On‑Prem‑GPU‑Cluster vs. Cloud‑Training: eine nüchterne Abwägung

Die Entscheidung ist kein Dogma, sondern Abgleich von Randbedingungen:

Gründe für On‑Prem:

  • Datengravitation und Souveränität: Rohdaten bleiben in der Fabrik/im Rechenzentrum; keine Egress‑Risiken.

  • Vorhersagbare Auslastung: Kontinuierliches Training oder viele parallele Experimente rechtfertigen CAPEX.

  • Netzrestriktionen: Trainingsdaten dürfen die OT/IT‑Grenzen nicht verlassen; air‑gapped Setups.

Gründe für Cloud:

  • Elastizität für kurzzeitige Peaks (z. B. Hyperparameter‑Sweeps).

  • Zugang zu neuesten Beschleunigern ohne Lieferzeiten, sofern Daten rechtskonform nutzbar sind.

On‑Prem‑Cluster‑Blueprint für Industrie:

  • Rechencluster:

  • GPU‑Knoten mit ausreichender PCIe‑Bandbreite und NVLink (wo verfügbar).

  • Scheduler: Kubernetes mit GPU‑Device‑Plugins für Inferenz‑Dienste; optional Slurm/Batch für Trainingsjobs. Partitionierung der GPUs (MIG‑Prinzip) für kleinere Jobs.

  • Netzwerk/Storage:

  • Hochdurchsatz‑Netz (mindestens 25/100 GbE; bei großem verteilten Training: RDMA/IB).

  • Objekt‑Storage (S3‑kompatibel) mit Erasure Coding für Daten; NVMe‑Lokalspeicher für Zwischenergebnisse. Für gemeinsame POSIX‑Bedürfnisse: parallele Filesysteme oder verteilte Dateidienste.

  • Software‑Stack:

  • Container‑Runtime mit GPU‑Support; Artefakt‑Registry on‑prem, gespiegelte Basisimages.

  • Orchestrierung/ML‑Pipelines; Model Registry; Feature Store; Monitoring/Logging.

  • Betriebsaspekte:

  • Strom/Kühlung dimensionieren; Hot/Cold‑Standby; Ersatzteil‑ und Treiber‑Management.

  • Auslastungsmanagement: Quoten, Preemption, Fair‑Share. Ohne hohe Auslastung kippt die TCO.

Hybride Muster:

  • Daten bleiben on‑prem; Modellgewichte (ohne sensible Daten) können in eine Cloud gespiegelt werden, um dort auf synthetischen/öffentlichen Datasets vorzutrainieren. Feintuning on‑prem.

  • Federated‑Learning‑Ansätze zwischen Werken, bei denen nur Gradienten/Modelldeltas synchronisiert werden – mit kryptografischen Schutzmaßnahmen –, können Datensouveränität wahren und dennoch gemeinsame Lernfortschritte ermöglichen.

5) Eine belastbare Referenzarchitektur – Bauteile und Flüsse

Edge (Werk/Halle/Lok):

  • Datenerfassung:

  • OT‑Konnektoren (OPC UA/MQTT‑Gateways), Kamera‑Ingest (GStreamer‑Prinzip), lokale Vorverarbeitung.

  • Schema‑Validierung schon am Rand (Reject early).

  • Pseudonymisierung/Maskierung:

  • Video‑Redaktion (Face/Person blurring), Tokenisierung personenbezogener Ereignisfelder.

  • Kurzzeit‑Speicher:

  • Lokaler Objekt‑Store/Ringpuffer; Edge‑Timeseries‑DB für schnelle Diagnosen.

  • Store‑and‑Forward:

  • Ereignisgesteuerte Synchronisierung in Zentrale; robuste Queues, die Netzabbrüche überstehen.

Core Rechenzentrum:

  • Datenbackbone:

  • Streaming (Kafka‑Prinzip) mit Schema Registry; Batch‑Ingest via CDC für MES/ERP.

  • Speicher:

  • S3‑kompatibler Object Store (WORM‑Buckets für Audit), Lakehouse‑Katalog (Tabellen‑Metadaten, Time‑Travel), Partitionsstrategie.

  • Datenqualität/Governance:

  • Data Contracts, automatisierte Tests (z. B. Wertebereiche, Vollständigkeit), Quarantäne‑Zonen bei Verstößen.

  • Katalog und Lineage; Self‑Service‑Zugriff mit feingranularen Policies.

  • Compute:

  • Kubernetes‑Cluster (getrennte Nodes für CPU/GPU), CI/CD‑Pipelines, Signierung.

  • Trainings‑Queue (Slurm oder dedizierte Namespaces), Artefakt‑Registry.

  • MLOps‑Schicht:

  • Experiment‑Tracking, Model Registry, Feature‑Pipelines, Evaluationsframeworks.

  • Deployment Layer für Online/Batch/Edge‑Targets.

  • Observability:

  • Metriken, Logs, Traces vereinheitlicht; Drift‑Services; Alerting.

  • Sicherheit:

  • mTLS, IAM, OPA‑Policies, Secret‑Management, Schlüssel im HSM, Audit‑Logs.

RAG/LLM‑Spezifika:

  • Dokumentenaufnahme mit OCR, Normalisierung von CAD/PDF/Scans.

  • Embedding‑Pipeline on‑prem; Vektorspeicher intern (z. B. in einem DB‑System mit Vektor‑Index).

  • Prompt‑ und Retrieval‑Evaluation mit Benchmark‑Sätzen aus realen Tickets/SOP‑Fragen.

  • Agenten‑Observability und Guardrails: Tool‑Aufrufe, Quellenzitate, Policy‑Checks, Fail‑Safe‑Antworten.

6) Data Mesh in der Praxis: So wird es in Werken beherrschbar