Qwen3.8-Flash-Next in locale: cosa significano davvero 6 miliardi di parametri attivi per RAM, VRAM e NVMe

No, Qwen3.8-Flash-Next non entra in memoria come un modello da 6B solo perché attiva circa 6B parametri per token. Qwen descrive un modello principale da 125B parametri con 6B parametri attivati, oltre a 51B di embedding n-gram e un componente MTP di circa 4B. Il repository ufficiale di Qwen3.8-Flash-Next attualmente occupa circa 360 GB nella versione BF16 rilasciata. Le conversioni GGUF della community possono ridurre notevolmente questa dimensione, ma non trasformano Flash-Next in un modello convenzionale da 6B.

Il modo più utile di considerare l'implementazione locale è come una gerarchia di memoria. La VRAM determina la quantità di esecuzione del modello ad alta velocità che può rimanere sulla GPU. La RAM di sistema fornisce capacità per i componenti residenti sulla CPU e per quelli scaricati, inclusa la tabella n-gram insolitamente grande che Qwen ha progettato per funzionare dalla memoria del sistema. L'NVMe fornisce archiviazione locale veloce e supporto tramite memory mapping per file che si avvicinano o superano i 100 GB, ma non sostituisce la RAM o la VRAM. La vera domanda è quindi quale parte del carico hardware viene eliminata dai 6B attivi e quale no.

6B attivi significa che Qwen3.8-Flash-Next richiede solo la memoria di un modello da 6B?

No. I parametri attivati descrivono l'elaborazione per token, non la quantità totale di stato del modello esistente. Questa distinzione è particolarmente importante per Qwen3.8-Flash-Next, perché la differenza tra il numero di parametri attivi e quello dei parametri archiviati è insolitamente grande.

Secondo la scheda ufficiale del modello Qwen3.8-Flash-Next, il modello linguistico contiene 125B parametri, di cui ne vengono attivati circa 6B per ogni token, oltre a 51B di parametri per gli embedding n-gram e circa 4B di parametri associati a MTP. Il principale MoE contiene 512 esperti instradati e, per ogni token, seleziona 10 esperti instradati più un esperto condiviso.

Che produce tre numeri diversi da non confondere:

Il punto fondamentale è che gli esperti inattivi non smettono di esistere. Token diversi possono essere instradati verso esperti diversi, quindi il runtime deve comunque poter accedere al pool più ampio di pesi, anche se solo una piccola frazione partecipa al passaggio forward di un determinato token. Questo è lo stesso motivo generale per cui altri grandi modelli MoE possono avere una computazione attiva relativamente modesta pur mantenendo footprint di memoria molto grandi, una distinzione importante anche nella nostra analisi dell'hardware locale per GLM-5.3-Flash.

Flash-Next aggiunge un'ulteriore particolarità. La sua tabella di embedding n-gram da 51B non viene utilizzata come una normale matrice di pesi di una rete neurale densa. Nella panoramica ufficiale dell'architettura Flash-Next di Qwen, il team spiega che le posizioni di ricerca degli n-gram possono essere determinate in anticipo. La tabella può quindi risiedere nella memoria host ed essere pre-caricata in modo asincrono mentre viene eseguito il calcolo di altre parti del modello.

Ecco perché il numero di 6B di parametri attivi è significativo, anche se non rappresenta un requisito di memoria. Flash-Next è progettato per separare la capacità del modello dalla computazione per token in modo più marcato rispetto a un modello denso convenzionale. Per l'inferenza locale, questo sposta la questione hardware da un singolo numero di VRAM a quanto efficientemente VRAM, RAM di sistema e spazio di archiviazione possano lavorare insieme.

Quanto è grande Qwen3.8-Flash-Next dopo la quantizzazione?

La versione ufficiale BF16 occupa circa 360 GB, il che esclude immediatamente un'implementazione completamente residente dall'hardware desktop ordinario. La quantizzazione cambia sostanzialmente la situazione.

Al 1° settembre 2026, le build GGUF attuali di Flash-Next di Unsloth vanno da versioni low-bit estremamente aggressive a varianti molto più grandi e di alta qualità. Due punti di riferimento utili sono la build UD-IQ4_XS da circa 93,7 GB e la build UD-Q4_K_XL da circa 111 GB.

Queste dimensioni GGUF sono conversioni della community, non raccomandazioni ufficiali di Qwen sulla RAM o sulla VRAM minima. Sono comunque utili per pianificare la capacità, perché mostrano l'entità del problema prima di aggiungere i buffer del runtime, lo stato del contesto, l'elaborazione della visione, il sistema operativo e altre applicazioni.

Un file del modello da 94 GB, per esempio, non implica che una macchina con esattamente 96 GB di memoria combinata offra un'implementazione confortevole. Il runtime ha comunque bisogno di spazio di lavoro e la quantità di memoria aggiuntiva necessaria varia in base alla lunghezza del contesto, al backend, al formato della cache, alla strategia di offload sulla GPU e alla concorrenza.

Di quanta VRAM ha bisogno Qwen3.8-Flash-Next?

Non esiste un unico numero utile di "VRAM minima" per Flash-Next, perché l'inferenza locale può variare da un'esecuzione quasi interamente residente sulla CPU a un modello distribuito su una o più GPU. La VRAM determina principalmente quanta parte del carico di inferenza ad alta larghezza di banda può rimanere sulla GPU e quindi la velocità di esecuzione del sistema.

Una GPU consumer da 24 o 32 GB non può contenere da sola un GGUF attuale a quattro bit da 94–111 GB. Questo non significa necessariamente che la GPU sia inutile. Un runtime capace di eseguire un offload parziale sulla GPU può mantenere tensori o livelli selezionati nella VRAM, mentre la RAM di sistema contiene il resto.

Le attuali opzioni di caricamento dei modelli di llama.cpp includono il posizionamento dei livelli sulla GPU, la selezione esplicita del dispositivo, le sostituzioni dei tensori e i controlli CPU per MoE. Ciò significa che "la mia GPU può eseguirlo?" e "la mia GPU può contenere l'intero modello?" sono domande diverse.

La differenza di prestazioni tra queste configurazioni può essere enorme anche quando il modello viene tecnicamente caricato in ogni configurazione. La larghezza di banda della memoria della GPU è drasticamente superiore a quella della normale memoria di sistema, e spostare una parte consistente del calcolo attivo sulla CPU può trasformare un modello locale altrimenti impressionante in qualcosa di più adatto alla sperimentazione che all'uso interattivo con agenti.

Per Flash-Next, la VRAM dovrebbe quindi essere considerata una **allocazione per le prestazioni**, non un requisito binario di compatibilità.

Quanta RAM serve a Qwen3.8-Flash-Next per l'offload tra CPU e GPU?

La RAM di sistema è probabilmente più importante per Flash-Next di quanto suggerisca il titolo "6B attivi". Una macchina con una GPU consumer ma con pochissima RAM non ha un posto utile in cui collocare la grande quantità di stato del modello che non entra nella VRAM.

L'embedding n-gram rende la situazione particolarmente interessante. Qwen afferma che la tabella da 51B può essere collocata nella memoria dell'host perché i suoi accessi sono deterministici e possono essere precaricati. Quando l'implementazione di Flash-Next è stata integrata in llama.cpp il 27 agosto, le note di implementazione descrivevano la tabella di embedding n-gram per livello come grande circa 97,7 GiB in BF16 e gestivano la ricerca delle righe dal lato host.

Questo non significa che ogni implementazione locale richieda permanentemente altri 97,7 GiB non quantizzati oltre a un GGUF quantizzato. La quantizzazione e la rappresentazione durante l'esecuzione sono importanti. Ciò dimostra però perché l'architettura è stata progettata intorno alla memoria eterogenea, invece di presumere che ogni parametro debba rimanere nella memoria della GPU.

Per un'inferenza GGUF pratica, la memoria di sistema dovrebbe essere pianificata in base alle dimensioni effettive del modello quantizzato, oltre al margine per il sistema operativo e il runtime. Con una quantizzazione di circa 94 GB, 128 GB di RAM sono una capacità obiettivo sperimentale plausibile, ma non offrono un margine ampio una volta inclusi il sistema operativo, il contesto, i buffer e il comportamento dell'allocazione tra GPU e host. Un sistema da 192 GB o 256 GB offre un margine molto più sicuro per un'inferenza ibrida seria.

Questo è uno degli esempi più chiari del motivo per cui la memoria dell’IA locale sta diventando una gerarchia anziché una singola specifica di VRAM. La memoria della GPU gestisce le attività più sensibili alla larghezza di banda, la memoria host amplia la capacità del modello e lo storage fornisce i dati persistenti del modello sottostanti a entrambe.

L’offloading su SSD NVMe può rendere pratico Qwen3.8-Flash-Next?

L’NVMe può rendere più facile archiviare e caricare un modello sovradimensionato, ma non trasforma la capacità dell’SSD in memoria veloce per l’inferenza. Questa distinzione diventa più importante man mano che i modelli locali superano la soglia dei 100 GB.

Un’unità NVMe veloce è utile per archiviare più varianti GGUF, caricare un modello di grandi dimensioni senza attendere lo storage di rete o il disco rigido più lento e supportare l’accesso al modello tramite memory mapping. llama.cpp utilizza il memory mapping come modalità di caricamento del modello, consentendo di mappare le pagine del modello da un file invece di richiedere che l’intero file venga copiato in una distinta allocazione RAM all’avvio.

Tuttavia, la documentazione sul caricamento della memoria di llama.cpp spiega anche perché ciò non dovrebbe essere interpretato come uno scaricamento gratuito sul disco. Se il modello operativo supera la RAM disponibile, i pageout e i ripetuti accessi allo storage possono compromettere le prestazioni. Il blocco della memoria esiste proprio perché può essere importante mantenere residenti nella RAM le pagine del modello utilizzate più frequentemente.

Una regola utile è: l’NVMe può rendere caricabile un modello sovradimensionato; non lo rende automaticamente interattivo.

Questo spiega anche perché l’architettura dello storage è sempre più importante per l’IA locale, anche quando il dispositivo di archiviazione non esegue direttamente l’inferenza. Modelli, risorse per la visione, indici RAG, dataset, spazi di lavoro degli agenti e diversi checkpoint quantizzati possono facilmente occupare centinaia di gigabyte. Lo storage locale veloce sta diventando parte del sistema IA, ma occupa comunque un livello diverso da quello della memoria che alimenta i calcoli attivi.

In che modo un contesto di 262K modifica il requisito di memoria?

Qwen3.8-Flash-Next supporta nativamente una lunghezza del contesto di 262.144 token e può essere esteso fino a un milione di token con YaRN. Ciò non significa che ogni distribuzione locale debba configurare per impostazione predefinita il contesto massimo.

Il modello utilizza un'architettura ibrida invece della consueta attenzione completa a ogni livello. Gated DeltaNet comprime la cronologia, mentre Qwen Sparse Attention utilizza un indicizzatore per selezionare i blocchi di contesto pertinenti. Questo è progettato specificamente per ridurre la pressione computazionale e di memoria associata alle sequenze lunghe.

Il contesto lungo non è comunque gratuito. La memoria del runtime può includere lo stato ricorrente, le cache dell'attenzione sparsa, lo stato dell'indicizzatore, i buffer temporanei di calcolo, gli input visivi, l'overhead del batching e le allocazioni specifiche del backend. L'andamento esatto della memoria dipende quindi dal motore di inferenza e non è determinato soltanto dalle dimensioni del file GGUF.

Esiste inoltre una differenza tra il limite di contesto architetturale di un modello e il livello di maturità dell'implementazione attuale di un runtime. Al 1° settembre 2026, il supporto di llama.cpp alla nuova architettura ha solo pochi giorni. Un problema CUDA attuale relativo al contesto di 262K segnala un errore nell'avvio del kernel esattamente a 262.144 token, mentre nel sistema di test 261.888 token funzionano correttamente. La segnalazione identifica il problema come una limitazione del kernel, non come un esaurimento della VRAM.

Questo problema specifico potrebbe essere risolto rapidamente, ma illustra un punto più generale: 262K è una capacità del modello, non una garanzia che ogni GPU attuale e ogni backend di inferenza possano utilizzare oggi l'intera finestra in modo efficiente.

Per la distribuzione locale, inizia dalla lunghezza del contesto effettivamente necessaria al carico di lavoro. Una sessione di programmazione, un'attività di analisi documentale o un flusso di lavoro RAG privato che rientra in 16K, 32K o 64K non migliora semplicemente perché il runtime riserva centinaia di migliaia di token.

Quale hardware può eseguire davvero Qwen3.8-Flash-Next in locale?

La risposta più utile sull'hardware dipende da cosa si intende per "eseguire". Caricare un modello fortemente quantizzato e generare token è un obiettivo. Mantenere prestazioni interattive, un contesto ampio, input visivi e carichi di lavoro basati su agenti è un obiettivo molto più impegnativo.

La tabella seguente è quindi una guida alla pianificazione basata sulle dimensioni attuali dei modelli e dei file GGUF, non una raccomandazione hardware ufficiale per Qwen.

La linea di demarcazione più importante non è uno specifico modello di GPU. È se la macchina dispone di una capacità combinata sufficiente di memoria veloce per evitare che il paging dallo storage entri nel percorso critico della generazione.

Una GPU da 24 GB abbinata a 192 GB di memoria di sistema veloce può offrire un esperimento con Flash-Next più credibile rispetto a una GPU da 24 GB abbinata a soli 32 o 64 GB di RAM. Al contrario, aggiungere una grande quantità di RAM non rende l’inferenza incentrata sulla CPU equivalente all’esecuzione degli stessi tensori nella memoria GPU ad ampia banda.

Per la maggior parte degli utenti desktop comuni interessati alla famiglia Qwen3.8 più che a questa architettura nello specifico, Qwen3.8-27B è l’obiettivo locale più convenzionale. Flash-Next ha più senso per chi vuole deliberatamente sperimentare con un modello sparso molto più grande, memoria eterogenea, un’architettura a contesto esteso o la tecnologia che, secondo Qwen, anticipa la direzione di Qwen4.

Vale la pena eseguire Qwen3.8-Flash-Next in locale?

Sì, per la workstation giusta e per il motivo giusto, ma non perché “6B attivi” facciano improvvisamente comportare un modello da circa 180 miliardi di parametri come un piccolo modello desktop.

Flash-Next è particolarmente interessante se disponi di 128–256 GB di memoria di sistema o unificata, di un’accelerazione GPU significativa, di uno storage NVMe veloce e di un motivo per sperimentare carichi di lavoro locali di grandi dimensioni per la programmazione, il multimodale, l’ufficio o gli agenti. La sua architettura è insolitamente rilevante per l’IA locale perché separa deliberatamente i parametri calcolati più frequentemente dalle grandi strutture orientate alla capacità, che possono risiedere al di fuori della memoria della GPU.

È una soluzione molto meno adatta a un normale PC con 32–64 GB di RAM, quando il piano dipende dal recupero costante da parte del sistema operativo delle pagine mancanti del modello dall’SSD. Una macchina del genere può dimostrare che il modello riesce tecnicamente ad avviarsi, ma “si carica correttamente” e “funziona in modo utile” sono criteri diversi.

La lezione più ampia va oltre questo modello. L’hardware per l’IA locale riguarda sempre meno la richiesta di un unico numero minimo di VRAM e sempre più la progettazione di una gerarchia: VRAM per il calcolo ad alta velocità, RAM per la capacità accessibile del modello e NVMe per l’archiviazione locale persistente di modelli e dati. Qwen3.8-Flash-Next rende questo passaggio insolitamente evidente.

FAQ: requisiti hardware locali per Qwen3.8-Flash-Next

Qwen3.8-Flash-Next può essere eseguito su una RTX 4090 o una RTX 5090?

Sì, queste GPU possono partecipare a un'implementazione locale ibrida, ma né una RTX 4090 da 24 GB né una RTX 5090 da 32 GB possono contenere interamente nella VRAM un modello GGUF Flash-Next attuale a quattro bit da circa 94–111 GB. Servirebbero una quantità consistente di RAM di sistema e l'offload su CPU/GPU. La GPU può comunque accelerare la parte del modello collocata al suo interno, quindi è molto diverso dal dire che queste schede non possono essere utilizzate.

Qwen3.8-Flash-Next può essere eseguito con 64 GB di RAM?

64 GB di RAM di sistema sono inferiori alle dimensioni delle build GGUF pratiche attuali più piccole, a quattro bit. La mappatura in memoria può consentire di accedere a porzioni di un file sovradimensionato dallo spazio di archiviazione, ma il paging ripetuto probabilmente renderà l'inferenza lenta e instabile in un carico di lavoro interattivo. Per un'implementazione locale seria, 64 GB non dovrebbero essere considerati un obiettivo pratico.

128 GB di RAM sono sufficienti per Qwen3.8-Flash-Next?

128 GB è un punto di partenza plausibile per una delle build GGUF più piccole, a circa quattro bit, se abbinata all'offload sulla GPU e a una finestra di contesto prudente. Non è una raccomandazione universale comoda. Un modello di circa 94 GB lascia meno di 34 GB per il sistema operativo, i buffer del runtime, lo stato del contesto, l'elaborazione della visione e altri servizi; pertanto, 192 GB o più offrono un margine significativamente migliore.

Qwen3.8-Flash-Next può essere eseguito interamente da un SSD NVMe?

Un runtime può mappare in memoria i file del modello archiviati su NVMe e il sistema operativo può recuperare le pagine quando servono. Questo non equivale a eseguire il modello «dall'SSD» alla velocità della RAM o della GPU. L'NVMe è eccellente per archiviare e caricare i modelli, ma utilizzarlo continuamente perché la memoria fisica è esaurita può ridurre drasticamente le prestazioni di generazione.

Il valore di 6B di parametri attivi significa che Qwen3.8-Flash-Next è veloce quanto un modello da 6B?

No. Il valore di 6B indica il numero approssimativo di parametri attivati del modello principale per ciascun token. Flash-Next conserva comunque un'architettura molto più grande, logica di instradamento, traffico di memoria, ricerca n-gram, stato dell'attenzione sparsa e altro lavoro a runtime. Un numero inferiore di parametri attivati può ridurre notevolmente il calcolo, ma non rende l'intero sistema equivalente a un modello denso da 6B.

Ollama o llama.cpp possono eseguire Qwen3.8-Flash-Next localmente?

supporto di llama.cpp per Qwen3.8-Flash-Next qwen4exp l'architettura è stata integrata in master il 27 agosto 2026, un giorno dopo il rilascio del modello. Gli attuali repository della community con modelli GGUF forniscono inoltre build destinate ai flussi di lavoro di inferenza locale basati su llama.cpp. Poiché l'implementazione è ancora molto recente, verifica le versioni runtime attuali e le istruzioni del modello prima di presumere che ogni backend GPU, lunghezza del contesto, percorso di visione o configurazione di offload sia altrettanto maturo.