DeepSeek ha pubblicato un paper che descrive DSpark, un sistema per accelerare la generazione di testo dei modelli linguistici in fase di produzione. Tra gli autori figurano Xin Cheng e altri ricercatori di Peking University, insieme al fondatore di DeepSeek, Liang Wenfeng. Il documento dichiara un aumento della velocità di generazione per utente compreso tra il 60% e l’85% sul modello V4-Flash e tra il 57% e il 78% su V4-Pro, le due declinazioni dell’ultima famiglia di modelli aperti presentata di recente da DeepSeek.
I modelli linguistici generano un token alla volta, e ogni passaggio richiede il recupero completo dei pesi del modello e della cache di attenzione dalla memoria della GPU. Il calcolo vero e proprio pesa poco: a pesare è il trasferimento dei dati, che lascia i core di calcolo della GPU inattivi per la maggior parte del tempo. La decodifica speculativa aggira il problema con un modello piccolo e veloce, il “drafter”, che propone in anticipo una sequenza di token verificata poi tutta insieme dal modello grande.
Il compromesso che nessun drafter aveva ancora risolto
Il drafter sequenziale, usato da tecniche come EAGLE-3, genera un token alla volta e resta accurato, ma il tempo di generazione cresce con la lunghezza del blocco proposto. Il drafter parallelo, come DFlash, produce l’intero blocco in un solo passaggio e resta veloce indipendentemente dalla lunghezza, ma ogni posizione viene prevista in isolamento, senza sapere cosa hanno scelto le posizioni vicine.
Il paper porta un esempio diretto: se il modello deve scegliere tra “certo” e “nessun problema”, un drafter parallelo può mescolare le due risposte in “certo problema”. Due posizioni dopo l’inizio del blocco, buona parte della probabilità è già incoerente: è il suffix decay, il degrado di coda del blocco proposto.
Un blocco lungo che perde senso a metà strada rallenta invece di accelerare.
DSpark aggiunge una memoria minima a un motore già rapido
DSpark separa la generazione del blocco in due fasi. Il motore parallelo, costruito sopra DFlash, produce in un solo passaggio le probabilità di base per ogni posizione del blocco. Una seconda testa, leggera e sequenziale, corregge quella coerenza guardando solo il token immediatamente precedente: una struttura di tipo markoviano, resa economica da una compressione che riduce la matrice di transizione tra vocabolario e vocabolario a un rango di 256 dimensioni.
Il costo aggiuntivo dichiarato è marginale: tra lo 0,2% e l’1,3% di latenza in più rispetto al drafter parallelo di partenza, a fronte di un guadagno fino al 30% nella lunghezza di blocco accettata a parità di dimensione proposta.
Quanto verificare conta più di cosa proporre
Un blocco più coerente non basta se il sistema lo verifica per intero anche quando la coda è comunque destinata al rifiuto. DSpark aggiunge una testa di confidenza che stima, per ogni token proposto, la probabilità che sopravviva alla verifica del modello grande, calibrata con una tecnica che il paper chiama scalatura di temperatura sequenziale.
Nei test su Qwen3-4B, alzare la soglia di confidenza porta il tasso di accettazione dei token proposti sulla chat generica dal 45,7% al 95,7%, sulla matematica dal 76,9% al 92,5% e sul codice dal 67,6% al 92%. Uno scheduler che legge in tempo reale il carico dell’hardware usa poi queste stime per allocare la capacità di verifica tra tutte le richieste attive: più margine quando il sistema è scarico, blocchi più corti quando il traffico sale.
I numeri di produzione, con l’avvertenza che il paper mette per iscritto
Nel confronto offline su Qwen3 a 4, 8 e 14 miliardi di parametri, DSpark migliora la lunghezza media dei token accettati del 26,7-30,9% rispetto a EAGLE-3 e del 16,3-18,4% rispetto a DFlash. Distribuito nei sistemi di produzione di DeepSeek-V4 sotto traffico reale, accelera la generazione per utente del 60-85% su V4-Flash e del 57-78% su V4-Pro rispetto a MTP-1, il precedente meccanismo di predizione multi-token di DeepSeek.
Sotto un vincolo severo di 120 token al secondo per utente su V4-Flash, la differenza dichiarata sale fino al 661% di throughput aggregato in più rispetto a MTP-1. Qui il paper aggiunge una precisazione che buona parte della copertura ha saltato: a quella soglia il sistema precedente collassa quasi del tutto, quindi il confronto va letto come prova che DSpark rende disponibili livelli di interattività prima irraggiungibili, più che come un moltiplicatore reale di velocità su un sistema già ben utilizzato.
Un baseline che crolla rende ogni confronto spettacolare: va riletto due volte.
Una verifica indipendente esiste già, in scala ridotta
Tutti i numeri sopra vengono dal paper e dalle metriche interne di DeepSeek: nessun laboratorio ha ancora replicato per intero i risultati alla scala di produzione di V4. Un tentativo indipendente esiste comunque: un port di DSpark per Apple Silicon, pubblicato su GitHub, misura su modelli Qwen3 e Gemma-4 un’accelerazione tra 1,4 e 1,65 volte rispetto alla generazione senza speculazione, un intervallo compatibile con quello dichiarato da DeepSeek per la produzione (1,57-1,85 volte).
Il confronto ha un limite evidente: gira su un solo utente, su un Mac, con modelli più piccoli del V4 di produzione. Resta una conferma parziale ottenuta da terzi, più solida di un annuncio mai messo alla prova fuori da DeepSeek.
DeepSpec conta più della percentuale in copertina
Insieme al paper, DeepSeek ha rilasciato anche DeepSpec, un toolkit con licenza MIT per addestrare e valutare drafter propri. Il repository include le implementazioni di DSpark, DFlash ed EAGLE-3 sotto un unico framework di addestramento, con checkpoint pubblicati per le famiglie Qwen3 e Gemma, non solo per i modelli DeepSeek.
Questo è il punto che cambia le cose per chi gestisce infrastrutture proprie: la tecnica diventa un metodo replicabile su modelli aperti già in uso altrove, disponibile a chiunque abbia un modello Qwen3 o Gemma da accelerare. Chi si affida a un’API ospitata ne beneficia solo quando il fornitore la adotta; chi ospita i propri modelli può addestrare un drafter DSpark sul proprio traffico da subito.
Il codice aperto rende i risultati controllabili da chiunque li metta alla prova.
La velocità è reale sulla carta, il conto tocca farlo in casa
Il meccanismo tecnico regge: la decodifica speculativa non altera la distribuzione di probabilità del modello finale, e la qualità delle risposte resta quella di sempre. Il guadagno è di velocità e di capacità del sistema, un punto che distingue DSpark da tecniche come quantizzazione o distillazione, che invece scambiano un po’ di qualità per un po’ di velocità.
Detto questo, i margini dichiarati restano cifre di parte, misurate sul traffico e sull’hardware di DeepSeek, contro un baseline che DeepSeek stessa ha costruito e ottimizzato. Chi valuta la tecnica sui propri modelli aperti farebbe bene a misurare il tasso di accettazione sul proprio traffico reale, non a fidarsi della percentuale in copertina: il paper stesso mostra quanto quel numero cambi tra chat generica, codice e matematica.
Per chi affitta GPU o paga a token, la notizia utile non è il record ottenuto da DeepSeek in un vincolo estremo di laboratorio, è che la tecnica sottostante è aperta, verificabile e già portata su hardware di fascia bassa con risultati coerenti. È lo stesso terreno su cui si gioca la partita più ampia dei costi di inferenza, dove il mercato si sta spostando dall’addestramento verso la produzione, e dove la scelta tra ospitare i modelli in casa o affittarli in cloud pesa direttamente sul margine finale.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Tom’s Hardware
Source link
