Kā izveidot vienas komandas LLM izmaksu virsgrāmatu vairākās AI API

Pakalpojumu sniedzēju informācijas paneļi var norādīt, cik organizācija iztērējusi. Viņi reti atbild uz jautājumu, kas finanšu un platformu komandām patiesībā ir jāatbild: kura komanda, produkts, vide, darba slodze vai klientu segments izraisīja tēriņus un vai tie bija paredzēti.

Izturīgais raksts nav vēl viens informācijas panelis. Tā ir iekšēja izmaksu virsgrāmata: ierakstu sistēma, kas apvieno lietojumprogrammas pieprasījuma metadatus, tvēruma API atslēgas, pakalpojumu sniedzēja lietojuma datus un rēķina līmeņa rēķinu kopsummas. Virsgrāmata sniedz inženieru komandām gandrīz reāllaika darbības redzamību, vienlaikus sniedzot finansēm saskaņotu skatījumu, kas var atbalstīt budžetu, piešķiršanu un atmaksu.

Šajā rakstā ir izklāstīta praktiska arhitektūra komandām, kuras izmanto vairāk nekā vienu AI API, tostarp marķēšanas līgums, pieprasījumu plūsma, tabulas, saskaņošanas process, vadīklas un kompromisi.

Problēma: pakalpojumu sniedzēja norēķini ir precīzi, bet ne vienmēr piešķirami

Lielākā daļa AI pakalpojumu sniedzēju piedāvā dažas lietošanas informācijas paneļu, lietošanas API, rēķinu eksportēšanas, projektu, darbvietu, pakalpojumu kontu vai izmaksu API kombinācijas. Šie rīki ir noderīgi, taču tie ne visi darbojas vienādā detalizācijas līmenī.

Fakti

• Daži pakalpojumu sniedzēja izmaksu galapunkti ir paredzēti finanšu pārskatu sniegšanai, un tie var sadalīt izdevumus pa rēķina rindas vienībām, projektiem vai norēķinu periodiem.
• Lietošanas API bieži sniedz detalizētu informāciju par darbību, taču lietošanas ieraksti un galīgo izmaksu ieraksti var nebūt ideāli saskaņoti atlaižu, kredītu, aizkavētu norēķinu, saistību cenu, pakešu likmju, kešatmiņas cenu vai rēķinu korekciju dēļ.
• Vietējās administratīvās robežas, piemēram, projekti, darbvietas, pakalpojumu konti, API atslēgas vai IAM principi, var palīdzēt attiecināt izdevumus, taču precīzas iespējas atšķiras atkarībā no pakalpojumu sniedzēja.
• Dažām platformām katra pieprasījuma metadati tiek rādīti izsaukšanas žurnālos, nevis izmaksu sadales pārskatos. Lai aprēķinātu pieprasījuma līmeņa izmaksas, komandām ir jāapkopo žurnāli un jāpiemēro cenu noteikšanas likmes.

Ieteikums

Apstrādājiet pakalpojumu sniedzēja datus kā ievadi, nevis visu sistēmu. Izveidojiet iekšējo virsgrāmatu, kas var atbildēt gan uz darbības, gan finanšu jautājumiem, un pēc tam katru dienu saskaņojiet to ar pakalpojumu sniedzēja izmaksu avotiem.

Virsgrāmatas arhitektūra

Izmaksu virsgrāmatā ir pieci galvenie komponenti:

1. Stabila izmaksu dimensiju shēma.
2. Aptveramie akreditācijas dati un maršrutēšanas noteikumi.
3. Pieprasījuma līmeņa metadatu tveršana.
4. Pakalpojumu sniedzēja lietojums un izmaksu iekļaušana.
5. Ikdienas saskaņošana un politikas īstenošana.

Mērķis ir izveidot divus saistītus skatus: aptuveno operāciju virsgrāmatu pēc pieprasījuma un saskaņotu ikdienas finanšu pārskatu.

Šis ir izplatīts pamatelements plašākai AI API izmaksu kontrolei, jo tā savieno inženiertehnisko telemetriju ar finansiālo atbildību, neatkaroties no viena pakalpojumu sniedzēja ziņošanas modeļa.

1. darbība: definējiet izmaksu dimensijas pirms informācijas paneļu izveides

Sāciet ar dimensijām, kuras konsekventi izmantos finanšu, inženieru, produktu un drošības komandas. Dariet to pirms diagrammu atlasīšanas vai ievades darbu rakstīšanas.

Praktiskā shēma parasti ietver:

• team_id: inženieru vai biznesa komanda, kurai pieder.
• product_id: produkts, funkciju apgabals vai iekšējā platforma, kas patērē API.
• vide: ražošana, iestudēšana, izstrāde, smilškaste, demonstrācija vai testēšana.
• workload: tērzēšana, kopsavilkums, izvilkšana, klasifikācija, koda ģenerēšana, novērtēšana, iegulšana, pārgrupēšana vai pakešu apstrāde.
• customer_segment: uzņēmuma, vidēja tirgus, bezmaksas izmēģinājuma, iekšējie, partneru vai citi apstiprināti segmenti.
• budget_owner: persona, komanda vai izmaksu centrs, kas atbild par tēriņiem.
• provider: AI API nodrošinātājs, ko izmantoja pieprasījumam.
• modelis: precīzs modelis vai izvietošanas identifikators.
• request_class: interaktīvs, fons, pakešu, atkārtots mēģinājums, atkāpšanās, novērtēšana vai administrators.

Saglabājiet shēmu pietiekami mazu, lai inženieri to faktiski aizpildītu. Pievienojiet pārvaldību, lai novērstu brīvā teksta novirzīšanu. Piemēram, team_id ir jānāk no iekšējā komandas reģistra, nevis no patvaļīgām pieprasījumu galvenēm.

Ieviešanas informācija

Attēlot izmērus kā līguma versiju. Pieprasījumu, kuram nav nepieciešamo ražošanas atzīmju, nevajadzētu aizvērt vārtejā vai novirzīt uz skaidri nosauktu karantīnas segmentu, kas tiek pārskatīts katru dienu.

{
  "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. darbība: izdodiet komandas un vides atslēgas, uz kurām attiecas problēma

Koplietojami monolīti API taustiņi padara izmaksu sadali trauslu. Ja katrs pakalpojums izmanto vienus un tos pašus akreditācijas datus, finanses nevar droši attiecināt tēriņus un platformu komandas nevar atspējot vienu darba slodzi, neietekmējot nesaistītas sistēmas.

Ja iespējams, izmantojiet tvēruma akreditācijas datus:

• Viena atslēga vai pakalpojuma konts katrai komandai un videi.
• Atsevišķi akreditācijas dati ražošanas un ar ražošanu nesaistītām darba slodzēm.
• Atsevišķi akreditācijas dati augsta riska eksperimentiem, novērtējumiem un pakešu darbiem.
• Pakalpojumu sniedzēja vietējie projekti vai darbvietas, ja tie ir skaidri saistīti ar iekšējām īpašumtiesībām.

Tas nenozīmē, ka katram mikropakalpojumam ir nepieciešams unikāls pakalpojumu sniedzēja konts. Pārāk daudz robežu rada darbības izmaksas. Noderīga vienība ir robeža, kurā atšķiras īpašumtiesības, budžets un darbības reakcija.

Drošības piezīme

API atslēgas un drošības pilnvaras nedrīkst sūtīt vietrāžos URL, jo URL parasti tiek tverti žurnālos, starpniekserveros, analīzes rīkos un pārlūkprogrammas vēsturē. Ievietojiet akreditācijas datus galvenēs vai pārvaldītajos slepenajos krātuvēs, pagrieziet tos, izmantojot automatizētu procesu, un reģistrējiet galvenos dzīves cikla notikumus, lai reaģētu uz incidentiem.

3. darbība. Pieprasījuma metadatu tveršana vārtejā vai lietojumprogrammas slānī

Virsgrāmatai ir nepieciešams vairāk nekā tikai marķieru skaits. Tam ir nepieciešams pietiekami daudz konteksta, lai izskaidrotu, kāpēc tika tērēti un vai tie bija noderīgi.

Katram LLM zvanam tveriet:

• Iekšējā pieprasījuma ID un izplatītās izsekošanas ID.
• Nodrošinātāja pieprasījuma ID pēc atgriešanas.
• Pakalpojumu sniedzējs, modelis, reģions un galapunkts.
• Komanda, produkts, vide, darba slodze, klientu segments un budžeta īpašnieks.
• Ievades pilnvaras, izvades marķieri, kešatmiņas marķieri, argumentācijas marķieri, iegulšanas vienības, attēlu vienības vai citas apmaksājamas vienības, ja tādas ir pieejamas.
• Latentums, atkārtojumu skaits, rezerves ceļš, taimauta statuss un kļūdas kods.
• Kešatmiņas trāpījums vai garām.
• Pieprasīt klasi: ražošana, novērtēšana, atkārtots mēģinājums, sērija vai eksperiments.

Centrālā vārteja to atvieglo, jo katrs pakalpojumu sniedzēja zvans tiek veikts caur vienu izpildes punktu. Ja centrālā vārteja nav iespējama, izmantojiet koplietojamo klienta bibliotēku un pieprasiet, lai pakalpojumi izstaro to pašu notikumu formātu.

Nereģistrēt visu pēc noklusējuma

Uzvedināts un izvadīts saturs var palīdzēt atkļūdot un pārbaudīt, taču tas arī rada konfidencialitātes, saglabāšanas un piekļuves kontroles pienākumus. Daudzām komandām noklusējuma iestatījumam ir jābūt metadatiem, pilnvaru skaitam, modeļu identifikatoriem un izsekošanas ID. Saglabājiet uzvednes un izvades saturu tikai saskaņā ar skaidru politiku ar saglabāšanas ierobežojumiem un piekļuves vadīklām.

4. darbība: uzturiet divas izmaksu tabulas

Mēģinājums panākt, lai viens galds kalpotu visiem mērķiem, parasti rada apjukumu. Izveidojiet divas virsgrāmatas ar dažādiem darbiem.

Aprēķinātā virsgrāmata pēc pieprasījuma

Šī tabula atbalsta gandrīz reāllaika darbības. Tas ir detalizēts, ātrs un aptuvens.

Noderīgās kolonnas ietver:

• 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

Paredzētās izmaksas jāaprēķina, pamatojoties uz labākajiem pieejamajiem apmaksājamo vienību datiem un versijas iekšējo tarifu karti. Saglabājiet tarifu kartes versiju katrā rindā, lai vēlāk varētu izskaidrot vēsturiskos aprēķinus.

Rēķinu saskaņošanas dienas virsgrāmata

Šī tabula atbalsta finanšu pārskatus. Tas ir mazāk detalizēts, lēnāks un tuvāks gala norēķinu realitātei.

Noderīgas kolonnas ietver:

• 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

Saskaņotajā tabulā ir jāsaglabā novirze, nevis tā jāslēpj. Ja pakalpojumu sniedzēja ziņotās izmaksas ir zemākas kredītu dēļ vai augstākas nodrošinātās caurlaidspējas dēļ, skaidri ierakstiet šo atšķirību.

5. darbība: saskaņojiet katru dienu, nevis manuāli mēneša beigās

Ikdienas saskaņošana neļauj pārsteigt pārsteigumus. Sākumā process var būt vienkāršs:

1. Nepārtraukti ievadiet pieprasījuma līmeņa virsgrāmatas notikumus.
2. Pārvada pakalpojumu sniedzēja lietojuma un izmaksu ierakstus pēc grafika.
3. Grupējiet iekšējos aprēķinus pēc nodrošinātāja, projekta vai darbvietas, modeļa, datuma un zināmajām piešķiršanas dimensijām.
4. Salīdziniet iekšējos aprēķinus ar pakalpojumu sniedzēja ziņotajām kopējām izmaksām.
5. Piešķiriet atšķirības, izmantojot dokumentētu politiku.
6. Ierakstiet novirzes iemeslus un saskaņošanas statusu.

Izplatītās novirzes kategorijas ietver vienošanās par atlaidēm, pakalpojumu sniedzēju kredītiem, aizkavētas lietošanas ierakstiem, kešatmiņā saglabāto marķieru cenu noteikšanu, pakešu cenu noteikšanu, nodrošināto caurlaidspēju, valūtas konvertēšanu, minimālās maksas un trūkstošos metadatus.

Saskaņošanas politikas piemērs

Ja pakalpojumu sniedzēja projekts ir paredzēts tieši vienai komandai un videi, piešķiriet šai komandai visas nodrošinātāja ziņotās dienas izmaksas un ierakstiet iekšējo tāmi kā papildu informāciju. Ja nodrošinātāja projektā ir vairākas komandas, proporcionāli sadaliet nodrošinātāja ziņoto kopējo summu, ņemot vērā iekšējās aptuvenās izmaksas, pēc tam ierakstiet korekciju katrā komandas rindā.

Šī politika nav ideāla, taču tā ir izskaidrojama. Izskaidrojamība ir svarīgāka par nepatiesu precizitāti.

6. darbība: pievienojiet budžetu un vadīklas virsgrāmatas dimensijām

Kad tēriņi ir attiecināti, vadīklas kļūst noderīgākas. Viens organizācijas mēroga ierobežojums lielākajai daļai komandu ir pārāk strups.

Izmantojiet dažādas vadīklas dažādām darba slodzēm:

• Smilškaste: stingri dienas vai nedēļas ierobežojumi, automātiska izslēgšanās, zems apstiprināšanas slieksnis.
• Izstrāde: vieglie brīdinājumi un nelieli cietie burti.
• Novērtējums: pakešu logi, skaidrs budžeta īpašnieks, derīguma termiņš.
• Ražošana: mīkstie brīdinājumi, eskalācijas darbplūsma, avārijas ierobežojumu palielināšanas ceļš.
• Partneris vai klients API usage: klientu līmeņa piešķiršana, kvotu piemērošana un ļaunprātīgas izmantošanas uzraudzība.

Stingri ierobežojumi novērš pārmērīgus rēķinus, taču tie var pārtraukt ražošanas darbplūsmas. Rūpīgi izmantojiet tos ražošanā un savienojiet tos ar eskalācijas noteikumiem. Darba slodzēm, kas nav saistītas ar ražošanu, stingri ierobežojumi parasti ir vieglāk attaisnojami.

7. darbība. Atklājiet novirzes, kas pārsniedz kopējos tēriņus

Kopējie dienas tēriņi ir signāls, kas kavējas. Labākos brīdinājumos tiek izmantoti virsgrāmatas darbības lauki.

Noderīgas anomāliju pārbaudes ietver:

• Maksa par veiksmīgu pieprasījumu pēc darba slodzes.
• Izvades marķiera attiecība salīdzinājumā ar vēsturisko bāzes līniju.
• Atkārtota mēģinājuma likme pēc pakalpojumu sniedzēja, modeļa un pakalpojuma.
• Atkāpšanās biežums no lētākiem uz dārgākiem modeļiem.
• Tērēšanas ātrums pašreizējā stundā.
• Kešatmiņas trāpījumu līmeņa samazināšanās darba slodzēm, kas, visticamāk, gūs labumu no saglabāšanas kešatmiņā.
• Tēriņi, kas nav saistīti ar ražošanu ārpus darba laika.
• Pieprasījumos trūkst obligāto izmaksu dimensiju.

Brīdinājums, kurā teikts, ka tēriņi ir lieli, ir mazāk noderīgs nekā brīdinājums, kurā teikts, ka viena pakalpojuma ražošanas kopsavilkuma pieprasījumi pēc izvietošanas ģenerē trīs reizes vairāk nekā parastie izvades marķieri.

Ieteicamā ieviešanas secība

Nemēģiniet izveidot visu arhitektūru vienā laidienā. Praktiskā secība ir šāda:

1. Definējiet izmaksu dimensiju shēmu un īpašumtiesību reģistru.
2. Sadaliet nodrošinātāja akreditācijas datus pēc komandas un vides, lai nodrošinātu vislielāko darba slodzi.
3. Pievienojiet vārteju vai klienta bibliotēkas metadatu tveršanu.
4. Izveidojiet aptuveno virsgrāmatu pēc pieprasījuma.
5. Pievienojiet izmantoto pakalpojumu sniedzēju un modeļu tarifu karti.
6. Iegūstiet pakalpojumu sniedzēja izmaksu datus ikdienas pārskatu tabulā.
7. Ieviesiet ikdienas saskaņošanu un dispersijas izsekošanu.
8. Pievienojiet budžeta politikas, brīdinājumus un apstiprināšanas darbplūsmas.
9. Katru nedēļu pārskatiet trūkstošos metadatus un nesadalītos tēriņus.

Pirmais noderīgais pavērsiens nav ideāls maksājuma atdošana. Tā ir iespēja vienas darbadienas laikā atbildēt, kura komanda un darba slodze izraisīja materiālās tēriņu izmaiņas.

Izmaiņas, lai tieši pieņemtu lēmumu

Pakalpojumu sniedzēja informācijas paneļi salīdzinājumā ar iekšējo virsgrāmatu: nodrošinātāju informācijas paneļi ir ātrāk pārņemami, taču tie reti atbilst iekšējām izmaksu dimensijām komandās, produktos, vidēs un klientiem.

Precizitāte salīdzinājumā ar operatīvajām izmaksām: vairāk atslēgu, projektu, darbvietu un tagu uzlabo attiecinājumu, taču tie palielina pārvaldības darbu. Izmantojiet robežas, kas atbilst patiesajām īpašumtiesībām.

Aprēķinātās izmaksas salīdzinājumā ar rēķina izmaksām: pieprasījuma līmeņa aprēķini ir savlaicīgi un noderīgi operācijām, taču tie automātiski neatspoguļo kredītus, saskaņotās cenas vai norēķinu korekcijas.

Centrālā vārteja pret izkliedētajiem instrumentiem: vārteja nodrošina konsekventu izpildi starp pakalpojumu sniedzējiem, taču tā kļūst par kritisko infrastruktūru. Dažās vidēs koplietotu klienta bibliotēku ir vieglāk pieņemt, taču to ir grūtāk ieviest.

Audititāte pret konfidencialitāti: satura reģistrēšana var palīdzēt izmeklēšanā, taču tikai metadatu reģistrēšana bieži vien ir drošāka noklusējuma metode.

Prognoze: izmaksu virsgrāmatas kļūs par daļu no AI platformas pārvaldības

Iespējams, ka pakalpojumu sniedzēja vietējie pārskati uzlabosies, taču starpnodrošinātāju piešķiršanai joprojām būs nepieciešams iekšējais konteksts. Pakalpojumu sniedzēji nevar zināt katra uzņēmuma komandas struktūru, produktu taksonomiju, klientu segmentāciju, apstiprināšanas darbplūsmu vai atmaksas politiku.

Tā kā mākslīgā intelekta lietojums no izmēģinājuma projektiem pārvēršas ražošanas darbplūsmās, izmaksu virsgrāmatas kļūs par parastās platformas pārvaldības daļu līdzās piekļuves kontrolei, atslēgu rotācijai, audita reģistrēšanai, ātruma ierobežojumiem un lietojuma analītikai. Komandas, kas agri nosaka savu izmaksu taksonomiju, vēlāk varēs vieglāk pievienot budžetus, piešķirt klientu līmenī un automatizētas vadīklas.

Lietojams secinājums

Veidojiet virsgrāmatu, pamatojoties uz atbildību, nevis diagrammām. Sāciet ar stabiliem izmēriem, tvēruma akreditācijas datiem un pieprasiet metadatus. Saglabājiet ātru inženiertehnisko darbību tāmi pēc pieprasījuma un saskaņotu ikdienas finanšu virsgrāmatu. Saskaņojiet, nevis piespiediet aprēķinus izskatīties precīzi, un saglabājiet atšķirības, lai būtu redzamas atlaides, saistības, kredīti un norēķinu kavējumi.

Noderīga pirmā versija var būt šaura: viens nodrošinātājs, trīs lielākās darba slodzes, tvēruma atslēgas pēc komandas un vides, metadatu tveršana, aptuvenās izmaksas un ikdienas salīdzinājums ar pakalpojumu sniedzēja ziņotajām kopsummas vērtībām. Kad tas darbojas, paplašiniet vienu un to pašu līgumu starp pakalpojumu sniedzējiem un pievienojiet budžeta politikas svarīgajām dimensijām.