Un checkpoint sperimentale ribattezzato ThinkingCap-Qwen3.6-27B sta facendo discutere la comunità AI con una promessa tanto diretta quanto allettante: dimezzare i token spesi in ragionamento mantenendo inalterata l’accuratezza del modello base Qwen3.6 da 27 miliardi di parametri. Il claim arriva da un post su Reddit (utente paf1138) e, pur nella sua provvisorietà, tocca un nervo scoperto dell’inference locale: l’efficienza computazionale.

I “token di ragionamento” sono quelli generati durante il chain-of-thought, il monologo interno tramite cui un LLM esplicita passaggi logici, calcoli e verifiche prima di emettere la risposta finale. Ridurli della metà significa, in proporzione, tagliare il tempo di calcolo, la latenza percepita e la pressione sulla VRAM della GPU. Per chi gestisce stack on-premise – dai laboratori air-gapped alle piccole flotte di server aziendali – è una differenza che può fare la differenza tra un servizio interattivo accettabile e uno frustrante, soprattutto con modelli pesanti come quelli della famiglia Qwen.

La valutazione riportata non è superficiale: copre ragionamento multiforme, domande a scelta multipla non basate su reasoning, conversazioni multi-turno quotidiane, aderenza a system prompt, sicurezza, matematica, codice e scenari agentici. Per fronteggiare l’alta variabilità insita nel campionamento a temperatura 1.0 (valore raccomandato da Qwen), i test sono stati ripetuti con semi diversi e accompagnati da test di significatività statistica. I benchmark sono stati suddivisi in porzioni in-domain (parti trattenute dei dataset usati in training) e out-of-domain, un accorgimento metodologico non scontato per chi mette alla prova checkpoint della comunità.

Questo dettaglio è importante perché segnala che la compressione del ragionamento potrebbe essere reale e non un effetto di overfitting. Se il fenomeno venisse confermato da riproduzioni indipendenti, cambierebbe la percezione del rapporto costo-beneficio dei modelli da 27B. Oggi far girare localmente un 27B in FP16 richiede almeno 54 GB di VRAM, costringendo a usare quantizzazioni e a scendere a compromessi sulla precisione. Con un dimezzamento dei token di pensiero, il throughput migliora sensibilmente e il TCO dell’infrastruttura si abbassa, rendendo più plausibile il self-hosting anche per organizzazioni con budget hardware limitati. È la stessa logica che porta molti team a preferire modelli più piccoli ma più veloci: se puoi ottenere la stessa accuratezza con metà token generati, hai di fatto ridotto il divario tra modelli grandi e piccoli senza toccare il numero di parametri.

C’è però un caveat grosso come una casa: tutto questo va verificato. Lo stesso autore originale scrive “to be verified of course but interesting promise”. Non sappiamo se la riduzione del ragionamento sia il frutto di un fine-tuning accidentale o di una tecnica riproducibile, né se si accompagni a un degrado nella qualità delle risposte su casi limite o a un aumento di allucinazioni in domini non testati. Inoltre, la sola metrica di token generati non dice nulla sul consumo energetico reale, che dipende dalla lunghezza totale delle sequenze e dall’efficienza del serving engine.

Per chi valuta deployment on-premise, la vicenda ThinkingCap è comunque un segnale incoraggiante: mostra che la comunità sta iniziando a esplorare non solo quantizzazioni più spinte, ma anche ottimizzazioni sul comportamento generativo dei modelli, un fronte ancora poco battuto dalle grandi aziende. Se la riduzione dei token di ragionamento diventasse una tecnica affidabile, potrebbe accelerare l’adozione di LLM locali in contesti dove la sovranità dei dati e la prevedibilità dei costi sono irrinunciabili. Fino ad allora, rimane un promettente esperimento da tenere d’occhio.