Miks mitte loota LLM-i kulude jaotamisel ainult pakkuja armatuurlauale?

Pakkuja armatuurlauad on kontotasemel nähtavuse jaoks kasulikud, kuid sageli ei vasta need sisemiste mõõtmetega, nagu meeskond, toode, keskkond, töökoormus, eelarve omanik või kliendisegment. Sisemine pearaamat lisab jaotamiseks ja juhtimiseks vajaliku ärikonteksti.

Kas taotlustaseme kuluprognoose tuleks käsitleda lõplike finantsnumbritena?

Ei. Taotluse taseme hinnangud on parimad töö nähtavuse ja anomaaliate varajase tuvastamise jaoks. Lõplik aruandlus peaks need prognoosid võrdlema teenusepakkuja esitatud kulu- või arvehinnanguga arveldusandmetega.

Mis on LLM-i kuluraamatu minimaalne kasulik versioon?

Väike esimene versioon peaks sisaldama suuremate meeskondade või keskkondade ulatusega võtmeid, nõutud päringu metaandmeid, loa või arveldatava üksuse hõivamist, versioonidega hinnakaarti ja igapäevast võrdlust teenusepakkuja kulude kogusummadega.

Kuidas peaksid meeskonnad käsitlema taotlusi, millel puuduvad kulusildid?

Puuduvate nõutavate siltidega tootmistaotlused peaksid lüüsis ebaõnnestuma või suunama karantiini eraldamise ämbrisse, mida vaadatakse iga päev üle. Märgistamata kulutuste kogunemine muudab tagasimakse ja eelarve jõustamise ebausaldusväärseks.

Kuidas koostada meeskonna kohta LLM-i kuluraamatut

Pakkuja armatuurlauad näitavad teile, kui palju organisatsioon kulutas. Nad vastavad harva küsimusele, mida finants- ja platvormimeeskonnad tegelikult vajavad: milline meeskond, toode, keskkond, töökoormus või kliendisegment kulutasid ja kas see kulu oli ootuspärane.

Vastupidav muster ei ole järjekordne armatuurlaud. See on sisemine kulureskontra: kirjesüsteem, mis ühendab rakendusepoolse päringu metaandmed, ulatusega API võtmed, pakkuja kasutusandmed ja arveldusastmega arvelduse kogusummad. Pearaamat annab insenerimeeskondadele peaaegu reaalajas tegevuse nähtavuse, pakkudes samal ajal rahandusele kooskõlastatud vaadet, mis võib toetada eelarveid, jaotamist ja tagasimakseid.

Selles artiklis kirjeldatakse rohkem kui ühte AI API-t kasutavate meeskondade praktilist ülesehitust, sealhulgas märgistamisleping, päringuvoog, tabelid, vastavusprotsess, juhtelemendid ja kompromissid.

Probleem: teenusepakkuja arveldus on täpne, kuid mitte alati eraldatav

Enamik tehisintellekti pakkujaid avaldab kasutuse armatuurlaudade, kasutus API-de, arvelduse eksportimise, projektide, tööruumide, teenusekontode või kulu API-de kombinatsioone. Need tööriistad on kasulikud, kuid need ei tööta kõik samal detailsustasemel.

Faktid

Mõned pakkuja kulu lõpp-punktid on loodud finantsaruandluse jaoks ja võivad jaotada kulutused arve reaüksuste, projektide või arveldusperioodide kaupa.
Kasutusliidesed pakuvad sageli üksikasjalikku teavet, kuid kasutuskirjed ja lõplikud kulukirjed ei pruugi allahindluste, krediitide, hilinenud arveldamise, kohustuste hindade, partiihindade, vahemälu hinnakujunduse või arvete korrigeerimiste tõttu ideaalselt kokku sobida.
Omalikud halduspiirid, nagu projektid, tööruumid, teenusekontod, API-võtmed või IAM-i printsiibid, võivad aidata kulutusi omistada, kuid täpsed võimalused erinevad pakkujati.
Mõne platvormi puhul kuvatakse päringupõhised metaandmed pigem kutsumislogides kui kulude jaotamise aruannetes. Meeskonnad peavad koguma logisid ja rakendama hinnakujunduse määrasid, et hinnata päringu tasemel kulusid.

Soovitus

Käitke pakkuja andmeid sisendina, mitte kogu süsteemina. Koostage sisemine pearaamat, mis suudab vastata nii tegevus- kui ka finantsküsimustele, ja seejärel võrrelda seda iga päev teenusepakkuja kuluallikatega.

Ledgeri arhitektuur

Kuluraamatul on viis põhikomponenti:

Stabiilne kuludimensioonide skeem.
Ulatunud mandaadid ja marsruutimisreeglid.
Taotluse tasemel metaandmete jäädvustamine.
Pakkuja kasutamine ja kulude kogumine.
Igapäevane leppimine ja eeskirjade jõustamine.

Eesmärk on luua kaks seotud vaadet: hinnanguline taotluspõhine tegevuste pearaamat ja kooskõlastatud igapäevane finantsreskontra.

See on laiemas AI API kulude kontrollimises levinud ehitusplokk, kuna see ühendab inseneri telemeetria finantsaruandlusega, sõltumata ühest pakkuja aruandlusmudelist.

1. samm: määrake kuludimensioonid enne armatuurlaudade loomist

Alustage mõõtmetest, mida finants-, inseneri-, toote- ja turvameeskonnad järjepidevalt kasutavad. Tehke seda enne diagrammide valimist või sisestustööde kirjutamist.

Praktiline skeem sisaldab tavaliselt järgmist:

tiim_id: omav inseneri- või ärimeeskond.
product_id: API-d kasutav toode, funktsiooniala või siseplatvorm.
keskkond: tootmine, lavastus, arendus, liivakast, demo või testimine.
töökoormus: vestlus, kokkuvõtte tegemine, ekstraheerimine, klassifitseerimine, koodi genereerimine, hindamine, manustamine, ümberpaigutamine või paketttöötlus.
kliendi_segment: ettevõtte, keskmise turu, tasuta prooviperioodi, sise-, partneri- või muud heakskiidetud segmendid.
budget_owner: isik, meeskond või kulukeskus, kes vastutab kulutuste eest.
pakkuja: taotluses kasutatud AI API pakkuja.
mudel: täpne mudeli või juurutuse identifikaator.
request_class: interaktiivne, taust, pakett, uuesti proovimine, varu, hindamine või administraator.

Hoidke skeem piisavalt väike, et insenerid selle tegelikult asustavad. Lisage juhtimine, et vältida vaba teksti triivimist. Näiteks team_id peaks pärinema meeskonnasisesest registrist, mitte suvalistest päringupäistest.

Rakenduse üksikasjad

Esitage mõõtmed versioonitud lepinguna. Taotlus, millel puuduvad nõutavad tootmismärgendid, peaks lüüsis ebaõnnestuma või suunama selgelt nimega karantiinisalve, mida vaadatakse iga päev üle.

kood>{ "schema_version": "2025-01", "team_id": "platvorm-ai", "product_id": "tugiabi", "keskkond": "tootmine", "töökoormus": "kokkuvõte", "customer_segment": "ettevõte", "eelarve_omanik": "kulukeskus-4812","request_class": "interaktiivne" }

2. samm: väljastage meeskonna ja keskkonna ulatusega võtmed

Jagatud monoliitsed API-võtmed muudavad kulude jaotamise hapraks. Kui iga teenus kasutab samu mandaate, ei saa rahandus kulutusi enesekindlalt omistada ja platvormimeeskonnad ei saa üht töökoormust keelata, ilma et see mõjutaks sõltumatuid süsteeme.

Kasutage võimaluse korral ulatusega mandaate:

Üks võti või teenusekonto meeskonna ja keskkonna kohta.
Tootmis- ja tootmisvälise töökoormuse jaoks eraldi mandaadid.
Eri mandaadid kõrge riskiga katsete, hindamiste ja paketttööde jaoks.
Pakkuja omaprojektid või tööruumid, kui need on selgelt seotud sisemise omandiga.

See ei tähenda, et iga mikroteenus vajab ainulaadset teenusepakkuja kontot. Liiga palju piire loob tegevuse üldkulud. Kasulik üksus on piir, kus omandiline kuuluvus, eelarve ja operatiivvastus erinevad.

Turvamärkus

API-võtmeid ja turvamärke ei tohiks URL-ides saata, kuna URL-id salvestatakse tavaliselt logidesse, puhverserveritesse, analüüsitööriistadesse ja brauseri ajaloosse. Sisestage mandaadid päistesse või hallatavatesse salasalvedesse, pöörake neid automaatse protsessi kaudu ja salvestage intsidentidele reageerimiseks peamised elutsükli sündmused.

3. samm: püüdke päringu metaandmeid lüüsis või rakendusekihis

Pearaamat vajab rohkemat kui žetoonide arvu. See vajab piisavalt konteksti, et selgitada, miks kulutati ja kas see oli kasulik.

Iga LLM-kõne puhul jäädvustage:

Sisepäringu ID ja hajutatud jälgimise ID.
Pakkuja päringu ID tagastamisel.
Pakkuja, mudel, piirkond ja lõpp-punkt.
Meeskond, toode, keskkond, töökoormus, kliendisegment ja eelarve omanik.
Sisestusmärgid, väljundmärgid, vahemällu salvestatud märgid, arutlusmärgid, manustamisüksused, pildiüksused või muud arveldatavad üksused, kui need on saadaval.
Laitentsus, korduskatsete arv, varutee, ajalõpu olek ja veakood.
Vahemälu tabas või ei taba.
Taotle klassi: tootmine, hindamine, uuesti proovimine, partii või katse.

Kesklüüs muudab selle lihtsamaks, sest iga teenusepakkuja kõne läbib ühe jõustamispunkti. Kui kesklüüs ei ole teostatav, kasutage jagatud klienditeeki ja nõudke teenustelt sama sündmusevormingu väljastamist.

Ära logi kõike vaikimisi

Sisu viipamine ja väljastamine võib aidata silumist ja kontrollitavust, kuid loob ka privaatsuse, säilitamise ja juurdepääsu kontrollimise kohustused. Paljude meeskondade jaoks peaksid vaikeväärtused olema metaandmed, lubade arv, mudeli identifikaatorid ja jälgimise ID-d. Salvestage viipasid ja väljastage sisu ainult selgesõnaliste eeskirjade alusel koos säilituspiirangute ja juurdepääsu juhtelementidega.

4. samm: hoidke kahte kulutabelit

Ühe laua igat otstarvet teenindava proovimine tekitab tavaliselt segadust. Koostage kaks pearaamatut erinevate töödega.

Hinnanguline päringupõhine pearaamat

See tabel toetab peaaegu reaalajas toiminguid. See on teraline, kiire ja ligikaudne.

Kasulikud veerud on järgmised:

päringu_id
provider_request_id
ajatempel
meeskonna_id
toote_id
keskkond
töökoormus
pakkuja
mudel
arveldatavad_ühikud
rate_card_version
hinnatud_kulu_usd
latency_ms
oleku_kood
retry_count
varuks_kasutatud
vahemälu_olek

Hinnanguline kulu tuleks arvutada parimate saadaolevate arveldatavate ühikute andmete ja sisemise hinnakaardi versiooni alusel. Hoidke hinnakaardi versioon igal real, et ajaloolisi prognoose saaks hiljem selgitada.

Arvetega kooskõlastatud igapäevane pearaamat

See tabel toetab finantsaruandlust. See on vähem detailne, aeglasem ja lähem lõpliku arvelduse tegelikkusele.

Kasulikud veerud on järgmised:

arvelduskuupäev
pakkuja
arve_konto
projekt_või_tööruum
meeskonna_id
toote_id
keskkond
hinnatud_kulu_usd
provider_reported_cost_usd
alllocated_adjustment_usd
reconciled_cost_usd
variatsiooni_põhjus

Ühendatud tabel peaks dispersiooni säilitama, mitte seda peitma. Kui teenusepakkuja teatatud kulu on krediidi tõttu madalam või ette nähtud läbilaskevõime tõttu suurem, registreerige see erinevus selgesõnaliselt.

5. toiming: kooskõlastage iga päev, mitte kuu lõpus käsitsi

Igapäevane leppimine hoiab üllatusi väikestena. Protsess võib alguses olla lihtne:

Sisestage taotlustaseme pearaamatu sündmusi pidevalt.
Sisestage teenusepakkuja kasutus- ja kulukirjed ajakava alusel.
Grupeerige sisemised hinnangud pakkuja, projekti või tööruumi, mudeli, kuupäeva ja teadaolevate jaotusmõõtmete järgi.
Võrrelge siseprognoose teenusepakkuja esitatud kulude kogusummadega.
Erinevuse määramine dokumenteeritud poliitika abil.
Kirjutage dispersiooni põhjused ja vastavuse olek.

Levinud erinevuste kategooriad hõlmavad kokkulepitud allahindlusi, teenusepakkuja krediite, viivitatud kasutuskirjeid, vahemällu salvestatud hinnakujundust, partiide hinnakujundust, etteantud läbilaskevõimet, valuuta konverteerimist, miinimumtasusid ja puuduvad metaandmed.

Leppimise poliitika näide

Kui pakkuja projekt on seotud täpselt ühe meeskonna ja keskkonnaga, määrake sellele meeskonnale kogu teenusepakkuja teatatud päevakulu ja lisage sisemine prognoos toetava detailina. Kui pakkuja projekt sisaldab mitut meeskonda, jaotage teenusepakkuja teatatud kogusumma proportsionaalselt sisemise hinnangulise kuluga ja seejärel salvestage korrigeerimine igale meeskonnareale.

See poliitika ei ole täiuslik, kuid see on seletatav. Seletatavus loeb rohkem kui vale täpsus.

6. samm: lisage eelarved ja juhtelemendid pearaamatu mõõtmetele

Kui kulutused on omistatud, muutuvad juhtelemendid kasulikumaks. Üksainus kogu organisatsiooni hõlmav limiit on enamiku meeskondade jaoks liiga nüri.

Kasutage erinevate töökoormuste jaoks erinevaid juhtelemente:

Liivakast: ranged päeva- või nädalapiirangud, automaatne väljalülitus, madal kinnituslävi.
Arendus: pehmed märguanded ja tagasihoidlikud kõvakatted.
Hindamine: pakettaknad, selge eelarve omanik, aegumiskuupäev.
Tootmine: pehmed hoiatused, eskalatsiooni töövoog, hädaolukorra piirangu suurendamise tee.
Partnerile või kliendile suunatud API kasutus: klienditasemel jaotamine, kvootide jõustamine ja väärkasutuse jälgimine.

Kõrvad piirangud hoiavad ära jooksvate arvete tekkimise, kuid võivad katkestada tootmise töövood. Kasutage neid tootmises ettevaatlikult ja siduge need eskalatsioonireeglitega. Tootmisvälise töökoormuse puhul on rangeid piiranguid tavaliselt lihtsam põhjendada.

7. samm: tuvastage kõrvalekalded, mis ületavad kogukulu

Päevane kogukulu on mahajäänud signaal. Paremad hoiatused kasutavad pearaamatu töövälju.

Kasulikud kõrvalekallete kontrollid hõlmavad järgmist:

Kulu eduka päringu kohta töökoormuse järgi.
Väljundi ja märgi suhe võrreldes ajaloolise lähtetasemega.
Proovi hind teenusepakkuja, mudeli ja teenuse järgi.
Tagastussagedus odavamatelt mudelitelt kallimatele.
Kulutamise kiirus praeguses tunnis.
Vahemälu tabamussageduse langus töökoormuse puhul, mis vahemällu salvestamisest eeldatavasti kasu toob.
Tootmisvälised kulutused väljaspool tööaega.
Taotlustel puuduvad nõutavad kuludimensioonid.

Hoiatus, mis ütleb, et kulutused on suured, on vähem kasulik kui hoiatus, mis ütleb, et ühest teenusest pärinevad tootmise kokkuvõtte päringud genereerivad pärast juurutamist kolm korda tavapäraseid väljundmärke.

Soovitatav juurutamise järjekord

Ärge proovige luua kogu arhitektuuri ühe versiooniga. Praktiline jada on järgmine:

Määratlege kuludimensioonide skeem ja omandiregister.
Jagage pakkuja mandaadid meeskonna ja keskkonna lõikes, et töökoormus oleks kõige suurem.
Lisage lüüsi või klienditeegi metaandmete püüdmine.
Looge hinnanguline päringupõhine pearaamat.
Lisage kasutatavate pakkujate ja mudelite jaoks versioonistatud hinnakaart.
Sisestage pakkuja kuluandmed igapäevasesse aruandlustabelisse.
Rakendage igapäevast vastavusse viimist ja dispersiooni jälgimist.
Lisage eelarveeeskirju, hoiatusi ja kinnitamise töövooge.
Vaadake puuduvad metaandmed ja jaotamata kulutused üle igal nädalal.

Esimene kasulik verstapost ei ole täiuslik tagasimakse. See on võimalus ühe tööpäeva jooksul vastata, milline meeskond ja töökoormus põhjustas materiaalse kulu muutuse.

Selgesõnalise otsustamise kompromissid

Pakkuja armatuurlauad versus sisemine pearaamat: pakkuja armatuurlauad on kiiremini kasutuselevõetavad, kuid need vastavad harva tiimide, toodete, keskkondade ja klientide sisemiste kulude dimensioonidele.

Granulaarsus versus operatiivkulud: rohkem võtmeid, projekte, tööruume ja silte parandavad omistamist, kuid suurendavad juhtimistööd. Kasutage piire, mis vastavad tegelikule omandiõigusele.

Hinnanguline kulu versus arve maksumus: päringutaseme hinnangud on õigeaegsed ja toimingute jaoks kasulikud, kuid need ei kajasta automaatselt krediiti, kokkulepitud hindu ega arvelduse korrigeerimisi.

Kesklüüs versus hajutatud seadmed: lüüs tagab järjepideva jõustamise kõigi pakkujate vahel, kuid sellest saab kriitilise tähtsusega infrastruktuur. Jagatud klienditeegi on mõnes keskkonnas lihtsam kasutusele võtta, kuid seda on raskem jõustada.

Auditatavus versus privaatsus: sisu logimine võib uurimist aidata, kuid ainult metaandmete logimine on sageli turvalisem vaikeseade.

Prognoos: kuluraamatud saavad osaks tehisintellekti platvormi juhtimisest

Tõenäoliselt paraneb teenusepakkujapõhine aruandlus, kuid pakkujatevaheline jaotamine nõuab siiski sisemist konteksti. Pakkujad ei saa teada iga ettevõtte meeskonnastruktuuri, toote taksonoomiat, klientide segmenteerimist, kinnitamise töövoogu ega tagasimaksepoliitikat.

Kuna tehisintellekti kasutus levib pilootprojektidest tootmistöövoogudesse, saavad kulureskontrad platvormi tavapärase halduse osaks koos juurdepääsukontrolli, võtmete vaheldumise, auditi logimise, määrapiirangute ja kasutusanalüütikaga. Meeskondadel, kes määravad oma kulude taksonoomia varakult, on hiljem lihtsam eelarveid, klienditasemel jaotamist ja automatiseeritud juhtelemente lisada.

Tehtitav järeldus

Koostage pearaamat vastutuse, mitte diagrammide ümber. Alustage stabiilsete mõõtmete, ulatusega mandaatide ja metaandmete taotlemisega. Säilitage inseneritoimingute jaoks kiire päringupõhine kalkulatsioon ja kooskõlastatud igapäevane finantsarvestus. Prognooside täpseks muutmise asemel ühildage ja säilitage erinevused, et allahindlused, kohustused, krediidid ja arveldusviivitused oleksid nähtavad.

Kasulik esimene versioon võib olla kitsas: üks pakkuja, kolm suurimat töökoormust, meeskonna ja keskkonna ulatusega võtmed, metaandmete kogumine, hinnangulised kulud ja igapäevane võrdlus pakkuja esitatud kogusummadega. Kui see toimib, laiendage sama lepingut pakkujate vahel ja lisage olulistele dimensioonidele eelarvepoliitikad.

Kuidas luua meeskonnapõhine LLM-i kulureskontra mitme AI API vahel