Speculative decoding: perché MTP e draft esterno non sono la stessa cosa

Nel speculative decoding, il punto non è solo andare più veloci. Il punto è capire dove finisce il lavoro: dentro il modello o dentro il sistema che devi integrare.

Se devi adottarlo in un prodotto, MTP e DRAFT non sono due nomi per la stessa idea. Puntano allo stesso obiettivo — generare testo più velocemente senza rinunciare alla qualità del modello finale — ma spostano la complessità in punti diversi della pipeline.

In pratica:

• con MTP, il percorso speculativo è integrato nel modello
• con draft esterno, il percorso speculativo nasce dalla collaborazione tra due modelli

La formula che trovo più utile è questa: MTP come speculative decoding integrato, draft esterno come speculative decoding assemblato. Non è una definizione assoluta: è una distinzione operativa. Serve a capire dove vive la complessità, chi se la prende in carico e quanto lavoro resta sul team che deve portare il modello in un sistema reale.

Perché esiste lo speculative decoding

Lo speculative decoding nasce da un problema semplice: i modelli grandi sono bravi, ma costosi in latenza. Ogni token richiede lavoro, e quel lavoro si accumula.

L'idea di base è elegante: usare un percorso più veloce per proporre in anticipo alcuni token e lasciare al modello più forte il compito di verificarli. Se la proposta regge, si guadagna tempo. Se non regge, il sistema torna al percorso principale senza compromettere la qualità finale della risposta.

MTP e DRAFT abitano lo stesso spazio concettuale. La differenza vera emerge in una sola domanda: chi propone quei token in anticipo, e come viene costruito quel percorso speculativo?

MTP: quando l'accelerazione è nel modello

MTP significa Multi-Token Prediction. In termini pratici, descrive modelli che incorporano già un meccanismo capace di anticipare più token all'interno della loro stessa struttura.

Ha senso descriverlo come speculative decoding integrato perché l'accelerazione non viene assemblata dall'esterno come combinazione di due modelli separati: arriva già impacchettata nel disegno del modello.

Questo cambia molto. Da un punto di vista architetturale, il comportamento speculativo è parte del progetto del modello. Da un punto di vista operativo, una parte importante della complessità è stata risolta prima che il modello arrivi nelle mani del team che lo userà.

La promessa reale di MTP, quindi, non è solo "più velocità". È meno superfici di rottura.

Draft esterno: quando l'accelerazione va composta

Con un draft esterno, il sistema speculativo nasce dalla collaborazione tra almeno due componenti distinti: un modello principale (target) e un modello più piccolo e veloce (draft). Il draft propone alcuni token. Il target li verifica. Se la proposta è coerente, il sistema accelera. Se non lo è, il target corregge la traiettoria.

L'idea è potente, e in alcuni contesti più interessante di MTP. Ma è inevitabilmente un sistema assemblato: l'accelerazione non vive nel solo modello, vive nella relazione tra modelli.

Questo sposta il baricentro del lavoro. Non stai semplicemente scegliendo un modello. Stai progettando un accoppiamento. Devi verificare compatibilità, supporto del motore di inferenza, coerenza dei formati, equilibrio tra costo del draft e beneficio reale sul throughput, e dettagli più sottili come tokenizer e comportamento del server sotto carico.

Il draft esterno non chiede solo una decisione di modello. Chiede una decisione di sistema.

Dove vive davvero la complessità

Con MTP, la complessità tende a stare più a monte: nel modello, nel lavoro di chi lo ha progettato, addestrato e ottimizzato.

Con DRAFT, la complessità si sposta più vicino al team che adotta la soluzione. Anche quando il concetto è lineare, l'integrazione può non esserlo. È più facile trovarsi a validare dettagli laterali: supporto reale della feature, combinazione corretta tra target e draft, benefici che sulla carta esistono ma che nella pipeline reale si riducono.

Se volessi sintetizzarlo in una frase: MTP sposta il problema più a monte; DRAFT lo lascia molto più vicino a valle.

Flessibilità contro affidabilità operativa

Il vantaggio del draft esterno è evidente: puoi scegliere combinazioni diverse. Un target più forte, un draft più leggero, un compromesso specifico per un budget preciso o un'infrastruttura particolare. Per chi fa ricerca o lavora su stack altamente personalizzati, questa flessibilità è preziosa.

Ma la flessibilità non è gratuita. Ogni grado di libertà in più apre anche una possibilità in più di incompatibilità, inefficienza o manutenzione aggiuntiva.

MTP rinuncia a una parte di questa componibilità in cambio di una proposta più chiusa ma più leggibile. Non puoi riassemblare tutto a piacere, ma proprio per questo hai meno punti in cui il sistema rischia di degradarsi. Per molti team, soprattutto fuori dalla ricerca pura, questa non è una perdita. È un vantaggio netto.

Perché MTP parte spesso avvantaggiato nell'adozione

Se l'obiettivo è usare speculative decoding in modo affidabile — e non dimostrare di saper orchestrare un sistema speculativo a basso livello — allora MTP parte quasi sempre avvantaggiato.

Scelgo volutamente questa formula più prudente perché esistono contesti in cui il draft esterno è la strada giusta. Ma nella maggior parte dei casi orientati a prodotto, benchmark ripetibili o adozione concreta, MTP riduce il numero di decisioni collaterali che assorbono tempo e attenzione.

Il punto non è quale soluzione sia più elegante sulla carta. Il punto è: dove finisce il tempo del team?

Se finisce nell'integrazione, nella manutenzione di una relazione tra modelli, nella verifica di compatibilità e nella diagnosi di performance altalenanti, allora il vantaggio teorico della flessibilità rischia di evaporare. Quando è ben supportato, MTP protegge meglio il focus: consente di lavorare sul caso d'uso, sui benchmark reali, sulla latenza percepita e sul costo operativo.

Quando sceglierei comunque un draft esterno

Il draft esterno non è una soluzione di serie B. È una soluzione più esigente.

Lo sceglierei quando la flessibilità non è un vantaggio eventuale, ma una parte strutturale del problema:

• quando serve controllare in modo fine il rapporto tra costo del target e costo del draft
• quando il team lavora su una piattaforma molto personalizzata
• quando l'obiettivo principale è la ricerca, non la standardizzazione
• quando l'infrastruttura è costruita per sperimentare con coppie diverse di modelli

In questi casi il draft esterno smette di essere una complicazione indesiderata e diventa il vero spazio di progetto. Sceglierlo significa voler quella complessità, non subirla.

Conclusione

MTP e DRAFT non sono due sinonimi con packaging diverso. Sono due scelte architetturali.

La prima incorpora l'accelerazione nel modello. La seconda costruisce l'accelerazione nella relazione tra modelli. La prima tende a semplificare l'adozione. La seconda tende ad aumentare la libertà, ma anche il carico di integrazione.

Se dovessi sintetizzare in una riga: MTP è la forma più pronta dello speculative decoding; DRAFT è la forma più componibile.

Nei sistemi reali, soprattutto quando il tempo del team conta quanto la performance, questa differenza pesa molto più di quanto sembri.