Un simulatore di volo in un singolo file HTML, generato da un modello linguistico. Non è una demo da conferenza, ma il risultato di un prompt artigianale pubblicato su Reddit. L’autore ha chiesto a Qwen3.6 35B-A3B di produrre un ambiente 3D procedurale con montagne, nuvole e terreno. Nessuna rivoluzione, se non fosse per il dettaglio tecnico che fa la differenza: il codice è stato generato con il modello in quantization a 8 bit eseguito su CPU, dopo che la versione a 4 bit su GPU aveva deluso. Il miglioramento qualitativo è stato così netto da spingere l’utente a definire il modello “fenomenale per la sua categoria”. L’episodio, in apparenza aneddotico, condensa in sé tre snodi cruciali per chi gestisce deployment on-premise di LLM: il rapporto tra quantization e fedeltà dell’output, la rinnovata competitività delle CPU per l’inference e l’impatto delle architetture a esperti (MoE) sui requisiti hardware.

Il prezzo occulto della quantization aggressiva

La quantization è una delle leve più usate per far entrare modelli di grandi dimensioni in hardware consumer o aziendale. Ridurre i pesi da 16 a 8 o 4 bit dimezza (o più) l’occupazione di VRAM, accelera l’inference e rende possibile l’esecuzione su GPU con memoria limitata. Ma la riduzione di precisione non è indolore. I benchmark sulla perplessità tendono a sottostimare l’impatto su compiti che richiedono aderenza puntuale a istruzioni complesse, generazione di codice strutturato o ragionamento multi-step. Nel caso del simulatore HTML, il passaggio da Q4_K_M (4 bit con alcuni livelli in 6 bit) a Q8_0 (8 bit uniformi) ha restituito al modello la capacità di seguire fedelmente un prompt che prevedeva una fase di pianificazione e una di implementazione. Il quantizzato a 4 bit, con ogni probabilità, introduceva un rumore tale da degradare la coerenza interna durante la generazione di un output lungo e articolato, facendo deragliare la struttura del codice. Non è una novità assoluta, ma vederlo esemplificato su un task creativo di tale complessità dà una misura concreta del fenomeno e ricorda che la quantization non è una proprietà binaria, ma un parametro di progetto con effetti diretti sulla qualità percepita dell’output.

Per le organizzazioni, questo significa che la scelta del formato di quantization non può essere delegata esclusivamente a metriche di velocità o di occupazione di memoria. Un modello che produce codice inaffidabile o testo che richiede continue correzioni vanifica il risparmio infrastrutturale ottenuto con il 4-bit. Il trade-off va quindi esplicitato e valutato in funzione del carico di lavoro: per task di classificazione o riassunto, un 4-bit può bastare; per generazione strutturata, documentazione tecnica o assistenza al codice, la maggiore precisione di un 8-bit – o addirittura di un 16-bit quando le risorse lo consentono – può ridurre i costi di post-elaborazione e aumentare la fiducia nell’output. Il test artigianale su Qwen3.6 suggerisce che già il salto a 8 bit può fare la differenza tra un modello “nella media” e uno “sorprendente”, anche se eseguito su un processore anziché su una scheda grafica.

L’architettura MoE sposta l’equilibrio verso la CPU

Qwen3.6 35B-A3B è un modello con un’architettura Mixture of Experts che attiva solo una frazione dei parametri totali per ogni token. La sigla “A3B” indica probabilmente 3 miliardi di parametri attivi su un totale di 35, una configurazione che riduce drasticamente il carico computazionale rispetto a un modello denso da 35 miliardi. Su GPU, questa caratteristica permette di sfruttare la VRAM in modo più efficiente, ma non elimina il collo di bottiglia principale: la capacità di memoria. Su CPU, invece, l’accesso a centinaia di gigabyte di RAM di sistema consente di caricare l’intero modello senza dover ricorrere a tecniche di offloading o a partizionamenti complessi. Con un quantizzato Q8_0 che pesa circa 35 GB, una macchina con 64 o 128 GB di RAM può ospitare il modello senza frammentazioni e con una banda di memoria che, sebbene inferiore a quella della VRAM, risulta abbondante per molti flussi di lavoro batch o interattivi a bassa concorrenza. L’architettura a esperti fa il resto: solo 3 miliardi di parametri vengono effettivamente attraversati a ogni token, mantenendo il costo computazionale entro limiti gestibili anche per un processore moderno con molti core e supporto alle istruzioni vettoriali.

Questo scenario ribalta una percezione radicata: la CPU è sempre stata considerata un ripiego per l’inference di LLM, una soluzione valida solo quando mancano le GPU. Ma con modelli dalla struttura sparsa e quantization oculata, la CPU può diventare una piattaforma di prima scelta per carichi dove la qualità dell’output è prioritaria rispetto alla latenza. Non si tratta di immaginare un sorpasso generalizzato, ma di riconoscere che esiste una classe di applicazioni – generazione di codice, reportistica, analisi dati in modalità asincrona – in cui un server CPU con molta RAM può offrire un rapporto qualità-prezzo difficilmente eguagliabile dalle GPU, specialmente se si considera il costo totale di possesso comprensivo di consumo energetico, raffreddamento e cicli di aggiornamento hardware. Inoltre, la possibilità di scalare orizzontalmente con più nodi CPU, magari sfruttando macchine già presenti in sala server, apre prospettive interessanti per l’inference distribuita senza dover stravolgere l’infrastruttura esistente.

Costo totale di possesso: la RAM come asset strategico

Per un’organizzazione che valuta un deployment on-premise di LLM, il calcolo del TCO ruota spesso attorno al prezzo delle GPU. Una scheda con 24 GB di VRAM può costare diverse migliaia di euro, e per modelli da 35 miliardi di parametri servirebbero almeno due schede o una configurazione con offloading parziale, con le relative complicazioni di banda e latenza. Una macchina server con CPU ad alta densità di core (ad esempio 32 o 64 core) e 128 GB di RAM DDR5 ha un costo assoluto comparabile, ma offre un ambiente più flessibile: la RAM può essere espansa fino a terabyte con costi marginali contenuti, mentre la VRAM su GPU è un vincolo fisico difficile da superare se non acquistando schede più costose o adottando architetture multi-GPU che fanno lievitare il budget di sistema. Il test su Qwen3.6 a 8 bit mostra che su una dotazione di RAM oggi considerata standard per server, è possibile eseguire un modello con qualità di output elevata senza dover scendere a compromessi sulla precisione dei pesi.

L’equazione cambia ulteriormente se si considera la durata del ciclo di vita dell’hardware. Le GPU, spinte dall’innovazione frenetica e dai colli di bottiglia di fornitura, seguono una curva di obsolescenza rapida, con generazioni che si susseguono ogni 18-24 mesi. I server CPU basati su piattaforme mature hanno un ciclo più lungo e benefici di economie di scala già consolidate. Anche il consumo energetico, in uno scenario di inference CPU, può essere più facile da gestire all’interno di data center progettati per carichi general purpose, senza richiedere l’adozione di sistemi di raffreddamento specializzati. Per le realtà che dispongono già di server tradizionali, la prospettiva di riconvertire parte della capacità computazionale inutilizzata per servire LLM on-premise, semplicemente aggiungendo RAM e utilizzando quantizzati a 8 bit, potrebbe trasformare un centro di costo in un asset abilitante per l’AI generativa dietro il firewall.

Non va trascurato, tuttavia, il limite della latenza. Su CPU, il tempo per generare un token è superiore a quello di una GPU moderna, e per applicazioni interattive con molti utenti concorrenti la lentezza può diventare inaccettabile. Tuttavia, per carichi batch notturni, pipeline di generazione di documentazione o assistenti che operano in modalità asincrona, la latenza non è il fattore critico. La variabile chiave diventa la bandwidth di memoria, che su piattaforme server con otto o più canali DDR5 può raggiungere valori sufficienti a sostenere un throughput di token accettabile per molti scenari d’uso. Monitorare l’evoluzione delle CPU con acceleratori AI integrati (come le NPU o i motori vettoriali) diventa quindi un segnale da non sottovalutare: se queste unità diventassero comuni anche su processori server, il divario con le GPU si assottiglierebbe ulteriormente per i carichi di inference.

Sovranità dei dati e affidabilità dell’output: due facce della stessa medaglia

Il principio della sovranità dei dati spinge molte organizzazioni a preferire soluzioni self-hosted per l’AI generativa, evitando di inviare informazioni sensibili a servizi cloud esterni. Ma la sovranità non è soltanto una questione di posizione fisica dei dati: se il modello on-premise produce output inaffidabili, il costo delle correzioni può annullare i benefici del controllo diretto. L’esempio del simulatore di volo mostra come una differenza apparentemente sottile nel formato di quantization possa rendere il modello utile o inutilizzabile per un task complesso. Se l’obiettivo è generare codice da integrare in un prodotto software, una bassa fedeltà genera debito tecnico e richiede interventi manuali che vanificano l’automazione. La scelta del formato di quantization diventa quindi parte integrante della strategia di sovranità: non basta tenere i dati in casa, serve un modello che rispetti le istruzioni senza introdurre errori difficili da individuare.

Questa consapevolezza spinge a riconsiderare l’intero stack di deployment. Anziché puntare tutto sulla velocità con GPU e quantizzati estremi, alcuni team potrebbero adottare un approccio ibrido: più istanze su CPU per i carichi dove la qualità è prioritaria, e GPU per i servizi real-time che tollerano una precisione ridotta. La gestione della coda e del bilanciamento del carico diventerebbe più articolata, ma consentirebbe di sfruttare al meglio entrambe le architetture. Nel caso specifico di Qwen3.6, un modello che si dimostra capace di produrre codice complesso a 8 bit su CPU può diventare il motore di uno strumento di development interno, dove gli sviluppatori lanciano una richiesta, attendono qualche secondo in più, ma ottengono un risultato direttamente utilizzabile. L’alternativa cloud avrebbe latenze inferiori, ma comporterebbe l’invio di codice e specifiche fuori dal perimetro aziendale – un rischio che molti settori regolamentati non possono permettersi.

La fiducia nell’output è il vero abilitatore della sovranità. Se il modello sbaglia in modo subdolo, il controllo sui dati serve a poco perché il processo decisionale umano deve comunque verificare ogni singola risposta, azzerando i guadagni di produttività. Invece, un modello quantizzato in modo conservativo su CPU, magari con una finestra di contesto ampia e una buona aderenza alle istruzioni, può essere delegato a compiti di generazione con un livello di supervisione ridotto. Il test artigianale di Qwen3.6 diventa così un campanello d’allarme: la rincorsa alla velocità e alla compressione spinta non deve far perdere di vista il motivo per cui si adotta un LLM, ovvero la capacità di produrre output significativi e affidabili.

Cosa guardare nei prossimi mesi

L’episodio segnala alcune traiettorie che le organizzazioni farebbero bene a monitorare. La prima è l’evoluzione dei modelli MoE. Se i vendor continueranno a rilasciare architetture con un rapporto parametri totali/attivi favorevole, l’inference su CPU diventerà progressivamente più praticabile anche per modelli di grandezza nominale elevata. L’arrivo di framework di inference ottimizzati per CPU, come i back-end che sfruttano le istruzioni AVX-512 o AMX dei processori Intel e le unità AMX/Metal di Apple, potrebbe accelerare ulteriormente questo trend. Il secondo segnale è l’andamento dei formati di quantization. Se la ricerca produrrà tecniche di compressione che mantengono la qualità di un 8-bit con l’ingombro di un 4-bit, il confine tra CPU e GPU si sposterà ancora. Ma per ora, il pragmatismo suggerisce di testare i modelli nelle condizioni reali di utilizzo, valutando la qualità percepita e non solo i benchmark astratti, prima di decidere il formato di deployment.

Infine, il mercato dell’hardware server potrebbe rispondere con piattaforme ibride che integrano acceleratori neurali accanto a CPU con molti canali di memoria, pensate esplicitamente per l’inference di LLM. Se queste soluzioni raggiungeranno prezzi accessibili, il trade-off odierno tra fedeltà e velocità potrebbe assottigliarsi, aprendo una terza via per il self-hosting: sistemi che offrono la banda di memoria di una GPU con la capacità di espansione della RAM. Nel frattempo, il test casalingo di un simulatore di volo ci ricorda che ogni scelta architetturale, dalla quantization all’hardware, ha un impatto diretto su ciò che l’utente finale vede e utilizza, e che l’on-premise ben progettato non è una rinuncia alla qualità, ma la condizione per poterla controllare fino in fondo.