Insights28/8/2026

Oltre l'Inference Ceiling: come gestire il costo dei token e rendere sostenibile un progetto di agentic AI

Articolo a cura di

Silvia Flacchi

Project Leader

Articolo a cura di

Mattia Ciriolo

Software Architect

Il riflesso comune, quando un progetto di intelligenza artificiale generativa scala, è pensare che valgano le stesse regole del cloud. La prassi classica ci dice che, finché non cambiano infrastruttura e architettura, il costo marginale di ogni nuovo cliente tende a zero; una volta raggiunto il limite di risorse, lo scaling orizzontale resta relativamente economico, perché aggiunge CPU, RAM, storage e traffico di rete, componenti a basso costo unitario.

Chi ragiona così sta applicando al posto sbagliato una legge che in vent'anni di cloud computing abbiamo imparato a dare per scontata. Nell'agentic AI la logica cambia: ogni inferenza consuma calcolo GPU reale, e le GPU sono oggi una risorsa scarsa e costosa. Di conseguenza il costo cresce con l'utilizzo , e ad alti volumi la crescita può fermarsi per motivi economici prima ancora che per motivi tecnici. Questo fenomeno si chiama inference ceiling, ed è il primo concetto che qualunque organizzazione dovrebbe mettere sul tavolo, non a metà progetto ma dal primo giorno di un pilot.

Per chiarire i termini: l'inferenza è il processo con cui un LLM applica la conoscenza acquisita in addestramento per elaborare una richiesta e generare una risposta. L'inference ceiling, invece, è il punto in cui il costo marginale di ogni nuova inferenza rende insostenibile la crescita del servizio.

Il problema: si sa quanto si spende, non quanto conviene

Il sintomo ricorrente in chi porta un assistente basato su agenti oltre il proof of concept è sempre lo stesso: si conosce la fattura mensile del cloud provider, ma non si sa scomporla per singolo caso d'uso di business. In un progetto che abbiamo seguito di recente in ambito turistico, un assistente conversazionale che genera itinerari di viaggio personalizzati per agenzie e back-office booking, la domanda che ha davvero cambiato la conversazione con il cliente non era "quanto stiamo spendendo in token", ma "quanto ci costa generare un itinerario completo, e quel costo è più basso o più alto del valore che genera?". È una domanda a cui nessuna dashboard standard del cloud provider può rispondere, perché nessun provider sa cosa significhi, per quel cliente, un "business task completo": nel caso citato, circa venti chiamate a modello orchestrate da una decina di agenti specializzati, per portare l'utente dalla richiesta al preventivo pronto.

La domanda giusta, però, non riguarda solo il controllo: riguarda il valore. Definire insieme agli esperti di business del cliente il caso d’uso permette di confrontare il costo del sistema agentico con il costo del processo che sostituisce: tempi di lavorazione, qualità dell’output, carico degli operatori. Fatto prima, e non a consuntivo, questo confronto tiene ingaggiati sponsor e stakeholder sulla bontà dell’investimento, e sposta la domanda da “quanto costa” a “quanto conviene”.

Il dato che quantifica il problema

Non è un caso isolato: secondo il State of FinOps 2026 della FinOps Foundation, la quota di team che gestisce attivamente la spesa AI è passata dal 31% al 98% in due anni, e il 73% delle organizzazioni ha visto i costi AI superare il budget pianificato: un salto di scala compresso in tempi troppo brevi perché la disciplina di governo si sia consolidata di pari passo.

La prospettiva di adesso.it: previsione e controllo non sono la stessa cosa

Non è un caso isolato: secondo il State of FinOps 2026 della FinOps Foundation, la quota di team che gestisce attivamente la spesa AI è passata dal 31% al 98% in due anni, e il 73% delle organizzazioni ha visto i costi AI superare il budget pianificato: un salto di scala compresso in tempi troppo brevi perché la disciplina di governo si sia consolidata di pari passo.

In fase di Fattibilità (il classico POC) i costi non rappresentano ancora un tema centrale: si valida solo se il caso d'uso funziona, tipicamente con modelli di frontiera e dei KPI di task success rate. È in fase di Sostenibilità (il pilot) che si comincia a costruire un vero impianto di misurazione (allocazione dei costi per prompt e per business task, non solo per progetto), e a definire soglie finanziarie credibili. La fase di Affidabilità (produzione) introduce SLA, alerting e quota management. La fase di Portafoglio, la più nuova e meno esplorata dal mercato italiano, riguarda la razionalizzazione dei costi quando più iniziative AI condividono le stesse risorse riservate, un livello di ottimizzazione che nessun singolo progetto può raggiungere da solo.

Il motore di simulazione che rende operativa la fase di Sostenibilità

Per rendere concreta la fase di Sostenibilità, in adesso.it abbiamo sviluppato un notebook interattivo di simulazione dei costi: non un cruscotto statico, ma una libreria modulare che si adatta scenario per scenario, cliente per cliente. Lo strumento parte dalle curve di utilizzo reali del sistema che si sta valutando: dati orari sull'intero anno, più una settimana campione a dettaglio di singolo minuto, sufficiente a far emergere pattern intraday specifici del business (in un progetto che abbiamo seguito, ad esempio, un calo di utilizzo a metà mattina legato alle pause degli operatori).

Su questa base applica ipotesi di conversione e di cambio d'uso per simulare la domanda futura, confrontando scenari di sola capacità a consumo con scenari ibridi a capacità riservata: in uno dei casi in cui lo abbiamo applicato, acquistare capacità riservata per l'intero anno copriva il 74% del tempo, lasciando il restante 26% a consumo, e più capacità si acquistava, più calava il tasso di utilizzo effettivo, non il contrario. È esattamente il tipo di confronto strutturato tra business e tecnologia che nessuna dashboard standard del provider offre. Lo stiamo costruendo come asset ripetibile, non come artefatto legato a un solo cliente: la prima versione è stata realizzata in meno di una settimana con tecniche di sviluppo assistito da agenti, ed è pensata per estendersi ad altri provider cloud e ad altri domini di business.

Il secondo pattern riguarda la scelta del modello, ed è probabilmente il dato più sorprendente che abbiamo osservato: nello stesso progetto, lo stesso budget di capacità riservata che serve quindici richieste in contemporanea con un modello di fascia media ne serve appena una o due con un modello di fascia alta (Figura 3).

Per leggere il confronto servono tre termini. Le API a consumo fatturano per token usato, senza garanzie di priorità in caso di congestione. Le API a consumo con priorità aggiungono una corsia riservata a fronte di un costo per token più alto. Le PTU (Provisioned Throughput Units), invece, sono capacità riservata: si acquista in anticipo un blocco fisso di throughput, a costo prevedibile e senza fattura per singolo token.

Tale soluzione è il cuore della value proposition Scaling AI: non basta "aggiungere un LLM a una feature", bisogna costruirla con fine-tuning, orchestrazione multi-agente e un modello dimensionato sul task, così da abbattere il costo marginale di uno o due ordini di grandezza e rendere pensabili scenari altrimenti insostenibili economicamente (nel caso citato, l'eventuale futura estensione a un pubblico consumer molto più ampio). Lo stesso vale per il trade-off tra capacità riservata e consumo a token: comprare più capacità riduce il costo per richiesta, ma può far scendere il tasso di utilizzo effettivo della capacità riservata fino all'11% (contro il 43% osservato con una capacità inferiore, dati riferiti al caso citato internamente).

Il terzo pattern, quello su cui i clienti insistono di più negli steering, è la differenza tra previsione e controllo: sapere in anticipo quanto costerà un flusso agentico non è la stessa cosa che sapere in tempo reale quanto si sta effettivamente spendendo, incrociato con i task realmente completati. Il mercato italiano tende a confondere le due cose, o a presentare strumenti di previsione come se fossero controllo.

Cosa fare, concretamente

Calcolare il costo per business task, non per progetto. Isolare il costo end-to-end di completare un caso d'uso reale (non un singolo prompt) e usarlo come unità di misura in ogni conversazione con il business.
Verificare l'inference ceiling prima di scalare, non dopo. Prima di allargare un pilot, stimare a quale volume di utenti concorrenti il costo marginale dell'inferenza rende il servizio economicamente insostenibile con il modello attuale.
Distinguere esplicitamente, nel proprio stack, previsione e controllo. Se lo strumento in uso risponde solo a "quanto spenderemo", va integrato separatamente con una misurazione di "quanto stiamo spendendo davvero e su cosa".

Domande frequenti

1.Cos'è l'inference ceiling in un progetto di agentic AI?

È il punto in cui il costo marginale di ogni nuova inferenza — che, a differenza del cloud tradizionale, non tende a zero ma scala in base al calcolo con il calcolo GPU utilizzato — rende insostenibile economicamente la crescita del servizio prima ancora che tecnicamente. Va stimato il prima possibile nel ciclo di vita del progetto, idealmente già in fase di proof of concept.

2.Conviene di più un modello grande o uno piccolo per un progetto agentico in produzione?

Dipende dal task, ma nella nostra esperienza un modello più piccolo, affiancato da fine-tuning e orchestrazione multi-agente ben progettata, può servire un numero di richieste concorrenti superiore di un ordine di grandezza rispetto a un modello di fascia alta, a parità di budget di capacità riservata.

3.Qual è la differenza tra previsione e controllo dei costi AI?

La previsione stima quanto costerà un flusso agentico prima o durante il progetto, su base statistica e storica. Il controllo misura in tempo reale quanto si sta effettivamente spendendo, incrociando i costi sostenuti con i task realmente completati. Sono due capacità distinte, spesso vendute o confuse come se fossero la stessa cosa.

4.Conviene acquistare capacità riservata (tipo PTU) o restare a consumo?

La capacità riservata riduce il costo per richiesta e stabilizza la latenza, ma il suo tasso di utilizzo effettivo può scendere sotto il 15% se dimensionata su un picco troppo alto rispetto al traffico reale, specie in presenza di forte stagionalità o pattern d'uso concentrati in poche ore del giorno. La scelta corretta è quasi sempre ibrida, e va rivista periodicamente, non fissata una volta per tutte.

5.Come si trasforma il cost engineering in un vantaggio competitivo, non solo in un controllo di spesa?

Misurando il costo per singolo risultato di business (non per token o per progetto) si può negoziare un modello di prezzo legato al valore generato — coerente con l'evoluzione del mercato verso schemi di pricing basati su outcome e consumo effettivo, invece che sul solo tempo/persona impiegato per costruire la soluzione.

Bibliografia

FinOps Foundation (2026). State of FinOps 2026 Report ,https://data.finops.org/

FinOps Foundation / The Linux Foundation (19 febbraio 2026). State of FinOps Survey: AI Value and Skills Top Priorities as FinOps Matures Across Technology Value. https://www.linuxfoundation.org/press/state-of-finops-survey-ai-value-and-skills-top-priorities-as-finops-matures-across-technology-value-98-manage-ai-90-saas-64-licensing-48-data-center-1