L’IA agentica incontrerà un limite infrastrutturale prima di raggiungere un limite di intelligenza

I modelli migliorano più rapidamente della nostra capacità di fornire ciò che viene chiesto loro.

Gran parte del dibattito sul futuro degli agenti IA riguarda le loro capacità. Il modello è in grado di pianificare in modo affidabile? Sa rimediare ai propri errori? Ci si può fidare ad affidargli un’azione con conseguenze?

Sono domande reali. Ma non saranno queste a determinare se gli agenti verranno adottati su larga scala nei prossimi anni, perché c’è un vincolo più immediato, che si sta manifestando più rapidamente. È economicamente oneroso erogare servizi agli agenti, e il problema si aggrava proprio con le capacità che tutti vogliono aggiungere.

Un chatbot e un agente comportano carichi di lavoro diversi

Una richiesta conversazionale consiste in un unico scambio: si invia il prompt, si ricevono i token e la connessione si chiude. È possibile elaborare le richieste in batch, memorizzare nella cache il prefisso e ragionare sul throughput usando un solo valore.

Una richiesta a un agente è una sessione. L’agente chiama uno strumento, attende, legge il risultato, decide cosa fare dopo, chiama un altro strumento e infine risponde. Un’attività relativamente semplice può richiedere sei o otto invocazioni del modello, con attese tra l’una e l’altra.

Questa differenza è importante per un motivo che non ha nulla a che fare con l’intelligenza. Tra un passaggio e l’altro, l’agente mantiene uno stato: la conversazione, i risultati degli strumenti e il ragionamento accumulato. Durante l’erogazione, questo stato risiede nella memoria della GPU sotto forma di cache KV e occupa memoria per tutta la durata della sessione, compresi i secondi che l’agente trascorre in attesa di un’API che non è la tua.

L’unità di misura della capacità non è più quindi il numero di «richieste al secondo», ma il numero di «sessioni simultanee residenti in memoria». Un sistema che gestiva comodamente mille richieste conversazionali al secondo potrebbe essere in grado di gestire solo alcune decine di sessioni simultanee di agenti sullo stesso hardware.

L’attesa è la parte più costosa

Ecco l’aspetto scomodo: durante una chiamata a uno strumento, l’agente non fa nulla. Non genera token e non consuma risorse di calcolo. La memoria della GPU, però, resta occupata, perché liberare quel contesto e ricalcolarlo costerebbe più che mantenerlo.

L’hardware più costoso resta riservato a una richiesta che, in quel momento, è in attesa di una query al database.

Nei sistemi distribuiti tradizionali abbiamo risolto questo problema molto tempo fa: si rilascia la risorsa e si riprende il lavoro quando arriva la risposta. Fare lo stesso per l’erogazione dei modelli significa trasferire la cache KV nella memoria host o su disco e poi ripristinarla; il costo del trasferimento è così elevato che la maggior parte dei sistemi non lo fa. La ricerca proprio su questo è in pieno svolgimento, proprio perché il problema è costoso.

L’esecuzione sequenziale peggiora la situazione più del necessario

Quasi tutti i framework per agenti eseguono le chiamate agli strumenti una dopo l’altra. Il modello chiede di cercare le previsioni del tempo, le riceve, chiede di controllare il calendario, riceve il risultato e poi chiede di cercare un volo, che trova.

Spesso queste tre chiamate non dipendono l’una dall’altra. Potrebbero essere eseguite contemporaneamente. Se vengono eseguite in sequenza, la latenza è la somma dei tempi; se vengono eseguite in parallelo, corrisponde al tempo della chiamata più lunga.

Non è un’osservazione nuova sugli agenti: è lo stesso principio strutturale che vale per qualsiasi sistema in cui più modelli o servizi operano entro un unico budget di latenza. La latenza totale dovrebbe corrispondere al percorso più lungo nel grafo delle dipendenze, non alla somma di tutte le fasi. Questo aspetto è ancora più importante per gli agenti perché la sessione resta nella memoria della GPU per tutta la sua durata: ridurre il tempo effettivo non migliora soltanto l’esperienza dell’utente, ma aumenta direttamente il numero di sessioni gestibili dall’hardware.

Dimezzando la durata delle sessioni, si raddoppia all’incirca la capacità simultanea, con le stesse GPU e senza modificare il modello.

I nuovi tentativi si moltiplicano in modi che nessuno aveva previsto

I framework per agenti ereditano le impostazioni predefinite per i nuovi tentativi dalle librerie HTTP sottostanti. In genere, sono previsti tre tentativi.

Anche il modello riprova, a modo suo. Quando uno strumento restituisce un risultato poco utile, un modello di ragionamento spesso tenta un approccio diverso: è un nuovo tentativo, anche se nessuno lo ha configurato.

Combinando i due comportamenti, una politica che prevede tre tentativi, applicata a un modello che autonomamente elabora altri tre approcci, diventa una politica da nove tentativi che nessuno ha mai definito. Ognuno di questi tentativi comporta un’invocazione completa del modello, con i relativi token e secondi di utilizzo della GPU.

Quando una dipendenza rallenta, è questa amplificazione a trasformare un peggioramento delle prestazioni in un’interruzione del servizio; inoltre, il costo di ogni tentativo è di ordini di grandezza superiore a quello di una chiamata REST ripetuta.

Come si manifesta davvero il limite

Non è un limite delle capacità. È qualcosa di più prosaico: un problema di sostenibilità economica che blocca i progetti nel passaggio dalla fase pilota alla produzione.

Il progetto pilota funziona. Gli utenti sono dieci, la latenza è accettabile e la fattura è trascurabile. Poi qualcuno fa una stima per diecimila utenti e il fabbisogno di GPU risulta irrealistico, non perché il modello sia lento, ma perché ogni sessione simultanea occupa memoria per tutta la sua durata, compresi i tempi di attesa.

È in questa fase che molte promettenti demo interne si fermano senza clamore.

Cosa fa arretrare il limite

Nulla di esotico, e tutto rientra nell’infrastruttura, non nella modellazione:

Eseguire in parallelo chiamate a strumenti indipendenti. Il maggiore singolo vantaggio disponibile oggi, che non richiede nuovo hardware.

Considerare la durata della sessione come metrica di capacità. Non i token al secondo. Non l’utilizzo della GPU. Conta quanto a lungo lo stato rimane in memoria e quante sessioni possono coesistere.

Stabilire il budget dei tentativi a livello di sistema, anziché per singola chiamata. Un limite globale — con i nuovi tentativi fissati a una piccola percentuale del traffico totale — evita l’effetto cumulativo descritto sopra. Le pratiche SRE di Google per gestire il sovraccarico e i budget di nuovi tentativi di Envoy applicano entrambe questa idea al di fuori dello stack IA.

Separare il ragionamento dall’esecuzione. Un modello grande per pianificare, uno molto più piccolo per i passaggi meccanici. La maggior parte delle attività svolte da un agente non richiede un modello all’avanguardia.

Rendere poco costoso l’abbandono del contesto. Cache KV quantizzata, attenzione paginata e percorsi di scaricamento per le sessioni inattive. È qui che si concentra oggi il lavoro più interessante sull’inferenza in produzione.

I modelli continueranno a migliorare. Su questo si può contare. Che gli agenti diventino infrastruttura o restino demo dipende da qualcosa di meno appariscente: se riusciremo a gestire un carico di lavoro che mantiene in memoria risorse costose mentre è in attesa e se smetteremo di pagare la somma dei tempi di una sequenza quando potremmo pagarne il percorso più lungo.

Ho pubblicato il modello di esecuzione alla base di quest’ultimo punto — l’esecuzione concorrente di chiamate a modelli dipendenti tra loro entro un unico budget di latenza — in «Esecuzione asincrona di grafi di inferenza per l’instradamento dei modelli nei sistemi di apprendimento automatico», International Journal of Computer Trends and Technology 72(10), ottobre 2024. Per approfondire l’integrazione dei modelli generativi nei sistemi decisionali soggetti a vincoli di latenza, si veda «Piattaforme di trading e decisionali potenziate dagli LLM: collegare l’intelligenza generativa ai sistemi decisionali finanziari», Journal of Information Systems Engineering and Management 11(1s), 2026.