Negli ultimi mesi ho passato più tempo del previsto a valutare modelli linguistici (i cosiddetti LLM, quelli dietro ChatGPT e assistenti simili) da far girare in locale, cioè sul mio hardware, non su un servizio cloud. Il motivo è semplice: dati aziendali che restano dentro casa, nessun costo per ogni domanda fatta al modello, nessuna dipendenza da un servizio esterno che può cambiare condizioni o prezzi da un giorno all’altro. Il problema è altrettanto semplice: come faccio a sapere, prima di installare qualcosa, se il mio computer o il mio server ce la fa davvero?
Per un po’ ho risposto per tentativi: installare, provare, aspettare che il sistema rallenti fino a diventare inutilizzabile o vada in errore per mancanza di memoria video. Poi ho trovato uno strumento gratuito che fa questi conti prima ancora di scaricare un solo file da qualche decina di GB: l’ApX VRAM Calculator.
Quattro parole prima di iniziare
Per capire cosa fa questo calcolatore, bastano quattro concetti, senza scendere nel tecnico.
- VRAM: è la memoria della scheda video, diversa dalla RAM del computer. Un modello linguistico deve stare quasi interamente dentro questa memoria per funzionare in modo fluido: se non basta, il sistema rallenta drasticamente o si blocca.
- Parametri: è la “taglia” del modello, indicata con sigle come 7B, 14B o 70B (miliardi di parametri). Più parametri significano, in genere, un modello più capace, ma anche più memoria richiesta per farlo girare.
- Contesto: è quanto testo il modello riesce a tenere “in mente” mentre elabora una risposta, misurato in token (un token è grosso modo una parola o una porzione di parola). Più contesto vuol dire poter incollare documenti più lunghi, ma anche più memoria occupata.
- Quantizzazione: è una compressione dei numeri interni del modello, pensata apposta per farlo occupare meno memoria. Si paga con un po’ di precisione nelle risposte, in cambio di poter far girare modelli altrimenti troppo pesanti per la propria scheda video.
La logica dietro i numeri
Il calcolatore stima quanta VRAM serve incrociando questi fattori, che si muovono in direzioni diverse. Un modello più grande, con più parametri, richiede più memoria. Un contesto più lungo aumenta la cosiddetta KV cache, cioè lo spazio che il modello usa per tenere traccia di quello che ha già letto, e quindi la memoria occupata. Una quantizzazione più aggressiva libera invece memoria, al prezzo di un compromesso sulla qualità delle risposte. Capire come questi tre fattori si bilanciano tra loro è già metà del lavoro.
Il primo test: un solo utente, per capire se il modello parte
Per rispondere alla domanda più semplice, “questo modello gira sulla mia GPU”, uso sempre lo stesso punto di partenza: modalità Inference (non Fine-tuning, che serve a chi vuole addestrare o adattare un modello da zero, un’operazione diversa e molto più pesante), batch size 1, un solo utente concorrente, contesto a 8K token, la GPU realmente installata nella macchina e offloading disattivato. Questa configurazione serve solo a capire se il modello entra in memoria, non descrive ancora un uso reale in ufficio: batch 1 e un solo utente sono il caso più leggero possibile, quello con meno richieste di VRAM. Cambiare anche solo la scheda video con una che ha meno VRAM, a parità di modello, può comunque ribaltare completamente l’esito anche di questo test minimo.
La configurazione realistica, quella che conta davvero
Il test a un utente serve solo a scartare in fretta un hardware chiaramente insufficiente. Prima di decidere se portare un modello in produzione in azienda, conviene rifare il calcolo con numeri vicini a come lo strumento verrà usato davvero, non con il minimo indispensabile. Qualche riferimento pratico:
- Assistenza clienti o gestione email: contare almeno 3-5 utenti concorrenti per un piccolo team, non 1, e un contesto di 16K-32K token, perché una conversazione con lo storico dei messaggi precedenti supera facilmente gli 8K iniziali.
- Lettura di documenti interi (contratti, manuali, verbali di riunione): un contesto di almeno 32K-64K token, anche con un solo utente alla volta, perché il documento da solo può occupare gran parte della memoria disponibile per il contesto.
- Strumento condiviso da tutto l’ufficio: il numero di utenti concorrenti da usare nel calcolo è quante persone lo useranno davvero nello stesso momento, di solito una frazione ridotta di chi vi ha accesso, non l’organico totale dell’azienda.
In tutti questi scenari la VRAM richiesta sale, a volte in modo sensibile, rispetto al test iniziale a un utente. È qui che spesso emerge se la macchina messa in conto basta davvero o se serve un salto di scheda video, più GPU insieme, oppure una quantizzazione più aggressiva per restare dentro la memoria disponibile.
Come leggo il risultato
Il calcolatore restituisce tre situazioni possibili. Ampio margine: la VRAM richiesta resta ben sotto quella disponibile, situazione comoda. Al limite: il modello entra, ma un contesto più lungo o altri programmi aperti sulla stessa macchina possono saturare la GPU. Non entra: serve una quantizzazione più spinta, un contesto più corto, oppure più VRAM, più schede video o offloading. Un modello che entra in memoria, però, non è ancora un modello piacevole da usare: guardo sempre anche i token al secondo generati e il tempo prima della prima risposta, non solo se la VRAM basta.
Un esempio concreto
Scelgo Inference, seleziono il modello esatto che mi interessa, per esempio una variante da 14 miliardi di parametri e non solo la famiglia generica, provo prima la quantizzazione Q4 (una via di mezzo ragionevole tra peso e qualità), indico la GPU davvero installata nel PC e il numero di schede. Faccio un primo passaggio con batch 1, un utente e 8K di contesto, solo per verificare che il modello parta. Poi rifaccio il calcolo con i numeri del caso d’uso reale, per esempio 5 utenti concorrenti e 32K di contesto per un piccolo team di assistenza clienti, e controllo di nuovo la VRAM richiesta, la velocità e la latenza con questi valori più realistici. Resta comunque una stima: runtime, driver, architettura del modello e altri carichi sulla macchina possono spostare il risultato reale, in un senso o nell’altro.
Se in azienda vi state chiedendo se ha senso portare un modello linguistico in locale, invece di affidarvi solo al cloud, questi numeri, calcolati sul caso d’uso reale e non sul test minimo a un utente, sono il primo posto da cui partire prima di comprare hardware.
Guarda la sintesi in slide
Ho riassunto questo stesso ragionamento in un piccolo deck di slide, utile se preferite scorrerlo velocemente o condividerlo con chi in azienda deve decidere sull’hardware.
