Introduzione: perché eseguire un LLM in locale?

“Possiamo farlo sulla nostra macchina?” è una delle prime domande che i team pongono quando valutano un modello di linguaggio open source. Le motivazioni variano: dati sensibili che non possono lasciare l’azienda, costi mensili prevedibili o semplicemente il desiderio di non dipendere da fornitori esterni. Qualunque sia il motivo, la domanda successiva è sempre la stessa: che hardware è necessario e quanto?

Le pagine dei fornitori e i thread dei forum raramente rispondono in modo diretto. La maggior parte della risposta è, però, una questione di aritmetica. Serve conoscere tre valori pubblici: il numero di parametri del modello, la memoria disponibile sulla GPU (o unificata) e la larghezza di banda di memoria della GPU. Il metodo completo è descritto passo dopo passo nel seguito, con esempi concreti su dodici modelli open source.

Passo 1 – Calcolare i pesi del modello

I pesi devono risiedere nella memoria della GPU. La loro dimensione è semplicemente:

pesi (GB) = parametri (miliardi) × byte per parametro

Il numero di byte per parametro dipende dalla precisione con cui il modello viene caricato:

    • 16 bit (BF16/FP16): 2 byte per parametro – qualità di riferimento.
    • 8 bit (FP8/INT8): 1 byte per parametro – compromesso comune in produzione.
    • 4 bit (INT4/FP4): 0,5 byte per parametro – consente modelli più grandi su hardware più piccolo.

Esempio pratico: Mistral Small 3.2 ha 24,0 miliardi di parametri. In 16 bit richiede 48 GB di peso, in 8 bit 24 GB e in 4 bit 12 GB. Ridurre la precisione comporta perdita di qualità, variabile a seconda del modello e del compito. È fondamentale valutare la qualità sul proprio set di test prima di scegliere una precisione più bassa.

Passo 2 – La cache KV, la parte che tutti dimenticano

I pesi non sono l’unica cosa che occupa memoria. Per ogni token nel contesto, ciascun livello di attenzione conserva un vettore chiave e un vettore valore, noti collettivamente come cache KV. La dimensione per token è:

cache KV per token (byte) = 2 × layer × teste KV × dimensione testa × byte per valore

Prendendo Mistral Small 3.2, il file config.json ufficiale indica 40 layer, 8 teste KV e una dimensione testa di 128. Con precisione a 16 bit:

2 × 40 × 8 × 128 × 2 = 163 840 byte ≈ 160 KiB per token.

Con un contesto di 32 000 token la cache richiede circa 5,4 GB; con 128 000 token sale a circa 21,5 GB, quasi tanto quanto i pesi in 8 bit. Alcune architetture, come Qwen3.8 27B, usano una combinazione di attenzione completa e lineare, riducendo drasticamente la cache. Per Qwen3.8, solo 16 dei 64 layer usano attenzione completa, portando a 2 GiB di cache per 32 k token.

La cache si moltiplica anche per le richieste concorrenti: dieci utenti con contesti da 32 k token richiedono dieci cache indipendenti. Una regola pratica è aggiungere un 20 % ai pesi per coprire cache e overhead di esecuzione, ma questa stima è valida solo per contesti brevi e un singolo utente. Per contesti lunghi o molti utenti è necessario calcolare la cache esplicitamente.

Passo 3 – Velocità determinata dalla larghezza di banda di memoria

Durante la generazione, il modello legge i pesi dalla memoria per ogni token prodotto. Con batch piccoli, il collo di bottiglia è la larghezza di banda di memoria, non la capacità di calcolo. Il limite teorico è:

token/s (flusso singolo) ≈ larghezza di banda (GB/s) ÷ byte letti per token (GB)

Per un modello denso, i byte letti per token corrispondono a tutti i pesi. Per i modelli a esperti misti, solo i parametri attivi vengono letti, rendendo questi ultimi più veloci per la stessa dimensione.

Esempi con dati ufficiali:

    • Qwen3.8 27B in 8 bit su NVIDIA RTX PRO 6000 Blackwell (1,792 GB/s) → 1,792 ÷ 27,8 ≈ 64 token/s.
    • gpt‑oss‑120b in 4 bit (117 B parametri, 5,1 B attivi) → 2,55 GB per token. Su NVIDIA DGX Spark (273 GB/s) → 107 token/s. Su Apple Mac Studio M5 Max (614 GB/s) → 241 token/s.

Questi valori sono dei “tetti” teorici; le prestazioni reali sono inferiori perché i kernel non sfruttano il massimo della banda, la cache KV deve essere letta e la suddivisione su più GPU introduce latenza di comunicazione. Tuttavia, il tetto è utile per scartare hardware inadeguato e per orientare i test successivi.

Passo 4 – Dal volume mensile al throughput necessario

Le aziende pensano spesso in termini di richieste mensili, non di token al secondo. La conversione è diretta:

token/s richiesti = richieste/mese × token di output per richiesta ÷ secondi al mese

Esempio: 200 000 richieste al mese, ciascuna con circa 300 token di output (≈ 225 parole). Il totale è 60 milioni di token in 2 592 000 secondi, cioè ≈ 23 token/s in media. I picchi saranno più alti del valore medio; per un’interazione fluida è necessario dimensionare per il picco, non per la media.

Applicazione pratica a 12 modelli open source

Utilizzando i passi 1 e 2 (peso + 20 % per cache, contesto corto) sui seguenti modelli, si ottengono le dimensioni in GB per le tre precisioni più comuni:

    • Qwen3.5 9B – 23 GB (16 bit), 12 GB (8 bit), 6 GB (4 bit)
    • Gemma 4 26B A4B – 62 GB, 31 GB, 15 GB
    • Qwen3.6 35B‑A3B – 86 GB, 43 GB, 22 GB
    • gpt‑oss‑20b – 50 GB, 25 GB, 13 GB
    • Mistral Small 3.2 – 58 GB, 29 GB, 14 GB
    • Qwen3.8 27B – 67 GB, 33 GB, 17 GB
    • Gemma 4 31B – 75 GB, 38 GB, 19 GB
    • gpt‑oss‑120b – 281 GB, 140 GB, 70 GB
    • Mistral Medium 3.5 – 306 GB, 153 GB, 77 GB
    • Llama 4 Maverick – 964 GB, 482 GB, 241 GB
    • Qwen3.5 397B – 968 GB, 484 GB, 242 GB
    • Nemotron 3 Ultra – 1 345 GB, 673 GB, 336 GB

Hardware di riferimento

Di seguito le specifiche di alcune GPU e sistemi unificati più comuni:

    • NVIDIA GeForce RTX 5090 – 32 GB, 1,792 GB/s
    • NVIDIA DGX Spark – 128 GB unificati, 273 GB/s
    • Apple Mac Studio M5 Max – fino a 128 GB unificati, 614 GB/s
    • Apple Mac Studio M5 Ultra – fino a 512 GB unificati, 1,2 TB/s
    • NVIDIA RTX PRO 6000 Blackwell – 96 GB, 1,792 GB/s
    • NVIDIA L40S – 48 GB, 864 GB/s
    • NVIDIA H100 SXM – 80 GB, 3,35 TB/s
    • NVIDIA H200 – 141 GB, 4,8 TB/s
    • NVIDIA DGX B200 (8 GPU) – 1 440 GB totali, 64 TB/s totali

Cosa mostrano i numeri?

Alcuni pattern emergono dal confronto tra modelli e hardware:

    • I modelli densi di piccole dimensioni (fino a ~30 B parametri) possono girare su una singola GPU consumer.
    • Modelli tra 30 B e 100 B richiedono GPU con almeno 48 GB di VRAM o sistemi con memoria unificata capace di ospitare i pesi più la cache.
    • Modelli molto grandi (oltre 200 B) necessitano di sistemi multi‑GPU o di memoria unificata di centinaia di gigabyte, come DGX Spark o Mac Studio M5 Ultra.
    • La larghezza di banda è il fattore limitante per il throughput di token; le GPU più recenti (H100, H200) offrono un salto considerevole rispetto alle soluzioni consumer.

In sintesi, la procedura di calcolo è semplice ma potente: conoscere il numero di parametri, scegliere la precisione, aggiungere il 20 % per la cache (o calcolarla esattamente per contesti lunghi) e confrontare il risultato con la capacità di memoria della GPU. Poi, verificare la larghezza di banda per stimare il massimo token/s e dimensionare in base al carico di lavoro reale, tenendo conto dei picchi.

Conclusioni pratiche

Per decidere se un LLM può essere eseguito in locale, seguite questi passaggi:

    • Identificate i parametri del modello e la precisione desiderata.
    • Calcolate la memoria necessaria per i pesi e aggiungete la cache KV (20 % è una buona stima di partenza).
    • Confrontate il risultato con la VRAM o la memoria unificata disponibile.
    • Stimate il throughput massimo usando la larghezza di banda di memoria.
    • Convertite le richieste mensili in token/s e dimensionate per il picco.

Seguendo questo approccio, è possibile evitare sorprese costose, scegliere l’hardware più adeguato e garantire che il modello risponda in modo fluido alle esigenze dell’organizzazione.