Un balzo del 50% nei token al secondo su un MacBook Pro con M3 Max. Non è un nuovo chip, ma una singola modifica al codice di llama.cpp, il motore di inference che alimenta gran parte degli LLM self-hosted. TimNN, con la pull request #22645, ha scovato un punto in cui il campionatore Top-N-Sigma eseguiva un softmax e un ordinamento incondizionati, per poi gettarne via il risultato quando nella pipeline era attivo subito dopo il campionatore Dist.

L’impatto è misurabile: con google_gemma-4-E4B-it-Q8_0, un modello quantizzato a 8 bit per la variante da 4 miliardi di parametri attivi, la velocità passa da circa 30 a circa 45 token al secondo, riducendo il tempo per token di 10 millisecondi. Su hardware consumer, dieci millisecondi a token fanno la differenza tra un’esperienza fluida e una frustrante.

La catena dei campionatori: dove si annida lo spreco

Nell’architettura di llama.cpp, la generazione del prossimo token non è affidata a un unico meccanismo ma a una sequenza di “sampler”, ciascuno dei quali restringe o modifica la distribuzione di probabilità sui token candidati. Top-N-Sigma è uno di questi: seleziona i token la cui probabilità supera una soglia calcolata sulla deviazione standard, ma per farlo ha bisogno di una distribuzione già ordinata. Finora, al termine del proprio lavoro, eseguiva sempre un softmax e un ordinamento completi – operazioni pesanti in termini di calcolo e accesso alla memoria, specialmente su dispositivi senza l’enorme banda di una GPU server.

Il problema è che Top-N-Sigma viene spesso usato in tandem con il campionatore Dist, che applica una distribuzione di temperatura e non richiede quell’ordinamento. Eseguire il softmax alla fine di Top-N-Sigma e poi ricalcolare tutto nel passaggio successivo è come imbiancare una stanza prima di abbattere il muro: lavoro sprecato.

Cosa cambia esattamente nella PR #22645

La modifica introduce un controllo: se il campionatore successivo nella catena è Dist (o comunque un sampler che non sfrutta l’output ordinato), Top-N-Sigma salta il softmax e l’ordinamento finali. Il risultato è un risparmio di calcolo che si traduce in un incremento netto della velocità di inference. Il codice non è ancora stato integrato nel ramo principale e l’autore stesso avverte di non conoscere a fondo il contratto API tra sampler concatenati, lasciando aperta la possibilità di effetti collaterali su configurazioni di campionamento diverse.

L’impatto reale per chi esegue modelli in locale

Per chi adotta stack on-premise – che si tratti di un singolo sviluppatore su un portatile Apple Silicon o di un’organizzazione che mantiene i dati entro i propri server – ogni punto percentuale di efficienza conta. Non si tratta solo di comodità: meno millisecondi per token significano minor consumo energetico sullo stesso carico di lavoro, e la possibilità di usare modelli più grandi o quantizzazioni più conservative senza scendere sotto la soglia di usabilità. Su un MacBook Pro con M3 Max, il guadagno osservato è di 10 ms a token, ma su hardware meno potente o in contesti dove l’inference è moltiplicata per centinaia di richieste, il risparmio aggregato può diventare rilevante.

Inoltre, questa ottimizzazione si inserisce in un filone più ampio: la comunità intorno a llama.cpp sta sistematicamente limando le inefficienze dell’inference locale, avvicinando le prestazioni di hardware consumer a quelle di soluzioni cloud. Ogni miglioramento sposta l’ago della bilancia verso scenari ibridi o interamente self-hosted, dove la sovranità dei dati e la prevedibilità dei costi (TCO) sono prioritarie.

I limiti e le incognite

Non tutti i modelli e tutte le catene di campionamento beneficeranno del cambiamento. Se Top-N-Sigma è usato da solo o accoppiato a sampler che si aspettano una distribuzione già ordinata, saltare il softmax potrebbe rompere la logica di campionamento. L’autore non ha fornito benchmark su altri backend (CUDA, Vulkan, Metal) né su altre architetture di modelli, e la comunità attende test più estesi. Rimane da verificare se il comportamento sia identico su tutti i backend e se la modifica possa essere generalizzata a ogni combinazione di sampler senza effetti avversi.

Quel che è certo è che la direzione tracciata è quella giusta: guardare con attenzione a cosa si butta via nel calcolo, perché l’inference on-premise non può permettersi sprechi. Per chi valuta deployment on-premise, AI-RADAR offre strumenti analitici per confrontare trade-off di prestazioni e costi, proprio a partire da miglioramenti incrementali come questo.