DSpark, la bozza che sa quando fermarsi: lo speculative decoding di DeepSeek-V4

Chi ha fatto la coda a un casello conosce il dilemma del casellante. Quando l’autostrada è vuota può permettersi di aprire una corsia in più anche per un’auto sola: non costa niente a nessuno. Quando c’è l’esodo, ogni corsia aperta per un’auto che poi si ferma a chiedere informazioni è una corsia tolta a chi stava passando davvero. La scelta giusta non dipende solo dall’auto che arriva, ma da quante ce ne sono dietro.

È, spostato nei data center, il problema che affronta DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation, uscito su arXiv il 6 luglio 2026 (2607.05147). Lo firmano trentatré autori di DeepSeek-AI e dell’Università di Pechino, con cinque primi autori a pari merito (Xin Cheng, Xingkai Yu, Chenze Shao, Jiashi Li, Yunfan Xiong) e Wenfeng Liang in chiusura. Non è un esercizio da laboratorio: è la descrizione del meccanismo che, dicono gli autori, ha sostituito il precedente nei server di DeepSeek-V4 due settimane dopo l’uscita della versione preview.

Che cosa non funzionava

Lo speculative decoding è ormai lo strumento standard per far generare più in fretta un modello linguistico: un modello piccolo, la bozza, propone un blocco di token; il modello grande li verifica tutti in un solo passaggio, tiene il prefisso che avrebbe potuto scrivere lui e scarta il resto. La regola di accettazione garantisce che il testo in uscita abbia esattamente la distribuzione del modello grande: cambia il tempo, non il risultato. Il paper riparte da qui e da una formula semplice per la latenza media per token,

$$L = \frac{T_{\text{draft}} + T_{\text{verify}}}{\tau},$$

dove $\tau$ è il numero di token accettati per giro. Le leve sono tre: scrivere la bozza più in fretta, scriverla meglio, verificarla con più giudizio.

Le bozze di oggi si dividono in due famiglie. Quelle autoregressive, come EAGLE-3, scrivono un token alla volta: ogni parola vede le precedenti, ma il tempo cresce con la lunghezza del blocco, e per restare veloci devono essere piccole e proporre poco. Quelle parallele, come DFlash, scrivono l’intero blocco in un solo passaggio: il costo quasi non dipende dalla lunghezza, e possono permettersi reti più profonde. Ma ogni posizione del blocco viene prevista senza sapere che cosa è stato scelto nelle altre.

Il paper ne dà un esempio che vale più di una formula. Se il contesto ammette sia «of course» sia «no problem», una bozza parallela può proporre «of problem» o «no course»: ogni posizione fa una media su tutte le continuazioni possibili invece di seguire quella davvero scelta. È la cosiddetta collisione multimodale, e produce il difetto che gli autori chiamano decadimento del suffisso: più ci si allontana dall’inizio del blocco, più le proposte vengono respinte.

Il secondo problema è di sistema, ed è quello del casellante. Verificare un token in più costa quasi nulla quando il server è scarico; quando è pieno, ogni token destinato a essere respinto occupa un posto nel batch che avrebbe potuto servire un’altra richiesta. Per questo, raccontano gli autori, in produzione DeepSeek usava ancora MTP-1: una bozza di un solo token. Bozze statiche più lunghe (MTP-3, MTP-5) sotto carico alto peggioravano il throughput complessivo.

Un po’ di autoregressione basta

La prima metà della proposta è l’architettura semi-autoregressiva. Il grosso del calcolo resta parallelo: una spina dorsale di tipo DFlash produce in un solo passaggio gli stati nascosti e i logit di base $U_k$ per tutte le posizioni. Sopra si innesta un modulo sequenziale leggero che aggiunge a ogni posizione una correzione $B_k$ dipendente dai token già campionati nel blocco:

$$p_k(v \mid x_0, x_{\lt k}) = \frac{\exp\big(U_k(v) + B_k(x_0, x_{\lt k}, v)\big)}{\sum_{u \in \mathcal{V}} \exp\big(U_k(u) + B_k(x_0, x_{\lt k}, u)\big)}.$$

La versione di default, la Markov head, guarda solo il token precedente: in linea di principio è una matrice vocabolario per vocabolario, approssimata con una fattorizzazione di rango basso $B = W_1 W_2$, con rango 256. Scelto «of» nella prima posizione, la testa spinge «course» e deprime «problem» nella seconda. Esiste anche una variante ricorrente, la RNN head, che ricorda l’intero prefisso del blocco; negli esperimenti aggiunge poco, soprattutto sui blocchi lunghi, e costa di più da implementare e da mettere in servizio, per cui gli autori tengono la Markov head. C’è un dettaglio che conta per lo speculative decoding: la distribuzione della bozza si scompone token per token, da sinistra a destra, quindi ogni token proposto ha ancora una probabilità esplicita, un softmax, che la regola di accettazione richiede.

Verificare meglio, non di più

La seconda metà è la verifica programmata sulla fiducia. Una piccola testa lineare stima, per ogni posizione $k$, la probabilità $c_k$ che quel token sopravviva alla verifica sapendo che i precedenti sono stati accettati. In addestramento il bersaglio è il tasso di accettazione analitico,

$$c_k^* = 1 – \tfrac{1}{2}\,\lVert p_k^{d} – p_k^{t} \rVert_1,$$

cioè uno meno la distanza in variazione totale fra la distribuzione della bozza e quella del modello grande. La probabilità che sopravviva l’intero prefisso fino alla posizione $j$ è il prodotto $a_j = \prod_{i \le j} c_i$.

Qui c’è un passaggio che distingue il paper dai metodi a soglia. Un tetto fisso («verifica finché la fiducia supera 0,7») richiede solo che le stime ordinino bene i token. Lo scheduler di DSpark invece fa un conto, e per farlo servono probabilità vere nel senso assoluto: una rete troppo sicura di sé falserebbe la stima del throughput. Gli autori misurano infatti una buona capacità di distinguere (AUC fra 0,81 e 0,90) ma un eccesso di fiducia, con errore di calibrazione fra il 3 e l’8%. Lo correggono con una ricalibrazione a temperatura fatta posizione per posizione, da sinistra a destra, che chiamano Sequential Temperature Scaling: l’errore medio scende intorno all’1%.

Con le stime calibrate, la lunghezza da verificare diventa un problema di ottimizzazione su tutto il batch. Il motore viene profilato una volta all’avvio: $\mathrm{SPS}(B)$ sono i passi al secondo che regge con un batch di $B$ token. Lo scheduler vuole massimizzare il throughput atteso

$$\Theta = \tau \cdot \mathrm{SPS}(B),$$

e lo fa in modo avido: mette in fila tutti i token candidati di tutte le richieste, ordinati per $a_{r,j}$, e li ammette uno per volta finché il guadagno in token attesi paga il rallentamento del batch più grosso. Quando $\Theta$ smette di crescere si ferma. Quella fermata anticipata non è un dettaglio: se lo scheduler guardasse più avanti, la decisione dipenderebbe da token non ancora «ufficiali» e la garanzia di distribuzione esatta cadrebbe. Il paper ne dà un controesempio in appendice.

I numeri, offline

Il confronto controllato usa come modelli grandi Qwen3 da 4, 8 e 14 miliardi di parametri e Gemma4-12B, con EAGLE-3 e DFlash riaddestrati da capo sugli stessi dati (1,3 milioni di prompt di Open-PerfectBlend), blocchi di 7 token, temperatura 1 e nove benchmark fra matematica, codice e conversazione. Qui lo scheduler è spento: si misura solo la qualità della bozza, come lunghezza media accettata per giro. Sui tre Qwen3 DSpark fa accettare bozze più lunghe di tutte e due le concorrenti, con il margine più largo su EAGLE-3.

Per avere un ordine di grandezza in valori assoluti, ecco due righe della tabella del paper.

L’analisi più istruttiva è posizione per posizione, ed è controintuitiva: sui tre Qwen3 la bozza parallela batte quella autoregressiva (su Gemma4-12B, invece, EAGLE-3 resta davanti a DFlash, mentre DSpark supera entrambe). Il motivo sta nel primo token, che conta più di tutti perché un suo rifiuto butta via l’intero blocco. Potendo essere più profonda, DFlash lo azzecca più spesso: in matematica 0,88 contro 0,81, in conversazione 0,72 contro 0,53. Poi però decade, mentre EAGLE-3 resta stabile o sale. DSpark prende il meglio dei due: parte a 0,93 in matematica e non crolla. Una DSpark a due strati supera una DFlash a cinque, e il vantaggio cresce coi blocchi lunghi: con 15 token proposti arriva al 30% in matematica, al 26% nel codice e al 22% in conversazione. Il ciclo sequenziale costa poco: con blocchi da 4 a 16 token la latenza di un giro, misurata a batch 128, cresce fra lo 0,2 e l’1,3% rispetto a DFlash.

I numeri, sul traffico vero

In produzione la bozza ha tre strati mixture-of-experts, blocchi di al massimo 5 token e la Markov head, affiancata alle versioni preview di DeepSeek-V4-Flash e DeepSeek-V4-Pro. Il confronto è con MTP-1. A parità di throughput complessivo, DSpark accelera la generazione per singolo utente del 60–85% su Flash e del 57–78% su Pro. Fissata una velocità minima garantita per utente, il throughput sale del 51% su Flash (con 80 token al secondo) e del 52% su Pro (con 35). Con il server poco affollato (sotto le 200 richieste concorrenti su Flash, le 150 su Pro) lo scheduler allarga la verifica dai 2 token fissi di MTP-1 a circa 4–6 per richiesta; quando il carico cresce, la stringe da solo.

Ci sono anche due numeri spettacolari, +661% e +406% di throughput alle soglie più severe (120 e 50 token al secondo per utente), e vanno letti come chiedono gli autori stessi: lì MTP-1 riesce a servire pochissime richieste insieme, e il rapporto esplode perché il denominatore è molto piccolo. Più che un’accelerazione, dicono, è la prova che DSpark rende praticabile un livello di interattività prima fuori portata.

Che cosa resta da verificare

La parte di produzione non è riproducibile dall’esterno. Sono telemetrie del traffico di DeepSeek, con curve interpolate su nuvole di punti, sul loro hardware e con il loro motore. Il confronto è con MTP-1, cioè con la configurazione che loro stessi usavano, non con altri scheduler adattivi della letteratura, che il paper cita ma non mette alla prova.

In produzione lo scheduler non è quello dimostrato. La capacità reale del motore va a gradini, non è la curva liscia che l’algoritmo presuppone, e il pipeline asincrono vuole sapere la dimensione del batch prima che il passo corrente finisca. Gli autori stimano allora il taglio con le fiducie di due passi prima e tolgono la fermata anticipata, sostenendo che il ritardo stesso fa da barriera causale e conserva l’esattezza. È un argomento ragionevole, ma resta un argomento: il ragionamento sull’esattezza, con il controesempio dell’appendice, è costruito sulla versione sincrona.

Le ipotesi di comodo sono dichiarate. Il throughput viene fatto dipendere solo dalla dimensione del batch e non dalla lunghezza dei contesti, cosa che gli autori giustificano con il bilanciamento del loro sistema. La valutazione offline usa la modalità senza ragionamento. E la bozza ha comunque un costo fisso: per le richieste difficili, dove quasi nulla verrà accettato, il calcolo speso a scriverla non si recupera. Gli autori indicano come via futura un’uscita anticipata della bozza stessa.

Perché conta adesso

A lungo la ricerca sullo speculative decoding ha misurato soprattutto una cosa: quanti token la bozza riesce a far accettare, su una richiesta sola. DSpark sposta la domanda dove sta il costo per chi gestisce un servizio: quanta verifica conviene comprare, adesso, con questo carico. La risposta non è più un numero fisso in un file di configurazione ma una decisione presa a ogni passo, come il casellante che apre e chiude corsie guardando la coda. Che la proposta venga da chi la usa ogni giorno su DeepSeek-V4, e che arrivi con i checkpoint per V4-Flash e V4-Pro e con DeepSpec, il repository di addestramento che include anche EAGLE-3 e DFlash, rende possibile la parte che il paper da solo non può dare: che altri la misurino sul proprio traffico.