llama.cpp ha accelerato di 42 volte la fase di prompt lookup drafting. Il dato arriva dalla community del progetto e va letto con precisione: non è l'inference complessiva a diventare 42 volte più rapida, ma il meccanismo con cui il runtime propone i token candidati quando sfrutta sequenze già presenti nel contesto. È una distinzione decisiva per chi gestisce modelli in locale, perché tocca un collo di bottiglia che spesso sfugge alle metriche di puro throughput.

La decodifica speculativa funziona proponendo più token in blocco e verificandoli in parallelo. Se i candidati sono buoni, il modello accetta più token in un solo passaggio e la generazione accelera. Se sono pessimi, il calcolo aggiuntivo diventa spreco. Il prompt lookup drafting evita di usare un modello separato per produrre le proposte: cerca nel prompt o nell'output già generato pattern ricorrenti e li riusa come draft. È un approccio efficiente quando il testo è ripetitivo, come accade nel codice, nei file di configurazione, nella documentazione tecnica e nelle domande su basi di conoscenza con terminologia stabile.

Il miglioramento segnalato riguarda proprio la velocità di questa ricerca e preparazione dei draft. Renderla 42 volte più rapida significa ridurre il tempo in cui il sistema non sta facendo inference utile, ma sta costruendo ipotesi da verificare. Su hardware self-hosted, dove CPU e GPU condividono un budget termico ed energetico, questo tipo di overhead non è neutrale. Un componente più snello consente di mantenere attiva la decodifica speculativa anche quando il margine di VRAM è ridotto o quando il modello principale è quantizzato in formati compressi. Il punto non è solo la velocità di picco: è la prevedibilità con cui un server locale risponde a richieste ripetute senza saturare le risorse.

La notizia segnala qualcosa di strutturale per chi osserva il deployment on-premise. Negli ultimi anni l'attenzione si è concentrata su modelli più piccoli, quantization spinta e ottimizzazione dei kernel. Questo intervento ricorda che i runtime sono un altro fronte di guadagno. Per le aziende che non possono spostare i dati su cloud pubblici, ogni riduzione dell'overhead si traduce in hardware che dura più a lungo o in requisiti energetici più bassi. Non è un dettaglio: nel calcolo del TCO, l'aspetto meno visibile è spesso quello che decide se un progetto locale resta sostenibile quando il carico cresce.

Per chi valuta deployment on-premise, i trade-off non si limitano alla scelta del modello ma includono l'ingegneria del runtime. AI-RADAR raccoglie framework analitici su /llm-onpremise per valutare questi aspetti, senza trasformare una singola ottimizzazione in una raccomandazione universale. La direzione, però, è chiara: l'ecosistema locale sta rendendo più economica la strada della sovranità dei dati, un'ottimizzazione alla volta.