DeepSeek V4 Preview: il modello da 1M token che rende economico il long context

DeepSeek V4 Preview non è l'ennesimo lancio da model card. È DeepSeek che prende posizione su una cosa precisa: la prossima gara del long context non la vincerà chi dichiara la finestra più grande, ma chi la rende abbastanza economica, stabile e — soprattutto — abbastanza noiosa da poterla usare tutti i giorni.

Il 24 aprile 2026 DeepSeek ha annunciato due modelli preview open-weight, DeepSeek-V4-Pro e DeepSeek-V4-Flash. Entrambi espongono una finestra da un milione di token su tutti i servizi ufficiali. Questo è il titolo dell'annuncio. La storia, però, è un'altra.

La storia è il costo. Un milione di token non serve a niente se ogni richiesta si comporta come un esperimento da laboratorio. Una finestra lunga diventa una capacità di prodotto solo nel momento in cui prefill, compute dell'attenzione, memoria della KV cache e serving ripetuto smettono di esplodere tutti insieme. E il technical report inquadra V4 esattamente così: una release di architettura e di sistemi costruita attorno all'intelligenza efficiente su contesti da un milione di token.

Lato prodotto, le cose sono semplici: deepseek-v4-pro e deepseek-v4-flash sono già disponibili via API, entrambi in modalità Thinking e Non-Thinking, e i nomi storici deepseek-chat e deepseek-reasoner spariranno dopo il 24 luglio 2026, 15:59 UTC. Gli open weights passano dalla collezione DeepSeek V4 su Hugging Face.

Un'avvertenza prima di cominciare: questo articolo tratta V4 per quello che è, una preview, non un verdetto. Le fonti primarie sono la release note ufficiale, il technical report e la collezione Hugging Face. I benchmark sono segnali utili, ma quasi tutti arrivano da valutazioni ufficiali o interne — quindi l'atteggiamento giusto è interesse con disciplina: provarlo, misurarlo, e non delegare il giudizio a un grafico di lancio.

Cosa è cambiato dopo il lancio

Al 27 aprile 2026 il quadro ufficiale è abbastanza nitido da separare i fatti solidi dal rumore del launch day:

• DeepSeek presenta V4 Preview come l'inizio del "cost-effective 1M context length", non come un semplice checkpoint più grosso.
• La famiglia pubblica ha due tagli: V4-Pro per il reasoning spinto e il lavoro agentico, V4-Flash per la produzione veloce ed economica.
• La migrazione API è volutamente minima: stesso base_url, cambia solo il model ID in deepseek-v4-pro o deepseek-v4-flash.
• DeepSeek dichiara che entrambi i modelli reggono il contesto da 1M token in entrambe le modalità, Thinking e Non-Thinking.
• I vecchi alias deepseek-chat e deepseek-reasoner sono scorciatoie di compatibilità a tempo: verranno ritirati dopo il 24 luglio 2026, 15:59 UTC.

La domanda giusta, quindi, non è più "DeepSeek ha un modello da un milione di token?". Ce l'ha. La domanda giusta è se V4 rende quel contesto abbastanza economico e affidabile per agenti, codebase enormi, compliance review, analisi di documenti lunghi e sistemi in produzione dove il costo dei prefissi ripetuti si sente davvero in bolletta.

La release in una frase

DeepSeek V4 è una famiglia MoE a due modelli progettata per rendere meno assurdo il costo dell'inferenza su un milione di token.

Vale la pena tenersi stretta questa frase, perché evita la trappola classica dei lanci AI: "modello più grande, contesto più grande, punteggi migliori". Qui la parte interessante è l'insieme coordinato delle scelte:

• V4-Pro per il reasoning difficile, il coding agentico e i workload long-context ad alto valore.
• V4-Flash per i percorsi di produzione economici che hanno comunque bisogno di contesti seri.
• Attenzione ibrida CSA/HCA per comprimere la storia lunga invece di guardare tutto a piena risoluzione.
• Connessioni residuali mHC e ottimizzatore Muon per stabilità e profondità in training.
• FP4/QAT e lavoro sul serving, perché l'economia del deployment è parte del progetto, non un dettaglio a valle.
• 1M token come default di servizio, non come demo da conferenza.

Se questa direzione regge nei deployment reali, cambia il modo stesso di progettare gli agenti. Più transcript può restare vivo. Più documenti possono abitare nel working set. Più log, piani, pull request e riassunti di file restano a portata di attenzione senza dover ricostruire ogni volta un impianto di retrieval su misura.

Non vuol dire che il retrieval vada in pensione. Vuol dire che gli cambia il mestiere.

La famiglia di modelli

V4-Pro è il modello di punta: 1.6T parametri totali, 49B attivi. V4-Flash è quello pensato per il serving: 284B totali, 13B attivi. Sono entrambi mixture-of-experts, quindi per ragionare sul costo per token il numero che conta è quello dei parametri attivi, non il totale da copertina.

La separazione in due tagli è la mossa intelligente. Un singolo checkpoint enorme produce una storia da benchmark. Una famiglia Pro/Flash produce una storia da deployment.

Pro è il modello da scegliere quando sbagliare costa: reasoning multi-step, sessioni su codebase grandi, coding agentico, sintesi difficili, automazioni ad alto valore, e tutti i task long-context dove la risposta dipende da collegamenti sottili sparsi nel prompt.

Flash è quello da mettere alla prova quando il workflow è frequente, sensibile alla latenza o al costo: estrazione, classificazione, assistenza al coding di routine, assistenti rivolti al cliente, e pipeline long-context protette da validator, test, schema o revisione umana.

Sul piano architetturale, V4 resta in famiglia: DeepSeekMoE nei feed-forward layer e Multi-Token Prediction ereditata dalla linea V3. Il baricentro nuovo sta altrove — attenzione long-context, instradamento del residual stream, scelta dell'ottimizzatore, quantizzazione pensata per il deployment, riuso della cache.

La vera svolta è l'economia della KV cache

Il long context ha da sempre un problema poco fotogenico: il conto arriva in compute e in memoria.

Ogni token generato deve fare i conti con tutto il prefisso. Ogni richiesta ha bisogno della sua KV cache. Ogni workload con prefissi condivisi rischia di ripagare lo stesso prefill all'infinito. Quando il prompt passa da migliaia a centinaia di migliaia di token, il problema di sistema diventa più importante del numero sulla slide.

La risposta di DeepSeek è l'attenzione ibrida. Il report descrive due meccanismi che si alternano:

• Compressed Sparse Attention (CSA) comprime le entry della KV cache e seleziona i blocchi compressi rilevanti.
• Heavily Compressed Attention (HCA) comprime in modo più aggressivo dove basta un accesso più grossolano.
• Un ramo di sliding-window attention tiene il contesto recente ad alta risoluzione.

È un compromesso pratico, e si vede. Un coding agent con tre ore di sessione alle spalle non ha bisogno di attenzione a piena risoluzione su ogni token dall'inizio. Gli serve precisione chirurgica sull'ultimo turno, accesso affidabile alle decisioni prese, e abbastanza struttura per ripescare piani, riassunti di file, log e vincoli senza mettere in ginocchio lo stack di serving.

Ecco perché la compressione della KV cache conta più del numero grezzo di token. Una finestra da un milione è utile solo se il modello può permettersi di guardarsi indietro.

CSA, HCA e la forma della memoria

CSA e HCA non sono "sparse attention con un nome più elegante". Dentro c'è una vera e propria teoria della memoria agentica.

Il contesto recente è fragile. Al modello serve il dettaglio locale esatto: la funzione su cui sta lavorando, l'ultimo output di un tool, l'ultima istruzione, il bug aperto. Comprimilo troppo e l'agente comincia a fare errori piccoli ma costosi.

Il contesto vecchio è un'altra cosa. Lì di solito basta una rappresentazione recuperabile: cosa è stato deciso, quali file sono stati toccati, quali vincoli sono emersi, cosa è fallito, che piano resta in piedi. Quella storia si può comprimere — a patto che il modello conservi un modo per puntare l'attenzione sui pezzi giusti al momento giusto.

Il design ibrido di V4 è costruito esattamente attorno a questa distinzione: dettaglio locale a portata di mano, storia lunga conservata a basso costo, selezione sparsa per rendere raggiungibile il contesto lontano.

Il report parla anche di riuso della KV cache su disco, e non è una nota a margine. In produzione moltissime richieste long-context condividono prefissi: corpora di documentazione, snapshot di repository, manuali di policy, log, conversazioni lunghe, workspace agentici. Se le entry CSA/HCA compresse si possono salvare e riusare, il sistema smette di pagare lo stesso prefill a ogni giro.

È la differenza tra "il modello supporta 1M token" e "il prodotto può permettersi 1M token".

mHC e Muon: le parti silenziose della release

L'attenzione si prenderà tutti i riflettori, ma V4 non è solo attenzione.

La prima novità silenziosa è mHC — Manifold-Constrained Hyper-Connections — un upgrade delle connessioni residuali classiche. I modelli profondi non sono solo una questione di parametri: sono una questione di instradamento del segnale. Il residual stream deve trasportare informazione attraverso la profondità senza collassare nel rumore e senza perdere per strada le trasformazioni utili. mHC è il tentativo di DeepSeek di rendere quel percorso più stabile ed espressivo.

La seconda è la scelta dell'ottimizzatore: Muon per la maggior parte dei parametri, AdamW per i moduli selezionati — embedding, output head, gli stessi moduli mHC, i pesi RMSNorm. Il report la presenta come una decisione di convergenza e stabilità alla scala di V4.

Messe insieme, queste scelte fanno sembrare V4 meno una patch alla finestra di contesto e più un redesign completo attorno a traiettorie di ragionamento lunghe. Il milione di token mette sotto stress tutto quanto: attenzione, flusso residuale, ottimizzatore, quantizzazione, gestione della cache, infrastruttura di serving, post-training. O tieni insieme tutto, o non tieni niente.

Scala di training e modalità di ragionamento

DeepSeek riporta oltre 32T token di pre-training per la serie: 32T per Flash, 33T per Pro. La lunghezza di sequenza cresce per gradi durante il training: 16K, poi 64K, poi 1M.

Dopo il pre-training, entrambi i modelli vengono post-addestrati su più modalità di ragionamento.

E non è cosmesi: la modalità di ragionamento cambia il comportamento del prodotto.

Non-Think è per le risposte dirette e rapide. High è la modalità deliberata di tutti i giorni. Max è quella con cui si va a caccia del punteggio: il modello può spendere più budget di ragionamento, e cambia anche il setup di valutazione.

Il che significa che "V4", nella pratica, non è una cosa sola. V4-Flash Non-Think dentro un prodotto ad alto volume e V4-Pro Max dentro un benchmark sono due punti diversi della stessa curva. Una valutazione seria deve dichiarare modello, modalità, dimensione del contesto, budget di output, latenza e condizioni di cache.

Altrimenti il confronto è teatro.

Benchmark: segnali buoni, non vangelo

Il report presenta V4-Pro-Max come uno dei modelli open più forti in diverse categorie, competitivo con i sistemi frontier chiusi su valutazioni selezionate di reasoning, coding, long context e lavoro agentico.

I risultati long-context sono i più rilevanti per il claim architetturale. Su MRCR 1M e CorpusQA 1M, Pro Max riporta rispettivamente 83.5 e 62.0, sopra Flash Max. È la gerarchia che ti aspetti: Flash rende moltissimo per il suo budget di parametri attivi, ma Pro resta la scelta prudente quando il task dipende da retrieval sottile e sintesi su un prompt enorme.

Il grafico comparativo qui sopra usa la Table 6 del report DeepSeek, non lo screenshot che gira su YouTube, perché quei valori sono tracciabili alla fonte. 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 la forbice si allarga. Terminal Bench 2.0: 67.9 per Pro Max, 56.9 per Flash Max. SWE Verified è più combattuto: 80.6 contro 79.0.

La mia lettura: Flash è il modello-prodotto che sorprende. Pro è quello a cui affiderei per primo i task ambigui, ad alto valore, lunghi o difficili da verificare.

Cosa dovrebbero fare gli sviluppatori

La migrazione API è volutamente piccola. DeepSeek dice di tenere lo stesso base_url e aggiornare solo il nome del modello:

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

La release note aggiunge che l'API supporta sia OpenAI Chat Completions sia le Anthropic APIs — il che rende V4 facilissimo da infilare in agenti esistenti, tool per IDE, sistemi di retrieval, harness di valutazione e servizi backend.

La parte urgente è la scadenza. Oggi deepseek-chat e deepseek-reasoner instradano 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 da qualche parte nel tuo codice, migrali adesso. Non ridurti alla settimana dello shutdown.

Per la valutazione, io partirei da quattro tracce:

| Traccia | Cosa misurare | | --- | --- | | Retrieval long-context | Trova i fatti giusti dentro documenti veri e disordinati, non solo dentro i needle dei benchmark? | | Coding agentico | Tiene insieme piani, edit, test e tool trace su sessioni lunghe? | | Costo e latenza | Cosa succede a 50K, 200K, 500K e 1M token con output di lunghezza realistica? | | Riuso della cache | I workload con prefissi condivisi diventano davvero più economici nel tuo serving path? |

Non valutare un modello da un milione di token solo su prompt corti. Ma non concludere nemmeno che una finestra da un milione significhi "incollaci dentro tutto". Il vantaggio vero è l'opzionalità: il sistema può portarsi dietro più contesto quando il workflow ne beneficia davvero.

Limiti e cautele

Resta una preview, e l'adozione dovrebbe tenerne conto.

• I claim prestazionali più forti sono claim di DeepSeek, non repliche indipendenti.
• Molti benchmark escono dal framework di valutazione interno.
• Lo scope pubblico attuale è text-first: questa non è una release multimodale.
• Una finestra da 1M token non manda in pensione retrieval, summarization, memory design o una buona gestione dello stato agentico.
• Il costo reale dipende da modalità di ragionamento, lunghezza dell'output, riuso dei prefissi, comportamento della cache e target di latenza.
• Superare i benchmark long-context non garantisce di ragionare bene su repository, log, ticket, PDF e tool trace caotici del mondo vero.

V4 rende i workflow da un milione di token più plausibili. Non li rende risolti.

E la distinzione pesa. I team che ne caveranno di più non saranno quelli che incollano il prompt più lungo, ma quelli che progettano il workspace long-running più pulito: file strutturati, piani espliciti, sintesi compatte, tool trace stabili, riuso della cache misurato sul serio.

Valutazione pratica

DeepSeek V4 Preview va letto come una release di efficienza vestita da release frontier. I modelli sono grandi, certo, ma l'argomento che conta è economico: rendere il contesto estremo meno esotico.

Usa V4-Pro per il lavoro dove una risposta sbagliata costa: reasoning profondo, sintesi multi-documento, sessioni su codebase enormi, agenti long-running, pianificazione complessa, automazione ad alto valore.

Usa V4-Flash dove conta il throughput e il workflow ha i suoi guardrail: assistenti in produzione, estrazione strutturata, classificazione, aiuto al coding di routine, customer support, pipeline long-context protette da validator o revisione umana.

La targhetta preview non è di facciata: la replica indipendente conta ancora, eccome. Ma la direzione è difficile da ignorare. Il 2024 e il 2025 hanno allargato le finestre di contesto. V4 scommette che il 2026 servirà a renderle economicamente utilizzabili.

Ed è il problema giusto su cui scommettere.

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