On-Premise GPU-Cluster vs. Cloud-Training: Ein Architekturleitfaden für industrielle KI unter DSGVO und Datensouveränität

Ausgangslage: Das eigentliche Problem ist nicht „KI“, sondern Datenbewegung und Kontrolle
In der Industrie scheitern KI-Initiativen selten an Modellen. Sie scheitern an Datenwegen, an Compliance und an Betrieb. Sie sammeln Terabytes an Bilddaten aus der Fertigung, Zeitreihen aus Flotten, Dokumente mit Personenbezug – und stehen dann vor drei harten Zwängen:

  • DSGVO und Betriebsräte: Personen- und Ereignisdaten dürfen nicht unkontrolliert in externe Rechenzentren wandern.

  • IP-Schutz und Exportkontrolle: Prozessparameter, CAD, Sensorik und Fehlermuster sind geistiges Eigentum. Datenabfluss killt Wettbewerbsvorteile.

  • Deterministischer Betrieb: KI muss sich in OT-Umgebungen beweisen. Keine „best effort“-SaaS, sondern reproduzierbare Pipelines, definierte SLAs und auditierbare Entscheidungen.

Vor diesem Hintergrund ist die Frage „On-Premise GPU-Cluster oder Cloud-Training?“ keine Kostenfrage allein. Es ist eine Frage der Souveränität, der technischen Passung zum Workload und der Beherrschbarkeit des Gesamtsystems.

Workload-Profile zuerst, Technologie danach
Bevor Sie Hardware kaufen oder Cloud-Budgets freigeben, klassifizieren Sie Ihre Trainings- und Inferenzlasten. Vier typische Klassen in der Industrie:

  • Computer Vision (CV) für visuelle Prüfung: Hohe Datenmengen (Bilder/Videos), moderates bis hohes GPU-Bedürfnis, hoher I/O-Durchsatz, häufiges Retraining bei Linien- oder Lieferantenwechsel.

  • Zeitreihen/Anomalieerkennung: Hohe Datenrate, oft CPU- oder Speicherbandbreitendominiert, moderate GPU-Nutzung, starker Fokus auf Feature-Engineering und Drift-Überwachung.

  • Dokumenten- und Textverarbeitung inkl. LLM-Finetuning: Hoher Speicherbedarf pro GPU, meist geringere I/O-Last als CV, sensible personenbezogene Daten, Governance und Prompt/Output-Logging kritisch.

  • Multimodale oder Simulations-unterstützte Verfahren (z. B. digitale Zwillinge): Mischlasten, teils HPC-typische Kommunikation (NCCL, MPI), Netzwerk-Latenz und -Durchsatz werden limitierend.

Diese Profile steuern Architekturentscheidungen:

  • Daten-Gewicht: Wenn Daten täglich im zweistelligen TB-Bereich entstehen (z. B. Kameras an mehreren Linien), sind „Daten zur Compute bringen“ On-Prem oft günstiger als „Compute zur Cloud bringen“. Egress/Ingress, Latenz und Compliance entscheiden gegen Cloud-First.

  • Parallelisierung und Skalierung: CV-Retraining auf 4–8 GPUs On-Prem ist pragmatisch. Massive Vortrainings von Foundation-Modellen sind eher HPC-Disziplin und wirtschaftlich/energetisch selten sinnvoll In-House. Finetuning oder Adapter-Training hingegen schon.

  • Geheimhaltungsstufe: Verteidigungsnahe Projekte, Bahnnetze, kritische Infrastrukturen – On-Prem mit strikter Segmentierung. Cloud allenfalls für anonymisierte, synthetische oder öffentliche Daten.

Entscheidungsmatrix: Wann On-Prem, wann Cloud, wann Hybrid?
On-Premise ist vorteilhaft, wenn:

  • Daten nicht oder nur schwer das Werksgelände verlassen dürfen (DSGVO, IP, Exportkontrolle).

  • Datenvolumen hoch und kontinuierlich ist (Bild/Video, Edge-Sensorik), sodass Datenbewegung dominiert.

  • Langfristige, planbare Rechenlasten bestehen (monatliche Retrains, kontinuierliche Experimente).

  • Sie deterministische Latenzen, kontrollierte Abhängigkeiten und Auditierbarkeit über Jahre benötigen.

Cloud ist vorteilhaft, wenn:

  • Lasten stark volatil sind (kurze, intensive Sprints; danach Leerlauf).

  • Daten bereits rechtskonform außerhalb liegen oder synthetisch/öffentlich sind.

  • Sie kurzfristig große Cluster brauchen, die On-Prem nicht wirtschaftlich vorhaltbar sind.

  • Sie organisatorisch OPEX bevorzugen und Governance sicher im Griff haben (inkl. Datenminimierung und Verschlüsselung).

Hybrid-Patterns funktionieren gut, wenn:

  • Vortrainings oder experimentelle Exploration in der Cloud mit nicht-sensitiven Daten erfolgt, während produktionsnahe Finetunes, Validierung und Inferenz On-Prem laufen.

  • Nur Modellgewichte (ohne Rohdaten) herausbewegt werden. Prüfen Sie dabei Lizenz- und IP-Regeln der Basis-Modelle.

  • Eine dedizierte Datenfreigabestufe existiert (Pseudonymisierung, DLP-Scans), bevor etwas die sichere Zone verlässt.

On-Prem Referenzarchitektur für industrielle ML-Workloads
Ein On-Prem-Cluster ist kein „ein großer Serverraum“. Er ist ein System aus Zonen, Datenpfaden und Betriebsprozessen. Ein erprobtes Muster:

Physische Basis

  • Racks und Strom: Redundante PDUs, A/B-Strom, USV, definierte Rackdichte (kW/Rack), Hot/Cold-Aisle. GPU-Knoten ziehen signifikant – planen Sie elektrische Reserven und Kühlung.

  • Kühlung: Luftgekühlt reicht bis mittlere Dichten; bei hoher Dichte Direktflüssigkühlung erwägen. Temperaturdrift beeinflusst GPU-Drosselung – Monitoring ist Pflicht.

  • Ersatzteile: Spares für Lüfter, Netzteile, NVMe, einzelne GPUs. RMA-Zeiten sind real.

Netzwerk und Segmentierung

  • Leaf-Spine mit 25/100/200 GbE, optional Infiniband für HPC/Jumbo-Frames und RDMA. Für viele CV-Workloads reicht 100 GbE, für verteile LLM-Finetunes eher mehr.

  • Netzwerkzonen:

  • Data Ingestion (OT/DMZ)

  • Compute (Train/Infer)

  • Storage (Objekt/Block)

  • Management/CI/CD

  • Bastion/Jump-Host

East/West-Verkehr strikt kontrollieren. Kein direktes OT→Compute ohne Pufferzonen.

  • Security Appliances: Layer-7-Firewalls nur da, wo sinnvoll. Für Cluster-internen Traffic zählt Latenz; Microsegmentation via CNI/NetworkPolicy in Kubernetes oder Slurm-Partitionen.

Storage-Architektur

  • Heiße Daten: NVMe-Lokaldisks auf GPU-Workern für Scratch/Shard-Daten. Vermeidet Engpässe bei Random-Read/Write (z. B. Bildaugmentierung).

  • Warme Daten: NVMe-over-Fabrics oder verteiltes Dateisystem für Shared Datasets (CephFS, BeeGFS, Lustre je nach Skill/Use-Case).

  • Objekt-Storage: S3-kompatibel On-Prem (MinIO, Ceph RGW) als zentrales Data Lake-Bucket. Versionierung einschalten; Parquet/Arrow bevorzugen; kleine Dateien bündeln.

  • Kalte Daten/Archiv: Tape oder günstige HDD-Tiers, WORM je nach Compliance.

  • Datenkatalog & Governance: Katalogisieren, was wo liegt, mit Provenance-Metadaten. Dataset-Versionierung (z. B. mittels LakeFS oder DVC-ähnlicher Logik).

  • DLP/PII-Kontrollen: Vor Eintritt ins Lake-Bucket Pseudonymisierung, Hashing, Maskierung – nicht als nachträglicher „Cleanup“.