DeepSeek V4 Pro GA vs Preview: 18-62% di ragionamento in meno

La versione General Availability di DeepSeek V4 Pro usa dal 18% al 62% di token di ragionamento in meno rispetto alla Preview che sostituisce, a parità di task. Corregge inoltre un failure mode capace di consumare per intero una finestra di output da 8,192 token ed è la prima versione Pro in cui la disattivazione del thinking rende affidabile l’estrazione in strict JSON. Perde però la capacità della Preview di ammettere di non conoscere una risposta. Abbiamo confrontato deepseek-v4-pro-0813 con la versione Preview in un unico batch, quattro giorni dopo la GA. Abbiamo misurato solo i token: il giorno precedente DeepSeek aveva modificato i prezzi di V4 e introdotto tariffe di picco e fuori picco, quindi un confronto in dollari tra due listini in movimento sarebbe stato meno indicativo dei token. DeepSeek ha rilasciato la versione GA senza blog post, changelog o comunicato stampa, quindi l’unico modo per capire cosa sia cambiato è misurarlo.

TL;DR

• La GA usa dal 18% al 62% di token di ragionamento in meno per task: 18 contro 48 in una semplice ricerca.
• Su entrambe le versioni, il thinking altera i valori dello strict JSON (2/8 corretti); l’unica configurazione pulita che abbiamo trovato è la GA con thinking disattivato (8/8).
• La GA corregge un failure mode della Preview: con thinking_budget: 16, la Preview ha riempito la finestra di output da 8,192 token in 5 esecuzioni su 9; la GA in 0 su 9.
• La GA perde il rifiuto esplicito: con entità inventate, la Preview rifiuta di rispondere in 100-150 token; la GA non restituisce nulla oppure inventa una risposta.

Quanto ragiona meno la versione GA?

Dal 18% al 62% in meno, con il divario maggiore sui task semplici. Ecco i risultati dei nostri quattro task standard, con tre esecuzioni ciascuno e input diversificati: riportiamo le mediane dei token di ragionamento e dei token totali di completamento.

Entrambe le versioni hanno ottenuto 3/3 su ogni task. Si tratta quindi di un guadagno netto di efficienza, non di un compromesso sulla qualità. Per il capacity planning conta l’andamento: più il task è complesso, minore è il risparmio. Si passa dal 62% su una ricerca a un solo passaggio al 18% su una catena di cinque passaggi. Qualunque sia il costo delle due versioni, questa è la forma del divario. L’estrazione strutturata ottiene il vantaggio maggiore: con uno strict json_schema, i token di ragionamento scendono da 159 a 40, una riduzione di 4x.

Il caching si comporta allo stesso modo nelle due versioni: entrambe hanno messo in cache 4,096 token di un prefisso da 5,000 token e servito l’hit 4 secondi dopo la chiamata di priming. In questo momento cambiano le tariffe, non il meccanismo. DeepSeek ha aumentato i prezzi della famiglia V4 e introdotto una tariffazione di picco e fuori picco, con prezzo dimezzato fuori picco, a partire dal 2026-08-16 alle 16:00 UTC. Prima di convertire questi token in dollari, verificate quindi il listino corrente di ciascuna versione e l’orario di esecuzione.

La GA ha corretto qualcosa di misurabile?

Sì, e si tratta del failure mode più costoso della famiglia. Se si invia thinking_budget: 16 alla Preview, il modello perde il filo: invece di ragionare brevemente e rispondere, entra in un loop ripetitivo (“I’ll output: 168. I’ll output: 168…”) che continua fino a esaurire max_tokens. In nove esecuzioni dello stesso task in 5 passaggi, la Preview ha riempito l’intera finestra da 8,192 token 5 volte. La GA non lo ha mai fatto e ha risposto correttamente in tutte le esecuzioni usando da 79 a 130 token.

Il costo del problema è evidente: una richiesta che dovrebbe risparmiare limitando il ragionamento finisce per fatturare 8,193 token di completamento, contro circa 130 per una risposta normale. Si paga quindi un output 63x più caro proprio per aver chiesto al modello di ragionare meno. Sulla Preview, neppure un budget di 64 token era sicuro: ha prodotto risposte errate (183, 174) in 2 esecuzioni su 3. Se usate ancora la Preview e controllate i costi con budget di thinking ridotti, questa è la prima combinazione da eliminare.

Qui si può disattivare il thinking senza rischi, ma non vale per tutta la famiglia: Flash 0731 è passata da 6/6 a 0/6 nei calcoli a 2 passaggi con thinking disattivato. Entrambe le versioni Pro, invece, sono rimaste a 3/3 sulla nostra catena in 5 passaggi con thinking: {"type": "disabled"} o enable_thinking: false. Su Pro, disattivare il thinking non riduce l’accuratezza nei task di ragionamento e corregge l’estrazione strutturata descritta di seguito.

Su entrambe le versioni, il selettore continua a non avere effetti concreti. reasoning_effort accetta low, medium, high, xhigh e max, mentre rifiuta none e minimal con un errore 400 che elenca i valori validi. Nel nostro task in 5 passaggi, i diversi livelli hanno prodotto da 76 a 122 token di ragionamento sulla GA e da 116 a 167 sulla Preview, senza un andamento monotono. Come emerso dalla nostra matrice dei controlli di ragionamento tra diversi vendor, DeepSeek si controlla con l’interruttore di disattivazione e con il budget, non con l’enum.

Il thinking continua ad alterare lo strict JSON?

Sì, su entrambe le versioni. La release GA è però la prima versione Pro a offrire una soluzione affidabile. Avevamo individuato questo difetto in DeepSeek V4 Flash 0731: il JSON rispetta lo schema, ma i numeri sono errati. Il problema è presente anche in Pro. Abbiamo chiesto a entrambe le versioni di estrarre quattro campi da una fattura di tre righe usando uno strict json_schema. Abbiamo eseguito otto test per configurazione e verificato i valori, non solo lo schema:

Tutti gli output errati sono parsabili, rispettano lo schema e contengono dati falsi. Per un documento che elenca chiaramente tre voci, il numero di righe restituito nelle varie esecuzioni è stato 45, 22, 2026, -4, -35 e -3864. Una risposta della Preview riportava un totale di -139,308,173,307,904; una risposta della GA ha persino inventato un’altra azienda (“MITRE”, totale 1000). Un validator considererebbe valido il JSON in tutti questi casi.

La conseguenza operativa è semplice. Sulla versione GA, il difetto è scomparso in tutte le nostre esecuzioni disattivando il thinking. Questa singola impostazione è il motivo più forte per abbandonare la Preview, che anche con thinking disattivato ha prodotto risultati errati in 6 casi su 8. Il risultato conferma il comportamento della famiglia già misurato su Flash, dove disattivare il thinking ha corretto tutte le esecuzioni. Conferma anche la zona sicura per i task a singolo passaggio emersa dalla nostra matrice dei controlli di thinking: l’estrazione non richiede ragionamento e, in questa famiglia, ragionare peggiora attivamente il risultato.

Cosa perde la GA?

La capacità di dire “non lo so”. Abbiamo posto domande su cinque entità inventate: il prezzo delle azioni di un’azienda, il numero di dipendenti di un istituto, lo statuto di una città, il punto di fusione di una lega e il vincitore di un premio. La Preview rifiuta correttamente di rispondere in 100-150 token di output: “I don’t have any information about a 1987 Pan-Continental Robotics Prize.” La GA adotta invece uno di due comportamenti, entrambi inutili:

Prima della pubblicazione abbiamo ripetuto il controllo tramite un secondo percorso di richiesta indipendente. In quel caso la Preview ha rifiutato tutte e tre le domande campionate usando da 101 a 148 token. La GA ha invece consumato 8,191 token e restituito una risposta vuota per una domanda, ha risposto con cautela a un’altra e ha indicato un punto di fusione preciso (“2,314 degrees Celsius”) per una lega inesistente nella terza. Client diverso, stessa asimmetria: il comportamento dipende dal modello.

Per le pipeline di retrieval, la conseguenza pratica è un doppio costo. Una domanda a cui l’indice non può rispondere consuma un’intera finestra di ragionamento nascosto e restituisce un messaggio vuoto oppure un dato inventato che il validator accetterà senza problemi. Se inoltrate a questo modello le query senza risposta, impostate max_tokens abbastanza basso da rendere il problema evidente ed economico. Trattate inoltre un completamento vuoto come un miss, non come un errore.

Cambia altro passando alla GA?

Poco. La migrazione dipende quindi dal comportamento, non dall’integrazione. Entrambe le versioni hanno accettato 279,000 token di input in una singola chiamata e risposto a una domanda basata su un’informazione collocata al centro del contesto. Condividono inoltre il tokenizer della famiglia: lo stesso corpus misto di inglese, cinese e codice produce lo stesso conteggio sulla GA, sulla Preview e su deepseek-v4-flash-0731. I budget di token si possono quindi trasferire tra i modelli della famiglia senza modifiche. Entrambe accettano silenziosamente temperature, top_p e top_k, oltre a un turno assistant precompilato, la funzionalità di prefix completion documentata da DeepSeek.

Anche il caching è identico, inclusa la granularità. Nessuna delle due versioni ha messo in cache un prefisso da 512 token. Al di sopra di tale soglia, entrambe usano pagine esatte da 1,024 token (1,024, 2,048, 4,096) e servono gli hit 4 secondi dopo la chiamata di priming. È la stessa dimensione di pagina usata da Flash. Resta un’altra domanda sui costi: entrambe le versioni restituiscono l’intera chain of thought in reasoning_content, ma reinviarla nel turno successivo non costa nulla. Un turno di follow-up ha fatturato gli stessi 134 token di input sulla GA (56 sulla Preview), sia includendo sia rimuovendo il ragionamento del turno precedente. A differenza dei modelli che rifatturano ogni token di ragionamento conservato, questa famiglia lo ignora.

Nel tool loop non c’è un vantaggio netto. In un loop agentico con due funzioni, prima cercare un incidente e poi riavviare il servizio indicato, la GA ha ragionato di più al primo passaggio (48 contro 34 token di ragionamento) e meno al secondo (18 contro 35). Entrambe le versioni hanno scelto il tool corretto 3 volte su 3. DeepSeek posiziona questa release per i workload agentici, ma il ragionamento per passaggio è sostanzialmente equivalente, nonostante i dati complessivi sull’efficienza. Per un agent che incontra vicoli ciechi, il comportamento di rifiuto descritto sopra conta di più.

FAQ

Quanto costa in meno eseguire la versione GA?

In termini di token, usa dal 18% al 62% di ragionamento in meno per task e 4x meno con uno strict json_schema. Per i dollari, consultate il listino corrente: il 2026-08-16 DeepSeek ha modificato i prezzi della famiglia V4 e introdotto tariffe di picco e fuori picco, con prezzo dimezzato fuori picco. Gli stessi token hanno quindi costi diversi in base alla versione e all’orario.

La GA fa risparmiare di più sui task semplici o su quelli complessi?

Sui task semplici. La riduzione dei token di ragionamento è del 62% per una ricerca a un passaggio, di circa il 48% per un problema testuale a 2 passaggi e per l’estrazione JSON, e solo del 18% per una catena aritmetica in cinque passaggi. Le due versioni convergono sui task multi-step complessi; la migrazione conviene soprattutto per il traffico semplice e ad alto volume.

Conviene ancora usare budget di thinking ridotti con DeepSeek V4 Pro?

Non sulla Preview. Con thinking_budget: 16, il modello è entrato in un loop ripetitivo che ha consumato l’intera finestra di output da 8,192 token in 5 esecuzioni su 9. Una richiesta pensata per costare poco ha prodotto un output circa 63x più caro; con 64 token ha restituito risposte errate. La GA ha gestito correttamente lo stesso budget in 9 esecuzioni su 9, quindi i budget ridotti sono sicuri solo sulla versione datata.

Posso fidarmi dell’output strict JSON di DeepSeek V4 Pro?

Solo con thinking disattivato e solo sulla GA. In otto esecuzioni per configurazione, con thinking attivo 6 risposte su 8 rispettavano lo schema ma contenevano numeri errati su entrambe le versioni, tra cui conteggi di 45, 2026 e -3864 righe per una fattura con tre voci. Con thinking: {"type": "disabled"}, la GA ha restituito valori corretti in 8 casi su 8; la Preview è rimasta errata in 6 casi su 8 anche con thinking disattivato. Validate i valori, non solo gli schemi.

DeepSeek V4 Pro rifiuta le domande a cui non può rispondere?

La Preview lo fa in 100-150 token. La GA, in gran parte, no: con entità inventate consuma l’intera finestra di output in ragionamento e restituisce un messaggio vuoto oppure, se dispone di una finestra più ampia, presenta come certa una risposta inventata. Verificate le risposte sulle vostre fonti invece di fidarvi dell’assenza di un rifiuto e trattate i completamenti vuoti come miss.

Misurazioni eseguite il 2026-08-17 tramite il gateway Synthorai, quattro giorni dopo la comparsa della versione GA. Per ogni confronto, la Preview è stata rieseguita nello stesso batch: matrice di selettori e interruttori di disattivazione (7 valori di effort, 5 budget, 2 parametri di disattivazione, n=3), analisi del ragionamento su quattro task, output strutturato strict JSON, loop di function calling in due turni, test su cinque entità inventate con due dimensioni della finestra, verifica dell’integrità dei valori strict JSON su quattro campi (n=8 per configurazione), coppia di test sulla fatturazione del replay del ragionamento, coppie di test sulla cache implicita con due tempi di attesa e ricerca della soglia minima della cache, accettazione di un contesto da 279K token con ricerca di un’informazione, confronto del tokenizer su un corpus fisso tra i modelli della famiglia V4 e test di accettazione per sampling, prefill e n>1. Il tasso di runaway deriva da nove esecuzioni per versione con max_tokens: 8192. Riportiamo i token invece dei dollari perché DeepSeek ha modificato i prezzi della famiglia V4 e introdotto tariffe di picco e fuori picco il 2026-08-16, il giorno precedente al batch. Il comportamento di rifiuto e il runaway sono stati verificati tramite un secondo percorso di richiesta indipendente. Tariffe e comportamento possono cambiare; ripetete le misurazioni prima di basarvi su un singolo dato.

← Torna al blog