DeepSeek rilascia DSpark: generazione AI fino all’85% più veloce per utente

DeepSeek ha rilasciato DSpark, un framework di speculative decoding pensato per accelerare l’inferenza in produzione. Non è un nuovo modello: è un’ottimizzazione del servizio. I checkpoint DeepSeek-V4-Pro-DSpark e DeepSeek-V4-Flash-DSpark riutilizzano i pesi esistenti di V4, con un modulo draft aggiuntivo.

Il team ha anche open-sourced DeepSpec, una codebase con licenza MIT per addestrare e valutare drafters di speculative decoding. L’obiettivo è uno solo: inferenza più veloce su modelli grandi in produzione con carichi elevati.

Cos’è DSpark e perché è diverso

Lo speculative decoding funziona dividendo la generazione in due fasi: un modello draft piccolo propone un blocco di token, il modello target li verifica in un singolo forward pass. Se il blocco viene accettato, si guadagna velocità mantenendo la qualità dell’output invariata.

Il problema è che i drafters esistenti fanno un trade-off. Quelli autoregressivi come Eagle3 condizionano ogni token sui precedenti: accettazione alta, ma costo di drafting che cresce con la dimensione del blocco. Quelli paralleli come DFlash producono tutto il blocco in un passaggio: costo basso, ma accettazione che decade rapidamente verso la fine del blocco.

DSpark risolve il compromesso suddividendo il drafting in due stadi: una backbone parallela pesante produce i logit di base per ogni posizione, poi un sequential head leggero aggiunge un bias dipendente dal prefisso prima di campionare ogni token.

Il sequential head predefinito è un Markov head: guarda solo il token immediatamente precedente. Usa una fattorizzazione low-rank (rank 256) per restare economico anche con vocabolari grandi. Opzionalmente c’è un RNN head che traccia tutto il prefisso, ma i miglioramenti sono marginali, quindi il Markov head è il default.

Il guadagno è netto: DSpark eredita l’alta precisione del primo token dalla backbone parallela, mentre il sequential head mantiene stabile l’accettazione anche in profondità nel blocco.

Verifica adattiva al carico

Più token draft non significano sempre più velocità. Verificare token che verranno rifiutati spreca capacità batch sotto carico pesante. DSpark aggiunge due componenti per gestirlo:

• Confidence head: assegna un punteggio di confidenza a ogni posizione draft, stimando la probabilità che il token passi la verifica. Dopo un post-hoc calibration step (Sequential Temperature Scaling), l’errore di calibrazione scende dal 3-8% a circa l’1%.
• Prefix scheduler: imposta la lunghezza di verifica per ogni richiesta in base al carico. Usa una curva di throughput misurata all’avvio: quando le GPU sono libere, verifica più token; quando sono occupate, ne verifica meno.

Lo scheduler usa una regola di early-stopping per rimanere lossless. Una ricerca globale ingenua, spiega l’appendice del paper, farebbe perdere informazione.

Risultati: offline e produzione

Nei test offline su matematica, codice e chat quotidiana, DSpark supera entrambi i baseline su ogni dominio. La lunghezza accettata (accepted length) cresce del 26-31% contro Eagle3 e del 16-18% contro DFlash. Un DSpark a 2 layer batte addirittura un DFlash a 5 layer.

Il sequential head aggiunge poco costo: scalare il blocco draft da 4 a 16 token aumenta la latenza per round solo dello 0,2-1,3%, mentre la lunghezza accettata migliora fino al 30%.

I risultati di produzione arrivano da DeepSeek-V4-Flash e V4-Pro sotto traffico reale. Rispetto al baseline MTP-1, la velocità per utente sale del 60-85% su Flash e del 57-78% su Pro. La configurazione shipped è DSpark-5: blocco draft di 5 token con Markov head.

Casi d’uso: dove DSpark fa la differenza

• Generazione di codice: l’accettazione è naturalmente alta. Lo scheduler può verificare prefissi lunghi con poco spreco. I coding agent generano output più velocemente.
• Chat aperta: la confidence head identifica token incerti e li taglia. In un test, l’accettazione è passata dal 45,7% al 95,7%.
• Ragionamento matematico: tracce lunghe passo-passo beneficiano di un’accettazione stabile in profondità. L’accettazione è salita dal 76,9% al 92,5%.
• Servizio ad alta concorrenza: a carico moderato, lo scheduler verifica circa 4-6 token per richiesta. A concorrenza alta, taglia il budget per proteggere il throughput.

I checkpoint sono su Hugging Face con un esempio di inferenza pronto. DeepSpec si usa in tre fasi: preparazione dati, addestramento (bash scripts/train/train.sh), valutazione (bash scripts/eval/eval.sh). I config predefiniti assumono un nodo con 8 GPU. Attenzione: la cache target può arrivare a circa 38 TB per la configurazione Qwen3-4B.