On-Premise ML-Infrastruktur vs. Cloud-Training: eine technische Entscheidungsgrundlage für industrielle KI

Problem zuerst: Die meisten Industrieunternehmen scheitern nicht an Modellen, sondern an der Infrastruktur drum herum. Ein Bildverarbeitungsmodell für die visuelle Qualitätsprüfung ist schnell in einem Notebook prototypisiert. Es in der Fertigung zu trainieren, zu versionieren, zu deployen und dauerhaft zu überwachen – ohne Daten das Werk zu verlassen und ohne Produktionsstillstand – ist die eigentliche Ingenieursaufgabe. Genau hier entscheidet sich: baue ich eine eigene GPU-Cluster-Infrastruktur On-Premise oder nutze ich Cloud-Training?

Dieser Text legt eine technische Grundlage für diese Entscheidung. Keine Hochglanzphrasen, sondern Architekturmuster, Betriebsrealität und harte Trade-offs aus industriellen Projekten.

1) Workload-Charakterisierung: Was trainieren und betreiben wir wirklich?

Bevor man über Hardware oder Cloudanbieter spricht, muss klar sein, welche Lasten überhaupt anstehen. Drei typische Klassen in der Industrie:

  • Klassisches CV/NLP-Training: Batch-Training von Modellen (ResNet, YOLO, U-Net, BERT-Varianten) mit mittelgroßen Datensätzen (100 GB – einige TB), regelmäßiges Retraining, klare Abnahmezyklen.
  • LLM-/Foundation-Model-Fine-Tuning und Inferenz: LoRA/QLoRA-Fine-Tuning, Adapters, RAG-Pipelines. Training eher I/O-arm, GPU-RAM-lastig; Inferenz latenzsensibel, skalierend über mehrere Mikroservices.
  • Zeitreihen/Anomaly Detection: Viele kleine Modelle pro Asset-Linie, Edge-nahe Inferenz, zentrales Training; hoher Daten-Durchsatz, stark automatisierte Pipelines.

Diese Lastprofile bestimmen Architektur- und Technologieentscheidungen deutlich stärker als “Cloud vs. On-Prem” im Abstrakten.

2) Die echten Entscheidungskriterien

Vergesst generische Checklisten. Folgende Parameter tragen die Entscheidung in der Praxis:

  • Datensouveränität und Datenlokalität: Darf Rohdatenmaterial (Kamerastreams, Maschinentelemetrie, Wartungsprotokolle) das Werk, Land oder Unternehmensnetz verlassen? Wie werden personenbezogene Daten im ML-Kontext behandelt (z. B. Logdaten, Annotationen)? Je strenger, desto eher On-Prem.
  • Netzwerktopologie und Daten-Gravitation: TB–PB an Daten pro Woche? Schlechte WAN-Anbindung? Dann wird jeder Upload zur Cloud ein Projekt für sich. Caching und komprimierte Extrakte helfen, beheben aber kein strukturelles Problem.
  • Auslastung und Taktung: Haben Sie einen kontinuierlichen Trainingsbedarf (Retraining, mehrere Produktlinien, Experimentierkultur) oder unregelmäßige Big-Bang-Trainings? Kontinuierliche Auslastung favorisiert On-Prem (CapEx amortisiert sich), sporadische Spitzen sprechen für Cloud-Bursting.
  • Betriebshoheit und Änderungszyklen: Müssen Sie Air-Gaps einhalten, Upgrades kontrolliert freigeben, Zulassungen dokumentieren? On-Prem gibt Ihnen maximale Kontrolle, Cloud beschleunigt Experimentieren – beides lässt sich kombinieren.
  • Teamkompetenz und Tooling: Können Sie einen GPU-Cluster betreiben (Kubernetes/Slurm, Treiber, Firmware, Storage)? Oder möchten Sie Infrastruktur als Code in der Cloud starten und den operativen Overhead minimieren?
  • Total Cost of Ownership (TCO): Nicht nur GPU-Preise. Energie, Kühlung, Racks, Netzwerk, Admin-Kapazität, Ersatzteile, Lieferzeiten vs. Cloud-Listenpreise, Rabatte, Auslastungsrisiko, Daten-Egress.

3) On-Prem GPU-Cluster: Referenzarchitektur, die in der Industrie funktioniert

Ein tragfähiges On-Prem-Design folgt wenigen robusten Prinzipien:

Compute

  • GPU-Knoten mit lokalen NVMe-Scratch-SSDs für Trainingsdaten-Caches und Checkpoints.

  • NVIDIA GPU-Stacks mit Containerisierung (NVIDIA Container Toolkit), Treiber- und CUDA-Management klar versioniert.

  • Partitionierung via MIG (auf A100/Hopper), falls Workloads variieren (Training vs. Inferenz vs. Batch-ETL).

  • Optional vGPU-Virtualisierung für Multi-Tenant-Umgebungen mit weichen SLAs.

Orchestrierung

  • Zwei bewährte Pfade:

  • Kubernetes für containerisierte Workloads, Multi-Tenancy, reproduzierbare Pipelines, LLM-Serving. Add-ons: NVIDIA GPU Operator, Volcano oder Kueue für Batch-Scheduling, Kubeflow/Ray für verteiltes Training, Argo Workflows für ML-Pipelines.

  • Slurm für klassisches HPC-Training und enge Kontrolle über Topologie und Scheduling. Beliebt, wenn große, homogene Trainingsjobs dominieren.

  • In der Praxis sind hybride Setups häufig: K8s für MLOps, Microservices und Inferenz; Slurm für die ganz großen, eng gekoppelten Trainingsjobs.

Storage

  • Dreistufig:

  • Objekt-Storage (S3-kompatibel), z. B. MinIO oder Ceph RGW, als System-of-Record für Datasets, Artefakte, Checkpoints.

  • Hochperformantes paralleles Dateisystem (BeeGFS, Lustre) für Trainingsläufe mit vielen kleinen Dateien und hohem IOPS-Bedarf.

  • Lokale NVMe-Caches pro Node für schnelle epoch-lokale Zugriffe; Koordination über Cache-Keys, nicht über “magische” NFS-Mounts.

  • Datenversionierung: LakeFS oder DVC über dem Objekt-Store, um Datasets transaktional und reproduzierbar zu referenzieren.

Netzwerk

  • RDMA-fähig (InfiniBand oder RoCEv2) für verteiltes Training (NCCL). Topologie mit geringer Oversubscription planen; Trainingsjobs sind hier gnadenlos.

  • Separates Storage- und Management-Netz. Kein späteres “wir legen noch VLANs drauf” – planen Sie Segmente von Beginn an.

MLOps-Bausteine

  • Experiment- und Modell-Registry (z. B. MLflow) On-Prem, Artefaktverwaltung via Objektspeicher.

  • Container-Registry On-Prem (Harbor), mit Image-Signing und CVE-Scanning.

  • Orchestrierung: Argo Workflows oder Airflow für ETL/ELT und Trainingspipelines.

  • Feature-Store: Open-Source-Stack (z. B. Feast) auf On-Prem-Kafka/Objektspeicher.

  • Observability: Prometheus/Grafana für GPU-, I/O- und Pipeline-Metriken; EFK/ELK für Logs; Tracing (OpenTelemetry) für Inferenzpfade.

  • Security: Secret-Management (HashiCorp Vault), Policy-Enforcement (OPA Gatekeeper/Kyverno), Admission Controller, signierte SBOMs für Images.

Souveränität und Compliance

  • Identity und Zugriff: OIDC mit eigenem IdP (z. B. Keycloak), rollenbasiert, Audit-Logs verpflichtend.

  • Air-Gap-fähige Updates: Spiegel-Registries, periodische Offline-Updates, reproduzierbare Builds.

  • Datenflüsse: Pseudonymisierung/Anonymisierung vor Persistenz, klare Data Contracts pro Pipeline, keine Schatten-Persistenz in Notebooks.

4) Cloud-Training: was es in der Praxis stark macht

Die Cloud glänzt dort, wo Variabilität und Geschwindigkeit dominieren:

  • Elastizität: Ephemere GPU-Cluster für große Experimente, ohne monatelange Beschaffung.
  • Managed-Komponenten: Objekt-Store, Queues, Monitoring-Dienste reduzieren den Infrastruktur-Overhead.
  • Spot/Preemptible-Instanzen: Für fehlertolerantes Training signifikante Kostenvorteile, wenn Checkpointing robust implementiert ist.
  • Entwicklungsbeschleunigung: Neue Hardware-Generationen sind früh verfügbar; Testen und Benchmarking vor Kaufentscheidungen möglich.