DSpark: la scommessa di DeepSeek sulla velocità che non tradisce la qualità

DeepSeek non ha presentato solo un nuovo approccio allo speculative decoding, con DeepSpec sta provando a trasformarlo in una pipeline industriale riproducibile. Il paper si chiama DSpark, la sigla è l'ennesima di una lunga serie che il laboratorio cinese sforna con cadenza quasi trimestrale, e la tentazione di scorrerla distrattamente è forte. Sarebbe un errore, perché dietro l'acronimo si nasconde una domanda molto concreta: quanto può accelerare davvero l'inferenza di un modello linguistico se il modello che genera le bozze di risposta smette di essere ingenuo, e se il sistema che le controlla impara a non sprecare tempo su quelle destinate al cestino.

Per capire perché la domanda è rilevante, conviene partire da un fatto scomodo che chiunque abbia usato un chatbot ha sperimentato senza saperlo. Ogni parola che un modello linguistico produce nasce da un intero passaggio di calcolo attraverso miliardi di parametri, uno alla volta, in sequenza. È un po' come se un romanziere dovesse rileggere l'intero manoscritto da capo prima di scrivere ogni singola parola successiva. Funziona, ma è lento, e in un sistema che deve rispondere a centinaia di richieste contemporaneamente quella lentezza si traduce in code, costi elettrici e utenti che fissano un cursore lampeggiante.

Il collo di bottiglia dell'inferenza

Lo speculative decoding è l'idea, ormai non più nuovissima, che ha provato a rompere questo schema: invece di far lavorare solo il modello grande e costoso, si affianca un modello piccolo e veloce, chiamato draft model, che azzarda una sequenza di token futuri. Il modello grande, quello che chiameremo target, li controlla tutti insieme in un solo passaggio, accettando il prefisso più lungo compatibile con ciò che avrebbe generato lui stesso e scartando il resto. Se il draft indovina bene, il target incassa più parole per ogni passaggio di calcolo, e la generazione accelera senza perdere un grammo di qualità, perché la regola di accettazione è costruita per non alterare la distribuzione statistica del modello grande.

Il problema è che il progetto del draft model determina un compromesso scomodo. I primi draft erano autoregressivi, cioè generavano un token alla volta condizionando ciascuno sui precedenti: bravi a mantenere coerenza interna, ma con un costo di generazione che cresce linearmente al crescere del blocco di parole proposte, il che li costringe a restare piccoli e a proporre blocchi corti. Le architetture parallele, penso a lavori come DFlash, hanno risolto il problema opposto: producono tutte le parole del blocco in un solo passaggio, rendendo il tempo di generazione quasi indipendente dalla lunghezza del blocco, e questo permette di osare blocchi molto più lunghi. Ma la parallelizzazione ha un prezzo, perché ogni posizione viene prevista in isolamento dalle altre, senza sapere cosa hanno "deciso" le posizioni vicine.

È lo stesso paradosso del cadavere squisito surrealista, il gioco caro ad André Breton in cui più persone scrivono una frase a turno vedendo solo l'ultima parola lasciata dal compagno precedente: il risultato può essere sorprendente, ma spesso collassa in un'accozzaglia di frammenti sensati singolarmente e incoerenti insieme. Quando un draft parallelo deve scegliere tra "certo" e "nessun problema" come risposta a un saluto, può tranquillamente produrre un mix illeggibile delle due, perché nessuna delle due scelte sa dell'esistenza dell'altra. Gli autori del paper chiamano questo fenomeno collisione multimodale, ed è la ragione per cui i draft paralleli, pur partendo forte, perdono rapidamente colpi man mano che il blocco si allunga.

Il secondo collo di bottiglia, meno raccontato ma altrettanto concreto, riguarda la verifica. Anche ammesso che il draft produca un blocco lunghissimo di parole plausibili, controllarle tutte costa calcolo del modello target, e quel calcolo è la risorsa più scarsa in un sistema di produzione con centinaia di richieste in coda. Verificare un token che ha altissima probabilità di essere respinto è come mandare un candidato palesemente non idoneo a un colloquio che potrebbe essere assegnato a qualcuno con più chance: non è gratis, sottrae capacità a chi ne trarrebbe beneficio reale. Il paper nota, con dati alla mano, che l'accettazione varia moltissimo a seconda del dominio: un problema di matematica o un frammento di codice hanno strutture rigide che il draft indovina meglio, una chiacchierata aperta è molto più imprevedibile. Una lunghezza di verifica fissa, uguale per ogni richiesta, ignora questa differenza e spreca sistematicamente risorse.

Un drafter che impara a dubitare di sé

La prima mossa di DSpark è architetturale, e il nome dato all'approccio, generazione semi-autoregressiva, descrive bene l'idea di mediazione. Il grosso del lavoro di bozza resta parallelo: uno zoccolo duro, quello che il paper chiama backbone, produce in un solo passaggio le previsioni di base per tutte le posizioni del blocco, mantenendo il vantaggio di velocità dei draft paralleli. Sopra questo zoccolo, però, viene innestato un modulo sequenziale leggerissimo, il cui unico compito è correggere le previsioni di base introducendo dipendenza tra un token e il successivo, senza rifare da capo il lavoro pesante.

L'immagine che rende meglio l'idea arriva dal jazz più libero, quello che circolava nell'orbita di Sun Ra: un'intera sezione ritmica può suonare simultaneamente leggendo la stessa partitura di base, ma è il solista che, ascoltando in tempo reale cosa hanno appena suonato gli altri, aggiusta la frase successiva perché suoni coerente col resto. Il backbone parallelo è la partitura comune, il modulo sequenziale è l'orecchio del solista. Nel paper questo modulo esiste in due varianti: una versione minimale, che guarda solo alla parola immediatamente precedente e usa una piccola tabella a basso rango per suggerire quali parole sono coerenti con essa, e una versione più ricca, con memoria ricorrente, che accumula informazione sull'intero prefisso generato fino a quel momento nel blocco. La prima è più economica, la seconda cattura dipendenze più lunghe, e i due progetti offrono un compromesso diverso tra costo di calcolo e qualità.

Il risultato più controintuitivo del paper riguarda proprio il confronto fra questa architettura e i draft puramente autoregressivi come Eagle3. Ci si aspetterebbe che generare parola per parola, con piena dipendenza sequenziale, produca sempre risultati migliori di un approccio in parte parallelo. Gli autori mostrano che non è così, analizzando l'accettazione posizione per posizione: alla primissima parola del blocco, un draft parallelo può permettersi un'architettura molto più profonda proprio perché il suo costo non dipende dalla lunghezza del blocco, e questo vantaggio di capacità iniziale si traduce in un margine netto, per esempio quasi venti punti percentuali di accettazione in più su compiti di conversazione aperta rispetto a un drafter autoregressivo vincolato a restare leggero. Siccome la prima parola del blocco è quella con più leva, un suo rifiuto invalida tutto il resto, questo vantaggio iniziale si ripercuote sull'intera catena. Il prezzo si paga più avanti nel blocco, dove il draft puramente parallelo perde colpi rapidamente mentre l'autoregressivo tiene meglio la barra. DSpark è pensato esattamente per sommare i due vantaggi, la potenza iniziale del parallelo e la tenuta di coda del sequenziale, senza ereditarne le rispettive debolezze. Immagine tratta dal paper

Verificare solo ciò che conta

La seconda metà della proposta è forse quella più originale, e riguarda non il modo in cui si genera il draft ma il modo in cui lo si verifica. DSpark affianca al backbone di generazione una testa di confidenza, un piccolo modulo che per ogni posizione del blocco stima la probabilità che quel token sopravviva al controllo del modello target, condizionata al fatto che tutte le parole precedenti nello stesso blocco siano state accettate. È una stima di rischio, calcolata prima ancora che il target apra bocca.

Qui però emerge un problema tipico di ogni sistema che si affida a stime di confidenza prodotte da una rete neurale: tendono a essere troppo sicure di sé, un fenomeno ben documentato nella letteratura sulla calibrazione dei modelli. Se lo scheduler si fidasse ciecamente dei punteggi grezzi, finirebbe per sovrastimare sistematicamente quante parole sopravviveranno, sballando i calcoli. DSpark introduce quindi una fase di calibrazione a posteriori, chiamata scalatura di temperatura sequenziale, che corregge questi punteggi uno alla volta procedendo da sinistra a destra nel blocco, usando un piccolo insieme di validazione per trovare il fattore di correzione giusto senza alterare l'ordine di merito tra i token, solo la loro magnitudine assoluta.

Con punteggi affidabili in mano, entra in gioco lo scheduler vero e proprio, quello che il paper battezza Hardware-Aware Prefix Scheduler. L'idea è elegante nella sua semplicità: raccogliere tutte le richieste attive in un dato istante, ordinare tutti i possibili prolungamenti di verifica di tutte le richieste in base alla probabilità di sopravvivenza stimata, e ammetterli uno alla volta in ordine decrescente finché il guadagno di throughput complessivo continua a crescere. Nel momento in cui aggiungere un altro token peggiora il throughput atteso, ci si ferma. È un meccanismo che ricorda da vicino la logica dei giochi da tavolo a piazzamento lavoratori, quelli in cui ogni turno si sceglie con cura dove investire una risorsa scarsa e la decisione, una volta presa, non si può disfare: qui la risorsa scarsa è la capacità di calcolo del modello target, e ogni token verificato in più su una richiesta è una fetta di quella capacità sottratta a un'altra.

C'è un vincolo teorico delicato che gli autori affrontano con cura quasi maniacale in appendice: la decisione di quanti token verificare non può dipendere dal contenuto del token stesso, altrimenti si introduce un bias di selezione che rompe la garanzia fondamentale dello speculative decoding, ossia che il risultato finale sia statisticamente identico a quello che avrebbe prodotto il solo modello target. Gli autori dimostrano con un controesempio numerico che una ricerca completamente retrospettiva, che valuta ogni possibile taglio del blocco prima di decidere, viola questa proprietà di causalità e distorce silenziosamente la distribuzione di output. La soluzione adottata nello scheduler teorico è fermarsi non appena il guadagno atteso comincia a calare, una specie di arresto anticipato che impedisce di "sbirciare" informazioni che non dovrebbero ancora essere disponibili.

In produzione, però, la teoria si scontra con l'hardware reale. La curva di capacità di un motore di inferenza non è una curva liscia come nei modelli matematici, è piena di gradini bruschi dettati da vincoli fisici delle GPU, e pretendere di ricalcolare lo scheduling ad ogni passo in modo sincrono rallenterebbe l'intera pipeline. DeepSeek ha risolto il conflitto rendendo lo scheduler asincrono: la capacità di riferimento viene stimata usando le previsioni di confidenza di due passaggi prima, non quelle istantanee, il che introduce un lieve ritardo ma preserva la proprietà di causalità richiesta, perché la decisione non dipende mai dalla realizzazione del token corrente. È un compromesso ingegneristico pragmatico più che elegante, ma è esattamente il tipo di dettaglio che separa un paper accademico da un sistema che gira davvero su milioni di richieste al giorno.

I numeri, messi alla prova

Sul fronte dei benchmark offline, DSpark viene confrontato con Eagle3, rappresentante della scuola autoregressiva, e con DFlash, rappresentante della scuola parallela, su quattro modelli target di taglia diversa: la famiglia Qwen3 nelle versioni da 4, 8 e 14 miliardi di parametri, più Gemma4 da 12 miliardi. Su tutti e quattro, misurando quante parole vengono accettate in media a ogni ciclo di verifica, DSpark supera sistematicamente entrambi i concorrenti. Il margine rispetto a Eagle3 oscilla tra il 27% e il 31% a seconda della taglia del modello, quello rispetto a DFlash resta più contenuto ma comunque robusto, tra il 16% e il 18%. Il vantaggio si conferma trasversalmente su matematica, generazione di codice e conversazione, sebbene con intensità diverse: come prevedibile, i compiti più strutturati come il codice tollerano blocchi di verifica più lunghi, quelli conversazionali molto meno.

Il test più interessante, però, non è quello offline, è la messa in produzione dentro il motore di serving di DeepSeek-V4, sia nella variante Flash che in quella Pro, a confronto con il precedente standard produttivo interno chiamato MTP-1, un drafter a singolo token che era rimasto in uso proprio perché varianti più aggressive a più token fissi degradavano il throughput aggregato sotto carico elevato. Qui DeepSeek introduce il concetto di frontiera di Pareto del serving: il compromesso osservabile tra quanta capacità aggregata il sistema riesce a servire e quanto velocemente ogni singolo utente vede scorrere la propria risposta. A parità di livello di servizio, cioè fissando una soglia minima di velocità percepita dall'utente, DSpark porta un incremento di velocità per utente che va dal 60% all'85% su Flash e dal 57% al 78% su Pro. Sotto vincoli di interattività molto stringenti, quelli in cui il vecchio sistema a singolo token collassava quasi del tutto per restare nei tempi, i guadagni relativi diventano numeri enormi, superiori al 600% in un caso: gli stessi autori, con una onestà che vale la pena sottolineare, avvertono di non leggere questi picchi come moltiplicatori realistici, ma come prova che DSpark riesce a mantenere un servizio dignitoso proprio dove prima il sistema smetteva praticamente di funzionare.

Il meccanismo che produce questo risultato è visibile nei dati di telemetria live: sotto carico moderato lo scheduler allunga il budget di verifica per richiesta, passando dai due token fissi di MTP-1 a un intervallo dinamico tra quattro e sei, mentre quando il numero di richieste concorrenti sale e la capacità del target si satura, il budget si restringe automaticamente, proteggendo la capacità di calcolo residua invece di sprecarla su token a bassa probabilità di sopravvivenza. È esattamente il comportamento load-aware che la teoria prometteva, osservato su traffico reale e non su simulazioni.

Va detto, per completezza e senza trionfalismo, che gli stessi autori segnalano un limite non banale: anche quando lo scheduler evita sprechi lato verifica, il costo di generare il blocco iniziale di bozza tramite il backbone parallelo resta fisso e viene comunque pagato, anche per le richieste più difficili in cui il tasso di accettazione finale sarà comunque basso. È un costo che al momento non viene recuperato, e il paper lo indica esplicitamente come direzione di lavoro futuro, ipotizzando meccanismi di uscita anticipata sensibili alla difficoltà della richiesta. Immagine tratta dal paper

Aprire i cassetti: DeepSpec e i suoi costi nascosti

DeepSeek non si è limitata a pubblicare un paper, ha aperto anche il repository DeepSpec, una codebase completa per addestrare e valutare draft model di questo tipo, con dentro sia DSpark sia le implementazioni di riferimento di DFlash ed Eagle3 usate per i confronti. Accanto al codice sono stati rilasciati anche i checkpoint pronti all'uso per le versioni preview di DeepSeek-V4-Pro con DSpark su Hugging Face, un dettaglio che conta parecchio per chi vuole sperimentare senza dover riaddestrare tutto da zero.

La struttura del repository segue un flusso lineare e leggibile: prima la preparazione dei dati, che include il download dei prompt, la rigenerazione delle risposte tramite il modello target e la costruzione di quella che viene chiamata target cache, poi la fase di addestramento vera e propria lanciata con uno script che distribuisce il lavoro su tutte le GPU visibili, infine la valutazione su una suite di benchmark che comprende, tra gli altri, GSM8K, MATH500, HumanEval e Arena-Hard-v2. È un flusso pensato per chi ha già dimestichezza con l'addestramento distribuito, non per chi vuole provare DSpark su un singolo laptop, e la documentazione stessa presuppone un nodo con otto GPU come configurazione di default.

C'è un avviso, sepolto nella documentazione della fase di preparazione dati, che merita più attenzione di quanta ne riceva di solito: costruire la target cache per l'impostazione predefinita basata su Qwen3-4B può occupare circa 38 terabyte di storage. Non è un errore di battitura, è la conseguenza diretta del fatto che il training richiede di salvare gli stati nascosti del modello target per un numero enorme di posizioni, per evitare di dover rieseguire il modello grande ad ogni epoca di addestramento del draft. Per chi legge questo pezzo pensando di replicare l'esperimento su hardware casalingo o anche su un piccolo cluster aziendale, questo singolo dettaglio ridimensiona parecchio l'accessibilità pratica del progetto: il codice è aperto, ma il costo infrastrutturale per usarlo fino in fondo resta quello di un laboratorio con risorse importanti.

Sul fronte della licenza, DeepSpec è rilasciato con licenza MIT, la più permissiva tra quelle comuni nell'open source, che consente riuso commerciale, modifica e redistribuzione con pochissime condizioni. Il file NOTICE del repository, però, ricorda che non tutto il codice è farina del sacco di DeepSeek: parti consistenti dell'implementazione, in particolare quella di Eagle3, sono adattate dal framework SpecForge distribuito con licenza Apache 2.0, mentre il progetto e la ricetta di addestramento di DFlash derivano da un repository di terzi anch'esso sotto licenza MIT. È una pratica di attribuzione corretta e trasparente, sempre più rara da vedere documentata con questa cura in un panorama, quello dei rilasci open source dei grandi laboratori, in cui spesso ci si limita a citare i paper accademici senza tracciare con precisione la provenienza del codice.

Chi vince, chi aspetta ancora

Guardando all'insieme del lavoro, i beneficiari più immediati sono gli operatori di infrastrutture di serving che gestiscono traffico ad alta concorrenza: se i numeri di produzione dichiarati reggeranno anche fuori dai laboratori DeepSeek, la possibilità di offrire livelli di interattività prima irraggiungibili senza dover raddoppiare la flotta di GPU è un argomento economico difficile da ignorare, e non stupirebbe vedere idee simili comparire rapidamente nei motori di inferenza open source più diffusi, da SGLang a vLLM. Ne beneficiano indirettamente anche gli utenti finali di applicazioni conversazionali e agentiche, per cui la latenza percepita conta quanto la qualità della risposta.

Chi resta più indietro, almeno nel breve termine, è la fetta di community che vorrebbe sperimentare in autonomia partendo da zero: tra i requisiti hardware per l'addestramento e lo spazio di archiviazione necessario per la cache del target, DeepSpec parla soprattutto un linguaggio da laboratorio industriale, non da hobbista con una singola scheda grafica. Restano inoltre alcune domande aperte che il paper stesso non chiude del tutto: quanto è robusto lo scheduler asincrono quando il traffico reale è ancora più irregolare di quello osservato nei test di DeepSeek, e se il costo fisso del backbone parallelo, quello che gli autori stessi indicano come limite, diventi un problema serio proprio nei casi d'uso più esigenti, quelli agentici a bassissima tolleranza di latenza, dove ogni millisecondo di generazione della bozza iniziale pesa proporzionalmente di più. Sono le domande a cui la prossima iterazione, quasi certamente in arrivo prima che qualcuno abbia finito di pronunciare bene l'acronimo attuale, proverà a rispondere.