De ontbrekende metriek tussen tokens en clouduitgaven

Het probleem is niet dat AI‑teams geen kostengegevens hebben. Het is dat het token‑dashboard en de cloudfactuur verschillende systemen beschrijven, die eigendom zijn van verschillende teams, zonder een betrouwbare manier om ze met elkaar te verbinden.

Een supportmedewerker kan één ticket oplossen na vijf modelaanroepen, een opzoekstap, twee tool‑aanroepen en een herpoging. Het bedrijf registreert één afgerond geval. De infrastructuur registreert een wirwar van verzoeken, pods, geheugen, accelerator‑tijd en gedeelde services. Totdat die gegevens overeenkomen, is kostenoptimalisatie deels giswerk.

Waarom vertellen token‑metriek en cloudfacturen verschillende verhalen?

Token‑aantallen zijn nuttig. Ze laten zien hoeveel tekst een model heeft ontvangen en teruggegeven, en ze helpen teams om prompts, modellen of routeringskeuzes te vergelijken. Maar ze vertellen niet wat er rondom de modelaanroep gebeurde, hoeveel rekenkracht het ophalen en het gebruik van tools ondersteunde, hoeveel mislukte pogingen er eerst waren, of of het uiteindelijke resultaat iets bruikbaars deed.

De State of FinOps 2026 laat zien hoe snel AI is doorgedrongen tot gewoon FinOps‑werk: 98 % van de respondenten beheert nu AI‑uitgaven, tegenover 63 % in 2025. Maar een grotere budgetpost vertelt nog steeds niet welke workflow het geld verbrandde of waarom.

Two document‑verwerkingsjobs kunnen ongeveer evenveel tokens gebruiken. De ene kan eindigen met één enkele modelaanroep. De andere kan context ophalen uit meerdere opslagplaatsen, een externe service aanroepen, terugvallen op een ander model, en het document opnieuw uitvoeren na een mislukte validatiecontrole die de gebruiker nooit ziet. De token‑totalen lijken gelijk, terwijl de uitvoerpaden dat niet doen.

Unite.ai heeft al onderzocht waarom token‑aantallen niet automatisch bedrijfswaarde vertegenwoordigen. token counts don’t automatically represent business value. De volgende stap is die aantallen te koppelen aan de workloads die ze hebben geproduceerd. Anders kan een team de kosten per token verbeteren terwijl de kosten per voltooide taak verslechteren.

Hoe ziet een volledige kostenketen eruit?

Een bruikbare kostenketen begint met de uitkomst die voor het bedrijf belangrijk is. Dat kan een opgelost support‑ticket zijn, een verwerkt document, een geaccepteerde code‑wijziging, of een voltooid agent‑workflow. Alles eronder moet een identiteit hebben die door het systeem kan worden gevolgd.

De applicatielaag biedt de eerste verbinding. Een request‑ID, trace‑ID, workflow‑naam of gesprek‑ID kan verschillende model‑ en tool‑operaties aan één werkstuk koppelen. Zonder die draad lijken tien gerelateerde gebeurtenissen op tien losstaande kosten.

De OpenTelemetry conventions for GenAI agents bieden een opkomend vocabularium voor deze laag. Ze omvatten operaties, providers, aangevraagde modellen, agents, gesprekken, token‑gebruik, tool‑uitvoering, fouten en workflows. De conventies staan nog gemarkeerd als in ontwikkeling, dus teams moeten ze niet beschouwen als een afgewerkte universele standaard. Ze zijn nuttig omdat ze het correlatieprobleem concreet maken.

Daarna volgt de infrastructuur. De split‑cost‑allocation‑data van AWS voor EKS kan gedeelde compute‑ en geheugen‑kosten toewijzen aan Kubernetes‑pods en details blootleggen zoals cluster, namespace, deployment, node, workload‑naam en workload‑type. Voor ondersteunde versnelde instances omvat de data ook reserveringen voor GPU’s, Trainium en Inferentia.

Dat is de andere helft van de keten. Een trace kan uitleggen wat de applicatie probeerde te doen; Kubernetes‑allocatie kan laten zien welke resources het werk droegen. De gids van Unite.ai over het deploying and monitoring LLMs on Kubernetes biedt de bredere productie‑context, inclusief resource‑allocatie, schaalvergroting en observabiliteit.

De koppeling zal niet per ongeluk ontstaan. Teams hebben een stabiele identifier nodig die lang genoeg blijft bestaan om applicatie‑telemetrie te verbinden met workload‑labels, allocatie‑records of een andere mapping‑laag. Klantgegevens horen niet in Kubernetes‑tags. Teams moeten bepalen welke low‑cardinality‑identifiers veilig een workflow‑categorie, service of functie kunnen koppelen aan de verbruikte resources.

Nadat die applicatie‑context aanwezig is, kunnen teams beginnen met het volgen van Kubernetes‑kosten per workload en namespace, CPU-, geheugen‑ en GPU‑gebruik koppelen aan het uitgevoerde werk. Dat vertelt nog steeds niet of de workflow bedrijfswaarde creëerde, maar het geeft de infrastructuurkant van de berekening iets concreets om aan te hechten.

Welke eenheidsmetriek moet het bedrijf vertrouwen?

Er bestaat geen enkele AI‑kostmetriek die elk team moet gebruiken. Kosten per token beantwoorden een model‑consumptievraag. Kosten per pod beantwoorden een infrastructuur‑allocatievraag. Geen van beide vertelt een producteigenaar of de functie zichzelf rechtvaardigt.

De beste noemer is meestal de kleinste uitkomst die het bedrijf duidelijk kan definiëren en die het productteam kan beïnvloeden. Een support‑operatie kan kosten per opgelost ticket bijhouden. Een documentsysteem kan kosten per succesvol verwerkt bestand gebruiken, terwijl een code‑assistent kosten per geaccepteerde wijziging kan onderzoeken in plaats van kosten per suggestie.

Succes verandert de berekening.

Een workflow met lage kosten per poging kan duur zijn als deze vaak faalt, herhaalde validaties veroorzaakt of te veel gevallen naar menselijke beoordeling stuurt. Daarom moeten teams de kosten per poging scheiden van de kosten per voltooiing en, waar mogelijk, kosten per geaccepteerde uitkomst. Het laatste cijfer is vaak het meest bruikbaar omdat het het werk omvat dat het systeem produceerde maar dat het bedrijf niet kon gebruiken.

Agent‑systemen maken dit moeilijker omdat hun paden van de ene uitvoering naar de volgende kunnen veranderen. De analyse van Unite.ai over the economics of scaling agentic AI workloads behandelt routering, tool‑aanroepen, retries en workflow‑niveau‑toewijzing. Die gedragingen behoren tot de eenheidsmetriek wanneer ze resources verbruiken, zelfs als de eindgebruiker slechts één antwoord ziet.

De metriek zal nog steeds niet perfect zijn. Gedeelde services, gecachte resultaten, batch‑jobs en vertraagde verwerking kunnen toewijzing vertroebelen. Een besluit‑bruikbare schatting is beter dan valse precisie, vooral wanneer het engineers vertelt welke laag nader onderzoek verdient.

Wie bezit het cijfer?

Het moeilijkste deel kan organisatorisch zijn. ML‑teams begrijpen model‑aanroepen en evaluatie. Platform‑teams begrijpen workloads en cluster‑gedrag. FinOps begrijpt facturatie‑data en allocatieregels. Product‑teams weten welke uitkomst belangrijk is.

Geen enkel team bezit de volledige keten.

Dat leidt tot een voorspelbaar debat over wiens dashboard correct is. Het ML‑team kan wijzen op lager token‑gebruik, terwijl het platform‑team stijgende GPU‑uren ziet en het product‑team minder voltooide taken dan voorheen. Alle drie observaties kunnen tegelijk waar zijn. De gedeelde metriek moet de relatie tussen hen verklaren.

Een bruikbare startpunt is één productie‑workflow met een duidelijk voltooiings‑event. Geef het een stabiele identifier. Neem die context mee door de model‑ en tool‑traces, koppel het aan de service of workload die draait in Kubernetes, en kies één bedrijfsnoemer. Breng vervolgens de teams samen wanneer het cijfer onverwacht verandert.

Die beoordeling is belangrijker dan een gepolijst dashboard. Een plotselinge stijging kan voortkomen uit langere prompts, een nieuw fallback‑pad, onderbenutte GPU‑capaciteit, een gewijzigde autoscaling‑policy, of een productbeslissing die meer werk door de AI‑functie stuurt. Elke oorzaak behoort tot een andere eigenaar.

Automatisering moet later komen. Een aanbevelingsengine kan alleen handelen op basis van de labels en drempels die hij ontvangt, en een slechte noemer kan een efficiënt systeem er verspild uit laten zien of een goedkope workflow belonen die gebruikers afwijzen. Teams hebben voldoende gedeelde zichtbaarheid nodig om modelgedrag te onderscheiden van applicatie‑ontwerp en infrastructuur‑allocatie voordat ze een systeem op het resultaat laten reageren. Anders kan een geautomatiseerde kostencorrectie de capaciteit verminderen, de latency verhogen en de uitgave verplaatsen naar een minder zichtbare plek.

De kostenketen moet worden gedeeld

AI‑kostbeheersing zal gefragmenteerd blijven zolang elk team alleen de laag optimaliseert die het kan zien. Tokens, traces, pods, accelerators en facturen zijn geen concurrerende metingen. Het zijn onderdelen van dezelfde kostenketen.

De bedrijven die ze met elkaar verbinden, zullen niet op de eerste dag een perfect cijfer krijgen. Het gaat erom of het team een hoge factuur kan terugvoeren naar de workflow die het veroorzaakte, kan achterhalen wat er veranderd is, en kan bepalen of het resultaat de kosten rechtvaardigde.