L'ottimizzazione degli LLM on-premise: il caso Qwen3.6 su RTX 5080 16GB

Nel panorama in rapida evoluzione dell'intelligenza artificiale, la capacità di eseguire Large Language Models (LLM) in locale, su infrastrutture on-premise, è diventata una priorità per molte aziende. Questa scelta è spesso dettata da esigenze di sovranità dei dati, compliance normativa e controllo sui costi operativi (TCO). Tuttavia, l'ottimizzazione delle prestazioni su hardware dedicato, in particolare per carichi di lavoro intensivi come gli agenti di coding che richiedono finestre di contesto ampie, presenta sfide significative.

Un recente benchmark ha esaminato le prestazioni di diverse configurazioni del modello Qwen3.6 su una GPU NVIDIA RTX 5080 da 16GB, utilizzando il popolare framework llama.cpp. L'obiettivo era identificare la configurazione più efficiente per scenari che prevedono contesti estesi, come quelli tipici degli agenti di coding. I risultati hanno rivelato un framework interessante, in particolare per quanto riguarda l'efficacia della funzionalità Multi-Token Prediction (MTP).

Metodologia e configurazioni sotto esame

La piattaforma di test comprendeva una GPU RTX 5080 con 16GB di VRAM, affiancata da una CPU Ryzen 9 9950X e 128GB di RAM, il tutto gestito da llama.cpp nella versione b9204. Sono stati valutati tre modelli Qwen3.6, ciascuno con diverse quantizzazioni e dimensioni:

  • Qwen3.6-27B MTP-UD-IQ3_XXS: Un modello da 27 miliardi di parametri, con una dimensione di circa 12.45 GB, che si adatta completamente alla GPU da 16GB.
  • Qwen3.6-35B-A3B MTP-UD-Q4_K_XL: Un modello MoE (Mixture of Experts) da 35 miliardi di parametri, con una dimensione di circa 22 GB, che richiede un offload parziale sulla CPU.
  • Qwen3.6-35B-A3B MTP-Q8_0: Un'altra variante da 35 miliardi di parametri, con una dimensione di circa 36 GB, che necessita di un offload più consistente.

La funzionalità Multi-Token Prediction (MTP), recentemente integrata in llama.cpp, è stata testata per valutarne l'impatto sulla velocità di generazione e di elaborazione del prompt. MTP mira a migliorare la velocità di inference speculando su più token contemporaneamente, ma la sua efficacia può variare a seconda dell'hardware e della configurazione del modello, specialmente in presenza di vincoli di VRAM.

Analisi delle prestazioni: velocità, contesto e qualità

I test hanno evidenziato che per il modello Qwen3.6-35B Q4_K_XL, la configurazione ottimale per un contesto di 128k token, senza MTP e con il flag --fit-target 1536, ha raggiunto una velocità di generazione di 56 token/secondo e una velocità di elaborazione del prompt di 1.584 token/secondo. Questo significa che un prompt di 128k token viene elaborato in circa 81 secondi.

Il dato più sorprendente riguarda proprio l'MTP: per il modello 35B MoE su 16GB di VRAM, l'MTP si è rivelato più lento del 23% in contesti brevi. Questo è dovuto al fatto che l'MTP richiede una riserva di VRAM (circa 1.5 GB per il buffer di calcolo), che spinge ulteriori layer del modello dalla GPU alla CPU, creando un collo di bottiglia. In contesti estesi, come 128k token, la velocità di generazione con e senza MTP converge a 56 token/secondo, poiché la cache KV (Key-Value) satura la VRAM indipendentemente dall'MTP, rendendo il suo overhead di calcolo inefficace.

Al contrario, per il modello 27B IQ3, che si adatta completamente alla GPU (12.45 GB), l'MTP ha fornito un beneficio, aumentando la velocità da circa 56 a 73 token/secondo. Questo suggerisce una regola generale: l'MTP è utile quando il modello risiede interamente sulla GPU, ma può essere controproducente quando il suo buffer di calcolo costringe l'offload di layer aggiuntivi alla CPU.

Per quanto riguarda la gestione del contesto, il modello 35B MoE si è distinto, gestendo facilmente oltre 131k token. Questo è attribuibile alla sua architettura ibrida (Gated DeltaNet + Attention) che richiede una cache KV solo per un numero limitato di layer di attenzione, mentre i layer SSM (State Space Model) utilizzano uno stato ricorrente minimo. Il modello 27B, invece, ha raggiunto un massimo di 56k token (o 110k con quantization q4_0 per la cache KV).

Sotto il profilo della qualità, il 27B IQ3 ha ottenuto un punteggio perfetto nel benchmark CodeNeedle (richiamo posizionale), mentre i modelli 35B erano leggermente inferiori. Nel benchmark GSM8K (matematica), il 35B Q4_K_XL ha mostrato un'accuratezza del 91% ed è stato il 37% più veloce nella valutazione rispetto al 27B.

Implicazioni per i CTO e le prospettive future

Per i CTO, i responsabili DevOps e gli architetti di infrastruttura che valutano il deployment di LLM on-premise, questi risultati offrono indicazioni preziose. La configurazione raccomandata per agenti di coding che richiedono ampie finestre di contesto su una RTX 5080 16GB è il modello Qwen3.6-35B Q4_K_XL senza MTP, utilizzando --fit on e --fit-target 1536. Questa configurazione garantisce 56 token/secondo a 128k di contesto e una capacità massima di 131k token, bilanciando velocità e capacità di gestione del contesto.

La scelta tra modelli più piccoli che si adattano completamente alla GPU (beneficiando potenzialmente dell'MTP) e modelli più grandi che richiedono offload parziale (dove l'MTP può essere svantaggioso) è un trade-off critico. La quantità di VRAM disponibile è il fattore determinante. Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per valutare questi trade-off in termini di performance, TCO e sovranità dei dati.

Guardando al futuro, l'integrazione nativa di MTP in framework come vLLM (versioni >= 0.19.0) con PagedAttention potrebbe cambiare lo scenario. La gestione dinamica della VRAM da parte di PagedAttention potrebbe eliminare l'overhead del buffer di calcolo fisso, rendendo l'MTP più efficace anche per i modelli che richiedono offload parziale. Questo sviluppo potrebbe sbloccare nuove opportunità per ottimizzare ulteriormente le prestazioni degli LLM su hardware locale.