La nuova economia della gestione dei costi dell'AI

Negli ultimi due anni, la storia relativa all'adozione dell'AI aziendale si è concentrata principalmente nell'indurre le persone a utilizzarla. Negli ultimi mesi, questa narrazione sta cambiando rapidamente in molte organizzazioni. L'osservabilità dell'AI, che un tempo misurava il successo in base al volume di token, sta iniziando a misurarlo in base al ritorno sull'investimento, e le aziende che per prime gestiscono i costi saranno quelle in grado di scalare l'AI senza che le spese superino i ricavi.

Fondamentalmente, la gestione dei costi dell'AI è la pratica di misurare, attribuire, controllare e ottimizzare la spesa in AI tra modelli, agenti, applicazioni e team. L'obiettivo non è semplicemente utilizzare meno token, ma massimizzare il valore aziendale generato per ogni dollaro speso. Poiché gli agenti AI svolgono un lavoro sempre più autonomo, tale disciplina si estende sempre più alla gestione dei costi di ragionamento degli agenti, delle chiamate agli strumenti e dei modelli che li alimentano.

Abbiamo incontrato Kevin Stumpf, Senior Staff Engineer presso Databricks e Technical Lead per Unity Gateway, per discutere di come i team dovrebbero concretamente mettere in pratica questa disciplina: non considerando il costo dell'AI come una voce di spesa da minimizzare, ma come un sistema da gestire.

Dal tokenmaxxing al valuemaxxing

I social media sono pieni di leader che sostengono che il "tokenmaxxing", ovvero far eseguire l'AI il più possibile e il più spesso possibile, sia il modo giusto per accelerare l'innovazione. A parte le ovvie implicazioni sui costi, perché questo è un modo errato di concepire l'adozione dell'AI?

Kevin Stumpf: Il settore sta passando dal tokenmaxxing al valuemaxxing. Nei primi tempi, esistevano classifiche pubbliche che mostravano quanti token le persone stavano consumando, e all'epoca questa strategia aveva senso. Molte persone erano riluttanti a iniziare a usare l'AI, quindi mostrare che i leader di riferimento ne me facevano un uso intensivo dava agli altri un motivo per seguirli. Se vedo qualcuno che rispetto usare un'enorme quantità di AI, voglio essere come quella persona.

Ma il sistema è stato manipolato. Una volta che essere in cima alla classifica è diventato uno status symbol, le persone hanno capito che il modo più rapido per arrivarci non era fare un buon lavoro, ma il volume. Avviare un agente elementare che esegue un loop continuo, chiedergli ripetutamente che tempo fa e consumare token senza fare sostanzialmente nulla. Questo è stato il risultato prevedibile di una struttura di incentivi che premiava l'utilizzo puro anziché i risultati.

Ora che le organizzazioni hanno ampiamente accolto l'AI, il confronto si è spostato sull'uso responsabile ed efficace. Ciò a cui dovremmo davvero puntare è un tipo diverso di classifica, che ordini le persone in base all'impatto generato con l'AI diviso per il costo sostenuto per generarlo. Questo è il ritorno sull'investimento, ed è un elemento molto più difficile da quantificare rispetto al conteggio grezzo dei token, ma è il valore che conta davvero. Correlato: Cosa sta guidando l'adozione dell'AI aziendale?

Cosa significa davvero l'attribuzione dei costi nella pratica

Puoi spiegari cosa significa veramente "attribuzione dei costi" nell'AI?

Kevin Stumpf: L'attribuzione dei costi dell'AI consiste in definitiva nel rispondere a due domande: da dove proviene la mia spesa e cosa ho ottenuto in cambio? Al livello più semplice, questo significa attribuire i costi a un singolo utente o a un team, come un team di data science o un team di ingegneria del software. Può anche essere mappata su un progetto specifico o su un nodo dell'organigramma aziendale, ad esempio per capire quanta spesa fa capo a un VP of AI rispetto a un SVP of Engineering.

L'obiettivo è ottenere una visibilità abbastanza granulare da poter analizzare i dati nel dettaglio e comprendere da dove provengono effettivamente i costi, perché non si può gestire ciò che non si può misurare. Databricks offre l'attribuzione dei costi pronta all'uso per utente, gruppo, agente, endpoint AI Gateway, modello, provider e periodo di tempo. Tuttavia, le organizzazioni possono anche personalizzarla ampiamente utilizzando i tag a livello di richiesta. Un tag può rappresentare qualsiasi elemento di interesse per l'organizzazione, come una specifica pull request, una funzionalità o un cliente esterno, e una volta che ogni richiesta include quel tag, è possibile aggregare la spesa in base ad esso secondo le proprie esigenze.

Questo cambiamento nell'orientamento dei clienti è stato reale. Sei mesi fa, la preoccupazione principale era rimanere indietro nell'adozione dell'AI. Ora è l'opposto: l'AI viene spesso usata per scopi banali, i costi crescono più rapidamente dei ricavi e i leader si chiedono come invertire questa curva dei costi prima che intacchi la redditività. Non si tratta di un'ipotesi. È una discussione a livello di consiglio di amministrazione in quasi tutte le organizzazioni con cui parliamo, compresa Databricks al suo interno.

Controllare l'eccesso di contesto

L'uso dei token e le dimensioni della finestra di contesto vengono spesso colpevolizzati, ma raramente spiegati in modo chiaro. Che aspetto ha in pratica l'eccesso di contesto (context bloat) in un sistema di produzione e qual è la soluzione pratica?

Kevin Stumpf: L'eccesso di contesto significa fornire a un agente molte più informazioni di quelle necessarie per prendere una buona decisione. Questo è un problema per due ragioni. Primo, consuma token non necessari. Secondo, distrae: l'agente deve elaborare quelle informazioni aggiuntive e decidere se sono rilevanti, il che costituisce un ulteriore sovraccarico. È un po' come consegnare a una persona una pila di documenti irrilevanti e chiederle di capire cosa sia importante ancora prima di iniziare il compito.

La soluzione migliore non è il ritaglio o la memorizzazione nella cache a posteriori, ma evitare di generare l'eccesso fin dall'inizio. Un pattern comune ed efficace consiste nel consentire all'agente di recuperare il contesto rilevante su richiesta, tramite strumenti, server MCP o competenze, anziché inviare in modo proattivo tutto ciò di cui potrebbe aver bisogno fin da subito. È opportuno inviare il contesto a un agente per impostazione predefinita solo se si è certi al 90% o più che sia davvero importante per il compito da svolgere. In caso contrario, è sufficiente informare l'agente su ciò che è disponibile e consentirgli di recuperare ciò di cui ha bisogno al momento opportuno.

Routing dinamico dei modelli e degli harness

La selezione del modello è spesso una decisione "da prendere una volta sola". Perché dovrebbe invece essere dinamica e in che modo il routing intelligente decide, in tempo reale, se un compito richiede un modello di punta (frontier model) o qualcosa di più economico e veloce? La stessa idea si applica anche alla scelta tra diversi harness per gli agenti?

Kevin Stumpf: L'ottimizzazione dei costi dell'AI non consiste nello scegliere sempre il modello più economico; i team dovrebbero piuttosto passare alla scelta del modello o dell'harness a minor costo in grado di offrire la qualità richiesta da un compito. La realtà attuale è che i modelli di punta (frontier model) sono estremamente capaci e costosi, mentre i modelli non di punta sono comunque molto validi, ma meno costosi. Circa il 5-10% dei compiti richiede effettivamente un modello di punta, perché la posta in gioco è sufficientemente alta da desiderare il miglior risultato possibile, o perché il problema è troppo complesso per modelli inferiori. Il restante 90% dei compiti può essere risolto da modelli meno complessi, che si tratti di modelli open source ospitati autonomamente o di famiglie di modelli più economiche dei principali laboratori.

Se lasciati ai propri incentivi, la maggior parte dei dipendenti sceglierà per impostazione predefinita il modello più costoso disponibile, poiché il loro obiettivo è semplicemente risolvere il problema e nessuno controlla quanto costi a livello individuale. Lo Smart Routing risolve questo problema inserendo un livello che valuta la complessità del compito in tempo reale e decide se una richiesta debba essere indirizzata a un modello di punta o a uno a costo inferiore, con l'obiettivo di mantenere la stessa qualità dei risultati a un costo più contenuto.

Il routing degli harness rappresenta il livello successivo al routing dei modelli. Nuove ricerche mostrano che lo stesso identico modello, eseguito tramite un harness diverso, può generare costi significativamente differenti. Ciò è logico, poiché l'harness determina l'interazione del modello con il suo ambiente: quali regole segue, quando riduce la finestra di contesto e quale logica di business ne governa il comportamento. Tutto questo influisce direttamente sul numero di token consumati. Il routing degli harness rappresenta la fase successiva nell'evoluzione progressiva dell'ottimizzazione dei costi, che abilitiamo tramite Unity Gateway e Omnigent, il nostro meta-harness.

Progettare guardrail sulla spesa

Parliamo dei guardrail sulla spesa vera e propria, come tetti massimi immodificabili (hard cap), budget e limiti di frequenza (rate limit). Qual è il modo corretto di progettarli affinché blocchino i costi incontrollati senza compromettere la produttività degli sviluppatori o interrompere i flussi di lavoro in produzione?

Kevin Stumpf: Alcune regole si applicano a ogni organizzazione, mentre altre dipendono dal caso d'uso o dall'azienda. Tutti dovrebbero impostare tetti massimi di spesa (hard cap) per individuare utilizzi incontrollati. Se il tipico utente esperto spende al massimo circa 300 $ al giorno in AI, è opportuno impostare il tetto massimo un po' più in alto, ad esempio a 500 $. Questo margine consente di intercettare errori reali, come un agente rimasto accidentalmente in esecuzione in un loop, senza limitare le giornate di utilizzo legittimamente elevato.

Oltre a questa baseline, ha molto senso prevedere budget differenziati per team o per progetto. Un team che lavora su un progetto critico per il CEO potrebbe giustificare un budget molto più elevato rispetto a un team impegnato in attività a priorità inferiore; questa decisione dovrebbe valutare il valore di ciò che il team produce rispetto al costo di concedergli maggiore margine di manovra.

I budget dovrebbero anche poter attivare diversi tipi di risposte, non solo un blocco definitivo. Possono inviare avvisi, applicare limiti rigidi o ridurre la capacità del modello disponibile, ad esempio interrompendo l'accesso predefinito ai modelli frontier una volta che un team ha consumato il 70% del suo budget e reindirizzando il resto delle sue richieste verso modelli open source. I principi fondamentali che si applicano ovunque: prevenire spese incontrollate, impostare limiti differenziati per gruppo o progetto, inviare un avviso prima di applicare un limite e integrare una riduzione intelligente della capacità invece di un'interruzione improvvisa.

Misurare ciò che l'AI offre effettivamente

Quali piattaforme offrono insieme il monitoraggio degli agenti e il tracciamento dei costi, e quanto può aiutarti questa visibilità a misurare il ROI effettivo, e non solo la spesa?

Kevin Stumpf: Misurare i costi è molto più semplice che collegare tali costi al ritorno sull'investimento, ed è la domanda a cui tutti vogliono una risposta e che quasi nessuno ha ancora risolto del tutto. Il tagging a livello di sessione o richiesta è ciò che rende possibile tutto questo. Se un agente sta lavorando a una pull request specifica, può taggare la sua sessione o le richieste specifiche generate con l'identificativo di quella pull request. Tale attribuzione viene riportata in una dashboard dei costi, consentendo di vedere, ad esempio, che il completamento di una determinata pull request è costato 300 $. Questo è qualcosa che stiamo già facendo internamente in Databricks.

In uno scenario ideale, e questo è qualcosa che stiamo integrando nel prodotto Unity Gateway, puoi fare un ulteriore passo avanti e collegare la pull request a una funzionalità specifica, e quella funzionalità a un risultato misurabile, come le entrate o la pipeline generate in un determinato periodo. Questo è il punto di svolta: non solo sapere quanto è costata l'AI, ma sapere quanto ha reso. Con Unity Gateway, disponiamo già di una piattaforma altamente personalizzabile su cui creare tutto questo e stiamo investendo per rendere disponibile questa vista dal costo al rendimento in modo predefinito, anziché come qualcosa che i team debbano costruire da soli.

La visibilità della spesa richiede un sistema centralizzato

Per un'azienda che esegue più modelli, agenti e strumenti su diversi team, cosa richiede effettivamente una buona visibilità della spesa? Si tratta di un problema di dashboard, di governance o di FinOps?

Kevin Stumpf: Per avere una buona visibilità della spesa è necessario che ogni interazione con l'AI passi attraverso un sistema centralizzato. È questo che consente di fissare le informazioni corrette in modo coerente, permettendo di creare dashboard e avvisi affidabili. Un AI gateway fornisce un punto di controllo centralizzato per la gestione dei costi dell'AI su modelli, agenti, strumenti e team. Databricks Unity Gateway è progettato per fornire questo punto di controllo centralizzato tra modelli, agenti, strumenti e agenti di codifica. Quando le interazioni con l'AI fluiscono attraverso un punto di controllo comune, le organizzazioni possono monitorare l'utilizzo, attribuire i costi, applicare i budget e ottimizzare la spesa in un unico luogo.

Ma avere un sistema centralizzato non basta. È necessario anche un modo per far sì che tutti instradino effettivamente il proprio traffico AI attraverso di esso. La visibilità funziona solo se l'adozione è universale, non opzionale.

Bilanciare l'ottimizzazione dei costi e la qualità dei risultati

Il controllo dei costi non può andare a scapito della qualità o dell'affidabilità. Come si fa a sapere quando un'ottimizzazione si è spinta troppo oltre iniziando a danneggiare i risultati?

Kevin Stumpf: Dipende strettamente dal caso d'uso. È necessario un meccanismo di feedback, che può essere soggettivo o oggettivo. Il feedback soggettivo è di tipo aneddotico, come qualcuno nel team che riferisce di non riuscire a svolgere il lavoro entro il budget attuale. Si tratta di un feedback rapido da ottenere, ma facile da liquidare come la lamentela di una singola persona. Il feedback oggettivo proviene da valutazioni automatizzate, più difficili da configurare ma decisamente più affidabili.

Per un caso d'uso comune come gli agenti di codifica, ciò potrebbe significare definire una metrica proxy per la qualità, ad esempio le pull request unite che non vengono annullate entro due settimane. Da lì puoi sperimentare: dimezzare il budget e vedere se tale metrica di riferimento varia, rimane stabile o persino migliora, visto che a volte i vincoli stimolano la creatività. Eseguire esperimenti paralleli tra team con budget, modelli e harness differenti, oppure confronti a tempo su alcune settimane, consente di dedurre anziché tirare a indovinare se un determinato budget stia creando o distruggendo valore.

Il valore del tracciamento end-to-end

Che ruolo giocano in questo contesto il tracciamento e il monitoraggio end-to-end? Una volta visualizzati prompt, chiamate a strumenti e utilizzo dei token nell'intero flusso di lavoro di un agente, quali opportunità si aprono che prima non erano possibili?

Kevin Stumpf: Il tracciamento consiste nel raccogliere l'insieme completo delle attività degli agenti: cosa pensano, quali strumenti chiamano, quali dati acquisiscono, se i prompt sono buoni o cattivi. Questi dati grezzi rappresentano la base da analizzare per estrarre informazioni utili, che si tratti di identificare abusi, sprechi, falle di sicurezza o semplicemente pattern a cui non si era pensato.

Questo rispecchia quanto accaduto nel settore dei dati più in generale. All'inizio avevamo solo dati puliti e strutturati nei database. Poi sono arrivati i data lake, che per un po' si sono trasformati in "data swamp" (paludi di dati) perché le persone vi riversavano dati non strutturati senza un modo per estrarne valore. Alla fine quelle paludi si sono ritrasformate in data lake utilizzabili e oggi ci troviamo nella posizione migliore di sempre per estrarre insight da dati non strutturati e semistrutturati, principalmente perché gli LLM sono abbastanza flessibili da elaborarli. I tracciati degli agenti rientrano nella stessa categoria. Più ne raccogli, maggiori saranno gli insight disponibili, ed è più facile che mai accedervi.

Scalare alle flotte di agenti

Molte aziende stanno passando da singole applicazioni AI a flotte di agenti. Questo passaggio modifica l'equazione dei costi (nuovi fattori di costo? nuovi punti ciechi?) rispetto all'esecuzione di un singolo modello dietro un'unica app?

Kevin Stumpf: Non cambia tanto l'equazione quanto la moltiplica. Gli sciami di agenti saranno la nuova realtà e ciascuno di essi utilizzerà token che dovranno essere attribuiti, monitorati e gestiti. Questo è il momento giusto per porre le giuste basi per la visibilità e la gestione dei costi, prima che il numero di agenti in produzione cresca come previsto.

Gli agenti di codifica rappresentano la categoria principale che consuma token oggi, ma la tendenza si estenderà a molte altre classi di agenti che svolgono un lavoro autonomo 24 ore su 24, 7 giorni su 7, con agenti che chiamano altri agenti che a loro volta ne chiamano altri. Le organizzazioni che aspettano a costruire un'infrastruttura centralizzata di osservabilità dei costi e dell'AI finché tale complessità non si manifesti la realizzeranno sotto pressione, anziché secondo i propri tempi e le proprie esigenze.

Se dovessi lasciare ai leader dell'AI aziendale un unico cambiamento di mentalità sulla gestione dei costi per il prossimo anno, quale sarebbe?

Kevin Stumpf: Non aspetterei il prossimo anno. Si tratta di una questione urgente e va trattata come tale fin da subito. Se dovessi riassumerla in un'unica idea, sarebbe questa: non si può gestire ciò che non si misura. Questo vale per le materie prime, vale per le persone e vale allo stesso modo per l'AI. L'AI sta diventando rapidamente una delle voci più importanti del rendiconto finanziario di un'azienda e deve essere completamente strumentata per poter essere misurata e, di conseguenza, gestita. È semplicemente un altro ingrediente grezzo nel sistema che produce i beni o i servizi della tua organizzazione e merita di essere trattato con la stessa disciplina.

Il tempo corre: Controllare i costi dell'AI tra team che utilizzano più modelli e strumenti non è un problema che si risolve con un'unica dashboard o con la scelta una tantum di un modello. Si tratta di una disciplina operativa: un'attribuzione abbastanza granulare da tracciare la spesa fino a una persona o a un progetto, un instradamento che si adatta in tempo reale alle esigenze di ciascun compito, guardrail che bloccano le spese incontrollate prima che diventino un problema evidente e un tracciamento sufficientemente dettagliato da trasformare i dati di utilizzo grezzi in informazioni davvero utili. Le organizzazioni che si stanno portando avanti su questo fronte non sono quelle che spendono meno per l'AI, ma quelle in grado di dire con certezza esattamente cosa hanno ottenuto in cambio di ciò che hanno speso.

Scopri di più su come Unity Gateway centralizza l'attribuzione dei costi, l'instradamento intelligente e i guardrail di spesa nell'intero ambiente AI.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale