MTP: velocità senza rischi
MTP: velocità senza rischi
Il CERT-AgID ha di recente pubblicato un paper che ogni team che lavora con LLM in produzione dovrebbe leggere: l’accelerazione dei modelli tramite Multi-Token Prediction (MTP) non è solo una questione di performance, ma un problema di sicurezza operativa. Se il draft che anticipa i token non resta subordinato al modello principale, il sistema può diventare instabile, imprevedibile e vulnerabile a un Denial of Service applicativo — anche senza alcun exploit classico.
Indice dei contenuti – MTP: velocità senza rischi
- Cos’è il Multi-Token Prediction e perché AGID se ne occupa ora
- Il rischio: quando la velocità diventa un problema di sicurezza
- Le tre dimensioni della sicurezza operativa secondo il CERT-AgID
- I risultati dei test: cosa cambiano p75, p95 e affinità CPU
- Esempio pratico: checklist di adozione MTP e monitoring p95 per un team dev
- Impatti sul mercato italiano: PA, fornitori IT e software house
- Conclusioni e formazione professionale
1. Cos’è il Multi-Token Prediction e perché AGID se ne occupa ora
Parliamo di MTP: velocità senza rischi. Il Multi-Token Prediction (MTP) è la tecnica che permette a un LLM di prevedere più token futuri in un solo passaggio, invece di generarli uno alla volta. In fase di inferenza viene quasi sempre abbinata al decoding speculativo: un modello “draft” più leggero propone un blocco di token successivi, e il modello “target” (quello principale) li verifica tutti insieme. Se il draft ha indovinato, il sistema avanza di più passi in un colpo solo, risparmiando tempo di calcolo.
Pensa a un assistente che scrive al tuo fianco mentre stai completando un documento: mentre tu digiti, lui prova ad anticipare le tre o quattro parole successive. Se ha indovinato, accetti il blocco e vai avanti veloce. Se ha sbagliato, scarti la proposta e riprendi da dove eri rimasto. L’assistente propone, ma tu — l’autore — resti l’ultima parola su cosa finisce davvero sul foglio.
Il CERT-AgID ha pubblicato a giugno 2026 il paper “Sicurezza e performance nel path MTP”, un’analisi tecnica che entra nel dettaglio di questa dinamica sui runtime locali. Il motivo per cui interessa oggi, e non tra un anno, è semplice: sempre più aziende italiane stanno portando LLM in produzione su infrastrutture proprie (on-premise o CPU-only, non solo su GPU cloud) per ridurre costi e mantenere il controllo dei dati, e l’MTP è una delle tecniche di ottimizzazione più adottate nei runtime moderni come llama.cpp e derivati.
2. Il rischio: quando la velocità diventa un problema di sicurezza – MTP: velocità senza rischi
Il punto centrale del paper AGID è che il draft non deve mai diventare l’autorità finale. Il suo compito è accelerare, non decidere. Durante la validazione speculativa possono verificarsi tre scenari: full accept (il target accetta tutta la proposta del draft, guadagno massimo), full reject (il target rifiuta tutto, nessun guadagno ma nessun danno) e partial accept, lo scenario critico in cui il target accetta solo una parte della proposta e il sistema deve riallineare il proprio stato interno per ripartire dal punto esatto.
Ed è proprio nel riallineamento che nascono i rischi. Un LLM mantiene durante la generazione uno stato interno fatto di due elementi: il frontier logico (il punto fino a cui la generazione è ufficialmente consolidata) e la KV cache (la memoria che evita di ricalcolare l’intero contesto a ogni passaggio, funzionando come un segnalibro). Nel path MTP questi due elementi possono temporaneamente disallinearsi: le parole suggerite dal draft sono già “scritte sul foglio”, ma il target deve ancora verificarle.
Questa asincronia non è di per sé un problema — lo diventa se il runtime confonde i token proposti con quelli già verificati. In quel caso il sistema rischia di validare token nella posizione sbagliata, corrompere la KV cache con dati incoerenti, o essere costretto a ricalcolare passaggi già effettuati. Non è un bug esotico: è esattamente il tipo di comportamento che, in un sistema esposto a input non fidati, un attaccante può provare a innescare deliberatamente.
3. Le tre dimensioni della sicurezza operativa secondo il CERT-AgID
Il paper definisce la sicurezza operativa su tre assi, distinti dalla moderazione dei contenuti a cui siamo abituati a pensare quando si parla di “AI safety”:
Integrità del comportamento. Attivare l’MTP dovrebbe cambiare solo la velocità, non la risposta finale. Una variazione nell’output è accettabile se dipende dal normale sampling del modello (due strade diverse ma entrambe valide); è invece una violazione se dipende da uno stato interno perso — KV cache, sampler, frontier logico e token accettati/rifiutati non più sincronizzati tra loro.
Disponibilità del servizio. Un path MTP instabile attiva meccanismi di recupero come il replay (rifare parte del lavoro già svolto) o il fallback (abbandonare la via veloce e tornare al decoding classico). Non sono errori in sé, ma se diventano frequenti la disponibilità peggiora: risposte lente, irregolari, o assert falliti — controlli interni che si bloccano perché il sistema raggiunge uno stato che non dovrebbe esistere.
Prevedibilità dei costi computazionali. Qui il paper introduce un concetto molto concreto per chi lavora in sicurezza: il DoS applicativo. Se un input viene costruito apposta per spingere il draft a sbagliare ripetutamente, il sistema resta formalmente funzionante ma è costretto a un carico di lavoro molto più alto del normale — senza che serva alcuna corruzione di memoria o exploit tradizionale.
Un esempio citato nel paper è particolarmente utile per chi lavora su sistemi di analisi automatica: davanti a un comando sospetto come powershell -enc ..., un draft con policy “greedy” (che sceglie sempre la continuazione più probabile) tende a proporre un’analisi prudente (“comando sospetto, va isolato”), mentre un draft più libero può derivare verso un suggerimento operativo pericoloso (“decodifica la stringa ed eseguila”). La conclusione tecnica è netta: un draft più prevedibile è anche un draft più sicuro, anche a costo di rinunciare a un po’ di creatività nel campionamento.
4. I risultati dei test: cosa cambiano p75, p95 e affinità CPU
MTP: velocità senza rischi. Uno degli aspetti più utili del paper, dal punto di vista metodologico, è il monito contro la misurazione della sola velocità media. Il CERT-AgID sottolinea che bisogna guardare ai percentili: mentre la mediana (p50) racconta il caso normale, il p75 mostra dove le condizioni iniziano a degradare e il p95 il comportamento vicino al caso peggiore. Un’ottimizzazione può migliorare la media e peggiorare drasticamente il p95 — in laboratorio sembra un successo, in produzione diventa un picco di latenza inaccettabile.
Sulle architetture CPU-only, i test hanno mostrato un altro fattore spesso ignorato: l’effetto barriera nel calcolo parallelo. Se i thread non sono vincolati a core fisici specifici, lo scheduler del sistema operativo li sposta arbitrariamente, introducendo variabilità che non dipende dall’MTP ma dalla macchina. Usando taskset per fissare l’affinità di CPU, i ricercatori hanno ridotto lo spread del tempo totale di generazione da circa 3448 ms a circa 1716 ms.
Sul piano algoritmico, un branch sperimentale del path MTP ha migliorato lo scenario a risposta media portando la mediana da 11.320 ms a 10.628 ms, senza generare replay, fallback o assert — un miglioramento “pulito”. Al contrario, una variante in cui il draft campionava dal sampler invece di usare sempre il candidato top-1 ha peggiorato i tempi da circa 9.949 ms a 14.092 ms, un +41,6%. Il messaggio è coerente con quanto visto al punto 3: il draft deve essere prevedibile, non creativo.
5. Esempio pratico: checklist di adozione MTP e monitoring p95 per un team dev
Immaginiamo un caso concreto: un team di sviluppo di una software house italiana, chiamiamola TecnoPuglia Srl, sta portando in produzione un assistente AI per l’analisi di log di sicurezza su un cluster CPU-only, e vuole attivare l’MTP per ridurre la latenza. Ecco la checklist minima da seguire prima del go-live, coerente con le indicazioni del paper AGID:
- Verifica la policy del draft. Configura il draft in modalità top1-greedy (continuazione più probabile, non campionata) quando il sistema analizza input potenzialmente sensibili o non fidati.
- Vincola l’affinità di CPU con
tasksetper isolare la misurazione dagli effetti dello scheduler, ed evitare di attribuire all’MTP variazioni che dipendono dalla macchina. - Misura sempre p50, p75 e p95, mai solo la media, sia in fase di test che in produzione.
- Conta acceptance rate, partial accept, replay e fallback: se questi eventi crescono in modo anomalo su certi input, è un segnale di possibile DoS applicativo.
- Testa esplicitamente i prompt “difficili” (worst-case), non solo lo scenario medio.
Uno script minimo per raccogliere questi dati in un ambiente di test locale può essere strutturato così:
#!/usr/bin/env bash
# monitor_mtp.sh — raccoglie metriche di latenza e stabilità per un path MTP
# Uso: ./monitor_mtp.sh "prompt di test" 30 (30 = numero di run)
PROMPT="$1"
RUNS="${2:-30}"
OUT="mtp_metrics.csv"
echo "run,generation_time_ms,accepted_tokens,rejected_tokens,replay_events,fallback_events" > "$OUT"
for i in $(seq 1 "$RUNS"); do
# Vincola l'esecuzione ai core 0-5 per eliminare l'effetto barriera dello scheduler
RESULT=$(taskset -c 0-5 ./llm_runtime \
--prompt "$PROMPT" \
--mtp-policy top1-greedy \
--metrics-json)
# Il runtime deve esporre queste metriche in JSON per ogni run
echo "$i,$(echo "$RESULT" | jq -r '.generation_time_ms'),\
$(echo "$RESULT" | jq -r '.accepted_tokens'),\
$(echo "$RESULT" | jq -r '.rejected_tokens'),\
$(echo "$RESULT" | jq -r '.replay_events'),\
$(echo "$RESULT" | jq -r '.fallback_events')" >> "$OUT"
done
# Calcolo dei percentili con python (numpy) sulla colonna generation_time_ms
python3 - "$OUT" <<'EOF'
import sys, csv
import numpy as np
with open(sys.argv[1]) as f:
reader = csv.DictReader(f)
times = [float(row["generation_time_ms"]) for row in reader]
p50 = np.percentile(times, 50)
p75 = np.percentile(times, 75)
p95 = np.percentile(times, 95)
print(f"p50: {p50:.0f} ms")
print(f"p75: {p75:.0f} ms")
print(f"p95: {p95:.0f} ms")
if p95 > p50 * 1.5:
print("ATTENZIONE: coda lunga (p95 > 1.5x p50). Verificare replay/fallback e policy del draft.")
EOF
Questo script è volutamente generico: llm_runtime va sostituito con il binario o l’endpoint del runtime effettivamente usato (llama.cpp, vLLM, o un servizio interno), a patto che esponga le metriche di accettazione, replay e fallback richieste dal paper. Il punto non è il tool specifico, ma il metodo: senza p75/p95 e senza contare gli eventi di recupero, non si sta davvero misurando la sicurezza del path MTP, solo la sua velocità media.
6. Impatti sul mercato italiano: PA, fornitori IT e software house
Le indicazioni del CERT-AgID non sono un semplice paper accademico: arrivano dall’agenzia che detta le linee guida di sicurezza per la Pubblica Amministrazione italiana, e questo ha conseguenze dirette su chi fornisce soluzioni AI alla PA o a settori regolamentati.
Per i fornitori IT e le software house che vendono soluzioni basate su LLM a enti pubblici, è ragionevole aspettarsi che nei prossimi capitolati tecnici compaiano requisiti su monitoraggio dei percentili di latenza, tracciabilità degli eventi di fallback/replay e policy del draft documentata, esattamente le metriche descritte nel paper. Chi non è in grado di produrre questa evidenza rischia di trovarsi tagliato fuori da gare e affidamenti che richiedono conformità alle indicazioni AgID.
Per i CISO e IT manager delle PMI, il messaggio è più ampio del solo MTP: conferma che la sicurezza dei sistemi AI si gioca anche su livelli infrastrutturali (runtime, stato interno, gestione della memoria) e non solo sui contenuti generati. È un cambio di prospettiva che richiede competenze nuove nei team, spesso non coperte dalla formazione tradizionale su cybersecurity o su sviluppo software.
Per il mercato della formazione IT, infine, questo tipo di direttive alza l’asticella: non basta più sapere “usare” un LLM tramite API, serve capire cosa succede sotto il cofano quando si ottimizzano i runtime, per poter valutare rischi, capitolati e fornitori con cognizione di causa.
7. Conclusioni e formazione professionale
Il paper del CERT-AgID ribadisce un principio semplice ma spesso dimenticato: un’ottimizzazione è sicura solo se non rende il sistema opaco, instabile o difficile da verificare. Per chi lavora con LLM in produzione, che sia in una PA, in una software house o in un team interno, questo significa aggiungere ai criteri di scelta domande che vanno oltre “quanto è veloce”: è ancora controllato? È verificabile? Il target resta l’arbitro finale? Resta stabile con input difficili? Ha costi prevedibili?
Se il tuo team sta valutando come portare LLM in produzione in modo sicuro, o vuole capire come impostare correttamente un progetto di intelligenza artificiale generativa in azienda, dalla scelta dell’architettura al monitoraggio in produzione, Innovaformazione propone due percorsi mirati:
- Corso Sviluppo applicazioni LLM, pensato per team tecnici che vogliono progettare, integrare e mettere in produzione applicazioni basate su modelli linguistici con un approccio consapevole su performance e sicurezza.
- Corso AI in Azienda, per chi in azienda deve capire impatti, rischi e opportunità dell’AI Generativa senza necessariamente scrivere codice, ma con la profondità tecnica per dialogare con i fornitori e valutare le proposte.
Contatti
Per un preventivo personalizzata su uno di questi corsi nella tua azienda, scrivi a info@innovaformazione.net o chiama il 347 1012275 — Dario Carrassi.