Chi esegue modelli locali con llama.cpp ha ora un motivo concreto per rivedere i parametri del decoder. La release v0.8.0 ha aggiunto il supporto a DFlash2 per Qwen3.8-Flash-Next, e un test indipendente su Apple Silicon M5 Max quantifica il salto: in media il throughput di decodifica cresce del 17% rispetto al meccanismo MTP.

I numeri vanno letti per categoria. Su codice il guadagno è del 18% (95,1 tps contro 80,5), su prompt a lista sale al 39% (127 tps contro 91,4), mentre sulla prosa c'è una regressione del 3% (51,9 tps contro 53,8) che l'autore considera dentro il rumore. Nel carico con contesto da 6k token il vantaggio è del 19%, ma con contesto lungo da 25k DFlash2 scende all'incirca al livello di MTP, mentre MTP resta quasi piatto. I test sono stati condotti dopo una ricerca estesa dei parametri: per MTP n-max=3 e p-min=0,75, per DFlash2 n-max=5 e p-min=0,75.

Il dato più interessante non è il guadagno medio, ma il compromesso sulla memoria. La testa di draft DFlash2 in Q4_0 occupa circa 350 MB contro i 2,2 GB della testa ggml MTP in Q4_0 usata come riferimento. Sembrerebbe un vantaggio netto per chi ha poca VRAM, ma non è così: il buffer di calcolo richiesto da DFlash2 compensa quasi esattamente il risparmio di peso della testa. In altre parole, DFlash2 regala velocità, non memoria. Il confronto tra testa Q4_0 e Q8_0 non mostra differenze misurabili né in velocità né in accettazione, quindi la scelta della Q4_0 serve a contenere l'impronta, ma non cambia la sostanza del budget VRAM complessivo.

Questo cambia il modo di leggere i benchmark per i deployment self-hosted. Spesso si valuta un drafter solo in base ai token al secondo, ma i numeri di questo test mostrano che l'accettazione e il costo di buffer sono altrettanto decisivi. Sui prompt a lista l'accettazione di DFlash2 è identica a MTP (98%) e il throughput sale del 39%; sul codice l'accettazione scende al 84% rispetto al 94% di MTP, ma la velocità resta più alta. Sulla prosa l'accettazione cala al 64%, e lì il vantaggio si annulla. Non è un difetto: è la prova che i draft head vanno tarati sul tipo di carico, non sull'idea astratta di "modello più veloce".

C'è anche una novità sul fronte multimodale. A differenza di quanto accade con DFlash2 per il modello 3.8 27B, qui i prompt con immagini funzionano. Nei test, i draft con visione abilitata hanno prodotto risposte coerenti e una buona accettazione. Per infrastrutture locali che devono processare documenti, schermate o foto restando dentro un perimetro on-premise, è un segnale tecnico rilevante: il drafter non è più un limite solo testuale, ma può operare anche su input visivi senza uscire dal contesto locale.

Strutturalmente, il caso DFlash2 segnala che il decoding speculativo sta diventando uno dei fronti principali dell'ottimizzazione on-premise. Non si tratta solo di scegliere un LLM più piccolo: l'efficienza dipende sempre più dall'accoppiata modello principale-drafter e dalla qualità dei parametri di accettazione. Per chi gestisce server locali o macchine Apple Silicon, questo sposta l'attenzione dal parametro unico dei token/s al profilo di accettazione per categoria, alla latenza percepita e alla sostenibilità del buffer di calcolo. Inoltre, il calo a 25k contesto mostra che i guadagni della draft non sono garantiti su finestre lunghe: è un vincolo strutturale da inserire nei calcoli di dimensionamento.

La compatibilità con llama.cpp v0.8.0 rende questi test riproducibili senza passare da API cloud. È un punto importante per chi valuta TCO e sovranità dei dati: il salto di throughput può essere misurato su hardware proprio, con GGUFs proprie e con parametri adattati al carico reale. La sezione /llm-onpremise di AI-RADAR offre strumenti analitici per separare, in questi casi, i guadagni reali dai numeri di marketing. Resta il fatto che DFlash2 non elimina il trade-off tra memoria e calcolo; lo sposta.