Den Manglende Måling Mellem Tokens og Cloud-omkostninger

Problemet er ikke, at AI‑teams mangler omkostningsdata. Det er, at token‑dashboardet og cloud‑regningen beskriver forskellige systemer, som tilhører forskellige teams, uden en pålidelig måde at forbinde dem på.

En supportmedarbejder kan løse én sag efter fem model‑kald, et hentnings‑trin, to værktøjskald og et genforsøg. Virksomheden registrerer én afsluttet sag. Infrastruktur‑laget registrerer en spredning af anmodninger, pods, hukommelse, accelerator‑tid og delte tjenester. Indtil disse registreringer mødes, er omkostningsoptimering delvist gætteri.

Hvorfor fortæller token‑målinger og cloud‑regninger forskellige historier?

Token‑tællinger er nyttige. De viser, hvor meget tekst en model modtog og returnerede, og de hjælper teams med at sammenligne prompts, modeller eller routing‑valg. Men de fortæller dig ikke, hvad der skete omkring model‑kaldet, hvor meget beregning der understøttede hentning og værktøjsbrug, hvor mange mislykkede forsøg der kom først, eller om det endelige resultat var nyttigt.

Den State of FinOps 2026 viser, hvor hurtigt AI er blevet en del af almindeligt FinOps‑arbejde: 98% af respondenterne håndterer nu AI‑udgifter, sammenlignet med 63% i 2025. Men en større budgetpost fortæller stadig ikke, hvilken arbejds‑flow brugte pengene, eller hvorfor. 

To dokument‑behandlingsjobs kan bruge omtrent det samme antal tokens. Den ene kan afslutte med én enkelt model‑anmodning. Den anden kan hente kontekst fra flere lagre, kalde en ekstern tjeneste, falde tilbage på en anden model og køre dokumentet igen efter en mislykket valideringskontrol, som brugeren aldrig ser. Token‑totalerne ser ens ud, mens eksekveringsstierne er forskellige.

Unite.ai har allerede undersøgt, hvorfor token counts don’t automatically represent business value. Det næste skridt er at forbinde disse tællinger med de arbejds‑loads, der producerede dem. Ellers kan et team forbedre omkostning pr. token, mens omkostning pr. afsluttet opgave bliver værre.

Hvordan ser en komplet omkostningskæde ud?

En brugbar omkostningskæde starter med det resultat, virksomheden bekymrer sig om. Det kan være en løst support‑sag, et behandlet dokument, en accepteret kodeændring eller et afsluttet agent‑workflow. Alt nedenunder skal have en identitet, der kan spores gennem systemet.

Applikations‑laget giver den første forbindelse. Et request‑ID, trace‑ID, workflow‑navn eller samtale‑ID kan binde flere model‑ og værktøjs‑operationer til ét stykke arbejde. Uden den tråd ser ti relaterede hændelser ud som ti uafhængige omkostninger.

The OpenTelemetry conventions for GenAI agents tilbyder et fremvoksende ordforråd for dette lag. De dækker operationer, udbydere, anmodede modeller, agenter, samtaler, token‑forbrug, værktøjseksekvering, fejl og workflows. Konventionerne er stadig markeret som under udvikling, så teams bør ikke betragte dem som en færdig universel standard. De er nyttige, fordi de gør korrelations‑problemet konkret.

Derefter kommer infrastrukturen. AWS’s split cost allocation data for EKS kan tildele delte beregnings‑ og hukommelsesomkostninger til Kubernetes‑pods og afsløre detaljer såsom klynge, namespace, deployment, node, arbejds‑load‑navn og arbejds‑load‑type. For understøttede accelerator‑instanser dækker dataene også GPU‑, Trainium‑ og Inferentia‑reservationer.

Det er den anden halvdel af kæden. Et trace kan forklare, hvad applikationen forsøgte at gøre; Kubernetes‑allokering kan vise, hvilke ressourcer bar arbejdet. Unite.ai’s guide til deploying and monitoring LLMs on Kubernetes giver den bredere produktionskontekst, inklusive ressource‑allokering, skalering og observabilitet.

Sammenkoblingen vil ikke ske ved et tilfælde. Teams har brug for en stabil identifikator, der holder længe nok til at forbinde applikations‑telemetri med arbejds‑load‑etiketter, allokerings‑registre eller et andet mappings‑lag. Kundedata hører ikke i Kubernetes‑tags. Teams bør beslutte, hvilke lav‑kardinalitets‑identifikatorer der sikkert kan forbinde en workflow‑kategori, tjeneste eller funktion med de ressourcer, den forbrugte.

Når den applikations‑kontekst er på plads, kan teams begynde at tracking Kubernetes costs by workload og forbinde namespace, CPU, hukommelse og GPU‑forbrug tilbage til det udførte arbejde. Det fortæller stadig ikke, om workflowet skabte forretningsværdi, men det giver infrastruktur‑siden af beregningen noget konkret at knytte til. 

Hvilken Enheds‑Måling Skal Virksomheden Stole På?

Der findes ingen enkelt AI‑omkostningsmåling, som alle teams skal bruge. Omkostning pr. token besvarer et model‑forbrugs‑spørgsmål. Omkostning pr. pod besvarer et infrastruktur‑allokerings‑spørgsmål. Ingen af dem fortæller en produkt‑ejer, om funktionen betaler sig.

Den bedste nævner er normalt det mindste resultat, virksomheden kan definere tydeligt, og som produktteamet kan påvirke. En support‑operation kan spore omkostning pr. løst sag. Et dokumentsystem kan bruge omkostning pr. succesfuldt behandlet fil, mens en kodeassistent kan undersøge omkostning pr. accepteret ændring i stedet for omkostning pr. forslag.

Succes ændrer regnestykket.

Et workflow med lav omkostning pr. forsøg kan være dyrt, hvis det ofte fejler, udløser gentagen validering eller sender for mange sager til menneskelig gennemgang. Derfor bør teams adskille omkostning til forsøg fra omkostning til færdiggørelse og, hvor muligt, omkostning pr. accepteret resultat. Det sidste tal er ofte det mest nyttige, fordi det inkluderer det arbejde, systemet producerede, men som virksomheden ikke kunne bruge.

Agent‑systemer gør dette sværere, fordi deres stier kan ændre sig fra én kørsel til den næste. Unite.ai’s analyse af the economics of scaling agentic AI workloads dækker routing, værktøjskald, genforsøg og workflow‑niveau attribution. Disse adfærdsmønstre hører til i enheds‑målingen, når de forbruger ressourcer, selvom den endelige bruger kun ser ét svar.

Målingen vil stadig ikke være perfekt. Delte tjenester, cachede resultater, batch‑jobs og forsinket behandling kan sløre attributionen. Et beslutnings‑nyttigt estimat er bedre end falsk præcision, især når det fortæller ingeniører, hvilket lag der fortjener undersøgelser.

Hvem Ejer Tallet?

Den sværeste del kan være organisatorisk. ML‑teams forstår model‑kald og evaluering. Platform‑teams forstår arbejds‑loads og klynge‑adfærd. FinOps forstår faktureringsdata og allokeringsregler. Produkt‑teams ved, hvilket resultat der betyder noget.

Intet team ejer den fulde kæde.

Det skaber en forudsigelig debat om, hvis dashboard der er korrekt. ML‑teamet kan pege på lavere token‑forbrug, mens platform‑teamet ser GPU‑timer stige, og produkt‑teamet ser færre afsluttede opgaver end før. Alle tre observationer kan være sande samtidigt. Den delte måling skal forklare forholdet mellem dem.

Et brugbart udgangspunkt er ét produktions‑workflow med en klar afslutnings‑begivenhed. Giv det en stabil identifikator. Bær den kontekst gennem model‑ og værktøjstraces, kortlæg den til den tjeneste eller arbejds‑load, der kører i Kubernetes, og vælg én forretnings‑nævner. Saml derefter teams, når tallet ændrer sig uventet.

Den gennemgang betyder mere end et poleret dashboard. En pludselig stigning kan skyldes længere prompts, en ny fallback‑sti, underudnyttet GPU‑kapacitet, en ændret autoskalings‑politik eller en produkt‑beslutning, der sender mere arbejde gennem AI‑funktionen. Hver årsag tilhører en anden ejer.

Automation bør komme senere. En anbefalings‑engine kan kun handle på de etiketter og tærskler, den modtager, og en dårlig nævner kan få et effektivt system til at fremstå spildfuldt eller belønne et billigt workflow, som brugerne afviser. Teams har brug for tilstrækkelig fælles synlighed til at skelne modeladfærd fra applikationsdesign og infrastruktur‑allokering, før de lader et system handle på resultatet. Ellers kan en automatiseret omkostnings‑rettelse reducere kapaciteten, øge latenstid og flytte udgiften til et mindre synligt sted.

Omkostningskæden Skal Deles

AI‑omkostningsstyring vil forblive fragmenteret, så længe hvert team kun optimerer det lag, de kan se. Tokens, traces, pods, acceleratorer og fakturaer er ikke konkurrerende målinger. De er dele af den samme omkostningskæde.

De virksomheder, der forbinder dem, får ikke et perfekt tal på dag ét. Det, der betyder noget, er om teamet kan spore en høj faktura tilbage til det workflow, der forårsagede den, finde ud af, hvad der ændrede sig, og afgøre om resultatet retfærdiggjorde omkostningen.