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

DeepSeek V4 Preview non è solo un altro lancio da model card. È DeepSeek che prende posizione su una cosa molto precisa: la prossima gara del long-context non la vincerà chi dichiara la finestra più grande, ma chi riesce a renderla economica, stabile e abbastanza ordinaria da usarla ogni giorno.

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 sui servizi ufficiali DeepSeek. Questo è il titolo. Non è ancora la storia.

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

La superficie prodotto è semplice: deepseek-v4-pro e deepseek-v4-flash sono disponibili via API, entrambi supportano modalità Thinking e Non-Thinking, e i nomi legacy deepseek-chat e deepseek-reasoner spariranno dopo il 24 luglio 2026, 15:59 UTC. Gli open weights sono distribuiti tramite la collezione DeepSeek V4 su Hugging Face.

Questo articolo tratta V4 come una preview, non come un verdetto finale. Le fonti primarie sono la release note ufficiale, il technical report e la collezione Hugging Face di DeepSeek. I benchmark sono segnali utili, ma molti arrivano da valutazioni ufficiali o interne: la postura corretta è interesse, non fede. Va provato, misurato e confrontato sul proprio lavoro.

Cosa è cambiato dopo il lancio

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

• DeepSeek presenta V4 Preview come l'inizio del "cost-effective 1M context length", non semplicemente come un checkpoint più grande.
• La famiglia pubblica ha due punti operativi: V4-Pro per reasoning massimo e lavoro agentico, V4-Flash per produzione veloce ed economica.
• La migrazione API è volutamente piccola: mantieni lo stesso base_url, cambia il model ID in deepseek-v4-pro o deepseek-v4-flash.
• DeepSeek dichiara che entrambi i modelli supportano contesto da 1M token e modalità Thinking / Non-Thinking.
• Gli alias precedenti deepseek-chat e deepseek-reasoner sono route temporanee di compatibilità e verranno ritirati dopo il 24 luglio 2026, 15:59 UTC.

Quindi la domanda giusta non è più "DeepSeek ha un modello da 1M token?". Lo ha. La domanda giusta è se V4 rende quel contesto abbastanza economico e affidabile per agenti, grandi codebase, compliance review, analisi documentale lunga e sistemi production dove il costo dei prefissi ripetuti conta davvero.

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.

Questa frase conta perché evita la trappola classica dei lanci AI: "modello più grande, contesto più grande, punteggi migliori". Qui la parte interessante è l'insieme delle scelte:

• V4-Pro per reasoning difficile, coding agentico e workload long-context ad alto valore.
• V4-Flash per percorsi di produzione più 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 ottimizzazione Muon per stabilità e profondità.
• FP4/QAT e lavoro sul serving per rendere l'economia di deployment parte della storia del modello.
• 1M token come default di servizio, non come demo da laboratorio.

Se questa direzione regge nei deployment reali, cambia il modo in cui si progettano gli agenti. Più transcript può restare vivo. Più documenti possono rimanere nel working set. Più log, piani, pull request e riassunti di file possono restare accessibili senza ricostruire ogni volta un sistema retrieval su misura.

Non significa che il retrieval diventi inutile. Significa che cambia il suo ruolo.

La famiglia di modelli

V4-Pro è il modello di punta: 1.6T parametri totali, 49B parametri attivi. V4-Flash è il modello più orientato al serving: 284B parametri totali, 13B parametri attivi. Essendo entrambi mixture-of-experts, il numero di parametri attivi è più utile del numero totale per ragionare sul costo per token.

La separazione è intelligente. Un singolo checkpoint enorme crea una storia da benchmark. Una famiglia Pro/Flash crea una storia da deployment.

Pro è il modello da scegliere quando l'errore costa: reasoning multi-step, sessioni su codebase grandi, coding agentico, sintesi difficili, automazione ad alto valore e task long-context in cui la risposta dipende da collegamenti sottili dentro il prompt.

Flash è il modello da testare quando il workflow è frequente, sensibile alla latenza o sensibile al costo: estrazione, classificazione, coding assistance di routine, assistenti customer-facing e pipeline long-context protette da validator, test, schema o revisione umana.

Dal punto di vista architetturale, V4 mantiene la linea DeepSeek: DeepSeekMoE nei feed-forward layer e Multi-Token Prediction ereditato dalla famiglia V3. Il baricentro nuovo è altrove: attenzione long-context, routing del residual stream, scelta dell'ottimizzatore, quantizzazione orientata al deployment e riuso della cache.

La vera svolta è l'economia della KV cache

Il long-context ha sempre avuto un problema poco glamour: il conto arriva in compute e memoria.

Ogni token generato deve interagire con il prefisso. Ogni richiesta ha bisogno di una KV cache. Ogni workload con prefissi condivisi rischia di pagare lo stesso prefill ancora e ancora. 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 intercalati:

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

È un compromesso pratico. Un coding agent con tre ore di transcript non ha bisogno di attenzione full-resolution su ogni token dall'inizio della sessione. Ha bisogno di accesso preciso all'ultimo turno, accesso affidabile alle decisioni passate e abbastanza struttura per recuperare piani, riassunti di file, log e vincoli senza far collassare 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 guardare indietro.

CSA, HCA e la forma della memoria

CSA e HCA non sono semplicemente "sparse attention con nomi migliori". Codificano una teoria della memoria agentica.

Il contesto recente è fragile. Il modello ha bisogno di dettaglio locale esatto: la funzione corrente, l'ultimo output di un tool, l'ultima istruzione, il bug attivo. Comprimi troppo vicino al punto di generazione e l'agente inizia a fare errori piccoli ma costosi.

Il contesto vecchio è diverso. Di solito serve una rappresentazione recuperabile: cosa è stato deciso, quali file sono stati toccati, quali vincoli sono emersi, cosa ha fallito, quale piano resta. Quella storia può essere compressa, se il modello mantiene un modo per indirizzare l'attenzione verso i pezzi giusti.

Il design ibrido di V4 nasce attorno a questa distinzione. Tiene vicino il dettaglio locale, conserva la storia lunga in modo più economico e usa selezione sparsa per rendere raggiungibile il contesto distante.

Il report discute anche il riuso della KV cache su disco. Non è un dettaglio laterale. In produzione molte 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 possono essere salvate e riusate, il sistema evita di pagare sempre lo stesso prefill.

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

mHC e Muon: le parti silenziose della release

La storia dell'attenzione sarà quella più citata, ma V4 non è solo attenzione.

Prima cosa: DeepSeek introduce mHC, cioè Manifold-Constrained Hyper-Connections, come upgrade delle connessioni residuali convenzionali. I modelli profondi non sono solo una questione di numero di parametri; sono una questione di instradamento del segnale. Il residual stream deve trasportare informazione attraverso la profondità senza collassare nel rumore o perdere trasformazioni utili. mHC è il tentativo di DeepSeek di rendere quel percorso più stabile ed espressivo.

Seconda cosa: 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. Il report lo presenta come una scelta di convergenza e stabilità alla scala V4.

Insieme, queste scelte fanno sembrare V4 meno una patch alla finestra di contesto e più un redesign full-stack attorno a traiettorie di ragionamento lunghe. Il milione di token mette sotto stress tutto: attenzione, flusso residuale, comportamento dell'ottimizzatore, quantizzazione, gestione della cache, infrastruttura di serving e post-training.

Scala di training e modalità di ragionamento

DeepSeek riporta più di 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 più modalità di ragionamento.

Non è un dettaglio cosmetico. La modalità di ragionamento cambia il comportamento del prodotto.

Non-Think serve per risposte dirette e rapide. High è la modalità deliberata normale. Max è la modalità di ricerca della capacità, dove il modello può spendere più budget di ragionamento e anche il setup di valutazione cambia.

Quindi "V4" non è una cosa sola nella pratica. 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 nominare 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 e competitivo con sistemi frontier chiusi su valutazioni selezionate di reasoning, coding, long-context e agentic.

I risultati long-context sono quelli 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 attesa: Flash è molto forte per il suo budget di parametri attivi, ma Pro resta la scelta più prudente quando il task dipende da retrieval sottile e sintesi su un prompt enorme.

Il grafico comparativo sopra usa la Table 6 del report DeepSeek, non lo screenshot YouTube, perché 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 la separazione è più evidente. Terminal Bench 2.0 è riportato a 67.9 per Pro Max e 56.9 per Flash Max. SWE Verified è più vicino: 80.6 contro 79.0.

La mia lettura: Flash è il modello prodotto più sorprendente. Pro è quello che sceglierei per primo quando il task è ambiguo, ad alto valore, lungo o difficile da verificare.

Cosa dovrebbero fare gli sviluppatori

La migrazione API è 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"

La release note dice anche che l'API supporta OpenAI Chat Completions e Anthropic APIs. Questo rende V4 facile da provare dentro agenti esistenti, tool IDE, sistemi retrieval, harness di valutazione e servizi backend.

La parte urgente è la timeline di retirement. 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 da qualche parte, migrali ora. Non aspettare la settimana dello shutdown.

Per valutarlo, userei quattro tracce:

| Traccia | Cosa misurare | | --- | --- | | Retrieval long-context | Trova i fatti giusti dentro documenti reali e disordinati, non solo benchmark needle? | | Coding agentico | Mantiene piani, edit, test e tool trace coerenti su sessioni lunghe? | | Costo e latenza | Cosa succede a 50K, 200K, 500K e 1M token con output realistici? | | 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 brevi. Ma non assumere nemmeno che una finestra da un milione significhi "incolla tutto". Il vantaggio è l'opzionalità: il sistema può portare più contesto quando il workflow ne beneficia davvero.

Limiti e cautele

Questa resta una preview, e questo deve influenzare l'adozione.

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

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

La distinzione conta. I team che ne trarranno più vantaggio non saranno quelli che incollano il prompt più grande. Saranno quelli che progettano il workspace long-running più pulito: file strutturati, piani espliciti, sintesi compatte, tool trace stabili e riuso della cache misurato.

Valutazione pratica

DeepSeek V4 Preview va letto come una release di efficienza vestita da release frontier. Le dimensioni dei modelli sono grandi, ma l'argomento importante è economico: rendere meno esotico il contesto estremo.

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

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

L'etichetta preview è reale. La replicazione indipendente conta ancora. 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.

È il problema giusto da risolvere.

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