DeepSeek e l’Universita di Pechino hanno presentato DSpark, un framework pensato per ridurre il collo di bottiglia della inferenza dei modelli linguistici di grandi dimensioni quando le richieste simultanee aumentano. L’obiettivo e semplice da capire: far rispondere piu in fretta i modelli senza sacrificare la qualita dell’output.
Il dato piu interessante, per chi guarda alle prestazioni concrete, e che DSpark e gia integrato nelle versioni di anteprima DeepSeek-V4-Flash e DeepSeek-V4-Pro.
DSpark prova a risolvere il limite piu costoso dei modelli AI in produzione
Il problema che DSpark prova a colpire e noto: nei modelli autoregressivi ogni nuovo token richiede un passaggio completo nella rete, quindi la latenza cresce con la lunghezza del testo generato. E uno dei motivi principali per cui i sistemi di chat AI diventano piu lenti proprio quando la richiesta e piu impegnativa.
Il framework parte dalla logica della speculative decoding, cioe la generazione rapida di candidati da parte di un modello piu leggero e la loro verifica in blocco da parte del modello principale. DSpark aggiunge pero due elementi chiave: una generazione candidata semi-autoregressiva e una verifica guidata dalla confidenza, pensate per migliorare sia il tasso di accettazione sia l’uso delle risorse di calcolo.
- La generazione candidata non e solo parallela: usa una struttura ibrida che combina un tronco principale parallelo e un modulo sequenziale leggero.
- Il sistema assegna a ogni posizione un punteggio di confidenza per stimare la probabilita che il token venga mantenuto dopo la verifica.
- La scelta della lunghezza da verificare non e fissa, ma adattata al carico e alla probabilita di sopravvivenza dei token.
- DSpark e gia stato impiegato nelle preview service di DeepSeek-V4-Flash e DeepSeek-V4-Pro.
La novita vera e nel mix tra parallelismo e dipendenze di contesto
Nel confronto con i draft model piu diffusi, DSpark prova a superare due limiti opposti. Da un lato ci sono i modelli autoregressivi come Eagle3, che mantengono buone dipendenze tra token ma diventano lenti quando il blocco candidato cresce. Dall’altro ci sono i modelli completamente paralleli come DFlash, rapidi in generazione ma piu fragili quando le posizioni successive iniziano a confliggere tra loro.
DSpark introduce un compromesso piu pratico: un backbone parallelo, basato su una versione migliorata di DFlash, produce gli stati nascosti e le logit di base; un modulo sequenziale leggero inserisce poi informazione di prefisso token per token. Questo consente di mantenere il vantaggio della generazione parallela iniziale, senza perdere del tutto la coerenza che aiuta l’accettazione dei token successivi.
Il lavoro sperimentale segnala che una versione DSpark con due layer Transformer supera, nei domini testati, l’accettazione di una versione DFlash con cinque layer. Tradotto in termini semplici: una piccola dose di dipendenza autoregressiva vale piu di un semplice aumento di profondita nella parte parallela.
- Modulo sequenziale disponibile in due varianti: testa di Markov o testa RNN.
- Il blocco candidato massimo usato in produzione e pari a 5 token.
- Nel deployment reale e stata scelta la testa di Markov come soluzione sequenziale.
- Il backbone parallelo include tre layer MoE e attenzione a finestra mobile.
Nei test di carico DSpark migliora anche il throughput complessivo
Il risultato piu utile per leggere la portata del progetto e che DSpark non migliora solo la latenza percepita dal singolo utente, ma anche il rendimento globale del sistema quando i carichi crescono. Nei test online con traffico reale, il framework e stato confrontato con il baseline a singolo token MTP-1 e ha mostrato vantaggi consistenti in diversi scenari di SLA.
Su V4-Flash, mantenendo una velocita minima di 80 token al secondo per singolo utente, il throughput aggregato sale del 51%. Quando l’SLA si stringe a 120 token al secondo, il baseline entra quasi nel suo limite operativo e DSpark arriva a un vantaggio di throughput dichiarato del 661%, grazie alla capacita di mantenere un batching utile anche in condizioni piu dure.
Su V4-Pro, invece, il guadagno di throughput e del 52% con SLA da 35 token al secondo e del 406% con SLA da 50 token al secondo. Nei casi in cui il throughput complessivo e allineato, la velocita di generazione per singolo utente cresce comunque del 57%-85%.
- Con bassa concorrenza, il scheduler assegna spesso 4-6 token di verifica per sfruttare la capacita inutilizzata.
- Con l’aumento del carico, la lunghezza di verifica si riduce in modo graduale per limitare la contesa delle risorse.
- Il sistema prova a massimizzare il throughput globale invece di proteggere solo il singolo campione di richiesta.
- Un limite resta: i candidati iniziali devono comunque essere generati per intero, anche se poi parte dei token viene scartata.
