Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Perché lanciamo Attribute™

By Vadim SoloveyJul 1, 20266 min read

Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.

Vede la fattura dell'AI. Riesce anche a spiegarla in parte. Ma non può attribuire quella spesa a clienti, team o utenti. Di conseguenza, non è in grado di dire se sta prezzando i propri prodotti con margini sani. Questo scarto - tra ciò che spende e ciò che riesce a rendicontare - è il problema che risolviamo con Attribute™.

L'attribuzione dei costi cloud non è mai stata semplice, soprattutto per le risorse condivise. In quindici anni abbiamo aiutato oltre 4.000 clienti a districare infrastrutture condivise, ad applicare policy di tagging e a costruire modelli di chargeback in grado di reggere qualsiasi verifica. È sempre stato un problema difficile. Con l'AI è diventato ancora più arduo.

L'infrastruttura su cui gira l'AI è stata progettata per velocità e scala, non per l'attribuzione. Gli approcci all'attribuzione su cui il settore si è adagiato nel cloud (i tag) non sono trasferibili. È una realtà architetturale - e richiedeva una risposta di natura diversa.

La trappola della strumentazione

La risposta standard all'attribuzione dei costi è sempre stata la strumentazione. Taggare le risorse. Incapsulare le chiamate API in un SDK. Imporre standard di denominazione. Costruire una pipeline che aggreghi quei segnali in una dashboard.

Per l'infrastruttura cloud tradizionale questo approccio funziona, anche se non alla perfezione. L'infrastruttura condivisa sottostante è relativamente statica. Il modello di ownership è relativamente chiaro. Si può arrivare a un risultato "abbastanza buono", con qualche compromesso.

L'infrastruttura AI fa saltare ogni presupposto su cui quell'approccio si regge.

Un singolo modello gestito serve più clienti contemporaneamente. Un cluster GPU condiviso esegue modelli per più prodotti in parallelo. Un gateway LLM aggrega le richieste di agent, harness e utenti umani in un unico flusso in uscita. Senza contare che un workload agentico può generare sub-agent che innescano costi di infrastruttura senza alcun legame visibile con la voce di fattura AI che li ha originati.

Non esiste un SDK con cui avvolgere una GPU condivisa. Non esiste un tag che sopravviva al passaggio attraverso un proxy LLM. E i workloads AI non si muovono a un ritmo che la strumentazione possa reggere. Un agent può generare mille sub-agent in una notte. Nel tempo di incapsulare in un SDK i nuovi pattern di chiamata e distribuire l'aggiornamento, la fattura è già arrivata.

Il divario di attribuzione nella spesa AI non è un problema di processo da cui si esce a colpi di strumentazione. È una realtà architetturale legata al funzionamento stesso dell'infrastruttura AI.

"Il divario di attribuzione nella spesa AI non è un problema di processo da cui si esce a colpi di strumentazione. È una realtà architetturale legata al funzionamento stesso dell'infrastruttura AI."

È questa l'intuizione che ci ha portati ad Attribute™. Se l'architettura dei workloads AI vanifica la strumentazione per progettazione, allora la strumentazione è la risposta sbagliata. Occorre misurare da un livello che veda tutto - prima di qualsiasi astrazione, prima di qualsiasi proxy, prima di qualsiasi confine di ownership. Occorre misurare a livello di kernel del sistema operativo.

Un approccio diverso

Attribute™ installa un sensore eBPF che opera all'interno del sistema operativo. Osserva il consumo effettivo - ogni token, ogni richiesta al modello, ogni ciclo GPU - nel momento in cui avviene, e riconduce ciascuna unità al processo, al container, al pod e alla richiesta responsabili. Combina poi quei dati con la fatturazione dei provider - Anthropic, OpenAI, Google Gemini e AWS Bedrock - separando automaticamente token cached, reasoning, input e output.

Il risultato è una token economics per cliente, per feature, per agent: generata in modo continuo, senza strumentazione, senza tagging, senza modifiche al codice.

Gli strumenti disponibili oggi (e ce ne sono di validi) si dividono in due filoni: 1. quelli che chiedono agli Engineers di definire la logica di allocazione via codice, e 2. quelli che usano l'inferenza sui metadati per proporre automaticamente tag virtuali.

Entrambi sono un passo avanti rispetto al tagging manuale. Ma nessuno dei due riesce a vedere dentro una GPU condivisa. Nessuno dei due riesce a seguire un token attraverso un gateway LLM fino al cliente o all'utente che lo ha generato. Il problema non è lo strumento. È il metodo.

Qualunque approccio che si affidi ai metadati per ricostruire l'attribuzione andrà a sbattere contro lo stesso muro, perché i metadati non esistono al livello in cui il consumo si verifica davvero.

La misurazione a livello di kernel non è un dettaglio tecnico. È l'unica architettura in grado di produrre un'attribuzione completa su tutta la superficie dell'infrastruttura AI moderna.

Perché Tokenomics è la chiave di lettura giusta

Con questo nuovo approccio stiamo contribuendo attivamente a costruire la categoria della Tokenomics, e parliamo di qualcosa di preciso. Non è AI cost management - di quel dibattito il settore è pieno, ed è in gran parte solo il lessico del FinOps cloud applicato a una nuova voce di spesa.

La Tokenomics è la disciplina che indaga quanto vale davvero ogni token per il business: chi lo ha consumato, che cosa ha prodotto e se la spesa è stata giustificata dal risultato.

Questo richiede attribuzione a livello di token. Non a livello di account. Non a livello di team. A livello di token. Bisogna sapere che una specifica sessione cliente ha consumato 47.000 token su tre modelli, che 31.000 di questi erano in una feature che pesa per l'80% sulla probabilità di rinnovo e che i restanti 16.000 erano in una feature sperimentale non ancora rilasciata in produzione. Sono questi i dati che permettono di decidere con intelligenza dove investire e dove tirare i remi in barca.

A quei dati non si arriva con il tagging. Non si arriva con gli SDK. Ci si arriva solo misurando al livello in cui il consumo si verifica davvero.

La Linux Foundation ha da poco annunciato l'intenzione di lanciare la Tokenomics Foundation, in partnership con la FinOps Foundation, per stabilire standard di settore aperti sull'economia dei token AI. JR Storment, Executive Director della FinOps Foundation e stretto partner di DoiT, lo ha detto senza mezzi termini: dare un nome al problema non equivale a risolverlo.

È proprio così. La categoria ha ora un nome e una casa istituzionale. Attribute™ è il livello di misurazione che la rende operativa.

Perché DoiT, e perché ora

DoiT ha gestito oltre 20 miliardi di dollari di spesa cloud per 4.500 clienti in 27 Paesi. Abbiamo visto emergere ogni grande categoria di costo cloud: ottimizzazione del compute, gestione dei commitments, allocazione dei costi Kubernetes. I team che costruiscono per tempo la giusta base di misurazione prendono decisioni migliori in ogni passaggio successivo. Quelli che rimandano l'attribuzione fino a quando le fatture sono ormai ingenti passano poi anni a ricostruire un contesto che avrebbero potuto avere fin dal primo giorno.

La spesa AI corre più veloce di qualsiasi categoria precedente. La nostra ricerca - un sondaggio su 500 responsabili finance - ha rilevato che il 79% delle aziende ha già registrato sforamenti sui costi AI e che solo il 15% dichiara di riuscire a calcolare accuratamente il ROI dell'AI senza colli di bottiglia significativi. Il momento per dotarsi degli strumenti giusti è adesso, non dopo la prossima fattura a sorpresa.

C'è un secondo segnale che vale la pena mettere a fuoco. Man mano che l'AI passa dalla sperimentazione all'infrastruttura di produzione, le domande cambiano. Non è più "quanto stiamo spendendo" - ma "quanto costa servire ogni singolo cliente", "quali feature AI ci stanno erodendo i margini" e "quali agent stanno bruciando spesa senza produrre nulla di concreto". Il Suo board pone queste domande. Il Suo CFO le pone. Dati di spesa a livello di account danno risposte a livello di account. Un'attribuzione a livello di kernel - per cliente, per agent, per feature - dà il tipo di risposte che cambiano davvero le decisioni.

È per questo che lo abbiamo costruito. Ed è per questo che lo portiamo in DoiT oggi.

Informazioni su Attribute™
Quindici minuti per l'installazione. Nessuna strumentazione richiesta. Token economics entro fine giornata. Per vedere come Attribute™ si comporta nel Suo ambiente, prenoti una demo qui.