Decodifica Speculativa: Inferenza di LLM 20-50% più rapida

Un modello da 70B genera un token per ogni passaggio in avanti (forward pass), 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 rimane inattiva mentre attende la risoluzione delle 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 lo impedisce: ogni token dipende dal precedente, causando un arresto della pipeline.

La decodifica speculativa rompe questo collo di bottiglia consentendo di generare più token nel tempo che normalmente servirebbe per generarne uno, senza modificare la distribuzione di output. I token ottenuti sono statisticamente identici a quelli che si otterrebbero con la decodifica autoregressiva standard; l’unica differenza è la velocità di ottenimento.

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

Come funziona la decodifica autoregressiva (e perché è lenta)

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

1. Esegui un passaggio in avanti attraverso il modello con il contesto corrente.
2. Campiona il prossimo token dalla distribuzione di output.
3. Aggiungi il token al contesto.
4. Ripeti.

Ogni passaggio richiede un intero passaggio in avanti — caricamento dei pesi dalla VRAM, calcolo dell’attenzione su tutto il contesto e produzione di un singolo token. Per un modello con 70B 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 lo impedisce.

Il divario tra Calcolo e VRAM

Le GPU moderne hanno più FLOP di quanti ne necessitino per la generazione di un singolo token, quindi il vero collo di bottiglia è la larghezza di banda della memoria — i pesi devono essere trasferiti dalla VRAM alle unità di calcolo per ogni passaggio in avanti. Quando si genera un token alla volta, la GPU passa la maggior parte del tempo ad attendere i trasferimenti di memoria piuttosto che eseguire calcoli utili.

La decodifica speculativa affronta questo problema fornendo alla GPU più lavoro per ogni trasferimento di memoria. Invece di un token per passaggio in avanti, genera K token per passaggio, ammortizzando il costo della memoria su più output.

Il meccanismo di Bozza e Verifica (Draft-Verify)

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

Verificare K token costa pressappoco lo stesso di generare un token autoregressivamente, quindi quando la bozza è corretta si ottengono K token al prezzo di un passaggio 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 in avanti:

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

Il collo di bottiglia della verifica

Nella pratica, la verifica domina il tempo di esecuzione — dal 42 al 95% del ciclo, a seconda del metodo e delle dimensioni del modello. Il passaggio in avanti del modello target è il collo di bottiglia, e i token rifiutati rappresentano calcolo sprecato.

Questo è il motivo per cui il tasso di accettazione è così importante. Ogni token rifiutato dopo il primo è lavoro di verifica sprecato. I migliori metodi di decodifica speculativa massimizzano i token accettati attesi per ciclo, non solo il tasso di accettazione grezzo.

La garanzia matematica

Una delle proprietà più importanti della decodifica speculativa è che produce token dalla stessa distribuzione esatta del campionamento autoregressivo standard dal modello target. Il passaggio di verifica utilizza il campionamento per 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 è d’accordo (p(x) ≥ p_draft(x)), il token è sempre accettato. Quando il target non è d’accordo, il token è accettato con probabilità proporzionale al rapporto, e i token rifiutati sono 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, motivo per cui la decodifica speculativa è senza perdite. Il modello di bozza influisce sulla velocità, non sulla qualità — i token che si ottengono sono statisticamente indistinguibili dalla decodifica standard, con la stessa perplesso e distribuzione. L’unica differenza è la latenza.

Strategie per il modello di bozza

Il meccanismo di bozza è la variabile che conta di più. Diversi approcci hanno diversi compromessi tra complessità di configurazione, tasso di accettazione e aumento di velocità.

Modelli di bozza autonomi

L’approccio più semplice carica un modello più piccolo insieme al target — tipicamente un modello da 1B-3B che fa da bozza per un target da 7B-70B.

Pro:

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

Contro:

• Richiede il caricamento di un secondo modello nella VRAM (1-4 GB a seconda delle dimensioni)
• La qualità del modello di bozza determina direttamente il tasso di accettazione
• Le bozze tra famiglie diverse (es. Qwen che fa da bozza per Llama) tipicamente prestano male

Regola empirica: Usa modelli della stessa famiglia. Gemma 2 2B fa bene da bozza per Gemma 2 27B. Llama 3.2 1B fa bene da bozza per Llama 3.1 70B. Le bozze tra famiglie diverse tendono ad avere bassi tassi di accettazione 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 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%, la decodifica speculativa potrebbe effettivamente rallentarti. Il sovraccarico dell’esecuzione del modello di bozza più la verifica supera 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, attacca teste di previsione autoregressiva 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 i token futuri. Durante l’inferenza:

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

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

Miglioramenti di EAGLE-3

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

1. Selezione degli strati: Invece di attaccare teste a ogni strato, EAGLE-3 utilizza l’ottimizzazione bayesiana per selezionare lo strato di uscita ottimale, riducendo il sovraccarico.
2. Previsione multi-token: Ogni testa prevede più token simultaneamente, aumentando la profondità della bozza senza un costo computazionale proporzionale.
3. Efficienza dell’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 tipicamente raggiunge tassi di accettazione del 60-80% sui carichi di lavoro in distribuzione, rispetto al 40-60% per i modelli di bozza autonomi. Nei 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 collezione Speculative Decoding Modules su HuggingFace. Esistono implementazioni di terze parti per vLLM e SGLang.

P-EAGLE: Bozza parallela (Marzo 2026)

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

Il risultato: P-EAGLE offre un aumento di velocità fino a 1.69x rispetto al vanilla EAGLE-3 su carichi di lavoro reali su NVIDIA B200. Il vantaggio si amplia a valori K più alti — dove la bozza sequenziale di EAGLE-3 diventa un collo di bottiglia, la bozza parallela di P-EAGLE non comporta 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 gestisce il resto. P-EAGLE è lo stato dell’arte attuale per la decodifica speculativa basata su EAGLE, e se stai distribuendo EAGLE nel 2026, P-EAGLE è la variante da usare.

Decodifica speculativa n-gram

La decodifica speculativa n-gram sostituisce una bozza neurale con l’abbinamento di pattern contro la storia del prompt. L’algoritmo cerca sequenze n-gram ripetute nel contesto, e quando la sequenza di token corrente corrisponde a un pattern visto in precedenza, propone i token che hanno seguito quel pattern in precedenza — ad esempio, se il modello ha già generato def calculate_total(items): e incontra def calculate_total( di nuovo, sa che i prossimi token saranno probabilmente items): basandosi sull’occorrenza precedente.

Le varianti della mappa n-gram (ngram-map-k, ngram-map-k4v) usano tabelle hash per ricerche più rapide invece della scansione lineare, con la chiave hash come l’n-gram corrente di dimensione N e il valore come la sequenza di token che ha seguito.

Pro:

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

Contro:

• Inutile per la generazione nuova — se il pattern non è 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, riempimento di template, documentazione ripetitiva e qualsiasi carico di lavoro in cui il modello rivisita pattern simili. Peggiore per: scrittura creativa, chat aperta e compiti di ragionamento.

Regolazione dei parametri

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

Per carichi di lavoro testuali, riduci size-n a 8-10 e aumenta min-hits a 2. Questo scambia la frequenza di corrispondenza per tassi di accettazione più alti per ogni corrispondenza.

Decodifica auto-speculativa

La decodifica auto-speculativa (nota anche come LayerSkip o self-speculation) 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, la decodifica auto-speculativa esegue una versione troncata — saltando alcuni strati transformer — per generare token di bozza a basso costo, e il modello completo verifica poi le proposte.

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

Pro:

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

Contro:

• Richiede la modifica del motore di inferenza per supportare passaggi in avanti parziali
• Complicazioni della cache KV — la bozza usa una cache KV parziale che deve essere conciliata con la cache del modello completo
• I tassi di accettazione sono tipicamente inferiori rispetto a EAGLE o modelli di bozza ben regolati

Implementazione llama.cpp: PR #18471 ha introdotto la decodifica auto-speculativa usando la storia del contesto come bozza. Il modello riutilizza token dalla sua propria storia di generazione per proporre continuazioni, particolarmente efficace per carichi di lavoro di coding dove i pattern si ripetono all’interno della stessa finestra di contesto.

MTP (Previsione Multi-Token)

MTP è una forma specializzata di decodifica speculativa costruita direttamente in determinati checkpoint del modello. Qwen 3.6 si ship sia con varianti GGUF standard che abilitate per MTP.

Come differisce: 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 in 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 è attivato con --spec-type draft-mtp --spec-draft-n-max N
• Le teste MTP aggiungono ~1-2 GB di sovraccarico VRAM
• Funziona meglio su architetture MoE (Qwen 3.6 35B-A3B) dove il routing spars keeps le teste MTP economiche

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

Tassi di accettazione: cosa significano nella pratica

Il tasso di accettazione (α) è il singolo metrica più importante per le prestazioni della decodifica speculativa. Determina se stai ottenendo un aumento di velocità o pagando un sovraccarico.

La formula dell’aumento di velocità

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, accetti 3.5 token per passaggio — un aumento di velocità di 3.5x rispetto alla decodifica 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 per:

• 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: Una temperatura più alta aumenta la divergenza tra bozza e target, abbassando l’accettazione. La decodifica speculativa funziona meglio a bassa temperatura (0.0-0.7).

Soglia critica: Se il tuo tasso di accettazione effettivo (α × K) scende sotto 1.0, la decodifica speculativa è più lenta della decodifica standard. Il sovraccarico della bozza più il tempo di verifica supera il costo di un singolo passo autoregressivo.

Decodifica speculativa in produzione: cosa succede realmente

I paper di ricerca riportano aumenti di velocità da 2 a 4x, ma i benchmark di produzione raccontano una storia più sfumata — gli aumenti di velocità si riducono con la dimensione del batch, la verifica domina il tempo di ciclo e nessun metodo singolo 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 attraverso quattro modelli e sei carichi di lavoro ha rivelato:

1. SD funziona, ma gli aumenti di velocità si riducono con la dimensione del batch. A dimensione batch 1, EAGLE raggiunge fino a 1.96x su Llama-3-70B. Alla dimensione batch 128, questo scende a 1.21x. Il sistema diventa limitato 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 in avanti del modello target è il collo di bottiglia. Ridurre la verifica sprecata sui token rifiutati è la via più promettente per il miglioramento.

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

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

Aspettative pratiche di aumento di velocità

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 la decodifica speculativa aggiunge sovraccarico senza beneficio proporzionale.

Monitoraggio in produzione

Dovresti tracciare il tasso di accettazione in produzione. Un tasso di accettazione in calo segnala che il tuo modello di bozza sta divergendo dal target — o perché il carico di lavoro è cambiato, o perché il modello di bozza necessita di riaddestramento.

Metriche chiave da monitorare:

• Tasso di accettazione per richiesta (dovrebbe essere stabile intorno al tuo baseline)
• Token al secondo con vs senza decodifica speculativa (l’aumento di velocità effettivo)
• Tempo di verifica come percentuale del tempo di ciclo (dovrebbe essere 42-95%)
• Tempo del passaggio in avanti del modello di bozza (dovrebbe essere < 20% del tempo del modello target)

Se il tuo tasso di accettazione scende sotto il 40%, disabilita la decodifica speculativa per quella richiesta. Il sovraccarico non ne vale la pena.

Configurazione pratica

La scelta del motore conta tanto quanto la strategia di bozza — vedi Ollama vs vLLM vs LM Studio e altri runtime locali per come ogni runtime gestisce il batching, la compatibilità API e il throughput prima di scegliere un percorso di decodifica speculativa.

llama.cpp

Per la configurazione del server generale e il caricamento GGUF, inizia con il quickstart llama.cpp; i flag qui sotto aggiungono la decodifica speculativa sopra.

llama.cpp supporta più metodi di decodifica speculativa 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 la decodifica speculativa

# 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 (tuning carico di lavoro testo)
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-speculativa (carichi di lavoro coding)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

Flag critici:

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

Insidie comuni:

• Dimenticare --parallel 1 — il server ignorerà silenziosamente la decodifica speculativa.
• Usare modelli di bozza tra famiglie diverse — i tassi di accettazione collassano, annullando qualsiasi aumento di velocità.
• Impostare --spec-draft-n-max troppo alto — ogni token di bozza extra costa VRAM per il buffer di bozza. I rendimenti diminuiscono intorno a 5-8.

vLLM

Il quickstart vLLM copre il deployment base; i flag qui sotto abilitano la decodifica speculativa su un server vLLM esistente.

vLLM supporta la decodifica speculativa 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 (bozza parallela)
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

La decodifica speculativa di vLLM è integrata con il batching continuo, quindi funziona sotto carichi di lavoro concorrenti. Lo scheduler gestisce più slot di token all’interno di un singolo passaggio in avanti, e il gestore della memoria gestisce la cache KV per entrambi i modelli di bozza e target.

SGLang

SGLang supporta la decodifica speculativa 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 con la decodifica speculativa perché la memorizzazione dei prefissi riduce il costo di verifica — il modello target riutilizza l’attenzione memorizzata per i prefissi condivisi, rendendo ogni passaggio di verifica più economico di un passaggio in avanti a freddo.

TensorRT-LLM

TensorRT-LLM fornisce decodifica speculativa di grado produzione con Triton Inference Server. La configurazione è più complessa ma offre le migliori prestazioni su hardware NVIDIA:

1. Costruisci il motore TensorRT per entrambi i modelli target e di bozza.
2. Configura il repository del modello con model.yaml che specifica la configurazione della decodifica speculativa.
3. Avvia Triton con l’API LLM / backend PyTorch.

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

Quando usare la decodifica speculativa

Usalo Quando

• Modelli target grandi (7B+): Il sovraccarico del meccanismo di bozza è ammortizzato sul calcolo del target. La decodifica speculativa brilla quando il modello target è lento — più grande è il target, più prezioso è l’aumento di velocità.
• Carichi di lavoro a bassa temperatura: La decodifica speculativa funziona meglio a temperatura 0.0-0.7, dove la distribuzione del modello target è concentrata e la bozza ha una migliore probabilità di corrispondenza.
• Applicazioni interattive: I carichi di lavoro sensibili alla latenza (chat, completamento codice, chiamate tool agente) beneficiano di più. L’elaborazione batch dove la GPU è già satura vede meno benefici.
• Generazione e modifica del codice: L’alta ripetizione nei pattern del codice rende n-gram e la decodifica auto-speculativa particolarmente efficaci.

Saltalo Quando

• Modelli target piccoli (< 3B): Il sovraccarico del modello di bozza si avvicina al tempo del passaggio in avanti del target. L’aumento di velocità è marginale o negativo.
• Campionamento ad alta temperatura: A temperatura > 0.7, la distribuzione del modello target è troppo ampia per la bozza da corrispondere in modo affidabile.
• Scrittura creativa e generazione aperta: Bassi tassi di accettazione sul contenuto nuovo rendono il sovraccarico non vale la pena.
• Dimensioni batch alte (> 32): Il sistema diventa limitato dal calcolo, e la decodifica speculativa aggiunge sovraccarico senza beneficio proporzionale. SpecDecode-Bench mostra l’aumento di velocità che scende da 1.96x a 1.21x mentre la dimensione del batch passa da 1 a 128.

Combinazione di metodi

Le configurazioni avanzate combinano più strategie di decodifica speculativa. L’analisi oracle di SpecDecode-Bench ha mostrato che combinare adattivamente n-gram e EAGLE può spingere l’aumento di velocità a 4.9x sui carichi di lavoro di modifica del codice.

L’idea è usare n-gram per i pattern che sono apparsi prima, dove l’accettazione è alta e il sovraccarico è vicino a zero, e fallback a EAGLE per i token nuovi. Nella pratica questo richiede supporto del motore per la speculazione multi-metodo — vLLM e TensorRT-LLM hanno supporto sperimentale, ma le implementazioni di grado produzione sono ancora in via 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 aumento di velocità di 1.8x.

Considerazioni sui costi

La decodifica speculativa scambia calcolo per latenza. Il calcolo totale per token è pressappoco lo stesso — stai solo facendo più lavoro in parallelo piuttosto che in sequenza.

Impatto sui costi GPU:

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

Inferenza cloud: A $2-4/ora per H100, la decodifica speculativa riduce la latenza per richiesta senza aumentare il costo per token. Per l’elaborazione batch dove la GPU è già satura, il beneficio sui costi è minimo — stai pagando per lo stesso tempo GPU in ogni caso.

Quando la decodifica speculativa fa risparmiare soldi: Applicazioni interattive dove si fattura per richiesta e si vuole ridurre il tempo-al-primo-token. Un aumento di velocità di 2x significa che i tuoi utenti aspettano la metà del tempo, e puoi servire più richieste al secondo sullo stesso hardware.

Quando non lo fa: Elaborazione batch dove stai già massimizzando l’utilizzo della GPU. Il calcolo extra dalla decodifica speculativa non aumenta il throughput — cambia solo il profilo di latenza.

Cosa c’è dopo

La decodifica speculativa sta maturando da novità di ricerca a standard di produzione. Il confine sta spingendo oltre le limitazioni attuali:

• Speculative Speculative Decoding (SSD): Parallelizza le fasi di bozza e verifica su hardware separato. Il modello di bozza esegue in modo asincrono, pre-speculando per più esiti di verifica probabili. I primi risultati mostrano un aumento di velocità fino a 2x rispetto alla decodifica speculativa ottimizzata, e 5x rispetto alla decodifica autoregressiva. Non ancora pronto per la produzione, ma la direzione è chiara.

• SpecSA (Verifica Speculativa Sparse): Combina la decodifica speculativa 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 alla decodifica autoregressiva sparse. Rilevante per modelli a contesto lungo dove l’attenzione sparse è già in uso.

• Speculazione adattiva: Commutazione automatica tra n-gram, EAGLE e metodi draft-model basata sulle caratteristiche del carico di lavoro. L’analisi oracle mostra un potenziale significativo inesplorato — le implementazioni attuali raggiungono 2-3x, ma il limite teorico è 4.9x.

• Decodifica speculativa multimodale: Estensione della bozza-verifica a modelli visione-linguaggio e generazione video. Prime indagini mostrano che gli stessi principi si applicano, ma le strategie di verifica necessitano di adattamento per modalità non testuali.

Framework decisionale