Entra in qualsiasi thread sugli LLM locali e la lite riguarda le GPU. Benchmark di VRAM, schede da 24 GB, CUDA contro ROCm, se la 3060 è ancora la scheda del popolo. Nel frattempo il numero che decide davvero se il tuo modello gira sta nell’altro slot, senza benchmark e senza marketing: quanta RAM ha la macchina.
La VRAM vende il sogno. La RAM decide se il modello parte davvero — e quanta sopravvive di contesto quando parte.
L’ho verificato sulla macchina che ho davanti mentre scrivevo questo post: un desktop Ryzen con 32 GB di RAM e una GeForce RTX 3060 con 12 GB di VRAM. Ho scaricato llama3.1:8b — la pagina dice 4,9 GB. Guarda cosa ha riservato davvero:

Tutto l’argomento sta in quello schermo. Un «modello da 4,9 GB» ha riservato 7,0 GB prima di rispondere a un solo prompt — una tassa di contesto del 43% — e si è tenuto 7.963 dei 12.288 MiB di VRAM. I pesi non sono mai stati il budget. Il contesto lo era.
Da dove vengono i gigabyte in più
Le note sulla memoria di llama.cpp spiegano l’aritmetica che le pagine di download omettono: memoria totale = pesi del modello + KV cache + buffer di calcolo. Solo il primo termine è costante. La KV cache cresce linearmente con la lunghezza del contesto, il buffer di calcolo con il batch. Ollama incarta llama.cpp, quindi vale la stessa legge — ecco perché ollama ps ha riportato 7,0 GB per un tag da 4,9 GB con finestra a 32.000 token, tutto residente su GPU.
Un modello quantizzato non è un compromesso. È l’ammissione che la memoria è sempre stata il vero budget.
È anche il motivo per cui la scala di quantizzazione GGUF esiste. Q4 non è una religione; è ciò che fa atterrare l’aritmetica della memoria nell’hardware che la gente possiede. Ed è per questo che due setup «identici» da 8B non si assomigliano per niente: stesso modello, lunghezza di contesto diversa, macchine diverse.
La tabella che nessuno compila prima di comprare
Tre classi di modello, entrambi i tipi di memoria, una scheda da 12 GB e 32 GB di RAM — la configurazione che migliaia di sviluppatori hanno davvero:
| Classe di modello (Q4) | Download | Caricato + ctx 32k | Su 12 GB di VRAM | Su 32 GB di RAM |
|---|---|---|---|---|
7–8B (llama3.1:8b) | 4,9 GB | 7,0 GB (misurato) | 100% GPU, ~8 GiB usati | appena notato |
13–14B (qwen2.5:14b) | 9,0 GB | ~12 GB | comincia l’offload | bene |
27–32B (gemma3:27b) | 17 GB | ~20 GB e più | la CPU tira il peso | l’unico motivo per cui gira |
Rileggi le ultime due righe. Con la sola VRAM, un 14B con contesto reale è già un lavoro di offload diviso, e un 27B è impossibile. Con 32 GB di RAM, entrambi sono solo lenti. Questa differenza — tra impossibile e lento — è tutta la differenza pratica tra VRAM e RAM. Se ci sta nella VRAM, è veloce. Se ci sta nella RAM, funziona. Se non ci sta in nessuna, stai facendo swap su NVMe e il tempo perde significato.
L’offload viaggia su PCIe, e la FAQ di Ollama è diretta sul costo: i layer che non entrano nella GPU girano sulla CPU, e il throughput crolla quando la quota GPU si restringe. Nessuno sceglie quel trade-off consapevolmente. Arriva in silenzio, layer dopo layer, e il sintomo è solo «i modelli locali sono sopravvalutati».
Il registro onesto
Cosa si è rotto o ha sorpreso mentre scrivevo, in ordine:
- Il numero del 43% in sé. Mi aspettavo che l’8B occupasse «circa la sua dimensione da file». Ha riservato 7,0 GB contro 4,9 GB scaricati. Se ha sorpreso me, sorprende chiunque legga schede tecniche invece di
ps. - La sessione di screenshot. La prima cattura ha preso la finestra sbagliata. La seconda ha funzionato, ed è quella sopra. Le prove sono un flusso di lavoro, non un’atmosfera — e un ciclo pull → cattura →
ollama rmtiene il disco onesto. - Cosa non si è rotto: la GPU non ha mai sconfinato. 8B con contesto a 32k su 12 GB è davvero comodo. La scheda sta bene. Male calibrato è il discorso attorno alla scheda.
Niente di questo dice che le GPU non contano — la riga 100% GPU nella cattura è il motivo per cui generare è sembrato istantaneo. Significa che la GPU è la seconda domanda. La scelta tra Ollama e llama.cpp viene dopo aver capito cosa ci sta, non prima.
La regola che vale la pena tenere
RAM necessaria = file del modello + KV cache per il tuo contesto reale + 4 GB per continuare a essere un computer. Per 7–8B in Q4, 16 GB sono comodi. Per 14B–32B, 32 GB smettono di essere un lusso e diventano il punto. Compra VRAM per la velocità che vuoi al contesto che usi; compra RAM per tutto ciò che caricherai prima o poi.
Guarda
ollama psuna volta e la religione delle schede tecniche si spegne in silenzio.
Quindi, due domande. Quando imposti la prossima macchina, compri VRAM per i benchmark che posterai — o RAM per i modelli che farai girare davvero? E, a essere onesti: quanti dei modelli scaricati alle 2 di notte hai cancellato prima di colazione? Io l’ho fatto stanotte, in mezzo al post. Dimmi nei commenti che non sono l’unico — e da che parte della linea RAM/VRAM sta la tua macchina.
FAQ
Quanta RAM serve per far girare un LLM locale?
La dimensione del file del modello, più il contesto, più il tuo desktop. 16 GB bastano con margine per modelli 7–8B in Q4; 32 GB sono ciò che trasforma un 14–32B da demo a strumento quotidiano.
VRAM o RAM: cosa conta di più per gli LLM locali?
La VRAM decide la velocità quando tutto ci entra. La RAM decide se il modello parte e quanto contesto sopravvive. L'offload via PCIe in mezzo è la zona lenta che nessuno ama.
Perché un modello caricato usa più memoria della sua dimensione di download?
La KV cache e i buffer di calcolo crescono con la lunghezza del contesto. llama.cpp documenta l'aritmetica: pesi + KV cache + buffer di calcolo, e solo il primo numero sta sulla pagina di download.
— mrsaynothing
— mrsaynothing
Opinions load-tested before shipping. Mostly.
Discuti questo post su dev.to dev.to ↗
Get the next argument by email
One email per post. Agree or tear it apart.
che cos'è?SSH Permission denied (publickey): la vera soluzione
Ti piacciono gli articoli? È così che costruisco per lavoro. assumimi