Server GPU in cloud: 7 provider a confronto per l’AI

Per scegliere un server GPU in cloud, parti dal lavoro da svolgere: Runpod per gestire direttamente il fine-tuning, Modal per l'inferenza serverless con codice personalizzato, Together AI per accedere ai modelli tramite un'API gestita e Vast.ai per noleggiare risorse su un marketplace ed eseguire lavori che possono essere ripresi dopo un'interruzione. Completano questi 7 provider Lambda, per le macchine virtuali con GPU, CoreWeave, per chi ha già pianificato la capacità di un cluster, e Google Cloud, quando l'applicazione dipende già dalla sua infrastruttura. Il punto di partenza è la memoria richiesta dal modello e il tempo di esecuzione fatturato, non la tariffa GPU più bassa in vetrina.

Prezzi e documentazione dei prodotti verificati il 30 ottobre 2026. Le cifre riportate sono gli importi in USD pubblicati quel giorno nei listini ufficiali dei fornitori. Il confronto si basa sulla documentazione, non su benchmark di prestazioni eseguiti sul campo. Disponibilità, imposte e configurazione finale del deployment possono modificare la spesa effettiva.

Server GPU in cloud: quale provider scegliere per ogni esigenza

Runpod è il primo candidato per chi sviluppa e vuole eseguire direttamente il fine-tuning di un modello; Modal e Together AI sono i primi da valutare per metterlo in servizio senza mantenere una macchina GPU sempre attiva. La scelta cambia se servono una regione specifica, capacità continuativa o un ambiente batch che faciliti il ripristino.

GPU cloud, prezzi a confronto: prima l'unità di misura, poi la cifra

Ogni tariffa di partenza indica il prodotto e l'hardware a cui si riferisce. Sono soglie d'accesso a servizi diversi, non offerte con prestazioni equivalenti. Il prezzo di una GPU aggiunta a una VM esclude la macchina virtuale che la ospita; un secondo di GPU serverless non comprende le risorse conteggiate a parte; una tariffa di inferenza dedicata non è un prezzo API a token.

Un'offerta del marketplace può sparire e la GPU meno costosa a listino potrebbe avere troppo poca memoria per il modello. La colonna sulla prova gratuita descrive l'offerta pubblica verificata, non tutti i programmi di crediti negoziabili. Together AI richiede crediti prepagati; il limite imposto da Google alle GPU è esplicito nelle condizioni della Free Trial.

Inferenza serverless: codice personalizzato o API di un modello?

Prima di scegliere la GPU, decidi se devi controllare l'ambiente di esecuzione del modello. Fare inferenza significa usare un modello addestrato per produrre una risposta. Un'API gestita permette di richiedere quella risposta; un ambiente di calcolo serverless personalizzabile permette di fornire il codice che la genera. Questa distinzione conta più del fatto che entrambi i prodotti si definiscano «serverless».

1. Modal: inferenza Python personalizzata con traffico variabile

Modal è una piattaforma di calcolo serverless per applicazioni in container distribuite tramite Python. È adatta a chi sviluppa un prodotto nel quale il codice che esegue il modello è parte integrante del servizio. Un'applicazione per elaborare documenti, per esempio, potrebbe richiedere pre-elaborazione personalizzata, una chiamata al modello e post-elaborazione nello stesso deployment. Modal consente di scalare con la domanda, ma il tempo fatturato comprende inizializzazione e attesa dei container pronti, non soltanto il calcolo utile del modello. Scegli Modal se vuoi controllare il runtime senza mantenere una VM sempre accesa.

Ideale per: team Python che distribuiscono inferenza personalizzata o job GPU in coda con domanda variabile.
Punto di forza: deployment a livello di applicazione e scalabilità automatica, con risorse di calcolo conteggiate separatamente.
Prezzi: calcolo GPU da $0.000164/secondo per una T4, più CPU e memoria, verificato il 30 ottobre 2026 nel listino di Modal.
Prova gratuita: Starter include $30/mese di crediti di calcolo; gli Shared Endpoints fatturati a token sono esclusi da questa quota.

Il limite pratico è la latenza dopo un periodo senza richieste. Un avvio a freddo, o cold start, comprende il lavoro necessario a preparare un nuovo container perché possa rispondere. Avvio del container, importazione delle librerie e caricamento dei pesi del modello sono fasi distinte. Un container che si avvia rapidamente non rende necessariamente il modello subito disponibile.

Modal offre controlli per tenere pronti i container e mantenere capacità di riserva. Possono migliorare la reattività, ma mantengono anche le risorse allocate. Per un assistente rivolto ai clienti, misura sia la prima richiesta dopo l'inattività sia quelle di una sessione intensa. Per una coda notturna di estrazione dati, attendere l'inizializzazione può essere accettabile. La guida di Modal agli avvii a freddo spiega il compromesso.

Il piano Starter pone anche un limite concreto alla crescita: 3 utenti per workspace e 10 GPU contemporanee. Bastano per un progetto pilota utile, ma un picco di worker indipendenti può raggiungere il limite di concorrenza quando la spesa mensile è ancora contenuta. Volumi persistenti e traffico di rete in uscita prevedono quote incluse e addebiti separati oltre soglia: inserisci quindi nel preventivo anche il percorso dei dati.

Anche la geografia richiede una scelta di configurazione. Modal distingue la regione in cui viene eseguito il container da quella che instrada le richieste. Vincolare l'esecuzione a una regione comporta inoltre un moltiplicatore sul prezzo. Avere il modello vicino al database serve solo se anche il percorso delle richieste rispetta i requisiti di latenza e residenza dei dati. La documentazione sulla selezione delle regioni descrive entrambi i controlli.

2. Together AI: quando serve un endpoint del modello pronto all'uso

Together AI è una piattaforma gestita di inferenza e addestramento. Si rivolge ai team che vogliono rilasciare una funzionalità basata su un modello prima di occuparsi dell'infrastruttura GPU. L'API serverless è il punto di partenza naturale se il modello necessario è a catalogo; l'inferenza dedicata aggiunge controllo sull'hardware che lo esegue. Il confine è la personalizzazione: l'API di un modello supportato è un prodotto diverso da un ambiente di addestramento configurabile liberamente. Scegli Together AI quando ti serve l'endpoint; acquista capacità dedicata quando il traffico o i requisiti di controllo la giustificano.

Ideale per: team che mettono in servizio modelli supportati o usano fine-tuning gestito e inferenza dedicata.
Punto di forza: il percorso da un'API fatturata a token all'esecuzione del modello su risorse dedicate.
Prezzi: inferenza dedicata su NVIDIA HGX H100 da $5.49/GPU-ora; le tariffe delle API serverless dipendono dal modello, come verificato il 30 ottobre 2026 nel listino di Together AI.
Prova gratuita: non prevista; è necessario acquistare crediti prepagati.

Tieni distinti i modelli di fatturazione. L'inferenza linguistica serverless addebita i token in ingresso e in uscita, cioè le porzioni di testo elaborate dal modello. L'inferenza dedicata viene fatturata al minuto per ogni replica pronta: una copia in esecuzione del servizio che espone il modello. La documentazione esclude provisioning e avvio a freddo dalla fatturazione del calcolo dedicato, ma una replica pronta continua a costare anche se riceve poche richieste. Portare le repliche a zero interrompe questo addebito. La documentazione sulla fatturazione dell'inferenza dedicata ne precisa i confini.

Per un'applicazione di assistenza con conversazioni sporadiche, il serverless evita di acquistare capacità del modello che resta inutilizzata. Per un'applicazione molto usata, con un andamento del traffico ormai noto, vale la pena confrontare le repliche dedicate usando gli stessi prompt e le stesse lunghezze di risposta. Non cambiare solo perché la tariffa per GPU sembra inferiore: occorre misurare il throughput per tradurla in costo per risposta completata.

Anche il fine-tuning gestito richiede una stima separata. Together propone LoRA basato su adapter e fine-tuning completo, con addebiti a token che tengono conto dei passaggi di addestramento e della valutazione. Un'epoca è un passaggio attraverso l'intero dataset di addestramento. Ripetere il dataset aumenta i token elaborati: la sola dimensione del file caricato non determina la fattura.

Il prodotto per cluster GPU è ancora un servizio distinto. Offre capacità on demand e riservata, con storage persistente fatturato a parte. Le prenotazioni dei cluster sono prepagate e non rimborsabili; eliminare un cluster non rende automaticamente gratuiti tutti i volumi conservati. La documentazione dei cluster dichiara gratuiti i trasferimenti in ingresso e in uscita. Non bisogna estendere queste regole a ogni prodotto API. I dettagli sono nella documentazione sulla fatturazione dei cluster.

Per l'inferenza, verifica insieme modello e regione. Alcuni modelli serverless consentono di circoscrivere l'inferenza agli Stati Uniti, mentre altri requisiti geografici orientano verso gli endpoint dedicati. I tempi di risposta delle API condivise possono variare con la domanda e le applicazioni devono comunque gestire i tentativi successivi in caso di errore. La documentazione serverless esplicita questi limiti.

Pod e VM on demand per il fine-tuning

Noleggia un ambiente sotto il tuo controllo quando stai ancora modificando script di addestramento, dipendenze o modello. Il fine-tuning adatta un modello esistente ai tuoi dati. Un Pod o una macchina virtuale permette di analizzare gli errori e ripetere il lavoro, ma lascia a te la responsabilità di fermare il calcolo e conservare i risultati.

3. Runpod: il primo candidato per gestire direttamente il fine-tuning

Runpod affianca Pod con GPU dedicate a prodotti Serverless e per cluster. È un candidato pratico per un piccolo team che sviluppa il proprio workflow per i modelli. Si può scegliere una GPU e un template di container, eseguire il fine-tuning e valutare in seguito un deployment Serverless separato per l'inferenza. I limiti sono concreti: l'affidabilità di Community Cloud varia da host a host, lo storage persistente ha un ciclo di vita indipendente e fermare un Pod non garantisce di ritrovare la stessa GPU alla riaccensione. Runpod merita attenzione per il controllo e la flessibilità di deployment, senza promettere di essere il più economico per qualsiasi carico di lavoro.

Ideale per: sviluppatori che cercano un container con GPU per esperimenti, fine-tuning con adapter e sviluppo di inferenza personalizzata.
Punto di forza: prodotti Pod e Serverless distinti per le fasi di sviluppo e messa in servizio.
Prezzi: il listino pubblica Pod RTX A5000 con 24 GB di VRAM da $0.27/ora, verificati il 30 ottobre 2026 sulla pagina prezzi di Runpod.
Prova gratuita: il listino consultato non indicava una prova gratuita delle GPU.

Parti dalla memoria, non dal nome del chip più prestigioso. Runpod elenca schede da 24 GB, opzioni da 48 GB come A40 e RTX A6000 e varianti A100 e H100 da 80 GB. Un piccolo team può così valutare diverse classi di memoria senza progettare subito un cluster. Questo non stabilisce una classifica di throughput: motore di inferenza, precisione del modello e configurazione dei batch possono cambiare la convenienza di una scheda.

Anche Secure Cloud e Community Cloud richiedono valutazioni diverse. Runpod descrive Secure Cloud come infrastruttura in data center e Community Cloud come offerta peer-to-peer con affidabilità variabile. Un esperimento che si può rifare tollera un rischio di guasto diverso da un servizio che gestisce richieste dei clienti. Scegli il gruppo di risorse in base ai requisiti di ripristino e supporto del lavoro. La guida di Runpod alla scelta di un Pod chiarisce la distinzione.

Lo storage è il vincolo che più facilmente sorprende al primo deployment. Il disco del container è temporaneo. Il volume disk sopravvive all'arresto, ma non all'eliminazione del Pod. Un volume di rete persiste in modo indipendente, ma è disponibile per i Pod su Secure Cloud e vincola la scelta dell'hardware alla propria posizione. Salvare i checkpoint soltanto su storage temporaneo vanifica il motivo per cui li si conserva. La documentazione sui volumi di rete spiega il vincolo di collocazione.

Secondo le regole verificate, i Pod fatturano il calcolo al secondo e non applicano costi ai trasferimenti in ingresso o in uscita. Lo storage può continuare a generare addebiti anche a Pod fermo. Serverless segue un ciclo diverso: i worker vengono fatturati durante inizializzazione, esecuzione e attesa inattiva, fino all'arresto. I worker Flex possono scalare a zero; i worker Active restano in esecuzione. Sono scelte sul tempo per cui le risorse restano allocate a pagamento, non semplici etichette diverse sulla stessa tariffa oraria. Consulta la fatturazione dei Pod e la fatturazione Serverless.

Per il prospetto completo di tariffe e storage, consulta la guida ai prezzi di Runpod del sito. Usala per stimare esecuzioni ripetute e inferenza sempre attiva.

1. 1

   Definisci il lavoro prima del deployment

   Annota il checkpoint esatto del modello, la modalità di inferenza o fine-tuning, la precisione, la lunghezza massima degli input e la concorrenza prevista. Scegli una classe di memoria GPU che lasci spazio al runtime, non soltanto al file del modello.

2. 2

   Scegli prima dove conservare i dati

   Se serve un volume di rete, crealo o selezionalo nel data center previsto prima di scegliere la GPU. Verifica che lì sia disponibile capacità GPU adatta. Mantieni una copia separata dei dati di addestramento e dei checkpoint insostituibili.

3. 3

   Distribuisci un template compatibile

   In Pods, seleziona la GPU, scegli il template del container, imposta il numero di GPU e avvia il deployment on demand. Controlla il filtro di compatibilità CUDA dell'host rispetto al template. CUDA è la piattaforma software da cui dipendono molte applicazioni per GPU NVIDIA.

4. 4

   Esegui una piccola prova e verifica la procedura di arresto

   Prova lo stesso percorso di caricamento, addestramento e scrittura dei checkpoint previsto per il lavoro finale. Registra il picco di memoria GPU e il tempo trascorso. Prima di fermare o terminare il calcolo, verifica che il checkpoint sia sullo storage persistente; poi controlla gli addebiti di storage rimasti.

Questi controlli di deployment sono descritti nella documentazione sulla gestione dei Pod. Usa la prova anche per verificare il ripristino: l'avvio successivo deve poter proseguire senza dipendere da una specifica macchina usata in precedenza.

4. Lambda: una VM con GPU in un ambiente familiare

Lambda è un cloud GPU con macchine virtuali Linux e offerte di cluster riservati. È adatto ai team che cercano una macchina convenzionale per una sessione di addestramento prolungata. Gli ambienti includono gli strumenti NVIDIA, mentre il catalogo spazia dalle istanze con una sola GPU ad allocazioni più ampie. Il vincolo d'acquisto è proprio la dimensione dell'allocazione: la stessa GPU può avere una tariffa per unità diversa a seconda di quante se ne noleggiano. Scegli Lambda per un ambiente di addestramento sotto il tuo controllo e verifica il selettore del numero di GPU prima di leggere una tariffa come se fosse il totale in fattura.

Ideale per: team di addestramento e fine-tuning che preferiscono l'accesso SSH a una VM con GPU.
Punto di forza: istanze con una sola GPU e un'offerta separata di cluster riservati.
Prezzi: le Single-GPU Instances partono da $0.69/GPU-ora per una Quadro RTX 6000 con 24 GB di VRAM, come verificato il 30 ottobre 2026 nel listino di Lambda.
Prova gratuita: il listino consultato non indicava una prova gratuita delle GPU.

Il catalogo comprende A6000 da 48 GB e varianti H100 PCIe e SXM da 80 GB. I nomi contano: «RTX 6000», «A6000» e schede più recenti con nomi simili non sono acquisti intercambiabili. Nelle note di deployment indica il nome completo della GPU e la memoria, così un'esecuzione futura non finirà su un dispositivo diverso senza che nessuno se ne accorga.

Il calcolo on demand di Lambda ha prezzi orari, ma viene fatturato a scatti di un minuto, dall'avvio in condizioni operative fino alla terminazione. Una macchina accesa che non lavora continua a costare. Per un job di addestramento, organizza lo spegnimento in base al ciclo di terminazione del provider: la fine del processo Python non implica la fine del noleggio. La documentazione sulla fatturazione di Lambda descrive il conteggio.

I filesystem persistenti richiedono un ulteriore passaggio di pianificazione: vanno collegati durante la creazione dell'istanza e devono trovarsi nella stessa regione. Restano a pagamento finché esistono, anche quando sono smontati; la documentazione di fatturazione dichiara gratuiti i trasferimenti in ingresso e in uscita dai filesystem. Prima di caricare un dataset voluminoso, verifica che GPU e filesystem possano trovarsi nella località desiderata. La documentazione sulle istanze Lambda riporta le regole per regioni e storage.

I cluster riservati comportano un acquisto di tutt'altra scala. La tabella pubblica dei 1-Click Cluster parte da 16 GPU e da un periodo di due settimane. Può essere adatta a una campagna di addestramento concentrata, ma è un punto di partenza poco indicato per chi sta ancora cercando di capire se l'adattamento su un singolo dispositivo risolverà il problema. Parti dall'esperimento più piccolo che può funzionare ed espandilo solo dopo aver stabilito il throughput necessario.

Noleggio GPU su marketplace e istanze interrompibili

Accetta il rischio di interruzione solo dopo aver dimostrato che il lavoro può ripartire. Un marketplace riunisce offerte di host diversi. Un'istanza interrompibile può essere sospesa o le sue risorse possono essere reclamate dal fornitore. I due concetti si sovrappongono, ma un noleggio on demand su marketplace non è automaticamente interrompibile.

5. Vast.ai: lavori ripristinabili senza vincoli rigidi di collocazione

Vast.ai è un marketplace GPU in cui gli host stabiliscono i prezzi. È utile a chi sa valutare la singola offerta e può convivere con una disponibilità di macchine mutevole. Un job batch di embedding o un esperimento di fine-tuning ripetibile può adattarsi bene, purché input e checkpoint sopravvivano all'istanza. Il limite è il conto economico specifico dell'host: calcolo, storage e trasferimenti nelle due direzioni possono avere addebiti separati. Scegli Vast.ai se puoi adattare l'implementazione all'offerta, senza pretendere che ogni offerta si comporti allo stesso modo.

Ideale per: esperimenti attenti al costo, job batch e addestramenti che possono ripartire dai checkpoint.
Punto di forza: scelta del singolo host tra noleggi on demand, riservati e interrompibili.
Prezzi: tariffe GPU stabilite dagli host e fatturate al secondo, più storage e trasferimenti; verifica l'offerta di partenza per la tua configurazione nel listino aggiornato di Vast.ai, consultato il 30 ottobre 2026.
Prova gratuita: il listino consultato non indicava una prova gratuita delle GPU.

L'offerta meno costosa serve solo se l'hardware è adatto al lavoro. Il catalogo di Vast.ai elenca RTX 3090 e RTX 4090 da 24 GB, L40S da 48 GB e H100 SXM da 80 GB. Filtra prima per memoria e software necessari. Poi confronta CPU, memoria di sistema, storage, condizioni di trasferimento e posizione dello specifico host.

Il calcolo viene conteggiato al secondo mentre l'istanza è in esecuzione. Lo storage resta a pagamento finché l'istanza esiste, anche quando è ferma. I costi di upload e download variano per host. Una GPU economica che scarica ripetutamente un modello o un dataset voluminoso può quindi risultare poco conveniente per un lavoro breve. Confronta l'intero percorso dei dati, non soltanto la scheda grafica. La documentazione sui prezzi di Vast.ai spiega queste componenti.

Per riprendere correttamente un addestramento interrompibile, il solo file del modello salvato potrebbe non bastare. Conserva lo stato necessario al framework di addestramento e prova la procedura di riavvio prima di farci affidamento. In una coda batch, assegna identificatori stabili ai job, così ripetere un'attività non duplica i risultati visibili ai clienti. Sono criteri da soddisfare prima di scegliere risorse interrompibili, non garanzie che il provider esegua il ripristino al tuo posto.

Vast.ai offre anche infrastruttura serverless. Questo non elimina le questioni relative all'host e ai costi dei dati: la documentazione verificata descrive la fatturazione serverless attraverso i costi di calcolo, storage e banda dell'istanza. Qui l'attenzione è sul noleggio tramite marketplace, perché è l'impiego più chiaramente adatto a un piccolo team disposto a gestire questi compromessi.

Cluster riservati e infrastruttura cloud già in uso

Riserva capacità dopo aver misurato una domanda stabile; resta vicino all'infrastruttura esistente quando spostare il carico creerebbe più lavoro di quanto ne farebbe risparmiare. Sono ragioni diverse per scegliere una piattaforma più ampia. Anche un piccolo team può avere l'una o l'altra esigenza senza acquistare su scala da hyperscaler.

6. CoreWeave: quando il fabbisogno del cluster è già definito

CoreWeave è un cloud di infrastruttura AI con Kubernetes gestito su nodi GPU bare metal. È adatto a un team che è passato dall'esperimento a un fabbisogno di calcolo pianificato. Kubernetes coordina i container su più macchine; è utile quando il deployment richiede questa orchestrazione e qualcuno ne ha la responsabilità. Per un piccolo team, il limite sta nell'allocazione e nella gestione operativa: acquistare a livello di nodo e usare un cluster gestito richiede comunque un carico ben definito, un piano per lo storage e un responsabile operativo. Valuta CoreWeave quando pianificare la capacità è un'esigenza concreta, non come scelta predefinita per scoprire di quali risorse ha bisogno il modello.

Ideale per: team con un fabbisogno di cluster noto e le competenze per gestire un carico di lavoro Kubernetes.
Punto di forza: Kubernetes gestito su nodi bare metal, con rete e isolamento del cluster.
Prezzi: la tabella per il Nord America indica un'istanza GH200 con una sola GPU a $6.50/ora; la capacità riservata richiede un preventivo, come verificato il 30 ottobre 2026 nel listino di CoreWeave.
Prova gratuita: il listino consultato non indicava una prova gratuita delle GPU.

Leggi con attenzione le colonne di CoreWeave. Diverse istanze GPU pubblicate contengono 8 GPU, comprese quelle nelle righe H100, H200, A100, L40 e L40S. La pagina mostra separatamente prezzi di inferenza per singola GPU e una nota li limita ai clienti della piattaforma di inferenza. Dividere il prezzo del nodo per il numero di GPU è utile per fare i conti, ma non dimostra che sia possibile noleggiare una frazione di quel nodo per un normale job su cluster.

Il listino distingue Nord America ed Europa e riporta opzioni on demand, spot e riservate. Per una prenotazione, chiedi configurazione esatta del nodo, località di deployment, durata dell'impegno e condizioni sulla capacità. Fai confermare nel preventivo anche la granularità della fatturazione: un prezzo pubblico all'ora, da solo, non implica un conteggio al secondo.

CoreWeave indica come gratuiti i trasferimenti dati interni e via Internet, mentre storage e servizi di IP pubblico hanno addebiti propri. Vale quindi la pena valutarlo per un carico con molti trasferimenti, ma la capacità di calcolo acquistata deve comunque essere utile. Trasferimenti economici non compensano un cluster che rimane inattivo per gran parte del periodo prenotato.

La documentazione di CoreWeave Kubernetes Service descrive il control plane gestito, i nodi bare metal, le reti private e la rete per le GPU. Per un piccolo team AI, la domanda decisiva riguarda le responsabilità: chi preparerà i job, controllerà gli errori, gestirà i segreti e ripristinerà il servizio? Se è la stessa persona che sta ancora validando l'applicazione, un Pod o un'API più semplici potrebbero portare prima a una funzionalità operativa.

7. Google Cloud: quando la GPU deve stare vicino all'applicazione esistente

Google Cloud offre macchine virtuali Compute Engine con GPU ed è una scelta sensata da valutare quando applicazione e dati si trovano già sulla piattaforma. Tenere l'esecuzione del modello vicino al resto del sistema può semplificare la scelta del deployment, anche se un cloud specializzato propone una tariffa GPU interessante. L'ostacolo è l'accesso: tipo di macchina, regione, quota e disponibilità fisica devono coincidere. Scegli Google Cloud quando il carico trae vantaggio dalla collocazione e dall'assetto operativo già in uso, senza scambiare il prezzo d'ingresso della GPU per quello di un server completo.

Ideale per: sviluppatori che aggiungono elaborazioni GPU a un'applicazione già gestita su Google Cloud.
Punto di forza: famiglie di macchine GPU con disponibilità regionale e controlli delle quote espliciti.
Prezzi: una T4 aggiuntiva in Iowa parte da $0.35/ora per la sola GPU, a cui si somma la VM, come verificato il 30 ottobre 2026 nel listino degli acceleratori Google.
Prova gratuita: durante la Free Trial non si possono aggiungere GPU; occorre passare a un account a pagamento.

Quanto costano le GPU di Google Cloud? Va aggiunta anche la VM

Una GPU aggiuntiva è una risorsa in più, non una macchina intera. La T4 indicata dispone di 16 GB di memoria GPU. Se l'applicazione richiede più memoria o un acceleratore diverso, bisogna scegliere un'altra configurazione, senza costruire il budget attorno a quella tariffa d'ingresso.

Google elenca anche famiglie di macchine con GPU integrate, tra cui G2 con L4, A2 con varianti A100 e varianti A3 che utilizzano H100 o H200. Il prezzo di una macchina con GPU integrata e quello di una GPU aggiuntiva comprendono risorse diverse. Nella stima includi il tipo di macchina scelto, insieme agli addebiti di storage e rete.

Compute Engine fattura al secondo dopo un minimo di un minuto. Una VM accesa ma inattiva continua a costare. Anche le prenotazioni possono generare addebiti quando le risorse non sono avviate: garantirsi la disponibilità è quindi una decisione diversa dall'avviare un job. Le regole di fatturazione di Compute Engine descrivono questi confini.

Le GPU di Google Cloud sono disponibili? La quota è solo un requisito

La presenza di una GPU a catalogo non garantisce che l'account possa avviarla oggi nella zona desiderata. Google documenta il supporto delle GPU per zona, mentre le quote operano separatamente dalla capacità fisica. Cerca la macchina prevista nell'elenco di regioni e zone GPU, poi verifica le quote GPU necessarie.

Per esempio, un team che serve i clienti vicino al proprio database dovrebbe individuare località vicine accettabili prima di richiedere una configurazione GPU. Se la zona desiderata non ha capacità disponibile, spostare più lontano il solo server del modello può modificare sia il tempo di risposta sia il percorso dei trasferimenti dati. Considera questa alternativa come una modifica dell'applicazione da testare.

La Free Trial pone un vincolo ulteriore: non permette di aggiungere GPU né di richiedere aumenti delle quote. Anche il Free Tier permanente di Google esclude le GPU. La promessa di un credito di benvenuto non basta quindi a dimostrare che un nuovo account possa avviare subito un esperimento con GPU. Fanno fede le condizioni ufficiali di Google.

Come scegliere un cloud GPU per l'AI

Escludi prima l'hardware che non può contenere il carico di lavoro, poi confronta i provider che offrono quello adatto. La memoria GPU, spesso chiamata VRAM, ospita il modello e lo stato necessario a eseguirlo. Un modello che entra a malapena in memoria può comunque fallire quando arriva un prompt più lungo o un'altra richiesta simultanea.

Parti da una stima dei soli pesi. A 16 bit ogni parametro occupa 2 byte; a 4 bit il peso grezzo occupa mezzo byte. Un modello da 8 miliardi di parametri richiede quindi circa 16 GB di pesi a 16 bit o 4 GB di pesi grezzi a 4 bit. Un modello da 32 miliardi di parametri dà 64 GB o 16 GB; uno da 70 miliardi dà 140 GB o 35 GB. Sono nostri calcoli in GB decimali, non requisiti di inferenza misurati. La guida al dimensionamento di Runpod fornisce la regola di memoria alla base del calcolo.

Lo spazio che manca alla stima conta. Il runtime di inferenza richiede memoria di lavoro e la cache KV conserva lo stato dell'attenzione durante la generazione. La lunghezza del contesto e le richieste simultanee modificano questo stato. Un «modello da 35 GB» non equivale a un budget di 35 GB per il deployment. La documentazione di Hugging Face sulla cache spiega perché la cache richieda una valutazione della memoria separata.

Usa le schede da 24 GB, 48 GB e 80 GB come classi da valutare, non come garanzie. Un piccolo modello quantizzato può lasciare un margine utile su un dispositivo da 24 GB. Un modello più grande, un contesto più lungo o più richieste contemporanee possono spostare il fabbisogno in un'altra classe. Prevedi un margine esplicito sul picco di memoria osservato, invece di dimensionare tutto sulla richiesta più piccola andata a buon fine.

Il fine-tuning cambia il problema. L'addestramento completo aggiunge gradienti, stato dell'ottimizzatore e attivazioni salvate. I metodi basati su adapter aggiornano un sottoinsieme più piccolo di parametri e possono ridurre i requisiti, ma non eliminano tutti i costi di memoria. Un'inferenza riuscita non dimostra che sulla stessa scheda possa entrare anche il fine-tuning completo. Consulta l'analisi della memoria per l'addestramento e la panoramica sul fine-tuning efficiente nei parametri.

Controlla poi la variante GPU e la compatibilità software. Il fatto che un provider elenchi H100 non significa che tutte le offerte H100 abbiano lo stesso formato, la stessa configurazione di memoria, la stessa allocazione CPU o la stessa interconnessione. Per usare più GPU serve anche un framework capace di distribuire il lavoro in modo efficace: acquistare più schede non risolve automaticamente un job troppo lento o troppo grande.

Chiudi la valutazione con l'intero ciclo di fatturazione. Per ogni finalista, distingui avvio del calcolo, lavoro utile, attesa delle risorse pronte, terminazione e storage conservato. Stima un mese in base al calendario previsto, includendo inattività e tentativi ripetuti. Una macchina allocata in modo continuo e un breve batch giornaliero richiedono budget diversi anche quando mostrano la stessa tariffa oraria.

Quale provider conviene scegliere nel proprio caso?

La scelta cambia prima in base al controllo necessario sul runtime, poi in base all'utilità di tenerlo pronto. Se un'API supportata realizza la funzionalità, inizia valutando Together AI. Se il codice di inferenza personalizzato è indispensabile e il traffico è variabile, confronta Modal con Runpod Serverless. Se serve un ambiente interattivo o una sessione prolungata di fine-tuning, parti dai Pod Runpod e dalle istanze Lambda.

Per un job batch ripristinabile con flessibilità di collocazione, aggiungi Vast.ai. Per un carico da cluster già definito, con un responsabile operativo, aggiungi CoreWeave. Se l'applicazione dipende già da una determinata località e configurazione operativa di Google Cloud, valuta la sua capacità GPU prima di sostenere il costo di migrazione verso un altro provider.

La capacità riservata diventa sensata quando sai che l'hardware resterà utile per tutta la durata dell'impegno e la disponibilità è di per sé importante. Non prenotare per scoprire quanto userai le risorse. Esegui prima il carico, misura la domanda che persiste nei periodi tranquilli e riserva soltanto la capacità giustificata da quel livello di base.

Anche un servizio sensibile alla latenza può preferire risorse dedicate o già pronte con un volume di richieste relativamente basso. Un cliente costretto ad attendere dopo ogni intervallo di inattività può costare più di un worker fermo. Misura la prima risposta dopo l'inattività e quelle più lente durante i picchi: la latenza media può nascondere entrambi i problemi.

Se stai ancora decidendo se gestire un runtime GPU, la guida al confronto tra chip di inferenza e GPU affronta la scelta più ampia del controllo sull'hardware.

Come sono stati selezionati i provider

I criteri sono aderenza al carico di lavoro, unità d'acquisto verificabile, memoria adeguata, costi dei dati, comportamento all'avvio e accesso regionale. I sette provider coprono API di modelli gestite, applicazioni serverless personalizzate, noleggio diretto di GPU, marketplace e cluster pianificati. La collocazione nell'articolo indica una raccomandazione per uno specifico lavoro, non una classifica universale di velocità.

Prezzi e affermazioni sulle funzionalità sono stati verificati sulle pagine dei fornitori il 30 ottobre 2026. Per questo confronto non sono state noleggiate GPU né eseguiti test di throughput o disponibilità del servizio. Le stime dei pesi sono calcoli espliciti; le raccomandazioni sulle piattaforme derivano dall'analisi dei comportamenti documentati.

La selezione resta centrata su chi sviluppa o lavora in un piccolo team AI. Directory cloud più estese, intermediari d'acquisto e altri hyperscaler aggiungerebbero nomi senza cambiare la prima decisione: serve un endpoint del modello, una macchina o un cluster? Un provider entra nella valutazione finale solo se può fornire la configurazione richiesta in una località utilizzabile.

Quali scelte evitare

Evita il modello d'acquisto inadatto al tuo carico di lavoro, anche quando il fornitore è valido per altri impieghi.

• Capacità interrompibile di Vast.ai per un job che non può riprendere o essere ripetuto in sicurezza. Verifica il ripristino prima di accettare il rischio di interruzione.
• Runpod Community Cloud quando il piano richiede un volume di rete Runpod. Questa opzione di storage è destinata ai Pod Secure Cloud.
• Modal con scalabilità a zero quando ogni prima risposta deve rispettare un obiettivo di latenza stretto e non hai misurato l'inizializzazione. Metti a budget risorse già pronte o modifica il deployment.
• Lambda 1-Click Clusters o una prenotazione CoreWeave quando il numero di GPU utili e la durata del lavoro sono ancora ipotesi. Stabilisci prima la domanda con un noleggio più piccolo.
• Together AI serverless quando il checkpoint richiesto o il comportamento del runtime non rientra nel prodotto API supportato. Valuta invece i prodotti dedicati o un ambiente GPU programmabile.
• La Free Trial di Google Cloud senza passaggio a un account a pagamento come strada per accedere subito alle GPU. Le restrizioni sulle GPU sono esplicite.

Domande frequenti sulle GPU cloud

Quali provider offrono GPU in cloud?

I sette provider confrontati sono Runpod, Lambda, CoreWeave, Vast.ai, Modal, Together AI e Google Cloud. Parti dalla categoria di prodotto necessaria: API di un modello gestita, calcolo serverless personalizzato, macchina on demand, noleggio su marketplace o capacità di cluster riservata. Le sezioni dedicate ai provider spiegano dove queste categorie si sovrappongono.

Si possono usare GPU cloud gratis?

Il piano Starter di Modal include crediti mensili di calcolo limitati, non accesso illimitato alle GPU, e gli addebiti a token degli Shared Endpoints sono separati. La Free Trial di Google blocca l'aggiunta di GPU fino al passaggio a un account a pagamento, mentre il Free Tier permanente le esclude. Together AI richiede esplicitamente crediti prepagati. Usa i crediti per valutare un carico di lavoro, non come piano di capacità per la produzione.

Come confrontare i servizi GPU cloud?

Confronta lo stesso checkpoint, la stessa precisione, le stesse lunghezze degli input e la stessa concorrenza sulla variante GPU e sulla dimensione di allocazione esatte. Includi avvio e inattività a pagamento, storage, trasferimenti e lavoro fallito. Il risultato utile è il costo del lavoro completato che rispetta i requisiti di latenza e ripristino, non il numero più basso accanto a «GPU-ora».

La prossima settimana, assegna a due finalisti lo stesso piccolo carico di lavoro e gli stessi criteri di accettazione. Registra picco di memoria, tempo al primo risultato utile, throughput dei job completati, durata fatturata delle risorse e costi che restano dopo l'arresto. Per l'addestramento, prova il ripristino da un checkpoint salvato; per l'inferenza, prova una richiesta dopo l'inattività e un picco di richieste. Espandi il deployment solo quando questi dati lo giustificano.

Scarica la checklist per l'audit dei workflow aziendali con l'AI e iscriviti alla newsletter per chi li gestisce.