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

Spesso ciò significa che molti strati rimangono sulla CPU, causando un calo netto della velocità dei token. Puoi provare ad aumentare il caricamento degli strati sulla GPU tramite ngl, scegliere una quantizzazione più piccola o accorciare il contesto in modo che una parte maggiore del modello venga caricata sulla GPU.

In che modo una finestra di contesto più lunga influisce sul numero di 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 offload parziale. Contesti più brevi, modelli più piccoli o una quantizzazione più aggressiva aiutano a mantenere elevate le prestazioni su una singola scheda da 16 GB.

Quali compromessi di quantizzazione sono rilevanti per far entrare modelli di grandi dimensioni in 16 GB?

Le quantizzazioni a bit più bassi richiedono meno VRAM e possono aumentare i token al secondo, ma potrebbero compromettere la qualità. Le quantizzazioni di tipo IQ3 e IQ4 rappresentano compromessi comuni per llama.cpp su una GPU da 16 GB quando è necessario un contesto lungo o checkpoint di dimensioni maggiori.

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 attivata a ogni step in avanti, tuttavia è comunque necessaria una quantità sufficiente di VRAM per gli esperti attivi, i pesi e la cache KV alla lunghezza del contesto desiderata.

Cosa puoi provare se un contesto di 64K è significativamente 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 alleviare la pressione sulla cache KV.

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

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

Indice

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

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

Stylized GPU with VRAM blocks and benchmark-style charts

In questo articolo registro i miei tentativi di spremere la massima velocità possibile.

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

Modello	Dimensione	VRAM 19K	GPU/CPU 19K	T/s 19K	VRAM 32K	Carico 32K	T/s 32K	VRAM 64K	Carico 64K	T/s 64K
Qwen3.6-35B-A3B-UD-IQ3_XXS	13.2	13.8GB	96%/100%	147.5	14.0GB	96%/101%	149.1	14.7GB	96%/101%	145.8
Qwen3.6-35B-A3B-UD-IQ4_XS	17.7	14.3GB	62%/266%	95.0	14.9GB	58%/279%	92.3	14.9GB	57%/293%	86.4
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-IQ3_XXS-bartowsky	11.3	12.8	98/100	44.9	13.5	98/100	44.9	14.5	45/415	23.6
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-27B-IQ4_XS.gguf	15.0	14.6	49/406	20.5	14.7	37/465	17.4	14.7	23/533	13.3
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
Qwen3.5-122B-A10B-UD-IQ3_S	46.5	14.7	25/516	19.4	14.7	24/516	19.5	14.7	24/516	19.6
Qwen3-Coder-Next-UD-IQ4_XS	38.4	14.6	32/460	41.1	14.7	29/440	41.3	14.8	32/460	38.3
Nemotron Super 120b IQ3_XXS	56.2	15.0	26/517	17.5	14.6	26/531	17.4	14.6	26/535	17.6
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 load (carico) sopra indicato è il Carico GPU. Se vedi un numero basso in questa colonna, significa che il modello si sta eseguendo prevalentemente sulla CPU e non può ottenere una velocità decente su questo hardware. Questo modello si allinea a ciò che le persone osservano quando una parte troppo piccola del modello entra nella GPU o quando il contesto sposta 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 i flag rilevanti per la VRAM e i token al secondo (dimensione del contesto, batching, -ngl), inizia con Guida rapida a 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 attraverso hardware e runtime diversi), consulta Prestazioni LLM nel 2026: Benchmark, Colli di Bottiglia e Ottimizzazione.

La qualità delle risposte è analizzata in altri articoli, ad esempio:

Migliori LLM per OpenCode - Testati Localmente. Puoi leggere di più su Opencode in Guida rapida a OpenCode: Installazione, Configurazione e Uso dell’Agente AI per il Coding a Terminale
Confronto della qualità della traduzione di pagine Hugo - LLM su Ollama

Ho eseguito test simili per gli LLM su Ollama: Migliori LLM per Ollama su GPU con 16 GB 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 forte calo dei token al secondo a 64K mentre altre restano stabili, segnale che bisogna riesaminare le quantizzazioni, i limiti del contesto o lo scaricamento dei layer, piuttosto che assumere che il modello sia “lento” in generale.

I modelli e le quantizzazioni che ho scelto di testare sono stati scelti per eseguirli personalmente e vedere se offrono un buon guadagno in termini di rapporto costi/benefici su questa apparecchiatura o meno. Quindi qui non ci sono quantizzazioni q8 con contesto di 200k :) …

GPU/CPU è un carico, misurato da nvitop.

Quando llama.cpp si configura automaticamente per scaricare i layer sulla GPU, cerca di mantenere 1 GB liberi. Specifichiamo manualmente questo parametro tramite il parametro da riga di comando -ngl, ma non lo sto ottimizzando qui, ho solo bisogno di capire che se c’è un calo significativo delle prestazioni quando si aumenta la dimensione della finestra di contesto da 32k a 64k - possiamo provare ad aumentare la velocità a 64k ottimizzando il numero di layer scaricati.

Hardware di test e configurazione di llama.cpp

Ho testato la velocità degli 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 layer scaricato specificato
VRAM iniziale utilizzata, prima di avviare llama-cli: 300MB

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

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

Esecuzioni Ottimizzate

Per alcuni modelli e quantizzazioni interessanti, ho provato a trovare parametri speciali da riga di comando per llama-cpp per sfruttare meglio la VRAM. Ecco quello che sono riuscito a ottenere:

Modello	Contesto	Layer su GPU	Carico CPU/CPU	Velocità
Qwen3.5-27B-IQ4_XS.gguf	18k	65	98%/100%	38.0
Qwen3.5-27B-IQ4_XS.gguf	64k	53	33%/488%	15.7

Conclusioni per build con 16 GB VRAM

Il mio preferito attuale, Qwen3.5-27B-UD-IQ3_XXS, si comporta bene nel suo punto dolce (sweetspot) a 50k di contesto (ottengo circa 36t/s)
Qwen3.5-122B-A10B-UD-IQ3_XXS supera in termini di prestazioni il 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 nella VRAM, quindi nessun calo delle prestazioni.
Non userò gemma-4-31B su 16GB VRAM, ma gemma-4-26B potrebbe essere mediamente decente…, da testare.
Devo testare bene come funzionano Nemotron cascade 2 e GLM-4.7 Flash REAP 23B. Saranno migliori di Qwen3.5-35B q3? Ne dubito, ma comunque proverò a testarlo per confermare il sospetto.