Due varianti dello stesso modello promettono la stessa cosa: tagliare i loop di ragionamento che rendono Qwen3.8-27B famoso per consumare token. ThinkingCap-Qwen3.8-27B e Swift-Qwen3.8-27B lo dichiarano nei rispettivi model card con numeri quasi identici: circa il 40% di token di ragionamento in meno e una degradazione minima della qualità. Il benchmark pubblicato su Reddit con la suite Aider e llama.cpp 0.5.0 in quantization Q8_0, con due run per modello, conferma la promessa sul valore mediano: entrambi i modelli chiudono le prove con circa 5.000 token di completamento in meno rispetto al Qwen3.8-27B di partenza. Ma il dato aggregato racconta solo la prima parte della storia.

Il dettaglio più sorprendente è che ThinkingCap e il Qwen3.8-27B originale ottengono esattamente lo stesso tasso di successo al primo tentativo e al secondo: 27,1% e 77,6%. L'autore della prova precisa di non aver mai visto due run dello stesso modello chiudere con valori identici e invita a trattare il risultato come una coincidenza. Resta però la conferma più netta che il fine-tuning non ha sacrificato la capacità di risolvere i problemi: ha lavorato sul costo del ragionamento, non sul livello assoluto delle risposte.

Swift si muove dentro il margine di rumore: perde due punti percentuali sul secondo tentativo, ma registra il tasso più alto di successo al primo colpo (30,8%). Il suo vantaggio emerge dalla distribuzione dei token. Nei valori mediani consuma circa 7.300 token per completamento contro i 7.436 di ThinkingCap, ma soprattutto non presenta la stessa coda lunga. Nei valori medi, ThinkingCap usa l'8,5% in più di token perché in diversi casi continua a sovra-ragionare in modo significativo. Swift ottiene una riduzione più uniforme. Anche il tempo per caso segue lo schema: Swift chiude in 750 secondi, ThinkingCap in 777, mentre il modello originale richiede 1.481 secondi.

Un altro elemento che separa i due modelli è il comportamento sui casi falliti. Entrambi spendono più token quando non riescono a risolvere un task rispetto a quando lo chiudono con successo, ma la forbice è molto più ampia per Swift: 13,2K token sui fallimenti contro 5,9K sui successi. ThinkingCap si ferma a 9,4K contro 6,8K. In un contesto self-hosted, dove ogni token in più equivale a tempo di GPU e consumo energetico, questa differenza è tutt'altro che accademica: Swift può bruciare più capacità di calcolo nei casi difficili prima di arrendersi, mentre ThinkingCap tende a chiudere prima, che lo si legga come una resa anticipata o come una migliore consapevolezza dei propri limiti.

La vera discriminante arriva dai linguaggi di programmazione. Su C++ ThinkingCap perde otto punti percentuali nel pass al secondo tentativo rispetto a Swift (61,5% contro 69,2%), mentre recupera su JavaScript (85,4% contro 81,2%) e Python (78,8% contro 72,7%). Le differenze sugli altri linguaggi inclusi nella suite Aider non sono statisticamente significative. Questo significa che chi lavora principalmente con un ecosistema specifico potrebbe osservare una resa diversa da quella suggerita dal numero aggregato: i benchmark generalisti rischiano di appiattire un profilo che invece è molto dipendente dal contesto.

ThinkingCap ha anche un primato raro: è l'unico dei tre modelli a produrre il 100% di diff ben formati, senza risposte malformate o errori di output. Per pipeline di sviluppo che integrano il modello in flussi automatici, questo conta quasi quanto la precisione: un diff malformato può spezzare un processo di patch automatico anche quando la soluzione era concettualmente corretta. Gli altri due modelli hanno prodotto alcuni casi di output non validi.

Questa prova segnala un cambiamento più ampio nel modo di valutare i modelli locali. I pass rate da soli non bastano più: due modelli con la stessa capacità possono avere TCO molto diverso in base a token mediani, code lunghe e stabilità dell'output. La riduzione del 40% dichiarata nei model card non è un dettaglio di marketing, ma una variabile operativa concreta per chi ospita il modello su hardware proprio. Il benchmark su llama.cpp con Q8_0 rende il confronto ancora più rilevante per la galassia self-hosted, dove i vincoli di memoria e latenza non sono ammortizzabili da un'infrastruttura cloud elastica.

Per chi deve valutare quale variante adottare in un contesto on-premise, questa storia mostra che i benchmark vanno sezionati per linguaggio, distribuzione dei token e qualità dei diff. Su /llm-onpremise AI-RADAR propone framework analitici per mettere a confronto questi trade-off. Nel frattempo l'autore segnala anche l'uscita di Swift Flash Next, lasciando intendere che il confronto tra varianti derivate da Qwen3.8-27B è destinato a continuare.