Far girare un Large Language Model MoE da 35 miliardi di parametri su una GPU consumer non è più un esperimento da laboratorio. Con un’unica RTX 3090, un utente ha messo alla prova Qwen3.6-35B-A3B APEX, ottenendo oltre 130 token al secondo con 128.000 token di contesto, il tutto senza cedere alla tentazione del cloud. Il report, pubblicato su Reddit, esplora due fork di llama.cpp e un promettente codec per la cache KV chiamato turbo8.

La configurazione e i fork a confronto

Il protagonista hardware è una RTX 3090 con i suoi 24 GB di VRAM. Per ospitare il modello APEX (I-Compact o I-Quality) servono quantizzazioni spinte: I-Compact occupa circa 17 GB, I-Quality circa 21,3 GB. Il sistema operativo e il runtime di inference si appoggiano a due fork di llama.cpp: ik_llama, noto per l’ottimizzazione dei kernel CUDA, e spiritbuun, che introduce il codec turbo8 per la compressione della cache chiave-valore.

I numeri parlano chiaro: con I-Compact, ik_llama tocca ~146 t/s in decoding, sia su testo narrativo che su codice. La variante spiritbuun con lo stesso modello si attesta intorno a 142–141 t/s. Passando a I-Quality, entrambi i motori si allineano a ~137 t/s. La differenza è minima, ma il dato interessante è che spiritbuun riesce a garantire le stesse prestazioni di ik_llama anche con il modello più pesante.

Il turbo8: più velocità e meno degrado

Il codec turbo8 sostituisce il tradizionale q8_0 per le chiavi della cache KV e si abbina a turbo4 per i valori. I benchmark pubblicati dallo sviluppatore su X mostrano che all’aumentare del contesto il vantaggio si amplia: da +1,9% a 2.048 token fino a +15% a 32.768 token, con una divergenza KL sempre inferiore. Tradotto: turbo8 è più veloce e perde meno informazione.

Nella pratica, l’utilizzo asimmetrico turbo8/turbo4 si è rivelato decisivo per spingere la finestra di contesto a 128k senza saturare la memoria. Per ottenere il massimo dal fork spiritbuun, però, occorre applicare una patch (PR #72) che risolve una regressione del ~38% nella velocità di prefill, altrimenti il vantaggio si azzera durante l’elaborazione dei prompt lunghi.

Qualità e trade-off: I-Compact o I-Quality?

I dati del repository APEX (relativi al modello Qwen3.5-35B-A3B) dipingono un framework chiaro. I-Quality e UD-Q4_K_XL hanno perplexità quasi identica (6,552 contro 6,554), ma APEX I-Quality è circa il 7% più veloce nella generazione (62,3 t/s contro 58,1) e ottiene un HellaSwag leggermente superiore (83,5% contro 83,0%).

I-Compact, con i suoi 17 GB, offre la miglior efficienza: perplexità leggermente più alta (6,857 vs 6,552), ma lo stesso HellaSwag di I-Quality (83,5%) e la possibilità di spingere il contesto fino a 256k senza esaurire la VRAM. Chi cerca il bilanciamento tra qualità e ampiezza del contesto troverà in I-Compact un alleato prezioso.

Perché interessa a chi fa deployment on-premise

Questa esperienza dimostra che hardware consumer, se abbinato a quantizzazioni evolute e codec KV di nuova generazione, può sostenere carichi di lavoro complessi – contesti lunghi, flussi agentici – senza ricorrere a server multi-GPU o API cloud. Per le organizzazioni attente alla sovranità dei dati e al Total Cost of Ownership, il messaggio è forte: oggi è possibile self-hostare LLM MoE di grandi dimensioni su singola scheda, con un controllo granulare su tutti i componenti della pipeline.

Certo, si tratta di fork sperimentali, con patch da applicare manualmente e scenari testati su un solo utente. Ma la direzione è quella di un ecosistema in cui la community sposta l’asticella verso il basso in termini di hardware richiesto, democratizzando l’inference di modelli che fino a poco fa sembravano riservati ai datacenter. AI-RADAR segue queste evoluzioni – dalle scelte di quantization ai runtime di serving – perché ogni tassello conta nel percorso verso stack on-premise realmente sostenibili.