Den manglende måleverdien mellom token og skyforbruk

Problemet er ikke at AI‑team mangler kostnadsdata. Det er at token‑dashbordet og skyregningen beskriver forskjellige systemer, eid av ulike team, uten en pålitelig måte å koble dem sammen.

En supportagent kan løse en sak etter fem modellkall, et hentingssteg, to verktøykall og et nytt forsøk. Virksomheten registrerer én fullført sak. Infrastruktur registrerer en rekke forespørsler, podder, minne, akseleratortid og delte tjenester. Inntil disse registreringene møtes, er kostnadsoptimalisering delvis gjetning.

Hvorfor forteller token‑målinger og skyregninger ulike historier?

Token‑telling er nyttig. Den viser hvor mye tekst en modell mottok og returnerte, og den hjelper team med å sammenligne prompt, modeller eller rutingsvalg. Men den forteller ikke hva som skjedde rundt modellkallet, hvor mye beregning som støttet henting og verktøybruk, hvor mange mislykkede forsøk som kom først, eller om det endelige resultatet var nyttig.

Den State of FinOps 2026 viser hvor raskt AI har beveget seg inn i vanlig FinOps‑arbeid: 98 % av respondentene håndterer nå AI‑utgifter, versus 63 % i 2025. Men en større budsjettlinje forteller fortsatt ikke hvilken arbeidsflyt brukte pengene eller hvorfor. 

To dokumentbehandlingsjobber kan bruke omtrent samme antall token. Den ene kan fullføres med én enkelt modellforespørsel. Den andre kan hente kontekst fra flere lagre, kalle en ekstern tjeneste, falle tilbake på en annen modell, og kjøre dokumentet på nytt etter en mislykket valideringskontroll som brukeren aldri ser. Token‑totalene ser like ut, mens utførelsesveiene er forskjellige.

Unite.ai har allerede undersøkt hvorfor token counts don’t automatically represent business value. Det neste steget er å koble disse tellingene til arbeidsbelastningene som produserte dem. Ellers kan et team forbedre kostnad per token samtidig som kostnaden per fullført oppgave blir dårligere.

Hvordan ser en komplett kostnadskjede ut?

En nyttig kostnadskjede starter med resultatet virksomheten bryr seg om. Det kan være en løst support‑sak, et behandlet dokument, en akseptert kodeendring eller en fullført agent‑arbeidsflyt. Alt under dette trenger en identitet som kan følges gjennom systemet.

Applikasjonslaget gir den første koblingen. En forespørsels‑ID, sporings‑ID, arbeidsflytnavn eller samtale‑ID kan knytte flere modell‑ og verktøysoperasjoner til ett arbeidsstykke. Uten den tråden ser ti relaterte hendelser ut som ti urelaterte kostnader.

The OpenTelemetry conventions for GenAI agents tilbyr et fremvoksende vokabular for dette laget. De dekker operasjoner, leverandører, forespurte modeller, agenter, samtaler, token‑bruk, verktøyutførelse, feil og arbeidsflyter. Konvensjonene er fortsatt merket som under utvikling, så team bør ikke behandle dem som en ferdig universell standard. De er nyttige fordi de gjør korrelasjonsproblemet konkret.

Deretter kommer infrastrukturen. AWS‑s split cost allocation data for EKS kan tilordne delte beregnings‑ og minnekostnader til Kubernetes‑podder og eksponere detaljer som klynge, navnerom, distribusjon, node, arbeidsbelastningsnavn og -type. For støttede akselererte forekomster dekker dataene også GPU‑, Trainium‑ og Inferentia‑reservasjoner.

Det er den andre halvdelen av kjeden. Et spor kan forklare hva applikasjonen prøvde å gjøre; Kubernetes‑allokering kan vise hvilke ressurser som bar arbeidet. Unite.ai‑s guide til deploying and monitoring LLMs on Kubernetes gir den bredere produksjonskonteksten, inkludert ressursallokering, skalering og observabilitet.

Sammenkoblingen vil ikke skje ved et uhell. Team trenger en stabil identifikator som varer lenge nok til å koble applikasjonstelemetri med arbeidsbelastnings‑etiketter, allokerings‑poster eller et annet kartleggingslag. Kundedata hører ikke hjemme i Kubernetes‑tagger. Team bør bestemme hvilke lav‑kardinalitets‑identifikatorer som trygt kan koble en arbeidsflytkategori, tjeneste eller funksjon til ressursene den forbruket.

Når denne applikasjonskonteksten er på plass, kan team begynne å tracking Kubernetes costs by workload og koble navnerom, CPU‑, minne‑ og GPU‑bruk tilbake til arbeidet som utføres. Det forteller fortsatt ikke om arbeidsflyten skapte forretningsverdi, men det gir infrastruktur‑siden av beregningen noe konkret å knytte til. 

Hvilken enhetsmåling bør virksomheten stole på?

Det finnes ingen enkelt AI‑kostnadsmåling som alle team bør bruke. Kostnad per token svarer på et modell‑forbruksspørsmål. Kostnad per pod svarer på et infrastruktur‑allokeringsspørsmål. Ingen av dem forteller en produktsjef om funksjonen tjener seg selv.

Den beste nevneren er vanligvis det minste resultatet virksomheten kan definere tydelig, og som produkteamet kan påvirke. En supportoperasjon kan spore kostnad per løst sak. Et dokumentssystem kan bruke kostnad per vellykket behandlet fil, mens en kodeassistent kan undersøke kostnad per akseptert endring i stedet for kostnad per forslag.

Suksess endrer regnestykket.

En arbeidsflyt med lav kostnad per forsøk kan være dyr hvis den feiler ofte, utløser gjentatte valideringer eller sender for mange saker til menneskelig gjennomgang. Derfor bør team skille kostnad per forsøk fra kostnad per fullføring, og der det er mulig, kostnad per akseptert resultat. Det siste tallet er ofte det mest nyttige fordi det inkluderer arbeidet systemet produserte, men som virksomheten ikke kunne bruke.

Agentsystemer gjør dette vanskeligere fordi deres veier kan endre seg fra en kjøring til den neste. Unite.ai‑s analyse av the economics of scaling agentic AI workloads dekker ruting, verktøykall, gjenforsøk og arbeidsflytnivå‑attribusjon. Disse atferdene tilhører enhetsmålingen når de forbruker ressurser, selv om sluttbrukeren kun ser ett svar.

Målingen vil fortsatt ikke være perfekt. Delte tjenester, bufrede resultater, batch‑jobber og forsinket behandling kan uklare attribusjonen. Et beslutningsnyttig estimat er bedre enn falsk presisjon, spesielt når det forteller ingeniører hvilket lag som fortjener undersøkelser.

Hvem eier tallet?

Den vanskeligste delen kan være organisatorisk. ML‑team forstår modellkall og evaluering. Plattformteam forstår arbeidsbelastninger og klyngeadferd. FinOps forstår faktureringsdata og allokeringsregler. Produkteam vet hvilket resultat som er viktig.

Ingen enkelt team eier hele kjeden.

Det skaper en forutsigbar diskusjon om hvem som har riktig dashbord. ML‑teamet kan peke på lavere token‑bruk, mens plattformteamet ser GPU‑timer stige og produkteamet ser færre fullførte oppgaver enn før. Alle tre observasjonene kan være sanne samtidig. Den delte målingen må forklare forholdet mellom dem.

Et gjennomførbart utgangspunkt er én produksjonsarbeidsflyt med en tydelig fullføringshendelse. Gi den en stabil identifikator. Ta med denne konteksten gjennom modell‑ og verktøyspor, kartlegg den til tjenesten eller arbeidsbelastningen som kjører i Kubernetes, og velg én forretningsnevner. Deretter samler du teamene når tallet endrer seg uventet.

Den gjennomgangen betyr mer enn et polert dashbord. En plutselig økning kan skyldes lengre prompt, en ny fallback‑vei, underutnyttet GPU‑kapasitet, en endret autoskalings‑policy eller en produktbeslutning som sender mer arbeid gjennom AI‑funksjonen. Hver årsak tilhører en annen eier.

Automatisering bør komme senere. En anbefalingsmotor kan kun handle på etikettene og tersklene den mottar, og en dårlig nevner kan få et effektivt system til å fremstå som sløsing eller belønne en billig arbeidsflyt som brukerne avviser. Team trenger tilstrekkelig delt synlighet for å skille modelladferd fra applikasjonsdesign og infrastruktur‑allokering før de lar et system handle på resultatet. Ellers kan en automatisert kostnadsretting redusere kapasitet, øke latens og flytte utgiften til et mindre synlig område.

Kostnadskjeden må deles

AI‑kostnadskontroll vil forbli fragmentert så lenge hvert team kun optimaliserer det laget de kan se. Token, spor, podder, akseleratorer og fakturaer er ikke konkurrerende målinger. De er deler av den samme kostnadskjeden.

Selskapene som kobler dem sammen får ikke et perfekt tall fra første dag. Det som betyr noe er om teamet kan spore en høy faktura tilbake til arbeidsflyten som forårsaket den, finne ut hva som endret seg, og avgjøre om resultatet rettferdiggjorde kostnaden.