Machine Learning Cloud: ML-Modelle in der Cloud entwickeln, deployen und skalieren

Machine-Learning-Workloads in der Cloud bieten Teams elastische GPU-/TPU-Rechenleistung, verwaltete Trainings-Pipelines und produktionsreife Inference-Endpunkte – ohne eigene Hardware besitzen zu müssen. Doch die Lücke zwischen einem Notebook-Prototyp und einem zuverlässigen, kostenoptimierten und compliance-konformen Produktionssystem ist genau die Stelle, an der die meisten Unternehmen ins Stocken geraten. Dieser Leitfaden behandelt Architekturentscheidungen, Hyperscaler-Tooling, Kostenkontrolle, Compliance-Anforderungen und operative Muster, die Opsios Engineering-Teams täglich in Multi-Cloud-Umgebungen beobachten.

Kernaussagen

• Alle großen Hyperscaler bieten verwaltete ML-Dienste an, doch die eigentliche Herausforderung liegt in der Operationalisierung von Modellen in der Produktion – nicht im Training.
• DSGVO und NIS2 schreiben konkret vor, wo ML-Trainingsdaten gespeichert werden dürfen und wie Inference-Endpunkte in der EU zu betreiben sind.
• GPU-Kosten dominieren ML-Cloud-Budgets; Spot-/Preemptible-Instanzen, Auto-Scaling für Inference und passend dimensionierte Instanzfamilien können die Ausgaben drastisch senken.
• Multi-Cloud-ML wird immer häufiger, erhöht aber die Pipeline-Komplexität – setzen Sie auf Container und ONNX, um portabel zu bleiben.
• MLOps-Reife – Versionierung von Daten, Modellen und Pipelines – unterscheidet Teams, die produktiv liefern, von solchen, die ewig prototypen.

Warum Machine Learning in der Cloud stattfindet

Das Training eines aussagekräftigen ML-Modells erfordert Rechenleistung, die teuer in der Anschaffung, aufwändig in der Wartung und die meiste Zeit ungenutzt ist. Ein einzelner Trainingslauf für ein großes Vision-Modell kann dutzende GPUs über Tage beanspruchen – und dann wochenlang brachliegen, während das Team an Daten und Features iteriert. Cloud-Infrastruktur wandelt diese Investitionskosten in stundengenaue Betriebskosten um, die auf null skalieren, wenn gerade kein Training läuft.

Über die reine Wirtschaftlichkeit hinaus aktualisieren Cloud-Anbieter ihre GPU- und Beschleunigerflotten kontinuierlich. AWS stellt NVIDIA H100-Instanzen (P5) in der Region eu-central-1 (Frankfurt) bereit, Azure bietet die ND H100 v5-Serie in Germany West Central an, und Google Cloud liefert TPU v5p-Pods. Vergleichbare Hardware On-Premises zu beschaffen bedeutet 6–12 Monate Lieferzeit und die Festlegung auf eine einzige Beschleuniger-Generation. In der Cloud wechseln Sie den Instanztyp zwischen Experimenten.

Der dritte Treiber ist das Ökosystem verwalteter Dienste. Feature Stores, Experiment-Tracker, Model Registries und Inference-Autoscaler werden als Erstanbieter-Services angeboten. Den Stack selbst aufzubauen ist möglich – MLflow, Feast, Seldon Core existieren – aber deren Betrieb in der Produktion erfordert dedizierte Platform-Engineering-Kapazitäten, die vielen mittelständischen Teams fehlen.

Managed Cloud Services

Hyperscaler-ML-Plattformen im Vergleich

Alle Cloud-Anbieter haben sich auf eine weitgehend ähnliche ML-Plattform-Architektur konvergiert: eine Notebook-/IDE-Schicht, eine Trainings-Orchestrierungsschicht, eine Model Registry und eine Inference-Hosting-Schicht. Die Unterschiede liegen im Detail.

Opsios operative Perspektive: Teams, die voll auf die ML-Plattform eines einzelnen Anbieters setzen, erzielen die reibungsloseste Erfahrung. Wenn Ihr Unternehmen jedoch bereits Multi-Cloud betreibt – in Deutschland verbreitet, etwa Azure für Microsoft 365 und AWS für die Kerninfrastruktur – benötigen Sie eine Portabilitätsstrategie. Wir sehen regelmäßig Kunden, die ihren Trainingscode mit Docker und einem framework-agnostischen Serving-Layer (Triton Inference Server, TorchServe oder ONNX Runtime) containerisieren, damit das Modellartefakt nicht an SageMaker oder Vertex AI gebunden ist.

Cloud-Migration

Die vier Arten von Machine Learning (und wo die Cloud jeweils passt)

Das Verständnis der ML-Kategorien ist wichtig, weil sie unterschiedliche Compute- und Datenprofile in der Cloud aufweisen.

Supervised Learning

Das Modell lernt aus gelabelten Beispielen (Eingabe → bekannte Ausgabe). Klassifikations- und Regressionsaufgaben dominieren das Enterprise-ML: Betrugserkennung, Nachfrageprognose, Churn-Vorhersage. Cloud-Eignung: unkompliziert – verteiltes Training auf gelabelten Datensätzen, Deployment als Echtzeit-Endpunkt. SageMaker Built-in Algorithms, Azure AutoML und Vertex AI AutoML adressieren genau dieses Muster.

Unsupervised Learning

Keine Labels. Das Modell entdeckt Strukturen: Clustering, Dimensionalitätsreduktion, Anomalie-Erkennung. Cloud-Eignung: erfordert häufig Instanzen mit großem Arbeitsspeicher für Distanzberechnungen über hochdimensionale Daten. Elastische Skalierung hilft, weil Hyperparameter-Sweeps für die Clusteranzahl parallel ausgeführt werden können.

Semi-Supervised und Self-Supervised Learning

Ein kleines gelabeltes Set kombiniert mit einem großen ungelabelten Korpus. Foundation-Model-Pre-Training (BERT, GPT, Vision Transformer) fällt hierunter. Cloud-Eignung: Hier explodieren die GPU-Kosten. Das Pre-Training eines großen Sprachmodells kann Hunderttausende Euro an Rechenkosten verursachen. Spot-Instanzen und regelmäßiges Checkpointing sind zwingend erforderlich.

Reinforcement Learning

Ein Agent lernt durch Interaktion mit einer Umgebung und erhält Belohnungssignale. Eingesetzt in Robotik-Simulation, Spiele-KI und Empfehlungsoptimierung. Cloud-Eignung: Simulationsumgebungen (AWS RoboMaker, benutzerdefinierte Umgebungen auf GKE) verbrauchen CPU und GPU in Bursts. Auto-Scaling und Preemptible VMs halten die Kosten beherrschbar.

Eine ML-Pipeline bauen, die tatsächlich in Produktion geht

Das offene Geheimnis des Enterprise-ML: Die meisten Modelle erreichen nie die Produktion. Laut Gartner-Studien zum KI-Deployment stagniert die Mehrheit der ML-Projekte zwischen Proof-of-Concept und Produktions-Deployment. Die Lösung sind nicht bessere Algorithmen – es ist MLOps-Disziplin.

Daten-Versionierung und Feature Engineering

Versionieren Sie Ihre Trainingsdaten genauso wie Ihren Code. DVC (Data Version Control), LakeFS oder Cloud-native Lineage-Tools (AWS Glue Data Catalog, Azure Purview, Google Dataplex) verfolgen, welche Daten welches Modell hervorgebracht haben. Feature Stores – Amazon SageMaker Feature Store, Feast auf GKE, Tecton – stellen sicher, dass Training/Serving-Skew die Modellqualität nicht schleichend verschlechtert.

Experiment Tracking

MLflow (Open Source, weit verbreitet), Weights & Biases oder die Hyperscaler-nativen Experiment-Tracker (SageMaker Experiments, Azure ML Experiments, Vertex AI Experiments) protokollieren Hyperparameter, Metriken und Artefakte. Ohne dieses Tracking können Sie weder Ergebnisse reproduzieren noch einem Auditor erklären, warum ein Modell sich so verhält, wie es sich verhält.

Continuous Training und CI/CD für Modelle

Behandeln Sie Modell-Retraining als geplante Pipeline, nicht als manuellen Notebook-Lauf. SageMaker Pipelines, Azure ML Pipelines und Vertex AI Pipelines unterstützen DAG-basierte Orchestrierung mit bedingten Schritten (Retraining nur, wenn Data Drift einen Schwellenwert überschreitet). Integrieren Sie Standard-CI/CD-Tools – GitHub Actions, GitLab CI, Azure DevOps – damit die Modell-Promotion durch Code Review und automatisierte Validierung läuft.

Model Monitoring in der Produktion

Deployte Modelle degradieren. Eingabeverteilungen verschieben sich, vorgelagerte Datenschemata ändern sich, und das Verhalten in der realen Welt weicht von den Trainingsdaten ab. Instrumentieren Sie Inference-Endpunkte mit:

• Data-Drift-Erkennung: SageMaker Model Monitor, Azure ML Data Drift, Vertex AI Model Monitoring oder Open-Source-Tools wie EvidentlyAI.
• Performance-Metriken: Accuracy/F1/AUC auf einem gelabelten Sample, Latenz p50/p95/p99, Fehlerraten.
• Alerting: Drift- und Degradationssignale über PagerDuty oder Opsgenie in bestehende Incident-Management-Workflows einleiten.

Opsios NOC integriert ML-Modell-Gesundheitssignale in dieselben CloudWatch-/Azure Monitor-/Datadog-Dashboards, die auch die Infrastruktur überwachen. Ein degradierter Modell-Endpunkt erhält dieselbe Triage-Priorität wie ein degradiertes API Gateway.

Managed DevOps

Kostenkontrolle für ML-Workloads

GPU-Compute ist der mit Abstand größte Posten in einem Machine-Learning-Cloud-Budget. Eine einzelne p5.48xlarge-Instanz (8x H100) auf AWS kostet On-Demand über 98 USD/Stunde. Multipliziert mit einem mehrtägigen Trainingslauf erreichen die Kosten schnell fünfstellige Beträge.

Praktische Strategien zur Kostenreduktion

Spot- und Preemptible-Instanzen: AWS Spot, Azure Spot VMs und GCP Preemptible/Spot VMs bieten typischerweise 60–90 % Ersparnis gegenüber On-Demand-Preisen für GPU-Instanzen. Der Kompromiss ist das Unterbrechungsrisiko. Mitigieren Sie durch häufiges Checkpointing (alle 15–30 Minuten) und Frameworks mit elastischem Training (PyTorch Elastic, Horovod).

Passende Instanzfamilien wählen: Nicht jeder Trainings-Job braucht eine H100. Viele tabellarische Modelle trainieren effizient auf CPU (C-Familien-Instanzen) oder älteren GPU-Generationen (T4, A10G). Reservieren Sie H100-/A100-Instanzen für Large-Model-Training und Fine-Tuning, wo der Durchsatzunterschied die Kosten rechtfertigt.

Auto-Scaling für Inference-Endpunkte: Ein Echtzeit-Inference-Endpunkt, der 24/7 auf einer GPU-Instanz läuft, kann pro Jahr mehr kosten als das Training, das das Modell hervorgebracht hat. Nutzen Sie SageMaker Serverless Inference, Azure ML Serverless Endpoints oder Vertex AI Autoscaling, um in Schwachlastzeiten auf null zu skalieren.

Reserved Capacity und Savings Plans: Für Inference-Workloads, die tatsächlich rund um die Uhr laufen, bieten AWS Savings Plans oder Azure Reserved Instances für GPU-VMs deutliche Rabatte (typischerweise 30–60 %, abhängig von Laufzeit und Zahlungsoption).

Idle-Ressourcen überwachen: Opsios FinOps-Praxis findet regelmäßig verwaiste SageMaker-Notebook-Instanzen, gestoppte aber nicht terminierte Trainingscluster und überdimensionierte Endpoint-Instanzen. Tagging-Disziplin und automatisierte Idle-Ressourcen-Alerts (AWS Cost Anomaly Detection, Azure Cost Management) fangen diese auf, bevor sie sich summieren.

Cloud FinOps

Compliance und Datensouveränität für ML in der EU

DSGVO, BSI C5 und NIS2

Die DSGVO verbietet ML auf personenbezogenen Daten nicht – sie verlangt eine Rechtsgrundlage (Artikel 6), Transparenz bei automatisierter Entscheidungsfindung (Artikel 22) und Datenminimierung. In der Praxis bedeutet das:

• Datenresidenz: Trainingsdaten, die personenbezogene Daten von EU-Bürgern enthalten, sollten in EU-Regionen verbleiben, sofern kein geeigneter Transfermechanismus vorliegt (Standardvertragsklauseln, Angemessenheitsbeschluss). Nach Schrems II sind zusätzliche technische Maßnahmen bei Transfers in die USA essenziell. Alle drei Hyperscaler bieten EU-basierte Regionen mit Datenresidenz-Optionen – für deutsche Unternehmen sind eu-central-1 (Frankfurt), eu-central-2 (Zürich) und Germany West Central besonders relevant.
• Recht auf Löschung vs. Modell-Memorisierung: Wenn eine betroffene Person die Löschung gemäß Artikel 17 verlangt, müssen Sie prüfen, ob das Modell memorisierte personenbezogene Daten enthält. Differential Privacy beim Training und Daten-De-Identifikations-Pipelines reduzieren dieses Risiko.
• BSI C5: Für deutsche Unternehmen im öffentlichen Sektor oder in regulierten Branchen ist der BSI Cloud Computing Compliance Criteria Catalogue (C5) ein zentrales Attestierungs-Framework. Alle drei Hyperscaler verfügen über C5-Testate – stellen Sie sicher, dass die genutzten ML-Dienste in den Geltungsbereich des jeweiligen Testats fallen.
• NIS2-Richtlinie: Falls Ihre Organisation gemäß NIS2 als wesentlich oder wichtig eingestuft wird (anwendbar auf Einrichtungen in 18 Sektoren), unterliegen ML-Inference-Endpunkte, die kritische Dienste unterstützen, den Risikomanagement- und Meldepflichten. Behandeln Sie sie wie jedes andere Produktionssystem: gepatcht, überwacht, Incident-Response-ready.

SOC 2 und ISO 27001

ML-Plattformen erben die Compliance-Position des zugrunde liegenden Cloud-Kontos. Wenn Ihr AWS-Konto innerhalb eines ISO 27001-zertifizierten Geltungsbereichs liegt, erben SageMaker-Workloads diesen Zertifizierungsscope – aber nur, wenn Sie IAM, Verschlüsselung, VPC-Isolation und Logging korrekt konfiguriert haben. Opsios SOC stellt sicher, dass ML-Workloads dem gleichen kontinuierlichen Compliance-Monitoring unterliegen wie die restliche Cloud-Umgebung.

Cloud Security

On-Premises vs. Cloud ML: Ein ehrlicher Vergleich

Der Trend, den Opsio bei mittelständischen und Enterprise-Kunden in der DACH-Region beobachtet: Training in der Cloud, Inference dort deployen, wo es Sinn ergibt. Für einen Einzelhändler mit Computer Vision in Filialen bedeutet das Cloud-Training mit Edge-Inference auf NVIDIA Jetson oder AWS Panorama-Geräten. Für ein SaaS-Unternehmen leben Training und Inference gleichermaßen in der Cloud mit Auto-Scaling.

Foundation Models und Generative AI in der Cloud

Die Generative-AI-Welle hat den Zugang zu Foundation Models zu einem erstklassigen Cloud-Dienst gemacht. AWS Bedrock, Azure OpenAI Service und Google Vertex AI Model Garden bieten API-Zugang zu Modellen von Anthropic, OpenAI, Meta, Mistral und anderen. Für die Machine-Learning-Cloud-Strategie ist das relevant, weil:

1. Fine-Tuning ersetzt Training von Grund auf für viele Anwendungsfälle. Statt einen Textklassifikator von null zu trainieren, fine-tunen Sie ein Foundation Model auf Ihren Domänendaten. Das reduziert Rechenkosten und Zeitaufwand drastisch.

2. Retrieval-Augmented Generation (RAG)-Pipelines kombinieren Vektordatenbanken (Amazon OpenSearch Serverless, Azure AI Search, Pinecone, Weaviate) mit Foundation Models, um Ausgaben in Unternehmensdaten zu verankern – Halluzinationen werden reduziert, Relevanz steigt.

3. Responsible AI Governance wird unverzichtbar. Modellevaluation, Content Filtering und Audit-Logging sind in Bedrock Guardrails, Azure AI Content Safety und Vertex AI Safety Filters integriert. Europäische Organisationen, die dem AI Act unterliegen (dessen stufenweise Anwendung seit 2024 begonnen hat), müssen diese Kontrollen dokumentiert vorweisen.

Opsios Position: Nutzen Sie verwaltete Foundation-Model-APIs für Prototyping und Inference mit niedrigem bis mittlerem Volumen. Für Hochdurchsatz-Inference oder wenn Sie vollständige Kontrolle über die Modellgewichte benötigen (aus Compliance- oder Anpassungsgründen), deployen Sie Open-Weight-Modelle (Llama 3, Mistral, Gemma) auf dedizierten GPU-Instanzen hinter Ihrem eigenen Inference-Server.

Erste Schritte: Eine pragmatische Roadmap

1. Inventarisieren Sie Ihre Daten. Bevor Sie eine ML-Plattform auswählen, katalogisieren Sie, welche Daten Sie haben, wo sie liegen, welche Qualität sie aufweisen und welcher Governance-Klassifikation sie unterliegen. ML-Modelle sind nur so gut wie ihre Trainingsdaten.

2. Wählen Sie eine Cloud-ML-Plattform und gehen Sie in die Tiefe. Widerstehen Sie dem Impuls, alle drei gleichzeitig zu evaluieren. Wenn Ihr Unternehmen primär auf AWS läuft, starten Sie mit SageMaker. Azure-Umgebung? Azure ML. Die Wechselkosten sind geringer als gedacht, wenn Sie den Trainingscode containerisieren.

3. Investieren Sie in MLOps, bevor Sie die Modellanzahl skalieren. Ein Modell in der Produktion mit ordentlichem Monitoring, Retraining-Pipelines und Drift-Erkennung ist mehr wert als zehn Modelle in Notebooks.

4. Setzen Sie Kosten-Leitplanken ab Tag eins. Budget-Alerts, Spot-Instanz-Policies und Endpoint-Auto-Scaling-Regeln sollten stehen, bevor der erste Trainings-Job startet.

5. Binden Sie Compliance frühzeitig ein. Wenn Sie personenbezogene Daten verarbeiten oder in einer regulierten Branche tätig sind, holen Sie Ihren DSB (Datenschutzbeauftragten) und das Compliance-Team bereits bei der Gestaltung der Datenpipeline ins Boot – nicht erst, wenn das Modell in der Produktion läuft.

Managed Cloud Services

Häufig gestellte Fragen

Was versteht man unter Machine Learning in der Cloud?

Machine Learning in der Cloud bedeutet, die Infrastruktur der Hyperscaler – GPU-/TPU-Rechenleistung, verwaltete Trainingsservices, Feature Stores und Inference-Endpunkte – anstelle eigener On-Premises-Hardware zu nutzen. Investitionskosten (CapEx) werden zu Betriebskosten (OpEx), Teams können Trainings-Jobs elastisch skalieren, und die Pflege von GPU-Treibern, CUDA-Stacks und Netzwerk-Fabric entfällt.

Ist ChatGPT KI oder ML?

ChatGPT ist beides. Es ist ein KI-Produkt, das auf einem Large Language Model (GPT) basiert, welches mit Machine-Learning-Verfahren trainiert wurde – konkret mit Supervised Fine-Tuning und Reinforcement Learning from Human Feedback (RLHF). ML ist die Methode; KI die übergeordnete Disziplin. ChatGPT ist eine Anwendung von ML innerhalb des KI-Feldes.

Welche vier Arten von Machine Learning gibt es?

Die vier üblicherweise genannten Arten sind: Supervised Learning (Training mit gelabelten Daten), Unsupervised Learning (keine Labels, Mustererkennung), Semi-Supervised Learning (kleines gelabeltes Set plus großes ungelabeltes Set) und Reinforcement Learning (ein Agent lernt über Belohnungssignale). Manche Taxonomien ordnen Semi-Supervised dem Supervised zu; andere ergänzen Self-Supervised Learning als fünfte Kategorie.

Ist On-Premises-ML im Vergleich zu Cloud-ML noch sinnvoll?

Für latenzkritische Edge-Inference oder Air-Gapped-Umgebungen mit strikter Datensouveränität ist On-Premises-ML nach wie vor berechtigt. Für iteratives Training, elastische Skalierung und Zugang zu den neuesten GPU-Generationen ist die Cloud jedoch praktikabler. Die meisten Unternehmen fahren ein hybrides Modell: Training in der Cloud, Inference dort deployen, wo Latenz- oder regulatorische Anforderungen es verlangen.

Wie wirkt sich die DSGVO auf das ML-Training in der Cloud aus?

Die DSGVO verlangt eine Rechtsgrundlage für die Verarbeitung personenbezogener Daten, die im Training verwendet werden. Sie müssen die Datenherkunft dokumentieren, Löschanfragen nachkommen (was mit der Memorisierung im Modell kollidieren kann) und sicherstellen, dass grenzüberschreitende Transfers den Vorgaben aus Kapitel V entsprechen – insbesondere nach Schrems II. Das Training mit personenbezogenen Daten von EU-Bürgern in einer ausschließlich US-basierten Region ohne angemessene Schutzmaßnahmen ist ein Compliance-Verstoß. Differential Privacy und Daten-De-Identifikations-Pipelines helfen, das Risiko zu minimieren.