DeepSeek-V4: un contesto da un milione di token che gli agenti possono realmente utilizzare

DeepSeek ha rilasciato oggi la sua nuova generazione di modelli, DeepSeek V4. Due checkpoint MoE (Mixture of Experts) sono stati resi disponibili sull'Hub: DeepSeek-V4-Pro, con un totale di 1.6T parametri e 49B attivi, e DeepSeek-V4-Flash, con un totale di 284B parametri e 13B attivi. Entrambi i modelli vantano una finestra di contesto di ben un milione di token. I numeri di benchmark sono competitivi, ma non raggiungono lo stato dell'arte (SOTA). Tuttavia, questo aspetto è secondario. La vera innovazione di DeepSeek V4 risiede nel modo in cui è stato progettato per supportare in modo efficiente lunghe finestre di contesto, posizionandosi così come uno dei migliori candidati per le attività basate su agenti.

L'attenzione principale è rivolta ai carichi di lavoro a lungo termine per gli agenti. Attualmente, l'esecuzione di un modello aperto di frontiera come agente tende a fallire in modi prevedibili: il modello si blocca, è necessario ripetere il prompt, la traccia supera il budget del contesto, la cache KV satura la GPU o i round-trip delle chiamate agli strumenti si degradano a metà di un compito lungo. V4 è stato costruito per risolvere questi fallimenti noti e indicare una nuova direzione per la comunità di sviluppatori.

Questo articolo copre tre aspetti fondamentali: le differenze architettoniche che rendono l'inferenza a contesto lungo economica, le decisioni di post-training specifiche per gli agenti che si aggiungono a tali innovazioni, e alcuni spunti tratti dal paper che aiutano a comprendere questi cambiamenti.

Efficienza del contesto lungo: capacità vs. performance

Una finestra di contesto di un milione di token rappresenta solo capacità, non automaticamente performance. La possibilità di utilizzare efficacemente questa capacità dipende dal costo di ogni passaggio forward a quella profondità. Per un agente che esegue una lunga traiettoria di utilizzo di strumenti (un compito SWE-bench, una sessione di navigazione multi-step, una sessione terminale con centinaia di comandi), ogni risultato dello strumento viene aggiunto al contesto, e ogni token successivo paga il costo completo dell'attenzione su tutto ciò che è venuto prima.

Due numeri sono cruciali in questo scenario: i FLOP di inferenza per singolo token e la dimensione della cache KV. Entrambi crescono con la lunghezza della sequenza. A un milione di token, DeepSeek-V4-Pro richiede solo il 27% dei FLOP di inferenza per singolo token rispetto a DeepSeek-V3.2, il che significa che funziona più velocemente sulla stessa hardware. Utilizza anche solo il 10% della memoria della cache KV. V4-Flash riduce ulteriormente questi numeri: solo il 10% dei FLOP e il 7% della cache KV.

Se confrontiamo la memoria della cache KV con un'architettura consolidata come la grouped query attention con 8 heads, archiviata nel consueto formato bfloat16, DeepSeek V4 richiede approssimativamente solo il 2% della dimensione della cache. Questo rende molto più facile la sua implementazione per la gestione di contesti molto ampi. La figura 1 illustra il confronto dei benchmark (a sinistra) e i FLOP per token e la cache KV accumulata in funzione della lunghezza della sequenza (a destra).

Innovazioni architettoniche per l'attenzione efficiente

Il guadagno in efficienza deriva dalla suddivisione dell'attenzione in due meccanismi e dalla loro alternanza tra i layer.

Compressed Sparse Attention (CSA)

La Compressed Sparse Attention (CSA) comprime le voci KV di 4 volte lungo la dimensione della sequenza utilizzando il pooling con gating softmax e un bias posizionale appreso. Un "lightning indexer" (FP4, multi-head dot product con scoring ReLU) seleziona i blocchi compressi top-k per ogni query. Questo meccanismo eredita l'idea della selezione sparsa dalla DeepSeek Sparse Attention di V3.2, ma la esegue su blocchi che sono già 4 volte più corti rispetto alla sequenza originale. Lo spazio di ricerca dell'indexer si riduce di conseguenza. La figura 3 mostra la CSA: il compressore collassa ogni 4 token in una singola voce KV compressa. Il lightning indexer seleziona i blocchi compressi top-k per query. Un ramo con finestra scorrevole gestisce i token non compressi più recenti.

Heavily Compressed Attention (HCA)

La Heavily Compressed Attention (HCA) comprime le voci KV di 128 volte e abbandona la selezione sparsa. Ogni query si attende densamente a ogni blocco compresso. La sequenza compressa è sufficientemente corta da rendere l'attenzione densa economica. La figura 4 illustra la HCA: un compressore più pesante (128x vs. 4x) seguito da attenzione densa sul flusso compresso, con lo stesso ramo a finestra scorrevole per la recency.

I layer si alternano tra CSA e HCA. Differenti layer gestiscono differenti pattern di attenzione, e imporre un unico meccanismo su tutti spreca capacità. Nello stack di 61 layer di V4-Pro, i layer 0-1 sono HCA, i layer 2-60 alternano CSA e HCA, e il blocco MTP (Multi-Track Processing) alla fine esegue solo l'attenzione a finestra scorrevole.

Entrambi i percorsi utilizzano l'archiviazione FP8 per la maggior parte delle voci KV e BF16 solo per le dimensioni RoPE. Il lightning indexer all'interno della CSA funziona in FP4. Queste scelte di archiviazione, combinate con i rapporti di compressione, producono la cifra del 2% per la cache KV. La figura 2 mostra l'architettura complessiva: i layer di attenzione si alternano tra CSA e HCA, i layer feed-forward utilizzano DeepSeekMoE, e le connessioni residuali sono sostituite da iper-connessioni a manifold vincolato (mHC).

Decisioni di post-training e infrastrutturali per gli agenti

L'attenzione efficiente su contesti lunghi è necessaria per i flussi di lavoro degli agenti, ma non sufficiente. Il paper descrive tre scelte di post-training e infrastruttura che mirano direttamente ai casi d'uso degli agenti.

Preservazione del ragionamento tra i turni

V3.2 manteneva le tracce di ragionamento attraverso i round di risultati degli strumenti, ma le scartava ogni volta che arrivava un nuovo messaggio utente. Per un agente che gestiva un singolo turno utente, questo andava bene. Per i flussi di lavoro multi-turno basati su agenti, dove l'utente invia un follow-up dopo che l'agente ha già concatenato diverse chiamate a strumenti, il modello perdeva il suo ragionamento accumulato e doveva ricostruire lo stato.

V4 preserva il contenuto del ragionamento attraverso i confini dei messaggi utente quando la conversazione contiene chiamate a strumenti. Il modello mantiene la cronologia completa del ragionamento attraverso tutti i round, inclusi i turni utente. Ciò consente una catena di pensiero coerente e cumulativa su compiti di agente a lungo orizzonte. Per l'uso conversazionale senza strumenti, il vecchio comportamento è preservato: il ragionamento viene svuotato a ogni turno per mantenere il contesto conciso. La figura 7 illustra il ragionamento con strumenti (in alto) che preserva il ragionamento attraverso tutti i turni, e il ragionamento senza strumenti (in basso) che scarta il ragionamento a ogni nuovo messaggio utente.

Nuovo formato per le chiamate agli strumenti

V4 introduce un token speciale |DSML| e un formato XML per le chiamate agli strumenti. Il formato XML riduce i fallimenti di escaping rispetto alle chiamate agli strumenti JSON-in-string, una modalità di fallimento comune quando i modelli emettono contenuti quotati nidificati. Lo schema separa i parametri stringa (passati così come sono con string="true") dai parametri strutturati (passati come JSON con string="false"). Questo elimina una classe di errori di parsing relativi a numeri e booleani che i formati di chiamata a strumenti JSON riscontrano regolarmente.

Infrastruttura per l'addestramento RL: DeepSeek Elastic Compute (DSec)

Il comportamento dell'agente è stato addestrato con l'apprendimento per rinforzo (RL) contro ambienti di strumenti reali. Il paper descrive l'infrastruttura di sandbox costruita a tale scopo. DeepSeek Elastic Compute (DSec) è una piattaforma Rust che espone quattro substrati di esecuzione dietro un singolo SDK Python: chiamate a funzioni, container, microVM (Firecracker) e VM complete (QEMU). Un singolo cluster esegue centinaia di migliaia di sandbox concorrenti.

Tre caratteristiche di DSec sono importanti per l'addestramento degli agenti:

• Caricamento rapido delle immagini tramite archiviazione 3FS stratificata (così i rollout RL non aspettano l'avvio del container).
• Replay della traiettoria sicuro da preemption (così i passi di addestramento interrotti riprendono senza rieseguire le chiamate agli strumenti).
• Un'API uniforme tra i substrati (così gli ambienti di addestramento possono mirare a chiamate di funzione o VM complete senza riscrivere il codice).

Queste decisioni infrastrutturali sono alla base dei punteggi di benchmark degli agenti.

Risultati dei benchmark

I numeri relativi alla conoscenza e al ragionamento sono competitivi ma non leader. I numeri degli agenti sono il punto in cui V4-Pro-Max si distingue nettamente dal resto del campo.

Numeri specifici dalla sezione "Agent" della tabella 6:

• Nel benchmark di codifica di ricerca e sviluppo interno del paper, che comprende 30 compiti curati su PyTorch, CUDA, Rust e C++, V4-Pro-Max raggiunge un tasso di superamento del 67%, contro il 47% per Sonnet 4.5 e il 70% per Opus 4.5.
• In un sondaggio condotto su 85 sviluppatori DeepSeek che utilizzano V4-Pro quotidianamente, il 52% ha affermato che era pronto a sostituire il loro attuale modello di codifica primario e il 39% si è mostrato propenso ad accettare.

I numeri di retrieval a contesto lungo sono presentati nella figura 9. La precisione MRCR 8-needle rimane sopra lo 0.82 fino a 256K token e si mantiene a 0.59 a 1M. Nello specifico, la figura 9 mostra che V4-Pro-Max rimane sopra lo 0.82 fino a 256K e si mantiene a 0.59 a 1M.

Checkpoint del modello e modalità di ragionamento

Quattro checkpoint sono disponibili sull'Hub. I modelli instruct utilizzano FP4 per i pesi degli esperti MoE e FP8 per tutto il resto. I modelli base sono interamente in FP8.

Entrambi i modelli instruct supportano tre modalità di ragionamento:

• Non-think: veloce, senza "chain of thought".
• Think High: ragionamento esplicito in blocchi <think>.
• Think Max: massimo sforzo di ragionamento con un prompt di sistema dedicato. Questa modalità richiede una finestra di contesto di almeno 384K token.

I parametri di campionamento raccomandati per tutte le modalità sono temperature=1.0 e top_p=1.0.

I numeri di V4-Pro su SWE Verified, MCPAtlas e il benchmark di ricerca e sviluppo interno lo pongono alla pari con i modelli chiusi di frontiera per i compiti degli agenti. La questione aperta è come le librerie di strumenti della comunità si adatteranno a |DSML|.