Cosa significa un basso carico sulla GPU durante l’esecuzione di un LLM con llama.cpp?

Spesso ciò comporta che molti strati restino sulla CPU, causando un calo netto della velocità di generazione dei token. È possibile aumentare lo spostamento degli strati sulla GPU mediante il parametro ngl, scegliere una quantizzazione di dimensioni inferiori o ridurre la lunghezza del contesto, in modo che una quota maggiore del modello risieda sulla GPU.

In che modo un contesto più lungo influisce sui token al secondo con 16 GB di VRAM?

Un contesto più lungo fa crescere la cache KV e l’utilizzo della VRAM, il che può ridurre i token al secondo o obbligare a un offloading parziale. Un contesto più breve, modelli più piccoli o quantizzazioni più aggressive aiutano a mantenere velocità elevate su una singola scheda da 16 GB.

Quale compromesso tra quantizzazione è importante per adattare modelli di grandi dimensioni su 16 GB?

I quantizzatori a bit più bassi occupano meno VRAM e possono aumentare il numero di token al secondo, ma possono compromettere la qualità. I quantizzatori di tipo 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 rapidi su una singola GPU da 16 GB?

I modelli MoE possono raggiungere un elevato numero di token al secondo poiché in ogni passo forward viene attivata solo una parte della rete; tuttavia, è comunque necessario disporre di VRAM sufficiente per gli esperti attivi, i pesi e la cache KV alla lunghezza di contesto scelta.

Che cosa si può provare se un contesto da 64K risulta molto più lento rispetto a uno da 32K sulla stessa GPU?

Configura il numero di livelli caricati sulla GPU tramite ngl, accetta un contesto più breve se adatto al tuo compito oppure passa a una quantizzazione più leggera affinché più livelli restino sul dispositivo e la pressione sulla KV cache si riduca.

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

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

Indice

Qui sto confrontando la velocità di diversi LLM eseguiti su una GPU con 16 GB di VRAM, per scegliere quello migliore per l’auto-hospitng.

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

GPU stilizzata con blocchi di VRAM e grafici in stile benchmark

In questo articolo documento i miei tentativi di ottenere la massima prestazione possibile in termini di velocità.

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

Model	Size	19K VRAM	19K GPU/CPU	19K T/s	32K VRAM	32K Load	32K T/s	64K VRAM	64K Load	64K: T/s
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
Mistral-Small-4-119B UD-IQ3_XXS	42.8	14.8	28/585	30.4	14.7	27/574	28.5	14.9	20/590	31.5
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 sono le dimensioni del contesto.

La voce load (carico) nella tabella sopra indica il GPU Load (carico della GPU). Se in questa colonna vedi un valore basso, significa che il modello funziona prevalentemente sulla CPU e non può raggiungere una velocità decente su questo hardware. Questo schema corrisponde a ciò che si osserva quando una quota insufficiente del modello si trova sulla GPU o quando il contesto sposta il carico di lavoro sulla CPU host.

Informazioni su llama.cpp, le prestazioni degli LLM, OpenCode e altre confrontazioni

Se desideri conoscere i percorsi di installazione, gli esempi di llama-cli e llama-server e i parametri (flag) importanti per la VRAM e i token al secondo (dimensione del contesto, batching, -ngl), parti da Guida Rapida a llama.cpp con CLI e Server.

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

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

[I Migliori LLM per OpenCode - Testati Localmente](https://www.glukhov.org/it/ai-devtools/opencode/llms-comparison/ “Confronto pratico di LLM in OpenCode - modelli locali Ollama e llama.cpp vs cloud. Attività di coding, statistiche di accuratezza della mappa di migrazione e analisi onesta dei fallimenti.”}). Puoi saperne di più su Opencode in [Guida Rapida a OpenCode: Installazione, Configurazione e Utilizzo dell’Agente di Coding AI per Terminale](https://www.glukhov.org/it/ai-devtools/opencode/ “Una guida pratica a OpenCode per sviluppatori: installazione e verifica, connessione di modelli/provider, esecuzione di workflow CLI, utilizzo del server + JS SDK e una breve scheda rapida.”})
Confronto della Qualità di Traduzione delle Pagine Hugo - LLM su Ollama

Ho eseguito un test simile per gli LLM su Ollama: I Migliori LLM per Ollama su GPU con 16GB di VRAM.

Se esegui Qwen 3.6 27B o 35B tramite llama.cpp e vuoi spingere ulteriormente la velocità di generazione, consulta Qwen 3.6 MTP vs Decodifica Standard su GPU 16GB — la decodifica speculativa MTP aggiunge fino al 67% di throughput di generazione per il modello denso 27B, con tabelle che mostrano il costo in VRAM e il compromesso sulla finestra di contesto a ogni livello di --spec-draft-n-max.

Perché la lunghezza del contesto cambia i token al secondo

Quando si passa da 19K a 32K o 64K token, la cache KV cresce e la pressione sulla VRAM aumenta. Alcune righe mostrano un grande calo dei token al secondo a 64K, mentre altre restano stabili: questo è il segnale per riconsiderare i quanti, i limiti del contesto o lo offload dei layer, piuttosto che assumere che il modello sia “lento” in generale. Per i calcoli di budget dietro questi numeri — la formula esatta per i byte KV per token, le tabelle dei tipi di cache a 32K/64K/128K e come calcolare il proprio margine di sicurezza — consulta KV Cache su GPU da 16 GB: Come Far Adattare Realmente il Contesto Lungo.

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

GPU/CPU è un carico, misurato da nvitop.

llama.cpp, quando configura automaticamente il caricamento dei layer sulla GPU, cerca di mantenere libero 1GB. Specifichiamo manualmente questo parametro tramite il parametro da riga di comando -ngl, ma qui non lo sto ottimizzando finemente (finetuning), 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 finemente il numero di layer scaricati (unloaded).

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 numero di layer scaricati specificato
VRAM utilizzata inizialmente, prima dell’avvio di llama-cli: 300MB

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

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

Esecuzioni Ottimizzate (Finetuned)

Per alcuni modelli e quanti interessanti ho provato a trovare parametri specifici da riga di comando per llama-cpp per sfruttare al meglio la VRAM. Ecco cosa sono riuscito a ottenere:

Model	Context	Layers on GPU	CPU/CPU load	Speed
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 configurazioni con 16 GB di VRAM

Il mio attuale favorito Qwen3.5-27B-UD-IQ3_XXS si comporta bene sul suo punto ottimale (sweetspot) di contesto da 50k (sto ottenendo 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 contesti da 100k token, e si adatta nella vram, quindi nessun calo di prestazioni
Non userò gemma-4-31B su 16GB di VRAM, ma gemma-4-26B potrebbe andare bene più o meno, da testare.
Devo testare quanto funzionano bene Nemotron cascade 2 e GLM-4.7 Flash REAP 23B. Saranno migliori del Qwen3.5-35B q3? Lo dubito, ma comunque, potrei testare per confermare il sospetto.
Per capire perché la fascia 25–34B è il predefinito del 2026 una volta che si dispone di 24 GB, e perché un Q4 Qwen3.8-27B non appartiene davvero a questa scheda da 16 GB, consulta La Frontiera Efficiente dei Modelli Aperti nel 2026.