DeepSeek V3.2: livello GPT‑5 con il 90% in meno di costi di training

La notizia che DeepSeek V3.2 eguagli i benchmark di ragionamento della classe GPT‑5 pur avendo allenato il modello con una frazione dei FLOPs — si parla di circa il 90% in meno di costi di training — non è solo una curiosità di ricerca. È un promemoria pratico: la frontiera non è più (solo) quante GPU metti in campo, ma come progetti l’architettura e dove investi il budget post‑training.

Cosa cambia per chi progetta sistemi

DeepSeek rilascia due varianti: la base V3.2 open-source (disponibile su Hugging Face) e la V3.2‑Speciale, accessibile via API per via del maggior consumo di token. La base centra 93,1% su AIME 2025 e un rating Codeforces di 2386; la Speciale sale a 96,0% su AIME 2025 e 99,2% su HMMT Feb 2025, con prestazioni “gold” su IMO e IOI 2025. Per chi costruisce piattaforme, tradotto: hai una strada pratica per testare capacità di ragionamento e agenticità avanzata, mantenendo controllo dell’infrastruttura e dei costi.

Efficienza come leva competitiva: meno FLOPs, più ingegneria mirata su attenzione, contesto e post‑training.

Sotto il cofano: DeepSeek Sparse Attention (DSA)

Il cuore dell’efficienza è la DSA: invece di processare tutti i token in O(L²), un “lightning indexer” seleziona solo i token rilevanti per ogni query, portando la complessità a O(Lk), con k molto più piccolo di L. Durante il continued pre‑training da V3.1‑Terminus, DSA è stata addestrata su 943,7 miliardi di token con 480 sequenze da 128K per step. Questa non è solo teoria: è budget computazionale spostato dove serve.

C’è poi un dettaglio che per gli agenti conta tantissimo: gestione del contesto per tool‑calling. Se in una conversazione aggiungi solo messaggi di tool, il modello mantiene le tracce di ragionamento, evitando di “ri‑pensare” da zero. Meno token bruciati, più throughput nelle pipeline multi‑turn.

// Pattern pratico per agenti: conservare il thinking solo quando arrivano messaggi di tool
let history = [];
let scratchpad = ""; // tracce di ragionamento

function onUserMessage(msg) {
  history.push({role: 'user', content: msg});
  scratchpad = ""; // reset: serve nuovo ragionamento
}

function onToolMessage(toolResult) {
  history.push({role: 'tool', content: toolResult});
  // NON resettiamo scratchpad: il modello può riusare il thinking
}

async function callLLM(prompt) {
  const system = "Usa lo scratchpad per il ragionamento e non ripetere step già risolti.";
  const input = [{role: 'system', content: system}, ...history, {role: 'assistant', content: `Pensiero:\n${scratchpad}\nRisposta:`}];
  const out = await llm.generate(input);
  scratchpad += extractThinking(out); // opzionale
  return out;
}

Post‑training che conta, più dei soli parametri

Il report tecnico indica un budget di post‑training >10% dei costi di pre‑training, per abilitare abilità tramite ottimizzazione RL invece che “scalare a forza”. I numeri pratici oltre alla matematica/olimpiadi? 46,4% su Terminal Bench 2.0 (coding workflow), 73,1% su SWE‑Verified e 70,2% su SWE Multilingual. Non perfetto, ma “ship‑ready” in molte pipeline di sviluppo.

Trade‑off di adozione: dove ha senso, subito

Scenari reali che ho visto o rifarei domani:

• Service per tool‑use pesante: orchestratori che chiamano CLI, database o API esterne. Il mantenimento delle tracce di pensiero tra invocazioni riduce latenza e token sprecati.
• Code‑assist “task‑aware”: usare la base V3.2 on‑prem per refactor/diagnostica, riservando la Speciale (via API) a ticket ostici che richiedono catene di ragionamento più lunghe.
• Workflow MLOps: generazione e validazione di script d’infrastruttura con cicli brevi; i punteggi SWE indicano buona utilità, specie con guardrail e test automatizzati.

Compatibilità hardware e inferenza ibrida: il segnale da V3.1

Un update recente su V3.1 ha mostrato una direzione chiara: supporto a chip domestici con formato FP8 (UE8M0) e inferenza ibrida, con toggle “deep thinking” per passare tra modalità di ragionamento e non‑ragionamento. Non è V3.2 nello specifico, ma il messaggio è netto: progettare modelli e runtime per ecosistemi hardware diversificati. Se gestite ambienti misti (on‑prem + cloud, GPU eterogenee), questa è musica.

Limiti dichiarati, aspettative realistiche

DeepSeek è trasparente: l’efficienza in token non è ancora “gratis”. Per eguagliare la qualità di modelli proprietari come Gemini 3 Pro, V3.2 tende a generare catene più lunghe. Inoltre la copertura della conoscenza generale è più stretta, dato il compute totale inferiore. In pratica: progettate prompt e tool‑use per accorciare i percorsi (retrieve→reason→act), e mettete fallback per query enciclopediche.

Il rilascio ha acceso discussioni anche a ridosso di NeurIPS: riconoscimenti pubblici (ad es. da ricercatori di DeepMind) non si conquistano con slogan. La lezione che porto a casa è semplice: la nuova corsa non è solo a chi ha più GPU, ma a chi sa usare meglio ogni token, ogni step di training e ogni millisecondo in inferenza. Per molti team, questo cambia il business case da “forse” a “facciamolo”.