Rebooted Solutions
ENFI
AI-avusteinen kehitys

Piilotettu matematiikka LLM-rajapintalaskun takana

Useimmat tiimit huomaavat kustannusongelman vasta kun lasku saapuu. Token-budjetit, kehoteulostaminen ja naiivit integraatiorakenteet voivat muuttaa hyödyllisen AI-ominaisuuden kalliiksi sudenkuopaksi — tässä on, mitä kannattaa katsoa ensin.

Tekoälyominaisuus on toimitettu. Se toimii. Kolme kuukautta myöhemmin API-lasku on nelinkertainen arvioon nähden, eikä kukaan osaa selittää eroa. Tämä on yleisin kaava, jonka näemme auditoidessamme tuotanto-LLM-integraatioita: kustannusmallia ei koskaan suunniteltu — se perittiin prototyypistä, jota ei tarkoitettu skaalautuvaksi.

Ratkaisu ei yleensä ole toimittajan vaihtaminen tai ominaisuuksien karsiminen. Se on kourallinen toteutuspäätöksiä, joista useimmat vie päivän tai alle.

Mistä oikeasti maksat

LLM-toimittajat veloittavat tokeneittain — karkeasti sanottuna sanoittain, välimerkit ja välilyönnit mukaan lukien. Tärkeä yksityiskohta: maksat molemmilta puolilta. Jokainen lähettämäsi token (kehote) ja jokainen mallin palauttama token (vastaus). Useimmissa tuotantokuormituksissa kehote on kustannuksiltaan selvästi vastauksia kalliimpi.

Asiakassuuntautuneessa chat-ominaisuudessa koko keskusteluhistoria sisältyy tyypillisesti jokaiseen pyyntöön, jotta mallilla on konteksti. Jos käyttäjä lähettää kymmenen viestiä 50 tokenin keskipituudella, kymmenennessä viestissä lähetät 500 tokenia historiaa plus järjestelmäkehotteen plus nykyisen viestin — jokaisen kutsun yhteydessä. Tokenilasku kasvaa joka vuoron myötä.

Liian pitkä kehote on yleisin syy

Järjestelmäkehotteet ovat yleisimpiä syyllisiä. Olemme auditoineet tuotantointegraatioita, joissa järjestelmäkehote on 2 000–4 000 tokenia — yksityiskohtaiset ohjeet, reunatapaukset, yritystausta — jokaisen API-kutsun alussa. Ominaisuus, joka käsittelee 10 000 pyyntöä päivässä 3 000 tokenin järjestelmäkehotteella, kuluttaa 30 miljoonaa syötetokenia pelkkään yleiskuormaan ennen kuin käyttäjä on kirjoittanut sanaakaan.

Auditoi järjestelmäkehotteesi. Poista kaikki, mikä selittää mallin oletuskäyttäytymistä, lisää kontekstia jota ei koskaan käytetä tai toistaa ohjeita. Testi on yksinkertainen: poista yksi osio kerrallaan ja tarkista, muuttuvatko tulokset. Useimmiten ne eivät muutu.

Tarkista sitten keskusteluhistoria. Täyttä historiaa ei tarvita lähes koskaan. Useimmat tehtävät toimivat viimeisten kolmen tai viiden vuoron kontekstilla. Liukuva ikkuna kovalla token-rajalla vie päivän toteuttaa ja vähentää kontekstitokeneja tyypillisesti 60–70 % pitkäkestoisessa chat-ominaisuudessa.

Kehotevälimuistitus: optimointi, jonka useimmat ohittavat

Molemmat suuret LLM-toimittajat tarjoavat kehotevälimuistittamisen: mekanismin, jolla voit merkitä kehotteen staattisen osan välimuistittavaksi, jolloin maksat vain murto-osan normaalista syötetoken-hinnasta cache-osumista. Ominaisuuksille, joissa on pitkä ja pysyvä järjestelmäkehote — tukiassistentti, dokumenttianalyysipätkä, sisäinen tietopankki — luvut ovat merkittäviä. Anthropic veloittaa cache-osumista noin 10 % normaalista syötetoken-hinnasta; OpenAI on samassa suuruusluokassa.

Toteutus on yksi parametrimuutos SDK:ssa. Jos sinulla on 2 000 tokenin järjestelmäkehote jokaisessa kutsussa ja cache-osumasi on 80 %, olet vähentänyt tuon osan tehokkaita syötekustannuksia 80 prosentilla. Useimmat LLM-ominaisuuksia rakentavat tiimit eivät tänä päivänä käytä kehotevälimuistittamista. Useimmat tiimit, jotka alkavat käyttää sitä, vähentävät kuukausittaisia API-kustannuksia 30–50 % ensimmäisessä laskutussyklissä.

Mallinporrastus: kaikki pyynnöt eivät tarvitse parasta malliasi

Hintaero frontier-mallin ja keskiluokan mallin välillä saman toimittajan valikoimassa on tyypillisesti 5–10-kertainen tokenilta. Kykyero useimmissa tuotantotehtävissä on pienempi kuin tuo ero antaa ymmärtää.

Luokittelu, intentiotunnistus, lyhyiden rakenteiden tiivistäminen ja reititysratkaisut eivät hyödy frontier-mallista. Pienempi malli hoitaa ne murto-osalla kustannuksista vastaavalla tarkkuudella. Jos käsittelet 100 000 pyyntöä päivässä ja 60 % on reititys- tai luokittelutehtäviä, tasojen välinen kustannusero on merkittävä. Rakenna integraatiosi mallin konfiguraatioparametriksi, reititä tehtävän monimutkaisuuden mukaan ja testaa laadun kompromissi empiirisesti ennen muutokseen sitoutumista. Tämä ei ole ennenaikaista optimointia — se on kertaluonteinen toteutus, joka maksaa itsensä takaisin viikoissa.

Kun lasku kertoo, että jokin on pielessä

Kustannusseuranta paljastaa tietyn luokan vikoja, joita toiminnalliset testisarjat eivät nappaa. Perimmme kerran tuotantointegraation, jossa vastauksen keskipituus oli 3 000 tokenia. Ominaisuus oli lyhytvastaus-Q&A-työkalu. Juurisyy: ei max_tokens-rajoitusta vastaukselle. Malli tuotti oletuksena täydelliset selitykset, koska mikään ei kertonut sen muuta. Yksi parametrimuutos vähensi ominaisuuden vastaustoken-kustannuksia 80 prosentilla.

Instrumentoi tokenien käyttö ominaisuuksittain ja kutsukohtaisesti ennen kaikkea muuta. Äkillinen nousu kehotteen keskipituudessa tarkoittaa yleensä, että koodimuutos ruiskuttaa kontekstia, jota ei pitäisi olla. Nousu vastauksen pituudessa tarkoittaa yleensä, että kehotteen muutos rikkoi odotetun tulosformaatin. Kustannusdata on välitysmuuttuja kehotteiden terveydelle — ja se havaitsee ongelmat, jotka ovat näkymättömiä toiminnallisessa testauksessa.

Nämä eivät ole esoteerisia optimointeja. Jokainen tiimi, jonka kanssa olemme rakentaneet LLM-ominaisuuksia tuotantoon, on hyötynyt vähintään kahdesta näistä. Järjestys on tärkeä: instrumentoi ensin, tunnista sitten suurin hukkalähde, korjaa se. Säästöt kertautuvat, koska jokainen muutos vähentää perustasoa seuraavalle.

Rebooted Solutions auditoi LLM-integraatioita osana AI-auditointipalveluamme — käymme läpi token-budjetit, välimuistitusstrategiat, mallinvalinnan ja kehotteiden arkkitehtuurin tuotantojärjestelmissä. Jos API-laskusi kasvaa nopeammin kuin käyttäjämääräsi, ota yhteyttä ja sovitaan sessio.

Kirjoittaja

Henri Parkkonen

Operatiivinen johtaja, osakas

Henri vastaa toimituksesta — automaatioista, full-stack-rakentamisesta ja Claude Code -työpajoista. Kirjoittaa työkaluvalinnoista ja siitä, miten ne kestävät todellisessa käytössä.

Profiili