Puuttuva mittari tokenien ja pilvikulujen välillä

Ongelma ei ole, että tekoälytiimeillä ei ole kustannustietoja. Ongelma on, että tokenien hallintapaneeli ja pilvilasku kuvaavat eri järjestelmiä, jotka kuuluvat eri tiimeille, eikä niillä ole luotettavaa tapaa yhdistää niitä.

Tukihenkilö voi ratkaista yhden tiketin viiden mallikutsun, yhden haun, kahden työkalukutsun ja yhden uudelleenyrityksen jälkeen. Liiketoiminta kirjaa yhden valmiin tapauksen. Infrastruktuuri kirjaa hajanaisia pyyntöjä, podseja, muistia, kiihdytysaikaa ja jaettuja palveluita. Kun nämä tiedot eivät kohtaa, kustannusoptimointi on osittain arvailua.

Miksi tokenimittarit ja pilvilaskut kertovat eri tarinoita?

Tokenimäärät ovat hyödyllisiä. Ne näyttävät, kuinka paljon tekstiä malli vastaanotti ja palautti, ja ne auttavat tiimejä vertailemaan kehotteita, malleja tai reititysvaihtoehtoja. Mutta ne eivät kerro, mitä tapahtui mallikutsun ympärillä, kuinka paljon laskentatehoa tuki hakua ja työkalujen käyttöä, kuinka monta epäonnistunutta yritystä tapahtui ensin, tai oliko lopputulos hyödyllinen.

The State of FinOps 2026 osoittaa, kuinka nopeasti tekoäly on siirtynyt tavalliseen FinOps-työhön: 98 % vastaajista hallitsee nyt tekoälykuluja, verrattuna 63 %:iin vuonna 2025. Mutta suurempi budjettirivi ei silti kerro, mikä työnkulku poltti rahaa tai miksi. 

Kaksi asiakirjankäsittelytyötä voi käyttää suunnilleen saman määrän tokeneita. Yksi voi päättyä yhteen mallipyyntöön. Toinen voi hakea kontekstia useista varastoista, kutsua ulkoista palvelua, siirtyä toiseen malliin ja suorittaa asiakirjan uudelleen epäonnistuneen validointitarkistuksen jälkeen, jonka käyttäjä ei koskaan näe. Tokenien kokonaismäärät näyttävät samankaltaisilta, mutta toteutuspolut eivät ole.

Unite.ai on jo tutkinut, miksi tokenimäärät eivät automaattisesti edusta liiketoiminnan arvoa. Seuraava vaihe on yhdistää nämä määrät niiden tuottaneisiin työkuormiin. Muuten tiimi voi parantaa kustannusta per token, mutta heikentää valmiin tehtävän kustannusta.

Miltä täydellinen kustannusketju näyttää?

Hyödyllinen kustannusketju alkaa liiketoimintaa kiinnostavasta tuloksesta. Se voi olla ratkaistu tukipyyntö, käsitelty asiakirja, hyväksytty koodimuutos tai valmis agenttityönkulku. Kaikki sen alapuolella tarvitsee tunnisteen, jota voidaan seurata järjestelmän läpi.

Sovelluskerros tarjoaa ensimmäisen yhteyden. Pyyntö‑tunnus, jäljitystunnus, työnkulun nimi tai keskustelutunnus voivat yhdistää useita mallin ja työkalun operaatioita yhteen työyksikköön. Ilman tätä lankaa kymmenen toisiinsa liittyvää tapahtumaa näyttää kymmeneltä erilliseltä maksulta.

The OpenTelemetry‑konventiot GenAI‑agenteille tarjoavat nousevan sanaston tälle kerrokselle. Ne kattavat operaatioita, tarjoajia, pyydettyjä malleja, agenteja, keskusteluja, token‑käyttöä, työkalujen suorittamista, virheitä ja työnkulkuja. Konventiot ovat edelleen kehitysvaiheessa, joten tiimien ei tulisi pitää niitä valmiina universaalina standardina. Ne ovat hyödyllisiä, koska ne konkretisoivat korrelaatio‑ongelman.

Then comes infrastructure. AWS’s EKS:n eritellyt kustannusten kohdistustiedot voi kohdistaa jaetut laskenta‑ ja muistikulut Kubernetes‑podeille ja paljastaa tietoja, kuten klusteri, nimiavaruus, käyttöönotto, solmu, työkuorman nimi ja tyyppi. Tuetuille kiihdytyksellisille instansseille tiedot kattavat myös GPU‑, Trainium‑ ja Inferentia‑varaukset.

Tämä on ketjun toinen puoli. Jäljitys voi selittää, mitä sovellus yritti tehdä, ja Kubernetesin resurssikohdistus voi osoittaa, millä resursseilla työ tehtiin. Unite.ai:n opas aiheesta LLM-mallien käyttöönotto ja valvonta Kubernetesissa antaa laajemman tuotantokontekstin, johon kuuluvat resurssien kohdistaminen, skaalaaminen ja havainnoitavuus.

Yhteys ei synny itsestään. Tiimit tarvitsevat vakaan tunnisteen, joka säilyy riittävän pitkään yhdistääkseen sovellustelemetrian työkuormien tunnisteisiin, kohdistustietoihin tai muuhun yhdistämiskerrokseen. Asiakastiedot eivät kuulu Kubernetes-tunnisteisiin. Tiimien on päätettävä, mitkä vähäisen kardinaliteetin tunnisteet voivat turvallisesti yhdistää työnkulkuluokan, palvelun tai ominaisuuden sen käyttämiin resursseihin.

Kun sovelluksen asiayhteys on mukana, tiimit voivat aloittaa Kubernetes-kustannusten seuranta työkuormittain ja yhdistää nimiavaruuden sekä suorittimen, muistin ja GPU:n käytön takaisin tehtävään työhön. Se ei vielä kerro, loiko työnkulku liiketoiminta-arvoa, mutta antaa laskelman infrastruktuuripuolelle konkreettisen kohteen. 

Mihin yksikkömittariin liiketoiminnan tulisi luottaa?

Ei ole yhtä ainoaa tekoälykustannusmittaria, jota jokaisen tiimin tulisi käyttää. Kustannus per token vastaa mallin kulutuskysymykseen. Kustannus per pod vastaa infrastruktuurin allokointikysymykseen. Kumpikaan ei kerro tuoteomistajalle, tuottaako ominaisuus riittävän arvon.

Paras nimittäjä on yleensä pienin tulos, jonka liiketoiminta voi määritellä selvästi ja johon tuotetiimi voi vaikuttaa. Tukipalvelu voi seurata kustannusta ratkaistua tapausta kohti. Dokumenttijärjestelmä voi käyttää kustannusta onnistuneesti käsiteltyä tiedostoa kohti, ja koodiavustaja voi tarkastella kustannusta hyväksyttyä muutosta, ei ehdotusta, kohti.

Onnistuminen muuttaa laskelmaa.

Työnkulku, jonka kustannus yritystä kohti on pieni, voi olla kallis, jos se epäonnistuu usein, aiheuttaa toistuvia tarkistuksia tai lähettää liian monta tapausta ihmisen arvioitavaksi. Siksi tiimien tulee erottaa yrityksen kustannus onnistuneen suorituksen kustannuksesta ja mahdollisuuksien mukaan hyväksytyn tuloksen kustannuksesta. Viimeinen luku on usein hyödyllisin, sillä se huomioi myös työn, jonka järjestelmä teki mutta jota liiketoiminta ei voinut käyttää.

Agenttijärjestelmät tekevät tästä vaikeampaa, koska niiden kulkureitit voivat muuttua suorituksesta toiseen. Unite.ai:n analyysi aiheesta agenttipohjaisen tekoälyn työkuormien skaalaamisen talous käsittelee reititystä, työkalukutsuja, uudelleenyrityksiä ja työnkulkutason kohdistusta. Nämä toiminnot kuuluvat yksikkömittariin aina kun ne kuluttavat resursseja, vaikka loppukäyttäjä näkisi vain yhden vastauksen.

Mittarista ei silti tule täydellistä. Jaetut palvelut, välimuistitulokset, eräajot ja viivästetty käsittely voivat hämärtää kohdistusta. Päätöksenteossa hyödyllinen arvio on parempi kuin näennäinen tarkkuus, varsinkin jos se kertoo insinööreille, mitä kerrosta kannattaa tutkia.

Kuka omistaa luvun?

Vaikein osa voi olla organisatorinen. Koneoppimistiimit tuntevat mallikutsut ja arvioinnin. Alustatiimit tuntevat työkuormat ja klusterien toiminnan. FinOps tuntee laskutustiedot ja kohdistussäännöt. Tuotetiimit tietävät, mikä tulos on tärkeä.

Mikään yksittäinen tiimi ei hallitse koko ketjua.

Tästä syntyy ennakoitava kiista siitä, kenen näkymä on oikeassa. Koneoppimistiimi voi osoittaa tokenien käytön vähentyneen, kun alustatiimi näkee GPU-tuntien kasvavan ja tuotetiimi aiempaa vähemmän valmistuneita tehtäviä. Kaikki kolme havaintoa voivat olla samanaikaisesti totta. Yhteisen mittarin on selitettävä niiden välinen suhde.

Toimiva lähtökohta on yksi tuotannon työnkulku, jolla on selvä valmistumistapahtuma. Anna sille vakaa tunniste. Vie tämä konteksti malli- ja työkalujäljitysten läpi, yhdistä se Kubernetesissa toimivaan palveluun tai työkuormaan ja valitse yksi liiketoiminnan nimittäjä. Kokoa sitten tiimit yhteen, kun luku muuttuu odottamattomasti.

Tämä arviointi on tärkeämpää kuin viimeistelty koontinäyttö. Äkillinen nousu voi johtua pidemmistä kehotteista, uudesta varareitistä, vajaakäyttöisestä GPU-kapasiteetista, muuttuneesta automaattisesta skaalauskäytännöstä tai tuotepäätöksestä, joka ohjaa enemmän työtä tekoälyominaisuuden kautta. Jokaisella syyllä on eri vastuuhenkilö.

Automaatio kuuluu myöhempään vaiheeseen. Suositusjärjestelmä voi toimia vain saamiensa tunnisteiden ja raja-arvojen perusteella. Väärä nimittäjä voi saada tehokkaan järjestelmän näyttämään tuhlaavalta tai palkita halvan työnkulun, jonka tuloksia käyttäjät eivät hyväksy. Tiimit tarvitsevat riittävän yhteisen näkyvyyden erottaakseen mallin käyttäytymisen sovellussuunnittelusta ja infrastruktuurin resurssikohdistuksesta ennen kuin ne antavat järjestelmän toimia tuloksen perusteella. Muuten automaattinen kustannuskorjaus voi vähentää kapasiteettia, lisätä viivettä ja siirtää kulut vähemmän näkyvään paikkaan.

Kustannusketjun on oltava jaettu

Tekoälyn kustannusten hallinta pysyy hajanaisena niin kauan kuin jokainen tiimi optimoi vain näkyvissään olevaa kerrosta. Tokenit, jäljitykset, podit, kiihdyttimet ja laskut eivät ole kilpailevia mittareita. Ne ovat saman kustannusketjun osia.

Ne yhdistävät yritykset eivät saa täydellistä lukua heti ensimmäisenä päivänä. Ratkaisevaa on, pystyykö tiimi jäljittämään suuren laskun sen aiheuttaneeseen työnkulkuun, selvittämään mikä muuttui ja päättämään, oliko tulos kustannusten arvoinen.