Serverloses GPU-Management: Ein Praxisleitfaden für AWS, GCP, Azure und NVIDIA

KI ist nicht nur Software – sie ist eine physische Realität mit engen Ressourcengrenzen. Ich habe Rechenzentren besucht, in denen die Verdunstungskühltürme mehr Wasser verbrauchen als ein kleines Viertel; eine Realität, die viele Softwareingenieure ignorieren können. Meine Kunden jedoch nicht. Sie wenden sich mit einer spezifischen Einschränkung an mich: Sie benötigen GPU-Leistung für Inferenz oder Fine-Tuning, aber ohne den operativen Aufwand der Bereitstellung dedizierter Hardware. Der traditionelle Weg – die Beschaffung teurer GPU-Instanzen, die Verwaltung von Treibern und der Aufbau komplexer Autoscaling-Gruppen – führt zu unterausgelasteten Ressourcen oder hektischer Betriebsamkeit bei Spitzennachfrage.

Dieser Leitfaden ist die Entscheidungsebene. Er vergleicht, wie AWS, GCP und Azure jeweils den serverlosen GPU-Zugriff handhaben, beleuchtet die relevanten Kompromisse in der Produktion und bietet Ihnen einen klaren Rahmen für die Auswahl der richtigen Plattform für Ihre Workload. Jede Plattform hat einen eigenen Deep-Dive-Artikel in dieser Reihe; Links dazu finden Sie am Ende jedes Abschnitts.

Der Begriff ist überladen. Bei den Anbietern umfasst er mindestens drei verschiedene Muster:

• Scale-to-zero-Inferenzendpunkte – Sie stellen ein Modell bereit; der Anbieter skaliert Instanzen (einschließlich GPU-Instanzen) je nach Traffic zwischen null und N. Sie zahlen pro Aufruf oder pro Sekunde aktiver Rechenzeit. Kaltstarts sind die Hauptkostenursache.
• Serverlose Batch- / Fine-Tuning-Jobs – Sie übermitteln einen Job; der Anbieter weist GPU-Ressourcen für die Dauer zu und gibt sie danach wieder frei. Kein Endpunkt zu verwalten, keine Replikatanzahl anzupassen.
• Verwaltete Modell-APIs – der Anbieter betreibt das Modell vollständig (z. B. Amazon Bedrock, Azure OpenAI). Sie rufen eine API auf; Sie kommen überhaupt nicht mit der GPU-Abstraktion in Berührung.

Nicht alle Plattformen unterstützen alle drei Muster gleichermaßen. Diese Asymmetrie ist das Erste, was man vor der Auswahl verstehen muss.

AWS bietet zwei unterschiedliche serverlose Einstiegspunkte. Für eigene Modelle ermöglicht SageMaker Serverless Inference die Bereitstellung eigener Container, ohne Instanzen verwalten zu müssen. Für Foundation Models bietet Amazon Bedrock einen vollständig verwalteten, Pay-per-Token-API-Zugriff auf Anthropic, Cohere, Amazon Titan und andere – keinerlei GPU-Management ist erforderlich.

Die wichtigsten Konfigurationshebel sind MemorySizeInMB (1024–6144 MB) und MaxConcurrency. Die 6 GB Speicherbegrenzung ist die harte Grenze, die in der Praxis am relevantesten ist: Modelle, die größer als etwa 3–4 B Parameter bei FP16 sind, passen nicht. Für größere Modelle führt der Weg über SageMaker Endpoints mit dedizierten GPU-Instanzen (ml.g5 oder ml.inf2) oder Bedrock.

ProvisionedConcurrency ist der Regler für Kaltstarts. Eine Einstellung auf 0 maximiert die Kosteneinsparungen, führt aber zu Kaltstarts von 10–30 Sekunden. Eine Einstellung auf 1–2 hält Instanzen zu geringen Fixkosten warm. Ich empfehle meinen Kunden, bei null zu beginnen, um eine Basislinie zu etablieren, und die Provisioned Concurrency nur dann hinzuzufügen, wenn die Latenz-SLOs verletzt werden.

Wann AWS wählen: Ihr Team arbeitet bereits im AWS-Ökosystem, Ihr Modell passt in 6 GB Speicher und Sie wünschen sich das vertrauteste IAM- und Observability-Modell. Die Ausgaben pro Endpunkt im AWS Cost Explorer sind ebenfalls die ausgereiftesten der drei Plattformen.

→ Den vollständigen Implementierungsleitfaden finden Sie hier: Serverlose GPU-Inferenz auf AWS SageMaker

Vertex AI Endpoints bieten die engste Integration in die umfassendere Vertex-Plattform – Model Registry, Experimente, Pipelines und Monitoring teilen sich alle dasselbe Ressourcenmodell. Sie definieren einen Maschinentyp mit einem angeschlossenen GPU-Beschleuniger (T4, A100, H100), legen Autoscaling-Grenzen fest, und Vertex erledigt den Rest.

Die kritische Einstellung ist min_replica_count. Eine Einstellung auf 0 ermöglicht echtes Scale-to-zero-Kostenverhalten, führt aber zu Kaltstarts, die bei GPU-Instanzen regelmäßig 60 Sekunden überschreiten. Für jeden benutzerseitigen Dienst ist min_replica_count=1 der korrekte Standardwert – die Kosten für eine inaktive n1-standard-4 + T4-Replika (~0,95 $/Std.) sind fast immer geringer als der Ingenieuraufwand für das Debugging von SLO-Verletzungen.

Hinsichtlich des Speicherbedarfs ist Vertex AI die flexibelste der drei Plattformen: Sie können eine A100 (40 GB HBM2) oder H100 (80 GB HBM3) an einen benutzerdefinierten Maschinentyp anbinden und so die 6-GB-Grenze umgehen, die AWS SageMaker Serverless einschränkt.

Wann GCP wählen: Sie entwickeln innerhalb der Vertex AI-Plattform und wünschen sich MLOps-Tools (Pipelines, Modellversionierung, Experimente) an einem Ort. Auch die richtige Wahl, wenn Ihr Modell für SageMaker Serverless zu groß ist, Sie aber mit Autoscaling serverless-nah bleiben möchten.

→ Den vollständigen Implementierungsleitfaden finden Sie hier: Serverlose GPU-Inferenz auf GCP Vertex AI

Azures serverlose GPU-Angebote lassen sich klar nach Anwendungsfall aufteilen.

Für das Fine-Tuning hat Azure das stärkste serverlose Modell der drei Plattformen. Sie verbinden sich über den AIProjectClient mit Ihrem Azure AI-Projekt, erhalten einen OpenAI-Client, laden Trainingsdaten hoch und übermitteln einen Fine-Tuning-Job. Azure weist für die Dauer GPU-Rechenleistung zu, der Job wird abgeschlossen, und Sie zahlen nur für die tatsächliche Nutzung. Es gibt keinen Endpunkt zu verwalten, keine Replikatanzahl anzupassen und keine Kaltstartprobleme. Speziell für den Fine-Tuning-Anwendungsfall ist dies das sauberste serverlose Muster, das ich in irgendeiner Cloud gefunden habe.

Für die Echtzeit-Inferenz mit eigenen Modellen ist Azure die schwächste der drei Plattformen. Azure Machine Learning Managed Online Endpoints unterstützen GPU-Instanztypen und Autoscaling, skalieren aber nicht auf null – mindestens eine Instanz muss immer aktiv bleiben. Dies macht sie operativ eher einer verwalteten dedizierten Instanz ähnlich als einem echten serverlosen Dienst. Die Ausnahme bilden Azure OpenAI-Endpunkte: Diese sind vollständig verwaltet, skalieren transparent und sind die richtige Wahl, wenn Ihre Inferenz-Workload auf ein unterstütztes OpenAI-Modell abzielt.

Wann Azure wählen: Sie führen ein Fine-Tuning von Azure OpenAI-Modellen durch, Ihre Organisation arbeitet bereits mit Azure, oder Sie benötigen die Compliance- und Datenresidenzgarantien der europäischen Azure-Regionen. Wählen Sie Azure nicht für die serverlose Inferenz eigener Modelle, wenn ein Kaltstart-freies Scale-to-zero eine zwingende Anforderung ist.

→ Den vollständigen Implementierungsleitfaden finden Sie hier: Serverlose GPU auf Azure – Fine-Tuning und Inferenz mit AIProjectClient

NVIDIA ist kein Cloud-Wettbewerber zu den drei oben genannten Anbietern – es ist das Substrat, auf dem alle drei laufen. Die von Ihrem Anbieter verwendete GPU-SKU bestimmt direkt den verfügbaren Speicher, den Rechendurchsatz und die Preisgestaltung:

NVIDIA Inference Microservices (NIMs) verdienen eine Erwähnung: Dies sind optimierte, vorgefertigte Container für gängige Modelle (LLaMA, Mistral, Stable Diffusion), die On-Premise oder auf jeder kompatiblen Cloud-GPU identisch laufen. Wenn Hardware-Portabilität eine Anforderung ist – dieselbe Workload heute auf GCP und im nächsten Quartal On-Premise auszuführen – sind NIMs die richtige Abstraktionsschicht zur Bewertung.

Beginnen Sie mit der Form Ihrer Workload:

1. Verwaltetes Foundation Model (keine benutzerdefinierten Gewichte)? → Verwenden Sie Bedrock (AWS), Vertex AI Model Garden (GCP) oder Azure OpenAI. Kein GPU-Management erforderlich.
2. Eigenes Modell, sporadischer Traffic, ≤ 6 GB Speicher? → AWS SageMaker Serverless Inference. Einfachstes Betriebsmodell im AWS-Ökosystem.
3. Eigenes Modell, variabler Traffic, großer GPU-Speicher oder enge MLOps-Integration erforderlich? → GCP Vertex AI mit min_replica_count=1.
4. Fine-Tuning eines OpenAI-Modells oder Einsatz mit Azure OpenAI? → Azure AIProjectClient. Das beste serverlose Fine-Tuning-Erlebnis der drei.
5. Inferenz eigener Modelle auf Azure? → Azure ML Managed Online Endpoints, aber planen Sie mindestens eine laufende Instanz ein.

Der serverlose GPU-Zugriff ist ausreichend ausgereift, um der Standard-Ausgangspunkt für jede neue KI-Workload zu sein. Doch „serverlos“ bedeutet auf jeder Plattform etwas anderes, und die Wahl zwischen ihnen ist nicht primär eine technische, sondern eine operative und organisatorische Entscheidung.

Wählen Sie AWS, wenn Ihr Team bereits im AWS-Ökosystem zu Hause ist und Ihre Modelle in die 6-GB-Speicherbegrenzung passen. Wählen Sie GCP Vertex AI, wenn Sie die vollständige MLOps-Plattform oder große GPU-Kapazitäten ohne dedizierte Instanzen benötigen. Wählen Sie Azure, wenn Sie Azure OpenAI-Modelle feinabstimmen oder in einer Azure-zentrierten Organisation arbeiten.

Die drei Deep-Dive-Artikel dieser Reihe führen Schritt für Schritt durch die Bereitstellung auf jeder Plattform – von Terraform über SDK-Aufrufe bis zur Kosteninstrumentierung. Beginnen Sie mit der Plattform, die Ihrer bestehenden Infrastruktur am nächsten ist, messen Sie 30 Tage lang und behandeln Sie FinOps-Governance vom ersten Tag an als erstklassige Anforderung.