Progettare l'architettura per l'accesso serverless alle GPU: una guida pratica per AWS, GCP, Azure e NVIDIA

L'AI non è solo software: è una realtà fisica con limiti rigidi di risorse. Ho visitato data center dove le torri di raffreddamento evaporativo consumano più acqua di un piccolo quartiere; una realtà che molti ingegneri del software possono permettersi di ignorare. I miei clienti, tuttavia, non possono. Si rivolgono a me con un vincolo specifico: necessitano della potenza delle GPU per l'inferenza o il fine-tuning, ma senza l'onere operativo di provvedere all'hardware dedicato. Il percorso tradizionale — procurarsi istanze GPU costose, gestire i driver, costruire complessi gruppi di autoscaling — porta a risorse sottoutilizzate o a frenetici affanni durante i picchi di domanda.

Questa guida rappresenta lo strato decisionale. Confronta il modo in cui AWS, GCP e Azure approcciano l'accesso serverless alle GPU, evidenzia i compromessi che contano in produzione e fornisce un quadro chiaro per scegliere la piattaforma giusta per il vostro carico di lavoro. Ogni piattaforma ha un articolo di approfondimento dedicato in questa serie; i link sono forniti alla fine di ogni sezione.

Il termine è sovraccarico. Tra i provider copre almeno tre modelli distinti:

• Endpoint di inferenza scale-to-zero — si implementa un modello; il provider scala le istanze (incluse le istanze GPU) tra zero e N in base al traffico. Si paga per invocazione o per secondo di elaborazione attiva. I cold start sono il costo principale.
• Job serverless di batch / fine-tuning — si invia un job; il provider alloca le risorse GPU per la durata, quindi le rilascia. Nessun endpoint da gestire, nessun numero di repliche da ottimizzare.
• API di modelli gestiti — il provider esegue interamente il modello (es. Amazon Bedrock, Azure OpenAI). Si chiama un'API; non si tocca affatto l'astrazione della GPU.

Non tutte le piattaforme supportano tutti e tre i modelli in egual misura. Questa asimmetria è la prima cosa da comprendere prima di scegliere.

AWS offre due distinti punti di ingresso serverless. Per i modelli personalizzati, SageMaker Serverless Inference consente di distribuire il proprio container senza gestire le istanze. Per i modelli di base, Amazon Bedrock fornisce accesso API completamente gestito, pay-per-token, a Anthropic, Cohere, Amazon Titan e altri — senza alcuna gestione della GPU.

Le leve di configurazione chiave sono MemorySizeInMB (1024–6144 MB) e MaxConcurrency. Il limite di memoria di 6 GB è il limite rigido che conta di più nella pratica: i modelli più grandi di circa 3–4 miliardi di parametri a FP16 non rientreranno. Per modelli più grandi, il percorso è SageMaker Endpoints con istanze GPU dedicate (ml.g5 o ml.inf2) o Bedrock.

ProvisionedConcurrency è il selettore per i cold start. Impostarlo a 0 massimizza il risparmio sui costi ma introduce cold start di 10–30 secondi. Impostarlo a 1–2 mantiene le istanze attive a un costo fisso modesto. Consiglio ai clienti di iniziare da zero per stabilire una base di riferimento, quindi di aggiungere concurrency provisioned solo se vengono violate le SLO di latenza.

Quando scegliere AWS: Il vostro team opera già nell'ecosistema AWS, il vostro modello rientra nei 6 GB di memoria e desiderate il modello IAM e di osservabilità più familiare. La visibilità della spesa per endpoint di AWS Cost Explorer è inoltre la più matura delle tre piattaforme.

→ Vedi la guida completa all'implementazione: Inferenza GPU Serverless su AWS SageMaker

Gli endpoint Vertex AI offrono la più stretta integrazione con la più ampia piattaforma Vertex — Registro Modelli, Esperimenti, Pipeline e Monitoraggio condividono tutti lo stesso modello di risorse. Si definisce un tipo di macchina con un acceleratore GPU allegato (T4, A100, H100), si impostano i limiti di autoscaling, e Vertex gestisce il resto.

L'impostazione critica è min_replica_count. Impostarlo a 0 offre un vero comportamento di costo scale-to-zero ma introduce cold start che superano regolarmente i 60 secondi per le istanze GPU. Per qualsiasi servizio rivolto all'utente, min_replica_count=1 è l'impostazione predefinita corretta — il costo di una replica inattiva n1-standard-4 + T4 (~0,95 $/ora) è quasi sempre più conveniente dello sforzo ingegneristico per il debug delle violazioni delle SLO.

Per il margine di memoria, Vertex AI è il più flessibile dei tre: è possibile allegare un A100 (40 GB HBM2) o un H100 (80 GB HBM3) a un tipo di macchina personalizzato, bypassando il limite di 6 GB che vincola AWS SageMaker Serverless.

Quando scegliere GCP: State costruendo all'interno della piattaforma Vertex AI e desiderate strumenti MLOps (pipeline, versioning dei modelli, esperimenti) in un unico posto. È anche la scelta giusta se il vostro modello è troppo grande per SageMaker Serverless ma volete rimanere serverless-adjacent con l'autoscaling.

→ Vedi la guida completa all'implementazione: Inferenza GPU Serverless su GCP Vertex AI

La storia delle GPU serverless di Azure si divide nettamente per caso d'uso.

Per il fine-tuning, Azure ha il modello serverless più robusto delle tre piattaforme. Ci si connette al proprio Azure AI Project tramite AIProjectClient, si ottiene un client OpenAI, si caricano i dati di training e si invia un job di fine-tuning. Azure alloca la potenza di calcolo della GPU per la durata, il job viene completato e si paga solo per ciò che è stato eseguito. Non c'è alcun endpoint da gestire, nessun numero di repliche da ottimizzare e nessuna preoccupazione per i cold-start. Per il caso d'uso specifico del fine-tuning, questo è il modello serverless più pulito che abbia incontrato su qualsiasi cloud.

Per l'inferenza in tempo reale su modelli personalizzati, Azure è il più debole dei tre. Gli endpoint online gestiti di Azure Machine Learning supportano i tipi di istanze GPU e l'autoscaling, ma non scalano a zero — un minimo di un'istanza deve rimanere in esecuzione. Questo li rende operativamente simili a un'istanza dedicata gestita piuttosto che a un vero serverless. L'eccezione sono gli endpoint Azure OpenAI: questi sono completamente gestiti, scalano in modo trasparente e sono la scelta giusta se il vostro carico di lavoro di inferenza è contro un modello OpenAI supportato.

Quando scegliere Azure: State effettuando il fine-tuning di modelli Azure OpenAI, la vostra organizzazione opera già su Azure, oppure necessitate delle garanzie di conformità e residenza dei dati delle regioni europee di Azure. Non scegliete Azure per l'inferenza serverless di modelli personalizzati se uno scale-to-zero senza cold-start è un requisito irrinunciabile.

→ Vedi la guida completa all'implementazione: GPU Serverless su Azure — Fine-Tuning e Inferenza con AIProjectClient

NVIDIA non è un concorrente cloud per i tre sopra citati — è il substrato su cui tutti e tre operano. La SKU della GPU che il vostro provider utilizza determina direttamente la memoria disponibile, il throughput di calcolo e i prezzi:

NVIDIA Inference Microservices (NIMs) meritano una menzione: questi sono container ottimizzati e pre-costruiti per modelli popolari (LLaMA, Mistral, Stable Diffusion) che funzionano in modo identico on-premise o su qualsiasi GPU cloud compatibile. Se la portabilità dell'hardware è un requisito — eseguire lo stesso carico di lavoro su GCP oggi e on-premise il prossimo trimestre — i NIMs sono il giusto strato di astrazione da valutare.

Iniziate dalla forma del vostro carico di lavoro:

1. Modello di base gestito (senza pesi personalizzati)? → Usate Bedrock (AWS), Vertex AI Model Garden (GCP) o Azure OpenAI. Nessuna gestione della GPU necessaria.
2. Modello personalizzato, traffico sporadico, ≤ 6 GB di memoria? → AWS SageMaker Serverless Inference. Il modello operativo più semplice nell'ecosistema AWS.
3. Modello personalizzato, traffico variabile, necessità di grande memoria GPU o stretta integrazione MLOps? → GCP Vertex AI con min_replica_count=1.
4. Fine-tuning di un modello OpenAI o esecuzione contro Azure OpenAI? → Azure AIProjectClient. La migliore esperienza di fine-tuning serverless dei tre.
5. Inferenza di modelli personalizzati su Azure? → Azure ML Managed Online Endpoints, ma prevedere il budget per un'istanza minima in esecuzione.

L'accesso serverless alle GPU è maturato a sufficienza da essere il punto di partenza predefinito per qualsiasi nuovo carico di lavoro AI. Ma "serverless" significa qualcosa di diverso su ogni piattaforma, e la scelta tra di esse non è principalmente tecnica — è operativa e organizzativa.

Scegliete AWS se il vostro team opera già nell'ecosistema AWS e i vostri modelli rientrano nel limite di memoria di 6 GB. Scegliete GCP Vertex AI se avete bisogno della piattaforma MLOps completa o di un ampio margine per le GPU senza istanze dedicate. Scegliete Azure se state effettuando il fine-tuning di modelli Azure OpenAI o operate in un'organizzazione Azure-first.

I tre articoli di approfondimento di questa serie esaminano passo dopo passo la distribuzione su ciascuna piattaforma — da Terraform alle chiamate SDK, fino alla strumentazione dei costi. Iniziate con la piattaforma più vicina alla vostra infrastruttura esistente, misurate per 30 giorni e trattate la governance FinOps come un requisito di prima classe fin dal primo giorno.