DeepSeek-V4-Flash sta in memoria grazie agli esperti a 4 bit

Chi dimensiona una macchina per DeepSeek-V4-Flash ragiona sul numero sbagliato. Il modello attiva 13 miliardi di parametri per token e ne conserva 284 miliardi (rapporto tecnico). La prima cifra stabilisce la velocità, la seconda stabilisce il conto della memoria. Noi dimensioniamo gli host Mixture-of-Experts sulla seconda, e se resta sostenibile lo si deve a una sola riga del file di configurazione: gli esperti sono archiviati a 4 bit.

DeepSeek ha pubblicato DeepSeek-V4-Flash-0731 il 31 luglio 2026 come versione ufficiale che sostituisce l'anteprima, con architettura e dimensioni invariate (MarkTechPost). I pesi sono rilasciati con licenza MIT e scaricabili liberamente (scheda del modello). Di seguito il calcolo dietro il numero della memoria, il punto esatto in cui l'affermazione « gira su un portatile » si sgretola, e che cosa cambia nel dimensionamento.

Il numero più citato è quello sbagliato

I parametri attivi determinano il calcolo per token. Il totale determina il conto della memoria, perché il router può richiamare qualsiasi esperto a ogni token: tutti devono quindi restare residenti.

Da qui discende tutto il resto. Un router che seleziona 6 esperti su 256 per ogni token non consente di tenerne in memoria soltanto 6: al token successivo ne sceglie altri sei. Ogni esperto deve essere residente, altrimenti il token resta in attesa di una lettura da disco. ModemGuides ne trae la conseguenza senza giri di parole: un modello denso da 13 miliardi richiede circa 8 GB a 4 bit, mentre V4-Flash, a precisione paragonabile, ne richiede all'incirca venti volte tanto (analisi hardware). Una discussione sul forum di Hugging Face lo sintetizza in quattro parole: « Not a 13B memory problem » (discussione).

Ormai dimensioniamo ogni host Mixture-of-Experts sul numero totale di parametri e trattiamo quello attivo come una pura misura di throughput, perché su questo modello i due valori differiscono di un fattore 22. L'abitudine non costa nulla quando le due cifre sono vicine e risparmia un ciclo di acquisti quando non lo sono.

❌ Dimensionare sul titolo: « 13 miliardi attivi, basterà una scheda da 24 GB. » ✅ Dimensionare sul checkpoint: 284 miliardi di pesi residenti, una soglia che si misura in centinaia di gigabyte, e la scheda da 24 GB esce dalla discussione.

Che cosa dice davvero il file di configurazione

Il checkpoint di DeepSeek-V4-Flash è a precisione mista per scelta progettuale: i pesi degli esperti MoE sono archiviati in FP4, mentre attenzione, normalizzazione e router restano in FP8.

Non si tratta di una quantizzazione applicata a posteriori dalla comunità, ma di una caratteristica dei pesi rilasciati, leggibile direttamente nel file config.json (configurazione):

"expert_dtype": "fp4",
"n_routed_experts": 256,
"num_experts_per_tok": 6,
"n_shared_experts": 1,
"num_hidden_layers": 43,
"hidden_size": 4096,
"moe_intermediate_size": 2048,
"quantization_config": {
  "quant_method": "fp8",
  "fmt": "e4m3",
  "weight_block_size": [128, 128]
}

La ricetta vLLM dedicata al modello descrive la stessa ripartizione a parole: pesi degli esperti in FP4, restanti parametri di attenzione, normalizzazione e routing in FP8 (ricette vLLM). Due tipi di dato, un solo checkpoint. Quale delle due metà prevalga decide tutto il resto, ed è la domanda a cui la configurazione risponde.

Dove risiedono i 284 miliardi di parametri

I tensori degli esperti rappresentano circa 278 dei 284 miliardi di parametri di V4-Flash. Per questo il formato di archiviazione scelto per gli esperti fissa quasi per intero l'occupazione di memoria.

La configurazione basta a verificarlo, senza scaricare nulla. Ogni esperto è un blocco SwiGLU che porta una dimensione nascosta di 4096 attraverso una dimensione intermedia di 2048, distribuita su tre matrici: gate, up e down. Sono 3 × 4096 × 2048, ovvero circa 25,2 milioni di parametri per esperto. Con 256 esperti instradati più un esperto condiviso, un singolo strato arriva così a quasi 6,5 miliardi di parametri nei soli esperti. Su 43 strati il totale si aggira sui 278 miliardi.

Rapportati ai 284 miliardi pubblicati, gli esperti pesano dunque circa il 98 per cento del modello. Tutto il resto — attenzione, embedding, normalizzazione, lo stesso router — si divide i pochi miliardi rimanenti.

Lo stesso calcolo applicato al percorso attivo restituisce la cifra pubblicata. Sei esperti instradati più quello condiviso fanno 7 esperti attivi per strato, circa 176 milioni di parametri, e quasi 7,6 miliardi su 43 strati. Aggiungendo lo stack di attenzione e gli embedding, densi e sempre attivi, si arriva ai 13 miliardi di parametri attivati dichiarati dal rapporto tecnico. La configurazione è coerente con sé stessa, cosa che conviene accertare prima di dare credito a qualsiasi numero da essa derivato.

La forma adottata è una scelta, non una casualità. La famiglia V4 unisce uno stack di attenzione ibrido — Compressed Sparse Attention e Heavily Compressed Attention — a Manifold-Constrained Hyper-Connections. Il rapporto tecnico quantifica il risultato nel 27 per cento dei FLOP di inferenza per token e nel 10 per cento della cache KV di DeepSeek-V3.2 su un contesto da un milione di token (rapporto tecnico). Routing sparso e attenzione compressa risolvono due problemi distinti: il routing contiene il calcolo per token, l'attenzione compressa rende sostenibile il contesto. Nessuno dei due riduce i pesi residenti, ed è esattamente per questo che il formato di archiviazione deve occuparsene separatamente.

Restano da applicare i tipi di dato. A mezzo byte per parametro, 278 miliardi di parametri di esperti occupano circa 139 GB. I pochi miliardi di parametri restanti, a un byte ciascuno, aggiungono una cifra singola di gigabyte. Se gli stessi esperti fossero stati rilasciati in FP8 occuperebbero circa 278 GB, in BF16 ben oltre mezzo terabyte. La scelta dell'FP4 non è quindi un dettaglio di arrotondamento: separa una singola macchina ad alta memoria da un'installazione distribuita su più nodi.

Il conto della memoria in byte, non in parametri

Il checkpoint rilasciato di DeepSeek-V4-Flash misura circa 167 GB su disco, e la più piccola versione quantizzata consigliata si ferma a 103 GB, con una soglia di 110 GB di memoria di lavoro.

Il numero di parametri è un'approssimazione, i byte sono il vincolo reale, e le cifre in byte sono pubbliche. I checkpoint fusi 0731 occupano circa 167 GB contro i circa 160 GB dell'anteprima, e la differenza sta nel modulo di decodifica speculativa che vi è agganciato (ricette vLLM).

Al di sotto della precisione piena, Unsloth pubblica una scala calibrata. La versione consigliata UD-IQ3_XXS pesa 103 GB, con l'indicazione di disporre di almeno 110 GB di RAM, dato che la dimensione del file esclude cache KV e allocazione del contesto. La versione UD-Q8_K_XL corrisponde a V4-Flash nella piena precisione originale, a 162 GB (documentazione Unsloth).

Tre numeri meritano di entrare in qualsiasi decisione sull'hardware:

Versione	Dimensione del file	Soglia di memoria di lavoro
Checkpoint 0731 rilasciato	~167 GB	superiore alla dimensione del file
Precisione piena (`UD-Q8_K_XL`)	162 GB	superiore alla dimensione del file
Consigliata, 3 bit (`UD-IQ3_XXS`)	103 GB	110 GB

Esiste inoltre più di un checkpoint. La ricetta vLLM ne elenca quattro: la versione 0731 predefinita con il modulo di bozza, i pesi FP8 dell'anteprima, una versione DSpark di anteprima e una variante NVFP4 pubblicata da NVIDIA, in cui gli esperti MoE vengono riquantizzati in NVFP4 standard mentre attenzione, esperti condivisi, testa di routing e modulo di bozza restano in FP8. Quella variante punta alle GPU Blackwell e porta con sé una riserva che conviene leggere prima di sceglierla: i suoi esperti non supportano il kernel MoE fuso riservato all'FP8 e ripiegano sul backend predefinito (ricette vLLM). Scegliere un checkpoint è dunque una decisione di throughput oltre che di memoria.

Lo scarto tra dimensione del file e soglia di lavoro è ciò che i team dimenticano. Una finestra di contesto da un milione di token (rapporto tecnico) non arriva senza costi di memoria, e le dimensioni dei file pubblicate non la comprendono.

In questi numeri si nasconde una lezione minore, ed è la stessa dei conteggi dei parametri. I totali pubblicati non concordano: accanto alla cifra di 284 miliardi hanno circolato articoli che ne indicavano 304 miliardi. Il rapporto tecnico fissa 284 miliardi con 13 miliardi attivati, e la ricetta vLLM come le schede tecniche dei fornitori lo confermano. Quando una cifra da titolo è contestata, è la dimensione su disco a bloccare davvero un'installazione, e sui 167 GB non discute nessuno.

Perché « gira su un portatile » continua a circolare

Sostenere che DeepSeek-V4-Flash funzioni su un portatile da 32 GB senza scheda grafica contrasta con le dimensioni pubblicate, dato che la più piccola quantizzazione consigliata richiede una soglia di 110 GB di memoria.

L'affermazione circola ovunque, e l'attrattiva si capisce: 13 miliardi di parametri attivi suggeriscono un modello adatto a una postazione di sviluppo. Non abbiamo testato una configurazione da 32 GB, e i numeri pubblicati dai fornitori vi si oppongono: 110 GB sono la soglia della versione più piccola consigliata da Unsloth (documentazione Unsloth). ModemGuides arriva alla stessa conclusione dal lato hardware e indica le macchine da 128 GB come obiettivo realistico, rilevando che Apple propone il Mac Studio con M3 Ultra a 96 GB, il che colloca il candidato più ovvio appena sotto la soglia (analisi hardware).

Quantizzare ulteriormente resta una leva reale, ma smette di essere gratuita. La stessa analisi misura per le versioni di classe 2 bit una concordanza di circa il 78 per cento sul token più probabile rispetto ai pesi di riferimento. È una decisione di qualità, non di confezionamento, e appartiene alla fase di valutazione più che a quella di acquisto. Chi scambia precisione con memoria misuri lo scambio sui propri compiti: vale la stessa disciplina che si applica ogni volta che un harness di valutazione si frappone tra un modello e il suo punteggio.

Che cosa cambia nel dimensionamento

Per i modelli Mixture-of-Experts conviene dimensionare l'host a partire dal numero totale di parametri e dal formato di archiviazione del checkpoint, usando il numero di parametri attivi soltanto per prevedere il throughput.

Da questo calcolo discendono tre abitudini.

Leggere il formato di archiviazione prima del numero di parametri. expert_dtype dice più cose sul conto della memoria dei 284 miliardi in evidenza, perché si applica al 98 per cento dei parametri. Un modello con meno parametri complessivi, ma archiviato in BF16, può tranquillamente richiedere più memoria di questo.

Trattare i parametri attivi come una misura di throughput. Spiegano perché DeepSeek possa offrire V4-Flash a 0,14 dollari per milione di token in ingresso e 0,28 dollari per milione in uscita (prezzi dell'API). Non spiegano nulla di quanto pesino i pesi.

Separare la questione della licenza da quella dell'hardware. La licenza MIT su questi pesi è un risultato concreto, e una licenza open-weight chiarisce che cosa sia permesso fare. Non chiarisce che cosa si sia attrezzati a fare. Sono due vagli indipendenti, e il secondo lo decidono i numeri di questo articolo.

Le capacità all'origine dell'interesse sono reali. DeepSeek-V4-Flash-0731 ottiene 82,7 su Terminal Bench 2.1 contro 72,1 di DeepSeek-V4-Pro (Preview) e 54,4 su DeepSWE contro 7,3 della propria anteprima (scheda del modello). Simon Willison lo indica come forse il miglior rapporto fra intelligenza e costo disponibile e segnala che Artificial Analysis lo colloca davanti a MiniMax M3, un modello da 428 miliardi di parametri (blog). Nulla di tutto ciò modifica il conteggio dei byte, ed è quel conteggio che l'ordine di acquisto deve soddisfare.

È lo stesso schema descritto nel nostro articolo su come ARC-AGI-3 abbia misurato l'harness e non soltanto il modello: un numero si attacca a un modello quando in realtà nasce dalla configurazione che lo circonda. Qui il numero è 13 miliardi, la configurazione è un router 6 su 256, e ciò che viene misurato è la velocità, non la dimensione. Per chi soppesa questa classe di modelli contro una soluzione ospitata di fascia alta, il nostro confronto su DeepSeek V4 espone il compromesso nel dettaglio, e la voce configurazione di inferenza tratta le impostazioni che spostano il throughput una volta che i pesi sono residenti.

Se sta valutando se un modello di questa classe abbia un posto nel suo stack, e preferisce che il dimensionamento sia risolto prima dell'acquisto dell'hardware anziché dopo, il nostro team svolge esattamente questo tipo di valutazione.

Domande frequenti

Quanta memoria richiede realmente DeepSeek-V4-Flash? Metta in conto almeno 110 GB. La versione a 3 bit consigliata da Unsloth pesa 103 GB e prevede una soglia di 110 GB, poiché le dimensioni dei file escludono cache KV e allocazione del contesto. La piena precisione originale arriva a 162 GB (documentazione Unsloth).

Perché 13 miliardi di parametri attivi non significano 13 miliardi in memoria? Perché il router può scegliere qualsiasi gruppo di 6 esperti su 256 a ogni token, quindi tutti restano residenti. I parametri attivi governano il calcolo per token, il totale governa il conto della memoria (analisi hardware).

Che cosa cambia l'FP4 nella pratica? Gli esperti concentrano circa il 98 per cento dei parametri: archiviarli a mezzo byte anziché a un byte dimezza quasi l'occupazione residente. La ripartizione appartiene al checkpoint e non è una riquantizzazione successiva (ricette vLLM).

DeepSeek-V4-Flash ha 284 o 304 miliardi di parametri? Il rapporto tecnico indica 284 miliardi di parametri con 13 miliardi attivati, e la ricetta vLLM lo conferma. Valori più alti sono circolati in articoli secondari. Il checkpoint misura in ogni caso circa 167 GB su disco (rapporto tecnico).

Si può eseguire senza scheda grafica? Non abbiamo testato quella configurazione, e le dimensioni pubblicate sconsigliano una macchina da 32 GB. La versione più piccola consigliata richiede 110 GB di memoria di lavoro, il che indirizza verso sistemi da 128 GB anziché verso i portatili (analisi hardware).