Inferenza LLM più veloce con la decodifica speculativa

Per chi sviluppa un'applicazione, la domanda utile è se la risposta arriva più velocemente in streaming con il proprio carico di lavoro. Per chi gestisce il servizio di inferenza, conta che il vantaggio regga anche con richieste simultanee e memoria sotto pressione. Chi acquista un'API gestita deve invece capire se il provider espone questa ottimizzazione o almeno ne documenta l'uso.

Documentazione verificata il 30 ottobre 2026: vLLM, SGLang e NVIDIA TensorRT-LLM. I comandi riportati sotto seguono la documentazione online: sono esempi di configurazione, non risultati di benchmark condotti per questo articolo.

Che cos'è la decodifica speculativa e come accelera l'inferenza LLM?

Un componente poco costoso da eseguire propone i token successivi; il modello principale decide quali possono entrare nella risposta. Un token è un'unità di testo elaborata dal modello, spesso una parte di parola. Il modello principale, o target, è quello di cui si vuole preservare il comportamento.

Immaginiamo un assistente che prepara una frase per un redattore scrupoloso. L'assistente può portarsi avanti, ma nulla arriva al lettore senza il controllo del redattore. Il vantaggio sta nel fatto che il target può valutare tutta la continuazione proposta insieme, senza dover aspettare un passaggio di generazione separato per ogni nuovo token. NVIDIA descrive il processo come un meccanismo di stesura della bozza seguito da un passaggio di verifica del target. Documentazione di TensorRT-LLM

Nella figura, le lettere rappresentano gli ID dei token. Il modello che prepara la bozza, detto drafter, propone A B C. Con la decodifica greedy, che sceglie il token successivo con la probabilità più alta, supponiamo che il target concordi su A B ma voglia proseguire con X. La risposta confermata diventa A B X. Anche l'eventuale continuazione preparata dopo il token C rifiutato viene scartata, perché dipendeva dal prefisso sbagliato.

Quando l'output viene campionato, il criterio di accettazione è più articolato di un semplice confronto tra le parole scelte dai due modelli. Il campionamento speculativo standard usa le probabilità del target e della proposta, con una distribuzione di correzione quando una proposta viene rifiutata. È proprio questa correzione a preservare la distribuzione di probabilità del target. L'algoritmo originale consente inoltre di aggiungere un token del target quando viene accettata l'intera bozza. Articolo originale di Leviathan, Kalman e Matias

Il modello più piccolo fornisce quindi proposte: non è un sostituto a cui delegare la risposta. Con un verificatore esatto, un drafter poco adatto dovrebbe penalizzare la velocità, senza prendere silenziosamente il controllo dell'output.

Che cosa significa «senza affidarsi a un modello meno capace»

La garanzia da chiedere è la conservazione della distribuzione del target. Non significa ottenere la stessa risposta casuale a ogni esecuzione, eliminare gli errori del target o migliorarne il ragionamento. vLLM documenta effetti numerici e legati al batching che possono produrre differenze anche quando l'algoritmo è senza perdita, o lossless. Garanzie lossless di vLLM

Durante la valutazione della decodifica speculativa, i pesi del target, la quantizzazione e le impostazioni di campionamento devono restare invariati. Modificando più elementi insieme, non si può attribuire a uno specifico cambiamento un'eventuale differenza di qualità.

Le varianti principali e la documentazione dei motori di inferenza

Il componente che genera le proposte va scelto in base al supporto dello specifico modello target e della versione del motore in uso. Il meccanismo resta sempre lo stesso: preparare una bozza e verificarla. A cambiare è la fonte della bozza.

Un modello separato per la bozza

Un modello linguistico più piccolo genera i token candidati usando i propri pesi. È la configurazione più intuitiva, ma richiede di caricare e gestire un altro modello. Contano la compatibilità e l'accordo con il target: «più piccolo» non significa automaticamente «utile». vLLM normalmente richiede un vocabolario condiviso, ma documenta anche un'opzione con supporto limitato per vocabolari diversi. Modelli draft in vLLM

Se il servizio è già vicino al limite di memoria, aggiungere un secondo modello può essere la prima mossa sbagliata. Se invece la latenza è cruciale, c'è capacità libera e il drafter è ben abbinato al target, vale la pena fare un esperimento controllato.

Decodifica speculativa con EAGLE

EAGLE, acronimo di Extrapolation Algorithm for Greater Language-model Efficiency, usa un drafter ausiliario addestrato e associato al target. Per proporre la continuazione, il drafter si serve delle rappresentazioni interne del target. Questi componenti addestrati, spesso chiamati head, richiedono un checkpoint compatibile. vLLM distingue le configurazioni eagle ed eagle3. Documentazione EAGLE di vLLM

Il target e il suo checkpoint EAGLE vanno trattati come una coppia compatibile. Non basta che il nome del checkpoint contenga la stessa famiglia di modelli. La famiglia corretta, la revisione del modello e l'implementazione del servizio di inferenza devono essere tutte registrate nella documentazione del deployment.

Decodifica speculativa con MTP

La multi-token prediction, o MTP, sfrutta la capacità nativa di un modello di proporre token futuri. vLLM la documenta come opzione per le famiglie di modelli supportate e fornisce un esempio di avvio che non richiede l'identificativo di un modello draft separato. Un modello privo di questa capacità non la acquisisce impostando method su mtp. Documentazione MTP di vLLM

Se il servizio usa già un checkpoint MTP supportato, conviene provare la configurazione documentata prima di aggiungere un drafter indipendente e non correlato. Si riducono così le scelte di compatibilità da affrontare, anche se le prestazioni restano da misurare.

La tabella seguente rimanda direttamente alla documentazione dei motori. Indica dove trovare le configurazioni, senza implicare che ogni modello funzioni in ogni combinazione.

Il nome di un algoritmo e la sua organizzazione in fase di esecuzione sono due cose diverse. Le note di rilascio attuali di TensorRT-LLM eliminano il percorso di esecuzione con un motore draft separato e mantengono le implementazioni che collocano il drafter all'interno del modello come sottomodulo. Questo non significa che l'approccio draft/target sia scomparso. Significa che vecchie istruzioni di deployment possono descrivere un percorso di esecuzione che la versione installata non offre più. Note di rilascio di TensorRT-LLM

Quando la decodifica speculativa conviene e quando no

La decodifica speculativa offre un vantaggio solo se l'output utile arriva prima, contando tutto il lavoro aggiuntivo. Il tasso di accettazione conta, ma è solo una parte del calcolo.

I token accettati devono ripagare il costo della bozza

Il tasso di accettazione è il rapporto tra i token della bozza accettati e quelli proposti. Da solo non dice quanto sia costato generarli. Un drafter più lento può concordare più spesso con il target e comunque rallentare il servizio.

Un criterio utile per decidere è:

(tempo di stesura della bozza + tempo di verifica + tempo di coordinamento) ÷ token di output confermati < tempo di decodifica per token senza speculazione

È una verifica dei costi, non una previsione di benchmark. Va misurato il ciclo completo sul proprio hardware. I «token di output confermati» comprendono anche un token di correzione o aggiuntivo fornito dal target, non soltanto le proposte accettate dalla bozza.

In un assistente per modificare codice, la ripetizione di strutture locali può rendere utili le proposte. In un assistente per il supporto clienti, il drafter potrebbe concordare sulle formule di cortesia e sui raccordi tra le frasi, ma faticare nelle risposte specifiche sul prodotto. I due carichi vanno misurati separatamente prima di basare una decisione di deployment sul tasso medio di accettazione.

Bozze più lunghe producono anche più lavoro che potrebbe essere scartato. La loro lunghezza va aumentata solo finché l'output confermato in più compensa i costi aggiuntivi di stesura, verifica e memoria. Nelle indicazioni di ottimizzazione, Fireworks sottolinea la stessa distinzione operativa: l'accettazione, da sola, non dimostra un vantaggio di velocità. Indicazioni di Fireworks sui benchmark

La dimensione del batch cambia il margine di miglioramento

Conviene partire dai carichi interattivi limitati dalla decodifica, per poi verificare il comportamento al picco di richieste simultanee. vLLM indica espressamente la decodifica speculativa per carichi vincolati dalla memoria, con un tasso di richieste medio-basso. In un passaggio vincolato dalla memoria, il trasferimento dei dati del modello limita l'avanzamento più della capacità di calcolo disponibile. Indicazioni di vLLM sui carichi di lavoro

La verifica in parallelo può sfruttare capacità di calcolo altrimenti sottoutilizzata. Un server molto impegnato, però, potrebbe già impiegarla per altre richieste. Dal punto di vista operativo, una latenza inferiore per una singola chat non dimostra quindi un throughput complessivo maggiore su un endpoint sotto carico.

Il continuous batching cambia quali richieste condividono ciascun passaggio di generazione. La decodifica speculativa va valutata con quello scheduler, riproducendo anche l'andamento reale degli arrivi. Un endpoint di sviluppo poco utilizzato e un endpoint di produzione con richieste in coda sono due esperimenti diversi.

Non esiste una soglia universale da imporre alla dimensione del batch. Il limite utile dipende dal modello, dall'hardware, dal metodo di stesura della bozza e dallo scheduler. Servono entrambe le prospettive, latenza e capacità: quanto velocemente arriva la risposta in streaming e quanto traffico il servizio regge rispettando l'obiettivo di latenza.

La memoria può annullare il vantaggio

Il drafter compete per una quantità finita di memoria GPU. Pesi separati, stato della bozza e aree di lavoro per la verifica possono occupare spazio che altrimenti servirebbe a gestire richieste. Anche la KV cache, che conserva lo stato dell'attenzione per i token già presenti, rientra in questo budget.

Prendiamo un assistente documentale veloce con prompt brevi, ma vicino al limite di capacità sui documenti lunghi. Un test riuscito con prompt brevi non dimostra che ci sia ancora spazio per la bozza accanto alla cache di produzione. Occorre provare il contesto più lungo che si intende supportare, con un numero realistico di richieste simultanee.

Le indicazioni di SGLang per gli errori di memoria esaurita includono esplicitamente la riduzione della memoria riservata, delle dimensioni usate per il graph capture, dell'albero delle bozze e delle richieste simultanee. Se occorre ridurre queste ultime per far entrare la decodifica speculativa in memoria, si tratta di un compromesso da misurare, non di un'ottimizzazione senza costi. Risoluzione dei problemi di memoria in SGLang

Accelerare la fase che fa attendere l'utente

Una risposta lenta può dipendere dall'attesa prima che inizi l'output, da uno streaming lento dopo l'avvio oppure da ritardi esterni al modello. La decodifica speculativa interviene sulla generazione. Se l'applicazione passa gran parte del tempo a cercare documenti o ad attendere una chiamata a uno strumento, accelerare il ciclo di decodifica può cambiare ben poco nell'esperienza d'uso.

Nelle misurazioni occorre separare attesa in coda, prefill e decode. Il prefill elabora il prompt; il decode produce la continuazione. La guida all'inferenza LLM illustra queste fasi, mentre la guida ai token al secondo distingue la velocità di output dal throughput complessivo delle richieste.

Come attivare la decodifica speculativa

La decodifica speculativa si attiva nel processo che serve il modello; poi si confronta il risultato con lo stesso target eseguito senza questa ottimizzazione. Gli esempi presuppongono che il motore sia già installato, che l'hardware possa contenere i modelli scelti e che si abbia accesso ai loro pesi. La documentazione deve corrispondere alla versione distribuita: una pagina latest online non garantisce la compatibilità con un container più vecchio.

Decodifica speculativa in vLLM

vLLM usa un oggetto JSON passato tramite --speculative-config. Questo esempio con un modello draft separato riprende target, drafter e lunghezza della bozza dalla documentazione per l'erogazione online:

vllm serve Qwen/Qwen3-4B-Thinking-2507 \
  --speculative-config '{"method":"draft_model","model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5}'

Il valore 5 indica il numero di proposte dell'esempio, non un valore ottimale consigliato. La documentazione depreca i precedenti flag separati --speculative-model e --num-speculative-tokens. Esempi di avvio di vLLM

Per un esempio con MTP nativa, il checkpoint base Xiaomi MiMo documentato si avvia così:

vllm serve XiaomiMiMo/MiMo-7B-Base \
  --tensor-parallel-size 1 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

È un esempio con un modello diverso, non un drafter da collegare direttamente al target Qwen precedente. Il requisito decisivo è il supporto del checkpoint: MTP deve essere presente nel modello e supportata dal motore. Esempio di avvio MTP in vLLM

Decodifica speculativa in SGLang

L'esempio attuale di SGLang per lo scheduler con sovrapposizione delle operazioni, o overlap scheduler, fornisce una coppia Qwen con target e drafter separati:

python3 -m sglang.launch_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --speculative-algorithm STANDALONE \
  --speculative-draft-model-path Qwen/Qwen2.5-1.5B-Instruct \
  --speculative-num-steps 4 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 5 \
  --mem-fraction-static 0.7 \
  --cuda-graph-max-bs-decode 8

L'attuale modalità overlap richiede --speculative-eagle-topk 1. Un albero più ampio copiato da un altro esempio è incompatibile con questa modalità. Le impostazioni documentate per scheduler e stesura della bozza vanno mantenute insieme. Esempio con overlap scheduler in SGLang

Per i carichi di lavoro variabili, SGLang documenta separatamente la speculazione adattiva per le configurazioni EAGLE supportate. Prima di aspettarsi che la lunghezza della bozza si regoli da sola, occorre leggere i requisiti di questa funzione. Speculazione adattiva in SGLang

Configurazione di TensorRT-LLM

TensorRT-LLM accetta le impostazioni della decodifica speculativa tramite una configurazione YAML. Salvare questo contenuto in speculative.yaml:

speculative_config:
  decoding_type: Eagle3
  max_draft_len: 4
  speculative_model: yuhuili/EAGLE3-LLaMA3.1-Instruct-8B

La lunghezza della bozza e il checkpoint provengono dall'esempio di configurazione speculativa di NVIDIA. Avviare il target corrispondente con la CLI del servizio di inferenza documentata:

trtllm-serve meta-llama/Llama-3.1-8B-Instruct \
  --config speculative.yaml

Va controllata anche la generazione del checkpoint, oltre al nome della configurazione. NVIDIA documenta Eagle come alias di compatibilità per Eagle3, ma le generazioni precedenti di checkpoint EAGLE restano incompatibili con questa modalità. Vincolo sui checkpoint di TensorRT-LLM

Se occorre scegliere anche il motore di inferenza, oltre al metodo speculativo, il confronto tra vLLM e SGLang offre una visione più ampia. Un buon drafter non può compensare l'assenza, nel motore, di un'altra funzione necessaria all'applicazione.

Anche chi usa un'API gestita può beneficiarne?

Sì, dove il provider la documenta e la abilita; il controllo disponibile dipende dal servizio. Non occorre possedere le GPU per beneficiare delle ottimizzazioni di inferenza del provider.

Fireworks AI, provider di inferenza gestita, documenta drafter predefiniti per la maggior parte dei modelli supportati sui deployment dedicati. Un modello senza drafter predefinito viene eseguito senza speculazione basata su un modello, salvo configurazione diversa. Fireworks gestisce la configurazione dell'inferenza serverless: i flag dei deployment dedicati non dimostrano quindi che ogni endpoint serverless usi la decodifica speculativa. Documentazione dei deployment Fireworks

Per chi rigenera un file con piccole modifiche, Fireworks documenta anche Predicted Outputs: il testo atteso si passa nel campo prediction della richiesta. Quel testo già noto diventa una fonte diversa di proposte e può affiancare la speculazione basata su un modello. È utile quando si conosce già gran parte della risposta, più che quando si pone una domanda aperta. Predicted Outputs di Fireworks

Per altri endpoint gestiti, occorre consultare la documentazione del provider prima di attribuire loro questo vantaggio o aggiungere un'impostazione. La sola compatibilità dell'API non dice quale modello draft, se presente, venga eseguito dietro l'endpoint.

Le promesse da ridimensionare

La decodifica speculativa migliora il servizio di inferenza solo in determinate condizioni: non è un moltiplicatore universale di velocità. Qui non viene promesso alcun aumento numerico delle prestazioni, perché un risultato ottenuto con un altro target, un altro drafter, un'altra GPU e un diverso mix di traffico non descrive il proprio servizio.

«Più token accettati significa un'applicazione più veloce» trascura il costo della bozza, l'attesa in coda e tutto ciò che l'applicazione fa intorno alla generazione. «Una bozza più lunga è migliore» ignora il lavoro scartato dopo un rifiuto. «Lossless significa stringhe identiche» confonde una distribuzione di campionamento con uno specifico esito casuale.

L'errore più costoso è trasformare un risultato ottenuto su un endpoint poco utilizzato in un'affermazione sulla capacità in produzione. Un assistente di programmazione può sembrare più veloce al suo sviluppatore mentre l'endpoint condiviso riesce a gestire meno sessioni simultanee. Occorre decidere se ottimizzare la latenza della risposta, il throughput sostenibile o entrambi, ed esplicitare questa scelta nei criteri di rilascio.

Un piano operativo per la prossima settimana

Chi sviluppa dovrebbe provare un componente compatibile per le proposte quando la decodifica è il collo di bottiglia. Chi gestisce il servizio dovrebbe esigere un vantaggio sotto carico di produzione. I team che usano API gestite dovrebbero partire dai controlli effettivamente documentati dal provider.

Se gran parte dell'attesa precede la generazione, va risolto prima quel collo di bottiglia. Se la bozza non entra in memoria o non esiste un checkpoint compatibile, il target può continuare a funzionare normalmente. La disponibilità di una funzione non dimostra che serva al proprio deployment.

Domande frequenti di chi sviluppa

Iscriviti alla newsletter per guide pratiche allo sviluppo e alla gestione di sistemi di IA.