Cosa significa un basso carico della GPU quando si esegue un LLM con llama.cpp?

Spesso ciò significa che molti livelli rimangono sulla CPU, causando un calo netto della velocità di generazione dei token. Puoi provare ad aumentare l’offloading dei livelli sulla GPU con ngl, scegliere una quantizzazione più piccola o accorciare il contesto in modo che una parte maggiore del modello possa risiedere sulla GPU.

In che modo una finestra di contesto più lunga influisce sui token al secondo su 16 GB di VRAM?

Un contesto più lungo aumenta la cache KV e l’utilizzo della VRAM, riducendo i token al secondo o richiedendo un offloading parziale. Contesti più brevi, modelli più piccoli o quantizzazioni più aggressive aiutano a mantenere elevate le prestazioni su una singola scheda da 16 GB.

Quali compromessi nella quantizzazione sono rilevanti per l’adattamento di grandi modelli in 16 GB?

I quanti a bit più bassi richiedono meno VRAM e possono aumentare i token per secondo, ma potrebbero compromettere la qualità. I quanti di stile IQ3 e IQ4 sono compromessi comuni per llama.cpp su una singola GPU da 16 GB quando è necessario un contesto lungo o checkpoint più grandi.

I modelli mixture-of-experts possono essere veloci su una singola GPU da 16 GB?

I modelli MoE possono raggiungere un elevato numero di token al secondo poiché solo una parte della rete viene eseguita in ogni passo in avanti, ma è comunque necessaria VRAM sufficiente per gli esperti attivi, i pesi e la cache KV alla lunghezza del contesto scelta.

Cosa si può provare se un contesto di 64K risulta molto più lento rispetto a 32K sulla stessa GPU?

Regola il numero di livelli caricati sulla GPU con ngl, accetta un contesto più breve se adatto al tuo compito, oppure passa a una quantizzazione più leggera per mantenere più livelli sul dispositivo e ridurre la pressione sulla cache KV.

Benchmark LLM con 16 GB di VRAM tramite llama.cpp (velocità e contesto)

Velocità dei token di llama.cpp su 16 GB di VRAM (tabelle).

Indice

Ecco il confronto sulla velocità di diversi LLM in esecuzione su una GPU con 16 GB di VRAM, con l’obiettivo di scegliere il migliore per l’auto-ospitamento.

Ho eseguito questi LLM su llama.cpp con finestre di contesto da 19K, 32K e 64K token.

GPU stilizzata con blocchi VRAM e grafici da benchmark

In questo articolo registro i miei tentativi di estrarre il massimo delle prestazioni, intese come velocità, possibile.

Tabella di confronto velocità LLM (token al secondo e VRAM)

Modello	Dimensione	19K VRAM	19K GPU/CPU	19K T/s	32K VRAM	32K Carico	32K T/s	64K VRAM	64K Carico	64K: T/s
Qwen3.5-35B-A3B-UD-IQ3_S	13.6	14.3GB	93%/100%	136.4	14.6GB	93%/100%	138.5	14.9GB	88%/115%	136.8
Qwen3.5-27B-UD-IQ3_XXS	11.5	12.9	98/100	45.3	13.7	98/100	45.1	14.7	45/410	22.7
Qwen3.5-122B-A10B-UD-IQ3_XXS	44.7	14.7	30/470	22.3	14.7	30/480	21.8	14.7	28/490	21.5
nvidia Nemotron-Cascade-2-30B IQ4_XS	18.2	14.6	60/305	115.8	14.7	57/311	113.6	14.7	55/324	103.4
gemma-4-26B-A4B-it-UD-IQ4_XS	13.4	14.7	95/100	121.7	14.9	95/115	114.9	14.9	75/190	96.1
gemma-4-31B-it-UD-IQ3_XXS	11.8	14.8	68/287	29.2	14.8	41/480	18.4	14.8	18/634	8.1
GLM-4.7-Flash-IQ4_XS	16.3	15.0	66/240	91.8	14.9	62/262	86.1	14.9	53/313	72.5
GLM-4.7-Flash-REAP-23B IQ4_XS	12.6	13.7	92/100	122.0	14.4	95/102	123.2	14.9	71/196	97.1

19K, 32K e 64K rappresentano le dimensioni del contesto.

Il carico sopra si riferisce al Carico GPU. Se vedi un numero basso in questa colonna, significa che il modello si sta eseguendo principalmente sulla CPU e non può ottenere una velocità decente su questo hardware. Questo pattern corrisponde a ciò che le persone osservano quando troppo poco del modello entra nella GPU o quando il contesto spinge il lavoro verso l’host.

Informazioni su llama.cpp, prestazioni LLM, OpenCode e altri confronti

Se desideri percorsi di installazione, esempi di llama-cli e llama-server, e le flag che contano per la VRAM e i token al secondo (dimensione del contesto, batching, -ngl), inizia con Avvio rapido di llama.cpp con CLI e Server.

Per una visione più ampia delle prestazioni (throughput rispetto alla latenza, limiti VRAM, richieste parallele e come i benchmark si integrano tra hardware e runtime), vedi Prestazioni LLM nel 2026: Benchmark, Colli di Bottiglia e Ottimizzazione.

La qualità della risposta è analizzata in altri articoli, ad esempio:

Migliori LLM per OpenCode - Testati Localmente. Puoi leggere di più su Opencode in Avvio rapido OpenCode: Installazione, Configurazione e Utilizzo dell’Agente AI per Coding a Terminale
Confronto qualità traduzione pagina Hugo - LLM su Ollama

Ho eseguito test simili per LLM su Ollama: Migliori LLM per Ollama su GPU con 16GB VRAM.

Perché la lunghezza del contesto cambia i token al secondo

Passando da 19K a 32K o 64K token, la cache KV cresce e la pressione sulla VRAM aumenta. Alcune righe mostrano un grosso calo dei token al secondo a 64K, mentre altre restano stabili; questo è il segnale per rivedere le quantizzazioni, i limiti del contesto o l’offloading degli strati, piuttosto che assumere che il modello sia “lento” in generale.

I modelli e le quantizzazioni che ho scelto di testare sono stati selezionati per essere eseguiti da me e verificare se offrono un buon guadagno in termini di rapporto costo/beneficio su questa attrezzatura o meno. Quindi niente quantizzazioni q8 qui con contesto 200k :) …

GPU/CPU è il carico, misurato da nvitop.

llama.cpp, quando configura automaticamente gli strati da scaricare sulla GPU, cerca di mantenere 1GB liberi. Noi specifichiamo manualmente questo parametro tramite il parametro da riga di comando -ngl, ma non lo sto ottimizzando qui, devo solo capire che se c’è una significativa perdita di prestazioni aumentando la dimensione della finestra di contesto da 32k a 64k - possiamo provare ad aumentare la velocità a 64k ottimizzando il numero di strati scaricati.

Hardware di test e configurazione di llama.cpp

Ho testato la velocità LLM su un PC con questa configurazione:

CPU i-14700
RAM 64GB 6000Hz (2x32GB)
GPU RTX-4080
Ubuntu con driver NVidia
llama.cpp/llama-cli, nessun strato scaricato specificato
VRAM iniziale usata, prima di avviare llama-cli: 300MB

Esecuzioni extra a contesto 128K (Qwen3.5 27B e 122B)

Modello	128K Carico	128K: T/s
Qwen3.5-27B-UD-IQ3_XXS	16/625	9.6
Qwen3.5-122B-A10B-UD-IQ3_XXS	27/496	19.2

Considerazioni per build con 16 GB VRAM

Il mio attuale preferito Qwen3.5-27B-UD-IQ3_XXS si comporta bene sul suo punto dolce a contesto 50k (sto ottenendo circa 36t/s)
Qwen3.5-122B-A10B-UD-IQ3_XXS sta superando in termini di prestazioni Qwen3.5 27B sui contesti superiori a 64K.
Posso spingere Qwen3.5-35B-A3B-UD-IQ3_S a gestire un contesto di 100k token, e entra in VRAM, quindi nessuna perdita di prestazioni.
Non userò gemma-4-31B su 16GB VRAM, ma gemma-4-26B potrebbe essere… mediamente buono, da testare.
Devo testare quanto bene funzionano Nemotron cascade 2 e GLM-4.7 Flash REAP 23B. Saranno migliori di Qwen3.5-35B q3? Ne dubito, ma comunque, potrei testare per confermare il sospetto.