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

Spesso ciò comporta che molti layer restino sulla CPU, causando un calo drastico della velocità dei token. Puoi provare ad aumentare il layer offload sulla GPU tramite ngl, a scegliere una quantizzazione più piccola o ad accorciare il contesto, così da far entrare più del modello sulla GPU.

Come influisce una finestra di contesto più lunga sui token al secondo con 16 GB di VRAM?

Un contesto più lungo aumenta la KV cache e l’uso della VRAM, riducendo potenzialmente i token al secondo o costringendo a un offloading parziale. Un contesto più corto, modelli di dimensioni ridotte o quantizzazioni più aggressive aiutano a mantenere velocità elevate su una singola scheda da 16 GB.

Quali compromessi di quantizzazione sono rilevanti per far funzionare modelli di grandi dimensioni con 16 GB?

Le quantizzazioni con bit rate più basso occupano meno VRAM e possono aumentare il numero di token al secondo, ma potrebbero compromettere la qualità. Le quantizzazioni di tipo IQ3 e IQ4 sono compromessi comuni per llama.cpp su una GPU da 16 GB quando sono necessari contesti lunghi o checkpoint più grandi.

Le miscele di esperti possono essere veloci su una singola GPU da 16 GB?

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

Cosa si può provare se un contesto di 64K è molto più lento di uno da 32K sulla stessa GPU?

Regolate il numero di livelli caricati sulla GPU tramite ngl, accettate un contesto più breve se si adatta al vostro compito o passate a una quantizzazione più leggera, così che più livelli restino sul dispositivo e la pressione sulla KV cache si attenui.

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

Velocità di tokenizzazione 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, scegliendo il migliore per l’auto-ospitato (self-hosting).

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

Grafica stilizzata di una GPU con blocchi VRAM e grafici in stile benchmark

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

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.6-35B-A3B-UD-IQ3_XXS	13.2	13.8 GB	96%/100%	147,5	14.0 GB	96%/101%	149,1	14.7 GB	96%/101%	145,8
Qwen3.6-35B-A3B-UD-IQ4_XS	17.7	14.3 GB	62%/266%	95,0	14.9 GB	58%/279%	92,3	14.9 GB	57%/293%	86,4
Qwen3.5-35B-A3B-UD-IQ3_S	13.6	14.3 GB	93%/100%	136,4	14.6 GB	93%/100%	138,5	14.9 GB	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.

Il carico (load) sopra si riferisce al Carico GPU (GPU Load). Se si vede un numero basso in questa colonna, significa che il modello viene eseguito principalmente sulla CPU e non può raggiungere una velocità dignitosa su questo hardware. Questo schema corrisponde a ciò che le persone riscontrano quando troppo poca parte del modello si adatta alla GPU o quando il contesto spinge il lavoro di nuovo sull’host.

Informazioni su llama.cpp, prestazioni LLM, OpenCode e altre comparazioni

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

Per una visione più ampia delle prestazioni (throughput rispetto alla latenza, limiti della VRAM, richieste parallele e come i benchmark si integrano tra hardware e runtime diversi), consulta 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 in Locale. Puoi leggere di più su OpenCode in Guida Rapida OpenCode: Installazione, Configurazione e Uso dell’Agente AI di Coding per Terminale
Confronto della qualità della traduzione delle pagine Hugo - LLM su Ollama

Ho eseguito un test simile per LLM su Ollama: Migliori LLM per Ollama su GPU con 16GB 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 VRAM e il compromesso della finestra di contesto a ogni livello --spec-draft-n-max.

Perché la lunghezza del contesto cambia i token al secondo

Mentre ci si sposta da 19K a 32K o 64K token, la cache KV cresce e la pressione sulla VRAM aumenta. Alcuni righe mostrano un grande calo dei token al secondo a 64K, mentre altre restano invariate; questo è il segnale per riconsiderare le quantizzazioni, i limiti del contesto o lo scarico dei layer (layer offload) piuttosto che dare per scontato che il modello sia “lento” in generale. Per i calcoli alla base di 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 Cache KV su GPU da 16 GB: Far Adattare il Contesto Lungo.

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

GPU/CPU è un carico, misurato da nvitop.

llama.cpp, quando configura automaticamente lo scaricamento dei 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 finemente 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 finemente il numero di layer scaricati (offloaded).

Hardware di test e configurazione llama.cpp

Ho testato la velocità dei 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 di avviare llama-cli: 300MB

Esecuzioni extra con 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

Esecuzioni Ottimizzate (Finetuned)

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

Modello	Contesto	Layer sulla GPU	Carico CPU/GPU	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

Considerazioni per configurazioni con 16 GB di VRAM

Il mio Qwen3.5-27B-UD-IQ3_XXS preferito al momento sembra andare bene nel suo punto di forza con contesto da 50k (sto ottenendo circa 36 token/sec)
Qwen3.5-122B-A10B-UD-IQ3_XXS supera in termini di prestazioni Qwen3.5 27B sui contesti superiori a 64K.
Posso spingere Qwen3.5-35B-A3B-UD-IQ3_S a gestire contesti di 100k token, e si adatta alla VRAM, quindi nessun calo di prestazioni
Non userò gemma-4-31B su 16GB di VRAM, ma gemma-4-26B potrebbe andare abbastanza bene…, bisogna testare.
Bisogna testare quanto bene funzionano Nemotron cascade 2 e GLM-4.7 Flash REAP 23B. Saranno migliori rispetto a Qwen3.5-35B q3? Lo dubito, ma comunque, potrei testare per confermare il sospetto.