Speculative Decoding: inferenza degli LLM dal 20% al 50% più veloce

Un modello da 70B genera un token per passaggio avanti e ogni passaggio ricarica i pesi dalla VRAM, calcola l’attenzione su tutto il contesto e sincronizza la memoria. Tra un token e l’altro, la GPU resta inattiva in attesa che si risolvano le dipendenze sequenziali.

Su un H100, un modello da 70B produce un token ogni 30-50ms. La GPU ha capacità di calcolo sufficiente per elaborare più token in parallelo, ma la dipendenza sequenziale glielo impedisce: ogni token dipende da quello precedente e la pipeline si blocca.

Il decodaggio speculativo rompe questo collo di bottiglia consentendo di generare più token nel tempo normalmente necessario per generarne uno, senza modificare la distribuzione dell’output. I token ottenuti sono statisticamente identici a quelli che si otterrebbero con il decodaggio autoregressivo standard; l’unica differenza è la velocità con cui vengono prodotti.

Questa guida copre i meccanismi, le varianti disponibili nel 2026, i compromessi legati al tasso di accettazione e la configurazione pratica su llama.cpp, vLLM, SGLang e TensorRT-LLM.

Come funziona il decodaggio autoregressivo (e perché è lento)

Prima di poter comprendere il decodaggio speculativo, è necessario capire il vincolo autoregressivo che aggira. La generazione autoregressiva standard elabora i token in sequenza:

1. Esegue un passaggio avanti attraverso il modello con il contesto attuale.
2. Campiona il token successivo dalla distribuzione di output.
3. Aggiunge il token al contesto.
4. Ripete.

Ogni passaggio richiede un ciclo completo di calcolo — caricare i pesi dalla VRAM, calcolare l’attenzione su tutto il contesto e produrre un singolo token. Per un modello con 70 miliardi di parametri, questo richiede circa 30-50ms per token su un H100. La GPU ha capacità di calcolo in eccesso — potrebbe elaborare più lavoro in parallelo — ma la dipendenza sequenziale glielo impedisce.

Il divario tra calcolo e VRAM

Le GPU moderne hanno più FLOP di quelli necessari per la generazione di un singolo token, quindi il vero collo di bottiglia è la banda della memoria: i pesi devono essere trasmessi dalla VRAM alle unità di calcolo per ogni passaggio avanti. Quando si genera un token alla volta, la GPU passa la maggior parte del tempo ad aspettare i trasferimenti di memoria anziché eseguire calcoli utili.

Il decodaggio speculativo risolve questo problema fornendo alla GPU più lavoro per ogni trasferimento di memoria. Invece di un token per passaggio avanti, genera K token per passaggio, distribuendo il costo della memoria su più output.

Il meccanismo Draft-Verify

Il decodaggio speculativo funziona in cicli ripetuti di bozza e verifica. Un meccanismo di bozza rapido propone K token candidati — da un modello di bozza piccolo, da una ricerca n-gram o da un’ testa di previsione collegata al modello target — e il modello target verifica tutti i K in un singolo passaggio avanti. La fase di bozza è poco costosa, tipicamente il 5-20% del tempo del passaggio avanti del modello target, mentre la verifica confronta ogni token di bozza con ciò che il target avrebbe generato, accettando il prefisso corrispondente più lungo e ricampionando a partire dal primo rifiuto.

Verificare K token costa approssimativamente lo stesso di generarne uno autoregressivamente, quindi quando la bozza è corretta si ottengono K token al costo di un singolo passo di verifica.

Un esempio concreto

Supponiamo che il modello di bozza proponga 5 token: ["I", " like", " cooking", " and", " traveling"]. Il modello target li verifica in un singolo passaggio avanti:

Il target accetta i token 1 e 2, poi genera " playing" per il token 3, producendo tre token in un solo ciclo invece di tre passaggi avanti separati. Se la bozza fosse stata corretta fino al token 5, si otterrebbero cinque token al costo di una sola verifica — un acceleramento di 5 volte solo per quel ciclo.

Il collo di bottiglia della verifica

In pratica, la verifica domina il tempo di esecuzione — dal 42% al 95% del ciclo, a seconda del metodo e della dimensione del modello. Il passaggio avanti del modello target è il collo di bottiglia e i token rifiutati rappresentano calcoli sprecati.

Ecco perché il tasso di accettazione è così importante. Ogni token rifiutato dopo il primo è lavoro di verifica sprecato. I migliori metodi di decodaggio speculativo massimizzano i token accettati attesi per ciclo, non solo il tasso di accettazione grezzo.

La garanzia matematica

Una delle proprietà più importanti del decodaggio speculativo è che produce token dalla stessa esatta distribuzione del campionamento autoregressivo standard dal modello target. Il passo di verifica utilizza il campionamento con rifiuto: quando la bozza propone il token x, il modello target calcola la sua probabilità p(x) e la bozza calcola p_draft(x). La probabilità di accettazione è:

min(1, p(x) / p_draft(x))

Quando il target concorda (p(x) ≥ p_draft(x)), il token è sempre accettato. Quando il target non concorda, il token è accettato con una probabilità proporzionale al rapporto, e i token rifiutati vengono ricampionati da una distribuzione residua:

r(x) = max(0, p(x) - p_draft(x)) / Σ max(0, p(y) - p_draft(y))

Questa procedura garantisce che la sequenza di output segua esattamente la distribuzione del modello target, ecco perché il decodaggio speculativo è senza perdite. Il modello di bozza influenza la velocità, non la qualità: i token ottenuti sono statisticamente indistinguibili dal decodaggio standard, con la stessa perlessità e distribuzione. L’unica differenza è la latenza.

Strategie per i modelli di bozza

Il meccanismo di bozza è la variabile più importante. Diverse approcci hanno compromessi diversi tra complessità di configurazione, tasso di accettazione e acceleramento.

Modelli di bozza autonomi

L’approccio più semplice carica un modello più piccolo accanto a quello target — tipicamente un modello da 1B-3B che crea bozze per un target da 7B-70B.

Pro:

• Concettualmente semplice
• Funziona con qualsiasi modello target
• Il modello di bozza può essere sintonizzato per corrispondere alla distribuzione del target

Contro:

• Richiede il caricamento di un secondo modello nella VRAM (1-4 GB a seconda della dimensione)
• La qualità del modello di bozza determina direttamente il tasso di accettazione
• Le bozze tra famiglie diverse (es., Qwen che crea bozze per Llama) hanno tipicamente prestazioni scadenti

Regola pratica: Usa modelli della stessa famiglia. Gemma 2 2B crea buone bozze per Gemma 2 27B. Llama 3.2 1B crea buone bozze per Llama 3.1 70B. Le bozze tra famiglie diverse tendono ad avere tassi di accettazione bassi perché le distribuzioni dei token divergono.

Trovare modelli di bozza compatibili

Non tutti i modelli piccoli funzionano come modelli di bozza per un dato target. Il fattore critico è l’allineamento della distribuzione — quanto da vicino le probabilità di output del modello di bozza corrispondono a quelle del target.

La regola d’oro: se il tasso di accettazione del modello di bozza scende sotto il 50%, il decodaggio speculativo potrebbe in realtà rallentarti. I sovraccarichi di esecuzione del modello di bozza più la verifica superano il beneficio quando la maggior parte delle proposte viene rifiutata.

EAGLE e EAGLE-3: Teste di previsione

EAGLE (Efficient Architecture Guided Language Model Estimation) elimina la necessità di un modello di bozza separato. Invece, collega teste di previsione autoregressive leggere agli strati interni del modello target.

Come funziona EAGLE

EAGLE addestra teste di previsione che prendono gli stati nascosti dagli strati intermedi del modello target e prevedono token futuri. Durante l’inferenza:

1. Il modello target esegue un passaggio avanti attraverso i suoi strati.
2. A ogni strato, la testa EAGLE legge lo stato nascosto e propone token per posizioni future.
3. Più teste operano in parallelo, ciascuna prevedendo un diverso istante futuro.
4. Il modello target verifica tutte le proposte in un singolo passaggio.

Il vantaggio: le teste EAGLE sono addestrate specificamente per corrispondere alla distribuzione del modello target. Vengono a contatto con le rappresentazioni interne del target direttamente, il che le offre un allineamento molto migliore rispetto a un modello di bozza autonomo.

Miglioramenti di EAGLE-3

EAGLE-3 (2025) affina l’approccio con tre modifiche chiave:

1. Selezione degli strati: Invece di collegare teste a ogni strato, EAGLE-3 utilizza l’ottimizzazione bayesiana per selezionare lo strato di uscita ottimale, riducendo i sovraccarichi.
2. Previsione multi-token: Ogni testa prevede più token simultaneamente, aumentando la profondità della bozza senza un costo computazionale proporzionale.
3. Efficienza nell’addestramento: EAGLE-3 si addestra sui dati di generazione del modello target stesso, migliorando i tassi di accettazione sui carichi di lavoro in-distribuzione.

Tassi di accettazione: EAGLE-3 raggiunge tipicamente tassi di accettazione dal 60% all'80% su carichi di lavoro in-distribuzione, rispetto al 40-60% per i modelli di bozza autonomi. Su carichi di lavoro di generazione di codice con alta ripetizione, l’accettazione può superare l'85%.

Configurazione: EAGLE-3 richiede teste pre-addestrate per il tuo modello target. NVIDIA fornisce teste EAGLE-3 per diversi modelli popolari tramite TensorRT-LLM e la raccolta Speculative Decoding Modules su HuggingFace. Esistono implementazioni di terze parti per vLLM e SGLang.

P-EAGLE: Bozze in parallelo (Marzo 2026)

Il principale limite di EAGLE-3 è la bozza autoregressiva — ogni token di bozza dipende da quello precedente, quindi generare K token di bozza richiede K passaggi avanti sequenziali attraverso la testa di bozza, e i sovraccarichi di bozza crescono linearmente con K. P-EAGLE rimuove questo limite generando tutti i K token di bozza in un singolo passaggio avanti attraverso un bozzatore leggero a 4 strati addestrato a prevedere fino a 10 token in parallelo.

Il risultato: P-EAGLE offre un acceleramento fino a 1,69 volte rispetto a EAGLE-3 puro su carichi di lavoro reali su NVIDIA B200. Il vantaggio si allarga a valori di K più alti — dove la bozza sequenziale di EAGLE-3 diventa un collo di bottiglia, la bozza parallela di P-EAGLE non incorre in costi aggiuntivi.

Configurazione in vLLM: Scarica una testa P-EAGLE pre-addestrata da HuggingFace, imposta "parallel_drafting": true nella tua configurazione vLLM e usa lo stesso flag --speculative-model — vLLM si occupa del resto. P-EAGLE è lo stato dell’arte attuale per il decodaggio speculativo basato su EAGLE, e se stai distribuendo EAGLE nel 2026, P-EAGLE è la variante da usare.

Decodaggio Speculativo N-gram

Il decodaggio speculativo n-gram sostituisce una bozza neurale con l’abbinamento di pattern contro la storia del prompt. L’algoritmo cerca sequenze di n-gram ripetute nel contesto e, quando la sequenza di token corrente corrisponde a un pattern visto in precedenza, propone i token che avevano seguito quel pattern in passato — ad esempio, se il modello ha già generato def calculate_total(items): e incontra nuovamente def calculate_total(, sa che i token successivi saranno probabilmente items): in base all’occorrenza precedente.

Le varianti mappa n-gram (ngram-map-k, ngram-map-k4v) usano tabelle hash per ricerche più veloci invece di scansioni lineari, con la chiave hash come n-gram attuale di dimensione N e il valore come la sequenza di token che ha seguito.

Pro:

• Zero sovraccarichi di VRAM — nessun modello aggiuntivo da caricare (~16 MB per la tabella hash)
• Estremamente veloce per carichi di lavoro ripetitivi (modifica di codice, refactoring, generazione di template)
• I tassi di accettazione possono raggiungere oltre il 90% su carichi di lavoro con alta auto-somiglianza

Contro:

• Inutile per la generazione nuova — se il pattern non è mai apparso prima, n-gram non ha nulla da proporre
• Il tasso di accettazione scende a quasi zero su carichi di lavoro creativi o diversificati
• Profondità di bozza limitata (tipicamente 2-4 token per corrispondenza)

Migliore per: Refactoring del codice, compilazione di template, documentazione ripetitiva e qualsiasi carico di lavoro in cui il modello ri-visita pattern simili. Peggior per: scrittura creativa, chat aperte e task di ragionamento.

Sintonizzazione dei parametri

I parametri n-gram contano più di quanto si possa pensare. I valori predefiniti funzionano per il codice, ma i carichi di lavoro testuali necessitano di aggiustamenti:

Per i carichi di lavoro testuali, ridurre size-n a 8-10 e aumentare min-hits a 2. Questo scambia la frequenza delle corrispondenze per tassi di accettazione più alti per corrispondenza.

Decodaggio Speculativo Auto-Riferito

Il decodaggio speculativo auto-riferito (chiamato anche LayerSkip o auto-speculazione) usa il calcolo parziale del modello stesso come bozza, quindi non è necessario un modello separato.

Come funziona

Invece di eseguire il modello completo per ogni token, il decodaggio speculativo auto-riferito esegue una versione troncata — saltando alcuni strati transformer — per generare token di bozza a basso costo, e poi il modello completo verifica le proposte.

Per esempio, un modello a 32 strati potrebbe eseguire con solo 16 strati per la bozza, poi verificare con tutti e 32 gli strati. Il passaggio avanti troncato è più veloce perché elabora meno strati, e i token di bozza beneficiano di vedere gli stessi strati iniziali del target.

Pro:

• Nessun peso di modello aggiuntivo da caricare
• Naturalmente allineato con la distribuzione del target (stessa architettura, strati parziali)
• Funziona bene per modelli con ridondanza significativa negli strati più profondi

Contro:

• Richiede modifiche al motore di inferenza per supportare passaggi avanti parziali
• Complicazioni nella cache KV — la bozza usa una cache KV parziale che deve essere riconciliata con la cache del modello completo
• I tassi di accettazione sono tipicamente più bassi rispetto a EAGLE o modelli di bozza ben sintonizzati

Implementazione in llama.cpp: La PR #18471 ha introdotto il decodaggio speculativo auto-riferito usando la storia del contesto come bozza. Il modello riutilizza token dalla sua stessa storia di generazione per proporre continuazioni, particolarmente efficace per carichi di lavoro di coding dove i pattern si ripetono entro la stessa finestra di contesto.

MTP (Multi-Token Prediction)

MTP è una forma specializzata di decodaggio speculativo integrata direttamente in determinati checkpoint di modelli. Qwen 3.6 offre sia varianti GGUF standard che con MTP abilitato.

Come si differenzia: Le teste MTP sono incorporate nell’architettura del modello durante l’addestramento. Il modello porta teste di previsione extra che propongono più token futuri in un singolo passaggio avanti. Non c’è un modello di bozza separato — le teste MTP sono parte del modello target stesso.

Compromessi:

• Nessun modello di bozza da gestire — MTP viene attivato con --spec-type draft-mtp --spec-draft-n-max N
• Le teste MTP aggiungono ~1-2 GB di sovraccarichi di VRAM
• Funziona meglio sulle architetture MoE (Qwen 3.6 35B-A3B) dove il routing sparsa mantiene le teste MTP economiche

Per benchmark dettagliati su MTP vs decodaggio standard su Qwen 3.6 27B e 35B, vedere Qwen 3.6 MTP vs Standard su GPU 16GB.

Tassi di Accettazione: Cosa Significano in Pratica

Il tasso di accettazione (α) è la singola metrica più importante per le prestazioni del decodaggio speculativo. Determina se si ottiene un acceleramento o si pagano sovraccarichi.

La formula dell’acceleramento

Token accettati attesi per passaggio di verifica:

E[accepted] = α × K

Dove K è il numero di token di bozza proposti per ciclo. Se α = 0,7 e K = 5, si accettano 3,5 token per passaggio — un acceleramento di 3,5 volte rispetto al decodaggio standard (che produce 1 token per passaggio).

Tasso di Accettazione per Metodo

Quando il tasso di accettazione scende

Il tasso di accettazione non è costante durante una generazione. Varia in base a:

• Posizione del token: I token iniziali tendono ad avere un’accettazione più alta (più contesto, meno incertezza). I token successivi scendono mentre il modello esplora continuazioni più diversificate.
• Tipo di carico di lavoro: La modifica del codice con pattern ripetuti vede α > 80%. La scrittura creativa aperta vede α < 40%.
• Temperatura: Temperature più alte aumentano la divergenza tra bozza e target, riducendo l’accettazione. Il decodaggio speculativo funziona meglio a temperature basse (0,0-0,7).

Soglia critica: Se il tuo tasso di accettazione effettivo (α × K) scende sotto 1,0, il decodaggio speculativo è più lento del decodaggio standard. I sovraccarichi di bozza più il tempo di verifica superano il costo di un singolo passo autoregressivo.

Decodaggio Speculativo in Produzione: Cosa Succede Really

I paper di ricerca riportano acceleramenti di 2-4 volte, ma i benchmark di produzione raccontano una storia più sfumata — gli acceleramenti si riducono con la dimensione del batch, la verifica domina il tempo del ciclo e nessun singolo metodo vince su ogni carico di lavoro.

Risultati di SpecDecode-Bench (2026)

Una valutazione sistematica di cinque varianti SD (n-gram, EAGLE, EAGLE-3, Draft-Model, MTP) su vLLM su quattro modelli e sei carichi di lavoro ha rivelato:

1. SD funziona, ma gli acceleramenti si riducono con la dimensione del batch. Con batch size 1, EAGLE raggiunge fino a 1,96x su Llama-3-70B. Con batch size 128, questo scende a 1,21x. Il sistema diventa vincolato dal calcolo ad alta concorrenza, e la GPU ha meno capacità inattiva da dedicare alla speculazione.

2. La verifica domina il tempo di esecuzione (42-95%). Il passaggio avanti del modello target è il collo di bottiglia. Ridurre la verifica sprecata sui token rifiutati è la via più promettente per il miglioramento.

3. Nessun singolo metodo vince ovunque. EAGLE-3 è la scelta migliore generale. I metodi draft-model eccellono quando il modello target è grande (70B+). N-gram è ottimale per la modifica del codice e task ad alto sovrapposizione.

4. L’analisi Oracle rivela un divario. Il limite superiore teorico per strategie combinate n-gram + EAGLE raggiunge ~4,9x su carichi di lavoro di modifica del codice, ma le implementazioni attuali raggiungono 2-3x. C’è spazio per l’ottimizzazione.

Aspettative Pratiche di Acceleramento

L’effetto della dimensione del batch è critico. A batch piccoli, la GPU ha calcolo inattivo da dedicare alla speculazione. A batch grandi, il sistema è già saturo e il decodaggio speculativo aggiunge sovraccarichi senza beneficio proporzionale.

Monitoraggio in Produzione

Bisogna tracciare il tasso di accensione in produzione. Un tasso di accettazione in calo segnala che il tuo modello di bozza sta divergendo dal target — sia perché il carico di lavoro è cambiato, sia perché il modello di bozza necessita di ri-addestramento.

Metriche chiave da monitorare:

• Tasso di accettazione per richiesta (dovrebbe essere stabile intorno alla tua baseline)
• Token al secondo con vs senza decodaggio speculativo (l’acceleramento effettivo)
• Tempo di verifica come percentuale del tempo del ciclo (dovrebbe essere 42-95%)
• Tempo del passaggio avanti del modello di bozza (dovrebbe essere < 20% del tempo del modello target)

Se il tuo tasso di accettazione scende sotto il 40%, disabilita il decodaggio speculativo per quella richiesta. I sovraccarichi non ne valgono la pena.

Configurazione Pratica

La scelta del motore conta quanto la strategia di bozza — vedere Ollama vs vLLM vs LM Studio e altri runtime locali per capire come ogni runtime gestisce batching, compatibilità API e throughput prima di scegliere un percorso di decodaggio speculativo.

llama.cpp

Per la configurazione generale del server e il caricamento GGUF, iniziare con la Guida rapida llama.cpp; i flag qui sotto aggiungono il decodaggio speculativo.

llama.cpp supporta diversi metodi di decodaggio speculativo tramite il flag --spec-type:

# Modello di bozza (autonomo)
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Obbligatorio: --parallel 1 per il decodaggio speculativo

# n-gram
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-gram (sintonizzazione per carichi di lavoro testuali)
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 8 \
  --spec-ngram-simple-size-m 32 \
  --spec-ngram-simple-min-hits 2

# MTP (Qwen 3.6)
llama-server \
  --model Qwen3.6-27B-MTP.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

# Auto-speculativo (carichi di lavoro di coding)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

Flag critici:

• --parallel 1 — Il decodaggio speculativo in llama.cpp richiede la modalità single-batch. Questa è una limitazione attuale.
• --spec-draft-n-max — Numero di token di bozza per ciclo. Iniziare con 3-5; valori più alti aumentano la pressione sulla VRAM.
• --spec-ngram-simple-size-n — Lunghezza n-gram per la ricerca. Il predefinito 12 funziona bene per il codice; ridurre a 8 per il testo.

Errori comuni:

• Dimenticare --parallel 1 — il server ignorerà silenziosamente il decodaggio speculativo.
• Usare modelli di bozza tra famiglie diverse — i tassi di accettazione crollano, annullando qualsiasi acceleramento.
• Impostare --spec-draft-n-max troppo alto — ogni token di bozza aggiuntivo costa VRAM per il buffer di bozza. Rendimenti decrescenti arrivano intorno a 5-8.

vLLM

La Guida rapida vLLM copre il deployment di base; i flag qui sotto abilitano il decodaggio speculativo su un server vLLM esistente.

vLLM supporta il decodaggio speculativo tramite i flag --speculative-model e --speculative-num-steps:

# Modello di bozza
vllm serve target-model \
  --speculative-model draft-model \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

# EAGLE-3
vllm serve target-model \
  --speculative-model EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-draft-tensor-parallel-size 1

# P-EAGLE (bozze in parallelo)
vllm serve target-model \
  --speculative-model P-EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-parallel-drafting true

# n-gram
vllm serve target-model \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

Il decodaggio speculativo di vLLM è integrato con il continuous batching, quindi funziona sotto carichi di lavoro concorrenti. Lo scheduler gestisce più slot di token in un singolo passaggio avanti, e il gestore della memoria gestisce la cache KV per entrambi i modelli di bozza e target.

SGLang

SGLang supporta il decodaggio speculativo tramite il suo flag --speculative-algorithm:

python -m sglang.launch_server \
  --model-path target-model \
  --speculative-algorithm ngram \
  --ngram-context-size 12 \
  --ngram-max-candidate-tokens 6

L’architettura RadixAttention di SGLang si abbina bene al decodaggio speculativo perché la caching del prefisso riduce il costo della verifica — il modello target riutilizza l’attenzione in cache per i prefissi condivisi, rendendo ogni passaggio di verifica più economico di un passaggio avanti a freddo.

TensorRT-LLM

TensorRT-LLM fornisce un decodaggio speculativo di grado di produzione con Triton Inference Server. La configurazione è più complessa ma offre le migliori prestazioni sull’hardware NVIDIA:

1. Compila il motore TensorRT per entrambi i modelli target e bozza.
2. Configura il repository dei modelli con model.yaml specificando la configurazione del decodaggio speculativo.
3. Avvia Triton con l’API LLM / backend PyTorch.

TensorRT-LLM supporta sia le varianti draft-model che EAGLE-3. Per carichi di lavoro di generazione di codice, TensorRT-LLM con decodaggio speculativo n-gram ha dimostrato una riduzione della latenza del 2-3x in deployment di produzione.

Quando Usare il Decodaggio Speculativo

Usalo Quando

• Modelli target grandi (7B+): I sovraccarichi del meccanismo di bozza sono distribuiti sul calcolo del target. Il decodaggio speculativo brilla quando il modello target è lento — più grande è il target, più prezioso è l’acceleramento.
• Carichi di lavoro a bassa temperatura: Il decodaggio speculativo funziona meglio a temperatura 0,0-0,7, dove la distribuzione del modello target è concentrata e la bozza ha una migliore possibilità di corrispondenza.
• Applicazioni interattive: I carichi di lavoro sensibili alla latenza (chat, completamento del codice, chiamate di tool degli agenti) ne beneficiano di più. L’elaborazione in batch dove la GPU è già satura vede meno benefici.
• Generazione e modifica del codice: L’alta ripetizione nei pattern di codice rende il decodaggio speculativo n-gram e auto-riferito particolarmente efficace.

Evitalo Quando

• Modelli target piccoli (< 3B): I sovraccarichi del modello di bozza si avvicinano al tempo del passaggio avanti del target. L’acceleramento è marginale o negativo.
• Campionamento ad alta temperatura: A temperatura > 0,7, la distribuzione del modello target è troppo ampia perché la bozza possa corrispondere in modo affidabile.
• Scrittura creativa e generazione aperta: I tassi di accettazione bassi su contenuti nuovi rendono i sovraccarichi non compensativi.
• Dimensioni di batch alte (> 32): Il sistema diventa vincolato dal calcolo e il decodaggio speculativo aggiunge sovraccarichi senza beneficio proporzionale. SpecDecode-Bench mostra l’acceleramento che scende da 1,96x a 1,21x al variare della dimensione del batch da 1 a 128.

Combinazione dei Metodi

Le configurazioni avanzate combinano più strategie di decodaggio speculativo. L’analisi oracle di SpecDecode-Bench ha mostrato che combinare adattivamente n-gram ed EAGLE può spingere l’acceleramento a 4,9x su carichi di lavoro di modifica del codice.

L’idea è usare n-gram per i pattern che sono già apparsi, dove l’accettazione è alta e i sovraccarichi sono vicini a zero, e ripiegare su EAGLE per i token nuovi. In pratica questo richiede supporto del motore per la speculazione multi-metodo — vLLM e TensorRT-LLM hanno supporto sperimentale, ma le implementazioni di grado di produzione sono ancora in fase di maturazione.

Per ora, la combinazione più pratica è MTP + n-gram in llama.cpp. MTP gestisce la speculazione neurale, mentre n-gram cattura i pattern ripetitivi che MTP manca. Su Qwen 3 27B, questa combinazione raggiunge 120 token/sec rispetto a 67 token/sec standard — un acceleramento di 1,8x.

Considerazioni sui Costi

Il decodaggio speculativo scambia calcolo per latenza. Il calcolo totale per token è approssimativamente lo stesso — si sta solo facendo più lavoro in parallelo invece che in sequenza.

Impatto sul costo GPU:

• La latenza per richiesta singola migliora del 20-50%, il che conta per le applicazioni interattive.
• Lo throughput (token/sec su molte richieste) migliora meno — la GPU è già satura a dimensioni di batch alte.
• L’uso della VRAM aumenta per l’impronta del modello di bozza (1-4 GB per bozze autonome, minimo per n-gram/EAGLE).

Inferenza nel cloud: A $2-4/ora per H100, il decodaggio speculativo riduce la latenza per richiesta senza aumentare il costo per token. Per l’elaborazione in batch dove la GPU è già satura, il beneficio sui costi è minimo — si paga per lo stesso tempo di GPU comunque.

Quando il decodaggio speculativo risparmia denaro: Applicazioni interattive dove si addebita per richiesta e si vuole ridurre il time-to-first-token. Un acceleramento di 2x significa che gli utenti aspettano la metà del tempo e si possono servire più richieste al secondo sullo stesso hardware.

Quando non lo fa: Elaborazione in batch dove si sta già massimizzando l’utilizzo della GPU. Il calcolo extra dal decodaggio speculativo non aumenta lo throughput — cambia solo il profilo di latenza.

Cosa Succede Dopo

Il decodaggio speculativo sta maturando da novità di ricerca a standard di produzione. La frontiera sta spingendo oltre le limitazioni attuali:

• Generazione parallela a livello di modello: Il decodaggio speculativo spinge più token per passaggio avanti a livello di inferenza senza toccare la distribuzione dell’output. I modelli linguistici di diffusione fanno una scommessa strutturalmente diversa, generando più token per passaggio avanti come parte dell’architettura del modello stessa. Vedere cosa arriva dopo gli LLM per come si confronta con l’approccio draft-verify sopra, e con i modelli a spazio di stato e i modelli del mondo JEPA all’altro capo del paesaggio post-transformer.

• Decodaggio Speculativo Speculativo (SSD): Parallelizza le fasi di bozza e verifica su hardware separato. Il modello di bozza funziona in modo asincrono, pre-speculando per più possibili esiti di verifica. I risultati iniziali mostrano fino a 2x di acceleramento rispetto al decodaggio speculativo ottimizzato, e 5x rispetto al decodaggio autoregressivo. Non ancora pronto per la produzione, ma la direzione è chiara.

• SpecSA (Verifica Speculativa Sparse): Combina il decodaggio speculativo con l’attenzione sparse dinamica. Trasforma l’attenzione sparse in un carico di lavoro orientato alla verifica, raggiungendo fino a 3,49x di throughput end-to-end rispetto al decodaggio autoregressivo sparse. Rilevante per i modelli di contesto lungo dove l’attenzione sparse è già in uso.

• Speculazione adattiva: Commutazione automatica tra metodi n-gram, EAGLE e draft-model in base alle caratteristiche del carico di lavoro. L’analisi oracle mostra un potenziale significativo non sfruttato — le implementazioni attuali raggiungono 2-3x, ma il limite teorico è 4,9x.

• Decodaggio speculativo multimodale: Estendere il draft-verify a modelli vision-lingua e generazione video. Le prime indagini mostrano che gli stessi principi si applicano, ma le strategie di verifica necessitano di adattamento per modalità non testuali.

Quadro Decisionale