Le migliori GPU cloud per l'inferenza e il servizio di modelli

I carichi di lavoro di inferenza hanno requisiti diversi rispetto all'addestramento: bassa latenza, elevata capacità di elaborazione e scalabilità efficiente in termini di costi. Endpoint GPU serverless, autoscaling e fatturazione al secondo diventano fondamentali quando si servono predizioni in produzione. Questa guida elenca i fornitori di GPU cloud ottimizzati per l'inferenza, inclusi quelli che offrono GPU serverless, deployment con scalabilità a zero e modelli GPU specifici per l'inferenza come L40S e T4.

Aggiornato Luglio 2026 inference

Nessun fornitore GPU corrispondente trovato per questa guida. Torni a controllare presto.

Cosa richiede realmente l’inferenza da una GPU noleggiata

L’inferenza è la fase di servizio della vita di un modello: i pesi sono già addestrati e si paga per il calcolo ogni volta che un utente invia un prompt, un’immagine o una richiesta. Questo cambia completamente la matematica dell’hardware rispetto all’addestramento. L’addestramento è vincolato dalla capacità di throughput e dura ore o giorni su cluster densi; l’inferenza è sensibile alla latenza, a raffiche, e funziona indefinitamente. Quando si noleggia una GPU per servire un modello, si ottimizza per il costo per token o per richiesta a un tempo di risposta accettabile, non per i FLOP grezzi su un lavoro lungo.

Il vincolo singolo più importante è solitamente la capacità di memoria, non il calcolo. Un modello deve entrare nella VRAM insieme alla sua cache key-value (KV), che cresce con la dimensione del batch e la lunghezza del contesto. Per i grandi modelli linguistici questo è il fattore dominante: un modello servito in 16 bit necessita di circa due byte per parametro solo per i pesi, quindi un modello di media dimensione può stare comodamente su una singola scheda di fascia media mentre un modello di scala frontier può richiedere più GPU collegate insieme. Il confronto sopra consente di filtrare precisamente per VRAM in modo da abbinare una scheda al modello più grande che si intende servire più un margine per richieste concorrenti.

Le specifiche che influenzano il costo e la latenza dell’inferenza

  • La capacità di VRAM determina se il modello e la sua cache KV entrano in una sola GPU o devono essere suddivisi. Lo spill su una seconda GPU o sulla memoria host aggiunge latenza e complessità.
  • La larghezza di banda della memoria è il vero collo di bottiglia per la generazione di token. La decodifica autoregressiva legge l’intero set di pesi per ogni token prodotto, quindi la memoria ad alta larghezza di banda (classe HBM) genera token più velocemente della memoria di tipo GDDR allo stesso livello di calcolo.
  • Il supporto per la bassa precisione è estremamente importante. Le schede con percorsi tensoriali FP8 o INT8 consentono di quantizzare i modelli per servire più richieste per dollaro con poca perdita di qualità. La quantizzazione a 8 bit o 4 bit riduce anche l’ingombro di memoria, spesso permettendo a un modello di entrare su una scheda più economica.
  • L’interconnessione (NVLink contro PCIe) conta solo quando un modello si estende su più GPU. Per il servizio su singola GPU è irrilevante; per il servizio tensor-parallelo di modelli molto grandi influisce direttamente sulla latenza dei token.

Inferenza batch (offline) versus inferenza in tempo reale

Due schemi di servizio molto diversi si nascondono sotto la parola “inferenza” e richiedono noleggi differenti.

L’inferenza in tempo reale serve utenti live: un chatbot, un endpoint API, un generatore di immagini dietro un’app web. Qui domina la latenza di coda, le GPU spesso rimangono parzialmente inattive in attesa del traffico e non si può tollerare che un’istanza venga rimossa a metà richiesta. Questo schema favorisce capacità on-demand sempre disponibili e una scheda con elevata larghezza di banda della memoria affinché la latenza per richiesta rimanga bassa anche con batch di piccole dimensioni.

L’inferenza batch o offline elabora un grande arretrato: valutazione di un dataset, generazione di embedding per un corpus, didascalia di un milione di immagini. Non ci sono utenti live, quindi la latenza per elemento conta poco e si possono impacchettare batch grandi per saturare la GPU. Questo schema è il candidato ideale per capacità interrompibile o spot, perché se un’istanza viene recuperata si riprende semplicemente la coda. Quando leggete la lista sopra, decidete prima in quale di questi due schemi vi trovate, perché cambia quale modello di fatturazione e livello di disponibilità è razionale.

Perché il throughput e l’utilizzo battono i FLOP di picco

Una scheda che sembra due volte più potente sulla carta raramente dimezza la bolletta dell’inferenza. La decodifica è vincolata dalla memoria, quindi il picco di calcolo pubblicizzato di una GPU è spesso sottoutilizzato durante la generazione. Ciò per cui si paga realmente è token effettivi al secondo per dollaro sotto le vostre reali dimensioni di batch e lunghezze di contesto. Le moderne architetture di servizio recuperano molta capacità sprecata tramite batching continuo, cache KV paginata e quantizzazione. La conclusione pratica quando si noleggia: una GPU di fascia media che esegue un server ottimizzato può battere una scheda di punta che esegue un server non ottimizzato, e una scheda più piccola e meno costosa che comunque supporta il modello è spesso la vincitrice in termini di costo per traffico costante.

Caratteristiche del provider che contano specificamente per il servizio

L’inferenza gira continuamente, quindi le caratteristiche della piattaforma circostante pesano più che per un lavoro di addestramento occasionale. Quando si confrontano le opzioni sopra, verificate queste dimensioni:

  • Granularità di fatturazione: la fatturazione al secondo o al minuto premia il servizio a raffiche e scalabile a zero; la fatturazione oraria grossolana penalizza gli endpoint che rimangono inattivi tra picchi di traffico.
  • Avvio a freddo e velocità di provisioning: se scalate le repliche su e giù in base alla domanda, la velocità con cui una nuova istanza GPU diventa pronta influisce direttamente sulla latenza percepita dall’utente e sulla vostra capacità di autoscaling.
  • Archiviazione persistente e caching delle immagini: scaricare grandi pesi del modello a ogni avvio è lento e talvolta misurato. Immagini cache o volumi allegati che contengono i pesi riducono drasticamente gli avvii a freddo.
  • Costi di uscita (egress): il servizio invia continuamente risultati agli utenti. Il costo per gigabyte di uscita, invisibile durante l’addestramento, può diventare una voce significativa per API ad alto volume.
  • Affidabilità on-demand versus prezzi spot: gli endpoint in tempo reale generalmente necessitano di capacità garantita on-demand; i lavori batch possono puntare a istanze interrompibili più economiche.
  • Opzioni di autoscaling e serverless: scalare a zero è importante quando il traffico è a raffiche, così non si paga per una GPU inattiva durante la notte.

Come leggere il confronto sopra per l’inferenza

Procedete in questo ordine. Prima, identificate il modello più grande che dovete servire e confermate che una scheda abbia abbastanza VRAM per i pesi più la cache KV alla concorrenza prevista. Secondo, preferite alta larghezza di banda della memoria e supporto a bassa precisione (FP8/INT8) per massimizzare i token al secondo per dollaro. Terzo, abbinate il modello di fatturazione e disponibilità al vostro schema: on-demand con fatturazione granulare per endpoint live, capacità interrompibile per lavori batch offline. Usate la tabella live per i prezzi attuali, poiché il prezzo orario varia con la domanda e la scarsità e cambia a seconda del provider; la regola duratura è che la scheda più economica che supporta comodamente il vostro modello e traffico quasi sempre vince, non la più potente disponibile.

Domande frequenti

Quanta memoria GPU mi serve per servire un modello in inferenza?

Pianificate per i pesi del modello più la cache key-value. In 16 bit, i pesi necessitano di circa due byte per parametro, e la quantizzazione a 8 bit o 4 bit riduce notevolmente questo valore. Aggiungete poi un margine per la cache KV, che cresce con la dimensione del batch e la lunghezza del contesto. Filtrate la lista sopra per VRAM e scegliete una scheda che supporti il modello con margine sufficiente affinché la concorrenza non vi faccia esaurire la memoria.

Una GPU più economica è sufficiente per l’inferenza o serve una scheda di punta?

Per molti carichi di lavoro di servizio, una scheda di fascia media offre un miglior rapporto qualità-prezzo. La generazione di token è vincolata dalla larghezza di banda della memoria più che dal calcolo di picco, quindi i FLOP di punta sono spesso sottoutilizzati. Se il vostro modello entra nella VRAM di una scheda più piccola e uno stack di servizio ottimizzato mantiene la GPU occupata, di solito otterrete un costo per token migliore rispetto al noleggio dell’opzione più costosa.

Dovrei usare istanze spot o interrompibili per l’inferenza?

Dipende dallo schema. L’inferenza batch offline tollera bene le interruzioni, poiché potete riprendere una coda, rendendo attraente la capacità spot più economica. Gli endpoint in tempo reale, rivolti agli utenti, generalmente necessitano di capacità garantita on-demand, perché il recupero di un’istanza a metà richiesta causa errori e rompe le garanzie di latenza.

Cosa rende la fatturazione dell’inferenza diversa da quella dell’addestramento?

L’addestramento è un lavoro finito e vincolato al throughput, mentre l’inferenza funziona continuamente e spesso rimane inattiva tra i picchi di traffico. Questo rende la fatturazione al secondo, il provisioning rapido, lo scale-to-zero e i costi di uscita prevedibili molto più importanti per il servizio rispetto a un addestramento occasionale. Valutate queste caratteristiche della piattaforma nel confronto sopra insieme al costo orario grezzo della GPU.