Wat "Serverloze GPU" werkelijk betekent
AI is niet zomaar software – het is een fysieke realiteit met duidelijke resourcelimieten. Ik heb datacenters bezocht waar de verdampingskoeltorens meer water verbruiken dan een kleine wijk; een realiteit die veel software-engineers zich kunnen permitteren te negeren. Mijn klanten kunnen dat echter niet. Zij komen bij mij met een specifieke beperking: ze hebben GPU-kracht nodig voor inferentie of fine-tuning, maar zonder de operationele last van het inrichten van dedicated hardware. De traditionele weg – dure GPU-instances aanschaffen, drivers beheren, complexe autoscalinggroepen bouwen – leidt tot onderbenutte resources of hectisch improviseren tijdens piekbelasting.
Deze gids is de beslissingslaag. Het vergelijkt hoe AWS, GCP en Azure elk serverloze GPU-toegang benaderen, brengt de afwegingen die van belang zijn in productie aan het licht, en biedt u een duidelijk kader voor het kiezen van het juiste platform voor uw workload. Elk platform heeft een dedicated diepgaand artikel in deze serie; links worden aan het einde van elke sectie verstrekt.
De term is overladen. Over de providers heen omvat het ten minste drie verschillende patronen:
- Scale-to-zero inferentie-endpoints — u implementeert een model; de provider schaalt instances (inclusief GPU-instances) tussen nul en N op basis van verkeer. U betaalt per aanroep of per seconde actieve compute. Cold starts zijn de grootste kostenpost.
- Serverloze batch- / fine-tuningtaken — u dient een taak in; de provider wijst GPU-resources toe voor de duur, en geeft deze vervolgens vrij. Geen endpoint om te beheren, geen replica count om af te stemmen.
- Beheerde model-API's — de provider draait het model volledig (bijv. Amazon Bedrock, Azure OpenAI). U roept een API aan; u raakt de GPU-abstractie helemaal niet aan.
Niet alle platforms ondersteunen alle drie de patronen gelijkwaardig. Die asymmetrie is het eerste wat u moet begrijpen voordat u een keuze maakt.
Platformvergelijking
| AWS | GCP | Azure | |
|---|---|---|---|
| Primaire dienst | SageMaker Serverless Inference | Vertex AI Endpoints | Azure AI Projects (AIProjectClient) |
| Beheerde model-API | Amazon Bedrock | Vertex AI Model Garden | Azure OpenAI |
| Serverloze inferentie (aangepaste modellen) | ✅ SageMaker Serverless | ✅ Vertex AI (min_replica=0) | ⚠️ Managed Online Endpoints (geen echte scale-to-zero) |
| Serverloze fine-tuning | ✅ SageMaker Training | ⚠️ Aangepaste taak, niet volledig serverloos | ✅ Azure OpenAI fine-tuning via AIProjectClient |
| Geheugenlimiet (serverloos) | 6 GB | ~16 GB (n1-standard-4 + T4) | Modelafhankelijk (Azure OpenAI beheerd) |
| Mitigatie van cold starts | ProvisionedConcurrency | min_replica_count ≥ 1 | N.v.t. (taakgebaseerd) |
| IaC-ondersteuning | CloudFormation / CDK / Terraform | Terraform (first-class) | Bicep / Terraform |
| Meest geschikt voor | Variabele inferentie, bestaande AWS-stack | Geïntegreerde MLOps-pijplijnen | Fine-tuning van Azure OpenAI-modellen |
AWS: SageMaker Serverless Inference en Bedrock
AWS biedt twee verschillende serverloze toegangspunten. Voor aangepaste modellen stelt SageMaker Serverless Inference u in staat uw eigen container te implementeren zonder instances te beheren. Voor fundamentmodellen biedt Amazon Bedrock volledig beheerde, pay-per-token API-toegang tot Anthropic, Cohere, Amazon Titan en anderen – geheel zonder GPU-beheer.
De belangrijkste configuratieknoppen zijn MemorySizeInMB (1024–6144 MB) en MaxConcurrency. Het 6 GB geheugenplafond is de harde limiet die in de praktijk het meest telt: modellen groter dan ongeveer 3–4 miljard parameters bij FP16 passen niet. Voor grotere modellen is de weg SageMaker Endpoints met dedicated GPU-instances (ml.g5 of ml.inf2) of Bedrock.
ProvisionedConcurrency is de regelknop voor cold starts. Instellen op 0 maximaliseert kostenbesparingen maar introduceert cold starts van 10–30 seconden. Instellen op 1–2 houdt instances warm tegen een bescheiden vaste prijs. Ik adviseer klanten om te beginnen bij nul om een basislijn vast te stellen, en pas provisioned concurrency toe te voegen als latency SLO's worden overschreden.
Wanneer AWS te kiezen: Uw team opereert al in het AWS-ecosysteem, uw model past binnen 6 GB geheugen, en u wilt het meest vertrouwde IAM- en observability-model. De per-endpoint uitgavendetail van AWS Cost Explorer is ook het meest volwassen van de drie platforms.
→ Zie de volledige implementatiegids: Serverloze GPU-inferentie op AWS SageMaker
GCP: Vertex AI Endpoints
Vertex AI Endpoints bieden de strakste integratie met het bredere Vertex-platform – Model Registry, Experiments, Pipelines en Monitoring delen allemaal hetzelfde resourcemodel. U definieert een machinetype met een gekoppelde GPU-accelerator (T4, A100, H100), stelt autoscalinglimieten in, en Vertex regelt de rest.
De cruciale instelling is min_replica_count. Instellen op 0 biedt echt scale-to-zero kosten-gedrag, maar introduceert cold starts die regelmatig 60 seconden overschrijden voor GPU-instances. Voor elke user-facing service is min_replica_count=1 de juiste standaard – de kosten van één idle n1-standard-4 + T4 replica (~$0,95/uur) zijn bijna altijd goedkoper dan de engineering-inspanning van het debuggen van SLO-overschrijdingen.
Voor geheugenruimte is Vertex AI de meest flexibele van de drie: u kunt een A100 (40 GB HBM2) of H100 (80 GB HBM3) aan een aangepast machinetype koppelen, waarmee het 6 GB-plafond dat AWS SageMaker Serverless beperkt, wordt omzeild.
Wanneer GCP te kiezen: U bouwt binnen het Vertex AI-platform en wilt MLOps-tools (pipelines, modelversiebeheer, experimenten) op één plek. Ook de juiste keuze als uw model te groot is voor SageMaker Serverless maar u serverloos-achtig wilt blijven met autoscaling.
→ Zie de volledige implementatiegids: Serverloze GPU-inferentie op GCP Vertex AI
Azure: Serverloze fine-tuning en inferentie via AIProjectClient
Azure's serverloze GPU-verhaal splitst zich duidelijk per use case.
Voor fine-tuning heeft Azure het sterkste serverloze model van de drie platforms. U maakt verbinding met uw Azure AI Project via AIProjectClient, verkrijgt een OpenAI-client, uploadt trainingsgegevens en dient een fine-tuningtaak in. Azure wijst GPU-compute toe voor de duur, de taak wordt voltooid en u betaalt alleen voor wat er is uitgevoerd. Er is geen endpoint om te beheren, geen replica count om af te stemmen en geen zorgen over cold starts. Specifiek voor de fine-tuning use case is dit het schoonste serverloze patroon dat ik in welke cloud dan ook ben tegengekomen.
Voor realtime inferentie op aangepaste modellen is Azure de zwakste van de drie. Azure Machine Learning Managed Online Endpoints ondersteunen GPU-instancetypen en autoscaling, maar ze schalen niet naar nul – minimaal één instance moet blijven draaien. Dit maakt ze operationeel vergelijkbaar met een beheerde dedicated instance in plaats van echt serverloos. De uitzondering zijn Azure OpenAI endpoints: deze zijn volledig beheerd, schalen transparant en zijn de juiste keuze als uw inferentieworkload gericht is op een ondersteund OpenAI-model.
Wanneer Azure te kiezen: U fine-tuned Azure OpenAI-modellen, uw organisatie draait al op Azure, of u heeft de compliance- en data-residentiegaranties van Azure's Europese regio's nodig. Kies Azure niet voor serverloze inferentie van aangepaste modellen als cold-start-vrije scale-to-zero een harde vereiste is.
→ Zie de volledige implementatiegids: Serverloze GPU op Azure — Fine-tuning en inferentie met AIProjectClient
NVIDIA: De fundamentele laag
NVIDIA is geen cloudconcurrent van de drie bovengenoemde – het is het substraat waarop alle drie draaien. De GPU SKU die uw provider gebruikt, bepaalt direct het beschikbare geheugen, de compute-doorvoer en de prijzen:
| NVIDIA SKU | HBM | Typische cloudmapping | Meest geschikt voor |
|---|---|---|---|
| T4 | 16 GB | GCP n1 + T4, AWS ml.g4dn | Inferentie werkpaarden, kosten-geoptimaliseerd |
| A10G | 24 GB | AWS ml.g5 | Inferentie + lichte fine-tuning |
| A100 | 40 / 80 GB | GCP a2, Azure NC A100 v4 | Inferentie van grote modellen, training |
| H100 | 80 GB HBM3 | GCP a3, Azure ND H100 v5 | Training en inferentie van frontiermodellen |
NVIDIA Inference Microservices (NIM's) verdienen een vermelding: dit zijn geoptimaliseerde, vooraf gebouwde containers voor populaire modellen (LLaMA, Mistral, Stable Diffusion) die identiek draaien on-premise of in elke compatibele cloud-GPU. Als hardwareportabiliteit een vereiste is – dezelfde workload vandaag op GCP draaien en volgend kwartaal on-premise – zijn NIM's de juiste abstractielaag om te evalueren.
Kiezen: een beslissingskader
Begin met de vorm van uw workload:
- Beheerd fundamentmodel (geen aangepaste gewichten)? → Gebruik Bedrock (AWS), Vertex AI Model Garden (GCP) of Azure OpenAI. Geen GPU-beheer nodig.
- Aangepast model, sporadisch verkeer, ≤ 6 GB geheugen? → AWS SageMaker Serverless Inference. Eenvoudigste operationele model in het AWS-ecosysteem.
- Aangepast model, variabel verkeer, grote GPU-geheugenbehoefte of strakke MLOps-integratie? → GCP Vertex AI met
min_replica_count=1. - Een OpenAI-model fine-tunen of draaien tegen Azure OpenAI? → Azure AIProjectClient. Beste serverloze fine-tuningervaring van de drie.
- Inferentie van aangepaste modellen op Azure? → Azure ML Managed Online Endpoints, maar budgetteer voor minimaal één draaiende instance.
FinOps Eerste Principe: Draai Serverloos Gedurende 30 Dagen, Beslis Dan
Implementeer kostenwaarschuwingen voordat u naar productie gaat — AWS Cost Explorer, GCP Budget API, of Azure Cost Management. Stel een budgetalarm in op 150% van uw prognose. Een serverloos GPU-endpoint dat schaalt om aan een onverwachte verkeerspiek te voldoen, kan op één middag een maand aan verwachte uitgaven genereren. Leg p99 latentie, aanroepenaantal en werkelijke uitgaven vast over 30 dagen. Evalueer pas dan of een gereserveerde GPU-instance goedkoper is. Naar mijn ervaring rechtvaardigen minder dan 20% van de workloads de operationele overhead van dedicated GPU-compute zodra inactiviteit en engineeringkosten volledig zijn meegerekend.
Conclusie
Serverloze GPU-toegang is voldoende gerijpt om het standaard startpunt te zijn voor elke nieuwe AI-workload. Maar 'serverloos' betekent iets anders op elk platform, en de keuze daartussen is niet primair een technische – het is een operationele en organisatorische.
Kies AWS als uw team al binnen het AWS-ecosysteem werkt en uw modellen passen binnen het 6 GB geheugenplafond. Kies GCP Vertex AI als u het volledige MLOps-platform of grote GPU-capaciteit zonder dedicated instances nodig heeft. Kies Azure als u Azure OpenAI-modellen fine-tuned of opereert binnen een Azure-first organisatie.
De drie diepgaande artikelen in deze serie doorlopen stap voor stap de implementatie op elk platform – van Terraform tot SDK-aanroepen tot kosteninstrumentatie. Begin met het platform dat het dichtst bij uw bestaande infrastructuur staat, meet gedurende 30 dagen en behandel FinOps-governance vanaf dag één als een eersteklas vereiste.
