Nel momento in cui integriamo i modelli linguistici tramite API nei nostri sistemi, solitamente tendiamo a valutare il costo in base ai token di input e output visibili: in sostanza la richiesta inviata al modello e la risposta ricevuta dall’applicazione.
Ma con i modelli dotati di reasoning o extended thinking, una parte del consumo può essere meno visibile o in alcuni casi addirittura celata: quella generata dai token di ragionamento, prodotti dal modello prima di formulare l’output finale.
Per un API consumer AI, questa distinzione non è secondaria.
In un prodotto reale, molte interazioni sono semplici: domande di customer service, richieste informative, controlli rapidi, risposte di una sola parola. In questi casi ci si aspetterebbe un consumo proporzionato alla complessità del task.
Le mie rilevazioni su Qwen3.5 mostrano invece un comportamento diverso: anche su prompt elementari, il modello attiva sistematicamente il reasoning e genera un volume di token interni molto superiore alla risposta visibile.
In una mia batteria di test composta da prompt di 8 parole o meno, qwen3.5-plus produce in media 1.204 reasoning token per risposte visibili medie di appena 3,4 token.
In termini operativi, significa arrivare a 354 token di reasoning per ogni token mostrato all’utente, anche quando l’output finale è una risposta minima come “Paris” o “12”.
È qui che il reasoning smette di essere solo una funzione del modello e diventa un fattore diretto di costo, latenza e prevedibilità in produzione. Approfondiamo il tutto, ma prima chiariamo qualche concetto.
Di cosa parleremo..
Che cos’è il Reasoning Runaway
Il reasoning runaway è il comportamento in cui un modello con extended thinking attiva il ragionamento anche quando il compito non lo richiede. Significa che l’IA attiva il “ragionamento” anche quando non parliamo di una risposta complessa, di un problema matematico o di una richiesta che impone passaggi logici articolati. Infatti, mi riferisco a prompt elementari, spesso risolvibili con pochi token, nei quali il modello genera comunque centinaia o migliaia di reasoning token prima di produrre una risposta visibile molto breve.
Nel caso di Qwen3.5, il fenomeno appare sistematico.
Le mie rilevazioni mostrano una percentuale di attivazione del reasoning pari al 100% sui test considerati, sia per qwen3.5-plus sia per qwen3.5-flash.
Questo cosa significa? Significa che il modello non usa il reasoning come risorsa selettiva, attivata solo quando serve, ma come componente ricorrente del processo di risposta.
Per chi consuma il modello via API, il punto è cruciale: il costo reale della chiamata non dipende solo da ciò che l’utente vede, ma anche da ciò che il modello genera prima di arrivare all’output finale.
I miei risultati nella batteria di test sui prompt elementari
Le rilevazioni in analisi si basano su una batteria di test composta da prompt elementari, cioè richieste molto brevi, con risposte semplici e verificabili. L’obiettivo era osservare cosa accade quando un modello viene messo davanti a compiti che non richiedono ragionamenti complessi: domande di conoscenza comune, piccoli calcoli, risposte secche, casi in cui l’output atteso può essere una parola o un numero.
Il confronto è stato eseguito sullo stesso insieme di 200 chiamate triviali per modello. Il punto non era misurare solo se la risposta fosse corretta, ma anche quanti reasoning token venissero generati prima dell’output finale. È qui che il comportamento di Qwen3.5 diventa rilevante: a fronte di risposte visibili medie di appena 3,4 token, il modello produce centinaia o migliaia di token interni anche quando la risposta finale è minima.
Questa la batteria di prompt:
- What is the capital of France? Answer with only the city name, nothing else. < France >>> Paris
- Compute the sum of the two integers provided. Answer with only the resulting number, nothing else. < 7 + 5 >>> 12
- Return the expanded form of the acronym provided. Answer with only the expanded acronym, nothing else. < HTTP >>> HyperText Transfer Protocol
- Answer the factual yes/no question provided. Answer with only “yes” or “no”, nothing else. < Is the sun a star? >>> yes
Ognuno dei prompt è stato applicato in 10 lingue su più modelli.
I numeri che dimostrano il runaway su Qwen
I dati mostrano che il consumo interno di Qwen3.5 non cresce solo in presenza di compiti difficili, ma compare già davanti a richieste elementari.
Nella batteria di test, qwen3.5-plus con reasoning forzato su OFF ha prodotto in media 1.204 reasoning token per chiamata, con una mediana di 346 token e picchi fino a 5.168 token.
Con reasoning forzato su ON, la media è salita solo leggermente, a 1.261 token, con un massimo di 5.345 token.
La differenza tra le due condizioni è minima: il modello continua a generare reasoning anche quando l’impostazione dovrebbe limitarlo.
Il comportamento non riguarda solo la versione più grande. Anche qwen3.5-flash, nella stessa batteria di test, ha prodotto in media 929 reasoning token per chiamata, con una mediana di 580 token e un massimo di 6.054 token.
In tutti i casi, l’attivazione del reasoning risulta pari al 100%, mentre l’output visibile medio resta fermo a 3,4 token. Il dato più diretto è il rapporto tra ciò che viene generato internamente e ciò che viene mostrato: per qwen3.5-plus si arriva in media a 354 reasoning token per ogni token visibile.
E il confronto con gli altri modelli?
Il dato diventa più chiaro quando Qwen3.5 viene confrontato con altri modelli sulla stessa batteria di test. qwen3.5-plus registra una media di 1.204 reasoning token per chiamata e un rapporto di 354 token interni per ogni token visibile.
qwen3.5-flash resta poco sotto, con 929 reasoning token medi e un rapporto di 273:1.
Gli altri modelli osservati si collocano su valori molto più bassi:
gpt-5.4 arriva a 28 reasoning token medi,
deepseek-v4-pro a 91,
deepseek-v4-flash a 49 e
gpt-5.4-nano a 6.
Alcuni modelli, come gemini-2.5-pro, grok-4-1-fast-reasoning e mistral-small-latest, non mostrano reasoning token nella batteria considerata.
Si tratta di una distanza che cambia notevolmente la lettura del fenomeno.
Non siamo davanti a una semplice differenza di efficienza tra modelli, ma a un comportamento distinto: Qwen3.5 genera reasoning in modo molto più esteso anche quando la risposta visibile resta minima.
Sul piano dei costi, la stessa batteria di test produce un consumo stimato di 0,583 dollari per qwen3.5-plus, contro 0,020 dollari per deepseek-v4-pro, 0,004 dollari per deepseek-v4-flash e 0,001 dollari per mistral-small-latest.
Per un API consumer AI, questo divario diventa rilevante quando le chiamate non sono isolate, ma vengono moltiplicate su migliaia o milioni di interazioni.
Perché il toggle non cambia il comportamento?
Uno dei dati più rilevanti riguarda il confronto tra reasoning forzato su OFF e reasoning forzato su ON. In teoria, l’impostazione su OFF dovrebbe ridurre o disattivare il ragionamento interno quando il task non lo richiede.
Nelle rilevazioni su qwen3.5-plus, però, il risultato resta quasi invariato: con OFF il modello produce in media 1.204 reasoning token, mentre con ON arriva a 1.261. La differenza è troppo ridotta per indicare un controllo reale del comportamento.
Si tratta di un punto centrale per chi usa modelli via API. Se il reasoning continua ad attivarsi anche quando viene disabilitato, il consumo non dipende più solo dalla complessità della richiesta o dalle impostazioni scelte dallo sviluppatore.
Diventa una proprietà del modello o del provider. In pratica, l’utente paga un processo interno che non riesce a modulare in modo efficace, anche quando la risposta finale resta composta da pochi token.
Quando poche chiamate fanno esplodere il consumo
Il runaway non emerge solo dalla media. La distribuzione mostra che qwen3.5-plus alterna casi di consumo più contenuto a chiamate in cui il reasoning cresce in modo marcato.
Con reasoning OFF, la mediana nella nostra batteria è di 346 reasoning token, mentre la media sale a 1.204. La distanza tra mediana e media indica che molti casi restano nell’ordine di alcune centinaia di token, mentre una parte delle chiamate entra in una fascia molto più alta, fino a superare i 5.000 reasoning token per una risposta che avrebbe potuto completamente farne a meno (“Qual è la capitale della Francia? Parigi”).
Sul piano operativo, il dato più critico è il p95 (95° percentile), cioè il valore sotto cui resta il 95% delle chiamate. Nel test, il p95 arriva a 3.668 reasoning token con OFF e a 4.049 reasoning token con ON. In pratica, significa che una quota ridotta ma ricorrente di richieste genera un consumo interno molto superiore alla risposta visibile. Per un sistema in produzione, picchi simili rendono più difficile stimare il costo per chiamata, fissare soglie di budget e garantire tempi di risposta costanti.
Quali sono le possibili cause del comportamento di Qwen?
Le mie rilevazioni ovviamente non mi consentono di stabilire con certezza perché Qwen3.5 generi così tanti reasoning token su compiti semplici, ma è possibile fare qualche ipotesi.
La prima riguarda una possibile impostazione aggressiva del servizio: il modello potrebbe essere configurato per attivare il reasoning come modalità predefinita su quasi ogni prompt, anche quando la richiesta non lo richiede. Il fatto che reasoning OFF e reasoning ON producano valori medi molto simili rende tale spiegazione compatibile con i dati.
Una seconda ipotesi riguarda l’architettura o il fine-tuning del modello. Il reasoning potrebbe essere integrato nel processo generativo, senza una separazione netta tra fase di ragionamento e fase di risposta.
Il modello potrebbe aver appreso durante l’addestramento che rispondere correttamente significa produrre catene di pensiero estese.
In entrambi i casi, il risultato operativo non cambia: anche davanti a prompt banali, Qwen3.5 tende a generare ragionamento interno in modo ricorrente, con un consumo di token non proporzionato alla risposta finale.
Il costo nascosto può essere un problema per chi usa modelli via API
Per un API consumer AI, il consumo di reasoning non è solo un dettaglio tecnico. Ogni token generato dal modello può incidere sul costo finale della chiamata, anche quando non compare nella risposta mostrata all’utente.
Nella batteria di test, qwen3.5-plus arriva a un costo stimato di 0,583 dollari per 200 richieste elementari, mentre modelli come deepseek-v4-flash e mistral-small-latest restano rispettivamente a 0,004 e 0,001 dollari sullo stesso insieme di prompt.
La differenza diventa rilevante quando un’applicazione gestisce molte interazioni semplici: assistenza clienti, FAQ, classificazioni rapide, controlli di stato, risposte operative. In scenari simili, l’utente si aspetta che il costo cresca in modo proporzionato alla complessità della richiesta.
Se invece una risposta di pochi token attiva centinaia o migliaia di reasoning token, il prezzo reale della chiamata può diventare molto diverso da quello previsto in fase di integrazione.
Il problema della latenza dovuta al reasoning
Oltre al costo, il reasoning incide notevolmente anche sui tempi di risposta, questo perché generare 1.200, 3.000 o più di 5.000 reasoning token prima dell’output finale può rallentare non poco la risposta percepita dall’utente.
Per un prodotto basato su API, tale aspetto pesa soprattutto nelle interfacce conversazionali, dove l’utente si aspetta risposte rapide anche a domande semplici. Una richiesta elementare che produce una risposta finale di pochi token non dovrebbe introdurre tempi di attesa elevati.
In alcune chiamate Qwen ha richiesto anche 22 secondi per processare e fornire una risposta, un’eternità considerando la batteria di domande estremamente semplici.
Quando il modello genera molto reasoning interno, la latenza può diventare un fattore da misurare con attenzione, insieme al costo per chiamata.
Perché il runaway rende difficile pianificare i consumi?
Il problema non riguarda solo il costo medio di una chiamata.
In produzione conta anche la possibilità di prevedere il consumo entro margini ragionevolmente stabili. Per questo nel settore si usano i tokenizer, cioè strumenti che riproducono la segmentazione del testo in token secondo le regole del modello usato. In questo modo è possibile stimare, almeno in modo orientativo, quanti token verranno consumati in input, facilitando la previsione dei costi operativi.
Le rilevazioni su Qwen3.5 mostrano invece una variabilità marcata: alcune richieste restano su poche centinaia di reasoning token, mentre altre superano diverse migliaia, pur partendo da prompt elementari e producendo risposte visibili minime.
Per chi integra modelli via API, una variabilità simile complica la gestione di budget, soglie di utilizzo e SLA. Un sistema può risultare sostenibile sulla media, ma diventare meno controllabile quando una parte delle chiamate genera picchi di reasoning. In applicazioni con volumi elevati, anche una quota ridotta di richieste fuori scala può incidere sul costo complessivo e sulla stabilità del servizio.
Quindi non ha mai senso usare Qwen3.5?
Le rilevazioni non portano a escludere Qwen3.5 in ogni scenario. Un modello che genera molto reasoning può avere senso quando il compito richiede davvero passaggi logici articolati, analisi multilivello, verifica di alternative o decisioni in cui il costo aggiuntivo è compensato dal risultato. In casi simili, il consumo interno può essere parte del valore prodotto dal modello.
Il punto critico emerge quando lo stesso comportamento compare su richieste semplici.
Per attività come risposte secche, FAQ, classificazioni rapide o micro-task operativi, il rapporto tra reasoning token e output visibile diventa difficile da giustificare.
Alla luce dei dati disponibili, Qwen3.5 appare più adatto a contesti in cui il reasoning è una necessità del task, non a flussi API composti in larga parte da interazioni elementari.
