DeepSeek V4.1 Flash è disponibile in GA: 552B con una nuova architettura, pesi MIT e una dismissione di V4 Pro che non è mai avvenuta

DeepSeek V4.1 Flash non è più un esperimento di due giorni. Il modello che l'8 e il 9 settembre è rimasto dentro l'API live del fornitore sotto un ID che portava la propria data di scadenza — deepseek-v4.1-flash-expires-on-0910 — è stato rilasciato davvero il 10 settembre 2026, attraverso l'app, l'interfaccia web e l'API di DeepSeek, dove ora risponde al nome di modello deepseek-flash. Tre cose del rilascio sono più grandi di quanto lasciasse intendere la beta. La prima è la documentazione: DeepSeek ha pubblicato un rapporto tecnico — intitolato, senza troppa sottigliezza, Pushing the Limits of KV Cache Compression — e i pesi con licenza MIT per un modello multimodale mixture-of-experts da 552 miliardi di parametri costruito su una nuova architettura Causal Encoder-Decoder. Quei pesi non sono una promessa: 48 shard safetensors, circa 510 GB in totale, sono andati online la mattina del rilascio, il che trasforma lo slogan non verificato della beta, «nuova architettura, multimodale nativo», in qualcosa che un lettore può scaricare e ispezionare. La seconda è la forma della gamma. DeepSeek V4 Flash e DeepSeek-V4-Flash-Vision-Exp sono stati ritirati, i loro vecchi ID continuano a risolversi nel nuovo modello alle tariffe Flash, e il piano di dismettere DeepSeek V4 Pro il 14 settembre è stato ritirato prima che arrivasse la data: V4 Pro è ancora servito, con fatturazione invariata, e DeepSeek ha promesso un preavviso prima di qualsiasi cambiamento. Il modello più economico della famiglia ha preso il posto del modello di punta sul prezzo e sui benchmark della stessa DeepSeek, e DeepSeek afferma che l'architettura sottostante è stata progettata per scalare a modelli più grandi. Ciò che sta sopra di esso è, al 25 settembre, la congettura di un tracker — una linea a tre livelli Flash, Pro e Ultra a 522B, 2T e 8T — offerta dall'account che l'ha pubblicata come speculazione e non confermata da nulla che DeepSeek abbia pubblicato. La terza è quella che la beta non ha mai avuto. Artificial Analysis ha ora pubblicato le prime valutazioni esterne del modello — un punteggio dell'Intelligence Index di 39 in modalità Reasoning allo sforzo massimo per i pesi di settembre e 45 per il checkpoint 1017 (un guadagno di sei punti che lo porta a pari merito con GLM-5.3 al secondo posto tra i modelli open-weight, un punto dietro MiMo-V2.6-Pro), contro 36 di DeepSeek V4 Pro 0813 sulla stessa scala, il che rende il modello da 552B il modello DeepSeek con il punteggio più alto che il sito abbia misurato. Altri dieci elementi sono più recenti del rilascio e puntano in direzioni diverse. Il 25 settembre il responsabile dei test dei modelli di ARC Prize in persona ha aperto una pull request per aggiungere un profilo DeepSeek V4.1 Flash di prima classe all'harness di benchmarking della fondazione — il valutatore il cui tabellone questo settore legge come un tetto di ragionamento più che come una verifica di produttività, in arrivo senza alcun risultato allegato e senza che ne sia promesso uno. Tre giorni dopo un laboratorio esterno ha pubblicato il tipo opposto di notizia: una misurazione completata, su un tabellone diverso, che mette DeepSeek V4.1 Flash accanto a un altro modello open-weight e lo trova il più debole dei due — e rileva che il numero cambia più in funzione dell'harness che avvolge il modello che del modello stesso. Su Exploit Bench, un benchmark della Carnegie Mellon che misura quanto un agente si spinge verso lo sfruttamento completo di un V8 di produzione, DeepSeek V4.1 Flash ha totalizzato in media 4,7 su 16 nella configurazione predefinita del benchmark e 9,3 sotto Claude Code, mentre GLM-5.3-Flash ha raggiunto un picco di 10,6 sotto Codex ed è sceso a 6,2 proprio sotto l'harness che si adatta meglio a DeepSeek V4.1 Flash. Il terzo è il meno drammatico e il più facile da verificare: il 7 ottobre il progetto vLLM ha pubblicato il proprio bilancio di tre settimane sull'erogazione di questo modello, riportando che la sua build attuale è 1,9× più veloce a bassa concorrenza e 5,3× il throughput con un vincolo di 150 TPS rispetto alla propria implementazione day-0 — un prima-e-dopo di un motore su se stesso più che un'altra valutazione esterna, e l'oggetto della sezione sulla velocità qui sotto. Un quarto riguarda quanto costa usare il modello più che quanto segna, e si è mosso due volte in tre giorni: il 12 ottobre OpenCode, l'agente di coding che prezza questo modello in base a un limite di utilizzo mensile anziché ai token misurati, ha alzato il proprio limite da $60 a $80 — una dichiarazione della piattaforma stessa su un prodotto che vende, riportata sulla sua pagina dei prezzi — e il 15 ottobre ha iniziato a servire lo stesso modello gratuitamente, con un secondo ID modello, su un contesto di 200.000 token rispetto alla finestra da 1M della voce a consumo. Un quinto, del 14 ottobre, misura il costo di erogazione del modello più che la sua qualità: Artificial Analysis ha aggiunto DeepSeek V4.1 Flash ad AA-AgentPerf, il suo benchmark hardware per l'inferenza agentica, con risultati sia su acceleratori NVIDIA sia AMD — a 100 token al secondo per utente, il GB300 NVL72 di NVIDIA guida il campo con circa 261 milioni di token al secondo per megawatt, e le stesse esecuzioni servono il modello con appena due acceleratori, cioè la sezione qui sotto espressa in una seconda valuta. Il sesto è il rilascio stesso, superato: il 17 ottobre DeepSeek ha sostituito il checkpoint dietro lo stesso nome di modello deepseek-flash con DeepSeek-V4.1-Flash-1017 — nuovi pesi, una tabella di benchmark del fornitore che batte il modello di settembre su ogni riga che pubblica, la stessa scheda tariffaria e lo stesso involucro da 1M di token — e, al 18 ottobre, una misurazione esterna dei nuovi pesi che contraddice la riga con cui il fornitore apre la tabella: Artificial Analysis assegna al checkpoint 1017 45 sul suo Intelligence Index e 33,8 su Terminal-Bench 4.0 sotto il proprio harness, contro il 42,3 della scheda di DeepSeek. Il settimo elemento è la discussione che quel divario ha prodotto. Il 19 ottobre un account tracker con un passato di anticipazioni su questi rilasci si è dichiarato «assolutamente certo» che il 42,3 sia reale «perché è migliore di GLM-5.3», e ha chiesto ad Artificial Analysis di eseguire il modello in un harness nativo. Il sito aveva già risposto il giorno prima, con un numero inferiore di otto punti e mezzo. L'ottavo non è un punteggio: il 20 ottobre un tracker di DeepSeek ha pubblicato la trascrizione di un agente in cui il checkpoint 1017 ha rifiutato una persona jailbroken a cui era stato applicato dsh-purge — un plugin costruito per rimuovere i vincoli dell'harness stesso — e le note di abliteration di una terza parte collocano il tasso di rifiuto del checkpoint non toccato a 97 su 100 prompt dannosi in modalità chat e 98 in modalità think, senza che DeepSeek abbia pubblicato una propria valutazione di sicurezza per nessuno dei due checkpoint. Il nono non è un punteggio né un prezzo: questa settimana DeepSeek ha aperto il motore di inferenza sul quale gira il proprio servizio, con una curva di decode per il checkpoint 1017 e le cifre di produzione che ne stanno alla base, e il thread che lo ha portato a galla questa settimana mette quella curva a confronto con un benchmark Ascend 950DT del 30 settembre che colloca il componente di Huawei circa da cinque a sette volte indietro per chip — la sezione sul silicio di servizio qui sotto. Il decimo non è un punteggio, un prezzo o un checkpoint: il 22 ottobre YuyuantanTan, l'account di attualità gestito da China Media Group, ha riportato che DeepSeek e MiniMax avevano completato le procedure di registrazione previste dal catalogo bozza cinese sull'esportazione di tecnologie e concluso l'open sourcing e le licenze verso l'estero. Si tratta di un resoconto di media statali su due aziende, non di un avviso di un regolatore o di una dichiarazione aziendale, ed è lo sviluppo che risponde alla domanda aperta il 16 ottobre dal catalogo bozza: se i pesi MIT di cui si occupa questo articolo possano continuare a essere pubblicati e spediti all'estero. La sezione sulla licenza qui sotto separa ciò che il rapporto dice da ciò che non dice.

Tutto quanto segue tiene distinte due tipi di affermazione. Le specifiche, i benchmark e i prezzi provengono dal changelog, dalla model card e dal report tecnico di DeepSeek — pubblicati dal fornitore, eseguiti dal fornitore e non riprodotti da nessun altro. Da allora quel divario si è ridotto grazie a quattro strumenti indipendenti — un indice composito, una board comunitaria dei kernel, un benchmark cyber controllato da harness e un benchmark hardware per il serving — uno dei quali, l'indice, è stato ora eseguito su entrambi i checkpoint. Nessuno di essi replica una singola riga del fornitore, e ARC Prize sta ancora costruendo la valutazione del ragionamento, senza che ne sia stato pubblicato nulla finora. Il 17 ottobre DeepSeek ha sostituito il modello dietro lo stesso nome API con il checkpoint DeepSeek-V4.1-Flash-1017. Per un giorno ciò ha significato che ogni numero esterno in questo articolo descriveva pesi che il fornitore non serviva più, senza alcun punteggio esterno per quelli che serviva; il 18 ottobre Artificial Analysis ha rieseguito il proprio indice sul nuovo checkpoint e ha pubblicato 45, contro 39 per i pesi di settembre. Gli altri tre strumenti non sono stati rieseguiti: il benchmark cyber, la board dei kernel e il benchmark hardware descrivono ancora i pesi di settembre, e nessun punteggio indipendente, vecchio o nuovo, replica una delle righe di benchmark di DeepSeek. Il dato sul costo del serving pubblicato dal progetto vLLM il 17 ottobre è più recente solo nella data di pubblicazione: il grafico alla base è datato 16 ottobre, il giorno prima della sostituzione, quindi descrive gli stessi pesi superati. Sul suo indice attuale (v4.3.2) Artificial Analysis assegna al checkpoint DeepSeek V4.1 Flash di settembre 39 e al checkpoint 1017 45, descrivendoli entrambi come ben al di sopra della mediana di 19 per modelli open-weight di dimensioni comparabili; sono numeri autentici di terze parti e i primi, in questa storia, che DeepSeek non ha prodotto. Ciascuno è un composito di dieci valutazioni, non una replica di una singola riga del fornitore, e non dice nulla sull'economia del contesto da 1M. Le cifre sui rifiuti in questo articolo sono un quarto tipo di affermazione e sono etichettate dove compaiono: provengono da persone che costruiscono derivati non censurati di questi pesi, non da DeepSeek e non da un laboratorio di valutazione, e DeepSeek non ha pubblicato alcuna valutazione di sicurezza per nessuno dei due checkpoint. I numeri hardware nella sezione sul serving sono ancora un'altra classe: la curva di decode NVIDIA e i dati di produzione sono misurazioni di DeepSeek del proprio motore, pubblicate con il codice questa settimana, e i punti Ascend provengono da un foglio di benchmark riprodotto in un thread su X che non è pubblicato né sul sito dell'uno né sull'altro fornitore. Dove un numero appartiene a DeepSeek, questo articolo lo dice. Un'altra classe resta fuori da quella tassonomia. Il rapporto del 22 ottobre secondo cui DeepSeek e MiniMax hanno completato la registrazione nell'ambito del progetto di catalogo delle esportazioni è media statali — YuyuantanTan di China Media Group, ripreso da diverse testate finanziarie cinesi — non un avviso del Ministero del Commercio, e DeepSeek non ha pubblicato alcuna dichiarazione che lo confermi. Il catalogo stesso è una bozza governativa aperta ai commenti fino al 15 novembre, ed è descritto come bozza ovunque compaia qui. I nomi delle build associati al rapporto — V4.1F-1017 e M3.1-Flash — provengono da un singolo account X il 23 ottobre e non compaiono nel rapporto dei media statali né nelle testate che lo hanno ripreso; il checkpoint che quel post nomina era già scaricabile da sei giorni quando è stato scritto.

Il checkpoint del 17 ottobre: cosa ha cambiato DeepSeek-V4.1-Flash-1017

Cinque settimane dopo il rilascio su cui è incentrato questo articolo, DeepSeek ha sostituito il modello che ne è alla base. La voce del changelog datata 17 ottobre si compone di tre frasi: “DeepSeek V4.1 Flash è stato aggiornato a DeepSeek-V4.1-Flash-1017. Anche i modelli ufficiali web e APP sono stati aggiornati alla nuova versione. Il metodo di chiamata dell’API e i prezzi restano invariati — è sufficiente usare deepseek-flash per accedere al modello più recente.” Tutto in quella citazione è il fornitore che parla del proprio prodotto, e tutte e tre le affermazioni sono verificabili sulle pagine di DeepSeek stesso anziché prese per buone: la riga della versione del modello nella tabella Models & Pricing ora riporta DeepSeek-V4.1-Flash-1017 laddove prima riportava DeepSeek-V4.1-Flash, la scheda delle tariffe accanto è la stessa ripartizione tra fuori punta e punta pubblicata il 10 settembre — 0,003 $, 0,15 $ e 0,60 $ per 1 milione di token fuori punta, che raddoppiano a 0,006 $, 0,30 $ e 1,20 $ nelle fasce di punta dei giorni feriali — e la guida rapida dell’API indica ancora deepseek-flash come stringa del modello, con contesto da 1 milione di token, tetto di output di 384K e limite di concorrenza di 2.500 richieste invariati. Gli ID alias ritirati si comportano come la nota di settembre diceva che avrebbero fatto: deepseek-v4-flash e deepseek-v4-flash-vision-exp sono ancora accettati e ora rispondono come DeepSeek-V4.1-Flash-1017 ai prezzi Flash. DeepSeek ha annunciato lo stesso cambiamento dal proprio account quel giorno, e vale la pena leggere il post insieme al changelog perché è più breve e più schietto: “DeepSeek-V4.1-Flash-1017 è qui! Prestazioni più solide nei benchmark, completamento delle attività più rapido e output più brevi rispetto alla versione precedente: un miglioramento paretiano di prestazioni e costi. Ora disponibile sul nostro sito web, nell’app e nell’API,” seguito dagli stessi tre harness e dalla stessa istruzione di aggiornare a DeepSeek Harness 0.2.1-rc.1 o versione successiva. Tutto ciò che contiene è il fornitore che descrive il proprio prodotto sul proprio canale: “ora disponibile sul nostro sito web, app e API” è la riformulazione di “anche i modelli ufficiali web e APP sono stati aggiornati” del changelog, e le affermazioni su benchmark, runtime, lunghezza dell’output e Pareto sono quelle della model card — con una differenza che conta per chiunque stia decidendo se provarlo. La scheda riporta un numero accanto a ogni riga di benchmark; il post non ne riporta nessuno, e né il post né il changelog attribuiscono una cifra all’affermazione su runtime e lunghezza dell’output. Due delle quattro cose che DeepSeek sta mettendo in primo piano qui sono ancora asserzioni del fornitore anziché risultati pubblicati, e il grafico dietro la frase sul Pareto — quello allegato al post — è di DeepSeek stesso, tracciato sulle sue stesse misurazioni dei costi per attività.

I pesi si sono spostati con esso, e questa è la parte che un lettore può verificare senza fidarsi di un changelog. Un secondo repository, deepseek-ai/DeepSeek-V4.1-Flash-1017, è apparso su Hugging Face nelle prime ore del 17 ottobre con la stessa licenza MIT: di nuovo 48 shard safetensors, lo stesso totale di circa 510 GB, ogni shard della stessa dimensione della sua controparte di settembre e l'hash di ogni shard diverso. Stessa forma, contenuti diversi — che è ciò che un “aggiornamento minore” dovrebbe sembrare dall'esterno, e che significa anche che le affermazioni sull'architettura che questo articolo riporta da settembre sono intatte: il file di configurazione che dichiara il backbone da 552B, i 384 esperti instradati, il percorso di prefill con 8B di parametri attivi per token e il percorso di decode da 16B è identico byte per byte a quello nel repository di settembre, quindi la KV cache da 890 byte per token è lo stesso design anziché uno nuovo. Ciò che il nuovo repository non contiene è la documentazione. Non c'è alcun report tecnico, nessuna cartella di valutazione e nessun template chat Jinja; la model card dice che la release non include un template chat e rimanda invece a un riferimento di codifica Python e a un nuovo toolkit Rust, deepseek-recipe, per trasformare richieste Chat Completions, Responses e in formato Anthropic nel formato di prompt del modello. Chiunque fissi i pesi tramite il nome del repository dovrebbe sapere che i due download differiscono in più dei loro hash. L'elenco dei file dice esattamente come: tutti i 48 shard hanno un checksum diverso e una dimensione in byte identica, mentre i file che non sono pesi — la configurazione che dichiara l'architettura, la licenza e l'intera cartella di codifica — sono identici byte per byte in entrambi i repository. Sette file esistono nel repository di settembre e non in questo, e nulla è stato aggiunto per sostituirli: il report tecnico, la cartella di valutazione, il template chat, le due figure che la card usava incorporare e un .gitignore. La model card restringe anche un parametro di serving. La card di settembre raccomandava un top_p di 0,95 oppure 1,0; la card del 17 ottobre raccomanda 1,0, con temperatura a 1,0, una finestra di contesto da 1M e un max_tokens di almeno 256K invariato.

La tabella di benchmark di DeepSeek stessa è il luogo in cui l'aggiornamento dovrebbe emergere, ed è una tabella del fornitore esattamente del tipo che erano le righe di settembre: esecuzioni della stessa azienda, non riprodotte da nessuno, pubblicate su un modello i cui pesi erano stati pubblici per alcune ore. Rispetto al checkpoint di settembre è in rialzo su ogni riga che la scheda riporta — HLE senza strumenti 42,6 contro 36,8, oppure 44,0 contro 39,1 sul sottoinsieme solo testo; Terminal-Bench 4.0 42,3 contro 31,2; DeepSWE v1.1 77,0 contro 74,2; ProgramBench 29,1 contro 20,3; NL2Repo-Bench 68,2 contro 65,4; Automation-Bench v1.0.6 60,5 contro 54,8; Agents' Last Exam 35,4 contro 31,8; Apex Bench v1.1 72,1 contro 64,6; Chartography con strumenti 83,0 contro 78,9; BabyVision con strumenti 92,5 contro 89,6; e ZeroBench-main con strumenti 51,0 contro 49,0, a Pass@5. La stessa tabella colloca 1017 rispetto ai modelli di frontiera su cui DeepSeek si confronta: ora supera GPT-5.6 Sol su Terminal-Bench 4.0, 42,3 contro 39,9, mentre resta ancora dietro a Opus 5 su 51,8, e guida entrambi su DeepSWE v1.1, 77,0 contro 73,0 e 74,0 — una riga letta dal grafico allegato all'annuncio del fornitore stesso, e il numero più citato della settimana. Su NL2Repo-Bench si sposta a 68,2 e resta comunque dietro a Opus 5 su 75,3, che è la stessa forma che aveva la tabella di settembre: più forte sul lavoro agentico strumentato, dietro sulle righe che premiano la profondità di ragionamento. La riga Terminal-Bench 4.0 è quella da leggere due volte, perché ora è l'unica riga di quella tabella con una controparte indipendente. DeepSeek l'ha eseguita sotto l'harness di Claude Code; Artificial Analysis esegue gli stessi 66 compiti sotto mini-swe-agent, e il suo risultato del 18 ottobre per questi pesi è 33,8 — otto punti e mezzo sotto il 42,3 del fornitore. Sulla tabella di DeepSeek stessa quella riga supera GLM-5.3 di 4,4 punti, 42,3 contro 37,9. Sull'harness di Artificial Analysis gli stessi pesi sono dietro a GLM-5.3 di otto, 33,8 contro 41,9.

Una riga di note in corpo minuscolo vale più di diversi di quei delta. La scheda di settembre ha valutato Terminal-Bench 4.0 con DeepSeek Harness nella sua modalità Minimal; la scheda 1017 dice che ha usato l'harness Claude Code per Terminal-Bench 4.0 e Mini-SWE-V2 per DeepSWE v1.1. Lo studio sugli harness più avanti in questo articolo ha misurato sette punti di dispersione su un modello attraverso sette CLI per agenti, quindi uno spostamento di undici punti su Terminal-Bench 4.0 che arriva con un harness diverso sotto non può essere letto come undici punti di modello. La scheda dichiara quale harness ha usato, ed è questo che rende la riga verificabile anziché soltanto impressionante, ma la riga racchiude due cambiamenti in un solo numero. L'esecuzione indipendente li separa, e non a favore del fornitore. Artificial Analysis ha valutato gli stessi pesi 1017 su Terminal-Bench 4.0 con mini-swe-agent — l'harness che mantiene costante per ogni modello in quella classifica — e ha ottenuto 33,8, contro 26,8 per il checkpoint di settembre sullo stesso harness. Su un harness fisso il checkpoint vale sette punti, non undici, e il numero di punta di DeepSeek si colloca otto punti e mezzo sopra quello che gli stessi pesi ottengono quando l'harness è mantenuto costante tra i modelli. Il resto dell'inquadratura di DeepSeek riguarda il costo più che il punteggio, ed è lo stesso asse su cui è stata venduta la release di settembre: il changelog sostiene che l'aggiornamento riduce il tempo di esecuzione dei task e la lunghezza dell'output, definisce il risultato «un nuovo ottimo paretiano di prestazioni e costi su più harness» e afferma di aver ottimizzato per DeepSeek Harness, Tencent CodeBuddy e WorkBuddy, raccomandando DeepSeek Harness 0.2.1-rc.1 o successivo. Il runtime e la lunghezza dell'output sono precisamente le quantità che le prove sulla verbosità in questo articolo seguono dall'esterno, e ora DeepSeek afferma di aver ridotto entrambe — senza allegare alcun dato. Ora esiste una misurazione esterna del nuovo checkpoint, e non mostra il taglio del runtime né dell'output: l'esecuzione dell'indice di Artificial Analysis colloca i pesi 1017 a 288,8 secondi per task contro 289,9 per settembre, e 89.495 token di output per task contro 88.574 — invariati su entrambi, con il risparmio sui costi che finisce da tutt'altra parte. Il post che DeepSeek ha pubblicato sul proprio account lo stesso giorno comprime tutto questo in «completamento più rapido dei task e output più brevi», per poi definire la coppia un miglioramento paretiano di prestazioni e costi — l'affermazione del changelog in forma più breve, dalla stessa fonte e altrettanto non misurata. È il fornitore che ripete se stesso, non una seconda fonte — il che conta, perché il numero tratto da quel grafico è quello che il mondo esterno ha passato la settimana a ripetere. L'unico artefatto dell'annuncio che porta effettivamente numeri è il grafico allegato al post, ed è DeepSWE v1.1 Pass@1 tracciato rispetto al costo medio per task sotto un harness mini_swe_v2. Vale la pena leggere la sua didascalia prima della riga sul Pareto: i dati della classifica pubblica sottostanti sono datati 22 settembre sul grafico stesso, tre settimane e mezzo prima del checkpoint che il grafico viene usato per promuovere, e le linee di confronto per i modelli di OpenAI sono attribuite al grafico DeepSWE di OpenAI stesso anziché a un'esecuzione condivisa. Un punto su quel grafico è nuovo. Tutto ciò con cui viene confrontato è stato pubblicato prima che esistesse.

Lo stesso giorno dello scambio, la lettura più condivisa di quella tabella è arrivata da qualcuno con un interesse diretto su dove viene eseguito il modello. Yuchen Jin, che lavora sui sistemi AI di Databricks, ha pubblicato che DeepSeek-V4.1-Flash-1017 "ottiene 77 su DeepSWE v1.1", che si tratta di "prestazioni di livello Opus 5 a un costo 83 volte inferiore" e che "lo lanceremo su Databricks". Il 77 è la riga di DeepSeek stesso, presa dal grafico allegato all'annuncio del fornitore, e nessuno al di fuori dell'azienda l'ha riprodotto. I due punti di confronto sono di Jin, e si dividono nettamente in uno che supera una verifica esterna e uno che non la supera. Il livello Opus 5 regge: le classifiche indipendenti che pubblicano DeepSWE v1.1 collocano il nome di questo modello in quella zona nelle proprie esecuzioni. La classifica APEX di Mercor — 113 attività originali su 91 repository, valutate con l'harness mini-swe-agent — elenca Opus 5 Max al 71,4% e una voce DeepSeek V4.1 Flash Max al 71,7%, e la classifica llm-stats per lo stesso benchmark colloca Claude Opus 5 al 68,8% contro il 74,2% di DeepSeek-V4.1-Flash. La lettura onesta della coppia è più ristretta di quanto faccia pensare il post: due classifiche che misurano questo benchmark in modo indipendente concordano che il modello è almeno pari a Opus 5 su di esso, e nessuna delle due mostra un 77, perché entrambe riportano o il dato di settembre o la propria esecuzione, e nessuna etichetta una voce con il checkpoint 1017. Il livello Opus 5 è sostenibile come affermazione su una zona. Il numero che lo ha prodotto non è ancora riproducibile.

La metà degli 83× del post è una sua aritmetica, non una cifra pubblicata, ed è la metà da prendere con le molle. Nessuna board riporta un costo per singolo task per il checkpoint 1017, e il grafico del fornitore alla base della stessa rivendicazione Pareto di DeepSeek traccia il costo per attività su un asse logaritmico che va da dieci centesimi a venti dollari — il tipo di ampiezza che un multiplo così grande richiede. Sulle sole tariffe di listino il divario è più stretto di 83×: Claude Opus 5 addebita $5 per 1M token in input e $25 per 1M in output contro $0,30 e $1,20 per DeepSeek-V4.1-Flash all'interno delle finestre di picco nei giorni feriali, circa 17× sull'input e 21× sull'output, e la risposta cambia parecchio in base alla quota di cache hit e al numero di token che richiede un'attività. La direzione dell'argomentazione sui costi non è in discussione, né qui né altrove in questo pezzo. Il multiplo specifico è un'affermazione su un confronto che nessuno ha pubblicato.

Databricks è la parte di quel post che un lettore può verificare nella documentazione, e la documentazione dice più di quanto non dica il post. DeepSeek V4.1 Flash è su Databricks Unity Gateway dall'11 settembre, il giorno successivo al lancio di DeepSeek, con input testuale e immagini tramite le Foundation Model APIs della piattaforma con il nome di servizio system.ai.deepseek-v4-1-flash; il 7 ottobre la piattaforma ha aggiunto per questo modello la priorità pay-per-token e il throughput con provisioning riservato. È anche la destinazione designata dalla piattaforma per questa famiglia: Databricks ha programmato il ritiro di DeepSeek V4 Pro (0813) il 30 ottobre e di DeepSeek V4 Flash (0731) il 5 novembre, indicando DeepSeek V4.1 Flash come sostituto consigliato in entrambe le note. Ciò che nessuna pagina di Databricks dice è che il checkpoint del 17 ottobre sia in arrivo. Questa affermazione è quella di un dipendente che parla a titolo personale — un segnale interno sull'intenzione, non una data di rilascio effettiva, e la pagina dei modelli supportati continua a riportare il modello senza un'etichetta di checkpoint. Quindi il cambiamento di disponibilità di questa settimana è prospettico, proveniente da una fonte interna alla piattaforma anziché dalla piattaforma stessa; ciò che un cliente Databricks può chiamare oggi sono i pesi di settembre, e il cambio che questo articolo ha descritto — nuovi pesi dietro lo stesso nome e lo stesso listino — è la forma che quel rimpiazzo assumerà quando arriverà.

Quindi ciò che non è cambiato è importante quanto ciò che è cambiato. Tre dei quattro strumenti indipendenti coprono ancora i pesi di settembre e solo quelli: la tabella dell'harness Exploit Bench, la board dei kernel della community e le esecuzioni hardware AA-AgentPerf sono state tutte prodotte prima dello scambio, e le due board DeepSWE v1.1 che portano il nome di questo modello pubblicano una voce senza alcun checkpoint. Il quarto è cambiato il 18 ottobre: Artificial Analysis ha aggiunto una riga separata per il checkpoint 1017, gli ha assegnato 45 sull'Intelligence Index e 33,8 su Terminal-Bench 4.0, e ha lasciato la riga di settembre ferma a 39 e 26,8. È la prima volta che un numero in questo articolo è stato prodotto da qualcuno diverso da DeepSeek sui pesi che DeepSeek sta attualmente servendo. La modifica all'API è un aggiornamento del checkpoint dietro un nome che DeepSeek aveva già documentato come riferito al modello Flash più recente — l'opposto del piano di settembre di far sì che deepseek-v4-pro rispondesse come un modello diverso, ed è la distinzione che gli sviluppatori stavano tracciando quando hanno obiettato a quel caso. Per chi chiama, l'effetto pratico è circoscritto e concreto: chiedere deepseek-flash ora ottiene pesi diversi allo stesso prezzo, con dietro una tabella migliore dichiarata dal fornitore e, dal 18 ottobre, una terza parte che li valuta — più bassa sull'unica riga in cui esistono entrambi. Su OrcaRouter anche l'id del modello e il listino prezzi sono invariati — DeepSeek V4.1 Flash è instradato al prezzo di listino di DeepSeek stesso con uno 0% di ricarico trasferito — che è l'aspetto che dovrebbe avere, dal lato di chi chiama, un fornitore che aggiorna un modello senza cambiarne il nome o il prezzo.

Cosa è stato effettivamente rilasciato il 10 settembre

La voce del changelog si apre con una sola frase: "Oggi rilasciamo ufficialmente il modello DeepSeek-V4.1-Flash." DeepSeek lo descrive come il membro più piccolo di una nuova famiglia di strutture di modelli, con comprensione visiva nativa, ed è la prima release di questo ciclo ad arrivare con un rapporto tecnico allegato. Lato API si tratta di un cambio di nome, non di una migrazione:

• Nome del modello — deepseek-flash sull'API proprietaria di DeepSeek; l'URL di base, la chiave e il formato della richiesta restano invariati.

• Ritirato — DeepSeek V4 Flash e DeepSeek-V4-Flash-Vision-Exp sono offline. I loro vecchi ID sono ancora accettati e ora instradano a V4.1 Flash, fatturati alle tariffe Flash, quindi le integrazioni esistenti continuano a funzionare senza modifiche al codice.

• V4 Pro — DeepSeek ha annunciato che dalle 12:00 ora di Pechino del 14 settembre le richieste a deepseek-v4-pro sarebbero state indirizzate a V4.1 Flash ai prezzi di V4.1 Flash fino al rilascio di V4.1 Pro, per poi invertire la decisione prima che arrivasse la data. V4 Pro è ancora fornito, con fatturazione invariata, e DeepSeek afferma che darà comunicazione di qualsiasi ulteriore modifica.

• Envelope — una finestra di contesto di 1 milione di token, output massimo di 384K, 2.500 richieste simultanee per account, supporto all'input di immagini, modalità di pensiero attiva per impostazione predefinita con opzione per la modalità senza pensiero.

• Pesi — lo stesso giorno, il repository deepseek-ai/DeepSeek-V4.1-Flash è comparso su Hugging Face con licenza MIT: 48 shard safetensors per un totale di circa 510 GB, il rapporto tecnico in PDF accanto a essi e un'implementazione di inferenza di riferimento in una cartella inference.

Quell’ultimo punto è anche il punto in cui si inserisce la vicenda dell’ID del modello ritirato per chiunque abbia deepseek-v4-flash codificato in modo fisso in un percorso di produzione: viene ancora risolto, ma a rispondere è un modello diverso. DeepSeek è stata esplicita nel dire che si tratta di uno shim di compatibilità, non di una promessa, il che lo rende una scadenza di migrazione mascherata da avviso di deprecazione.

L'architettura, ora agli atti.

Due giorni fa questa sezione sarebbe potuta essere solo un elenco di cose che nessuno aveva pubblicato. Il rapporto tecnico lo chiarisce, e l'affermazione strutturale si rivela letterale, non marketing. DeepSeek V4.1 Flash è un modello multimodale mixture-of-experts da 552B parametri, e le parti nuove sono quelle che determinano il costo di esecuzione:

• Backbone — 552B parametri totali, mixture-of-experts con un esperto condiviso e 384 esperti instradati per layer, sei esperti instradati attivi per token.

• CED — un transformer a 40 livelli suddiviso in un encoder causale a 20 livelli e un decoder a 20 livelli. La cache KV globale del decoder è proiettata dagli stati nascosti finali dell'encoder, invece di essere derivata dagli stati nascosti di ciascun livello del decoder, ed è proprio qui che si ottiene la maggior parte del risparmio di memoria.

• Asimmetria di attivazione — circa 8B parametri attivi per token durante la prefill e 16B durante la decode, quindi leggere un prompt lungo è sostanzialmente più economico che generare da esso.

• Cache KV — il rapporto sostiene 890 byte per token di cache KV globale, circa un quarto di DeepSeek V4 Flash, utilizzando la cache KV principale in FP4 con una scala ogni 16 canali più il riutilizzo tra livelli.

• Attenzione e decodifica — Compressed Sparse Attention 2 con modalità Full, Reindex e Reuse e un indicizzatore sparso gerarchico, Single-Pass mHC e decodifica speculativa DSpark.

• Engram — una tabella di memoria condizionale da 196 miliardi di parametri, accessibile in modo sparso tramite una ricerca basata su token, che si colloca accanto al percorso mixture-of-experts anziché all'interno dello stack di attenzione. È il singolo blocco di pesi più grande del rilascio, ed è la cifra riportata nella model card a rendere leggibile la dimensione del download.

• Visione — DeepSeek-ViT con un proiettore MLP a due strati, addestrato dall'inizio del pre-addestramento del modello linguistico anziché essere innestato successivamente su una base testuale.

— Addestramento — 45T token di corpus multimodale, con attenzione sparsa addestrata a una lunghezza di sequenza di 64K e contesto esteso a 1M al traguardo dei 34T token. Il post-addestramento prevede SFT, poi RL, poi distillazione on-policy.

• Sforzo di ragionamento — un intero controllabile in modo continuo da 1 a 100, una regolazione più fine rispetto ai livelli basso, alto e massimo che DeepSeek V4 Pro espone.

Il numero della KV-cache è quello con conseguenze che vanno oltre la scheda tecnica, ed è qui che il design dimostra il suo valore. Una finestra di contesto da 1M di token è utile solo se puoi permetterti di riempirla. Il motivo per cui l'economia del contesto lungo della generazione precedente era problematica era duplice: la cache globale cresceva con ogni layer che applicava l'attenzione sul prompt, e la maggior parte della capacità di cache persistente veniva spesa per mantenere stato di finestra scorrevole che smetteva di essere utile nel giro di minuti. La risposta del rapporto affronta entrambi i problemi. Se il prodotto erogato sia all'altezza a 1M di token in condizioni di concorrenza reale è il tipo di affermazione che richiede ancora una terza parte — i punteggi indipendenti che ora esistono misurano il modello, non l'economia del contesto lungo — ma il meccanismo ora è documentato anziché dedotto, e la sezione seguente lo analizza nel dettaglio.

Dentro la cache: come si ottengono davvero 890 byte per token

Il titolo del report è la tesi. Leggilo e l'affermazione sull'efficienza smette di sembrare un effetto collaterale del backbone mixture-of-experts e inizia a sembrare il brief di progettazione — che è la lettura su cui sono convergiti gli articoli indipendenti sin dal rilascio. La ragione per cui conta commercialmente anziché accademicamente è dove finisce davvero il conto di un agente: l'inquadramento di DeepSeek è che la voce dei cache-hit è quella che lo domina su carichi di lavoro agentici lunghi, il che rende la dimensione della cache una leva di costo di prim'ordine. I numeri di DeepSeek collocano la cache globale a 890 byte per token, circa 437× più piccola del DeepSeek V1 originale e circa un quarto di DeepSeek V4 Flash. Fai il calcolo su una finestra completa e la differenza è tra circa 890 MB di KV globale per una singola sequenza da 1M di token e circa 3,5 GB al tasso per token di V4 Flash. Tre cambiamenti fanno la maggior parte della compressione: uno su quanto viene memorizzato, uno su cosa viene letto e uno su cosa viene conservato del tutto.

Il formato di archiviazione è il più leggibile tra questi. La cache globale principale è mantenuta in FP4 usando il layout E2M1 con una scala E4M3 ogni 16 canali — metà della larghezza della cache FP8 memorizzata da DeepSeek V4 e un quarto di FP16. Ciò che lo rende sostenibile è che DeepSeek ha quantizzato la cache durante l'addestramento anziché al momento del serving, quindi il rumore introdotto dal formato più stretto è qualcosa che il modello ha imparato a gestire invece di qualcosa che gli è stato inflitto successivamente. Non tutto è stato compresso in quel modo: la cache locale a finestra scorrevole resta in FP8, perché il report la considera la parte sensibile a un'ulteriore riduzione.

Compressed Sparse Attention 2 gestisce ciò che viene letto. A ogni layer di attenzione viene assegnata staticamente una di tre modalità — Full, Reindex o Reuse — così i layer decoder possono condividere lo stato delle chiavi e lo stato dell'indicizzatore invece di mantenerne ciascuno il proprio, e il primo layer in modalità Full costruisce un pool di candidati a cui i successivi layer di indicizzazione sono limitati. Le cifre riportate collocano quel pool a 16,384 posizioni con la selezione sparsa sulle 512 voci migliori, ed è ciò che disaccoppia il costo di indicizzazione dalla lunghezza del contesto: secondo DeepSeek, passare da un contesto di 4K a 1M aggiunge solo circa un quarto di calcolo in più per token generato, invece della crescita all'incirca proporzionale alla finestra che il progetto precedente implicava. Quel singolo dato è la cosa più utile nel report per chiunque cerchi di quantificare il costo di un carico di lavoro a contesto lungo, ed è anche quello del tutto privo di conferme esterne: nessuna delle misurazioni esterne in questo articolo ha testato l'estremo superiore della finestra di contesto.

Il cambiamento che incide maggiormente sul lato persistente ha il nome meno promettente. DeepSeek V4 manteneva due cose nella propria cache persistente per più di 72 ore con carichi di lavoro tipici: il KV globale e lo stato dell’attenzione a finestra scorrevole. Lo stato a finestra scorrevole è rilevante per pochi minuti, ma consumava quasi metà della capacità della cache persistente — uno spazio dimensionato per giorni e occupato da dati utili per un minuto. V4.1 Flash elimina del tutto lo stato SWA dalla cache persistente e lo colloca in un pool assemblato con circa il 10% della DRAM dell’host di ciascuna macchina, con un tempo di vita nell’ordine dei minuti. Quando una sessione riprende e quello stato non c’è più, SWA Bounded Replay lo ricostruisce in modo approssimativo: invece di riprodurre livelli × token della finestra, riproduce solo la finestra più recente, riportata a 128 token, e accetta che lo stato ricostruito non sia matematicamente identico a una riproduzione completa. DeepSeek afferma di aver osservato un impatto minimo sulla qualità dovuto all’approssimazione e di aver simulato lo stesso comportamento durante il post-addestramento. Mettendo insieme questo aspetto alla cache globale più ridotta, l’impronta KV persistente scende a circa un ottavo di quella di DeepSeek V4 Flash con carichi di lavoro identici — un taglio maggiore rispetto al valore di un quarto che apre la scheda tecnica, perché si tratta di due modifiche sovrapposte anziché di una singola modifica di formato.

Due limiti gravano su tutto questo. Il report non offre alcun confronto end-to-end su latenza o costi, quindi una cache persistente otto volte più piccola non è un carico di lavoro dimostratamente otto volte più economico: la compressione allevia la pressione sulla memoria, e solo la parte memory-bound di un costo reagisce a questo. E il risparmio non è qualcosa che ti capita. Un motore deve implementare la proiezione encoder-decoder, le tre modalità CSA2, il layout della cache FP4 e Bounded Replay prima che il numero significhi qualcosa, motivo per cui 890 byte vanno letti preferibilmente come una specifica first-party per l'API servita da DeepSeek stessa anziché come una promessa su una build locale — le conversioni quantizzate per llama.cpp, Ollama e LM Studio nel repository non portano con sé questa cache. Il dato principale copre anche i token di testo; gli embedding visivi ne restano fuori. Su qualsiasi cosa self-hosted, il numero di cui fidarsi è quello che misuri. Quanto può spingersi un motore con esso non è più un'ipotesi, sebbene non sia ancora indipendente. vLLM ha implementato il trim lato decoder e Bounded Replay nelle tre settimane successive al rilascio e ha pubblicato il prima e il dopo nella sezione sulla velocità qui sotto — la cosa più vicina finora a una verifica della specifica, e una verifica fatta da un motore che misura il proprio lavoro anziché da un valutatore che misura il modello.

Il punteggio indipendente, eseguito due volte: 39 per i pesi di settembre, 45 per 1017

Artificial Analysis ha pubblicato la prima valutazione indipendente di DeepSeek V4.1 Flash, ed è il numero che la beta non era riuscita a produrre. Sulla versione attuale dell'Artificial Analysis Intelligence Index (v4.3.2), il modello ottiene 39 in modalità Ragionamento con sforzo massimo. Sulla stessa scala e con la stessa impostazione, DeepSeek V4 Pro 0813 ottiene 36 e DeepSeek V4 Flash 0731 ottiene 34. Letti insieme, questi tre risultati dicono ciò che il marketing di DeepSeek aveva affermato e che i suoi benchmark non erano riusciti a dimostrare da soli: il modello più piccolo della famiglia è ora il più forte. Artificial Analysis descrive 39 come ben sopra la mediana di 19 per i modelli a pesi aperti di dimensioni comparabili. Per cinque settimane è stato un punteggio relativo al solo checkpoint di settembre: la scheda del valutatore riportava la data di rilascio di settembre e nulla più. Il 18 ottobre la situazione è cambiata, e il cambiamento è la notizia che questo articolo non aveva quando è stato pubblicato la prima volta. È comparsa una seconda riga per DeepSeek V4.1 Flash 1017, datata 17 ottobre, con un punteggio di 45 sullo stesso indice e con lo stesso sforzo massimo. Questo colloca i pesi 1017 allo stesso livello di GLM-5.3 a 45, due punti sotto GPT-5.6 Sol a 47 e sei sotto Claude Opus 5 a 51 — e rende il checkpoint il modello DeepSeek con il punteggio più alto misurato dal sito, cinque settimane dopo che i pesi di settembre avevano conquistato quel titolo. Gli conferisce inoltre una posizione che prima non aveva, e che il valutatore dichiara esplicitamente nella sua analisi del 19 ottobre: secondo nella tabella dei pesi aperti, a pari merito con GLM-5.3 e un punto dietro MiMo-V2.6-Pro a 46, con Step 5 Preview e Kimi K3 un punto più indietro a 44. I sei punti non sono distribuiti uniformemente tra le dieci valutazioni. La stessa analisi riporta i maggiori avanzamenti nelle componenti agentiche e di conoscenza — un Elo GDPval-AA v2.1 di 1.746 contro 1.600, un Elo AA-Briefcase v1.1 di 1.570 contro 1.420 e un tasso di non allucinazione AA-Omniscience del 33% contro il 4%, con l'accuratezza che sale dal 43% al 46% e l'indice di quella valutazione che passa da -5 a +5. Questi sono i numeri del valutatore per i suoi stessi test, pubblicati da lui anziché riprodotti qui, e descrivono un modello diventato decisamente meno propenso a inventare una risposta — un miglioramento diverso da quello sulla velocità che il changelog di DeepSeek mette in primo piano.

Il confronto che conta qui è quello interno, perché è lo stesso confronto che fa la tabella di routing di DeepSeek. V4.1 Flash porta 552B parametri totali con 16B attivi per token; DeepSeek V4 Pro 0813 ne porta circa 1,6T totali con circa 49B attivi. Un modello con circa un terzo del backbone ottiene tre punti in più su un composito che il suo produttore non ha eseguito — nove punti in più una volta contati i pesi 1017, dato che il flagship da 1,6T non si è mosso da 36. Il compromesso dimensione-punteggio è l'intera tesi del design Causal Encoder-Decoder, e un valutatore senza alcun interesse nel risultato ha ora prodotto un numero coerente con essa.

Anche la parte dell'affermazione relativa al prezzo regge, e questo è il primo confronto sui prezzi del racconto che non proviene da un listino tariffario DeepSeek. Artificial Analysis indica DeepSeek V4.1 Flash a $0,30 per 1M di token in input e $1,20 per 1M in output, rispetto a $1,32 e $3,96 per DeepSeek V4 Pro 0813 — 4,4× più economico sull'input e 3,3× sull'output, con un costo misto di $0,18 per 1M secondo il mix 7:2:1 di cache hit, input e output del sito. È anche più economico del più vecchio e più piccolo DeepSeek V4 Flash 0731 che va a sostituire, che il sito indica a $0,44 e $1,32 con un punteggio inferiore di cinque punti. Più economico del modello che sostituisce, più economico del modello che rimpiazza, e avanti rispetto a entrambi nell'indice.

Due avvertenze vanno apposte sul numero. È un composito di dieci valutazioni eseguite al massimo sforzo di ragionamento, quindi non dice nulla sulle impostazioni di sforzo inferiori che la maggior parte del traffico di produzione usa effettivamente, né su come la qualità si mantenga all'estremità di una finestra da 1M token. Ed è il punteggio di un singolo valutatore: indipendente, ma non replicato — e il composito stesso è stato rivisto da quando questo articolo lo ha citato per la prima volta, da v4.3 a v4.3.2, il che ha spostato il punteggio di DeepSeek V4.1 Flash da 40 a 39 e quello del suo predecessore da 35 a 34. Ciò che invece stabilisce è ristretto e utile — l'unica affermazione che la beta non poteva sostenere, cioè che un modello da 552B è davvero competitivo con il flagship da 1.6T di DeepSeek, ora ha una fonte esterna a DeepSeek. La riga 1017 porta le stesse due avvertenze e una in più. È il punteggio di un singolo valutatore, per pesi più recenti di cinque settimane rispetto alla maggior parte delle prove qui, ed è un singolo composito anziché una replica di qualsiasi riga di fornitore. Anche il suo prezzo per task è cambiato sul sito: il checkpoint di settembre è oggi indicato a $0.49 per task dell'Intelligence Index, dove questo articolo riportava inizialmente $0.27, e il checkpoint 1017 a $0.26. Trattate la cifra in dollari come un numero variabile sulla dashboard di qualcun altro, non come una costante — la stessa lezione che il punteggio dell'indice stesso ha impartito quando è passato da 40 a 39. La tabella dei costi accanto al punteggio è il resto dell'avvertenza, e vale in entrambi i sensi. Il modello un posto sopra è anche a metà del suo prezzo: MiMo-V2.6-Pro raggiunge 46 a $0.13 per task dell'Intelligence Index contro $0.26 qui, e il confronto di Artificial Analysis stesso colloca GPT-6.1 Sol a sforzo medio a 48 per $0.21. Ciò che il checkpoint 1017 vince è il confronto testa a testa che DeepSeek pubblicizza da settembre — batte GLM-5.3-Flash su entrambi gli assi di quella tabella, 45 contro 42 e $0.26 contro $0.28 a task — che è l'accoppiata in cui capacità e costo si muovono nella stessa direzione.

Il prossimo punteggio esterno: ARC Prize sta costruendo il test

Il 25 settembre, il responsabile dei test dei modelli di ARC Prize, Matt Mazur, ha aperto una pull request nel repository di benchmarking ARC-AGI-3 della fondazione stessa, aggiungendo un adattatore per provider DeepSeek di prima classe: un profilo, denominato deepseek-v4-1-flash-low-provider-adapter, il cui campo model è deepseek-ai/DeepSeek-V4.1-Flash. L'affermazione che ARC Prize intenda valutare questo modello è arrivata come un singolo post sui social, così l'abbiamo verificata sul codice della fondazione stessa piuttosto che sul post. L'adattatore, il profilo, i suoi unit test e la sua documentazione sono nel diff, e il repository è l'harness che la politica di testing di ARC Prize indica per il suo benchmark agentico interattivo. Ciò che non esiste è un risultato: la pull request è aperta e non è stata unita, non c'è alcun punteggio, né una data di pubblicazione, né una dichiarazione su quali livelli di ragionamento saranno pubblicati. Ciò che conta è la forma della misurazione, più che la notizia che ne arriverà una. ARC-AGI pone una domanda che gli altri board non pongono: un modello può essere veloce, economico e forte all'interno di un harness e ottenere comunque un punteggio intorno ai sessanta su compiti che non ha visto. Questa è la domanda che nessuno ha ancora posto a DeepSeek V4.1 Flash.

Il profilo stabilisce come funzionerebbe un'esecuzione di questo tipo, e tre dettagli influenzeranno il numero che alla fine verrà fuori. Esegue il modello con l'impostazione a basso sforzo di ragionamento anziché al massimo, trasmette le risposte in streaming, imposta un contesto dell'harness da 1M token con un trigger di compattazione del riepilogo a 175.000 token e limita l'output a 262.144 token. Passa attraverso l'endpoint compatibile con OpenAI di Baseten invece che attraverso quello di DeepSeek, ed è configurato a 0,30 $ per 1M token di input e 1,20 $ per 1M token di output — le tariffe di punta del listino DeepSeek, non le cifre non di punta citate più avanti in questo articolo. ARC Prize calcola il costo per attività a partire dai prezzi configurati nel profilo, quindi la cifra finale sarà basata su tariffe di punta, cosa da tenere a mente prima di confrontarla con i 0,042 $ per attività registrati da DeepSeek V4 Flash 0731 quando è stato testato. L'altra caratteristica insolita è una soluzione alternativa al modo in cui si comporta la modalità di pensiero di DeepSeek: il contenuto di ragionamento storico viene riprodotto solo quando una richiesta include strumenti, quindi l'adattatore fa sì che il modello emetta ogni azione ARC come una chiamata di strumento submit_action e riproduce il messaggio esatto dell'assistente con il suo ragionamento allegato, invece di estrarre le azioni dalla prosa.

Il termine di paragone rispetto al quale questo sarà misurato proviene dalla classifica di ARC Prize. DeepSeek V4 Flash 0731, il checkpoint che V4.1 Flash ritira, è la voce verificata della classifica per il livello Flash da cui proviene: 61,4% su ARC-AGI-2 al massimo sforzo di ragionamento e 89,0% su ARC-AGI-1, a $0,042 e $0,021 per attività. Dots3-Note Preview si attesta al 76,8% su ARC-AGI-2, che è il 77% a cui punta il post che ha segnalato l'adattatore, e l'aspettativa dello stesso account — che qualsiasi cosa sotto l'80% da un successore molto più grande e nativamente multimodale sarebbe deludente — è la sua interpretazione piuttosto che un obiettivo pubblicato. La parte restante di quell'interpretazione merita un'etichetta: l'affermazione che V4.1 Flash genera il 29% in più di token rispetto al modello che sostituisce è senza attribuzione e indefinita, e nulla che DeepSeek o ARC Prize abbiano pubblicato dice cosa misura.

Un avvertimento su quale board sia questa. L'adapter è approdato nel repository ARC-AGI-3, l'harness per il benchmark agentico interattivo della fondazione, e il repository separato che esegue ARC-AGI-1 e ARC-AGI-2 non contiene alcuna voce V4.1 — la sua lista di modelli non è aggiornata dal 27 luglio e nomina ancora endpoint DeepSeek più vecchi. Quindi il fatto databile è che ARC Prize ha collegato questo modello al suo harness agentico; se comparirà anche sulla board ARC-AGI-2, dove vive il confronto al 61,4%, non è qualcosa che il codice pubblico mostra oggi. La lettura pratica per chiunque scelga un modello si è ampliata. Quattro strumenti indipendenti su DeepSeek V4.1 Flash sono ora in gioco — un indice composito che è stato eseguito due volte, una per checkpoint; una board di kernel della community; un benchmark cyber controllato dall'harness; e, dal 14 ottobre, un benchmark di serving hardware — e due di essi collocano il modello dentro un harness su task che non ha visto. Il più recente dei due è il composito, che porta Terminal-Bench 4.0 dal v4.3 dell'indice: 66 task da terminale, pass@1 mediato su tre ripetizioni, ogni modello sotto lo stesso harness agentico. Il suo risultato del 18 ottobre per i pesi 1017 è 33,8. Il benchmark cyber, sotto, è quello che più si avvicina tra tutti, e su di esso questo modello perde l'unico confronto testa a testa che effettua. Il profilo ARC è la valutazione costruita per rispondere alla domanda sul ragionamento, ed è ancora quella senza un numero. Finché non viene eseguita, il tetto di ragionamento del modello è non misurato, e il numero con cui confrontarlo è quello del suo predecessore.

Il primo punteggio cyber esterno: l'harness sposta il numero più del modello

Il 28 settembre il laboratorio di valutazione Generality Labs ha pubblicato un seguito del suo precedente lavoro cyber intitolato «L'harness conta quando si eseguono i Cyber Benchmark?» — la prima misurazione esterna completata che mette DeepSeek V4.1 Flash accanto a un altro modello open-weight sullo stesso cyber benchmark. Il benchmark è Exploit Bench, una valutazione della Carnegie Mellon di Seunghyun Lee e del prof. David Brumley che assegna un punteggio a quanto un agente risale una scala di sedici capacità — dal raggiungimento di codice vulnerabile, all'innesco del bug, alla costruzione di primitive di exploit, fino all'esecuzione arbitraria di codice — contro V8 di produzione con la sandbox di sicurezza V8 abilitata. Il laboratorio ha eseguito due modelli, DeepSeek V4.1 Flash e GLM-5.3-Flash di Z.ai, con un budget di 250 milioni di token per attività su 10 attività estratte dalle 41 originali del benchmark tramite Item Response Theory, e ha ripetuto ciascun modello in sette configurazioni di harness: sei CLI per agenti — Claude Code, Codex, Kimi CLI, ReAct, Gemini CLI e OpenCode — più il default del benchmark stesso, che il resoconto etichetta come Original. Original non è affatto una CLI di terze parti: non ha limite di token, ha un tetto di 300 turni e nessuna compattazione del contesto. L'account che ha segnalato questo risultato descrive Original all'incirca come un ciclo while di Python; questa è la sua caratterizzazione, non quella dei ricercatori, la cui descrizione è quella riportata sopra.

Il risultato è una dispersione che nessun singolo punteggio avrebbe mostrato. La capacità media è su 16. DeepSeek V4.1 Flash dà il meglio di sé con Claude Code, 9,3, con Codex secondo a 8,9; lo stesso modello scende a 7,4 su Kimi CLI, 5,9 su OpenCode, 5,7 su Gemini CLI, 5,3 su ReAct e 4,7 con Original — l'impostazione predefinita del suo stesso benchmark, nonché il peggiore dei sette. GLM-5.3-Flash inverte quella classifica a entrambe le estremità. La sua configurazione migliore è Codex a 10,6, superiore al 10,02 che il dataset dello studio riporta per Mythos Preview sull'intero set di 41 attività, benché i ricercatori avvertano che un sottoinsieme di 10 campioni non sia pienamente rappresentativo; la sua peggiore è Claude Code a 6,2, lo stesso harness che è il migliore di DeepSeek V4.1 Flash, e 8,9 su Gemini CLI, 8,2 su Kimi CLI, 8,1 su OpenCode, 7,7 su ReAct e 6,4 con Original. Facendo la media su tutti e sette, GLM-5.3-Flash si colloca vicino a 8,0 e DeepSeek V4.1 Flash vicino a 6,7. Quindi entrambe le metà dell'affermazione che è circolata con questo risultato trovano conferma nei dati pubblicati: la scelta dell'harness vale diversi punti, e su questo benchmark DeepSeek V4.1 Flash è il più debole dei due modelli — tranne che con Claude Code, dove è in vantaggio di oltre tre.

I ricercatori sono espliciti sul fatto che non possono spiegare completamente lo scarto. Il loro unico indizio positivo è il modo in cui ciascun harness compatta il contesto, e la differenza è una questione di formulazione. Il prompt di compattazione di ReAct chiede al modello di “Scrivere un riassunto di continuazione che ti permetta (o a un'altra istanza di te stesso) di riprendere il lavoro”; nelle trascrizioni pubblicate dal laboratorio, ciò a volte porta il modello a dichiarare il lavoro finito, dopodiché l'harness lo risveglia di nuovo e lui invia di nuovo lo stesso rapporto decine di volte finché il budget non si esaurisce. Codex inquadra lo stesso momento come “Crea un riassunto di passaggio per un altro LLM che riprenderà il compito”, e il laboratorio ipotizza che rivolgersi a un agente diverso sia ciò che mantiene il modello in progresso su budget lunghi. La chiamano un'ipotesi, non una causa. Un errore di configurazione conta anche per la lettura della tabella: la compattazione di ReAct era impostata a 100K token invece del trigger previsto, quindi compattava molto più spesso di quanto previsto dal design, il che abbassa le righe ReAct di entrambi i modelli. Le avvertenze dello studio stesso vanno tenute presenti con qualsiasi numero da esso — due modelli, 10 campioni per configurazione di harness, 70 campioni di domande per modello rispetto ai 41 compiti originali del benchmark, e tre campioni che hanno dato errore o non sono mai terminati, due dei quali GLM-5.3-Flash. Gli autori affermano che il campione ridotto è intrinsecamente rumoroso, che non si deve presumere che il risultato si estenda ad altri domini e compiti, e che un lavoro precedente di METR non ha trovato differenze statisticamente significative tra harness su compiti a lungo orizzonte. È un laboratorio esterno che esegue il benchmark di qualcun altro, non i proprietari del benchmark, e non è sottoposto a revisione paritaria. Ciò che non è è una cifra di un fornitore, ed è il primo numero esterno in questo articolo che contraddice la versione del fornitore stesso anziché limitarsi a non confermarla.

C'è una cosa, qui, su cui un router può agire e una su cui non può. Non può scegliere il vostro harness — quello è l'agent loop che già eseguite, e il punto centrale di questo studio è che la scelta è portante. Quello che può fare è rendere la metà modello della coppia una modifica di una sola riga. DeepSeek V4.1 Flash e GLM-5.3-Flash sono entrambi instradabili tramite OrcaRouter con una singola chiave compatibile con OpenAI, al prezzo di listino del provider stesso con 0% di markup aggiunto, così un team che vuole trovare la propria combinazione di modello e harness può sostituire il modello sotto un harness fisso senza un secondo contratto o una seconda integrazione, e lasciare dietro di sé un modello collaudato come failover automatico se la sostituzione si rivela una regressione. È lo stesso argomento che la sezione sull'adozione espone più sotto, applicato a una decisione che lo studio sull'harness ha appena reso concreta: su queste evidenze, l'harness che eseguite può contare più del modello che scegliete, e il lato modello di quella coppia è il lato che potete cambiare in un pomeriggio.

Dove si colloca rispetto alla frontiera, e dove perde ancora.

La scheda modello di settembre confronta V4.1 Flash con Opus-5.0, GPT-5.6 Sol, Kimi K3 e GLM-5.3 al massimo sforzo di ragionamento, con i suoi DeepSeek V4 Pro e DeepSeek V4 Flash come baseline interne. Ogni cifra riportata di seguito è dichiarata dal fornitore, ottenuta con gli harness di DeepSeek e non riprodotta da alcuna terza parte. La scheda precisa che i risultati agentici utilizzano la modalità Minimal di DeepSeek Harness con un contesto da 1M token per i benchmark di codice e una finestra da 512K per quelli visivi, pertanto non sono direttamente comparabili con i numeri di terze parti pubblicati sugli stessi benchmark. I punteggi indipendenti nelle sezioni precedenti sono misurazioni diverse su insiemi diversi di valutazioni; supportano il quadro generale e non corroborano alcuna singola riga riportata di seguito, e le righe del 17 ottobre nella sezione precedente provengono da una scheda diversa e da un'esecuzione diversa degli stessi benchmark.

Nel lavoro agentico e di coding, i dati del fornitore pongono V4.1 Flash al di sopra dei modelli frontier che nomina:

• Terminal-Bench 2.1 — 90.6, contro 89.1 per Opus-5.0, 88.8 per GPT-5.6 Sol e 87.9 per DeepSeek V4 Pro

• DeepSWE v1.1 — 74.2 risolti, contro 74.0, 73.0 e 62.7

• CyberGym — 88,1, contro 84,5 sia per GPT-5.6 Sol che per GLM-5.3, e 83,3 per DeepSeek V4 Pro

• AutomationBench — 54.8, contro 50.3 per Opus-5.0 e 37.7 per DeepSeek V4 Flash

• Agent's Last Exam — 31.8, contro 28.6 e 25.7

• Codeforces — un rating di 3.471, davanti a DeepSeek V4 Pro con 3.348 e DeepSeek V4 Flash con 3.289

• MathArena Apex — 65.6, alla pari con Kimi K3 e davanti a DeepSeek V4 Pro con 65.3

E sulle suite agentiche più difficili non lo fa:

• Terminal-Bench 3.0 — 30.0, ben al di sotto di Opus-5.0 con 43.3 e GPT-5.6 Sol con 34.4, anche se molto avanti rispetto a DeepSeek V4 Pro con 11.8

• Terminal-Bench 4.0 — 31.2, contro 51.8 e 39.9, e di nuovo davanti a DeepSeek V4 Pro su 12.4

• ProgramBench — 20.3, contro 37.0 per Opus-5.0

• NL2Repo-Bench — 64,0, contro 75,3 per Opus-5.0

• HLE — 36,8, contro 56,3 e 44,5

• ExploitGym — 15.3, contro 33.7 e 22.1

La forma di quell'elenco è più informativa di qualsiasi singola riga. V4.1 Flash supera la frontiera sui benchmark che premiano l'uso prolungato degli strumenti all'interno di un harness, e perde su quelli che premiano la profondità di ragionamento — il pattern che ci si aspetterebbe da un modello progettato attorno a throughput ed economia del contesto anziché attorno a un tetto massimo di ragionamento grezzo. Il confronto interno è quello sorprendente: batte DeepSeek V4 Pro su essenzialmente ogni riga, comprese le righe in cui entrambi perdono contro Opus-5.0. DeepSeek non sta affermando che il suo modello più economico sia il migliore sul mercato. Sta affermando che il suo modello più economico è il migliore che DeepSeek produca, un'affermazione che la sua stessa tabella di routing supporta.

Quanto costa e come si presenta effettivamente il confronto con Pro.

Il listino prezzi del 10 settembre ora è semplicemente la scheda V4.1 Flash, pubblicata nella pagina Models & Pricing di DeepSeek con una distinzione tra fascia di punta e fascia non di punta:

• Input, cache hit — $0.003 per 1M token fuori punta, $0.006 in punta

• Input, cache miss — $0,15 per 1M token fuori punta, $0,30 in punta

• Output — $0,60 per 1M token fuori punta, $1,20 in punta

• Fasce di punta — 01:00–04:00 e 06:00–10:00 UTC, da lunedì a venerdì; ogni altra ora viene fatturata a metà della tariffa di punta

• In renminbi — ¥0,02, ¥1 e ¥4 fuori punta, che raddoppiano a ¥0,04, ¥2 e ¥8 nelle ore di punta

Confrontalo con il modello che sta sostituendo. DeepSeek V4 Pro addebita $0.022 per 1M di input con cache hit, $0.66 di input con cache miss e $1.98 di output fuori picco — circa 4,4× sull'input con cache miss e 3,3× sull'output. Questi sono i numeri che il reindirizzamento del 14 settembre avrebbe applicato a ogni chiamata a deepseek-v4-pro, ed è per questo che il piano era una questione di prezzo tanto quanto di capacità; sono ancora il motivo per cui il confronto conta: DeepSeek ha ritirato il reindirizzamento, non il listino tariffario. Artificial Analysis arriva allo stesso calcolo dai propri listini — $0.30 e $1.20 per 1M per V4.1 Flash contro $1.32 e $3.96 per DeepSeek V4 Pro 0813, gli stessi 4,4× e 3,3×, e un valore misto di $0.18 per 1M sul mix 7:2:1 di cache hit, input e output del sito. Il listino è anche più basso di DeepSeek V4 Flash 0731, il modello che ritira, che lo stesso sito indica a $0.44 e $1.32.

Il prezzo per token non è il costo per attività, e la beta ne è la prova. I tester del primo giorno hanno segnalato che sessioni di cinque minuti prosciugavano il loro saldo più rapidamente sul nuovo modello rispetto allo stesso tempo reale su DeepSeek V4 Flash, perché il modello è progettato per emettere token rapidamente e l'addebito cresce in proporzione ai token, non ai minuti. Una card che costa un quarto del prezzo di Pro è un affare se un'attività si conclude con un numero comparabile di token; è un pareggio se il modello ragiona più a lungo per arrivarci.

Dove un numero esterno su quella questione esiste davvero, indica due direzioni opposte. Artificial Analysis colloca DeepSeek V4.1 Flash a $0.27 per task dell’Intelligence Index sul proprio set di valutazione — una cifra reale per task, prodotta fuori da DeepSeek, e bassa. Ma la stessa esecuzione ha generato 250M token di output contro una mediana di 140M per modelli comparabili, e il riepilogo del sito definisce il modello molto verboso nello stesso fiato in cui lo definisce veloce. La verbosità è gratuita dentro un harness di benchmark ed è costosa in produzione, che è esattamente il meccanismo che i beta tester stavano descrivendo quando hanno riferito che i saldi si prosciugavano più rapidamente in termini di tempo reale. Lo stato onesto della questione per task è che un valutatore indipendente ne ha ora misurato entrambe le metà, sul proprio set di valutazione, e la risposta dipende ancora da ciò che si sta eseguendo. Il composito non può mostrare dove finisca l’output in più, e nemmeno i beta tester lo hanno detto. I primi resoconti di prova diretta lo fanno, e si trovano nella sezione velocità qui sotto: il modello è verboso perché sta verificando. L’aggiornamento del 17 ottobre è la prima volta che DeepSeek afferma di aver spostato quel numero: il changelog dice che il nuovo checkpoint “riduce il tempo di esecuzione delle attività e la lunghezza dell’output”, e il post poche ore dopo dice la stessa cosa in meno parole — “completamento delle attività più rapido e output più brevi”. Questo è DeepSeek che affronta, di propria iniziativa, l’esatta quantità di cui si lamentava la misurazione esterna, senza alcuna cifra allegata a nessuna delle due affermazioni. Il primo sguardo esterno, il 18 ottobre, ha rilevato il volume aggregato in calo — 210 milioni di token di output sull’indice contro 250 milioni per settembre — e la cifra per task piatta, a 89.495 token contro 88.574.

Quanto costa un mese: un'indennità di 80 $, poi un piano gratuito

La scheda qui sopra risponde a quanto costa un token. Una cifra diversa si è mossa due volte, ed entrambe le volte è arrivata da OpenCode — l'agente di programmazione la cui sottoscrizione Go prezza l'accesso a questo modello come una quota di utilizzo mensile anziché come token a consumo — parlando della propria sottoscrizione anziché del modello. Il 25 settembre l'account della piattaforma ha pubblicato: “Operazione Cheepseek Fase 2: $60 di utilizzo per DeepSeek v4.1 Flash è ora permanente”. Il 12 ottobre ha pubblicato il seguito nello stesso formato — “Operazione Cheepseek Fase 3: $80 di utilizzo per DeepSeek V4.1 Flash” — e la sua pagina dei prezzi riportava $80 per questo modello, dove a fine settembre riportava $60. Quella lettura è stata effettuata una seconda volta il 13 ottobre, sulla stessa pagina, e ha restituito la stessa riga: $80 sul piano Go da $10 al mese, $160 su Go Plus. La cifra, quindi, non è l'affermazione di un singolo post su sé stesso; è il prezzo pubblicato da una piattaforma per ospitare questo modello, ed era ancora lì un giorno dopo. Letti insieme, i due post dicono cosa “permanent” abbia finito per significare: nessuna data di scadenza — e un numero più alto tre settimane dopo. Quel cambiamento non è un nuovo modo di raggiungere il modello — quello arriva tre giorni dopo, nel paragrafo qui sotto. DeepSeek V4.1 Flash risponde sull'API di DeepSeek stessa dal 10 settembre e OrcaRouter lo ospita alle tariffe di DeepSeek stessa dal rilascio, quindi i pesi, l'architettura e ogni riga di benchmark in questo articolo non sono toccati da una riprezzatura dell'abbonamento; ciò che ottobre ha cambiato è chi è disposto a ospitare il modello e a quali condizioni.

L'ingresso gratuito è un tipo di cambiamento diverso da entrambi gli altri, e l'unico dei tre che cambia ciò che un lettore può fare questa settimana. Il 15 ottobre OpenCode ha aggiunto una voce separata per questo modello — DeepSeek V4.1 Flash Free, id del modello deepseek-v4.1-flash-free — erogato senza alcun costo. L'elenco pubblico dei modelli della piattaforma lo restituisce accanto all'id a consumo, la sua documentazione della Console contiene una voce sui modelli gratuiti che lo descrive come gratuito per un periodo limitato e il suo fornitore come soggetto a una politica di conservazione zero che non addestra sui dati, e la sua tabella prezzi pubblicata colloca input, output e letture in cache alla voce Free. Ciò che non è, è il prodotto completo. I limiti catalogati della voce gratuita — aggiunti a models.dev, il catalogo da cui è tratta la lista di modelli di OpenCode stessa, il 15 ottobre — indicano la voce a consumo come modello di base e fissano la finestra a 200.000 token con un tetto di output di 32.000 token, contro il contesto da 1M e l'output massimo di 384K della voce a consumo deepseek-v4.1-flash. Si tratta degli stessi pesi dietro condizioni di erogazione più strette, non di un modello più piccolo o distillato, e il tetto di output è la clausola che morde per prima sul lavoro agentico, dove una singola modifica a un file può superarlo. La piattaforma non fissa alcuna data di fine per l'accordo e non pubblica alcuno scadenziario tariffario, perché non esiste una tariffa. Nulla di tutto ciò proviene da DeepSeek: è la decisione commerciale di una singola piattaforma riguardo a un modello che non possiede, dichiarata sulla propria lista di modelli, sulla propria documentazione e sulla propria tabella prezzi, ed è l'unica fonte per tutto quanto sopra — non abbiamo trovato alcuna misurazione indipendente di come si comporta l'endpoint gratuito sotto carico, e "periodo limitato" è l'espressione della piattaforma, non un calendario. Leggilo come il modo più economico per mettere una finestra da 200.000 token davanti a questo modello oggi, e non come un cambiamento di ciò che il modello è.

I meccanismi arrivano da quella pagina dei prezzi, letta il 12 ottobre e riletta il 13 ottobre. Go è un abbonamento da $10 al mese, e la sua tabella abbina ogni modello presente con un numero stimato di richieste ogni cinque ore e un limite di utilizzo mensile, in colonne separate per i due livelli. DeepSeek V4.1 Flash ha la quota più ampia della pagina: $80 al mese e 34.670 richieste stimate ogni cinque ore su Go, che raddoppiano a $160 e 69.330 su Go Plus. Le righe fatturano il modello secondo la scheda tariffaria di DeepSeek — $0,15 per 1M token di input, $0,60 di output e $0,003 per una lettura in cache fuori dalle ore di punta, che raddoppiano a $0,30, $1,20 e $0,006 nelle finestre di picco dei giorni feriali — e questi sono i dati del fornitore, invariati rispetto alla lettura di settembre che questa sezione riportava già. Due cose che la pagina mostrava allora non compaiono oggi, ed entrambe meritano di essere segnalate perché la lettura precedente si basava su di esse: la regola di consumo a tre bucket — 20% su qualsiasi intervallo di cinque ore, 50% nell'arco di una settimana e 100% nell'arco di un mese — non compare più, e l'URL della documentazione da cui erano state lette in origine le stime delle richieste, opencode.ai/docs/go, ha restituito 404 quando abbiamo controllato. I conteggi delle richieste sopra riportati sono il calcolo aritmetico della piattaforma su una forma di chiamata che essa non pubblica, non il nostro.

La modifica è verificabile sulla pagina, e lo è anche il fatto che ormai ce ne sia stata più di una. A fine settembre le stesse righe riportavano $60 senza alcuna scadenza associata, dopo che una quota promozionale di $15 era stata moltiplicata per quattro fino a $60 e riportava il 20 settembre come data di scadenza del moltiplicatore; le stime delle richieste erano pubblicate su due colonne, 6,500 / 16,250 / 32,500 standard contro 26,000 / 65,000 / 130,000 con il moltiplicatore applicato. Le righe riportavano $80 in entrambe le letture, e le stime pubblicate per questo modello sono 34,670 ogni cinque ore e 69,330 al mese — una quota in dollari più alta accanto a un numero mensile di richieste più basso rispetto all'insieme ampliato di settembre, e le due cose non possono descrivere entrambe lo stesso profilo di chiamata ipotizzato. La pagina non indica alcun mix di token e non offre spiegazioni, quindi la differenza è un fatto relativo alle due letture, non qualcosa che possiamo risolvere dall'esterno. Le tariffe stesse non sono mai state uno sconto sul listino di DeepSeek — il prezzo per token è sempre stato quello del fornitore, e lo è ancora. Ciò che una quota non fa è dire qualcosa sulla qualità: è il giudizio di una piattaforma secondo cui può sostenere il traffico di questo modello a quelle tariffe senza una scadenza, il che è una prova riguardante l'ecosistema di serving più che il modello.

La distinzione conta quando scegli, perché un tetto fisso e un contatore pass-through sono prodotti diversi. DeepSeek V4.1 Flash è su OrcaRouter alla tariffa di DeepSeek con 0% di ricarico — $0,15 per 1M di input e $0,60 per 1M di output fuori picco, gli stessi numeri elencati nella scheda sopra, senza nulla incluso intorno: nessun abbonamento da acquistare e nessuna quota mensile da esaurire. Un tetto di $80 su un prezzo mensile fisso è la forma giusta per uno sviluppatore che esegue un agente tutto il giorno, dove la domanda è quanto costa il mese — e un tetto già aumentato una volta, di un terzo, è anche un promemoria che la cifra è una decisione commerciale anziché una proprietà del modello. Un livello gratuito con una finestra di 200.000 token è la forma giusta per provare il modello questa settimana e la forma sbagliata per le codebase che richiedono la finestra completa, che è l'unica cosa che i due livelli dello stesso modello non condividono. Una tariffa del fornitore trasmessa invariata è la forma giusta per un servizio, dove la domanda è quanto costa ogni chiamata e se il prossimo movimento di prezzo del fornitore ti raggiunge il giorno in cui avviene. Entrambi rispondono a quanto costa questo modello; rispondono per profili di spesa diversi.

Velocità: i numeri della beta, la dichiarazione del produttore e il prima e dopo del motore stesso

Quando la beta è stata aperta, il throughput era la notizia principale. Gli sviluppatori hanno segnalato circa 420 token di output al secondo in generazioni lunghe, con picchi oltre 500, e un'esecuzione ampiamente condivisa ha prodotto più di 71.000 token in meno di tre minuti. Quelle restano misurazioni della comunità effettuate in condizioni non controllate e dovrebbero ancora essere lette in quel modo — ma il meccanismo dietro di esse ora è documentato anziché congetturato. Una KV cache da 890 byte per token e un percorso di decodifica che attiva 16 miliardi di parametri sono un design pensato per il throughput, quindi l'architettura è almeno della forma giusta per produrre numeri come quelli. Quanto siano realmente grandi è il problema del paragrafo successivo, e la risposta è più piccola.

L’affermazione di DeepSeek stessa, nel changelog, è che V4.1 Flash “ha superato in modo completo V4 Pro in prestazioni, costo, velocità e tempo totale”. La parola che qui fa il lavoro è tempo totale: è il modo in cui il fornitore inquadra la velocità come completamento del compito anziché come token al secondo, che è la metrica che resiste al contatto con un vero ciclo di agente che scrive un file, legge l’errore e riprova. Artificial Analysis ora assegna un dato misurato alla vecchia affermazione: 185 token di output al secondo per DeepSeek V4.1 Flash, contro 175 per DeepSeek V4 Flash 0731. Questo è un numero reale di una terza parte ed è circa la metà dei 420 token al secondo riportati dagli sviluppatori durante la beta, motivo per cui i dati della beta dovrebbero restare dove appartengono — nella colonna delle condizioni non controllate.

Il 7 ottobre il progetto vLLM ha pubblicato il proprio resoconto delle tre settimane successive al rilascio, ed è il primo dato di velocità misurato in questo articolo che non sia né un contatore di token né uno slogan commerciale. A scrivere sono Inferact e il team vLLM: il progetto riporta che DeepSeek V4.1 Flash, sulla sua build corrente, è 1,9× più veloce della propria implementazione day-0 a bassa concorrenza e offre 5,3× il throughput con un vincolo di 150 TPS — il dato riportato nel suo riepilogo, rispetto a “circa 5×” nel corpo dello stesso post. Entrambi sono misurati sul benchmark agentico di serving SemiAnalysis AgentX, con TP4 e l’attenzione FlashInfer dietro il dato di bassa latenza e DEP2 con attenzione data-parallel dietro quello di throughput, su hardware NVIDIA GB200 e GB300. Tre cose di quel risultato meritano di essere tenute ben chiare. Confronta vLLM con vLLM: la baseline è la ricetta day-0 del progetto stesso, non un altro motore né un altro modello, quindi il numero dice quanto è migliorato lo stack di serving, non come questo modello si confronti con qualsiasi altra cosa. È il resoconto del runtime sul proprio lavoro, e nessuna terza parte lo ha riprodotto. E il maggior guadagno singolo viene dal runtime, non dai pesi: SWA bounded replay, che riesegue solo gli ultimi 128 token di una finestra scorrevole invece di riprodurre quella finestra attraverso i layer, ora è attivo per impostazione predefinita per questo modello dietro un singolo flag. Il progetto riporta circa il 30% in meno di tempo al primo token grazie a replay e cattura CUDA-graph, una riduzione del 30–40% del calcolo di prefill grazie al trim lato decoder e quasi il 70% in meno di TTFT a circa 100K di throughput quando tre ottimizzazioni si sommano. Riporta anche dove il replay penalizza: senza CUDA graphs è più lento della baseline sui prompt brevi, fino al 12% peggio a 1K token, perché l’overhead di lancio supera il lavoro risparmiato. L’accuratezza è stata verificata su GSM8K e GPQA senza differenze significative riportate, con scarti entro circa 1,5 errori standard: il dato da tenere presente rispetto all’affermazione del report stesso che il bounded replay è approssimativo e non esatto. Il progetto aggiunge che il modello non ha richiesto alcun offloading della KV-cache in nessun punto del benchmark e si aspetta che l’offloading inizi a convenire solo a concorrenza più elevata, con prefill e decode suddivisi tra macchine. Si tratta di una misurazione diversa dalla kernel board qui sotto, che valuta i kernel scritti dal modello; i dati di vLLM riguardano quanto costa servire il modello una volta che un motore ne ha implementato l’architettura, e il motore qui è quello che riporta. Il progetto ha pubblicato un altro post il 17 ottobre, il giorno in cui DeepSeek ha sostituito il checkpoint, e il numero con cui ha aperto era un tipo diverso di dato: 1,3B token per dollaro di costo totale di proprietà su SemiAnalysis AgentX, a 830.000 token al secondo per GPU contando insieme token in cache, di input e di output, mantenendo 100 token di output al secondo per ogni utente. È un risultato di costo di serving più che un delta di velocità, e la sezione sul costo di serving qui sotto lo analizza in dettaglio. Tre cose al riguardo sono rilevanti per questo paragrafo: sono lo stesso progetto, lo stesso modello e lo stesso benchmark a tre settimane dal resoconto del 7 ottobre; il progetto inquadra quel resoconto come capitolo uno, a 5x il throughput agentico del giorno zero, con un capitolo successivo ancora in arrivo, e da allora sul suo blog non è apparso un secondo post di DeepSeek; e una curva dei costi resta comunque il lato del runtime nel bilancio, non un verdetto esterno sul modello. Questa distinzione è anche il motivo per cui questo numero conta per chi non eseguirà mai un nodo. Nessuno di questi lavori è lavoro svolto da chi effettua la chiamata: uno stack di serving che diventa 1,9× più veloce a bassa concorrenza rende più veloci le richieste che gestisce, e raggiungere questo modello tramite un’API è il modo in cui la maggior parte dei team ne trarrà beneficio senza possedere l’hardware. DeepSeek V4.1 Flash è su OrcaRouter alla tariffa di DeepSeek stessa con 0% di markup, sulla stessa chiave compatibile con OpenAI del resto della gamma, con un modello collaudato alle spalle come failover automatico: il modello e i prezzi si muovono al ritmo del provider, e la scelta del motore resta dal lato del provider.

Quanto costa servire: i primi numeri indipendenti sull'hardware

Tutto quanto sopra misura il modello. Il 14 ottobre Artificial Analysis ha aggiunto DeepSeek V4.1 Flash ad AA-AgentPerf, il benchmark che esegue su sistemi acceleratori anziché su modelli, e il risultato è la prima risposta pubblica a una domanda che un listino prezzi non può risolvere: quanto di questo modello riesce a sostenere un megawatt di potenza di un datacenter. AA-AgentPerf riproduce sessioni registrate di agenti di programmazione — ragionamento multi-turno, chiamate a strumenti, contesti che superano i 100K token, inclusi i prompt cache hit — su uno stack di serving live e individua il numero massimo di agenti concorrenti che un sistema sostiene mentre ciascuno continua a rispettare un obiettivo di velocità per agente. Per questo modello il dato di punta è la soluzione rack-scale di NVIDIA. A 100 token di output al secondo per utente, GB300 NVL72 guida il gruppo con circa 261 milioni di token al secondo per megawatt, davanti a B300 con circa 220 milioni, B200 con 193 milioni, GB200 con 178 milioni e MI355X di AMD con 128 milioni. Sono i numeri di Artificial Analysis, letti oggi dalla sua pagina sull'inferenza nei datacenter, e sono le sue misurazioni di specifiche configurazioni hardware e di serving, non di un fornitore. Due dettagli meritano di essere ricordati. I numeri per megawatt sono calcolati dalla potenza dell'acceleratore misurata durante l'esecuzione — die GPU più HBM — anziché dal TDP nominale. E ogni punto del grafico indica il motore, la versione e il formato numerico che vi sono dietro, così il numero è un'affermazione su uno stack di serving e non solo sui pesi.

Il motivo per cui il grafico di questo modello appare diverso dagli altri è la sua dimensione. DeepSeek V4.1 Flash sta su appena due acceleratori, ed è per questo che un sistema su scala rack ottiene qui un vantaggio minore rispetto a un modello più grande: Artificial Analysis riporta che B300 resta entro circa il 20% rispetto a GB300 NVL72 lungo tutta la curva e lo supera a entrambe le estremità — il maggior throughput per megawatt quando si consente che la velocità per utente scenda, e l'agente singolo più veloce quando non lo si consente. Con batch size pari a uno, ogni componente Blackwell e la MI355X si collocano tra circa 600 e 670 token al secondo per un singolo utente, contro 372–392 su H100 e H200. Confrontato con DeepSeek V4 Pro 0813 sullo stesso asse, il modello più piccolo restituisce circa 1,3× il throughput per megawatt su GB300 e circa 6,2× su B200 in corrispondenza dei 100 tok/s — l'affermazione di efficienza che la sezione sull'architettura fa dal lato della KV-cache, proveniente da una terza parte che ha misurato un sistema anziché una specifica. Le configurazioni dietro quei numeri mostrano il trucco centrale del design in produzione anziché solo sulla carta: sia nelle esecuzioni a due acceleratori su B300 sia su MI355X, la tabella Engram da 196B viene servita dalla memoria host pinned tramite il percorso di CPU-offload di vLLM invece di risiedere sull'acceleratore — il meccanismo descritto nelle note di rilascio, ora visibile nella configurazione alla base di una misurazione pubblicata. Una seconda cifra di costo, in una valuta diversa, arriva dal benchmark su cui è stato misurato il post di vLLM del 7 ottobre. Il 17 ottobre il progetto vLLM ha pubblicato un grafico che colloca DeepSeek V4.1 Flash a 1,3 miliardi di token per dollaro di costo totale di proprietà su SemiAnalysis AgentX, con curve separate per GB300 NVL72 con Dynamo, GB200 NVL72, B200, H100 e MI300X. Il livello di costo alla base è etichettato owning at large-hyperscaler volume, e le ipotesi di costo per ora-chip sottostanti vanno da 0,95 $ per una MI300X e 1,17 $ per una H100 fino a 1,73 $ per una B200 e 2,31 $ per una GB300, tratte dall'indagine sui prezzi di SemiAnalysis stessa di luglio 2026. Due limiti vanno tenuti presenti. È il progetto vLLM a riportare il modello di costo di SemiAnalysis, e nessuna delle due parti lo ha visto replicato. Inoltre il grafico è datato 16 ottobre, il giorno prima che DeepSeek sostituisse i pesi dietro il nome del modello, quindi anch'esso descrive il checkpoint di settembre. Questo fa tre valute in questo articolo per un solo modello: token al secondo per utente, token al secondo per megawatt e token per dollaro. L'ultima è quella su cui un acquirente senza datacenter può agire, perché è la quantità sotto forma della quale il miglioramento dei costi di un fornitore finisce per raggiungerlo. Resta una misurazione di serving e non di qualità: nulla qui dice quanto sia buono il modello, e i risultati hardware di una classifica non sono una replica di alcuna riga di benchmark sopra riportata. Ciò che invece stabilisce è che il lato dei costi del listino di questo modello ora poggia su prove esterne. Un modello che un fornitore può servire a più volte il throughput per megawatt è un modello che un fornitore può permettersi di mantenere economico, e DeepSeek V4.1 Flash è su OrcaRouter al prezzo di listino di DeepSeek stesso con 0% di markup, che è la forma che trasmette il miglioramento dei costi di un fornitore invece di trattenerlo.

Quanto costa il motore sul silicio di due fornitori

Fino a questa settimana la domanda sul throughput di questo modello ha ricevuto risposta solo dalle misurazioni di altri — un runtime che rendiconta il proprio lavoro, un sito di benchmark che misura un sistema, sviluppatori che contano token in una beta. Questa settimana DeepSeek ha aperto DeepInfer, il framework che afferma alimentare il servizio di produzione di questo modello, con licenza Apache-2.0 — il repository è apparso il 16 ottobre e il primo commit è arrivato il 20 ottobre — e vi ha incluso un grafico Pareto di decodifica per il checkpoint 1017 misurato su 64 acceleratori SM100 all'interno di un unico dominio scale-up. La configurazione stampata sul grafico è la parte che conta, perché è la configurazione su cui verte il confronto seguente: expert parallelism di 64 su data parallelism di 64, i “384+64 esperti” stampati sul grafico, un contesto di 131.072 token, lunghezza del draft DSpark fissata a tre token e un tasso di accettazione per token del 75%. La curva raggiunge il massimo appena sotto i 30.000 token di output al secondo per acceleratore alla sua estremità meno interattiva, scende nella fascia dei 20.000 e passa quando la velocità per utente supera i 100 token al secondo, e arriva a poche migliaia al bordo destro del grafico. È DeepSeek che misura il proprio motore sul proprio modello, quindi non è un numero indipendente — ma è la prima curva di decodifica per questa architettura pubblicata dal laboratorio che l'ha costruita, e lo script di sweep che l'ha prodotta è nello stesso repository.

Il documento pubblicato accanto al codice fornisce il punto operativo, ed è il motivo per cui i numeri seguenti sono indicati a 230 token di output al secondo anziché a un qualche massimo astratto. Le cifre di produzione di DeepSeek indicano la decodifica a 14K token al secondo per acceleratore, mentre il servizio mantiene 230 token di output al secondo per utente — 300 nei carichi di lavoro di programmazione — con un tasso di successo della cache di input del 96%, un input medio di 77K token, un tempo medio al primo token di 400 ms e un p99 di un secondo, e il prefill dimensionato quasi in rapporto 1:1 con la decodifica, su un singolo cluster che, a suo dire, serve 155.000 miliardi di token al giorno. La voce di ricavo accanto a questi dati, 38 $ per ora-acceleratore con tariffa off-peak, è il primo dato di costo che DeepSeek abbia collegato pubblicamente all’erogazione di questo modello. Nessuno di questi dati è sottoposto a revisione, tutti provengono dal fornitore che descrive il proprio servizio, e resta comunque il quadro più concreto che esista di quanto costi gestire questa architettura.

L'altra metà del confronto proviene dal silicio di Huawei, ed è la metà con le fonti più deboli. Un foglio di benchmark datato 30 settembre e intitolato “Ascend 950DT DeepSeek-V4.1-Flash Benchmark” riporta il modello distribuito su 32 chip con precisione mista FP8–FP4, con attenzione data-parallel e mixture-of-experts expert-parallel, su una sequenza di 128K token, usando decodifica speculativa DSpark con una configurazione forzata del load-balancer expert-parallel e una lunghezza media accettata di 4,1 token. Contiene tre punti. La sua colonna della latenza è il tempo per token di output, quindi il reciproco di ogni voce è la velocità per utente di quella riga, ed è ciò che consente di sovrapporre il foglio alla curva:

• batch globale di 1.536, 9,41 ms per token di output — circa 106 token di output al secondo per utente — 5.102 token al secondo per chip.

• batch globale di 384, 4,40 ms per token di output — circa 227 token di output al secondo per utente — 2.727 token al secondo per chip.

• Batch globale di 2.560, 13,79 ms per token di output — circa 73 token di output al secondo per utente — 5.800 token al secondo per chip, il valore più alto nella tabella e quello utilizzato nel suo titolo.

Rapportate alla curva NVIDIA, le due righe centrali sono quelle che mordono, perché si collocano alle velocità a cui un servizio effettivamente gira. Il thread che ha fatto emergere il foglio legge il confronto come 25.500 token al secondo per acceleratore contro 5.102 a 100 token di output al secondo per utente, e 20.000 contro 2.727 a 230 — un divario di cinque volte al primo punto operativo e di 7,4× al secondo. Leggere direttamente la stessa curva pubblicata sposta quei numeri NVIDIA: una passata pixel sull'immagine si avvicina a 28.000 al traguardo dei 100 token e a 17.000 a 230, su entrambi i lati rispetto ai numeri del thread; la fascia che danno è di circa cinque volte e mezza al primo punto operativo e di circa sei al secondo, il che restringe l'intervallo del thread senza cambiarne la forma. Questo è il valore di un benchmark letto da un grafico, e non cambia la direzione del risultato. Vale anche la pena notare che il titolo di 5.800 del foglio è la sua riga meno interattiva — il punto in cui la curva NVIDIA è più vicina al proprio picco, e dove il rapporto torna a circa cinque.

Non sono riuscito a trovare quel foglio sulle pagine di DeepSeek o di Huawei; è arrivato a questo articolo come un'immagine allegata a un thread su X, e le tre cifre Ascend vanno lette come un benchmark del fornitore non pubblicato finché qualcuno non pubblica l'esecuzione che vi sta dietro. Ciò che è verificabile è l'asimmetria nelle configurazioni, e questa deriva dalla documentazione di DeepSeek stessa. Le note di distribuzione di DeepInfer raccomandano prefill con parallelismo degli esperti da 2 a 8 e decode da 64 a 128, su «macchine ordinarie con 8 GPU per il prefill, supernodi ordinari con 64–128 GPU per il decode». Su NVIDIA si tratta di un singolo dominio NVLink, che è il contesto all'interno del quale è stato misurato il grafico sopra. Su Ascend, la libreria di comunicazione di DeepSeek stessa dice chiaramente ciò che non è finito: «Le dimensioni EP più grandi e combine restano in fase di ottimizzazione», con combine che comporta un overhead aggiuntivo di riduzione locale e contesa HBM rispetto al percorso URMA, e con il lavoro sul firmware Huawei ancora da completare — un'avvertenza pubblica in DeepEP-Ascend fin dalla sua prima release del 29 settembre. Questo è il modo corretto di leggere il divario: il numero NVIDIA proviene dalla configurazione per cui DeepInfer è stato ottimizzato, e il numero Ascend da uno stack il cui stesso autore dice che il percorso wide-EP è ancora in fase di sviluppo. Una parte del divario da cinque a sette volte è il chip, una parte è l'interconnessione e il software che ci sta sotto, e nessuno ha separato le due cose.

Quanto vale in denaro il divario dipende da prezzi che nessuno ha pubblicato, e il thread fa comunque i calcoli: a circa 139.000 dollari per acceleratore Blackwell, estrapolati dai prezzi dei rack sul mercato grigio, contro i presunti 37.000 dollari per un 950DT, NVIDIA deve garantire circa 3,8 volte il throughput per chip per eguagliare Ascend già solo sul costo di acquisizione; il thread colloca il punto di incrocio vicino a 6.800 token al secondo per chip. I punti Ascend pubblicati si collocano sotto quella linea; la previsione del thread che il percorso wide-EP li porti a 8.000–10.000 si colloca sopra, e si tratta di una previsione, non di una misurazione. Ogni input è debole — un prezzo di mercato grigio, uno presunto e cifre ricavate da una curva — e nulla tiene conto di networking, alimentazione, raffreddamento, manutenzione o del valore di poter acquistare l'hardware.

Per chi non monterà mai un nodo in rack, la parte utile non è il tabellone. È che il modello più economico della linea DeepSeek è ora documentato come economico da servire sul silicio di due fornitori, con il motore proprietario del fornitore pubblicato e i numeri alla base scaricabili — il genere di prove su cui si fonda un prezzo. Non cambia alcun listino tariffario: DeepSeek V4.1 Flash è su OrcaRouter al prezzo di listino del fornitore, $0,15 per 1M di token di input e $0,60 per 1M di token di output alle tariffe fuori picco, trasferito con 0% di ricarico, così quando il costo di servizio di un fornitore scende, il risparmio arriva come un prezzo che non deve necessariamente muoversi anziché come margine di rivendita. Un costo di servizio messo in discussione sull'hardware di due fornitori è un prezzo con più margine di ribasso sotto di sé rispetto a uno che nessuno ha misurato affatto.

Ingegneria del kernel: il primo scoreboard che non è di DeepSeek

Le righe di benchmark sopra sono i numeri dell'harness di DeepSeek stesso, e i punteggi esterni che ora esistono misurano il ragionamento generale e lo sfruttamento cyber, piuttosto che la programmazione di basso livello. Esiste anche il primo sguardo di terze parti all'ingegneria dei kernel del modello, ed è arrivato in una forma che DeepSeek non ha commissionato: un benchmark agentico gestito dalla community che chiede ai modelli di scrivere veri kernel CUDA e valuta i risultati rispetto a una roofline — il limite teorico dell'hardware. La classifica è kernelbench.com, eseguita su una RTX PRO 6000, ed è indipendente da entrambi i fornitori. La sua metodologia di audit è riportata dalla community anziché sottoposta a peer review, quindi leggi le sue percentuali come un segnale direzionale di terze parti, non come una misurazione certificata; è anche il primo tabellone di questa storia in cui i numeri di DeepSeek si trovano accanto a quelli di un concorrente diretto.

La riga principale è quella su cui è costruita l'architettura. L'attenzione sparsa di DeepSeek V4.1 Flash — lo stack CSA2 che produce la cache da 890 byte per token — è stata scritta come kernel CUDA dal modello e ha raggiunto il 50,19% del roofline equivalente denso, quarto in classifica dietro Claude Fable 5.1 al 106,27%, Claude Opus 5 al 103,67% e Claude Fable 5 al 72,66%. La prima cosa da notare è che l'architettura del produttore stesso è il kernel in cui è più bravo: un modello addestrato su un design ad attenzione sparsa scrive il kernel di attenzione sparsa in modo più efficiente di qualsiasi altra cosa nella classifica sotto i primi tre. La seconda cosa è il confronto segnalato dall'informatore. Il tentativo di GLM-5.3 Flash sullo stesso kernel raggiunge il 4,45% del roofline — un ordine di grandezza in meno rispetto a V4.1 Flash sulla stessa riga della stessa classifica. Quel divario, non un qualsiasi benchmark pubblicato da DeepSeek, è ciò che significa «miglioramento massiccio nell'ingegneria dei kernel».

Il confronto non si ferma alla riga della sparse attention, e il quadro più completo conta perché il titolo del tweet nomina GLM-5.3 Flash mentre il resoconto citato a cui fa riferimento menziona in realtà un diverso e più grande GLM-5.2 sulla propria riga fused-MoE — una discrepanza di denominazione di cui vale la pena essere cauti. Sulle righe in cui entrambi i modelli di fascia flash hanno effettivamente completato un'esecuzione, V4.1 Flash le vince tutte: Kimi-Linear Decode a 17,10× contro 13,64×, MegaQwen Decode a 5,39% di roofline contro 3,92%, TopK Bitonic a 4,25% contro 7,17% per GLM-5.3 Flash, Sonic MoE a 10,81% (il miglior punteggio pubblicato da qualsiasi modello della classifica per quel kernel) contro 10,21%, e KDA CUTLASS a 3,74% contro 2,26%. Su altri due kernel GLM-5.3 Flash non ha alcuna esecuzione completata — fused MoE e il kernel di simulazione Grid + MinGRU, dove V4.1 Flash registra il 28,56% di roofline. (L'unica riga in cui GLM-5.3 Flash batte V4.1 Flash è TopK Bitonic, 7,17% contro 4,25%, che è anche la riga in cui nessuno dei due modelli si avvicina al leader della classifica.) L'andamento generale è lo stesso del titolo: sul lavoro GPU di basso livello, V4.1 Flash non è semplicemente avanti rispetto al modello più piccolo di Z.ai — è in un'altra categoria, e sui due kernel più difficili il modello più piccolo non completa affatto.

Ciò che la classifica non fa è dirti quanto di quel divario sia dovuto al modello e quanto all'architettura che gli viene chiesto di scrivere. DeepSeek V4.1 Flash è un modello da 552 miliardi di parametri la cui attenzione è una progettazione ad attenzione sparsa; GLM-5.3 Flash è un modello più piccolo il cui addestramento non è mai stato incentrato sullo stesso stack CSA2. Un modello a cui viene chiesto di scrivere un kernel per un'architettura che assomiglia alla propria distribuzione di addestramento ha un vantaggio intrinseco, ed è per questo che la lettura più equa della classifica è direzionale anziché un verdetto testa a testa: l'ingegneria dei kernel è ora una capacità misurata di questo modello, è genuinamente forte, e il confronto specifico tracciato dalla fonte regge sulle righe condivise. La classifica risponde anche a una domanda a cui la scheda tecnica non poteva rispondere: se la cache da 890 byte sia realizzabile in pratica. Un modello che scrive il proprio kernel di attenzione sparsa alla metà del roofline è un modello il cui design di base è almeno implementabile su hardware reale dalla stessa classe di ingegneri che dovrebbe servirlo.

Il posto onesto in cui questo si colloca è accanto a tutto il resto di questo pezzo: un'altra misurazione di terze parti che DeepSeek non ha prodotto, questa volta di una capacità — la scrittura di kernel GPU — che nessuna riga di benchmark di fornitore copriva. È una singola scheda della community su una singola generazione di GPU, eseguita una volta sola, e il suo passaggio di audit non è sottoposto a peer review, quindi è un'evidenza sulla direzione più che un punteggio certificato. Ma è il primo numero esterno che mostra a cosa serve la nuova architettura: un modello economico di fascia Flash che, quando gli viene chiesto di svolgere il lavoro di sistemi di basso livello su cui DeepSeek stessa spende la propria ingegneria, raggiunge circa la metà di ciò che l'hardware consente, mentre il suo concorrente diretto di fascia Flash arriva a meno di un ventesimo.

Correzioni rapide, conferme lente: i primi resoconti pratici

Il throughput è la metà della storia della velocità che un contatore di token non riesce a vedere. I resoconti pratici accumulatisi dal rilascio misurano l'altra metà — come si comporta il modello lungo il percorso verso una risposta, e quanto costa quel comportamento — e non concordano sul fatto che ciò che hanno trovato sia una funzionalità. Tre resoconti indipendenti descrivono lo stesso schema. Nessuno di essi è una valutazione controllata; i dati che seguono provengono da singoli professionisti che svolgono i propri compiti, e vanno letti come resoconti d'uso anziché come misurazioni.

Il resoconto più chiaro del comportamento viene da MindStudio, che ha messo DeepSeek V4.1 Flash su una build da zero di un visualizzatore 3D interattivo. La sua traccia di ragionamento, secondo le parole del recensore, “mostrava che verificava i propri calcoli invece di limitarsi a generare codice”. Il modello ha individuato un bug nello smorzamento dei controlli orbitali a metà della build, ha ricavato la correzione partendo dai principi primi e poi “ha ricontrollato la correzione in un browser headless prima di dichiarare concluso il compito”. In un secondo compito — una dashboard basata su Docker — ha trovato un singolo operatore di confronto invertito e ha confermato la correzione eseguendo il polling dell'endpoint live otto volte mentre i numeri si aggiornavano. Questo è ciò che descrivevano i tester della beta quando definivano il modello uno che pensa troppo, e non c'è niente di sbagliato in nessuno dei suoi singoli passaggi: l'errore è stato trovato, corretto e verificato. Ed è anche esattamente la lamentela. Il bug era già stato gestito, un'altra sessione di DeepSeek aveva già confermato la correzione nel giro di un minuto, e il modello ha continuato comunque a controllare. MindStudio interpreta l'abitudine come un punto di forza e lo dice; la sua unica critica in quel test riguardava un problema di fisica che è rimasto in loop finché non è stato fermato a mano al primo tentativo, per poi essere risolto correttamente al secondo tentativo.

La lettura dalla direzione opposta riguarda il tempo. Una raccolta comunitaria di test di V4.1 Flash descrive un problema di fisica — una tazza d’acqua tagliata ad angolo obliquo — in cui il modello ha impiegato dodici minuti e circa 130.000 token per arrivare a una risposta corretta, eseguendo tre giri di autoverifica che non gli erano stati richiesti prima di convergere. Lo stesso resoconto documenta la modalità di errore all’estremo opposto di quell’abitudine: la catena di pensiero cade occasionalmente in un ciclo ripetitivo di “fammi scrivere” che macina token a circa 200 al secondo senza fare progressi, e il suo consiglio è lato client anziché lato modello — impostare un tetto max_tokens e un timeout della richiesta e lasciare che tronchino il ciclo. Registra anche lo stesso tipo di problema risolto in diciotto secondi da un’esecuzione con lo sforzo di ragionamento abbassato a basso, il che ricorda che gran parte di questo è una manopola più che un difetto.

La prova più netta che il volume di verifica non è la stessa cosa della correttezza proviene da una revisione di Tencent Cloud Labs che ha abbinato DeepSeek V4.1 Flash come implementatore e GPT-6 Astra come revisore su una riproduzione di un paper. Sono stati eseguiti tre round, e Astra non ha mai ribaltato l'algoritmo principale. Ciò che il revisore continuava a correggere, round dopo round, era l'impalcatura che V4.1 Flash aveva costruito per sé — la configurazione dell'esperimento, la costruzione statistica e l'interpretazione che traeva dai propri risultati. Il numero di test è cresciuto da 82 a 97 a 110, e tutti sono passati ogni volta. Rispetto a una baseline brute-force, la configurazione scelta dal modello coincideva con l'ottimo nell'8,89% dei casi con i parametri stessi del paper, nell'11,04% con confidenza randomizzata e nel 10,30% con una configurazione randomizzata. Il rilievo più incisivo di Astra riguardava un test che pretendeva di verificare i confini degli interi: eseguiva 153 controlli di estensione e zero rami di confine tra interi. Un modello può superare la suite che ha scritto e comunque non aver risposto alla domanda, e quella revisione è un caso concreto di tale divario, piuttosto che l'affermazione che ne esista uno. L'ambito è ristretto e gli autori lo dicono — un singolo selettore di lunghezza speculativa, valori di confidenza simulati, nessuna esecuzione end-to-end — ma la forma è quella descritta dagli altri rapporti.

Accostato ai numeri di Artificial Analysis, questo smette di sembrare un aneddoto. La prima valutazione indipendente del modello lo ha misurato come molto veloce e molto verboso nello stesso respiro: 185 token di output al secondo, e 250 milioni di token di output generati nel suo set di valutazione rispetto a una mediana di 140 milioni per modelli comparabili. Un punteggio composito non può dire dove finisca l'output in eccesso. I resoconti pratici possono. I token non sono riempitivo — sono il modello che controlla. Lo stesso volume emerge da una direzione non correlata in un bug report su un client terminale di terze parti, dove il contenuto di ragionamento su una rotta deepseek-flash è stato aggiunto alla risposta visibile invece di essere separato in un blocco di pensiero, producendo singoli blocchi di testo fino a 73.003 caratteri di monologo interiore, senza nulla catturato da riprodurre nei turni successivi. Quel bug appartiene al client e non a DeepSeek, e non è una prova sulla qualità — ma è una buona illustrazione di quanto pensiero emetta questo modello quando un harness non riesce a separarlo.

Niente di tutto ciò ribalta l'aritmetica dei prezzi di cui sopra; la spiega. Un modello che verifica se stesso vale i suoi token nei lavori agentici, dove una correzione sbagliata costa più dei token spesi per dimostrarla giusta, ed è poco adatto a un lungo ciclo di modifiche banali in cui la conferma costituisce la maggior parte dell'esecuzione. Due cose rendono la differenza gestibile. La manopola dello sforzo di ragionamento è un numero intero continuo da 1 a 100 anziché tre livelli fissi, quindi lo stesso modello può essere abbassato per lavori economici e alzato per lavori difficili — il risultato di diciotto secondi di cui sopra è derivato dal fare esattamente questo. E la rete di sicurezza economica appartiene al client: un tetto massimo di max_tokens e un timeout della richiesta trasformano un ciclo ripetuto da un conto in una risposta troncata. Entrambe sono il tipo di impostazione che vale la pena fissare prima che un percorso di produzione punti a questo modello, e nessuna delle due è qualcosa che il modello farà da solo.

Rifiuti: il checkpoint rifiuta, e il rifiuto è misurabile

Il 20 ottobre, ciò che ha attirato l'attenzione su DeepSeek-V4.1-Flash-1017 non è stata una riga di benchmark, ma un rifiuto. Il tracker DeepSeek già citato in questo articolo ha pubblicato lo screenshot di una sessione agente che eseguiva il checkpoint 1017 con dsh-purge applicato, e ha riportato che il modello ha comunque rifiutato: l'esecuzione, per usare le parole dell'autore del post, «ha rifiutato la persona», con il modello che ragionava che la richiesta era «un tentativo di prompt injection» e che «non avrebbe dovuto adottare la persona». L'interpretazione del post era che il checkpoint «*non* è del tutto ingenuo riguardo ai jailbreak» e che DeepSeek «sta iniziando a pensare alla sicurezza». dsh-purge non è un trucco di prompt incollato in un messaggio utente. È un plugin pubblico di DeepSeek Harness — 9.897 stelle su GitHub e versione 1.1.71 al 20 ottobre — creato per rimuovere la riscrittura dei prompt e i suffissi iniettati dello stesso harness, e il suo README in inglese traccia esattamente la distinzione su cui verte questo test: l'harness «riscrive prompt, gate di approvazione, policy della sandbox e migrazione delle sessioni a runtime», quindi chiedere solo «il modello risponderà» tratta un blocco a livello host come un rifiuto del modello, e il plugin esiste per separare questi due livelli sulla propria installazione. In questa sessione la separazione è emersa dal lato del modello. I contatori nello stesso screenshot — 156 passaggi, 33,7 milioni di token, 232 token al secondo — descrivono un'esecuzione agente completa anziché un prompt one-shot, e il riepilogo dell'agente stesso afferma che il plugin era meccanicamente a posto e che «quel modello specifico lo ha rifiutato».

Quello è lo screenshot di una singola sessione scattato da una persona, e va riportato esattamente come tale. Il prompt non è mostrato, il verdetto è il riassunto dell'agente stesso anziché una risposta valutata, e l'account è un osservatore di DeepSeek anziché un laboratorio di valutazione, quindi nulla nel post può essere riprodotto a partire dal post. Ciò che lo rende meritevole di essere preso sul serio è che entrambe le sue parti possono essere verificate rispetto a fonti indipendenti dalla persona che l'ha pubblicato: il plugin, che è pubblico e documenta il proprio meccanismo, e il comportamento di rifiuto del checkpoint, che ora è stato conteggiato da qualcun altro.

Il dato si trova nella documentazione di un derivato. Una build abliterata della comunità dei pesi 1017, pubblicata su Hugging Face il 17 ottobre, riporta la misurazione che ha reso necessaria la build. Su 100 richieste dannose trattenute, decodificate in modo greedy per 384 token ciascuna, il checkpoint non modificato ha rifiutato 97 richieste in modalità chat e 98 in modalità think; dopo che un sottospazio di rifiuto di rango 2 è stato proiettato via dai 40 layer principali, gli stessi 100 prompt hanno prodotto 4 e 9 rifiuti. Sono cifre di terze parti sui pesi di DeepSeek, prodotte senza accesso alla pipeline di addestramento di DeepSeek, e sono anche un unico set di prompt, un unico valutatore e un'unica quantizzazione del modello — una conversione Q8_0 anziché l'FP8 distribuito da DeepSeek — quindi la lettura onesta è “quasi sempre”, non “97,0%”. Su questa base, la descrizione dell'autore del post regge: il checkpoint rifiuta, in modo affidabile, in entrambe le sue modalità.

Ciò che il dato non supporta è l'idea che questa sia una nuova impostazione. Il checkpoint di settembre c'era già. Il team dietro una build non censurata di settembre ha misurato il modello non toccato sull'intero set di 320 prompt di HarmBench e ha riportato un tasso di successo degli attacchi del 42,8% con il ragionamento disattivato e dell'1,6% al massimo sforzo — vale a dire che il modello che questo sostituisce ha rifiutato circa il 98% di quella classe di richieste una volta che gli è stato consentito di pensare. Le due misurazioni provengono da set di prompt diversi, valutatori diversi e quantizzazioni diverse, quindi non possono essere sottratte l'una dall'altra; ciò su cui concordano è la forma. Il rifiuto ad alto sforzo era già il comportamento del modello di settembre, e il checkpoint 1017 si colloca nello stesso intervallo. L'affermazione più ristretta è quella che la sessione del 20 ottobre testa effettivamente, ed è quella che vale la pena mantenere: il rifiuto è sopravvissuto a un plugin costruito specificamente per rimuovere i vincoli lato harness, ed è sopravvissuto come giudizio del modello sul prompt anziché come blocco a livello host.

Niente di tutto ciò è documentato dal fornitore. La model card di settembre di DeepSeek ha una sezione di valutazione ed è solo benchmark — nessun tasso di rifiuto, nessun risultato di red-team, nessuna valutazione di sicurezza — e la card 1017 non contiene affatto una sezione di valutazione, avendo eliminato quella cartella insieme al report tecnico. Il comportamento di rifiuto di questo modello è quindi descritto interamente da chi costruisce attorno a esso: autori di derivati che contano i prompt e un tracker che legge una trascrizione. Per chiunque indirizzi un agente verso il checkpoint, questa è la lacuna operativa. Un rifiuto all'interno di un ciclo di agente non è una nota a piè di pagina della policy sui contenuti; è una chiamata a strumento fallita nel mezzo di un'esecuzione, e emerge come qualsiasi altro errore per singola chiamata — ed è per questo che la mitigazione è la stessa che si applica a un timeout. Su OrcaRouter si tratta di una decisione di routing anziché di una modifica al codice: il checkpoint 1017 e i modelli DeepSeek su cui ripiegherebbe stanno dietro un unico endpoint, quindi una chiamata che torna rifiutata può essere ritentata su un secondo modello invece di terminare l'esecuzione. Il rifiuto stesso appartiene al modello, e nulla sul livello di routing lo cambia.

Il conteggio dei derivati è l'ultimo tassello indipendente, e punta nella stessa direzione. Una ricerca su Hugging Face per il nome del checkpoint ha restituito 121 repository pubblici il 20 ottobre, e 25 di essi riportano nel nome uncensored, abliterated o derisked — build il cui unico scopo è rimuovere il comportamento con cui si è scontrata la sessione del 20 ottobre, il primo dei quali è stato pubblicato lo stesso giorno in cui sono stati caricati i pesi. Non è una prova che il modello sia buono, né una raccomandazione; è la prova che nei pesi c'è un meccanismo di rifiuto funzionante da rimuovere, perché chi rimuove queste cose non si prende la briga quando non c'è nulla da rimuovere. Stabilisce anche l'aspettativa per chiunque faccia self-hosting: il checkpoint che scarichi è quello che rifiuta, e ogni variante uncensored su quella lista è un modello diverso, non un'impostazione.

La questione del V4 Pro, e i gradini sopra Flash

Durante la beta, il modulo di feedback di DeepSeek ha chiesto ai tester se la versione intermedia «può sostituire completamente la versione online di DeepSeek V4 Pro». Era una domanda sorprendente da porre agli utenti, perché implicava che il futuro del flagship fosse aperto. La risposta arrivata il 9 e 10 settembre è stata di natura operativa: dalle 12:00 ora di Pechino del 14 settembre, deepseek-v4-pro avrebbe smesso di essere servito e il suo traffico sarebbe passato a V4.1 Flash ai prezzi di Flash, con V4.1 Pro indicato come successore eventuale. Gli sviluppatori hanno obiettato, e l'obiezione non era che la sostituzione fosse scadente, bensì che una stringa di modello è un contratto, e scambiare i pesi dietro un ID di produzione rompe pipeline ottimizzate per i prompt e cicli di agenti costruiti sulle vecchie versioni. Nel giro di due giorni DeepSeek ha ritirato il piano. Il suo changelog ora afferma che ha «deciso di continuare a fornire servizi API per DeepSeek V4 Pro dopo il 14 settembre 2026, con il metodo di fatturazione invariato», e che darà ulteriore preavviso se ciò cambierà. L'inversione è dichiarata dal fornitore anziché riportata, ed è verificabile sulla pagina Models & Pricing, che elenca ancora deepseek-v4-pro accanto a deepseek-flash.

Ciò che la tabella di routing non spiega è il perché. Il 9 settembre, teortaxesTex — uno degli account di informatori che avevano segnalato la beta — ha riferito che DeepSeek aveva ammesso che il pre-addestramento del suo V4-Pro era andato storto; secondo le sue parole, l’azienda ci ha “combinato un pasticcio”. Resta un’affermazione a fonte unica, proveniente da un account vicino agli ambienti interni, e DeepSeek non ha ammesso nulla pubblicamente: il changelog inquadra la dismissione come conseguenza del fatto che il nuovo modello è migliore, non che il vecchio sia rotto. Ciò che può essere verificato dall’esterno è la forma del lancio in disponibilità generale del V4 Pro del 13 agosto. L’annuncio è stato ritirato nel giro di circa un giorno. Il repository Hugging Face ha brevemente contenuto una configurazione di livello Flash sotto il nome Pro, prima che i pesi venissero corretti. E le valutazioni indipendenti di ciò che veniva servito con quel nome si sono collocate appena sopra il molto più piccolo DeepSeek V4 Flash, contro grafici ufficiali che mostravano risultati vicini a quelli dell’ammiraglia — sull’attuale indice Artificial Analysis i due sono distanti un solo punto, 36 contro 35. Resoconti indipendenti hanno attribuito la colpa a cause diverse — un comportamento di ragionamento sovradattato all’harness di valutazione interno di DeepSeek, una confusione tra deployment e pesi oppure, come sostiene la fuga di notizie, un pre-addestramento davvero andato storto. Il rerouting non stabilisce quale delle ipotesi sia corretta, e da allora DeepSeek ha annullato la cosa; ciò che resta è un fornitore che fissa il prezzo del suo modello più recente a un quarto della tariffa cache-miss dell’ammiraglia e lo colloca davanti a quell’ammiraglia nei propri benchmark, cosa che le aziende di solito non fanno perché tutto è andato secondo i piani.

Flash, Pro, Ultra: cosa ha detto DeepSeek e cosa è solo una supposizione

La documentazione di DeepSeek stessa afferma esplicitamente che questo è il livello più basso di qualcosa. Il changelog definisce DeepSeek V4.1 Flash “il modello più piccolo della nostra nuova famiglia di architetture” e afferma che l’architettura “è progettata per un tetto di capacità più elevato, un’inferenza più rapida, un throughput maggiore e la scalabilità verso modelli più grandi”. Il rapporto tecnico chiude il cerchio con toni più forti: il modello “costituisce un nuovo punto di partenza per i nostri continui sforzi di scaling”, e l’azienda afferma che “perseguirà lo scaling congiunto di architettura del modello, pre-training e post-training per esplorare ulteriormente la frontiera dell’intelligenza dei modelli”. Entrambe le frasi provengono direttamente dall’azienda, entrambe sono state pubblicate il 10 settembre e nessuna delle due costituisce un annuncio di prodotto. Impegnano DeepSeek a costruire modelli più grandi su questo progetto; non ne citano uno, non ne specificano le dimensioni né indicano una data.

Tutto ciò che va oltre quella riga è speculazione. Il 25 settembre il tracker @teortaxesTex — lo stesso account il cui post del 9 settembre sul pre-training di V4 Pro è già citato in questo articolo — ha interpretato lo schema come una linea completa a tre livelli: “DeepSeek è abbastanza chiaro che non si fermeranno qui… Sembra che intendano creare un'intera gamma, Flash-Pro-Ultra. Magari 522B-2T-8T?” Le dimensioni sono definite una congettura da chi le propone, e la prudenza è tutt'altro che superflua: nulla nel changelog, nella model card, nel report tecnico, nell'organizzazione Hugging Face, nella pagina dei prezzi o nell'elenco dei modelli di DeepSeek nomina un livello Ultra, e nulla sopra 552B. La scala ipotizzata è anche un'aritmetica più traballante di quanto sembri. Il suo piolo più basso, 522B, non è il modello da 552B che è stato rilasciato — o la cifra è un lapsus per un numero che DeepSeek ha già pubblicato, oppure indica un checkpoint che nessuno ha visto, e non c'è modo dall'esterno di dire quale delle due. Il suo piolo più alto, 8T, è cinque volte il modello di punta da 1.6T il cui repository DeepSeek ha aperto ad aprile, in un anno in cui il rilascio più recente dell'azienda è stato progettato per attivare 8B parametri per token perché il costo di inferenza, non il numero di parametri, era il vincolo che mirava a risolvere.

Lo stesso resoconto ha inoltre ventilato separatamente un modello DeepSeek da 3 trilioni di parametri come qualcosa su cui il laboratorio stava lavorando ma che non era sicuro di poter erogare in modo economicamente sostenibile: un’affermazione diversa su una cosa diversa, e altrettanto non confermata. Non è necessario conciliare l’una con l’altra, perché nessuna delle due ha una seconda fonte. Ciò che si può verificare è la direzione: un laboratorio che definisce il suo modello più recente il più piccolo di una famiglia, e la sua architettura una che scala a modelli più grandi, è un laboratorio che pianifica di rilasciare modelli al di sopra di questo gradino. Come chiamerà i gradini, e quanto saranno grandi, non compare in alcun documento che un lettore possa aprire oggi.

Per chiunque scelga un modello invece di seguire una roadmap, quella distinzione è tutto. Se la famiglia si estenderà verso l’alto, la decisione che la maggior parte dei team ha davanti resta comunque se passare al livello che esiste — e il modo più economico per tenere aperta quella decisione è non aspettare. DeepSeek V4.1 Flash è su OrcaRouter alle tariffe di DeepSeek stesso con 0% di ricarico, quindi se arriva un successore di fascia Pro a un prezzo diverso, la modifica finisce nel listino tariffe anziché in un contratto. DeepSeek V4 Pro si trova sulla stessa chiave dietro di esso, il che rende l’arrivo successivo di un terzo livello una decisione di routing anziché una migrazione.

I pesi MIT cambiano quello che puoi farci.

DeepSeek V4.1 Flash è distribuito con licenza MIT, e i pesi sono stati pubblicati nell'organizzazione deepseek-ai su Hugging Face il 10 settembre — lo stesso giorno dell'API, non settimane dopo. Il repository è deepseek-ai/DeepSeek-V4.1-Flash: 48 shard safetensors per un totale di circa 510 GB, il rapporto tecnico in PDF accanto a essi e una cartella di inferenza che contiene un'implementazione di riferimento più uno script di conversione che suddivide il checkpoint tra i ranghi del parallelismo tensoriale. Quel repository è il checkpoint di settembre; quello attivo dal 17 ottobre è deepseek-ai/DeepSeek-V4.1-Flash-1017, che riporta la stessa licenza MIT, gli stessi 48 shard e gli stessi circa 510 GB, ma che sostituisce ogni shard e omette il rapporto, il modello di chat e la cartella di valutazione.

Vale la pena essere precisi su che cosa sia quel download, perché non è un rilascio a piena precisione. I safetensors contengono all'incirca 204 miliardi di parametri in FP8 e 557 miliardi in INT8, contro circa 2 miliardi in BF16, e la config dichiara la quantizzazione fp8: il checkpoint che scarichi è già compresso, ed è così che un modello da 763 miliardi di parametri entra in circa 510 GB. Il blocco singolo più grande al suo interno è la tabella Engram: due tabelle FP8 che costituiscono circa 189 GiB del download, da cui ogni passo di decodifica legge solo poche righe.

Per un modello con una spina dorsale da 552B, la licenza è la parte che cambia le decisioni. MIT è permissiva, senza soglia di ricavi e senza clausola di uso accettabile che meriti una revisione legale, e il profilo di attivazione — 8B per token in prefill, 16B in decode, con una cache da 890 byte per token — è ciò che rende plausibile servirla al di fuori di un hyperscaler anche se il conteggio dei parametri appare elevato. Tuttavia, quest'ultima cifra è una proprietà dell'intero stack di cache più che dei pesi, perciò un motore self-hosted che implementa il formato quantizzato e non il resto del design si collocherà ben al di sopra di essa.

Una licenza permissiva non è un'autorizzazione all'esportazione, e per sei giorni di ottobre la differenza è sembrata poter contare. Il 16 ottobre il Ministero del Commercio e il Ministero della Scienza e della Tecnologia cinesi hanno pubblicato l'Annuncio n. 48 del 2026, una bozza di revisione del catalogo delle tecnologie vietate o soggette a restrizioni all'esportazione che per la prima volta riguarda i pesi dei modelli di IA e il codice sorgente. Propone 40 aggiunte tra IA, biotecnologie e solare, 23 delle quali relative all'IA, con consultazione pubblica fino al 15 novembre. Due deroghe nella bozza fanno la maggior parte del lavoro per un modello come questo: la tecnologia già di pubblico dominio tramite rilascio open source o pubblicazione accademica non deve essere controllata, e l'accesso tramite API, app, SaaS e in forma leggera su dispositivo per utenti esteri non è trattato come esportazione di tecnologia del modello. Le soglie riportate dalla stampa specializzata combinano una soglia minima di due trilioni di parametri, un posto tra i primi dieci al mondo nei benchmark di prestazioni e sicurezza, e l'addestramento su dati nazionali fondamentali o importanti. Un modello da 552 miliardi di parametri supera la prima; se le altre due lo riguardino è qualcosa che un lettore non può determinare dall'esterno, perché la bozza non pubblica le definizioni — il che rende la deroga sul pubblico dominio, non il test dimensionale, la clausola che conta per pesi già presenti su Hugging Face.

Ciò che è cambiato il 22 ottobre non è stato il testo, ma il registro di conformità. YuyuantanTan ha riportato che DeepSeek e MiniMax avevano completato le procedure di registrazione e concluso l'open sourcing e la concessione di licenze per l'estero. Il rapporto non dice quali rilasci consideri come open sourcing, non nomina alcun modello, checkpoint o data e non ha annunciato nuovi pesi; i rilasci open source visibili in quella finestra sono il motore DeepInfer e il toolkit deepseek-recipe trattati sopra. La versione dell'affermazione a livello di build è più ristretta e successiva: il 23 ottobre un account X con una lunga storia di monitoraggio di DeepSeek ha pubblicato che DeepSeek e MiniMax avevano rispettivamente “ottenuto le autorizzazioni per l'open sourcing di V4.1F-1017 e M3.1-Flash”. Tale attribuzione è di chi ha pubblicato il post, nessuna delle due società ha pubblicato una dichiarazione che la confermi e nessuna autorità di regolamentazione ha pubblicato un avviso che nomini la registrazione di una delle due società. Il checkpoint nominato nel post era su Hugging Face con licenza MIT dal 17 ottobre, sei giorni prima. Qualunque autorizzazione sia stata concessa, non ha condizionato il download: il repository è arrivato prima.

Per un lettore, il contenuto pratico è più ristretto dei titoli che lo circondano e si muove in due direzioni. Nulla del checkpoint del 17 ottobre, della licenza MIT o del repository è cambiato il 22 ottobre; il download, gli shard e le differenze di hash descritte sopra sono esattamente come erano. Ciò che è cambiato è la risposta alla domanda se un laboratorio cinese possa continuare a pubblicare pesi come questi mentre il catalogo è ancora in consultazione: il resoconto dei media statali dice di sì per DeepSeek e MiniMax, in base a una bozza che esclude la tecnologia già pubblica e lascia l'accesso alle API fuori dalla definizione di esportazione. Il limite è nel tempo verbale. L'esenzione riguarda la tecnologia già di pubblico dominio, il che descrive i checkpoint di settembre e ottobre e non descriverebbe automaticamente un rilascio effettuato dopo la finalizzazione del catalogo — e l'obbligo di registrazione provvisorio che si dice sia entrato in vigore il 16 ottobre è stato riportato anziché pubblicato integralmente. Chiunque pianifichi di scaricare qualunque cosa DeepSeek rilasci in seguito sta pianificando in base a una regola che non esiste ancora. Chiunque oggi chiami V4.1 Flash, o esegua i pesi 1017, si affida a una deroga che la bozza prevede e che nessuna delle due versioni della misura provvisoria contraddice.

Il supporto per il serving è arrivato lo stesso giorno e stabilisce la soglia pratica minima. vLLM ha pubblicato una ricetta day-0 validata su hardware NVIDIA e AMD, e SGLang ha rilasciato il supporto day-0 per inferenza e RL nella stessa finestra tramite il suo stack di training Miles. Entrambi sono stati rilasciati come immagini di anteprima anziché pacchetti stabili: il container vLLM riportava un tag del 9 settembre, un giorno prima della GA del modello stesso. Quel lato della storia si è evoluto il 22 settembre, quando vLLM ha rilasciato v0.30.0: la prima versione stabile di vLLM a supportare questa architettura, con DeepSeek V4.1 Flash elencato nel supporto ai nuovi modelli, la ricetta vLLM del modello stesso che ora richiede 0.30.0 o versione successiva e il tag dell’immagine del giorno di lancio ritirato. Le note di rilascio sono il resoconto del progetto sul proprio lavoro, non un risultato misurato, e vanno lette in questo modo. Attribuiscono alla versione il merito di mantenere l’intera KV cache del modello in MXFP8 tramite il record FlashMLA V4.1 su SM100, e di offrire prefetch asincrono per le lookup Engram offloadate sulla CPU oltre allo sharding data-parallel di Engram — i due cambiamenti più importanti per un modello la cui tabella Engram è il singolo blocco più grande del download. Nessuno dei due cambiamenti è accompagnato da un numero esterno al progetto, e le note di rilascio non ne riportano alcuno — ma il progetto ha pubblicato un prima-e-dopo sul modello nel suo complesso il 7 ottobre, tre settimane dopo il rilascio: 1,9× più veloce a bassa concorrenza e 5,3× il throughput con un vincolo di 150 TPS rispetto alla propria build day-0, con l’elenco delle pull request unite alla base di ciascuna ottimizzazione. Le cifre e i loro limiti sono nella sezione sulla velocità qui sopra. Ciò che non esiste è una replica esterna: ogni numero in quel post è il progetto che misura se stesso. Ciò che il rilascio chiarisce è il packaging: 762 commit da 315 contributor, 104 dei quali alla prima contribuzione, in una versione con tag anziché in un’immagine di anteprima. L’aritmetica della ricetta vLLM stessa pone ancora il minimo a circa 614 GB di VRAM per il checkpoint da 510 GB più margine — un nodo H200 con otto GPU o un tray GB200 NVL4 — e avverte che un contesto da 1M token va limitato nella pratica, non dato per scontato. Una KV cache più ridotta cambia quanta memoria serve al motore in esecuzione, non quanto è grande il checkpoint, quindi la soglia minima del nodo resta valida. Il write-up di SGLang aggiunge una leva specifica di questa architettura: spostare la tabella Engram nella memoria host con un singolo flag d’ambiente ha aumentato la capacità della KV cache di circa il 36% in un test con quattro GB300, a throughput di decode e tempo al primo token comparabili, e il bounded replay SWA lato decoder ha aumentato del 1,56× il throughput di prefill su otto H200. Due limiti accompagnano questo risultato. L’implementazione di riferimento nel repository si descrive come un esempio leggibile anziché un motore di serving di produzione, e i runtime consumer erano in ritardo: il percorso di quantizzazione che avrebbe permesso di eseguirlo su un laptop o un Mac Studio non era aperto al lancio. In breve, i pesi sono davvero aperti e lo stack di serving esiste davvero — su hardware che si conta in nodi anziché in GPU, che è la ragione onesta per cui una licenza permissiva non significa automaticamente una build locale. Il repository 1017 non cambia nulla rispetto a quella soglia — il checkpoint è lo stesso da 510 GB negli stessi 48 shard, e le note di runtime che lo accompagnano sono quelle pubblicate per i pesi di settembre.

Ciò che i pesi aperti non ti danno, di per sé, è un segnale di qualità — ma quel divario ora è in parte colmato, e si è colmato ulteriormente il 18 ottobre. Ora esistono quattro strumenti indipendenti, uno dei quali eseguito due volte: l'Intelligence Index di Artificial Analysis, che assegna 39 al checkpoint di settembre e 45 al checkpoint 1017; lo studio Exploit Bench citato sopra, un benchmark cyber eseguito con sette harness per agenti; la board comunitaria dei kernel nella sezione sottostante; e, dal 14 ottobre, i risultati AA-AgentPerf di Artificial Analysis per questo modello, che misurano l'hardware su cui viene servito anziché quanto è buono. Il prima-e-dopo del 7 ottobre del progetto vLLM, sopra, misura ancora una cosa diversa — quanto costa servire il modello anziché quanto è buono — ed è il resoconto che il runtime dà di sé. Nessuno è un punteggio di ragionamento del tipo che ARC Prize sta costruendo, tre dei quattro descrivono ancora il checkpoint di settembre, e per la maggior parte delle righe specifiche di questo articolo la model card resta l'unica fonte — ma il valore composito non appartiene più a quella lista: il 45, e il 33,8 sotto di esso, sono stati prodotti rispetto ai pesi che DeepSeek serve oggi. Non è un'accusa; è lo stato delle prove, ed è per questo che questo articolo tiene separati i due tipi di numero. I pesi aperti significano davvero che il modello non resterà confinato all'endpoint di DeepSeek, il che conta per chiunque avesse come ostacolo la residenza dei dati anziché il prezzo.

Come adottarlo senza scommetterci la produzione

Una cosa è cambiata da noi dal rilascio, e rende questa sezione più semplice di quanto sarebbe stata la settimana scorsa: DeepSeek V4.1 Flash è ora su OrcaRouter. Risponde all'id del modello deepseek/deepseek-v4.1-flash tramite lo stesso endpoint compatibile con OpenAI del resto della linea, alla tariffa propria di DeepSeek — $0.15 per 1M di token di input, $0.60 per 1M di output e $0.003 per 1M di letture dalla cache nelle fasce non di punta, che raddoppiano nelle finestre di punta dei giorni feriali — applicata in pass-through con markup dello 0%. È quest'ultima parte che vale la pena chiarire: l'importo che ti viene addebitato è quello del provider, non un prezzo di rivendita, quindi un taglio di prezzo del fornitore è attivo qui lo stesso giorno, anziché quando viene rinegoziato un contratto. DeepSeek V4 Flash e DeepSeek V4 Pro utilizzano la stessa chiave, il che rende la migrazione di seguito un cambio di routing anziché una migrazione a una nuova piattaforma. Il checkpoint del 17 ottobre non cambia nulla di tutto ciò: DeepSeek ha mantenuto sia il nome del modello API sia il listino tariffe, quindi l'aggiornamento non cambia né l'id né il prezzo da questa parte, ed è così che si presenta un pass-through quando un fornitore aggiorna un modello senza toccare nessuno dei due.

Questa è anche la ragione per non affrettare la migrazione. Il rerouting del 14 settembre sarebbe stato un fornitore che cambia sotto di te il significato di un ID modello, se DeepSeek non l'avesse annullato sotto pressione, e l'episodio è il promemoria recente più limpido del fatto che una stringa di modello è un contratto che un fornitore può riscrivere — il che è anche la cornice giusta per il discorso sulla line-up di cui sopra, dato che una famiglia a tre livelli è un piano e questa è già cambiata una volta. Per un modello i cui unici punteggi esterni finora sono un indice composito, una rumorosa tabella cyber e una classifica kernel della community — e che non ha alcun record in produzione — la forma più sicura è quella per cui è costruito un router: inviare una quota di traffico modellato sulla produzione al nuovo modello, tenere dietro un modello collaudato come failover automatico, così che una regressione di qualità costi un nuovo tentativo invece di un incidente, e lasciare che il DSL di routing decida quali chiamate valgono il modello non collaudato e quali devono restare sul cavallo di battaglia. La migrazione a V4.1 Flash è probabilmente la destinazione giusta. Non è una migrazione da fare sull'annuncio.

Domande aperte

• Benchmark indipendenti — il conteggio è passato da zero a quattro strumenti, e nessuno di essi misura il ragionamento del modello nel modo in cui ARC Prize intende farlo. Il punteggio di 39 di Artificial Analysis è un composito di dieci valutazioni a sforzo di ragionamento massimo, e il suo 45 — pubblicato il 18 ottobre — è lo stesso composito applicato ai pesi più recenti. Lo studio Exploit Bench citato sopra è un punteggio di sfruttamento informatico entro un budget di token fisso, e colloca DeepSeek V4.1 Flash al di sotto di GLM-5.3-Flash. La classifica kernel della community su kernelbench.com è una tabella di kernel engineering. I risultati AA-AgentPerf di Artificial Analysis, pubblicati il 14 ottobre, sono una tabella hardware: quanti token al secondo per megawatt ogni sistema di acceleratori serve a questo modello, e nulla sulla qualità. Nessuno ha replicato le singole righe di benchmark di DeepSeek, e non è stata pubblicata alcuna misurazione indipendente con impostazioni di sforzo di produzione, né all'estremità di una finestra da 1M di token. Il checkpoint del 17 ottobre non è più privo di misurazioni: il 18 ottobre Artificial Analysis ha aggiunto una riga 1017 a 45 sul suo indice e 33,8 su Terminal-Bench 4.0, e il dato del bench si colloca otto punti e mezzo sotto quanto la tabella del fornitore dichiara per gli stessi pesi. Ciò che manca ora è un secondo parere su quel dato — un valutatore, un harness, un'esecuzione — e un qualsiasi punteggio indipendente per le quattro misurazioni precedenti alla sostituzione. L'unica valutazione costruita per rispondere alla domanda sul ragionamento è ancora in fase di realizzazione — ARC Prize ha un profilo DeepSeek V4.1 Flash nel suo harness di benchmarking in una pull request aperta, senza alcun risultato allegato — e ARC-AGI non ha mai valutato questo checkpoint: il 61,4% su ARC-AGI-2 che l'arrivo dell'adattatore ha riportato in auge appartiene a DeepSeek V4 Flash 0731, il modello che V4.1 Flash manda in pensione. Il numero più recente associato a questo modello, il 77,0 su DeepSWE v1.1, è la riga con la fonte più debole del pezzo: è un grafico di DeepSeek stesso, letto da un'immagine allegata all'annuncio del fornitore, e non esiste alcuna esecuzione esterna di DeepSWE v1.1 sul checkpoint 1017 — il risultato del 18 ottobre di Artificial Analysis è per gli stessi pesi ma per un benchmark diverso. Le due classifiche indipendenti che pubblicano il benchmark collocano il nome di questo modello al 71,7% e al 74,2%, il che basta a metterlo accanto a Opus 5 ma non a confermare il dato del fornitore — e nessuna delle due indica quale checkpoint abbia misurato.

• Self-hosting sotto la soglia del nodo — il supporto day-0 di vLLM è diventato una release stabile il 22 settembre con v0.30.0, che aggiunge un path KV MXFP8 e l’offload asincrono di Engram; il supporto day-0 di SGLang viene ancora distribuito come immagine di anteprima. Nessuno dei due sposta la soglia hardware, che si colloca intorno a un nodo da otto GPU perché è il checkpoint da 510 GB a determinarla — e le note di deployment di DeepSeek stessa, pubblicate con DeepInfer, lo precisano ulteriormente: è possibile distribuire un nodo di prefill accanto a un nodo di decode, ma la configurazione decode consigliata prevede un expert parallelism pari o superiore a 64, il che fa sì che l’unità efficiente minima sia di 64 GPU di prefill accanto a 64 di decode. Il post del 7 ottobre del progetto vLLM è il più completo registro di ottimizzazioni misurate pubblicato su questo modello — 1,9× a bassa concorrenza e 5,3× con un vincolo di 150 TPS rispetto alla propria build day-0, insieme ai dati SGLang sopra riportati — e il suo seguito del 17 ottobre aggiunge una curva token per dollaro che copre davvero configurazioni H100, MI300X e B200 accanto ai componenti rack-scale. Entrambi sono la rendicontazione del progetto stesso sul proprio runtime. Nessuno dei due sposta la soglia: un token meno caro su una GB300 o una H100 non riesce comunque a far stare un checkpoint da 510 GB su un desktop, quindi è un percorso più rapido verso la stessa soglia, non verso una soglia più bassa. Se release successive e quantizzazioni della community porteranno questo su macchine più piccole è la domanda aperta per chiunque voglia i pesi anziché l’endpoint, ed è quella che decide se una licenza permissiva sia una licenza pratica.

• Che cos'è V4.1 Pro — DeepSeek lo presenta come il successore di V4 Pro, ma non ha pubblicato né una data, né specifiche, né un prezzo, e il reindirizzamento annunciato del traffico Pro esistente verso un modello di livello Flash è stato ritirato prima che entrasse in vigore. Ciò che sta al di sopra di Flash è descritto dall'azienda solo come l'architettura che scala verso modelli più grandi; la scala Flash, Pro e Ultra e le sue dimensioni 522B, 2T e 8T sono la speculazione di un osservatore, non di DeepSeek.

• Costo per attività — Artificial Analysis riporta ora una cifra per attività per entrambi i checkpoint: $0,49 per attività dell'Intelligence Index per i pesi di settembre, riformulati rispetto ai $0,27 inizialmente riportati in questo articolo, e $0,26 per 1017. È la prima evidenza esterna per una qualsiasi parte della rivendicazione Pareto di DeepSeek, ed è più ristretta della rivendicazione. Le stesse righe mostrano che il checkpoint 1017 genera 210M token di output sull'intero indice, contro 250M per settembre — output complessivamente più brevi — ma 89.495 token di output per attività contro 88.574, il che non è affatto più breve, e 288,8 secondi per attività contro 289,9, il che non è più veloce. La ripartizione dei costi del sito stesso attribuisce l'intero risparmio al lato input: la voce output è piatta, $0,106 per attività contro $0,107, mentre l'input scende da $0,379 a $0,155 e le scritture in cache da $0,322 a $0,095. Che un'attività si completi con meno dollari dipende da quanti token richiede, e questa è una proprietà del carico di lavoro, non del listino. La descrizione dell'aggiornamento fornita da DeepSeek stessa va nella direzione opposta: il changelog afferma che il nuovo checkpoint riduce il tempo di esecuzione delle attività e la lunghezza dell'output, e il suo post del 17 ottobre lo ripete come “completamento delle attività più rapido e output più brevi”. Nessuno dei due riporta un numero, e la misurazione esterna alla base di questo punto li ha ora confrontati: sulle due grandezze nominate da DeepSeek, i pesi 1017 si sono spostati di circa l'1 per cento, in direzioni opposte, rispetto a un punto di partenza di cinque settimane prima. Una terza cifra si trova sull'altro lato dello stesso prospetto: il grafico del 17 ottobre del progetto vLLM colloca il modello a 1,3B token per dollaro di costo totale di proprietà su SemiAnalysis AgentX, a un livello di costo che presuppone volumi da grandi hyperscaler. Un servizio meno costoso non risolve neppure questo punto: un costo per token inferiore lascia il valore di token per attività, che è ciò per cui un chiamante paga effettivamente, esattamente dove lo ha trovato la misurazione di settembre.

• Verifica incontrollata — i tester che li provano direttamente segnalano occasionali loop di ripetizione nella catena di pensiero, e deliberazioni di dodici minuti e centinaia di migliaia di token su problemi che si risolvono in pochi secondi con un'impostazione di effort inferiore. Nessun benchmark indipendente misura quanto spesso accada l'una o l'altra cosa né quanto costi in produzione, e la mitigazione riportata finora è costituita da tetti di token lato client anziché da qualcosa che il modello faccia da sé. Lo studio Exploit Bench di cui sopra documenta lo stesso modo di fallire dalla direzione opposta: il loop di report ripetuti che mostra nei transcript ReAct è prodotto dal prompt di compattazione dell'harness anziché dal ragionamento del modello stesso, il che ricorda che un loop in un transcript non è automaticamente un difetto del modello.

• Ingegneria dei kernel — la bacheca comunitaria di kernel CUDA di kernelbench.com (RTX PRO 6000, con scaling roofline) vede DeepSeek V4.1 Flash al 50,19% del roofline equivalente-denso sul proprio kernel di attenzione sparsa, quarto in classifica generale, contro il 4,45% di GLM-5.3 Flash sulla stessa riga. La bacheca è gestita dalla comunità e non sottoposta a peer review; non è stata pubblicata alcuna seconda generazione di GPU né alcuna replica.

• Contesto lungo all'estremità lontana — l'attenzione sparsa è stata addestrata a 64K ed estesa a 1M al traguardo dei 34T token. Quanto la qualità regga verso la fine di una finestra completa da 1M è esattamente ciò che una valutazione indipendente del contesto lungo stabilirebbe.

• Ricostruzione della cache ai margini — SWA Bounded Replay ricostruisce in modo approssimativo, anziché esatto, lo stato scartato della finestra scorrevole, e DeepSeek afferma che il risultato può variare a seconda di dove cade un cache hit all'interno di una sessione. Il rapporto rileva un impatto minimo osservato sulla qualità; condizioni estreme o non testate sono esattamente quelle in cui emergerebbe un'approssimazione del genere, e nessuno al di fuori di DeepSeek ha controllato.

• Se i carichi di lavoro Pro si sposteranno davvero — il reindirizzamento forzato è stato ritirato, quindi nulla si sposta a meno che un team non scelga di spostarsi, e i team che hanno pagato prezzi Pro per la profondità di ragionamento sono quelli che hanno più probabilità di notare una differenza di capacità su lavori modellati su Terminal-Bench 3.0, dove V4.1 Flash è nettamente indietro rispetto a Opus-5.0.

• I termini e il comportamento del livello gratuito — OpenCode ha aggiunto il 15 ottobre una voce senza costi per questo modello, su una finestra di 200.000 token e un tetto di output di 32.000 token, descritta sulle sue stesse pagine come disponibile per un periodo limitato. Se l'accordo sopravviva a quella frase, come regga l'endpoint sotto carico e se DeepSeek abbia voce in capitolo sono tutte cose non dette: l'elenco dei modelli, la documentazione e la tabella dei prezzi della piattaforma sono l'unica fonte, non c'è una data di termine a cui vincolare qualcuno e nessuno ha pubblicato una misurazione del percorso gratuito.

• Sicurezza e rifiuti — DeepSeek non pubblica alcun tasso di rifiuto, risultato di red-team o valutazione di sicurezza per nessuno dei due checkpoint, e nessun laboratorio indipendente ha valutato questo modello su un benchmark di jailbreak. Le cifre in questo articolo provengono da persone che sviluppano derivati non censurati — 97 prompt dannosi su 100 rifiutati in modalità chat, 98 in modalità think, su un unico set di prompt e un unico valutatore — e da un singolo screenshot di una sessione agente in cui il modello ha rifiutato una persona jailbroken. Se tale comportamento si mantenga a basso sforzo di ragionamento, in lingue diverse dall'inglese, contro attacchi automatizzati anziché un prompt basato su una persona, e sotto un harness che riscrive il system prompt, non è stato misurato da nessuno.

• La documentazione del prossimo checkpoint — il rapporto del 22 ottobre risolve la questione della registrazione per i pesi già pubblici, perché il catalogo preliminare esclude la tecnologia già di pubblico dominio. Non risolve la questione del rilascio successivo a questo. Il catalogo è una bozza aperta ai commenti fino al 15 novembre, le relative soglie sono riportate anziché pubblicate nel testo, e l’obbligo di registrazione transitorio che si dice sia entrato in vigore il 16 ottobre non è stato pubblicato integralmente. V4.1F-1017 stesso è disponibile, con licenza MIT e senza restrizioni; ciò che un futuro checkpoint DeepSeek deve superare prima di poter essere scaricato è una regola che non esiste ancora.

La beta era una domanda di due giorni: se un modello di livello Flash potesse svolgere il ruolo di Pro. La release è la risposta di DeepSeek, con una rate card e un piano di routing — per poi ritirare il piano di routing nel giro di due giorni, quando gli sviluppatori hanno obiettato che un modello di produzione veniva sostituito sotto di loro. È un'affermazione più debole di quanto lasciasse intendere l'annuncio e più onesta: le prove di qualità a sostegno del cambio sono i benchmark di DeepSeek stesso, più misurazioni esterne che per lo più vanno nella stessa direzione. La più recente di queste, un benchmark cyber eseguito con sette harness di agenti, va nella direzione opposta sull'unico confronto che effettua, e l'azienda ha lasciato la scelta ai clienti invece di farla al loro posto. Dalla release, i pesi sono passati da una promessa a un download da 510 GB, il modello è passato da endpoint del fornitore a qualcosa verso cui puoi fare routing, e lo stack di serving è passato da una ricetta day-0 a una misurata — vLLM che si dichiara 1,9× più veloce a bassa concorrenza dopo tre settimane, per poi pubblicare, il giorno in cui il checkpoint è cambiato, una curva di costo che prezza il modello a 1,3B token per dollaro di costo totale di proprietà su SemiAnalysis AgentX. Questa settimana si è aperto anche lo strato sotto tutto questo: DeepSeek ha pubblicato DeepInfer, il motore su cui gira il proprio servizio, con una curva di decode per questo checkpoint, i dati di produzione dietro quella curva e un benchmark di settembre non pubblicato che colloca l'Huawei 950DT da cinque a sette volte dietro NVIDIA per chip alla velocità a cui DeepSeek serve effettivamente. A cinque settimane di distanza, il checkpoint stesso si è mosso una volta: il 17 ottobre hanno portato nuovi pesi dietro lo stesso nome e lo stesso prezzo, con una tabella del fornitore migliore su ogni riga pubblicata e un harness diverso sotto una di esse. Due giorni dopo è arrivata la misurazione esterna, ed è il numero più utile di questo pezzo: Artificial Analysis ha collocato i pesi 1017 a 45 sul suo indice — a pari merito con GLM-5.3 per il secondo posto tra i modelli open-weights, un punto dietro MiMo-V2.6-Pro — e a 33,8 su Terminal-Bench 4.0, contro il 42,3 del fornitore sullo stesso benchmark — quindi l'harness che lusinga il modello nella tabella di DeepSeek non è l'harness in cui il numero sopravvive. Se stai scegliendo oggi, la posizione onesta è che V4.1 Flash sembra il miglior rapporto qualità-prezzo della linea DeepSeek, ha quattro strumenti indipendenti al suo attivo — nessuno dei quali è un punteggio di ragionamento, uno dei quali ora eseguito contro il checkpoint che DeepSeek serve dal 17 ottobre — una quinta valutazione in costruzione, nessuno storico di produzione, uno stack di serving i cui due numeri più forti — un delta di velocità e una curva di costo — provengono entrambi dal progetto che ha scritto il runtime, e un risultato cyber esterno che già contraddice se stesso a seconda dell'harness con cui avvolgi il modello, un tier gratuito da 200.000 token comparso su una piattaforma il 15 ottobre e una prima tornata di resoconti pratici che descrivono un modello che verifica il proprio lavoro più a fondo di quanto la maggior parte dei chiamanti gli chieda — il che è un motivo per indirizzarvi una parte del traffico, non un motivo per migrare sulla base dell'annuncio. L'aggiornamento annunciato da DeepSeek il 17 ottobre cambia i pesi e aggiunge un'affermazione del fornitore — completamento più rapido delle attività, output più brevi — e la prima misurazione esterna di quei pesi ne supporta al massimo metà: costo per attività dell'indice ridotto del 46%, mentre il tempo per attività e i token di output per attività si sono appena mossi. Un giorno dopo, l'affermazione più letta su quel checkpoint era quella di un dirigente: 77 su DeepSWE v1.1 a un costo inferiore di 83×, da un dipendente Databricks che dice anche che il checkpoint arriverà su quella piattaforma. Metà resiste al confronto con le board indipendenti, che ora collocano il nome di questo modello sopra Opus 5 su quel benchmark. L'altra metà non ancora: il 77 è la riga di DeepSeek stesso, non riprodotta, e l'83× è aritmetica senza alcun costo per attività pubblicato dietro. La documentazione di Databricks conferma che il modello è sulla sua piattaforma e che i due modelli DeepSeek sottostanti sono destinati a uscire; non conferma che il checkpoint stia arrivando. Quell'affermazione è ormai la seconda più interessante sul checkpoint, non la prima. Il 19 ottobre un account tracker che ha anticipato diversi di questi rilasci si è dichiarato "certissimo" del 42,3 su Terminal-Bench 4.0, sulla base del fatto che batte GLM-5.3, e ha chiesto ad Artificial Analysis di eseguire il modello in un harness nativo. Il sito lo aveva già fatto. Sul proprio harness gli stessi pesi segnano 33,8 — sotto il 41,9 di GLM-5.3, non sopra. La riga del fornitore è reale ed è di DeepSeek; l'inferenza che ne viene tratta non sopravvive all'esecuzione da parte di qualcun altro.

Se la versione di questo che vuoi è quella che ti tiene aperte le opzioni, tutte e tre sono a una chiave di distanza e prezzate alle tariffe proprie di DeepSeek con 0% di markup aggiunto. La release stessa: DeepSeek V4.1 Flash on OrcaRouter — contesto da 1M token, un tetto di output di 384K, input di immagini, a $0,15 per 1M di input e $0,60 per 1M di output fuori picco. Il modello che sostituisce: DeepSeek V4 Flash on OrcaRouter. E il modello di punta che DeepSeek ha deciso di continuare a servire: DeepSeek V4 Pro on OrcaRouter. Indirizza una parte del traffico verso quello nuovo, tieni un modello collaudato alle spalle come failover, e lascia che sia il routing a decidere.

La scelta di un modello è anche una questione di ciò che è andato storto in precedenza: gli incidenti AI documentati e i fallimenti degli agenti per i modelli di questa classe sono raccolti nell'Archivio degli Incidenti AI di OrcaRouter, dove ogni voce riporta le proprie fonti, la gravità, il grado di confidenza e il flag di contestazione.