Il post parte da una domanda semplice: qualcuno usa davvero, in produzione, il livello di reasoning impostato su 'none' per i task agentici? L'autore ammette di essere tentato dall'idea di risparmiare tempo, ma di non averlo mai fatto: si è sempre fermato almeno al livello medio. È una paura che merita di essere presa sul serio, perché tocca un punto centrale delle pipeline agentiche moderne.

In un LLM, il livello di reasoning regola quanta parte della generazione viene dedicata a passaggi intermedi prima dell'azione o della risposta finale. A livello 'none' il modello salta quella fase: produce direttamente l'output operativo, con meno token complessivi e latenza più bassa. Per carichi con molti passaggi, questo può sembrare un guadagno netto. Ma in un agente i passaggi non sono isolati: ogni decisione condiziona la successiva. Senza reasoning, il modello tende a scegliere in base a pattern superficiali, non a un piano. L'errore non resta confinato al singolo step, si propaga.

Il costo invisibile del reasoning a zero

Chi lavora con LLM self-hosted conosce bene il ragionamento in termini di VRAM e TCO. Ogni token di reasoning in più occupa contesto, consuma banda di calcolo e rallenta i loop. È naturale chiedersi se disattivare il reasoning non sia il modo più rapido per ottenere più azioni al minuto sulla stessa macchina. Ma la metrica che conta in un sistema agentico non è il numero di azioni avviate, bensì il numero di azioni concluse correttamente. Un livello 'none' può ridurre il costo marginale del singolo tentativo e aumentare quello dei tentativi falliti, che a loro volta richiedono nuovi passaggi, correzioni manuali o addirittura il fallimento dell'intera pipeline.

Il rischio specifico per i deployment locali

Nei deployment basati su API cloud, il costo del reasoning extra è spesso contabilizzato come spesa variabile e può essere assorbito più facilmente. In un ambiente on-premise o air-gapped, invece, la capacità di calcolo è fissa: se disattivare il reasoning porta a errori che richiedono ricalcoli, il tempo risparmiato sul primo passaggio può essere perso più volte nel recupero. Inoltre, quando i vincoli di sovranità dei dati impediscono di spostarsi su un modello più grande o su un servizio esterno, la robustezza del singolo agente diventa un requisito di sistema, non un parametro secondario. Per chi valuta deployment on-premise, AI-RADAR offre su /llm-onpremise framework analitici per soppesare questi trade-off.

La domanda dell'utente, quindi, non è solo operativa: segnala la mancanza di una tassonomia condivisa per valutare i livelli di reasoning nei workload agentici. Finché il parametro viene trattato come una preferenza personale, il rischio è che i team lo impostino al ribasso per risparmiare sulle bollette e scoprano solo dopo, in produzione, che il costo si è spostato sulla qualità delle decisioni.