DeepSeek V4 Flash: thinking corrompe il JSON strict

DeepSeek V4 Flash costa $0.14 per milione di token in input e $0.28 per milione in output; i cache hit costano $0.0028. La build 0731 sottoposta a retraining, ora distribuita con questo nome, ha però un difetto da aggirare a livello di routing: con thinking attivo, come da default, e un json_schema strict, i campi integer sono risultati corrotti in 8 run su 13 con default thinking, su due percorsi di richiesta indipendenti. Disattivando thinking, tutti i run hanno restituito risultati corretti e l’estrazione ha consumato un settimo dei token. Abbiamo misurato deepseek-v4-flash-0731 il giorno del rilascio: la corruzione, il crollo più netto introdotto dal retraining quando si disattiva thinking, il budget minimo che ripristina l’accuratezza, le pagine cache da 1.024 token e le differenze ancora presenti rispetto alla build preview e a V4 Pro.

TL;DR

• Con default thinking e json_schema strict, deepseek-v4-flash-0731 ha corrotto campi integer in 8 run su 13, su due percorsi di richiesta; V4 Pro li ha corrotti in 2 su 4, mentre solo la preview non ha mostrato errori.
• Il retraining 0731 ha reso più netto il crollo con thinking disattivato: nei test matematici a 2 passaggi il risultato è sceso da 6/6 a 0/6.
• La cache serve pagine da 1.024 token a partire da una soglia di circa 1,1K token, risponde con un hit 0,3 secondi dopo il priming e conserva le entry per oltre 45 minuti.
• enable_thinking: false ha corretto tutti i run strutturati usando un settimo dei token; per i calcoli a 2 passaggi, il thinking budget sicuro è 256.

Come si confrontano sulla carta e al contatore le tre build V4?

Stesso tokenizer, stessa cache e stesso meccanismo di thinking; cambiano prezzi e modalità di errore. Tutte le misure riportate sotto derivano dagli stessi probe eseguiti sulle tre build; un trattino indica che non abbiamo testato quella combinazione. Le analisi pubblicate il giorno del rilascio si concentrano sui benchmark, mentre qui trattiamo gli aspetti operativi:

La modalità thinking corrompe l’output strutturato su V4 Flash?

Sulla build 0731 sì, e l’errore è abbastanza silenzioso da arrivare in produzione. Un’estrazione di una fattura con quattro campi e json_schema strict — fornitore, data, totale e numero di righe — con default thinking ha restituito JSON valido rispetto allo schema, ma con valori numerici errati. A fronte di un documento che elenca chiaramente tre elementi, line_items ha restituito -1, 1, -1 e -19; attraverso il nostro gateway, nessuno dei 5 run con default thinking è risultato corretto. Limitare il budget non evita il problema: un run con budget da 64 token ha prodotto la stessa corruzione e, anche con un budget da 256 token, 1 run su 3 ha restituito 670 come numero di righe. La corruzione dipende dalla presenza di thinking, non dalla sua dimensione. Su un secondo percorso di richiesta indipendente, lo stesso probe ha prodotto dati corrotti in 3 run su 8 distribuiti su due batch: in un caso il totale era 519.95 anziché i $520.00 del documento, in un altro il numero di righe era 22. Su quel percorso, il reasoning è rimasto attivo anche dopo la richiesta di disabilitarlo; la soluzione indicata sotto è quindi verificata sul percorso principale. Il JSON è sempre parsabile e supera sempre la validazione dello schema. Sono sbagliati solo i valori: lo scenario peggiore per una pipeline che si fida della validazione.

La correzione richiede una sola riga: enable_thinking: false ha prodotto JSON valido e corretto in ogni run, con circa 44 completion token contro i 328 del default. Le differenze nella famiglia sono indicative: la build preview, testata nello stesso modo con thinking attivo, ha ottenuto 4/4 senza errori, mentre V4 Pro ha corrotto 2 run su 4. Il problema riguarda quindi la linea V4 con thinking e colpisce più duramente la versione flash sottoposta a retraining. Non è neppure il bug thinking più schema già noto: lo scorso aprile vLLM ha corretto un problema di instradamento dei campi, per cui il JSON di DeepSeek finiva nel campo reasoning lasciando vuoto il content. In questo caso i campi sono gestiti correttamente, ma i valori sono sbagliati: un errore decisamente peggiore. Finché DeepSeek non lo corregge, su questi modelli thinking e output strutturato strict vanno considerati incompatibili. Non c’è alcun costo funzionale: l’estrazione a passaggio singolo è proprio il tipo di workload in cui disattivare thinking è sicuro, oltre che 7 volte più economico.

Quali controlli per thinking accetta l’API?

Due modi per disattivarlo, un budget preciso e un selettore di effort che non prevede la disattivazione. L’interfaccia testata accetta per reasoning_effort i valori low, medium, high, xhigh e max. A differenza di Qwen 3.8 Max, none e minimal vengono rifiutati, quindi il selettore da solo non può impedire al modello di ragionare. Per disattivare thinking bisogna usare enable_thinking: false oppure thinking: {"type": "disabled"}; i due parametri si comportano allo stesso modo, producendo risposte da 9 token a una domanda banale. thinking_budget viene rispettato fino al singolo token, esattamente come abbiamo misurato su Qwen 3.8: richiedendo 16, il contatore indica 16. L’intera chain of thought viene restituita in reasoning_content, mentre l’overhead fisso del prompt è di soli 5 token per chiamata.

Il selettore di effort, invece, non ha prodotto differenze misurabili. In un task complesso di conteggio dei numeri primi, low e high hanno consumato rispettivamente 31.374 e 31.370 reasoning token, contro i 26.897 del default; tutte e tre le risposte erano corrette. È normale variabilità e non si vede alcun limite. Nei livelli di Qwen 3.8 si nascondono invece budget cap che intervengono sui task complessi. Su V4 Flash, i livelli non hanno modificato nulla, indipendentemente dalla profondità testata. Per questo modello contano solo il parametro di disattivazione e thinking_budget; il selettore non ha effetti pratici. C’è anche un paradosso: la model card di DeepSeek fissa i benchmark agentici su “max reasoning effort”, un’impostazione che sull’interfaccia misurata non ha prodotto differenze distinguibili rispetto al default.

Quanto thinking serve davvero per i calcoli a 2 passaggi?

Più di quanto servisse prima del retraining, invertendo la raccomandazione sulla modalità economica data per altri modelli. Nel nostro batch riproducibile di aritmetica a 2 passaggi — 1850 casse per 24 componenti, il 75% viene spedito, ne arrivano 3.120 — le tre build V4 si comportano come tre modelli diversi:

I risultati mostrano due cose. Primo, il retraining agentico ha spostato l’aritmetica nel canale thinking: la build preview riesce a cavarsela in parte con thinking disattivato, 0731 fallisce completamente e Pro non ne risente. Secondo, il budget minimo dipende dal modello: 16 thinking token bastano a recuperare completamente Qwen 3.8 Max sullo stesso batch, mentre 0731 ne richiede 256. A quel punto raggiunge la massima accuratezza e costa meno del default: i completion token totali sono 53-188, contro 100-200 con la configurazione standard. Se trasferite una configurazione di thinking budget da un modello all’altro, rieseguite i test di accuratezza. Il controllo è universale, la soglia no.

Cosa offre la cache implicita?

Pagine da 1.024 token, una soglia bassa, risposta rapida e conservazione prolungata. Le coppie di prefissi con salt hanno prodotto hit di esattamente 1.024, 2.048, 4.096 e 7.168 token all’aumentare del prompt: una quantizzazione allineata a pagine da 1.024. La soglia si trova appena sopra una pagina: un prompt da 704 token non ha mai prodotto un hit, mentre uno da 1.166 token ha generato un hit da 1.024. Un hit è arrivato 0,3 secondi dopo il priming, quindi non c’è alcun ritardo di costruzione da gestire. L’entry veniva ancora servita dopo 45 minuti: è la cache implicita più longeva che abbiamo testato in questa fascia. L’entry di Qwen 3.8 Max scadeva tra 15 e 45 minuti e la sua soglia è vicina a 4,3K token. DeepSeek indica per l’input con cache hit un prezzo di $0.0028 per milione, pari al 2% del prezzo di un miss, senza sovrapprezzo di scrittura. Si applica la consueta disciplina nella disposizione dei layer: prima il prefisso stabile, poi il contenuto variabile.

I limiti di 1M per il contesto e 384K per l’output sono reali?

La finestra ha retto in tutti i test: i codici di override inseriti nel prompt sono stati restituiti alla lettera a 137.638, 465.238 e 838.198 prompt token, con latenze tra 7 e 20 secondi. È il recupero su contesti lunghi più rapido che abbiamo misurato in questa fascia di prezzo. Sul fronte dell’output, il limite è meno rigido di quanto documentato: DeepSeek dichiara un massimo di 384K token, ma le richieste con max_tokens pari a 393.217 e persino 524.288 sono state accettate sia con thinking sia senza. Il limite non viene quindi applicato in fase di richiesta e un budget eccessivo non genera un errore esplicito. Se vi serve un tetto, applicatelo lato client.

Preview, 0731 e Pro: quale build risponde alle chiamate?

La pagina dei prezzi di DeepSeek ora riporta un solo SKU: deepseek-v4-flash, versione DeepSeek-V4-Flash-0731, con prezzi invariati. In pratica, su alcuni route la build preview viene ancora servita con il proprio nome. Le due versioni sono facilmente distinguibili dall’esterno, anche se condividono il tokenizer: i conteggi su corpora in inglese, cinese e codice sono identici, quindi i budget sono trasferibili. Il fingerprint più chiaro è il test con thinking disattivato: nei nostri batch, sui calcoli a 2 passaggi la preview ottiene circa 2/6 e 0731 0/6. La preview è anche l’unica build che ha superato senza errori il test sull’output strutturato: 4/4 corretto, contro 5/5 corrotti per 0731 e 2/4 per Pro. Se il traffico dipende da uno di questi comportamenti, testate l’endpoint effettivamente chiamato invece di fidarvi del nome. V4 Pro ($0.435/$0.87) non risente del crollo nei calcoli, ma presenta comunque il problema sull’output strutturato.

Un dato utile per la pianificazione: sui medesimi corpora, il tokenizer condiviso dai tre modelli genera circa il 6-9% di token in più rispetto a Qwen 3.8. Per confrontare i budget tra vendor servono quindi i dati di densità per lingua, non basta il listino.

FAQ

L’output strutturato è sicuro su DeepSeek V4 Flash?

Sì, con thinking disattivato: il json_schema strict è stato rispettato e tutte le estrazioni del nostro batch erano corrette. Con default thinking sulla build 0731, i campi integer sono risultati corrotti in 8 run su 13, su due percorsi di richiesta, pur continuando a superare la validazione dello schema. V4 Pro ha corrotto 2 run su 4 con lo stesso probe; solo la build preview non ha mostrato errori. Impostate enable_thinking: false sui route di output strutturato finché il difetto non verrà corretto.

È possibile disattivare thinking su DeepSeek V4 Flash?

Sì, in due modi: enable_thinking: false oppure thinking: {"type": "disabled"}. Il retraining 0731 ha però reso fragile la modalità senza thinking nei task multi-step: 0/6 nei calcoli a 2 passaggi. Per qualsiasi attività che vada oltre una lookup a singolo passaggio, usate 256 come soglia minima di thinking_budget: nei test ha ottenuto risultati perfetti con un costo inferiore al default.

Qual è la dimensione minima del prompt per la cache di V4 Flash?

Poco più di 1.024 token: un prompt da 704 token non è mai finito in cache, mentre uno da 1.166 token ha prodotto un hit di esattamente 1.024. Gli hit sono quantizzati in pagine da 1.024 token, arrivano 0,3 secondi dopo il priming e restano disponibili per oltre 45 minuti. L’input con cache hit è indicato a $0.0028 per milione, pari al 2% del prezzo di un miss.

I prezzi sono cambiati con il rilascio 0731?

No. DeepSeek ha mantenuto $0.14 per milione di token in input in caso di cache miss, $0.0028 per un cache hit e $0.28 per l’output. Ha inoltre integrato 0731 nel nome deepseek-v4-flash come versione corrente del modello. È cambiato il comportamento, non il prezzo: maggiore dipendenza da thinking e il difetto sull’output strutturato descritto sopra.

Misure raccolte il 2026-08-04 tramite il gateway Synthorai su deepseek-v4-flash-0731, con test di confronto sulle versioni preview di deepseek-v4-flash e deepseek-v4-pro: batch di estrazione con schema strict e logging del payload per ogni run, verificati su un secondo percorso di richiesta indipendente; probe sui valori accettati dal selettore e su input non validi; batch di accuratezza a 2 passaggi con n=4-6 per configurazione e salt, seguito da una scala progressiva di thinking budget; coppie cache con salt a intervalli di 2,5 s, con probe su soglia, pagina, ritardo e intervallo; probe sui limiti di max_tokens in entrambe le modalità; conteggi del tokenizer sugli stessi tre corpora per tutti i modelli V4 e Qwen 3.8 Max. Gli importi in dollari sono i prezzi di listino pubblicati da DeepSeek al momento della pubblicazione; verificateli rispetto al contatore del vostro provider. Il comportamento potrebbe cambiare con le prossime iterazioni di DeepSeek sulla build 0731.

← Torna al blog