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, API atslēgas ar tvērumu, 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 tiek piešķirti

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 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 pēc rēķina rindas pozīcijām, projektiem vai norēķinu periodiem.
• Lietošanas API bieži sniedz 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 rēķ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īzās 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. Komandām ir jāapkopo žurnāli un jāpiemēro cenu noteikšanas likmes, lai aprēķinātu pieprasījuma līmeņa izmaksas.

Ieteikums

Uzskatiet 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šākā AI API izmaksu kontrolē, jo tā savieno inženiertehnisko telemetriju ar finanšu atbildību, neatkaroties no viena pakalpojumu sniedzēja ziņošanas modeļa.

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

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, funkcijas apgabals vai iekšējā platforma, kas izmanto API.
• vide: ražošana, iestudēšana, izstrāde, smilškaste, demonstrācija vai testēšana.
• darba slodze: 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ņēmumu segmenti, vidēja tirgus segmenti, bezmaksas izmēģinājuma versijas, 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, kas tika izmantots pieprasījumam.
• modelis: precīzs modeļa vai izvietošanas identifikators.
• request_class: interaktīvs, fona, 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, parametram 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

Izmērus attēlojiet kā līguma versiju. Pieprasījumam, kuram nav nepieciešamo ražošanas atzīmju, nevajadzētu tikt aizvērtam vārtejā vai tas jānovirza skaidri nosauktā karantīnas segmentā, kas tiek pārskatīts katru dienu.

{
  "schema_version": "2025-01",
  "team_id": "platform-ai",
  "product_id": "atbalsta palīgs",
  "vide": "ražošana",
  "darba slodze": "kopsavilkums",
  "customer_segment": "uzņēmums",
  "budžeta_īpašnieks": "izmaksu centrs-4812","request_class": "interaktīvs"
}

2. darbība: izdodiet komandas un vides atslēgas, uz kurām attiecas darbības joma

Koplietojamas monolītās API atslēgas padara izmaksu sadali trauslu. Ja katrs pakalpojums izmanto vienus un tos pašus akreditācijas datus, finanses nevar droši attiecināt izdevumus 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 vietrāži 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 lietojumprogrammu slānī

Virsgrāmatai ir nepieciešams vairāk nekā tikai tokenu 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ā izsekošanas ID.
• Pakalpojumu sniedzē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 pilnvaras, iegulšanas vienības, attēlu vienības vai citas apmaksājamas vienības, ja tādas ir pieejamas.
• Latentums, atkārtoto mēģinājumu skaits, rezerves ceļš, taimauta statuss un kļūdas kods.
• Kešatmiņā trāpīts vai nepamanīts.
• Pieprasīt klasi: ražošana, novērtēšana, atkārtots mēģinājums, pakešu komplektēšana 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 tādu 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 privātuma, 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 kontroli.

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.

Paredzamā virsgrāmata pēc pieprasījuma

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

Noderīgas kolonnas ir:

• pieprasījuma_id
• provider_request_id
• laikspiedols
• team_id
• product_id
• vide
• darba slodze
• nodrošinātājs
• modelis
• apmaksājamās_vienības
• likmju_kartes_versija
• estimated_cost_usd
• latency_ms
• statusa_kods
• retry_count
• fallback_used
• kešatmiņas_statuss

Aprēķinātās izmaksas jāaprēķina, izmantojot labākos pieejamos apmaksājamo vienību datus 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ārskatu sagatavošanu. Tas ir mazāk detalizēts, lēnāks un tuvāks gala norēķinu realitātei.

Noderīgas kolonnas ir:

• norēķinu_datums
• nodrošinātājs
• invoice_account
• projekts_vai_darbvieta
• team_id
• product_id
• vide
• estimated_cost_usd
• provider_reported_cost_usd
• allocated_adjustment_usd
• reconciled_cost_usd
• variance_reason

Saskaņotajā tabulā ir jāsaglabā novirze, nevis jāslēpj. Ja pakalpojumu sniedzēja ziņotās izmaksas ir zemākas kredītu dēļ vai lielā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 samierināšanās ļauj izvairīties no pārsteigumiem. Sākumā process var būt vienkāršs:

1. Nepārtraukti ievadiet pieprasījuma līmeņa virsgrāmatas notikumus.
2. Pārvadiet pakalpojumu sniedzēja lietojumu 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. Uzrakstiet novirzes iemeslus un saskaņošanas statusu.

Izplatītās novirzes kategorijas ietver sarunātas atlaides, pakalpojumu sniedzēju kredītus, aizkavētas lietošanas ierakstus, 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. Viena 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šana, zems apstiprināšanas slieksnis.
• Izstrāde: vieglie brīdinājumi un nelieli stingrie vāciņi.
• 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ļš.
• Partneru vai klientu saskarsmes API lietojums: klientu līmeņa piešķiršana, kvotu izpilde 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āki brīdinājumi izmanto virsgrāmatas darbības laukus.

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.
• Mēģiniet vēlreiz 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ēriņu ātrums pašreizējā stundā.
• Kešatmiņas trāpījumu biežuma samazināšanās darba slodzēm, kas varētu gūt labumu no saglabāšanas kešatmiņā.
• Tēriņi, kas nav saistīti ar ražošanu, ārpus darba laika.
• Pieprasījumos trūkst nepieciešamo 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 dispersiju 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 atskaites punkts nav ideāla atmaksa. Tā ir iespēja vienas darbadienas laikā atbildēt, kura komanda un darba slodze izraisīja materiālās tēriņu izmaiņas.

Kompozīcijas, lai tieši izlemtu

Pakalpojumu sniedzēja informācijas paneļi salīdzinājumā ar iekšējo virsgrāmatu: pakalpojumu sniedzē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 darbības pieskaitāmajā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 ir 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 salīdzinājumā ar izkliedētajiem instrumentiem: vārteja nodrošina konsekventu izpildi starp pakalpojumu sniedzējiem, taču tā kļūst par kritisku infrastruktūru. Dažās vidēs koplietotu klienta bibliotēku ir vieglāk pieņemt, taču to ir grūtāk ieviest.

Auditējamība salīdzinājumā ar 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 ziņojumi uzlabosies, taču starpnodrošinātāju sadalei 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 sastāvdaļu līdzās piekļuves kontrolei, atslēgu rotācijai, audita reģistrēšanai, ātruma ierobežojumiem un lietojuma analītikai. Komandām, kas agri definē savu izmaksu taksonomiju, vēlāk būs vieglāk pievienot budžetu, klientu līmeņa piešķiršanu un automatizētas vadīklas.

Apstrīdams 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 summām. Kad tas darbojas, paplašiniet to pašu līgumu starp pakalpojumu sniedzējiem un pievienojiet budžeta politikas svarīgajām dimensijām.