AI locale: la qualità si progetta anche nell’inferenza

La qualità di un sistema AI locale dipende anche dalle risorse che assegniamo a ogni richiesta. Un modello può entrare nella memoria di una workstation e richiedere comunque tempi di elaborazione o quantità di contesto incompatibili con il lavoro previsto. Tra riuscire a eseguirlo e utilizzarlo con efficacia c’è una decisione progettuale.

Immaginiamo un assistente incaricato di correggere un errore software. Generare una modifica plausibile è una parte del compito. Deve individuare i file pertinenti, interpretare le dipendenze, eseguire i test e capire se la correzione introduce una regressione. La velocità con cui produce testo conta, ma il risultato dipende dalla possibilità di completare questo percorso.

È qui che può emergere la distanza tra un modello competitivo nei benchmark e un’installazione locale deludente. I pesi possono appartenere alla stessa versione, mentre cambiano il budget di ragionamento, la precisione numerica, il contesto disponibile e gli strumenti. La capacità misurata nel benchmark diventa utile soltanto se il sistema riesce a sostenerne le condizioni di utilizzo.

Lo stesso modello, scelte di esecuzione diverse

Un esempio documentato è la famiglia Qwen3 presentata nell’aprile 2025. Il team descrive due modalità integrate nello stesso modello: thinking, che genera passaggi di ragionamento prima della risposta finale, e non-thinking, che risponde direttamente. Nelle valutazioni pubblicate, mostra inoltre come le prestazioni possano migliorare all’aumentare del budget dedicato al ragionamento. Sono risultati del produttore su specifiche valutazioni, non una misura delle prestazioni di qualsiasi workstation. Il punto rilevante è il meccanismo: la quantità di calcolo utilizzata durante l’inferenza contribuisce al risultato, anche senza cambiare i pesi. (Fonte: Qwen)

La distinzione è concreta anche nell’interfaccia. La model card di Qwen3-32B documenta il parametro enable_thinking, che permette di attivare o disattivare quella modalità nel template della conversazione. Separatamente, il limite di generazione determina quanti nuovi token il modello può produrre. Modalità di ragionamento e budget massimo sono quindi controlli diversi. (Fonte: model card Qwen3-32B)

Questo esempio non dimostra che dedicare più calcolo migliori ogni risposta. Dimostra perché scegliere il modello non esaurisce la scelta del sistema.

Per estrarre date e importi da un documento ben strutturato può essere sufficiente una risposta diretta, verificata rispetto al testo originale. Per analizzare un errore che coinvolge più componenti può essere utile lasciare spazio a un’elaborazione più estesa. Applicare la stessa configurazione a entrambi i casi significa ignorare la differenza tra i lavori.

La domanda operativa diventa: su quali compiti il calcolo aggiuntivo produce un miglioramento che giustifica l’attesa?

Dal punteggio alle condizioni che lo rendono possibile

Un benchmark condensa una valutazione in un numero. Per trasferire quel risultato a un’applicazione occorre recuperare ciò che il numero riassume: versione del modello, modalità di esecuzione, budget di generazione, contesto e criteri di valutazione. Nei compiti agentici entrano in gioco anche strumenti, tentativi consentiti e modalità di interazione con l’ambiente.

Ridurre il budget per rendere una dimostrazione più rapida può essere una scelta sensata. Cambia però il sistema che stiamo valutando. Lo stesso vale quando utilizziamo pesi quantizzati o una finestra di contesto più piccola.

Per chi progetta un’applicazione, il benchmark dovrebbe quindi servire a selezionare candidati da provare. La decisione finale richiede un confronto sul lavoro reale.

Nel caso dell’assistente software, il criterio non è quanto convincente appaia la spiegazione della patch. È se la modifica risolve il problema, supera le verifiche pertinenti e rispetta i vincoli del progetto. Una risposta fluida può fallire tutti questi requisiti. Una risposta più lenta può soddisfarli, ma il beneficio va misurato.

La prestazione da acquistare o costruire è il risultato verificato, entro un tempo accettabile.

Ragionamento e contesto condividono lo stesso vincolo hardware

Su una GPU con 16 GB di VRAM, il primo controllo è spesso la dimensione dei pesi. È necessario, ma lascia aperta la domanda più importante: quanta memoria resta per eseguire il lavoro?

Oltre ai pesi, l’inferenza richiede memoria per il runtime, i buffer di calcolo e la gestione del contesto. Nei comuni Transformer autoregressivi, la KV cache conserva informazioni utilizzate dall’attenzione per evitare di ricalcolarle a ogni token. Il suo consumo dipende dall’architettura, dalla precisione e dalla lunghezza della sequenza gestita. La documentazione di Hugging Face distingue strategie di cache orientate a compromessi diversi tra memoria e velocità. (Fonte: Hugging Face)

Torniamo all’assistente che corregge il bug. All’inizio riceve una descrizione breve. Poi legge il codice, acquisisce l’output dei test e confronta nuove informazioni con quelle già raccolte. La sessione cresce mentre il lavoro procede.

Se il sistema perde informazioni necessarie, può proporre una soluzione incompatibile con un vincolo letto in precedenza. Se dedica troppo spazio a contenuti irrilevanti, consuma risorse senza aiutare la decisione. Se interrompe la generazione prima della risposta completa, l’elaborazione già svolta può non tradursi in un risultato utilizzabile.

Ragionamento e contesto vanno quindi dimensionati insieme. Uno offre spazio all’elaborazione; l’altro rende disponibili le informazioni su cui elaborare.

La quantizzazione può ridurre l’occupazione dei pesi e lasciare più memoria al resto dell’esecuzione. È una leva utile, da valutare sul compito e sulla configurazione scelta. Anche un modello più piccolo può essere una soluzione migliore se consente di sostenere l’intera sessione con qualità sufficiente.

La configurazione utile è quella che porta il lavoro fino alla verifica, non quella che occupa tutta la memoria disponibile.

Il tempo di risposta è un requisito di progetto

Un assistente utilizzato durante una conversazione e un agente che prepara un’analisi in background hanno esigenze differenti. Nel primo caso l’attesa interrompe l’interazione. Nel secondo può essere accettabile dedicare più tempo a un’elaborazione, purché il risultato arrivi entro la scadenza prevista.

Questa differenza dovrebbe precedere la scelta dei parametri.

Se l’applicazione deve aiutare uno sviluppatore durante una modifica, conta quanto spesso ne interrompe il lavoro. Se deve esaminare un insieme di documenti durante la notte, contano maggiormente completezza, capacità di elaborazione e gestione degli errori. Il modello potrebbe essere lo stesso; la configurazione e i criteri di successo no.

I token al secondo descrivono soltanto una parte di questa esperienza. Il tempo complessivo comprende l’elaborazione dell’input, la generazione, le chiamate agli strumenti, i test e gli eventuali tentativi successivi. A questi si aggiunge il tempo umano necessario per controllare o correggere il risultato.

Anche il fallimento ha una durata. Un agente che continua a ripetere tentativi improduttivi può consumare più risorse di uno che riconosce presto un limite. Timeout e criteri di interruzione sono quindi parte della qualità del servizio: permettono di cambiare approccio quando l’elaborazione non produce nuove evidenze.

Il budget di ragionamento va trattato come una risorsa da assegnare. Aumentarlo ha senso quando migliora abbastanza la probabilità di completare correttamente il compito.

Valutare una configurazione significa valutare una decisione

Per scegliere in modo fondato serve un insieme di compiti rappresentativi, accompagnati da criteri di accettazione. Nel caso del codice, test pertinenti e revisione delle modifiche. Nell’analisi documentale, riscontri sui documenti originali. Nell’estrazione di dati, controlli sui valori e sulla struttura dell’output.

Su questi compiti si possono confrontare configurazioni diverse, registrando correttezza, tempo totale, consumo di memoria e intervento umano. Modello, quantizzazione, runtime e parametri devono rimanere identificabili, così da rendere interpretabili i risultati e ripetibile il confronto.

La scelta può portare a più profili di esecuzione: uno rapido per richieste circoscritte, uno più impegnativo per problemi complessi, un percorso alternativo per i casi che superano le risorse disponibili. Non occorre introdurre subito un sistema di selezione automatica. Anche una distinzione esplicita tra tipi di lavoro può essere sufficiente per evitare che ogni richiesta riceva lo stesso trattamento.

Questo approccio cambia anche il confronto tra locale e remoto. La domanda diventa quale ambiente soddisfi i requisiti del compito, considerando dati, risorse, latenza e costi operativi. L’esecuzione locale è una possibilità architetturale da valutare, non un obiettivo da imporre a ogni carico.

Dal controllo dei pesi al controllo del servizio

Il valore dell’AI locale consiste anche nella possibilità di scegliere versioni, configurazioni e condizioni di esecuzione. È un controllo concreto, ma diventa un vantaggio professionale quando permette di costruire un servizio dal comportamento conosciuto.

Un’organizzazione può accettare un modello meno capace in termini assoluti se completa bene un compito delimitato, nei tempi richiesti e con verifiche adeguate. Può invece scartare un modello meglio posizionato nei benchmark se il costo operativo per raggiungere quella qualità è incompatibile con l’applicazione.

Progettare l’inferenza significa decidere quali capacità rendere disponibili, per quali lavori e a quali condizioni. È in questa scelta che un modello scaricato diventa un sistema utilizzabile: non perché riproduce una classifica sulla propria workstation, ma perché offre risultati sui quali è possibile costruire un processo di lavoro.