La metrica mancante tra token e spese cloud

Il problema non è che i team di IA manchino di dati sui costi. È che il cruscotto dei token e la fattura cloud descrivono sistemi diversi, appartenenti a team diversi, senza un modo affidabile per collegarli.

Un agente di supporto può risolvere un ticket dopo cinque chiamate al modello, un passaggio di recupero, due chiamate a tool e un nuovo tentativo. L’azienda registra un caso completato. L’infrastruttura registra una serie di richieste, pod, memoria, tempo di acceleratore e servizi condivisi. Finché questi record non coincidono, l’ottimizzazione dei costi è in parte un’ipotesi.

Perché le metriche dei token e le fatture cloud raccontano storie diverse?

Il conteggio dei token è utile. Mostra quanta testo un modello ha ricevuto e restituito, e aiuta i team a confrontare prompt, modelli o scelte di routing. Ma non indica cosa è accaduto attorno alla chiamata del modello, quanta computazione ha supportato il recupero e l’uso di tool, quante tentativi falliti sono avvenuti prima, o se il risultato finale è stato effettivamente utile.

Il State of FinOps 2026 mostra quanto rapidamente l’IA sia entrata nel lavoro FinOps ordinario: il 98% degli intervistati ora gestisce le spese AI, rispetto al 63% nel 2025. Tuttavia, una voce di budget più ampia non indica comunque quale flusso di lavoro ha consumato i soldi o perché. 

Due lavori di elaborazione documenti possono utilizzare approssimativamente lo stesso numero di token. Uno può concludersi con una singola richiesta al modello. L’altro può recuperare contesto da diversi archivi, chiamare un servizio esterno, ricorrere a un altro modello e rieseguire il documento dopo un controllo di validazione fallito che l’utente non vede. I totali dei token appaiono simili, mentre i percorsi di esecuzione no.

Unite.ai ha già esaminato perché i conteggi dei token non rappresentano automaticamente il valore di business. Il passo successivo è collegare quei conteggi ai carichi di lavoro che li hanno prodotti. Altrimenti, un team può migliorare il costo per token peggiorando il costo per attività completata.

Come appare una catena dei costi completa?

Una catena dei costi utile parte dal risultato a cui l’azienda tiene. Potrebbe trattarsi di un caso di supporto risolto, di un documento elaborato, di una modifica al codice accettata o di un flusso di lavoro dell’agente completato. Tutto ciò che segue deve avere un’identità che possa essere tracciata attraverso il sistema.

Il livello applicazione fornisce la prima connessione. Un ID richiesta, ID traccia, nome del flusso di lavoro o ID conversazione può collegare diverse operazioni di modello e tool a un unico pezzo di lavoro. Senza quel filo conduttore, dieci eventi correlati sembrano dieci addebiti non correlati.

Le convenzioni OpenTelemetry per agenti GenAI offrono un vocabolario emergente per questo livello. Coprono operazioni, fornitori, modelli richiesti, agenti, conversazioni, utilizzo dei token, esecuzione di tool, errori e flussi di lavoro. Le convenzioni sono ancora contrassegnate come in fase di sviluppo, quindi i team non dovrebbero trattarle come uno standard universale definitivo. Sono utili perché rendono concreto il problema di correlazione.

Poi arriva l’infrastruttura. I dati di allocazione dei costi suddivisi per EKS di AWS possono assegnare i costi condivisi di calcolo e memoria ai pod di Kubernetes ed espongono dettagli come cluster, namespace, deployment, nodo, nome del carico di lavoro e tipo di carico di lavoro. Per le istanze accelerate supportate, i dati coprono anche le riserve di GPU, Trainium e Inferentia.

Questa è l’altra metà della catena. Una traccia può spiegare cosa l’applicazione ha cercato di fare; l’allocazione di Kubernetes può mostrare quali risorse hanno svolto il lavoro. La guida di Unite.ai a distribuire e monitorare LLM su Kubernetes fornisce il contesto di produzione più ampio, includendo l’allocazione delle risorse, il dimensionamento e l’osservabilità.

L’unione non avverrà per caso. I team hanno bisogno di un identificatore stabile che duri a lungo abbastanza da collegare la telemetria dell’applicazione con le etichette dei carichi di lavoro, i record di allocazione o un altro livello di mappatura. I dati dei clienti non appartengono ai tag di Kubernetes. I team dovrebbero decidere quali identificatori a bassa cardinalità possono collegare in modo sicuro una categoria di flusso di lavoro, servizio o funzionalità alle risorse che ha consumato.

Una volta che il contesto dell’applicazione è in atto, i team possono iniziare a monitorare i costi di Kubernetes per carico di lavoro e collegare namespace, CPU, memoria e utilizzo GPU al lavoro svolto. Questo ancora non indica se il flusso di lavoro ha generato valore di business, ma fornisce al lato infrastruttura del calcolo qualcosa di concreto a cui agganciarlo. 

Quale metrica di unità dovrebbe l’azienda considerare affidabile?

Non esiste un’unica metrica di costo AI che tutti i team debbano usare. Il costo per token risponde a una domanda di consumo del modello. Il costo per pod risponde a una domanda di allocazione dell’infrastruttura. Nessuna delle due indica a un product owner se la funzionalità sta giustificando il proprio costo.

Il denominatore migliore è solitamente il risultato più piccolo che l’azienda può definire chiaramente e che il team di prodotto può influenzare. Un’operazione di supporto potrebbe monitorare il costo per caso risolto. Un sistema di documenti potrebbe usare il costo per file elaborato con successo, mentre un assistente di codifica potrebbe esaminare il costo per modifica accettata anziché il costo per suggerimento.

Il successo cambia i calcoli.

Un flusso di lavoro con un basso costo per tentativo può risultare costoso se fallisce spesso, genera convalide ripetute o invia troppi casi a revisione umana. Per questo i team dovrebbero separare il costo per tentativo dal costo per completamento e, dove possibile, il costo per risultato accettato. Quest’ultimo numero è spesso il più utile perché include il lavoro prodotto dal sistema ma che l’azienda non ha potuto utilizzare.

I sistemi di agente rendono la cosa più difficile perché i loro percorsi possono cambiare da un’esecuzione all’altra. L’analisi di Unite.ai sull’economia della scalabilità dei carichi di lavoro AI agentici copre routing, chiamate a tool, retry e attribuzione a livello di flusso di lavoro. Questi comportamenti appartengono alla metrica di unità quando consumano risorse, anche se l’utente finale vede solo una risposta.

La metrica non sarà comunque perfetta. Servizi condivisi, risultati in cache, job batch e processi ritardati possono offuscare l’attribuzione. Una stima utile per le decisioni è migliore di una precisione falsa, specialmente quando indica agli ingegneri quale livello merita indagine.

Chi possiede il numero?

La parte più difficile può essere organizzativa. I team ML comprendono le chiamate al modello e la valutazione. I team di piattaforma comprendono i carichi di lavoro e il comportamento del cluster. I FinOps comprendono i dati di fatturazione e le regole di allocazione. I team di prodotto sanno quale risultato conta.

Nessun team possiede l’intera catena.

Ciò genera un dibattito prevedibile su quale dashboard sia corretta. Il team ML può puntare a un minore utilizzo di token, mentre il team di piattaforma vede aumentare le ore GPU e il team di prodotto osserva meno attività completate rispetto a prima. Tutte e tre le osservazioni possono essere vere contemporaneamente. La metrica condivisa deve spiegare la relazione tra esse.

Un punto di partenza praticabile è un flusso di lavoro di produzione con un chiaro evento di completamento. Assegnargli un identificatore stabile. Trasportare quel contesto attraverso le tracce di modello e tool, mapparlo al servizio o al carico di lavoro in esecuzione su Kubernetes e scegliere un denominatore di business. Poi riunire i team quando il numero varia in modo inatteso.

Questa revisione conta più di una dashboard rifinita. Un improvviso aumento può derivare da prompt più lunghi, un nuovo percorso di fallback, capacità GPU sottoutilizzata, una politica di autoscaling modificata o una decisione di prodotto che invia più lavoro alla funzionalità AI. Ogni causa appartiene a un diverso proprietario.

L’automazione dovrebbe arrivare in seguito. Un motore di raccomandazione può agire solo sulle etichette e soglie che riceve, e un denominatore errato può far apparire un sistema efficiente come sprecone o premiare un flusso di lavoro economico che gli utenti rifiutano. I team hanno bisogno di una visibilità condivisa sufficiente per distinguere il comportamento del modello dal design dell’applicazione e dall’allocazione dell’infrastruttura prima di consentire a un sistema di agire sul risultato. Altrimenti, una correzione automatica dei costi può ridurre la capacità, aumentare la latenza e spostare la spesa in un’area meno visibile.

La catena dei costi deve essere condivisa

Il controllo dei costi AI rimarrà frammentato finché ogni team ottimizza solo lo strato che può vedere. Token, tracce, pod, acceleratori e fatture non sono misurazioni concorrenti. Sono parti della stessa catena dei costi.

Le aziende che le collegano non otterranno un numero perfetto fin dal primo giorno. Ciò che conta è se il team può rintracciare una fattura elevata al flusso di lavoro che l’ha generata, capire cosa è cambiato e decidere se il risultato ha giustificato il costo.