DeepSeek V4.1 Flash: prezzi API bassi, pesi aperti enormi

DeepSeek V4.1 Flash combina prezzi API bassi con un modello a pesi aperti molto grande. Uscito il 10 settembre 2026, attiva 8 miliardi di parametri nell’elaborazione dell’input e 16 miliardi nella generazione dell’output, ma la sola rete principale ne contiene 552 miliardi. Il miglioramento riguarda il carico di calcolo delle singole fasi, non un piccolo download per il portatile. [1] [2]

Che cosa significa davvero «8B attivi»?

Il numero di parametri attivi descrive la parte del modello utilizzata per un token, non l’intero modello da conservare. V4.1 Flash è un modello mixture-of-experts, che seleziona parti della rete per eseguire i calcoli. La nuova architettura di DeepSeek separa inoltre l’elaborazione dell’input dalla generazione dell’output, assegnando alle due fasi quantità attive diverse. [2]

L’elaborazione dell’input viene solitamente chiamata prefill: il modello legge il prompt prima di rispondere. La generazione dell’output è il decode: produce token in sequenza. Il rapporto tecnico di DeepSeek descrive un’architettura encoder-decoder causale con 20 strati per ciascuna parte. I valori dichiarati sono 8B parametri attivi nel prefill e 16B nel decode; B indica qui i miliardi. [2]

Per questo fare la media e parlare di «un modello da 12B» sarebbe fuorviante. Un prompt lungo con una risposta breve distribuisce il lavoro diversamente da un input corto seguito da una grande patch. L’architettura assegna calcoli diversi a queste fasi, ma nessuna rende il modello completo un checkpoint piccolo per hardware domestico.

La suddivisione dello spazio occupato lo rende evidente. DeepSeek dichiara una rete principale da 552B più circa 196B di memoria condizionale Engram, un componente di consultazione. La configurazione di deploy del progetto vLLM conta anche il modello di generazione di bozze DSpark e altri tensori. Il pacchetto completo su Hugging Face mostra attualmente 763B parametri. Sono conteggi di parti diverse della stessa release. [2] [3]

La discussione del lancio su r/LocalLLaMA, il 10 settembre, affiancava all’entusiasmo domande su architettura e deploy. È questo il punto interessante: il modello può calcolare in modo selettivo e restare enorme da ospitare. [5]

Perché conta una cache del contesto più piccola?

Una cache più piccola riduce uno dei costi di memoria delle conversazioni lunghe. La cache KV conserva informazioni di attenzione dei token già elaborati per riutilizzarle durante la generazione. Questa memoria è distinta da quella necessaria a conservare i pesi.

Il rapporto di DeepSeek indica 890 byte per token per la memoria KV globale, circa un quarto del valore di V4 Flash. L’annuncio dichiara separatamente un quarto del fabbisogno di memoria ad alta larghezza di banda e un ottavo dello spazio SSD per la cache KV, rispetto alla generazione precedente. Sono misure collegate, non descrizioni intercambiabili dell’intera memoria del modello. [1] [2]

Per gli agenti di programmazione conta perché un compito può accumulare contenuti del repository, risultati degli strumenti e modifiche successive. Una cache ridotta diminuisce il costo di conservare quel contesto. Non dimostra che il modello ricorderà correttamente ogni dipendenza o sceglierà una buona patch. La capacità dichiarata è di circa un milione di token; la configurazione di servizio precisa 1.048.576. [2] [3]

Leggerei quindi il cambiamento come un miglioramento infrastrutturale. Rende più pratico offrire il contesto lungo, mentre la qualità di un compito di programmazione esteso resta una domanda separata.

I miglioramenti nella programmazione sono verificati indipendentemente?

Questo confronto viene dalla valutazione di DeepSeek, non da un test indipendente di questa pubblicazione. La tabella del modello addestrato a seguire istruzioni mostra miglioramenti chiari rispetto a V4 Flash in diversi benchmark di agenti. Il confronto utile è con quella versione precedente nelle condizioni dichiarate, non con punteggi di un altro fornitore ottenuti diversamente.

DeepSeek riporta un passaggio dal 54,4% al 74,2% su DeepSWE v1.1, pari a 19,8 punti percentuali. La scheda del modello specifica reasoning_effort=100, temperature=1.0 e top_p=0.95. Le valutazioni degli agenti di codice utilizzano DeepSeek Harness Minimal con un contesto di un milione di token; DeepSWE usa mini-SWE. Queste condizioni fanno parte del significato dei numeri. [2]

La mia lettura è che questa release meriti una nuova valutazione di programmazione. Il mio precedente confronto di V4 Flash riguarda il vecchio modello e non determina come si comporti V4.1. Ripeterei compiti rappresentativi con gli stessi test e criteri di revisione prima di applicare al lavoro quotidiano un vecchio giudizio negativo o un nuovo punteggio di lancio.

Quanto costa DeepSeek V4.1 Flash tramite API?

La tabella attuale usa l’identificatore deepseek-flash e applica prezzi diversi nelle fasce di punta e non di punta. Alla verifica del 14 settembre 2026, l’input senza cache costa 0,15 dollari per milione di token fuori punta e 0,30 nelle ore di punta. L’output costa rispettivamente 0,60 e 1,20 dollari. L’input in cache ha una tariffa propria inferiore. [4]

I prezzi di punta sono il doppio di quelli fuori punta. Un confronto deve indicare fascia oraria e categoria di cache, non soltanto il numero più basso. Il costo totale dipende anche da ragionamento, risultati degli strumenti e tentativi aggiuntivi. Un prezzo basso per i token di output è interessante, ma io misurerei il costo di ottenere un risultato verificabile.

Puoi eseguire i pesi aperti in locale?

I pesi sono disponibili con licenza MIT, ma il deploy documentato richiede hardware server di fascia alta. La configurazione vLLM descrive un checkpoint di circa 511 GB e un budget minimo di memoria GPU di 614 GB. Gli esempi comprendono un tray GB200 NVL4 e un nodo con otto GPU H200. Sono requisiti di quella configurazione, non un minimo universale per ogni futura implementazione. [2] [3]

Per questo separerei la decisione sull’API da quella sull’hosting. Un insieme fisso di compiti tramite API verifica se il modello serve al tuo lavoro. Ospitare i pesi richiede anche un piano operativo per modello, memoria, ambiente e capacità. I pesi aperti offrono questa possibilità agli operatori, senza eliminare il lavoro necessario per gestirla.

Come sviluppatore individuale, inizierei con un confronto limitato via API rispetto al modello già in uso. Per un team di infrastruttura, partirei dalla configurazione di deploy e misurerei le lunghezze reali di prompt e output. Il dato 8B diventa utile quando sai quale fase del tuo lavoro descrive.