Le migliori GPU cloud per il servizio e il deployment di LLM

Cosa richiede realmente il serving di un LLM da una GPU noleggiata

Il serving di un modello di linguaggio di grandi dimensioni è un carico di lavoro fondamentalmente diverso dall’addestramento. L’addestramento è limitato dalla capacità di throughput e tollerante alla latenza; il serving è sensibile alla latenza, limitato dalla memoria e a raffiche. Quando noleggia una GPU per distribuire un LLM dietro un’API, il collo di bottiglia raramente è rappresentato dai FLOPS grezzi. È quanto del modello e della sua cache KV può essere mantenuto nella VRAM, quanto velocemente quella memoria può essere trasferita e quante richieste concorrenti può raggruppare prima che i token al secondo per utente crollino.

La cache KV è la parte che la maggior parte delle persone sottovaluta. Ogni richiesta attiva memorizza le chiavi e i valori di attenzione per il suo contesto, e questa impronta cresce con la lunghezza della sequenza e il numero di utenti concorrenti. Un modello che si adatta comodamente a riposo può esaurire la memoria nel momento in cui si spinge traffico reale con prompt lunghi. Per questo motivo, le distribuzioni di serving spesso necessitano di più spazio VRAM rispetto a quanto suggeriscono solo i pesi del modello.

Come dimensionare la GPU rispetto al modello

La prima domanda pratica è se il modello si adatta su una sola GPU o deve essere suddiviso su più dispositivi. Confrontando quanto sopra con il suo modello, consideri questi fattori:

• La capacità VRAM determina quali modelli si adattano. Un modello quantizzato da 7B–13B in FP8 o INT8 può essere servito da un singolo acceleratore di fascia media, mentre un modello da 70B in BF16 generalmente necessita di una scheda ad alta memoria o di un nodo multi-GPU. I modelli di frontiera molto grandi richiedono effettivamente più GPU di fascia alta collegate insieme.
• La larghezza di banda della memoria determina la velocità di generazione dei token. La decodifica autoregressiva legge l’intero set di pesi per ogni token prodotto, quindi la memoria di classe HBM (come quella presente nelle schede per data center) genera token molto più velocemente rispetto alle schede consumer basate su GDDR per lo stesso modello. Per la chat interattiva, la larghezza di banda spesso conta più della potenza di calcolo.
• Le precisioni supportate determinano quanto aggressivamente si può ridurre il modello. Le schede con supporto per tensori FP8 e INT8 consentono di servire modelli più grandi con meno VRAM e a un throughput più elevato, a condizione che lo stack di serving e lo schema di quantizzazione del modello siano compatibili.
• L’interconnessione è importante quando un modello si estende su più GPU. Il serving in parallelo tensoriale scambia attivazioni tra GPU ad ogni livello, quindi i collegamenti di classe NVLink all’interno di un nodo offrono una latenza significativamente migliore rispetto alle configurazioni solo PCIe. Per le distribuzioni su singola GPU, l’interconnessione è irrilevante.

Serving su singola GPU versus multi-GPU

Se il suo modello e la sua cache KV di picco si adattano su una sola GPU, mantenga quella configurazione. Il serving su singola GPU evita completamente l’overhead di comunicazione tra dispositivi ed è più semplice da gestire. Passi al parallelismo tensoriale o al serving multi-nodo solo quando il modello non può davvero essere contenuto, perché ogni GPU aggiunta introduce costi di sincronizzazione e complica l’autoscaling. Quando ha bisogno di più GPU, preferisca istanze nella lista sopra che abbinano schede ad alta memoria con un’interconnessione veloce all’interno del nodo piuttosto che assemblare schede poco collegate tra loro.

Caratteristiche del provider importanti per il serving, non per l’addestramento

Oltre al silicio, il modello operativo del provider decide se una distribuzione è praticabile. Quando esamina il confronto sopra per un carico di lavoro di serving anziché per un addestramento, dia priorità diversa:

• Tempo di avvio a freddo e di configurazione diventano preoccupazioni di prima classe. Un endpoint di serving che scala a zero tra picchi di traffico paga il costo dell’avvio a freddo ad ogni aumento di scala, quindi un provisioning rapido e la memorizzazione nella cache delle immagini influenzano direttamente la latenza finale.
• La granularità di fatturazione cambia l’economia del traffico a raffiche. La fatturazione al secondo o al minuto è adatta per endpoint autoscalanti che avviano e arrestano istanze; la fatturazione grossolana all’ora penalizza questo modello.
• Affidabilità on-demand rispetto a spot è generalmente la scelta giusta. Le istanze interrotte o spot sono eccellenti per l’addestramento e i lavori batch ma rischiose per un endpoint rivolto all’utente, dove un recupero a metà richiesta interrompe il traffico live. Le istanze spot possono comunque servire bene l’inferenza batch non interattiva.
• Storage persistente e caricamento rapido del modello riducono i disagi di riavvio. Pesi di più gigabyte che si ricaricano da uno storage freddo a ogni riavvio aggiungono minuti di inattività; volumi memorizzati nella cache o allegati riducono questo problema.
• Networking e uscita dati influenzano i costi su larga scala. L’inferenza ad alto throughput può trasferire molti dati in uscita; verifichi i termini di uscita prima di impegnarsi in una distribuzione ad alto traffico.

Batch versus tempo reale, e dove si colloca il costo

Decida presto per quale modalità intende ottimizzare. Il serving interattivo in tempo reale valorizza un basso tempo al primo token e tassi costanti di token per utente, favorendo memoria ad alta larghezza di banda e dimensioni di batch modeste. L’inferenza batch o offline valorizza il throughput totale e può impacchettare grandi batch su hardware più economico o interrotto, scambiando la latenza per richiesta con un costo per token molto migliore. Molti team gestiscono entrambe le modalità: un livello reattivo on-demand per utenti live e un livello batch supportato da spot per la generazione in massa.

Per quanto riguarda il costo del noleggio, il serving copre tutto lo spettro. Un modello piccolo quantizzato su una scheda di fascia media è economico e ampiamente disponibile; i modelli di frontiera su nodi multi-GPU ad alta memoria sono scarsi, più costosi e talvolta soggetti a vincoli di capacità durante i picchi di domanda. Poiché le tariffe variano costantemente e dipendono dalla regione e dall’impegno, consideri il confronto live sopra come fonte di verità piuttosto che una cifra fissa, e confronti le istanze in base a VRAM, classe di larghezza di banda, interconnessione e modello di fatturazione insieme, non solo al prezzo di listino.

Domande frequenti

Quanta VRAM serve per servire un LLM?

Preveda la memoria per i pesi del modello alla precisione scelta più un ampio margine per la cache KV, che cresce con la lunghezza del contesto e gli utenti concorrenti. Indicativamente, modelli piccoli e medi quantizzati si servono da una singola scheda di fascia media, mentre modelli grandi in precisione più alta necessitano di una scheda ad alta memoria o di più GPU. Dimensioni sempre per la concorrenza di picco, non per l’inattività.

Le GPU spot o interrotte sono adatte per il serving di LLM?

Per endpoint real-time rivolti all’utente, generalmente no, perché un recupero può interrompere richieste live e costringere a riavvii a freddo. Le istanze spot sono adatte per inferenza offline o batch, dove le interruzioni rallentano solo il throughput senza interrompere una sessione interattiva. Molti team mantengono capacità on-demand per il traffico live e usano spot per i lavori in massa.

Perché la larghezza di banda della memoria conta più del calcolo per il serving?

La decodifica token per token legge i pesi del modello dalla memoria per ogni token generato, quindi la velocità di generazione è limitata da quanto velocemente la GPU può trasferire dati dalla memoria piuttosto che dai suoi FLOPS di picco. Per questo motivo le schede da data center equipaggiate con HBM producono token più velocemente delle schede consumer che ospitano lo stesso modello, e perché la larghezza di banda è una colonna chiave da confrontare sopra.

Devo servire su una sola GPU o suddividere su più GPU?

Utilizzi una singola GPU ogni volta che il modello e la sua cache KV di picco si adattano, poiché questo evita la comunicazione tra dispositivi e semplifica la scalabilità. Passi al parallelismo tensoriale multi-GPU solo quando il modello non può davvero essere contenuto, e in tal caso scelga istanze che combinano schede ad alta memoria con un’interconnessione veloce all’interno del nodo.