DeepSeek V4 Preview: il contesto da un milione di token come problema di efficienza

DeepSeek V4 Preview non e' un aggiornamento minore di model card. Il 24 aprile 2026 DeepSeek ha annunciato due modelli preview open-weight, DeepSeek-V4-Pro e DeepSeek-V4-Flash, con una promessa comune: contesto da un milione di token su tutti i servizi ufficiali DeepSeek.

Quel numero e' facile da leggere male. Il punto importante non e' soltanto che la finestra di contesto sia grande. Una finestra enorme serve a poco se ogni richiesta diventa un evento di compute e memoria sostenibile solo da un laboratorio. La tesi centrale del technical report e' che V4 modifica la curva dei costi dell'inferenza long-context.

La release note definisce la superficie prodotto: deepseek-v4-pro e deepseek-v4-flash sono disponibili via API, entrambi supportano 1M token e modalita' Thinking / Non-Thinking, e i vecchi nomi deepseek-chat e deepseek-reasoner saranno ritirati dopo il 24 luglio 2026, 15:59 UTC. La collezione DeepSeek V4 su Hugging Face e' il punto di distribuzione degli open weights.

Questo articolo tratta la release come preview, non come verdetto finale. Le affermazioni sotto sono basate sulla release note e sul report DeepSeek, salvo dove indicato diversamente. I benchmark sono segnali utili, ma molti sono ufficiali o interni, quindi la replicazione indipendente resta necessaria.

La famiglia di modelli

V4-Pro e' il modello principale: 1.6T parametri totali, 49B parametri attivi. V4-Flash e' il modello economico: 284B parametri totali, 13B parametri attivi. Entrambi sono modelli MoE, quindi il numero di parametri attivi e' piu' rilevante per il costo per token rispetto al numero totale.

La coppia e' piu' interessante di un singolo checkpoint frontier. Pro e' posizionato per ragionamento difficile, agentic coding, conoscenza e lavoro long-context. Flash prova a preservare una parte significativa di quel comportamento a un costo di serving inferiore.

L'architettura mantiene la linea DeepSeek: DeepSeekMoE per i feed-forward layer e Multi-Token Prediction dalla famiglia V3. Le novita' sono il design dell'attenzione long-context, il cambio residuale mHC e lo stack di training e serving attorno a questi elementi.

La vera storia: compressione della KV cache

L'attenzione vanilla diventa costosa a contesti estremi perche' ogni nuovo token deve leggere un prefisso enorme, e il servizio deve mantenere disponibile una grande key-value cache. Una finestra da 1M token ha quindi due colli di bottiglia separati:

• Compute: il costo di leggere e pesare il contesto precedente per ogni token generato.
• Memoria: la KV cache accumulata che deve restare disponibile durante la generazione.
• Riuso nel serving: il costo di prefilling ripetuto quando molte richieste condividono lunghi prefissi.

La risposta di DeepSeek e' l'attenzione ibrida. Il report descrive Compressed Sparse Attention (CSA) e Heavily Compressed Attention (HCA) come meccanismi intercalati. CSA comprime le entry KV e seleziona blocchi compressi sparsi per l'attenzione. HCA comprime in modo piu' aggressivo. Entrambi mantengono un ramo sliding-window per il dettaglio locale.

Questo spiega perche' la release note dice che 1M token e' ora lo standard nei servizi ufficiali DeepSeek. Il claim non e' "possiamo tecnicamente far entrare un milione di token una volta". E' "architettura e serving rendono un milione di token abbastanza ordinario da esporlo come capacita' standard".

CSA, HCA e il compromesso dell'attenzione

CSA e HCA non sono solo etichette per sparsity. Codificano un compromesso specifico: rappresentare la storia lunga in forma compressa, recuperare abbastanza accesso mirato tramite selezione sparsa e mantenere i token recenti non compressi con una sliding window.

L'intuizione pratica:

• CSA e' il percorso compresso a fedelta' piu' alta. Comprime gruppi di entry KV e usa un indexer per selezionare le entry compresse rilevanti.
• HCA e' il percorso a compressione piu' forte. Riduce memoria e compute dove il modello puo' tollerare un accesso storico piu' grossolano.
• Sliding-window attention conserva il dettaglio locale, importante perche' la compressione e' piu' rischiosa vicino al punto corrente di generazione.

E' un compromesso sensato per workflow agentici e di ricerca. Un coding agent con una trascrizione enorme non ha sempre bisogno di attenzione a piena risoluzione su ogni token dall'inizio della sessione. Spesso ha bisogno di contesto recente preciso piu' accesso recuperabile a decisioni, log, piani e sintesi precedenti.

Il report discute anche la KV cache su disco. Per richieste con prefisso condiviso, le entry CSA/HCA compresse possono essere salvate e riusate, mentre le entry sliding-window, piu' grandi, richiedono strategie separate. In produzione conta perche' i sistemi long-context sono spesso limitati dal prefill ripetuto, non solo dal passaggio finale di generazione.

mHC e Muon: non solo attenzione

Il report presenta V4 come una combinazione di architettura, ottimizzazione e infrastruttura. Due upgrade spiccano oltre l'attenzione.

Primo, mHC, o Manifold-Constrained Hyper-Connections, aggiorna le connessioni residuali convenzionali. Gli stack residuali profondi non sono solo un problema di capacita'; sono un problema di instradamento del segnale. mHC e' il tentativo di DeepSeek di rendere il residual stream piu' stabile ed espressivo mentre il modello diventa piu' profondo.

Secondo, DeepSeek usa l'ottimizzatore Muon per la maggior parte dei parametri, mantenendo AdamW per moduli selezionati come embedding, output head, moduli mHC e pesi RMSNorm. L'obiettivo dichiarato e' convergenza piu' rapida e stabilita' su scala V4.

Questi dettagli contano perche' rendono V4 meno simile a "V3.2 con contesto piu' grande" e piu' simile a un redesign di sistema attorno a traiettorie di ragionamento lunghe.

Scala di training e modalita' di post-training

DeepSeek riporta oltre 32T token di pre-training per la serie: Flash su 32T token e Pro su 33T token. La lunghezza di sequenza durante il training viene estesa progressivamente attraverso 16K, 64K e 1M.

Dopo il pre-training, entrambi i modelli vengono post-addestrati in piu' modalita' di ragionamento.

Il design delle modalita' e' pratico. Non-Think serve per risposte dirette e veloci. High e' la modalita' deliberata normale. Max e' la modalita' di ricerca della capacita', dove DeepSeek modifica prompt e incentivi di training per consentire al modello di spendere piu' budget di ragionamento.

Questo crea anche una trappola di misurazione: confrontare "V4" senza specificare la modalita' non e' preciso. Un'applicazione production che usa Flash Non-Think e un benchmark che usa Pro Max stanno usando punti diversi della stessa curva di famiglia.

Benchmark: utili, ma non definitivi

Il report presenta V4-Pro-Max come il modello open piu' forte in diverse categorie e competitivo con i migliori modelli closed in valutazioni selezionate di reasoning, coding, long-context e agentic. I numeri long-context piu' importanti sono MRCR 1M e CorpusQA 1M, dove Pro Max riporta rispettivamente 83.5 e 62.0, davanti a Flash Max.

Il grafico comparativo sopra usa la Table 6 del report DeepSeek, non lo screenshot YouTube, perche' quei valori sono tracciabili al technical report. Confronta DeepSeek-V4-Pro-Max con Claude Opus 4.6 Max, GPT-5.4 xHigh e Gemini-3.1-Pro High sui benchmark in cui il report elenca tutti e quattro i valori.

Sul lavoro agentico, il divario tra Pro e Flash e' piu' chiaro. Su Terminal Bench 2.0, Pro Max e' riportato a 67.9 mentre Flash Max e' a 56.9. Su SWE Verified, il gap e' piu' piccolo: 80.6 contro 79.0.

La mia lettura: Flash sembra insolitamente forte per il suo budget di parametri attivi, ma Pro resta il default piu' prudente per task in cui gli errori sono costosi, multi-step o difficili da rilevare.

Cosa cambia per gli sviluppatori

La superficie di migrazione API e' volutamente piccola. DeepSeek dice di mantenere lo stesso base_url e aggiornare il nome del modello:

const model = "deepseek-v4-pro"; // oppure "deepseek-v4-flash"

Anche il claim di compatibilita' e' ampio: la release note dice che l'API supporta OpenAI Chat Completions e Anthropic APIs. Questo rende V4 facile da provare in toolchain esistenti, soprattutto coding agent e sistemi retrieval-heavy.

La nota di retirement e' piu' urgente. deepseek-chat e deepseek-reasoner oggi vengono instradati verso V4-Flash non-thinking/thinking, ma DeepSeek dice che diventeranno inaccessibili dopo il 24 luglio 2026, 15:59 UTC. Se quei nomi sono hard-coded in un'applicazione, vanno migrati prima di quella data.

Limiti

La release e' ancora una preview. Questo deve influenzare la valutazione dei team.

• I claim piu' forti sono claim ufficiali DeepSeek, non repliche indipendenti.
• Molti benchmark arrivano dal framework di valutazione interno di DeepSeek.
• La storia pubblica attuale e' text-first; non e' una release multimodale.
• Il contesto da un milione di token non elimina retrieval, summarization o memory design. Cambia lo spazio dei compromessi.
• Costo e latenza vanno misurati su prompt reali, perche' modalita' di ragionamento, lunghezza dell'output e riuso della cache possono dominare il prezzo headline.

C'e' anche una questione di valutazione sul long context. Superare un benchmark retrieval da 1M token non equivale a ragionare in modo affidabile su un milione di token di documenti, log, codice e tool trace disordinati. V4 rende quel workload piu' plausibile. Non lo rende risolto.

Valutazione pratica

DeepSeek V4 Preview va letto come una release di efficienza travestita da release frontier. I parametri sono tanti, ma la storia architetturale riguarda il rendere utilizzabili economicamente i contesti lunghi.

Usa V4-Pro quando il task e' difficile da verificare, agentico, pesante sul ragionamento o davvero long-context: sessioni su grandi codebase, analisi multi-documento, pianificazione complessa e automazione ad alto valore.

Usa V4-Flash quando costo e latenza dominano e il task puo' tollerare un modello piu' piccolo: assistenti production, classificazione long-context, estrazione strutturata, aiuto coding di routine e workflow in cui puoi aggiungere validator attorno al modello.

Lo status di preview conta, ma la direzione e' chiara. Se il 2024 e il 2025 hanno riguardato finestre di contesto piu' grandi, V4 scommette che il 2026 riguardera' renderle abbastanza economiche da usarle ogni giorno.

Fonti: release note DeepSeek, technical report DeepSeek V4, collezione DeepSeek V4 su Hugging Face e la discussione YouTube come contesto di supporto.