Cos'è lo speculative decoding? Come gli LLM propongono e verificano token più velocemente

Lo speculative decoding è una tecnica di inferenza per LLM che accelera la generazione dei token senza modificare la qualità dell’output. Un modello di bozza più piccolo e veloce propone in anticipo diversi token candidati e il modello obiettivo, più grande, li controlla tutti in un unico passaggio parallelo: mantiene le previsioni valide e ricampiona dalla prima discrepanza per preservare la propria distribuzione esatta dell’output.

I modelli linguistici di grandi dimensioni generano solitamente le risposte un token alla volta. Ogni nuova fase di output richiede la lettura dei pesi del modello dalla memoria, lasciando sottoutilizzata la capacità di calcolo dell’acceleratore mentre si attende la larghezza di banda della memoria. Lo speculative decoding supera il collo di bottiglia di un token per passaggio trasformando i controlli sequenziali in una verifica parallela.

Perché la decodifica autoregressiva standard è lenta?

La decodifica autoregressiva standard è lenta perché la generazione di ogni token richiede un passaggio in avanti separato attraverso l’intero modello. Il processo è quindi limitato dalla larghezza di banda della memoria anziché dalla capacità di calcolo.

Quando un modello linguistico scrive una risposta, ogni token dipende da tutti quelli precedenti. Nella decodifica standard, un modello da 70 miliardi di parametri deve caricare i propri pesi dalla memoria ad alta larghezza di banda per produrre il primo token, caricare nuovamente gli stessi pesi per produrre il secondo e ripetere questo ciclo centinaia di volte.

Eppure molti token di una risposta sono facili da prevedere. Parole funzionali, parentesi di chiusura nel codice, frasi comuni e sintassi ripetitiva non richiedono tutta la profondità di ragionamento di un modello enorme per essere indovinati con precisione, anche se si desidera comunque che il modello grande esprima il giudizio finale sull’intera risposta. Poiché GPU e TPU possono elaborare un breve blocco di token in parallelo quasi nello stesso tempo effettivo necessario per un singolo token, durante la decodifica di un token la capacità di calcolo aggiuntiva rimane inutilizzata. Lo speculative decoding mette al lavoro questa capacità parallela disponibile.

Come funziona lo speculative decoding passo dopo passo?

Lo speculative decoding esegue un ciclo di quattro fasi fino al completamento della risposta: propone token candidati, li verifica in parallelo con il modello obiettivo, accetta quelli corrispondenti e ricampiona al primo rifiuto.

Invece di chiedere al grande modello obiettivo di generare ogni token in sequenza, il motore di inferenza lo affianca a un’approssimazione molto più piccola e veloce, spesso chiamata modello di bozza. Ogni ciclo attraversa quattro fasi distinte:

1. Proposta dei token candidati: Partendo dalla sequenza corrente, il piccolo modello di bozza genera rapidamente, uno alla volta, una breve finestra di anticipazione di $K$ token candidati e registra la propria distribuzione di probabilità per ciascuna posizione.
2. Verifica parallela: Il grande modello obiettivo riceve la sequenza originale insieme a tutti i $K$ token proposti ed esegue un solo passaggio in avanti. Poiché le architetture transformer possono valutare sequenze di token note in parallelo, proprio come durante l’elaborazione del prompt, il modello obiettivo calcola simultaneamente le proprie distribuzioni di probabilità per ogni posizione proposta.
3. Accettazione o rifiuto dei token proposti: Scorrendo da sinistra a destra i $K$ token proposti, il motore confronta a ogni passaggio la probabilità del modello di bozza con quella del modello obiettivo tramite una regola formale di campionamento per rifiuto, spesso chiamata speculative sampling. Nella decodifica greedy, con temperatura zero, un token proposto viene accettato quando coincide con la prima scelta del modello obiettivo. Nelle modalità di campionamento, i token ai quali il modello obiettivo assegna almeno la stessa probabilità del modello di bozza vengono sempre accettati, mentre quelli con probabilità inferiore vengono accettati in proporzione al rapporto tra la probabilità del modello obiettivo e quella del modello di bozza.
4. Ricampionamento e generazione di un token bonus: Se la prima discrepanza si verifica nella posizione $m$, quel token e tutti i token proposti successivi vengono scartati. Un token sostitutivo per la posizione $m$ viene campionato direttamente da una distribuzione residua corretta che tiene conto delle probabilità di entrambi i modelli. Se tutti i $K$ token proposti vengono accettati, il modello obiettivo dispone già della distribuzione di probabilità per la posizione $K + 1$ grazie allo stesso passaggio parallelo e può quindi campionare gratuitamente un ulteriore token bonus.

Poiché le regole di rifiuto e ricampionamento annullano matematicamente gli errori del modello di bozza, lo speculative decoding è senza perdita. Ogni passaggio che tratta più token produce campioni estratti esattamente dalla stessa distribuzione di probabilità che si avrebbe eseguendo il solo modello obiettivo: non si verifica quindi alcun peggioramento della precisione nei benchmark, della capacità di ragionamento o del tono.

Quanto è più veloce lo speculative decoding nella pratica?

Le ricerche fondamentali mostrano che lo speculative decoding offre accelerazioni del tempo effettivo di circa 2X fino a 3X sui modelli linguistici di grandi dimensioni, se abbinato a un modello di bozza adatto e a sufficiente capacità di calcolo parallelo.

Gli articoli fondamentali che hanno introdotto la tecnica tra la fine del 2022 e l’inizio del 2023 hanno dimostrato notevoli miglioramenti della latenza sia nei transformer encoder-decoder sia in quelli con solo decoder, senza modificare i pesi dei modelli o le distribuzioni dell’output:

Studio	Modello obiettivo	Configurazione della bozza	Accelerazione del tempo effettivo riportata	Condizioni e attività
Leviathan et al. (2023)	T5-XXL (11B parametri)	T5-small (77M parametri)	2X–3X (fino a 2.6X–3.4X nelle tabelle di configurazione T5-small)	Implementazione T5X usata senza modifiche per traduzione (EN-DE) e riepilogo (CNN/DM), con argmax (temp 0) e campionamento standard (temp 1).
Chen et al. (2023)	Chinchilla (70B parametri)	Modello di bozza da 4B parametri addestrato per speculative sampling	2X–2.5X	Configurazione distribuita su TPU v4 per riepilogo (XSum) e generazione di codice (HumanEval).

Si noti la differenza di dimensioni tra i modelli obiettivo e di bozza in entrambi gli studi: T5-small è circa due ordini di grandezza più piccolo di T5-XXL e il modello di bozza da 4B rappresenta una piccola frazione del modello Chinchilla da 70B. Un modello di bozza deve essere abbastanza piccolo perché l’esecuzione di $K$ passaggi sequenziali su di esso aggiunga pochissimo sovraccarico rispetto a un singolo passaggio del modello obiettivo.

Cosa determina il tasso di accettazione e perché l’accelerazione non è garantita?

L’accelerazione dello speculative decoding dipende da due fattori principali: quanto le previsioni del modello di bozza concordano con quelle del modello obiettivo, cioè il tasso di accettazione, e quanta capacità di calcolo parallelo libera è disponibile nell’hardware. Un’accelerazione netta non è quindi mai garantita.

Se il modello di bozza sbaglia continuamente le previsioni, il sistema sostiene il costo di latenza dell’esecuzione di $K$ passaggi sequenziali sul modello di bozza per poi vedere il modello obiettivo rifiutare il primissimo token. Nel caso peggiore, un ciclo speculativo produce un solo token ricampionato impiegando più tempo di un passaggio standard del modello obiettivo.

Diverse variabili pratiche determinano se lo speculative decoding accelera o rallenta l’inferenza:

• Allineamento tra modello di bozza e modello obiettivo: Il modello di bozza deve condividere esattamente lo stesso tokenizer e lo stesso vocabolario del modello obiettivo e la sua distribuzione di addestramento dovrebbe corrispondere strettamente. Il completamento del codice, l’output JSON strutturato e la traduzione di espressioni prevedibili tendono a produrre tassi di accettazione più elevati della scrittura creativa ad alta temperatura, in cui molti token molto diversi sono ugualmente plausibili.
• Sovraccarico di latenza del modello di bozza: Anche un tasso di accettazione elevato non accelera la generazione se il modello di bozza stesso è troppo grande e lento. Leviathan et al. hanno dimostrato che un modello di bozza T5-small più piccolo superava i candidati più grandi T5-base e T5-large nell’accelerazione complessiva del tempo effettivo, perché il sovraccarico di proposta per ogni passaggio era molto inferiore.
• Lunghezza della finestra di anticipazione ($K$): Un’anticipazione troppo breve limita il numero di token verificabili in un solo passaggio. Un’anticipazione troppo lunga spreca tempo per proporre token successivi che vengono scartati quando un token precedente è rifiutato.
• Capacità di calcolo parallelo disponibile (saturazione della dimensione del batch): Lo speculative decoding usa capacità di calcolo inutilizzata per ridurre la latenza. Nei servizi sensibili alla latenza con batch ridotti, gli acceleratori dispongono di ampia capacità libera per verificare $K$ token in parallelo con un costo temporale aggiuntivo quasi nullo. Con batch concorrenti molto grandi, quando le unità di calcolo della GPU sono già completamente sature, aggiungere $K$ posizioni di verifica per richiesta aumenta il tempo del passaggio e può annullare l’accelerazione.

Qual è il rapporto tra speculative decoding, KV cache e caching dei prompt?

Lo speculative decoding accelera soltanto la fase di decodifica della generazione dell’output, mentre l’uso della KV cache evita di ricalcolare l’attenzione tra i token e il caching dei prompt accelera il prefill degli input ripetuti e ne riduce il costo.

Poiché tutte e tre queste ottimizzazioni riguardano la latenza di inferenza dei transformer, gli sviluppatori spesso confondono il ruolo di ciascuna nel ciclo di vita della richiesta:

• Prefill e decodifica: Ogni richiesta a un LLM si divide in due fasi. Il prefill elabora tutti i token del prompt di input in parallelo per costruire lo stato iniziale; è già limitato dalla capacità di calcolo ed è veloce per token. La decodifica genera i token di output passo dopo passo ed è limitata dalla larghezza di banda della memoria. Lo speculative decoding aiuta solo nella fase di decodifica e non accelera la lettura di un prompt di input lungo.
• Ruolo della KV cache: Sia il modello obiettivo sia quello di bozza utilizzano la propria KV cache durante lo speculative decoding. Man mano che i token candidati vengono proposti e verificati, i loro stati Key e Value vengono aggiunti alla cache. Quando il modello obiettivo rifiuta token proposti dopo la posizione $m$, il motore di inferenza ripristina semplicemente le KV cache di entrambi i modelli troncandole, così da scartare le voci rifiutate prima di avviare il ciclo successivo.
• Differenza rispetto al caching dei prompt: Il caching dei prompt riutilizza blocchi di KV cache precalcolati per prefissi di prompt identici tra chiamate API separate, riducendo il tempo al primo token (TTFT) e spesso anche i prezzi dei token di input. Lo speculative decoding riduce la latenza tra token (ITL) durante lo streaming della risposta.

Cosa significa lo speculative decoding per gli sviluppatori API e chi ospita i modelli in proprio?

Per gli sviluppatori API, lo speculative decoding si manifesta come una minore latenza di streaming end-to-end anziché come una voce di fatturazione separata. Chi ospita i modelli in proprio lo configura direttamente nei motori di inferenza per migliorare la reattività di ogni richiesta.

Il modo in cui si utilizza lo speculative decoding dipende dal fatto che si chiamino endpoint di modelli ospitati o si gestisca un proprio parco di GPU:

1. La fatturazione per token delle API ospitate cambia raramente: I fornitori di IA ospitata generalmente fatturano per milione di token di input e output elaborati dal punto di vista dell’utente. Anche se un fornitore usa lo speculative decoding internamente, i token di bozza rifiutati rimangono interni al motore di servizio: vengono addebitati i token di output finali generati alla tariffa standard del modello. Per ridurre la fattura API diretta oltre al tempo di attesa, considera il prompt engineering, le API batch e i modi pratici per ridurre i costi delle API di IA, oppure confronta le tariffe quando decidi come scegliere un modello di IA.
2. Vantaggi per l’esperienza utente in tempo reale: Per chi sviluppa applicazioni, lo speculative decoding eccelle nell’esperienza utente. Agenti vocali, assistenti di codice negli IDE e flussi di produzione interattivi, dai copiloti di programmazione dal vivo alle pipeline di script abbinate a strumenti creativi come AI Studio Video, risultano sensibilmente più reattivi quando i token di output arrivano al doppio della velocità senza passare a un modello meno capace.
3. Configurazione dell’hosting autonomo: Se esegui modelli con pesi aperti sulla tua infrastruttura, configuri lo speculative decoding direttamente nello stack di servizio. Devi caricare sia il modello obiettivo sia quello di bozza nella memoria della GPU, oppure usare una variante senza modello di bozza, assicurarti che condividano esattamente lo stesso tokenizer e regolare la lunghezza dell’anticipazione in base al tuo livello abituale di richieste concorrenti.

Serve sempre un modello di bozza separato?

Le varianti successive dello speculative decoding eliminano la necessità di addestrare e distribuire un piccolo modello di bozza separato, mantenendo lo stesso principio di proposta e verifica.

Gestire due modelli separati in memoria e trovare un piccolo modello con esattamente lo stesso tokenizer e un comportamento allineato a quello del modello obiettivo può essere complicato dal punto di vista operativo. Per risolvere il problema, i ricercatori sull’inferenza e i framework di servizio hanno introdotto diversi approcci senza modello di bozza:

• Proposta tramite n-grammi e ricerca nel prompt: Invece di eseguire una rete neurale per proporre token, il motore cerca segmenti di testo corrispondenti nel prompt di input e nell’output generato di recente e copia i token successivi come candidati. Funziona particolarmente bene per riassumere documenti, modificare codice o estrarre citazioni già presenti nella finestra di contesto.
• Teste di previsione multi-token e livelli ausiliari: Invece di mantenere un intero modello autonomo, un piccolo insieme di teste di previsione leggere o livelli di bozza può essere collegato direttamente agli stati nascosti del modello obiettivo per proporre i token successivi in un solo passaggio.
• Self-speculative decoding: Alcune configurazioni usano un sottoinsieme dei livelli del modello obiettivo stesso, saltando i livelli intermedi durante la proposta, per generare token candidati; eseguono poi tutti i livelli per verificarli.

Indipendentemente da come vengono proposti i token candidati, la garanzia fondamentale rimane la stessa: il modello obiettivo completo verifica i candidati in parallelo e applica la propria distribuzione di probabilità esatta a ogni token accettato.

Domande frequenti

Lo speculative decoding modifica la precisione del modello o la qualità dell’output?

No. Lo speculative decoding standard (speculative sampling) è matematicamente senza perdita. Nella decodifica greedy accetta soltanto i token che corrispondono esattamente alla prima previsione del modello obiettivo. Nel campionamento con temperatura, le regole di rifiuto e ricampionamento residuo assicurano che le sequenze generate seguano esattamente la stessa distribuzione di probabilità della decodifica autoregressiva standard del modello obiettivo.

Lo speculative decoding riduce il tempo al primo token (TTFT)?

No. Il tempo al primo token misura quanto impiega il modello a leggere il prompt di input durante la fase di prefill e a emettere il primissimo token di output. Poiché il prefill elabora già i token del prompt in parallelo, lo speculative decoding accelera solo i successivi passaggi di decodifica, riducendo la latenza tra token e il tempo totale di completamento del resto della risposta.

Perché lo speculative decoding può essere più lento con batch di grandi dimensioni?

Lo speculative decoding si basa sulla capacità di calcolo parallelo libera della GPU o della TPU per controllare più token di bozza all’incirca nello stesso tempo necessario per controllarne uno. Quando un server gestisce un batch molto grande di richieste concorrenti, la capacità di calcolo dell’acceleratore è già completamente utilizzata; verificare token di bozza aggiuntivi per ogni richiesta aggiunge quindi tempo di esecuzione effettivo e può superare il risparmio sulle letture dalla memoria.

Qualsiasi modello piccolo può fungere da modello di bozza per qualsiasi modello grande?

Non direttamente nello speculative decoding standard a livello di token. Il modello di bozza e il modello obiettivo devono condividere un vocabolario e un tokenizer compatibili affinché gli ID dei token candidati e le relative distribuzioni di probabilità corrispondano correttamente tra i due modelli. Per questo gli abbinamenti provengono solitamente dalla stessa famiglia di modelli, come T5-small che propone token per T5-XXL.

Fonti

• Yaniv Leviathan, Matan Kalman, and Yossi Matias — Fast Inference from Transformers via Speculative Decoding (arXiv:2211.17192, ICML 2023)
• Charlie Chen, Sebastian Borgeaud, Geoffrey Irving, Jean-Baptiste Lespiau, Laurent Sifre, and John Jumper — Accelerating Large Language Model Decoding with Speculative Sampling (arXiv:2302.01318, 2023)