Hosting per applicazioni di intelligenza artificiale: dimensionamento di CPU, GPU e storage

Limitare innanzitutto il carico di lavoro dell'IA

La scelta dell'hardware inizia dal compito da svolgere, non da una GPU. Nel caso della Inferenza Un modello esistente elabora gli input e genera, ad esempio, delle risposte. Il fine-tuning adatta un modello pre-addestrato a dati aggiuntivi o a un compito specifico; l’addestramento completo, invece, costruisce i pesi del modello nell’ambito di un ciclo di addestramento a sé stante.

Questi obiettivi determinano profili di carico diversi: un servizio di chat deve rispondere alle richieste, mentre un’attività di addestramento elabora dati per un periodo di tempo più lungo e salva i risultati intermedi. Per Hosting AI Dovresti quindi stabilire se l'attenzione debba concentrarsi sul tempo di risposta, sulle richieste elaborate, sulla durata della formazione o, ad esempio, sui costi di una determinata attività.

Documenta la versione del modello e il tempo di esecuzione, nonché il numero di parametri, l’architettura, la precisione e l’eventuale quantizzazione prevista. Annotare inoltre le lunghezze previste per gli input e gli output, le richieste simultanee o le dimensioni dei batch, nonché il carico di picco. In questo modo è possibile confrontare le offerte e i test successivi sulla base delle stesse ipotesi, anziché limitarsi a mettere a confronto i soli dati nominali dell’hardware.

Nel caso di un assistente di chat interno, una singola richiesta breve può essere gestita senza problemi, mentre diverse conversazioni lunghe possono sovraccaricare la memoria. La cache KV mantiene stati aggiuntivi durante la generazione del testo; il suo fabbisogno dipende, tra l’altro, dal modello e dall’elaborazione. Pertanto, non limitarti a pianificare solo per il dialogo medio, ma considera anche contesti lunghi e l’utilizzo in parallelo.

Tieni inoltre conto di quali dati vengono trattati, dove possono essere archiviati e quali livelli di disponibilità e tempi di ripristino sono necessari. Questi obiettivi operativi influenzano la scelta tra un singolo server e un’architettura più complessa. Le ipotesi rimangono un punto di partenza: solo una verifica con un carico rappresentativo potrà dimostrare se sono valide.

CPU e RAM in fase di sviluppo

Anche se un modello viene eseguito su una GPU, la CPU collabora lungo il percorso dei dati. Può ricevere richieste, tokenizzare il testo, leggere file e preparare gli input per l’elaborazione del modello. Se questa preparazione è troppo lenta, la GPU rimane in attesa di lavoro; in tal caso, un acceleratore più potente non risolve necessariamente il collo di bottiglia.

Il sito Memoria di lavoro A seconda dell'applicazione, occupa spazio per i componenti del modello, i dati preparati e le cache dei file. A ciò si aggiunge lo spazio di memoria necessario per i processi che caricano e convertono i dati di addestramento. Pertanto, non limitarti a pianificare solo il modello stesso, ma considera anche il percorso dal set di dati al batch finito e prevedi riserve sufficienti per i picchi di elaborazione.

I DataLoader di PyTorch possono utilizzare più worker per l'elaborazione parallela dei dati. Tuttavia, i worker aggiuntivi occupano anch'essi memoria; anche l'area di memoria condivisa può diventare insufficiente. Aumenta quindi il loro numero gradualmente e monitora i tempi di attesa dei dati e il fabbisogno di memoria, invece di adottare un valore fisso come raccomandazione generale.

Un numero maggiore di core della CPU è utile soprattutto nei casi in cui le attività da svolgere possano essere eseguite in parallelo. Se invece l’accesso allo storage, una singola fase di elaborazione o la stessa GPU limitano la velocità di elaborazione, l’aggiunta di ulteriori core non cambia granché. Anche il comportamento di clock può essere rilevante per le richieste brevi; per ulteriori approfondimenti si veda l’articolo su Governor della CPU sui server di hosting.

Per i modelli di piccole dimensioni o le richieste sporadiche, l’inferenza su CPU rappresenta un’alternativa da prendere in considerazione rispetto al sistema GPU sempre attivo. Confronta entrambe le varianti utilizzando lo stesso modello, con la precisione adeguata e il profilo di carico previsto. È fondamentale verificare se la CPU è in grado di garantire il tempo di risposta richiesto anche nei momenti di picco e quali costi effettivi ne derivano.

Comprendere bene la GPU e la VRAM

Nel caso di un’inferenza interamente residente sulla GPU, i pesi del modello devono essere contenuti nella memoria disponibile della GPU. Il Fabbisogno di VRAM Ma non finisce qui: il runtime necessita di ulteriori aree per i risultati intermedi e i buffer temporanei. Una mappa in cui i pesi rientrano a malapena dal punto di vista matematico non costituisce quindi una base sicura per il funzionamento in produzione.

Nella generazione autoregressiva di testo si aggiunge la cache KV. Questa memorizza gli stati di chiave e valore già calcolati, in modo che possano essere riutilizzati nelle fasi successive della generazione. Contesti lunghi e richieste elaborate contemporaneamente possono aumentare questo fabbisogno di memoria aggiuntivo; l’entità di tale aumento dipende dal modello e dall’elaborazione.

La documentazione di Transformers 4.48.2 descrive, tra le altre cose, la quantizzazione della cache e lo spostamento in memoria come possibilità per risparmiare VRAM. Il vantaggio dipende dall’implementazione e dal carico; ulteriori elaborazioni o trasferimenti di dati possono ridurre la velocità. Verifica quindi congiuntamente il consumo di memoria e il tempo di risposta, invece di considerare automaticamente un risparmio di memoria come un guadagno in termini di prestazioni.

Durante l'addestramento, il calcolo inferenziale è ancora meno sufficiente. Oltre ai pesi, sono necessari spazi di memoria per i gradienti, gli stati dell'ottimizzatore e le attivazioni memorizzate. L'entità di queste componenti dipende, tra l'altro, dall'ottimizzatore, dalla precisione e dal metodo di addestramento; sequenze più lunghe o batch più grandi possono aumentare in particolare la memoria dedicata alle attivazioni.

Per un'esecuzione interamente residente sulla GPU, la VRAM disponibile deve essere in grado di contenere i pesi e i dati di esecuzione necessari. I metodi ibridi possono mantenere parti dell'elaborazione o i pesi del modello al di fuori della GPU; la loro idoneità e i costi dei trasferimenti di dati dipendono dal tempo di esecuzione. Ciò va distinto dallo spostamento della cache KV descritto in Transformers 4.48.2.

Considera congiuntamente il modello, la durata dell'esecuzione e il parallelismo previsto e verifica i livelli massimi di memoria sotto un carico rappresentativo. Una memoria sufficiente per la modalità di esecuzione scelta non è di per sé una garanzia del tempo di risposta o del carico di lavoro desiderati.

Calcolo approssimativo della memoria del modello

Un primo calcolo della memoria parte dal numero dei parametri del modello e dal formato in cui vengono effettivamente memorizzati i loro pesi. Esso fornisce un limite minimo per questa quota di memoria, ma non ancora un dimensionamento completo del server GPU. In particolare, non indica quanta memoria richieda una specifica richiesta in fase di esecuzione.

Esempio di calcolo illustrativo, non si tratta di una misurazione: Sette miliardi di parametri moltiplicati per due byte danno 14 miliardi di byte per i pesi. Dividendo questo valore per 1.073.741.824 byte per GiB, si ottengono circa 13,0 GiB. Ciò presuppone che tutti i pesi considerati siano effettivamente rappresentati in modo uniforme con due byte per parametro; formati diversi o rappresentazioni aggiuntive modificano il calcolo.

Non è incluso il Cache KV per la generazione di testo, i buffer temporanei e l'overhead di esecuzione. Soprattutto in presenza di contesti lunghi, la cache può aumentare in modo significativo; anche il numero di richieste elaborate contemporaneamente è rilevante ai fini della riserva necessaria. La documentazione sulla cache di Transformers 4.48.2 descrive inoltre alcune tecniche che consentono di risparmiare memoria, ma che, a seconda della tecnica utilizzata, comportano una riduzione della velocità.

Per l’addestramento, il calcolo del peso non è affatto sufficiente. La documentazione relativa a Transformers 4.35.0 stima, per una configurazione esemplificativa a precisione mista con AdamW, 18 byte per parametro, oltre alle attivazioni. In questo valore sono inclusi ulteriori componenti quali i gradienti e gli stati dell’ottimizzatore; le attivazioni dipendono, tra l’altro, dalla lunghezza della sequenza e dalla dimensione del batch.

I 18 byte non rappresentano un moltiplicatore generico valido per ogni sessione di addestramento: l’ottimizzatore, la precisione e il metodo di addestramento possono modificare il fabbisogno. Pertanto, né da questo valore né dai 13,0 GiB si può dedurre una raccomandazione relativa a una determinata dimensione della VRAM. Per la scelta sono determinanti il tempo di esecuzione effettivo e i picchi di memoria previsti sotto un carico rappresentativo.

Confronto tra carichi di lavoro e colli di bottiglia

A parità di pesi del modello, a seconda del compito da svolgere possono presentarsi requisiti molto diversi. La tabella mostra possibili punti critici, senza indicare alcuna gerarchia né garantire l’esistenza di colli di bottiglia. Quale risorsa costituisca effettivamente il limite dipende, tra l’altro, dal modello, dalla pipeline di dati, dalla parallelizzazione e dal carico di lavoro.

Nel caso di un assistente di chat interno, il modello e la generazione rappresentano solo una parte della pianificazione. Definisci una lunghezza massima dell’input, una lunghezza prevista dell’output e il numero di utenti simultanei. Successivamente è possibile verificare se il tempo di risposta rimane accettabile in caso di picchi di carico e se pesi, cache e buffer rientrano contemporaneamente nella memoria disponibile.

Una ricerca di documenti con risposta generativa comporta un percorso di dati più lungo: i documenti vengono importati ed elaborati, vengono generati gli embedding, viene effettuato un search nell’indice e i contenuti rilevanti vengono trasmessi al modello linguistico. L'importazione e la ricerca possono avere requisiti di CPU, RAM e spazio di archiviazione diversi rispetto alla generazione. Pertanto, è opportuno registrare separatamente i tempi e i requisiti di memoria di queste fasi.

Durante la messa a punto è possibile Accumulo del gradiente consentono di ottenere una dimensione effettiva del batch maggiore, sebbene vengano elaborati contemporaneamente solo batch singoli più piccoli. I gradienti di più passaggi vengono raccolti prima che i parametri vengano aggiornati. Ciò può essere utile in caso di memoria limitata, ma non garantisce un aumento della produttività; i passaggi di elaborazione aggiuntivi possono richiedere tempo.

Anche l’alimentazione dei dati merita un’attenzione particolare: se la pre-elaborazione o il caricamento dei dati sono più lenti rispetto all’elaborazione del modello, una GPU più potente non è necessariamente d’aiuto. Al contrario, una pipeline di dati veloce non può sostituire una VRAM insufficiente. È quindi opportuno confrontare le alternative utilizzando gli stessi dati di input e un profilo di carico comprensibile.

Pianificazione dello storage e delle connessioni GPU

Ai fini della pianificazione dello spazio di archiviazione, è opportuno distinguere tra tipo di dati e modalità di accesso: i set di dati di addestramento vengono letti ripetutamente, mentre i pesi del modello vengono caricati prima dell’utilizzo. Entrambi necessitano di una fonte affidabile da cui possano essere nuovamente resi disponibili in caso di cambio di host. La capacità da sola non è sufficiente; anche i tempi di caricamento e i modelli di accesso influenzano il funzionamento.

I dati di lavoro temporanei possono essere memorizzati su un disco NVMe locale qualora sia necessario uno spazio di lavoro veloce. Verifica con il fornitore se questi dati resistono ai riavvii e ai cambi di host. I checkpoint e i backup, invece, richiedono una strategia di conservazione pianificata con cura e un percorso di ripristino verificato; una directory scratch locale non costituisce automaticamente un backup indipendente.

Lo storage condivisibile o basato su oggetti può facilitare la distribuzione e l'archiviazione di record di dati, pesi e checkpoint. È fondamentale verificare se l’applicazione supporti la modalità di accesso scelta e se i dati possano essere caricati e ripristinati entro i tempi previsti. Un’area di lavoro locale aggiuntiva può rivelarsi utile, ma non sostituisce l’archiviazione permanente.

GPUDirect Storage Consente, in presenza di condizioni adeguate a livello di hardware, software e file system, un percorso dei dati più diretto tra lo storage e la memoria della GPU. Ciò risulta particolarmente interessante quando l’input e l’output si trovano sul percorso critico e l’applicazione utilizza il percorso supportato. Se la CPU deve prima decodificare o pre-elaborare i dati, ciò può limitarne i vantaggi.

In presenza di più GPU, occorre distinguere tra replica e ripartizione. La replica fornisce copie del modello per distribuire le richieste; non trasforma automaticamente le aree VRAM separate in una memoria condivisa. La documentazione relativa a vLLM 0.20.1 descrive una tale distribuzione parallela dei dati; ciò non implica alcuna affermazione riguardo a qualsiasi altra versione di runtime.

Il parallelismo tensoriale e quello in pipeline, invece, distribuiscono parti dell’elaborazione e generano esigenze di comunicazione. A tal fine, verifica le connessioni tra le GPU e, in caso di più server, la topologia di rete e il supporto offerto dal modello e dal runtime. La documentazione relativa a vLLM 0.8.5 tratta queste strategie per il serving distribuito; le indicazioni specifiche riportate sono legate alla versione.

Rilevare i colli di bottiglia sotto carico

Un confronto significativo inizia con un documento profilo di carico. Specificare la versione del modello, la precisione, la variante hardware specifica e la versione del runtime. Aggiungere le lunghezze tipiche e massime del contesto, le lunghezze di output e il numero di richieste simultanee. In questo modo sarà possibile verificare una successiva modifica dell’infrastruttura alle stesse condizioni.

Durante l'inferenza, misura il tempo necessario per ottenere il primo token e la velocità di generazione. Registra inoltre gli errori e i tempi di risposta sia in condizioni di carico normale che in caso di picchi previsti. Un throughput medio elevato non è sufficiente se singole richieste, in presenza di contesti lunghi o di un elevato livello di parallelismo, rimangono in attesa troppo a lungo o falliscono.

Per l'addestramento e la messa a punto, è opportuno utilizzare come punto di partenza i passaggi o gli esempi elaborati per unità di tempo. Osserva inoltre quanto tempo la pipeline di dati richiede per il batch successivo. I DataLoader di PyTorch possono essere preparati con più worker; anche il loro fabbisogno di memoria e il carico sulla memoria condivisa devono essere presi in considerazione nella valutazione.

Rileva i picchi relativi alla memoria GPU e alla RAM, nonché l'utilizzo dello spazio di archiviazione e i tempi di attesa. Su un sistema NVIDIA esistente, il comando di lettura mostra nvidia-smi A seconda del dispositivo e del driver, tra le altre cose, lo stato della GPU e l'utilizzo della memoria. Non modifica alcuna configurazione operativa, ma non sostituisce una misurazione effettuata dall'applicazione.

Un basso carico della GPU, di per sé, non indica né un problema della CPU né un problema di storage. Confrontalo nel tempo con i tempi di attesa dei dati, l'andamento delle richieste e l'occupazione della memoria, modificando, se possibile, solo una variabile rilevante per ogni confronto. Documenta anche i limiti del test, ad esempio se mancano ancora picchi di carico rari o input particolarmente lunghi.

Gestire in modo affidabile l'infrastruttura di IA

La pianificazione operativa richiede una combinazione verificabile di variante della GPU, driver, framework e runtime del modello. Prima di effettuare gli aggiornamenti, verifica quali versioni sono supportate insieme e come tornare alla combinazione precedente in caso di problemi. In presenza di percorsi dati specifici, come GPUDirect Storage, anche l’hardware, il software e il file system devono essere adeguati all’uso previsto.

Stabilisci chi è autorizzato a leggere o modificare modelli, dati di addestramento, protocolli e interfacce amministrative. Per i dati sensibili, è inoltre necessario verificare che la posizione di archiviazione, la trasmissione dei dati e il periodo di conservazione siano conformi ai requisiti in materia di protezione dei dati. Verifica questi aspetti per tutti i servizi coinvolti, non solo per il server su cui è in esecuzione il modello.

A Punto di controllo salva lo stato dell'addestramento in vista di un successivo ripristino. Definisci quali stati sono necessari al tuo software di addestramento, con quale frequenza devono essere salvati e per quanto tempo devono essere conservati. I pesi del modello destinati alla distribuzione e i checkpoint per la ripresa dell'addestramento hanno finalità diverse e dovrebbero essere contrassegnati di conseguenza.

Lo spazio di archiviazione locale non è automaticamente permanente e non sostituisce un backup indipendente. Chiedi al fornitore cosa succede ai dati locali in caso di riavvio, sostituzione dell’host o scadenza del contratto. Conserva i dati necessari indipendentemente dall’area di lavoro e verifica il ripristino nella pratica, compreso il tempo necessario per tornare operativi.

Nel caso di lavori distribuiti, il monitoraggio comprende, oltre alle singole GPU, anche i nodi, le connessioni di rete e lo stato di avanzamento dell’intera applicazione. Pianificare da quale stato salvato un processo debba ripartire dopo un'interruzione e quali risorse debbano essere disponibili a tal fine. Se parti del modello sono distribuite su più server, anche le loro connessioni influenzano il funzionamento; le indicazioni contenute nella documentazione vLLM 0.8.5 sono specifiche per quella versione.

Scegliere il modello di hosting e il server GPU

In caso di lavori occasionali, è possibile ricorrere a un Server GPU può essere vantaggioso: paghi in base alle condizioni specifiche dell’offerta per la fornitura necessaria, invece di mantenere una capacità a disposizione in modo permanente. Confronta anche i tempi di avvio, la disponibilità nel momento desiderato e i costi relativi ai dati archiviati e alla trasmissione dei dati.

In caso di carico costante, vale la pena optare per un’infrastruttura riservata in modo permanente. Questa soluzione può offrire un maggiore controllo sui tempi di esecuzione e sul percorso dei dati, ma richiede una pianificazione autonoma per gli aggiornamenti, il monitoraggio e il ripristino. Un servizio di inferenza gestito si fa carico di parte di queste operazioni; verifica, tuttavia, quali modelli, impostazioni e percorsi dei dati siano effettivamente disponibili in tale contesto.

Per la scelta dell'infrastruttura di machine learning sono necessarie informazioni relative a una specifica versione della GPU in particolare: capacità della VRAM, larghezza di banda della memoria, formati di calcolo supportati e fattore di forma. Non applicare i valori massimi di una famiglia di prodotti a ogni variante senza averli verificati. Confronta le specifiche prestazionali solo con le relative condizioni di test e il modello previsto, anziché basare la decisione esclusivamente su un valore teorico massimo.

Anche il tipo di scalabilità fa parte dell’offerta: le istanze replicate possono distribuire le richieste, mentre la suddivisione del modello richiede il supporto da parte del runtime e della topologia di connessione. La documentazione di vLLM tratta il parallelismo dei dati nella versione 0.20.1 e il serving distribuito nella versione 0.8.5; queste affermazioni non dovrebbero essere applicate ad altre versioni senza prima averne verificato la validità.

Definisci innanzitutto il modello e il profilo di carico, quindi valuta la memoria e il percorso dei dati e richiedi preventivi adeguati. Verifica infine i tempi di risposta, gli errori e il fabbisogno di risorse utilizzando richieste rappresentative o dati di addestramento. Troverai ulteriori aspetti utili per la valutazione alla voce Hosting GPU per applicazioni web. Senza questo confronto tra i carichi di lavoro, non è possibile formulare una raccomandazione generale riguardo alle GPU.