DeepSeek ha rilasciato DSpark, un framework di decodifica speculativa open source che, secondo la società, accelera l'inferenza del modello LLM (Large Language Model) fino all'85% sotto traffico live, senza alcuna perdita di qualità dell'output. Descritto in un nuovo documento di DeepSeek-AI e dell'Università di Pechino, il sistema è già in esecuzione all'interno dell'infrastruttura di servizio DeepSeek-V4 che gestisce le richieste degli utenti reali.
Il lavoro affronta uno dei problemi più ostinati nell’IA di produzione: l’inferenza è lenta perché i modelli generano testo un token alla volta, ciascuno dei quali richiede un passaggio completo attraverso la rete. La decodifica speculativa è un rimedio popolare in cui un modello "bozza" piccolo e veloce propone un blocco di token che il modello a grandezza naturale verifica quindi in un unico passaggio, accettando il prefisso corretto più lungo. Poiché la verifica è parallela e matematicamente esatta, accelera le cose preservando la distribuzione del modello originale. DSpark, rilasciato insieme al repository di formazione DeepSpec su GitHub, è diventato rapidamente una delle storie di ingegneria dell'intelligenza artificiale più discusse su Hacker News. Per maggiori informazioni su questa storia, consulta la nostra aggiornamenti sull'intelligenza artificiale.
Perché la decodifica speculativa esistente si scontra con un muro
Recenti ricerche speculative sulla decodifica si sono spostate verso "drammatori paralleli" che generano un intero blocco di token candidati in un unico passaggio in avanti, rendendo la latenza della bozza quasi indipendente dalla dimensione del blocco. Il documento DSpark identifica due colli di bottiglia che hanno impedito a questi metodi di mantenere le loro promesse su larga scala.
Il primo è un problema di qualità. Poiché i redattori paralleli prevedono ciascuna posizione in modo indipendente, non possono modellare il modo in cui i token all'interno di un blocco dipendono l'uno dall'altro. I ricercatori mostrano che questo porta a "collisioni multimodali" e ad un rapido decadimento dell'accettazione nelle posizioni successive in un blocco di bozza, un fenomeno che chiamano decadimento del suffisso. Più lungo è il blocco parallelo, più è probabile che la sua coda sia sbagliata.
Il secondo è un problema a livello di sistema. Sebbene generare blocchi con bozze lunghe sia economico, verificare ciecamente ogni token proposto spreca una scarsa capacità batch sui token che potrebbero essere rifiutati. Sotto l'elevata concorrenza di un sistema di servizio reale, la durata ideale della verifica varia lungo due assi: le richieste strutturate come il codice sostengono tassi di accettazione più elevati rispetto alle chat aperte e la verifica di token aggiuntivi è quasi gratuita in condizioni di carico leggero ma costosa quando il sistema è saturo.
Un modello di bozza semi-autoregressivo
Per correggere il decadimento del suffisso, DSpark adotta quella che gli autori chiamano un'architettura semi-autoregressiva. Abbina una dorsale parallela computazionalmente pesante, che può proporre molti token contemporaneamente, con un modulo sequenziale leggero che introduce la modellazione delle dipendenze intra-blocco. Il design è pensato per combinare l'elevata capacità dei modelli paralleli nelle prime posizioni con la coerenza dei suffissi dei tradizionali drafter autoregressivi, che generano token uno dopo l'altro e rispettano naturalmente le dipendenze.
Su benchmark offline controllati che spaziano dal ragionamento matematico, alla generazione di codice e alla chat quotidiana, il team riferisce che DSpark migliora sostanzialmente la lunghezza accettata per ciclo di verifica rispetto a solidi parametri di base. Nello specifico, il documento afferma che DSpark migliora la lunghezza accettata rispetto al drafter autoregressivo Eagle3 del 30,9%, 26,7% e 30,0% su tre impostazioni e rispetto al drafter parallelo DFlash del 16,3%, 18,4% e 18,3%.
Verifica pianificata con fiducia e consapevole del carico
La parte più nuova di DSpark è il suo approccio alla verifica. Invece di verificare un numero fisso di bozze di token per ogni richiesta, DSpark formula la selezione della lunghezza di verifica come un problema di massimizzazione del throughput globale. Abbina stime calibrate di quanto tempo è probabile che il prefisso di una bozza sopravviva, ciò che il documento chiama probabilità di sopravvivenza, con uno scheduler basato sull'hardware che legge il carico del motore in tempo reale.
Il risultato è una verifica pianificata con fiducia: il sistema adatta dinamicamente il numero di token da verificare per ciascuna richiesta in base sia al contenuto della richiesta che allo stato corrente del motore di servizio. In condizioni di carico leggero può permettersi di effettuare verifiche generose, mentre in condizioni di forte concorrenza indirizza il budget di verifica del modello target solo verso token con il rendimento atteso più elevato, evitando il collasso del throughput derivante dalla spesa della capacità batch su token a bassa probabilità.
Risultati in Traffico utenti live
I numeri più importanti provengono dalla produzione. Il team ha implementato DSpark all'interno del sistema di servizio DeepSeek-V4 che serve il traffico degli utenti in tempo reale e lo ha confrontato con la precedente linea di base di produzione dell'azienda, un metodo di previsione multi-token noto come MTP-1.
Secondo il documento, DSpark accelera costantemente la velocità di generazione per utente dal 60% all'85% per DeepSeek-V4-Flash e dal 57% al 78% per DeepSeek-V4-Pro con un throughput aggregato corrispondente. In base a rigorosi accordi sul livello di servizio in cui la capacità di base si deteriora gravemente, l'equivalente di 120 token al secondo per Flash e 50 token al secondo per Pro, DSpark mitiga i costi di verifica per mantenere un throughput robusto. Superando questo limite prestazionale, gli autori sostengono che si sbloccano livelli di interattività rigorosi che prima erano irraggiungibili, spostando di fatto la frontiera paretiana del servizio LLM verso l’esterno.
Questa distinzione è importante per gli operatori. Una maggiore velocità per utente con lo stesso throughput totale significa assistenti e flussi di lavoro agenti più reattivi senza acquistare più hardware, mentre sopravvivere a rigorosi SLA di latenza sotto carico è ciò che separa una demo di ricerca da un sistema che può resistere durante i picchi di traffico.
Open source per la comunità
DeepSeek sta rilasciando i checkpoint DSpark addestrati per entrambi i modelli di anteprima DeepSeek-V4-Flash e DeepSeek-V4-Pro. Il repository DeepSpec allegato, pubblicato sotto la licenza permissiva del MIT, è descritto come un codebase di valutazione e formazione full-stack basato su algoritmi per la decodifica speculativa. Include utilità per la preparazione dei dati, implementazioni di modelli in bozza, script di formazione e strumenti di valutazione e viene fornito con tre algoritmi di modelli in bozza: DSpark, DFlash e Eagle3.
Il rilascio riduce gli ostacoli che impediscono ad altri laboratori e team infrastrutturali di addestrare e confrontare i propri modelli in bozza rispetto a una pipeline standardizzata. La suite di valutazione di DeepSpec copre benchmark consolidati tra cui GSM8K, MATH500, AIME 2025, HumanEval, MBPP, LiveCodeBench, MT-Bench, AlpacaEval e Arena-Hard-v2.
Perché è importante
I costi di inferenza e la latenza sono ora tra i vincoli che definiscono il settore dell’intelligenza artificiale, influenzando tutto, dal modo aggressivo con cui le aziende distribuiscono agenti di intelligenza artificiale alla capacità dei fornitori più piccoli di competere con gli hyperscaler sull’economia unitaria. Il contributo di DSpark non è tanto un singolo nuovo algoritmo quanto una dimostrazione che co-progettare attentamente la bozza del modello e lo scheduler di verifica, e trattare la durata della verifica come una funzione dello stato del sistema in tempo reale, può spostare significativamente l'ago nelle implementazioni reali.
Per DeepSeek, che ha costruito la sua reputazione su sistemi efficienti e rilasciati liberamente, DSpark è un altro punto di riferimento in una discussione che il laboratorio porta avanti da oltre un anno: che le prestazioni di servizio di frontiera possono essere ottenute attraverso un'ingegneria più intelligente piuttosto che solo attraverso il calcolo grezzo. Il fatto che i guadagni siano stati misurati in base al traffico in tempo reale, piuttosto che in un benchmark sintetico, rende il risultato più facile da prendere sul serio per gli altri operatori mentre la comunità open source digerisce il documento e inizia a riprodurre i numeri.
---
Rimani Aggiornato sull'IALe ultime notizie, analisi e scoperte sull'intelligenza artificiale — tutto in un posto.
Leggi altre notizie sull'IA →
