Qwen 3.8 27B su GPU da 16 GB: il limite resta la memoria
Le build quantizzate di Qwen 3.8 27B portano un modello da 27 miliardi di parametri nel budget di memoria di alcune GPU da 16 GB, secondo la guida 2026 pubblicata da Atomic. Il cambiamento concreto riguarda la compressione dei pesi e la possibilità di eseguire localmente un modello più grande, non una riduzione equivalente di tutte le risorse necessarie. I materiali disponibili documentano configurazioni e test, ma non una data precisa di rilascio sulla quale fondare l’annuncio.
La distinzione decisiva è tra 16 GB di VRAM e 16 GB di RAM complessiva. La prima configurazione dispone di memoria video dedicata; nella seconda, sistema operativo, applicazioni e inferenza devono condividere lo stesso budget. Presentare questi risultati come prova che un modello 27B funzioni comodamente su qualsiasi computer con 16 GB significa cancellare il vincolo che determina l’esperienza: quanta memoria resta dopo aver caricato i pesi?
Qwen 3.8 27B: la configurazione riguarda la VRAM
La guida di Atomic distingue esplicitamente RAM e VRAM: indica orientativamente modelli da 20B–35B per schede con 16 GB di memoria video, mentre colloca generalmente nella fascia 8B–12B le scelte per sistemi con 16 GB di RAM totale o memoria unificata. Sono indicazioni di dimensionamento, non garanzie di compatibilità per ogni architettura e contesto.
Qwen 3.8 27B, attribuito al team Qwen di Alibaba, viene descritto come un modello denso ibrido a 64 layer, con blocchi Gated DeltaNet e Gated Attention e un encoder visivo. Il modello di base supporta testo, immagini e video, dispone di modalità thinking disattivabile ed è distribuito con licenza Apache 2.0. Il supporto multimodale del modello non dimostra però che ogni conversione o configurazione locale offra automaticamente tutte queste funzioni.
Per una GPU da 16 GB, Atomic propone un file GGUF AD-IQ3S da 13,8 GB. È questa specifica build compressa, non il modello alla precisione originale, a rendere plausibile il caricamento nella memoria video. La capacità residua deve ancora assorbire cache e buffer del runtime.
Quantizzazione e KV cache: perché il contesto costa memoria
La quantizzazione riduce la precisione numerica con cui vengono rappresentati i pesi. Atomic Dynamic assegna precisioni differenti ai tensori in funzione della sensibilità misurata, invece di applicare una compressione uniforme. Il compromesso consiste nel ridurre l’occupazione preservando quanto possibile il comportamento del modello originale: non nel rendere gratuita l’inferenza.
Secondo la guida, in llama.cpp Qwen 3.8 richiede circa 256 KB per token di KV cache, la memoria che conserva informazioni utilizzate durante la generazione: circa 2 GB a 8K token e 8 GB a 32K. Atomic indica quindi intorno a 8K il contesto pratico con offload completo sulla GPU da 16 GB. È una stima da verificare: sommando un file da 13,8 GB alla cache da circa 2 GB, il margine per gli altri consumi è già ristretto.
Il contesto nativo dichiarato di 262.144 token, estendibile fino a un milione con tecniche come YaRN, non equivale pertanto al contesto utilizzabile su quella scheda. La variante da 13,0 GB lascia maggiore spazio; quella da 14,4 GB privilegia la fedeltà, mentre il file da 16,5 GB è descritto come troppo grande per un offload completo pratico. Il collo di bottiglia passa dai soli pesi alla memoria dell’intera sessione.
Fedeltà e benchmark: tre misure da non confondere
Atomic riporta una matrice d’importanza costruita su 4.967.044 token provenienti da 3.004 documenti e una valutazione rispetto al modello BF16 originale su 87 segmenti esclusi dalla calibrazione, ciascuno con contesto 4K. L’accordo sul token più probabile è del 91,33% per la build più compatta, del 92,41% per AD-IQ3S, del 93,15% per la variante intermedia e del 95,39% per quella da 16,5 GB.
Per la build raccomandata, il token preferito differisce dunque dall’originale in circa il 7,6% dei casi misurati. Questo non significa un tasso di errore del 7,6%: la metrica misura accordo tra distribuzioni, non correttezza delle risposte o affidabilità di un’applicazione. Inoltre, segmenti da 4K non dimostrano da soli la conservazione delle prestazioni su contesti molto più lunghi.
La guida riporta per Qwen anche 89,2 su GPQA Diamond, 90,3 su LiveCodeBench v6 e 61,7 su SWE-bench Pro. I materiali non stabiliscono però che questi risultati siano riprodotti dalla build da 13,8 GB sulla GPU da 16 GB. Separatamente, un test video della variante Estra W2, quantizzata a 2 bit e di circa 10 GB, riferisce 11,4 token al secondo su una RTX 2080 con 16 GB e il 75% di superamento di 100 esercizi Python. Un test Thinking Cap Q4KM riporta l’87%, ma con hardware e procedura differenti: non è un confronto controllato.
MoE e modelli piccoli: due alternative con vincoli diversi
Ornith 1.5 35B-A3B offre un’altra strada: l’architettura Mixture-of-Experts, o MoE, attiva circa 3 miliardi di parametri per token su 34,7 miliardi complessivi. Attivare meno parametri riduce il lavoro computazionale associato agli esperti selezionati, ma non elimina la necessità di conservare i pesi del modello. La build raccomandata pesa infatti 13,7 GB; quella da 15,5 GB è giudicata troppo stretta dopo l’allocazione di cache e buffer.
La guida descrive anche una variante da 22,1 GB con l’opzione –cpu-moe di llama.cpp: gli esperti instradati vengono collocati nella RAM di sistema, lasciando attenzione, routing e layer condivisi sulla GPU. Il costo viene spostato, non cancellato. Per Qwen, essendo denso, la stessa fonte segnala invece un offload sulla CPU oneroso.
Con 16 GB complessivi, Atomic elenca opzioni più piccole: Qwen 3.5 9B da 7,4 GB, Ornith 1.5 9B da 8,6 GB, Gemma 4 12B da 7,4 GB e LFM2.5 8B-A1B da 7,0 GB. Anche qui restano gli overhead del contesto e, quando supportati, degli input multimodali.
Inferenza locale: la decisione dipende dal carico reale
L’esecuzione locale può ridurre il ricorso a servizi cloud e mantenere l’elaborazione sul dispositivo, ma non certifica da sola privacy o convenienza economica. Il perimetro dipende dall’applicazione e dai suoi collegamenti esterni; il costo totale comprende hardware, energia, integrazione e manutenzione. È lo stesso criterio da applicare quando si valuta un computer destinato all’AI locale: la capacità dichiarata non basta a giustificare l’investimento.
Il vantaggio più concreto riguarda chi possiede già una GPU con memoria sufficiente e lavora con contesti contenuti. Prima dell’adozione servono misure sulla build effettiva: occupazione massima, latenza iniziale, velocità di generazione e qualità sui compiti previsti. I materiali non offrono una comparazione uniforme su questi punti. Il progresso è reale nel dimensionamento; resta da dimostrare quanto lavoro utile quella memoria riesca a sostenere senza sacrificare affidabilità e tempi di risposta.