Tencent rilascia AngelSpec in open source, sfidando lo speculative decoding universale

Tencent Hunyuan ha rilasciato AngelSpec in open source dopo aver riportato un'inferenza Hy3-A21B fino a 2,40 volte più veloce rispetto al decoding autoregressivo standard. Il framework combina supporto per addestramento, valutazione e deployment di due diversi percorsi di speculative decoding. La sua tesi centrale mette in discussione un'ipotesi diffusa: un unico metodo di drafting non può gestire in modo efficiente ogni carico di lavoro dei modelli linguistici.

AngelSpec include la previsione multi-token, o MTP, che propone diversi token futuri tramite un drafter autoregressivo leggero. Introduce inoltre DFly, un sistema di block diffusion che genera in parallelo un gruppo più lungo di token. Tencent afferma che DFly ha offerto una capacità di elaborazione dal 10,5% all'11,8% superiore a DFlash nelle condizioni di serving testate.

Il confronto è rilevante perché DFlash aveva già allontanato lo speculative decoding dal drafting strettamente sequenziale. AngelSpec non si limita a proporre un altro drafter più rapido. Organizza due approcci contrapposti in base al carico di lavoro che ciascuno gestisce meglio, quindi adatta la verifica alle condizioni di runtime.

Il risultato è un framework aperto con una visione più operativa dell'accelerazione dell'inferenza. Gli sviluppatori possono esaminare il percorso di addestramento, testare i modelli draft Hy3 rilasciati e osservare come le prestazioni cambiano al variare del traffico. Tuttavia, i guadagni riportati da Tencent derivano dai suoi modelli, dalle sue configurazioni e dal suo schema di valutazione. I risultati indipendenti in produzione restano la prova decisiva mancante.

AngelSpec trasforma una scelta di ricerca in una scelta di deployment

AngelSpec considera lo speculative decoding come un problema di selezione del carico di lavoro, non come una competizione per un'unica architettura di drafting universale.

I ricercatori di Tencent hanno presentato la prima versione del paper su AngelSpec il 28 luglio 2026. Una versione rivista è seguita il 29 luglio. L'azienda ha poi annunciato il rilascio open source con il codice di addestramento e i pesi del modello draft Hy3-A21B.

Lo speculative decoding utilizza un drafter più piccolo o meno costoso per proporre diversi token futuri. Il modello target completo verifica insieme tali proposte e accetta il prefisso corrispondente. Quando le proposte sono accurate, il sistema produce diversi token validi evitando un numero equivalente di costosi passaggi del modello target.

Il metodo preserva la distribuzione di output del modello target quando è implementato con il processo richiesto di verifica e rifiuto. Cambia quindi l'efficienza con cui vengono generati i token, anziché sostituire le risposte del modello target con quelle del drafter.

La qualità del draft determina comunque se quel vantaggio teorico si traduca in un'accelerazione pratica. Un drafter debole produce token rifiutati, aggiungendo lavoro senza far avanzare la generazione. Un drafter grande può prevedere con precisione, ma consumare troppo tempo e memoria. Anche la verifica può diventare costosa quando i sistemi testano più candidati di quanti una richiesta giustifichi.

AngelSpec riunisce queste variabili in un unico framework di addestramento e valutazione. Supporta MTP e lo speculative decoding block-parallel, inclusi generazione di hidden state, addestramento a contesto lungo, workflow di rollout e valutazione online dell'accettazione. Il rilascio punta a coprire una parte più ampia del percorso tra un checkpoint di ricerca e un servizio di inferenza operativo.

I due percorsi di drafting del framework dividono il problema in base al comportamento dell'output. Tencent addestra il suo drafter MTP su dati conversazionali diversificati, dove il linguaggio è aperto e i token successivi restano relativamente incerti. Addestra il percorso block-diffusion su codice e matematica, dove le continuazioni più lunghe seguono spesso strutture più prevedibili.

Questa specializzazione è il cambiamento più importante dell'evento. Molti confronti sullo speculative decoding chiedono quale metodo vinca in media. AngelSpec chiede invece quale struttura di drafting si adatti a una distribuzione specifica, quindi espone entrambe le strutture attraverso un percorso di sviluppo comune.

I pesi allegati rendono inoltre il rilascio più verificabile di un paper che descrive un sistema non disponibile. Tencent afferma di aver rilasciato drafter MTP e DFly per Hy3-A21B attraverso i propri canali di modelli. Gli sviluppatori necessitano ancora del corrispondente modello target e di hardware di serving adeguato, ma non devono ricreare ogni fase di addestramento prima di iniziare la valutazione.

Hy3 fornisce al rilascio un target impegnativo. Il repository ufficiale del modello Hy3 descrive un modello mixture-of-experts con 295 miliardi di parametri totali e 21 miliardi di parametri attivi. Elenca inoltre un layer MTP da 3,8 miliardi di parametri e una finestra di contesto da 256.000 token.

Queste specifiche rendono l'efficienza dell'inferenza economicamente importante. Solo una frazione del modello completo si attiva per ciascun token, ma il serving richiede comunque notevoli risorse di memoria, comunicazione e calcolo del modello target. Un drafter che aumenta l'output accettato per ogni fase di verifica può migliorare la latenza o la capacità di elaborazione senza riaddestrare il modello primario.

AngelSpec arriva quindi come qualcosa di più di un altro accessorio per Hy3. Offre un framework esplicito per scegliere, addestrare e valutare sistemi draft al mutare delle condizioni di serving. Questa portata più ampia esercita pressione sullo speculative decoding universale.

I guadagni riportati mettono sotto pressione le strategie di drafting statiche

L'affermazione più forte di Tencent non è solo il picco di accelerazione, ma il vantaggio di DFly a ogni livello di concorrenza testato da 4 a 64.

Secondo il paper, DFly ha offerto un'accelerazione end-to-end da 1,98 a 2,40 volte rispetto al decoding autoregressivo su Hy3-A21B. Tencent riporta inoltre una capacità di elaborazione superiore dal 10,5% all'11,8% rispetto a DFlash e un output medio accettato più lungo di circa il 30%.

La concorrenza misura quante richieste il sistema di serving elabora contemporaneamente. Modifica l'equilibrio tra calcolo, efficienza del batching, pressione sulla memoria e overhead di verifica. Un metodo che appare veloce per una sola richiesta può perdere il proprio vantaggio quando molte richieste competono per gli stessi acceleratori.

Tencent afferma che DFly ha ottenuto la più alta capacità di elaborazione media a ogni livello di concorrenza testato, da 4 a 64. Questo intervallo è rilevante perché comprende traffico relativamente leggero e un servizio con batching più intenso. Il risultato suggerisce che lo scheduler e la strategia di verifica di DFly abbiano contribuito oltre al tasso grezzo di accettazione del modello draft.

I numeri richiedono comunque un'interpretazione prudente. Un'accelerazione di 2,40 volte non significa che ogni utente riceva risposte 2,40 volte prima. L'accelerazione end-to-end dipende dal carico di lavoro del benchmark, dalla lunghezza dell'output, dal mix di richieste, dalla politica di batching, dal profilo hardware e dalla configurazione di base.

Capacità di elaborazione e latenza rispondono inoltre a domande diverse. La capacità di elaborazione misura quanto lavoro un sistema completa nel tempo. Gli utenti interattivi sono spesso più interessati al tempo fino al primo token e al ritardo tra i token successivi. Un servizio può aumentare la capacità totale producendo al contempo miglioramenti più piccoli o disomogenei per una singola richiesta.

Questa distinzione mette sotto pressione i team di inferenza che utilizzano politiche di drafting fisse. Una politica statica può scegliere una lunghezza del draft, una profondità di verifica o un drafter per tutto il traffico. AngelSpec sostiene che queste scelte dovrebbero rispondere al dominio, alle caratteristiche delle richieste, al carico online e all'hardware di deployment.

Il bersaglio della pressione non è quindi un'azienda specifica. È l'approccio che considera lo speculative decoding come un'estensione fissa del modello. Se i risultati di Tencent troveranno conferma altrove, gli operatori avranno bisogno di logiche di routing e scheduling capaci di capire quando il lavoro di drafting continua a essere utile.

DFlash offre il confronto più diretto. Il suo design block-diffusion utilizza gli hidden state del modello target per prevedere in parallelo più token draft. L'approccio evita di generare ogni proposta attraverso un passaggio separato e sequenziale del drafter.

Gli autori di DFlash hanno riportato un'accelerazione superiore a sei volte in esperimenti selezionati e miglioramenti rispetto a EAGLE-3. Questi risultati hanno utilizzato target e condizioni di test differenti, quindi non devono essere confrontati direttamente con il massimo di 2,40 volte di AngelSpec. L'affermazione rilevante di Tencent è il confronto controllato con DFly riportato nella propria valutazione di Hy3.

I sistemi in stile EAGLE restano un altro importante riferimento. Utilizzano le caratteristiche del modello target per guidare un drafter autoregressivo più piccolo, spesso organizzando le proposte per una verifica efficiente. Questi sistemi possono offrire risultati stabili su testi diversi, ma le dipendenze sequenziali all'interno del drafting possono limitare la rapidità con cui vengono proposte lunghe sequenze candidate.

MTP occupa una versione più leggera di quel percorso autoregressivo. È più facile da integrare quando il target espone già layer di previsione compatibili. Il rilascio Hy3 di Tencent include un layer MTP, rendendo il modello un banco di prova naturale per confrontare il drafting leggero con un sistema block-parallel specializzato.

La pressione esercitata da AngelSpec sui deployment esistenti è pratica. I team devono decidere se il modello aggiuntivo, la logica di scheduling, il profiling e l'uso di memoria producano abbastanza token accettati da giustificarne la complessità. Il framework offre loro codice e pesi per esplorare questa domanda, ma non rende universale la risposta.

Come AngelSpec rende DFly più selettivo

DFly combina drafting parallelo e informazioni autoregressive, poi investe il lavoro di verifica dove il rendimento atteso è più elevato.

Un drafter block-diffusion prevede diverse posizioni insieme anziché completarle una alla volta. La previsione parallela riduce la latenza del drafting, soprattutto quando il blocco candidato è lungo. Tuttavia, i token all'interno di una frase o di una sequenza di codice dipendono fortemente dai token precedenti nello stesso blocco.

Questa dipendenza crea un punto debole. Se ogni posizione viene prevista a partire da vicini mascherati o incompleti, le proposte successive possono non disporre delle informazioni che un drafter autoregressivo riceve naturalmente. Un errore iniziale può accorciare il prefisso accettato dal modello target, sprecando gran parte del blocco proposto.

DFly affronta questa tensione con due componenti connesse. Il suo backbone è condizionato dalle caratteristiche del modello target, pur mantenendo la generazione block-parallel. Una testa autoregressiva condizionata dal predecessore fornisce inoltre alle previsioni informazioni sui token precedenti, migliorando le dipendenze all'interno del blocco proposto.

L'architettura non trasforma l'intero draft in un processo sequenziale convenzionale. Il design di Tencent cerca di preservare il lavoro parallelo nel backbone aggiungendo al contempo informazioni sufficienti sui predecessori per migliorare la coerenza dei candidati. Questo equilibrio è centrale per il dichiarato aumento della lunghezza media accettata.

La lunghezza accettata è il numero di token proposti che il modello target approva prima di incontrare una discrepanza. Prefissi accettati più lunghi distribuiscono ogni costosa fase di verifica su una maggiore quantità di output utile. Tuttavia, massimizzare la sola lunghezza accettata può essere fuorviante se la produzione e il controllo di tali candidati consumano troppo tempo.

AngelSpec aggiunge quindi un metodo di verifica adattiva chiamato D-Cut. La profondità di verifica indica quanta parte di ciascuna continuazione proposta il modello target controlla. Una profondità fissa può investire eccessivamente in candidati incerti o fermarsi troppo presto su quelli altamente prevedibili.

D-Cut considera la capacità di verifica come una risorsa condivisa a livello di batch. Stima il valore atteso del mantenimento di ulteriori posizioni candidate e confronta tale valore con un costo di runtime profilato. Lo scheduler può quindi indirizzare più lavoro di verifica verso prefissi ad alta confidenza attraverso più richieste.

Questa è una decisione di serving, non semplicemente una decisione sul modello. Due richieste eseguite sullo stesso modello possono giustificare livelli di verifica diversi. Un completamento di codice strutturato può mantenere un prefisso lungo e sicuro, mentre una risposta in chat aperta può divergere dopo pochi token.

Anche l'hardware cambia il calcolo. Un batch di verifica più grande può essere efficiente su una configurazione di acceleratori e costoso su un'altra. Costi di comunicazione, larghezza di banda della memoria, kernel e parallelismo del modello target influenzano tutti la convenienza temporale di un'ulteriore posizione candidata.

Per questo AngelSpec profila il costo di runtime invece di basarsi soltanto sulle stime di probabilità. Un candidato può sembrare destinato a essere accettato, ma offrire comunque una scarsa utilità se il suo controllo espande un batch in una forma inefficiente. Lo scheduler necessita sia della confidenza sia di un costo di sistema misurato.

La documentazione sul decoding speculativo di Nvidia illustra come i framework di deployment espongano già configurazioni specifiche per metodo. Il supporto DFlash richiede un draft model, una draft length, un mask token e layer target selezionati. AngelSpec spinge ulteriormente il problema verso un'allocazione adattiva tra richieste live.

La suddivisione per dominio integra quell'adattamento di runtime. MTP resta il percorso leggero per output conversazionali con maggiore incertezza. DFly è rivolto a codice e matematica, dove blocchi paralleli possono catturare sequenze prevedibili più lunghe. Nessuno dei due metodi ottiene automaticamente il diritto a gestire ogni richiesta.

Si consideri un servizio di coding AI che genera una suite di test ripetitiva. Importazioni, firme delle funzioni e schemi delle asserzioni possono rendere il blocco successivo relativamente prevedibile. DFly può proporre una continuazione più lunga, e D-Cut può mantenere una verifica più approfondita quando la confidenza resta alta.

Si consideri ora lo stesso servizio mentre risponde a una domanda ambigua sull'architettura. Più spiegazioni valide possono iniziare dallo stesso prompt. Il prefisso accettato può accorciarsi perché il drafter e il target scelgono formulazioni diverse. Una proposta MTP più piccola può evitare di spendere risorse per un lungo blocco candidato con basse probabilità di sopravvivenza.

Questo meccanismo rende il rilascio più rilevante di un singolo miglioramento nei benchmark. Riformula il decoding speculativo come una policy che abbraccia dati di addestramento, architettura del drafter, classificazione delle richieste e costo di serving. L'aumento di velocità deriva dal coordinamento di questi livelli, anziché dalla massimizzazione di un singolo punteggio isolato.

Cosa non dimostrano i numeri di AngelSpec

AngelSpec fornisce prove proprietarie credibili, ma non dimostra ancora che DFly vinca tra modelli, hardware o traffico di produzione.

I risultati del paper provengono dal team che ha progettato il framework e addestrato i draft model. Al momento del rilascio, i confronti riportati non sono stati riprodotti indipendentemente. I lettori dovrebbero considerare gli aumenti di velocità come affermazioni aziendali misurate, non come garanzie universali di prestazioni.

La dipendenza dal modello è la prima limitazione. DFly usa feature interne del target, quindi un drafter è strettamente legato all'architettura e alle caratteristiche di addestramento del proprio target. Un drafter Hy3-A21B non può semplicemente diventare un acceleratore plug-and-play per una famiglia di modelli non correlata.

Questo legame aumenta i costi di addestramento e manutenzione. Ogni target supportato potrebbe richiedere un proprio processo di estrazione degli hidden state, una miscela di dati di addestramento, un checkpoint e un ciclo di validazione. Gli aggiornamenti del modello target possono inoltre richiedere nuovi test di compatibilità o un nuovo addestramento del drafter.

La dipendenza dall'hardware crea un'altra incertezza. Tencent afferma che D-Cut utilizza un costo di runtime profilato, riconoscendo che la migliore policy di verifica cambia tra sistemi diversi. Una policy ottimizzata per un cluster potrebbe richiedere nuovi profili prima di funzionare bene su acceleratori o topologie di rete differenti.

Anche i numeri principali pubblici comprimono diversi carichi di lavoro in intervalli. Codice, matematica e conversazione hanno prevedibilità differenti. Il throughput medio può nascondere categorie deboli, lunghezze di prompt sfavorevoli o schemi di traffico in cui l'overhead di drafting si avvicina al calcolo target risparmiato.

Il comportamento con contesti lunghi merita un'attenzione particolare. AngelSpec supporta l'addestramento long-context e Hy3 indica una finestra di contesto di 256.000 token. Tuttavia, grandi cache key-value aumentano la pressione sulla memoria e possono modificare il costo relativo di drafting e verifica. I risultati con contesti più brevi non possono risolvere la questione delle prestazioni vicino alla finestra massima del modello.

Anche la preservazione della qualità richiede rigore nell'implementazione. Il decoding speculativo può preservare la distribuzione del target attraverso un corretto algoritmo di accettazione e rifiuto. Scorciatoie di deployment, verifica approssimata, sampling modificato o quantizzazione incompatibile possono cambiare gli output. Gli operatori devono convalidare sia la velocità sia l'equivalenza comportamentale.

Anche la memoria è un costo reale. Il modello target, il draft model, le interfacce degli hidden state e buffer di runtime aggiuntivi devono coesistere. Persino un drafter leggero può ridurre lo spazio disponibile per la cache key-value o per batch più grandi. Il conseguente compromesso di capacità può annullare un guadagno di throughput in deployment vincolati dalla memoria.

Conta anche la complessità operativa. Un servizio di produzione deve monitorare lunghezza di accettazione, tempo di drafting, tempo di verifica, comportamento delle code e prestazioni di fallback. Il routing tra MTP e DFly introduce un ulteriore livello decisionale, i cui errori possono inviare i carichi di lavoro sbagliati al drafter sbagliato.

Il rilascio open-source rende queste questioni verificabili, ed è un aspetto prezioso. Non le risolve automaticamente. I team dovrebbero riprodurre una baseline autoregressiva sul proprio hardware prima di confrontare uno dei due percorsi AngelSpec.

Dovrebbero quindi separare le misurazioni per carico di lavoro e livello di traffico. Categorie utili includono chat interattiva, completamento di codice, ragionamento matematico, tracce di tool-use e generazione long-form. Ogni categoria dovrebbe includere percentili di latenza, throughput, consumo di memoria, lunghezza di accettazione e controlli di equivalenza dell'output.

Un confronto equo con DFlash richiede anche condizioni allineate. Devono essere usati lo stesso modello target, precisione, framework di serving, distribuzione dei prompt, lunghezza dell'output e concorrenza. Altrimenti, le affermazioni architetturali possono intrecciarsi con qualità dei kernel o differenze di configurazione.

Il feedback della community offre segnali iniziali, ma non sostituisce una riproduzione controllata. I report di deployment locale utilizzano spesso modelli quantizzati, hardware consumer o motori di serving modificati. Questi risultati possono rivelare problemi di compatibilità, anche se raramente corrispondono abbastanza da vicino alla configurazione del paper da convalidarne l'intervallo principale.

Il divario nei benchmark non rende AngelSpec irrilevante. Definisce la fase successiva della storia. Tencent ha fornito un'architettura, un percorso di codice e pesi del modello che team esterni possono mettere alla prova in condizioni non controllate dagli autori originali.

Tre segnali determineranno se AngelSpec andrà oltre Hy3

L'importanza di AngelSpec dipenderà dalla replica indipendente, dal supporto per modelli più ampio e da prove che il routing adattivo regga il traffico reale di produzione.

Il primo segnale è un benchmark Hy3-A21B riproducibile da parte di un team di inferenza indipendente. Il test più solido userebbe i pesi MTP e DFly rilasciati, riportando al contempo hardware, precisione, versioni del framework, mix di prompt e lunghezze degli output. Dovrebbe confrontare decoding autoregressivo, MTP, DFlash e DFly in condizioni allineate.

Una replica vicina all'intervallo da 1,98 a 2,40 volte di Tencent rafforzerebbe l'affermazione centrale. Guadagni coerenti rispetto a DFlash suggerirebbero inoltre che il predecessor conditioning e D-Cut aggiungono valore oltre al drafting generale con block diffusion. Guadagni minori o instabili ridurrebbero l'attrattiva pratica di AngelSpec.

Il report indipendente più utile pubblicherebbe più del throughput medio. Dovrebbe includere tempo al primo token, latenza inter-token, latenza di coda, utilizzo della memoria, lunghezza accettata e prestazioni a vari livelli di concorrenza. Queste misurazioni mostrerebbero se l'efficienza aggregata migliora l'esperienza utente.

Il secondo segnale è il supporto per un'altra importante famiglia di modelli target. AngelSpec dispone attualmente delle prove più chiare e dei pesi draft rilasciati attorno a Hy3. Un porting riuscito a Qwen, Llama o a un altro modello open ampiamente adottato verificherebbe se il suo framework si generalizza oltre l'architettura di Tencent.

Il porting esporrebbe anche il reale costo di adozione. I ricercatori dovrebbero generare hidden state del target, addestrare drafter specializzati, integrare la verifica e profilare il comportamento di runtime. Un porting documentato con un impegno ingegneristico ragionevole rafforzerebbe l'affermazione del framework in merito all'usabilità end-to-end.

L'assenza di porting suggerirebbe che AngelSpec è principalmente un pacchetto di ottimizzazione per Hy3. Tale risultato potrebbe comunque beneficiare gli utenti dei modelli Tencent, ma indebolirebbe la tesi più ampia di un framework unificato per il decoding speculativo.

Il terzo segnale è costituito da prove di produzione su carichi di lavoro misti. L'argomentazione di Tencent si basa sull'eterogeneità, quindi un benchmark statico non può convalidarla pienamente. Il test decisivo è se un servizio live possa scegliere tra MTP e DFly mentre cambiano traffico, domini e utilizzo dell'hardware.

Gli operatori dovrebbero osservare con quale frequenza le decisioni di routing migliorano l'output accettato per unità di costo di verifica. Dovrebbero inoltre misurare tassi di fallback ed errori di routing. Un sistema adattivo complesso deve superare una baseline più semplice dopo aver incluso il suo overhead di monitoraggio e scheduling.

Questo test è particolarmente rilevante per servizi che combinano chat, coding, lavoro matematico e azioni degli agenti. Tali prodotti generano output con entropia e lunghezza molto diverse. Offrono le condizioni in cui il drafting specializzato dovrebbe superare una policy universale.

Se i deployment con carichi di lavoro misti mostrano guadagni stabili, i concorrenti saranno spinti a esporre controlli di routing simili. I framework di serving potrebbero evolvere dalla selezione di un singolo algoritmo speculativo all'avvio verso l'assegnazione, per richiesta, di algoritmi e budget di verifica.

Se i guadagni collassano fuori da carichi di lavoro curati, i metodi più semplici resteranno attraenti. MTP può essere più facile da gestire, soprattutto quando un modello viene già distribuito con layer compatibili. Le strategie draft statiche riducono inoltre il numero di modelli e policy che i team devono mantenere.

Gli sviluppatori che valutano il rilascio dovrebbero conservare i risultati dei test e le decisioni di configurazione in una base di conoscenza ingegneristica ricercabile. Gli esperimenti di decoding speculativo coinvolgono abbastanza variabili interagenti che le esecuzioni non documentate diventano rapidamente impossibili da confrontare.

AngelSpec ha già cambiato la domanda che gli ingegneri dell'inferenza devono affrontare. La scelta non è più soltanto se abilitare il decoding speculativo. È se il drafter, la distribuzione di addestramento, la policy di verifica e il profilo hardware corrispondano abbastanza bene a ogni richiesta da risparmiare lavoro reale.

I prossimi uno-tre mesi dovrebbero rivelare se team esterni riprodurranno i numeri di Tencent, porteranno DFly oltre Hy3 e convalideranno il routing adattivo sotto domanda live. Fino ad allora, AngelSpec è un serio esperimento open con risultati proprietari promettenti, non un vincitore consolidato.

Per i team che oggi servono Hy3, il prossimo passo utile è un benchmark controllato rispetto alle configurazioni autoregressive e MTP esistenti. Per tutti gli altri, la domanda chiave è più circoscritta: il drafting consapevole del carico di lavoro offre un'efficienza sostenuta sufficiente a giustificare un ulteriore modello e livello di scheduling? La risposta determinerà se AngelSpec diventerà un framework di inferenza ampiamente adottato o resterà un vantaggio ben progettato legato principalmente alla famiglia di modelli di Tencent.