Cloud Intelligence™
Come validare l'attribuzione dei costi AI in un ambiente di produzione
Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.
About Gregory Wiedeman
Senior Cloud Architect I
Greg is a Cloud Architecture Strategist at DoiT International and holds an M.S. in Systems Engineering from Regis University. He specializes in cloud architecture, FinOps consulting, and technical advisory services—helping clients optimize infrastructure and make smarter build decisions. When he's not immersed in cloud cost strategies, he enjoys writing about AI governance for non-technical leaders, playing cornhole, or climbing Colorado's many 14ers.
My personal pageDimostrare che è possibile attribuire i costi all'AI è semplice; fidarsi di quell'attribuzione è difficile.
Una dashboard può mostrare token, richieste o utilizzo delle GPU; la difficoltà sta nel capire se queste cifre si riferiscono al cliente, alla funzionalità di prodotto, al team o all'agente giusto e se i totali corrispondono a quelli di cui finance ed engineering si fidano già.
Questo articolo presenta un approccio pratico alla verifica dell'attribuzione dei costi AI in produzione. L'obiettivo non è avere una dashboard perfettamente funzionante fin dal primo giorno, bensì stabilire una catena di evidenze misurabile che colleghi l'attività a runtime al contesto di business.
Partire da una definizione di "corretto"
Prima di impostare un sistema di attribuzione, è necessario decidere a quale tipo di domanda i risultati devono rispondere.
Ad esempio:
- Qual è il costo per cliente dell'erogazione del servizio?
- Quali funzionalità di prodotto generano la spesa maggiore sui modelli?
- Quanto costa eseguire ciascun agente AI?
- Quali sono i workloads condivisi che generano i costi infrastrutturali?
- Quale quota della spesa nel perimetro non è attualmente attribuibile?
Le domande riguardano aspetti diversi dell'attribuzione; sebbene un approccio a livello di team possa bastare a scopo di showback, ottenere una vista per cliente richiede identificatori di tenant, dettagli sulla funzionalità e una mappatura tra identificatori a runtime e nomi di business.
Prima di guardare i risultati, è necessario mettere per iscritto i criteri di validazione. Un piano di validazione efficace dovrebbe specificare:
- I workloads e i provider nel perimetro
- Le dimensioni che devono essere visibili
- La fonte di verità per il confronto
- La finestra temporale oggetto del confronto
- La varianza accettabile
- Il trattamento della spesa non attribuita
Attribute™ assegna il consumo a runtime a diverse dimensioni, come team, namespace, workload, modello, funzionalità, ambiente, tenant o cliente. La scelta decisiva è selezionare le dimensioni che corrispondono alla domanda di business, invece di raccogliere ogni etichetta possibile.
1. Iniziare con un workload dal perimetro limitato
Non cominci validando l'intero ambiente cloud. Parta invece da una porzione piccola e rappresentativa:
- Un servizio in produzione
- Un modello o un gateway
- Una funzionalità rivolta ai clienti
- Un namespace Kubernetes
- Un account di fatturazione o un progetto
Con un perimetro ristretto, eventuali discrepanze possono essere individuate e il team di piattaforma dispone inoltre di un risultato di riferimento estendibile in futuro.
Per il primo test, acquisisca l'attività attesa in modo indipendente. Dati di confronto utili potrebbero includere:
- Dati di utilizzo o fatturazione del provider
- Contatori di richieste e token del gateway LLM
- Log applicativi
- Identificatori di tenant o cliente
- Metadati dei workloads Kubernetes
- Utilizzo di GPU o compute
Non è necessario che tutti i sistemi adottino la stessa terminologia. L'obiettivo è semplicemente capire come i vari sistemi si relazionano tra loro.
2. Assicurarsi che la chiave di attribuzione resti visibile a runtime
I problemi di attribuzione di solito iniziano prima che il costo venga calcolato: al momento della raccolta della telemetria, la chiave di attribuzione — ossia l'identificatore necessario per distinguere un'istanza di utilizzo da un'altra — potrebbe mancare.
Per ogni dimensione target, risponda a tre domande:
- Quale identificatore si riferisce al cliente, alla funzionalità o al tenant?
- In quale punto del percorso della richiesta compare l'identificatore?
- Il collector a runtime può osservarlo in modo continuativo?
Ad esempio, un identificatore cliente potrebbe trovarsi in una richiesta autenticata, in un header del gateway, in un attributo della connessione al database o in un campo specifico dell'applicazione; ma se l'identificatore esiste solo nella memoria dell'applicazione e non attraversa mai alcun confine osservabile, sarà necessario ricorrere a un diverso metodo di integrazione o instrumentazione.
Per questo motivo la validazione dovrebbe partire dalla possibilità di vedere la chiave a runtime, e non dal totale mostrato su una dashboard; se la chiave non può essere osservata in modo affidabile, l'allocazione a valle resterà incompleta anche se il livello di reporting è configurato con cura.
I tag non riescono a seguire la spesa AI attraverso GPU condivise e gateway. Legga AI Features Have a Visibility Problem per capire perché l'osservabilità a runtime batte l'instrumentazione. Scarichi l'ebook →
3. Definire i confini della raccolta
Attribute™ raccoglie informazioni sul consumo a runtime a livello di kernel tramite eBPF (extended Berkeley Packet Filter, una tecnologia del kernel Linux progettata per l'osservabilità a basso overhead) e non richiede alcuna modifica al codice dell'applicazione né all'SDK applicativo. Il confine della raccolta, tuttavia, resta importante.
Documenti:
- Quali cluster, host o account sono coperti
- Quali workloads sono inclusi o esclusi
- Quali sistemi operativi e versioni del kernel sono supportati
- Se il traffico viene cifrato prima di raggiungere il confine osservabile
- Se l'infrastruttura condivisa rientra nel perimetro di misurazione
Prima dell'avvio della modellazione dell'attribuzione, il processo di onboarding di DoiT prevede una revisione della topologia dei cluster, una verifica della compatibilità di kernel e sistema operativo, un esame dei requisiti di sicurezza e un'analisi del flusso di telemetria. Per maggiori informazioni sul modello di engagement, consulti la documentazione panoramica di Attribute.
Una dichiarazione di copertura utile si presenta così:
La validazione include il namespace di inferenza in produzione, il gateway self-hosted e i nodi GPU associati da lunedì alle 00:00 UTC a martedì alle 00:00 UTC, con esclusione del traffico di sviluppo, dei workloads batch e delle connessioni preesistenti.
Con confini chiari, i team non considereranno un risultato intenzionalmente parziale come un malfunzionamento, né tratteranno un'area non misurata come se avesse costo zero.
4. Creare una mappatura dall'identificatore al business
La telemetria a runtime spesso parte da identificatori tecnici:
- Nomi dei pod
- ID dei container
- Nomi dei namespace
- ID dei modelli
- Chiavi API
- ID dei tenant
- Nomi dei servizi
I team finance e di prodotto hanno bisogno di dimensioni leggibili:
- Nome del cliente
- Funzionalità di prodotto
- Business unit
- Ambiente
- Fascia di prezzo
- Team responsabile
Si assicuri che la mappatura sia chiara e ne conservi una copia; annoti chi ne è responsabile e quando è stata aggiornata l'ultima volta, e specifichi cosa accade quando un identificatore non ha un record di business corrispondente.
Una tabella di mappatura dovrebbe includere almeno le seguenti colonne, ad esempio:
| Identificatore a runtime | Dimensione di business | Responsabile | Data di validità | Stato di validazione |
|---|---|---|---|---|
tenant-4821 |
Acme / Search Assistant | Product Platform | 2026-09-01 | Confermato |
tenant-5177 |
ExampleCo / Document Review | AI Applications | 2026-09-01 | Confermato |
tenant-unknown |
Non mappato | Platform FinOps | 2026-09-01 | Da verificare |
La riga non mappata è importante. Nasconderla crea l'apparenza di un'attribuzione completa, eliminando al tempo stesso le evidenze necessarie per migliorare la copertura.
Vuole scoprire quali clienti Le costano di più? Scarichi Cost Per Customer: A FinOps Field Guide to Multi-Tenant Cloud Attribution, con query SQL pronte all'uso per AWS, Google Cloud e Azure. Scarichi la guida →
5. Riconciliare le tre viste della stessa attività
Una validazione affidabile confronta almeno tre prospettive:
- Attività a runtime — ciò che il workload ha chiamato o consumato
- Utilizzo del provider o del gateway — ciò che la piattaforma riporta in termini di token, richieste o compute
- Costo attribuito — come quell'utilizzo viene assegnato alle dimensioni di business
Confronti la stessa finestra temporale tenendo conto delle differenze di timing: le esportazioni di fatturazione possono subire ritardi, i contatori del gateway possono interpretare una richiesta in modo diverso e la telemetria a runtime può osservare retry o chiamate in cache in modo diverso rispetto alla fattura del provider.
Due metriche semplici risultano utili:
Coverage = attributed in-scope spend / total in-scope spend
Variance = absolute (source total - attributed total) / source total
È necessario monitorare le metriche giorno per giorno a livello di workload, poiché una percentuale complessiva potrebbe mascherare un problema serio relativo a un cliente o a una funzionalità specifica.
In presenza di una discrepanza, la classifichi invece di modificare subito la regola di attribuzione:
- Disallineamento di perimetro
- Disallineamento della finestra temporale
- Ritardo di fatturazione del provider
- Identificatore a runtime mancante
- Identificatore non mappato
- Retry o richiesta duplicata
- Lavoro in cache o asincrono
- Percorso di traffico non supportato
Il processo di classificazione trasforma quello che sarebbe un esercizio di riconciliazione in una serie di attività di engineering; l'esempio seguente mostra come questa riconciliazione venga portata fino in fondo prima di passare ai test dei casi limite.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Esempio illustrativo di validazione
L'esempio riportato di seguito ha scopo puramente illustrativo e non si basa sui risultati di alcun cliente reale.
Un'azienda SaaS vuole determinare il costo della propria funzionalità di riepilogo documenti dal punto di vista di ciascun tenant; la funzionalità invia le richieste tramite un gateway LLM condiviso in esecuzione su Kubernetes.
Il team definisce un periodo di validazione di 24 ore che include un namespace di produzione, un gateway e due provider di modelli, quindi confronta i contatori di token del gateway, l'utilizzo del provider e l'output di Attribute™.
| Fase di validazione | Risultato |
|---|---|
| Totale provider e gateway | 10.200 $ di utilizzo AI nel perimetro |
| Spesa attribuita a tenant noti | 9.650 $ |
| Spesa non mappata o non attribuita | 550 $, pari al 5,4% del perimetro |
| Conclusione iniziale | L'attribuzione è utile, ma non ancora completa |
Il team indaga sulla discrepanza invece di trattarla come un errore di calcolo e individua due cause:
- Il tenant lanciato più di recente ha identificatori a runtime non presenti nella mappatura di business.
- Un workload batch utilizza lo stesso gateway, ma si trova al di fuori del perimetro del namespace originario.
Il team aggiunge la mappatura mancante del tenant, separa il workload batch e ripete il confronto con le finestre temporali allineate. Questa volta si ottiene una copertura del 99% per il perimetro della funzionalità definita, con la varianza residua attribuibile ai tempi di fatturazione del provider.
Ciò che conta non è la percentuale in sé. Il team dispone ora di una spiegazione coerente della cifra, di responsabilità definite per la spesa non mappata e di una procedura di validazione utilizzabile ogni volta che vengono aggiunti nuovi tenant, modelli o workloads.
Vede ancora spesa AI non allocata? Scarichi 5 Reasons AI Costs Don't Add Up e scopra perché tag e SDK non bastano a colmare il divario. Scarichi l'ebook →
6. Testare i casi limite che distorcono le unit economics
Non è sufficiente limitarsi a inviare una richiesta, perché i sistemi AI in produzione possono mostrare comportamenti che influenzano il costo apparente di una funzionalità o di un cliente. Testi almeno:
- Retry dopo errori del provider
- Risposte in streaming
- Prompt o risposte in cache
- Richieste batch
- Più modelli dietro un unico gateway
- Traffico generato da persone e da agenti
- Workloads su GPU condivise
- Connessioni di lunga durata a database o gateway
- Failover tra provider
I workloads Java richiedono un'attenzione particolare, poiché la visibilità eBPF a livello di kernel non è adeguata per il traffico TLS cifrato all'interno della piattaforma Java; per questo scenario Attribute™ ha sviluppato un agente Java. Per conoscere le modalità di deployment supportate, le limitazioni e le verifiche da effettuare dopo l'installazione, consulti la Java Instrumentation Guide.
La validazione non riguarda solo il fatto che il sensore sia in esecuzione: occorre anche verificare che osservi il traffico rilevante per questo workload, nel modo in cui il workload opera realmente.
7. Mantenere la copertura come forma di controllo
La qualità delle attribuzioni varia in base all'ambiente: dopo la validazione del deployment iniziale possono emergere lacune quando vengono aggiunti nuovi tenant, gateway, modelli, namespace o funzionalità.
Istituisca una revisione ricorrente che verifichi:
- Nuovi identificatori osservati privi di mappatura
- Spesa assegnata a una dimensione sconosciuta o condivisa
- Variazioni nella copertura attribuita
- Variazioni impreviste del costo per richiesta o per funzionalità
- Workloads che hanno smesso di inviare dati
- Differenze tra i totali del provider e i totali attribuiti
Consideri la copertura una metrica operativa, non un traguardo da raggiungere una volta sola.
Una checklist pratica di accettazione
Prima di dichiarare un deployment di attribuzione pronto per la produzione, confermi che:
- Le domande di business e le dimensioni rilevanti sono state documentate.
- Il perimetro esatto e l'arco temporale sono chiaramente definiti.
- L'identificatore target è visibile nel percorso del traffico a runtime.
- Cluster, host, account e workloads sono tutti documentati.
- Gli identificatori a runtime hanno nomi leggibili a livello di business.
- La spesa non mappata e non attribuita è visibile.
- L'attività a runtime è riconciliata con i dati forniti dal provider o dal gateway.
- Retry, caching, streaming e workloads condivisi sono stati testati.
- I workloads Java con TLS sono stati valutati correttamente.
- Esiste un responsabile per copertura e varianza, insieme a un calendario di revisione.
Conclusione
L'attribuzione dei costi AI ha valore solo nella misura in cui le persone se ne fidano abbastanza da prendere decisioni basandosi su di essa.
La fiducia nasce da un processo ripetibile: occorre specificare la domanda, delimitare il perimetro, verificare la disponibilità della visibilità a runtime, collegare gli identificatori tecnici al contesto di business, riconciliare le diverse viste, testare i casi limite in produzione e tenere d'occhio la copertura nel tempo.
Attribute™ fornisce il livello di misurazione a runtime per l'AI e per l'infrastruttura condivisa; la qualità dei risultati, tuttavia, dipende comunque dal modello di attribuzione, dal confine della raccolta e dal relativo processo di validazione.
Per i team che passano da fatture AI aggregate al costo per cliente, funzionalità o agente, la validazione non è l'ultimo passo dopo il deployment: è il sistema operativo del programma di misurazione.
