Un singolo esperimento su un modello Qwen da quattro miliardi di parametri riapre una questione centrale per chi esegue LLM in locale: quanto pesano i token di esitazione sull'accuratezza e quanta parte del danno può essere recuperata senza fine-tuning. Il test parte dal paper di Meta (arXiv 2606.00206) e applica un logit-bias ai token che indicano ripensamenti («wait», «maybe», «perhaps», «however», «alternatively», «wrong», «error» e molti altri). Su 50 domande casuali di MATH-500, l'accuratezza migliora in tutti i livelli di quantization GGUF analizzati.

I numeri vanno letti con cautela. In BF16 si passa dal 74% all'84% con una riduzione del 19,4% dei token di reasoning. Q8_0 sale dal 76% all'80%, Q4_K_M dal 60% al 66%, Q3_K_M dal 52% al 66%, Q2_K dal 12% al 24%. Non è una curva uniforme: il guadagno più netto in termini relativi è su Q2_K, il livello di quantization più aggressivo, il cui risultato raddoppia. Il caso di Q3_K_M è interessante perché con la penalizzazione supera il Q4_K_M senza penalizzazione, almeno su questo campione.

Qui sta il punto strutturale. Penalizzare l'overthinking non tocca i pesi del modello, non richiede GPU con grandi quantità di VRAM e non introduce dipendenze cloud. È un intervento di inference-time che agisce sulla distribuzione dei token in uscita. Per lo scenario self-hosted — dove llama.cpp e i formati GGUF sono di fatto uno standard per l'inference locale — questo tipo di leva può ridurre il costo computazionale senza cambiare hardware. Meno token di reasoning generati significano meno step di calcolo e una latenza potenzialmente più bassa, un fattore rilevante quando il modello gira su macchine con memoria condivisa o su GPU consumer. Anche in un'ottica di TCO, ridurre la quantità di token prodotti senza cambiare modello o hardware ha un valore diretto.

Il rovescio della medaglia è altrettanto chiaro. Il test usa un solo modello, 50 domande e una lista di token decisa a monte. Non è possibile parlare di significatività statistica con un solo test su un solo modello, e il risultato potrebbe non replicarsi su altri benchmark, altre famiglie di modelli o altri task. Inoltre, un logit-bias fisso sui marker di esitazione può avere effetti collaterali: penalizzare «but», «or» o «however» può aiutare in un compito matematico ma ridurre la capacità di produrre ragionamenti condizionali in contesti linguistici o creativi. La scelta degli ID dei token dipende dal tokenizer e richiede attenzione: i valori vanno verificati rispetto al vocabolario del modello in formato GGUF.

Per chi valuta deployment on-premise, il segnale è duplice. Da un lato, i risultati mostrano che la scelta del livello di quantization non è solo un compromesso tra precisione numerica e risparmio di memoria: anche il comportamento dei token di ragionamento gioca un ruolo. Dall'altro, interventi come il logit-bias sono economici e replicabili nel contesto di llama.cpp, ma vanno testati sul proprio dominio prima di considerarli parte della pipeline. L'esperimento di am17an non è una raccomandazione, ma un invito a misurare: su un campione piccolo ha funzionato, su scala reale servono dati più solidi.