DeepSeek V4.1 Flash: 890 Byte di Cache KV per Token

DeepSeek rilascia V4.1-Flash, un modello multimodale MoE che riduce drasticamente il consumo della cache KV a soli 890 byte per token. Prestazioni ai vertici dei benchmark per agenti, costi contenuti e licenza MIT.

DeepSeek V4.1 Flash: 890 Byte di Cache KV per Token

Panoramica

Il 10 settembre 2026, DeepSeek ha rilasciato V4.1-Flash, il terzo modello della famiglia V4 — e con un messaggio molto chiaro: superare l'architettura Flash precedente simultaneamente in termini di qualità e costi. I numeri dimostrano esattamente questo. Con 552 miliardi di parametri di backbone e 196 miliardi di parametri Engram, il modello attiva per ogni token solo 8 miliardi in fase di prefill e 16 miliardi in fase di decode — con una finestra di contesto di un milione di token e un output massimo di 384.000 token. La cache KV globale scende a soli 890 byte per token. Il report tecnico porta un titolo azzeccatissimo: "Pushing the Limits of KV Cache Compression" (Spingendo i limiti della compressione della cache KV).

I pesi sono disponibili su Hugging Face con licenza MIT, e l'utilizzo è supportato tramite vLLM, SGLang e Transformers. I prezzi dell'API rimangono ai livelli del V4-Flash, con un modello tariffario basato su fasce orarie Peak/Off-Peak (di punta e non).

Cos'è il modello

V4.1-Flash è un modello multimodale Mixture-of-Experts (MoE). Elabora testo e immagini in modo nativo: un DeepSeek-ViT con 2D-RoPE e unshuffle dei pixel 3×3 fornisce embedding visivi che vengono appresi assieme al testo fin dalla primissima fase di pretraining. Per ogni livello MoE operano 1 esperto condiviso e 384 esperti con routing, di cui 6 sono attivi per token. Il livello di ragionamento (reasoning) è regolabile in modo continuo (tramite un intero da 1 a 100): un maggiore sforzo cognitivo porta a risultati sensibilmente migliori, ma richiede circa 2,5 volte il numero di token in output.

L'architettura: tre leve contro la cache

Il collo di bottiglia dei moderni sistemi basati su agenti raramente è la dimensione del modello, ma la cache KV: ogni livello di un Transformer classico mantiene le proprie coppie chiave-valore e, con contesti lunghi, questo accumulo cresce fino a raggiungere l'ordine dei gigabyte. DeepSeek interviene su tre fronti.

Primo: Causal Encoder-Decoder (CED). Il backbone a 40 livelli è diviso in 20 livelli di encoder e 20 livelli di decoder. Il decoder non calcola da sé la propria cache KV globale, ma la proietta a partire dagli stati nascosti finali dell'encoder. I token di prompt si fermano quindi nell'encoder: il carico computazionale in fase di prefill si dimezza circa, lasciando attivi solo 8 miliardi di parametri. La fonte d'ispirazione per questo meccanismo è YOCO.

Secondo: Compressed Sparse Attention 2 (CSA2). A ogni livello CSA2 viene assegnato staticamente uno dei tre seguenti modi: Full (KV principale proprio, indicizzatore proprio, nuovi indici Top-512), Reindex (KV principale esterno, rivalutazione propria) o Reuse (KV principale e indici interamente ereditati). I 18 livelli CSA2 dell'encoder comprimono con un rapporto di 2 in gruppi da sei, mentre i 20 livelli del decoder comprimono con un rapporto di 1 in gruppi da quattro. Un indicizzatore sparse gerarchico limita il pool di candidati a 16.384 posizioni, svincolando così il costo di indicizzazione dalla crescita lineare rispetto alla lunghezza del contesto. Tradotto in FLOPs per token di decode, il salto da 4K a 1M di contesto aumenta il costo computazionale di un solo quarto.

Terzo: FP4 e Bounded Replay. La cache KV principale viene quantizzata in E2M1 (una scala E4M3 ogni 16 canali), ispirandosi a NVFP4, dimezzandone di fatto il peso. Gli stati della sliding-window (finestra da 128 token) non finiscono più sull'SSD, ma nel pool della RAM host con un TTL di pochi minuti; in caso di fallimento (cache miss), la funzione "SWA Bounded Replay" ricompila esclusivamente gli ultimi 128 token. Risultato: l'impronta persistente della cache è di circa un ottavo rispetto al V4-Flash; a livello globale ci si attesta a 890 byte per token — circa 1/4 rispetto al V4-Flash e 437 volte più piccola del V1. Il report tecnico illustra la progressione: 389.120 → 48.068 → 3.514 → 890 byte.

Il resto del pacchetto è composto da moduli collaudati: mHC a singolo passaggio con coefficienti di input-mixing traslati e kernel Mega-mHC fuso, il modulo Engram per lookup basato su token nei livelli 1 e 14, nonché DSpark come decodifica speculativa (speculative decoding) con verifica guidata da confidence (confidence-scheduled verification).

Prestazioni in sintesi

Nel confronto di base, V4.1-Flash tiene testa al gigantesco V4-Pro, ma lo fa con un terzo dei parametri totali e un quarto di quelli attivi: MMLU-Pro 74,1 (Pro: 73,5), BigCodeBench 60,6 (59,2), GSM8K 93,0. Multimodalità nativa: DocVQA 95,6, CVBench 77,9, RefCOCO 86,0, MMMU-Pro 56,5.

Al livello massimo di reasoning nei benchmark per agenti (Fonte: Model Card):

BenchmarkV4.1-FlashV4-FlashOpus-5GPT-5.6 Sol
Terminal-Bench 2.190.682.789.188.8
DeepSWE v1.174.254.474.073.0
AutomationBench54.837.750.345.8
Agent's Last Exam31.826.7
CyberGym88.184.5
GPQA Diamond90.989.993.494.1

Inoltre: rating Codeforces di 3471 (V4-Pro: 3348), MathArena Apex a 65,6 come Kimi K3. Su ProgramBench e nella comprensione di immagini complesse, secondo il report, rimane un divario misurabile rispetto ai più grandi sistemi closed-source.

La gestione della fase di post-training è notevolmente sobria: nessun nuovo algoritmo, solo SFT → RL → On-Policy-Distillation impiegando oltre 40 modelli insegnanti (teacher models) e sfruttando ambienti agenti scalati e sintetizzati tramite scaffold come Claude Code, Codex, OpenCode, Pi, mini-SWE e DeepSeek Harness. DeepSeek attribuisce i notevoli guadagni prestazionali allo scaling dei dati e delle task — non ad alcun rivoluzionario aggiornamento algoritmico.

Prezzi e disponibilità

L'API offre V4.1-Flash alle medesime tariffe del V4-Flash, utilizzando fasce orarie Peak e Off-Peak; durante le ore di Off-Peak il costo si dimezza. Costi per milione di token (in fascia Off-Peak): $0,22 in input (cache miss), $0,007 in caso di cache hit, $0,66 in output — in fascia Peak i prezzi sono esattamente il doppio. Il Prefix-Caching automatico è attivo di default. Le nuove tariffe sono entrate in vigore dalle 04:00 UTC del 10 settembre 2026. Pesi: licenza MIT, disponibili su Hugging Face. Partner ufficiali come WorkBuddy (incluso CodeBuddy) e OpenCode supportano il modello nativamente sin dal primo giorno.

Cosa significa all'atto pratico

Per documenti lunghi e knowledge graph: La cache, ridotta di 437 volte per ogni token, rappresenta il vero salto evolutivo. Chi opera con contesti da 1M e frequenti chiamate di tool, potrà avviare molte più sessioni in parallelo per singola GPU, anziché dover sostituire o ampliare la flotta hardware.

Per le pipeline di agenti: L'attivazione asimmetrica (8B Prefill / 16B Decode) calza a pennello per pattern con un carico spostato sull'input — come grandi moli di codice sorgente o testi lunghi a fronte di output brevi e fortemente strutturati. L'asse a regolazione continua del reasoning (reasoning-effort) permette inoltre di bilanciare di volta in volta i costi e i benefici in ogni singolo step: livello basso per le impaginazioni o numerazioni, alto per i controlli incrociati severi, medio per i task generici.

Per l'operatività: In vLLM si usa il checkpoint misto FP4/FP8; vanno specificati i flag --tokenizer-mode deepseek_v4, --reasoning-parser deepseek_v4, e per l'utilizzo delle modalità Think un --max-model-len pari o superiore a 393.216. Emergono due consigli chiave dal forum Nvidia: un contesto di 32K rappresenta il valore di default più stabile in assoluto, mentre i 64K andrebbero impiegati esclusivamente per reale necessità (il carico sulla KV e la gestione delle richieste parallele mostrano un netto punto di flessione superata quella soglia).

Per il posizionamento di mercato: Con l'arrivo di questa generazione, i modelli open-weights non sono più valutati come "semplicemente ottimi in virtù del loro costo", bensì dominano apertamente in quattro su cinque dei più severi benchmark per agenti autonomi — il tutto offerto con licenza MIT. Permangono alcune lacune sulle query analitiche circa i dettagli finissimi delle immagini e su lunghe catene logico-deduttive di stampo prettamente scientifico; su queste due nicchie, V4-Pro (che attinge a ben 49B di parametri attivi) rimane ancora l'opzione più rassicurante.

Punti chiave

  1. CED delega la computazione del prompt all'encoder: 8B di parametri attivi nel prefill, 16B nel decode, mentre la KV del decoder è generata tramite proiezione.
  2. CSA2 + FP4 + Bounded Replay spingono la cache KV globale all'incredibile soglia di 890 byte per token: un valore pari a 1/4 rispetto al V4-Flash, 1/8 della precedente quota persistente, ben 437 volte inferiore rispetto all'originario V1.
  3. Benchmark alla mano: Terminal-Bench 2.1 segna 90,6 · DeepSWE v1.1 tocca 74,2 · AutomationBench va a 54,8 · CyberGym brilla a 88,1 — risultati impressionanti sotto pura licenza MIT.
  4. Messa in esercizio: pienamente compatibile con vLLM/SGLang/Transformers, Prefix-Caching automatico integrato, contesto a 32K suggerito come best-practice di default.

FAQ

V4.1-Flash è da considerarsi un sostituto totale del V4-Pro? Nei benchmark di programmazione incentrati sugli agenti sì, forte di netti vantaggi sia per i prezzi che per le velocità operative. Tuttavia, per fitte e lunghe catene di ragionamento prettamente scientifico o avanzate analisi visive, la model card conferma che persiste un margine a favore dei modelli più mastodontici.

Perché la cache KV costituisce il reale collo di bottiglia? Poiché ogni layer di un Transformer classico conserva le proprie accoppiate chiave-valore — un cuscino di dati che tende inevitabilmente a gonfiarsi in base alla lunghezza del contesto e al numero dei vari passaggi elaborativi vincolando criticamente HBM, SSD e banda passante.

Come posso modulare finemente il ragionamento? Attraverso la voce reasoning_effort impostabile con un valore integer da 1 a 100; spingersi sulla fascia massima accresce misurabilmente i risultati finali ma porta all'incirca a duplicare i token emessi in output.

Quant'è il vantaggio pratico in merito alla cache? Il footprint globale precipita in picchiata dagli originari 3.514 byte per token registrati col V4-Flash giù fino ad appena 890 — un drastico fattore di divisione per 4, distanziando persino il V1 di un fattore 437.

Qual è lo stack raccomandato per il serving? Risultano perfetti vLLM o SGLang accompagnati dal tokenizer e reasoning-parser settati su deepseek_v4; prediligere i checkpoint misti FP4/FP8; abilitare la logica Think ponendo cura all'attributo max-model-len ≥ 393.216.

Condividi articolo

Share: