Il repository Hugging Face JetBrains/Mellum2.1-12B-A2.5B-Thinking-MTP mette in evidenza un dettaglio architetturale che cambia i conti dell'inference self-hosted. Non si tratta di un nuovo modello da zero, ma di una variante del Mellum2.1 Thinking con una testa multi-token prediction (MTP) aggiuntiva. La testa è un blocco transformer extra, addestrato insieme al modello principale, che prova a indovinare il token successivo a quello appena campionato. I motori di inference la usano come draft speculativa: il modello verifica ogni token proposto e l'output rimane identico, ma il decoding procede più rapidamente.

Secondo quanto riportato nella scheda, l'accelerazione è di 1,4–1,8 volte rispetto al decoding standard, con circa il 90% dei token proposti accettati al primo tentativo. Il peso della testa si trova in model-mtp.safetensors sotto il prefisso mtp., mentre il config.json la annuncia con num_nextn_predict_layers: 1. Per il resto, il modello è identico a Mellum2.1 Thinking.

La notizia tecnica ha una conseguenza pratica che va oltre il singolo checkpoint. La speculative decoding classica richiede spesso un modello draft separato: un secondo LLM, più piccolo, che propone sequenze e viene poi verificato dal modello principale. Questo approccio aumenta l'occupazione di VRAM e introduce un secondo fronte da gestire nel serving. Una testa MTP integrata elimina proprio quel fronte: il draft nasce dallo stesso checkpoint, senza un modello aggiuntivo da caricare e sincronizzare. Per chi opera in ambiente on-premise, dove la memoria GPU e la complessità operativa contano quanto il throughput, il cambiamento è rilevante.

Non è solo una questione di architettura. Il supporto è già presente nei tre ambienti più usati per il serving locale. vLLM dalla versione 0.33 accetta --speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'. transformers dalla versione 5.20 espone use_mtp=True nel metodo generate. llama.cpp, tramite il repository GGUF, usa --spec-type draft-mtp --spec-draft-n-max 1. In concreto, un team che aggiorna il runtime può attivare l'accelerazione senza cambiare il modello e senza costruire una pipeline di speculative decoding parallela.

È qui che la storia diventa strutturale. L'ottimizzazione si sposta dal layer di orchestrazione al checkpoint. Il modello porta con sé una capacità di accelerazione che i framework devono solo riconoscere. Questo riduce la variabilità delle prestazioni tra installazioni diverse e semplifica il dimensionamento dell'hardware: si guadagna velocità sulla stessa infrastruttura, senza riservare memoria a un draft model esterno. In un confronto di TCO, il beneficio non arriva dall'aggiunta di GPU, ma da un utilizzo più efficiente di quelle già presenti. Per i team che valutano deployment self-hosted, la possibilità di ottenere decoding più rapido senza introdurre componenti aggiuntivi abbassa una barriera concreta.

Resta da osservare come si comporterà l'acceptance rate su domini lontani da quelli del modello base. La verifica del token proposto, però, garantisce che l'output resti invariato anche quando il draft viene scartato: il rischio è solo una minore accelerazione, non una degradazione della qualità. La diffusione di teste MTP in checkpoint condivisi pubblicamente segnala che questa tecnica sta uscendo dalla letteratura per entrare nel serving di tutti i giorni.