La notizia in breve: da un test condiviso su Reddit, un utente ha chiesto a un modello Qwen3.6 35B-A3B di generare in un unico file HTML un simulatore di volo con montagne, nuvole e terreno procedurale. Tecnica di prompting: prima pianificazione, poi implementazione fedele al piano. Il risultato ha sorpreso: il modello ha prodotto un codice complesso e funzionale, ma la vera rivelazione è stata il passaggio dalla quantization a 4 bit su GPU (Q4_K_M) a quella a 8 bit su CPU (Q8_0). Con la precisione maggiore e l’esecuzione sul processore, la qualità dell’output è cresciuta in modo tangibile, tanto da definire il modello “fenomenale per la sua categoria”.

L’episodio non è un semplice aneddoto da appassionati. Tocca un nervo scoperto per chi gestisce deployment on-premise di LLM: l’eterna tensione tra velocità e qualità, che nella pratica della quantization trova uno dei suole banche di prova più concreti. Ridurre i pesi da 8 a 4 bit dimezza l’occupazione di memoria e rende possibile l’inference su GPU con VRAM limitata, magari a token/s sostenuti. Ma il prezzo da pagare in termini di coerenza e aderenza alle istruzioni può essere molto più alto di quanto suggeriscano i benchmark sulla perplessità.

Nel caso specifico, il salto da Q4_K_M a Q8_0 ha evidentemente restituito al modello la capacità di seguire con precisione un prompt articolato, producendo codice non solo sintatticamente corretto ma anche strutturalmente ricco. Non è una sorpresa assoluta: è noto che la quantization aggressiva introduce rumore che degrada le prestazioni su compiti di ragionamento e generazione strutturata. Ma vederlo esemplificato su un task creativo e complesso come un simulatore 3D autocontenuto dà una misura concreta del fenomeno.

Il fatto che l’inference su CPU — tradizionalmente considerata una soluzione di ripiego — abbia offerto risultati migliori rispetto alla GPU in questo scenario è un dettaglio tecnico con implicazioni di secondo ordine. Le CPU hanno accesso a molta più RAM (centinaia di gigabyte contro la VRAM tipica di una GPU consumer o anche professionale) e a un’architettura di memoria senza le limitazioni dei bus PCIe per il trasferimento tra RAM e VRAM quando si fa offloading. Con un quantizzato Q8_0, il modello pesa circa 35 GB, collocabile interamente in RAM senza frammentazioni. Su una CPU con molti core e adeguata larghezza di banda di memoria, l’inference può essere sufficientemente veloce per molti carichi di lavoro batch o interattivi, e la fedeltà del modello rimane alta. Questo cambia l’equazione per le organizzazioni: investire in server con CPU ad alta densità di core e centinaia di gigabyte di RAM potrebbe risultare più economico e flessibile che acquistare GPU costose e limitate in VRAM, specialmente per modelli che non richiedono latenze bassissime.

C’è poi un aspetto di sovranità dei dati e controllo che esula dalla mera ubicazione fisica. Un LLM self-hosted che produce codice HTML complesso in un colpo solo riduce la dipendenza da API cloud e da servizi esterni. Ma se il modello quantizzato male genera codice inaffidabile, il costo di correzione annulla il beneficio della sovranità. La scelta del livello di quantization diventa quindi parte integrante della strategia di deployment: troppo bassa, e il modello sbaglia; troppo alta, e i costi hardware lievitano. Il caso Qwen3.6 a 8 bit su CPU mostra un possibile punto di equilibrio, dove la lentezza è compensata dalla qualità dell’output, e il costo totale di possesso può essere competitivo rispetto a soluzioni ibride o cloud.

Guardando al panorama più ampio, modelli con attivazione sparsa come i Mixture of Experts riducono i parametri attivi per token. Qwen3.6 35B-A3B lascia intuire un’architettura con 35 miliardi di parametri totali e soltanto 3 miliardi attivi per inference. Questo rende plausibile l’uso su CPU senza l’intero peso computazionale di un modello denso da 35B, ma mantenendo la qualità di uno da 35B. Se questa strada sarà percorsa da altri vendor, la distinzione tra “modelli per GPU” e “modelli per CPU” potrebbe assottigliarsi, spostando gli investimenti infrastrutturali verso memorie più capienti e processori con più core vettoriali.

Non è detto che il sorpasso della CPU sia dietro l’angolo per ogni scenario. L’utente parla di “slowdown”, e per applicazioni real-time o interattive con molti utenti la latenza resta un fattore critico. Ma per generazione batch, codice, documentazione, analisi dati — dove la correttezza prevale sulla velocità — questa architettura ha senso. E per chi è già attrezzato con server on-premise tradizionali, riscoprire la CPU come piattaforma di inference per LLM di qualità potrebbe aprire una via a basso costo per portare l’AI generativa dietro il firewall senza stravolgere l’infrastruttura esistente.

In definitiva, un test artigianale riaccende un dibattito tecnico che le aziende farebbero bene a non ignorare. La quantization non è un interruttore binario ma un parametro di progetto con ripercussioni dirette sul valore di ciò che il modello produce. E il processore, spesso dato per spacciato nell’era delle GPU, potrebbe rivelarsi un alleato inaspettato per chi cerca qualità senza compromessi sulla sovranità dei dati.