Kako zgraditi knjigo stroškov LLM za posamezno ekipo v več API-jih AI

Nadzorne plošče ponudnika vam lahko povedo, koliko je organizacija porabila. Redko odgovorijo na vprašanje, ki ga ekipe za finance in platforme dejansko potrebujejo: katera ekipa, izdelek, okolje, delovna obremenitev ali segment strank je povzročil porabo in ali je bila ta poraba pričakovana.

Trajni vzorec ni še ena nadzorna plošča. To je notranja knjiga stroškov: sistem zapisov, ki združuje metapodatke zahtev na strani aplikacije, ključe API v obsegu, podatke o uporabi ponudnika in skupne zneske zaračunavanja na ravni računa. Glavna knjiga daje inženirskim ekipam operativno vidljivost v skoraj realnem času, medtem ko daje financam usklajen pogled, ki lahko podpira proračune, dodelitve in povratne bremenitve.

V tem članku je predstavljena praktična arhitektura za ekipe, ki uporabljajo več kot en AI API, vključno s pogodbo o označevanju, tokom zahtev, tabelami, postopkom usklajevanja, kontrolami in kompromisi.

Težava: zaračunavanje ponudnika je natančno, vendar ga ni vedno mogoče dodeliti

Večina ponudnikov umetne inteligence razkriva nekatere kombinacije nadzornih plošč za uporabo, API-jev za uporabo, izvozov obračunavanja, projektov, delovnih prostorov, računov storitev ali stroškovnih API-jev. Ta orodja so uporabna, vendar ne delujejo vsa na enaki ravni podrobnosti.

Dejstva

• Nekatere končne točke stroškov ponudnika so zasnovane za finančno poročanje in lahko porabo razčlenijo po vrstičnih postavkah računa, projektih ali obračunskih obdobjih.
• API-ji za uporabo pogosto zagotavljajo operativne podrobnosti, vendar se zapisi o uporabi in zapisi o končnih stroških morda ne bodo popolnoma uskladili zaradi popustov, dobropisov, zakasnjenega obračunavanja, cen obvez, paketnih stopenj, cen predpomnilnika ali prilagoditev računov.
• Domorodne skrbniške meje, kot so projekti, delovni prostori, storitveni računi, API ključi ali principali IAM, lahko pomagajo pri dodelitvi porabe, vendar se natančne zmogljivosti razlikujejo glede na ponudnika.
• Pri nekaterih platformah se metapodatki za posamezno zahtevo prikažejo v dnevnikih klicev namesto v poročilih o dodelitvi stroškov. Ekipe morajo združiti dnevnike in uporabiti cene za oceno stroškov na ravni zahteve.

Priporočilo

Podatke ponudnika obravnavajte kot vhod, ne kot celoten sistem. Zgradite notranjo knjigo, ki lahko odgovori na operativna in finančna vprašanja, nato pa jo vsak dan uskladite z viri stroškov ponudnika.

Arhitektura Ledgerja

Knjiga stroškov ima pet glavnih komponent:

1. Stabilna shema dimenzij stroškov.
2. Poverilnice v obsegu in pravila usmerjanja.
3. Zajem metapodatkov na ravni zahteve.
4. Uporaba ponudnika in vnos stroškov.
5. Dnevno usklajevanje in uveljavljanje pravilnika.

Cilj je ustvariti dva povezana pogleda: ocenjeno knjigo na zahtevo za operacije in usklajeno dnevno knjigo za finance.

To je običajen gradnik v širšem AI API nadzoru stroškov, ker povezuje inženirsko telemetrijo s finančno odgovornostjo, ne da bi bil odvisen od modela poročanja enega samega ponudnika.

1. korak: Določite razsežnosti stroškov pred izdelavo nadzornih plošč

Začnite z dimenzijami, ki jih bodo skupine za finance, inženiring, izdelke in varnost dosledno uporabljale. Naredite to, preden izberete grafikone ali napišete opravila za vnos.

Praktična shema običajno vključuje:

• team_id: lastna inženirska ali poslovna ekipa.
• product_id: izdelek, področje funkcije ali notranja platforma, ki uporablja API.
• okolje: produkcija, uprizarjanje, razvoj, peskovnik, demo ali test.
• delovna obremenitev: klepet, povzemanje, ekstrakcija, klasifikacija, ustvarjanje kode, vrednotenje, vdelava, prerazvrščanje ali paketna obdelava.
• customer_segment: poslovni, srednji trg, brezplačni preizkus, interni, partnerski ali drugi odobreni segmenti.
• budget_owner: oseba, ekipa ali stroškovno mesto, odgovorno za porabo.
• ponudnik: ponudnik AI API, uporabljen za zahtevo.
• model: natančen identifikator modela ali uvedbe.
• request_class: interaktivno, v ozadju, v paketu, znova, nadomestno, ocenjevanje ali skrbništvo.

Shema naj bo dovolj majhna, da jo bodo inženirji dejansko zapolnili. Dodajte upravljanje, da preprečite premikanje poljubnega besedila. Na primer, team_id mora izhajati iz notranjega registra ekipe, ne iz poljubnih glav zahtev.

Podrobnosti o izvedbi

Predstavi dimenzije kot pogodbo z različicami. Zahteva, ki nima zahtevanih proizvodnih oznak, se ne sme zapreti na prehodu ali pa se usmeri v jasno poimenovano karantensko vedro, ki se dnevno pregleduje.

{
  "schema_version": "2025-01",
  "team_id": "platform-ai",
  "product_id": "support-assistant",
  "environment": "production",
  "workload": "summarization",
  "customer_segment": "enterprise",
  "budget_owner": "cost-center-4812",
  "request_class": "interactive"
}

2. korak: Izdaja omejenih ključev po skupini in okolju

Skupni monolitni API ključi naredijo porazdelitev stroškov krhko. Če vsaka storitev uporablja isto poverilnico, finance ne morejo zanesljivo pripisati porabe in skupine platform ne morejo onemogočiti ene delovne obremenitve, ne da bi to vplivalo na nepovezane sisteme.

Uporabite poverilnice v obsegu, kjer koli je to mogoče:

• En ključ ali storitveni račun na ekipo in okolje.
• Ločene poverilnice za produkcijske in neprodukcijske delovne obremenitve.
• Ločene poverilnice za visoko tvegane poskuse, ocene in paketna opravila.
• Izvorni projekti ali delovni prostori ponudnika, ko se čisto preslikajo v notranje lastništvo.

To ne pomeni, da vsaka mikrostoritev potrebuje edinstven račun ponudnika. Preveč meja povzroča operativne stroške. Uporabna enota je meja, kjer se razlikujejo lastništvo, proračun in operativni odziv.

Varnostna opomba

API ključev in varnostnih žetonov ne smete pošiljati v URL-jih, ker so URL-ji običajno zajeti v dnevnikih, proxyjih, analitičnih orodjih in zgodovini brskalnika. Postavite poverilnice v glave ali upravljane skrivne shrambe, jih krožite skozi avtomatiziran proces in zabeležite ključne dogodke življenjskega cikla za odziv na incident.

3. korak: Zajem metapodatkov zahteve na prehodu ali aplikacijski ravni

Knjiga potrebuje več kot žetone. Potrebuje dovolj konteksta, da pojasni, zakaj je do porabe prišlo in ali je bila koristna.

Za vsak klic LLM zajemite:

• ID notranje zahteve in ID porazdeljenega sledenja.
• ID zahteve ponudnika, ko je vrnjen.
• Ponudnik, model, regija in končna točka.
• Ekipa, izdelek, okolje, delovna obremenitev, segment strank in lastnik proračuna.
• Vhodni žetoni, izhodni žetoni, predpomnjeni žetoni, žetoni sklepanja, vdelane enote, slikovne enote ali druge plačljive enote, če so na voljo.
• Zakasnitev, število ponovnih poskusov, nadomestna pot, status časovne omejitve in koda napake.
• Zadetek v predpomnilniku.
• Razred zahteve: proizvodnja, vrednotenje, ponovni poskus, serija ali poskus.

Osrednji prehod to olajša, ker gre vsak klic ponudnika skozi eno točko uveljavljanja. Če osrednji prehod ni izvedljiv, uporabite skupno odjemalsko knjižnico in zahtevajte, da storitve oddajajo enako obliko dogodka.

Ne beleži vsega privzeto

Pozivna in izhodna vsebina lahko pomaga pri odpravljanju napak in reviziji, ustvarja pa tudi obveznosti glede zasebnosti, hrambe in nadzora dostopa. Za mnoge ekipe bi morali biti privzeti metapodatki, število žetonov, identifikatorji modela in ID-ji sledenja. Shranjujte pozivno in izhodno vsebino samo v skladu z izrecnim pravilnikom z omejitvami hrambe in nadzorom dostopa.

4. korak: Vzdrževanje dveh tabel stroškov

Poskus, da bi ena tabela služila vsem namenom, običajno povzroči zmedo. Zgradite dve knjigi z različnimi opravili.

Ocenjena knjiga na zahtevo

Ta tabela podpira operacije v skoraj realnem času. Je zrnat, hiter in približen.

Uporabni stolpci vključujejo:

• request_id
• provider_request_id
• timestamp
• team_id
• product_id
• environment
• workload
• provider
• model
• billable_units
• rate_card_version
• estimated_cost_usd
• latency_ms
• status_code
• retry_count
• fallback_used
• cache_status

Ocenjene stroške je treba izračunati iz najboljših razpoložljivih podatkov o zaračunljivi enoti in različice notranjega cenovnega razreda. Različico cenika hranite v vsaki vrstici, da bo mogoče pozneje razložiti pretekle ocene.

Dnevna knjiga, usklajena z računom

Ta tabela podpira finančno poročanje. Je manj razdrobljen, počasnejši in bližje realnosti končnega obračunavanja.

Uporabni stolpci vključujejo:

• billing_date
• provider
• invoice_account
• project_or_workspace
• team_id
• product_id
• environment
• estimated_cost_usd
• provider_reported_cost_usd
• allocated_adjustment_usd
• reconciled_cost_usd
• variance_reason

Usklajena tabela mora ohraniti varianco, namesto da bi jo skrila. Če so stroški, ki jih poroča ponudnik, nižji zaradi kreditov ali višji zaradi omogočenega pretoka, to razliko izrecno zabeležite.

5. korak: usklajujte dnevno, ne ročno ob koncu meseca

Dnevno usklajevanje poskrbi, da so presenečenja majhna. Postopek je sprva lahko preprost:

1. Neprekinjeno vnašajte dogodke v knjigi na ravni zahteve.
2. Po urniku vnesite podatke o uporabi in stroških ponudnika.
3. Združite notranje ocene po ponudniku, projektu ali delovnem prostoru, modelu, datumu in znanih dimenzijah dodelitve.
4. Primerjajte notranje ocene s skupnimi stroški, ki jih poroča ponudnik.
5. Dodelite razlike z uporabo dokumentiranega pravilnika.
6. Napišite razloge odstopanja in stanje uskladitve.

Pogoste kategorije odstopanj vključujejo dogovorjene popuste, kredite ponudnika, zapise o zakasnitvi uporabe, cene predpomnjenih žetonov, paketne cene, omogočeno prepustnost, pretvorbo valut, minimalne stroške in manjkajoče metapodatke.

Primer politike usklajevanja

Če se projekt ponudnika preslika na natanko eno ekipo in okolje, tej ekipi dodelite celotne dnevne stroške, ki jih poroča ponudnik, in zabeležite notranjo oceno kot podporno podrobnost. Če projekt ponudnika vključuje več ekip, razdelite skupni znesek, ki ga je prijavil ponudnik, sorazmerno z notranjimi ocenjenimi stroški, nato zabeležite prilagoditev v vsako vrstico ekipe.

Ta pravilnik ni popoln, vendar ga je mogoče razložiti. Razložljivost je pomembnejša od lažne natančnosti.

6. korak: Priložite proračune in kontrole dimenzijam glavne knjige

Ko je poraba dodeljena, postanejo kontrole uporabnejše. Ena sama omejitev za celotno organizacijo je za večino ekip preostra.

Uporaba različnih kontrolnikov za različne delovne obremenitve:

• Peskovnik: stroge dnevne ali tedenske omejitve, samodejni izklop, nizek prag odobritve.
• Razvoj: mehka opozorila in skromne trde omejitve.
• Ocena: paketna okna, izrecni lastnik proračuna, datum poteka.
• Produkcija: mehka opozorila, potek dela za stopnjevanje, pot povečanja omejitve v sili.
• Uporaba za partnerje ali stranke API: dodeljevanje na ravni strank, uveljavljanje kvot in spremljanje zlorab.

Trde omejitve preprečujejo bežne račune, vendar lahko prekinejo potek dela v proizvodnji. Pazljivo jih uporabljajte v produkciji in jih seznanite s pravili stopnjevanja. Za neproizvodne delovne obremenitve je trde omejitve običajno lažje utemeljiti.

7. korak: Odkrijte anomalije, ki presegajo skupno porabo

Skupna dnevna poraba je zaostajajoč signal. Boljša opozorila uporabljajo operativna polja glavne knjige.

Uporabna preverjanja nepravilnosti vključujejo:

• Cena na uspešno zahtevo glede na delovno obremenitev.
• Razmerje izhodnih žetonov v primerjavi z zgodovinsko osnovo.
• Stopnja ponovnih poskusov glede na ponudnika, model in storitev.
• Nadomestna pogostost od cenejših k dražjim modelom.
• Hitrost porabe v trenutni uri.
• Padec stopnje zadetkov v predpomnilniku za delovne obremenitve, za katere se pričakuje, da bodo imeli koristi od predpomnilnika.
• Neprodukcijska poraba zunaj delovnega časa.
• V zahtevah manjkajo zahtevane stroškovne dimenzije.

Opozorilo, ki pravi, da je poraba visoka, je manj uporabno kot opozorilo, ki pravi, da zahteve za povzemanje proizvodnje iz ene storitve po uvedbi ustvarijo trikrat več običajnih izhodnih žetonov.

Priporočeno zaporedje izvajanja

Ne poskušajte zgraditi celotne arhitekture v eni izdaji. Praktično zaporedje je:

1. Določite shemo stroškovnih dimenzij in register lastništva.
2. Razdelite poverilnice ponudnika glede na skupino in okolje za delovne obremenitve z največjo porabo.
3. Dodajte zajem metapodatkov prehoda ali knjižnice odjemalca.
4. Ustvarite ocenjeno knjigo na zahtevo.
5. Dodajte cenovni razred z različicami za ponudnike in modele v uporabi.
6. Vnesite podatke o stroških ponudnika v tabelo dnevnega poročanja.
7. Izvedite dnevno usklajevanje in sledenje odstopanj.
8. Dodajte pravilnike o proračunu, opozorila in poteke dela za odobritev.
9. Vsak teden preglejte manjkajoče metapodatke in nerazporejeno porabo.

Prvi uporaben mejnik ni popolno povračilo. To je zmožnost, da v enem delovnem dnevu odgovorite, katera ekipa in delovna obremenitev sta povzročila spremembo materialne porabe.

Kompromisi za eksplicitno odločitev

Nadzorne plošče ponudnika v primerjavi z notranjo knjigo: nadzorne plošče ponudnika je hitreje sprejeti, vendar se redko ujemajo z dimenzijami notranjih stroškov v skupinah, izdelkih, okoljih in strankah.

Zdrobljenost v primerjavi z operativnimi stroški: več ključev, projektov, delovnih prostorov in oznak izboljša dodeljevanje, vendar poveča delo upravljanja. Uporabite meje, ki ustrezajo dejanskemu lastništvu.

Predvideni stroški v primerjavi s stroški na računu: ocene na ravni zahtev so pravočasne in uporabne za operacije, vendar ne odražajo samodejno kreditov, dogovorjenih cen ali prilagoditev zaračunavanja.

Centralni prehod v primerjavi s porazdeljenimi instrumenti: prehod omogoča dosledno uveljavljanje med ponudniki, vendar postane kritična infrastruktura. Odjemalsko knjižnico v skupni rabi je v nekaterih okoljih lažje sprejeti, težje pa jo je uveljaviti.

Preverljivost v primerjavi z zasebnostjo: beleženje vsebine lahko pomaga pri preiskavah, vendar je beleženje samo metapodatkov pogosto varnejše privzeto.

Napoved: Knjige stroškov bodo postale del upravljanja platforme AI

Verjetna smer je, da se bo izvorno poročanje ponudnika izboljšalo, vendar bo dodeljevanje med ponudniki še vedno zahtevalo notranji kontekst. Ponudniki ne morejo poznati strukture skupine vsakega podjetja, taksonomije izdelkov, segmentacije strank, delovnega toka odobritve ali politike povratnih bremenitev.

Ko se bo uporaba umetne inteligence razširila iz pilotnih projektov v proizvodne poteke dela, bodo knjige stroškov postale del običajnega upravljanja platforme poleg nadzora dostopa, rotacije ključev, revizijskega beleženja, omejitev stopnje in analitike uporabe. Ekipe, ki zgodaj določijo svojo stroškovno taksonomijo, bodo pozneje lažje dodajale proračune, dodeljevanje na ravni strank in avtomatizirane kontrole.

Uporabni sklep

Knjigo zgradite na podlagi odgovornosti, ne na podlagi grafikonov. Začnite s stabilnimi dimenzijami, obsegajočimi poverilnicami in zahtevajte metapodatke. Ohranite hitro oceno na zahtevo za inženirske operacije in usklajeno dnevno knjigo za finance. Uskladite ocene, namesto da bi vsiljevali, da so videti natančne, in ohranite odstopanja, tako da popusti, obveznosti, krediti in zamude pri obračunavanju ostanejo vidni.

Uporabna prva različica je lahko ozka: en ponudnik, največje tri delovne obremenitve, ključi v obsegu glede na ekipo in okolje, zajem metapodatkov, ocenjeni stroški in dnevna primerjava s skupnimi vrednostmi, ki jih poroča ponudnik. Ko bo to delovalo, razširite isto pogodbo med ponudniki in pripnite proračunske pravilnike na pomembne dimenzije.