Metrica lipsă dintre tokenuri și cheltuielile cloud

Problema nu este că echipele de AI nu au date despre costuri. Este că tabloul de bord al tokenurilor și factura cloud descriu sisteme diferite, deținute de echipe diferite, fără o modalitate fiabilă de a le conecta.

Un agent de suport poate rezolva un tichet după cinci apeluri de model, un pas de recuperare, două apeluri de instrument și o reluare. Afacerea înregistrează un caz finalizat. Infrastructura înregistrează o serie de cereri, poduri, memorie, timp de accelerator și servicii partajate. Până când aceste înregistrări se întâlnesc, optimizarea costurilor este parțial ghicitoare.

De ce metricile token și facturile cloud spun povești diferite?

Numărătorile de tokenuri sunt utile. Ele arată cât text a primit și a returnat un model și ajută echipele să compare prompturi, modele sau alegeri de rutare. Dar nu îți spun ce s‑a întâmplat în jurul apelului modelului, câtă calculare a susținut recuperarea și utilizarea instrumentelor, câte încercări eșuate au precedat, sau dacă rezultatul final a fost cu adevărat util.

Raportul State of FinOps 2026 arată cât de repede AI a intrat în munca obișnuită de FinOps: 98% dintre respondenți gestionează acum cheltuielile AI, față de 63% în 2025. Dar o linie bugetară mai mare tot nu îți spune ce flux de lucru a ars banii sau de ce. 

Două sarcini de procesare a documentelor pot folosi aproximativ același număr de tokenuri. Una se poate încheia cu o singură cerere de model. Cealaltă poate recupera context din mai multe depozite, apela un serviciu extern, recurge la un alt model și să ruleze din nou documentul după o verificare de validare eșuată pe care utilizatorul nu o vede. Totalurile de tokenuri par similare, în timp ce căile de execuție nu sunt.

Unite.ai a examinat deja de ce numărarea tokenurilor nu reprezintă automat valoarea de afaceri. Pasul următor este să conectăm aceste numărări la sarcinile care le-au generat. În caz contrar, o echipă poate îmbunătăţi costul pe token în timp ce costul pe sarcină finalizată se înrăutăţește.

Cum arată un lanț complet de costuri?

Un lanț de costuri util începe cu rezultatul care contează pentru afacere. Acesta poate fi un caz de suport rezolvat, un document procesat, o modificare de cod acceptată sau un flux de lucru al agentului finalizat. Tot ce se află dedesubt trebuie să aibă o identitate care poate fi urmărită prin sistem.

Stratul de aplicație furnizează prima conexiune. Un ID de cerere, un ID de trasare, un nume de flux de lucru sau un ID de conversație pot lega mai multe operații de model și instrument de o singură bucată de muncă. Fără acest fir, zece evenimente corelate arată ca zece taxe necorelate.

The OpenTelemetry conventions for GenAI agents oferă un vocabular emergent pentru acest strat. Acestea acoperă operații, furnizori, modele solicitate, agenți, conversații, utilizarea tokenurilor, execuția instrumentelor, erori și fluxuri de lucru. Convențiile sunt încă marcate ca în dezvoltare, așa că echipele nu ar trebui să le trateze ca pe un standard universal finalizat. Sunt utile deoarece fac problema corelației concretă.

Apoi vine infrastructura. split cost allocation data for EKS de la AWS poate aloca costuri partajate de calcul și memorie la poduri Kubernetes și expune detalii precum cluster, spațiu de nume, implementare, nod, nume de sarcină și tip de sarcină. Pentru instanțele accelerate suportate, datele acoperă și rezervările GPU, Trainium și Inferentia.

Aceasta este cealaltă jumătate a lanțului. O trasare poate explica ce a încercat să facă aplicația; alocarea Kubernetes poate arăta ce resurse au purtat munca. Ghidul Unite.ai pentru deploying and monitoring LLMs on Kubernetes oferă contextul de producție mai larg, inclusiv alocarea resurselor, scalarea și observabilitatea.

Îmbinarea nu se va întâmpla din întâmplare. Echipele au nevoie de un identificator stabil care să supraviețuiască suficient de mult pentru a conecta telemetria aplicației cu etichetele sarcinilor, înregistrările de alocare sau un alt strat de mapare. Datele clienților nu trebuie să apară în etichetele Kubernetes. Echipele ar trebui să decidă ce identificatori cu cardinalitate redusă pot conecta în siguranță o categorie de flux de lucru, serviciu sau funcționalitate la resursele consumate.

Odată ce contextul aplicației este în loc, echipele pot începe tracking Kubernetes costs by workload și pot conecta namespace‑ul, CPU‑ul, memoria și utilizarea GPU înapoi la munca desfășurată. Acest lucru tot nu îți spune dacă fluxul de lucru a creat valoare de afacere, dar oferă părții de infrastructură a calculului ceva concret la care să se lege. 

Ce metrică unitară ar trebui să aibă încredere afacerea?

Nu există o singură metrică de cost AI pe care fiecare echipă să o folosească. Costul pe token răspunde unei întrebări de consum al modelului. Costul pe pod răspunde unei întrebări de alocare a infrastructurii. Niciuna nu spune unui proprietar de produs dacă funcționalitatea își justifică costul.

Cel mai bun numitor este de obicei cel mai mic rezultat pe care afacerea îl poate defini clar și pe care echipa de produs îl poate influența. O operațiune de suport ar putea urmări costul pe caz rezolvat. Un sistem de documente ar putea folosi costul pe fișier procesat cu succes, în timp ce un asistent de codare ar putea examina costul pe modificare acceptată în loc de costul pe sugestie.

Succesul schimbă matematica.

Un flux de lucru cu un cost scăzut pe încercare poate fi scump dacă eșuează frecvent, declanșează validări repetate sau trimite prea multe cazuri spre revizuire umană. De aceea echipele ar trebui să separe costul pe încercare de costul pe finalizare și, unde este posibil, costul pe rezultat acceptat. Ultimul număr este adesea cel mai util deoarece include munca produsă de sistem, dar pe care afacerea nu a putut să o folosească.

Sistemele de agenți fac acest lucru mai dificil deoarece căile lor pot varia de la o rulare la alta. Analiza Unite.ai a the economics of scaling agentic AI workloads acoperă rutarea, apelurile de instrument, reluările și atribuirea la nivel de flux de lucru. Aceste comportamente aparțin metricii unitare când consumă resurse, chiar dacă utilizatorul final vede doar un singur răspuns.

Metrica tot nu va fi perfectă. Serviciile partajate, rezultatele în cache, sarcinile batch și procesarea întârziată pot estompa atribuția. O estimare utilă pentru decizie este mai bună decât o precizie falsă, mai ales când le spune inginerilor care strat merită investigat.

Cine deține numărul?

Cea mai grea parte poate fi organizatorică. Echipele ML înțeleg apelurile de model și evaluarea. Echipele de platformă înțeleg sarcinile și comportamentul clusterului. FinOps înțelege datele de facturare și regulile de alocare. Echipele de produs știu care rezultat contează.

Nicio echipă nu deține întregul lanț.

Acest lucru creează un argument previzibil despre a cărei tablă de bord îi revine adevărul. Echipa ML poate arăta un consum mai mic de tokenuri, în timp ce echipa de platformă vede ore GPU în creștere și echipa de produs observă mai puține sarcini finalizate decât înainte. Toate cele trei observații pot fi adevărate simultan. Metriul partajat trebuie să explice relația dintre ele.

Un punct de plecare viabil este un flux de lucru de producție cu un eveniment de finalizare clar. Îi atribui un identificator stabil. Transportă acest context prin trasările de model și instrument, mapeaz‑l la serviciul sau sarcina care rulează în Kubernetes și alege un singur numitor de afacere. Apoi adună echipele când numărul se modifică neașteptat.

Acea revizuire contează mai mult decât un tablou de bord lustruit. O creștere bruscă poate proveni din prompturi mai lungi, o nouă cale de fallback, capacitate GPU subutilizată, o politică de autoscalare modificată sau o decizie de produs care trimite mai multă muncă prin funcționalitatea AI. Fiecare cauză aparține unui proprietar diferit.

Automatizarea ar trebui să vină mai târziu. Un motor de recomandări poate acționa doar pe baza etichetelor și pragurilor pe care le primește, iar un numitor greșit poate face un sistem eficient să pară risipitor sau să răsplătească un flux de lucru ieftin pe care utilizatorii îl resping. Echipele au nevoie de vizibilitate partajată suficientă pentru a distinge comportamentul modelului de designul aplicației și alocarea infrastructurii înainte de a permite unui sistem să acționeze pe rezultat. În caz contrar, o corecție automată a costurilor poate reduce capacitatea, crește latența și muta cheltuiala undeva mai puțin vizibil.

Lanțul de costuri trebuie să fie partajat

Controlul costurilor AI va rămâne fragmentat atâta timp cât fiecare echipă optimizează doar stratul pe care îl poate vedea. Tokenurile, trasările, podurile, acceleratoarele și facturile nu sunt măsurători concurente. Ele sunt părți ale aceluiași lanț de costuri.

Companiile care le conectează nu vor obține un număr perfect din prima zi. Ceea ce contează este dacă echipa poate urmări o factură mare înapoi la fluxul de lucru care a generat-o, să înțeleagă ce s‑a schimbat și să decidă dacă rezultatul a justificat costul.