Tehke AI API arveldusraamat: hinnapakkumine, reserveerimine, arveldamine ja vastavusse viimine iga mudelikõne
Praktiline arvelduse kontrolli muster mitme mudeliga lüüside jaoks: hinnake kulusid enne päringut, reserveerige rentniku eelarve, normaliseerige teenusepakkuja kasutust, arveldage tegelikud tasud ja kooskõlastage arved ilma ainult pakkuja töötlemata vastustele tuginemata.
Kliendile suunatud AI API arveldamine ei saa olla teenusepakkuja töötlemata kasutuse igakuine eksport. Kui lüüs avaldab üürnikele, meeskondadele või partneritele mitu mudelit, peab arveldamine enne arve olemasolu vastama raskemale küsimusele: kas see taotlus peaks olema praegu lubatud ja kuidas selle maksumust hiljem selgitatakse?
Praktiline muster on arveldusraamat, millel on neli etappi: pakkumine, reserveerimine, arveldamine ja vastavusse viimine. Enne päringut märkige tõenäoline maksumus. Reserveerige piisavalt üürniku eelarvet, et katta lubatud halvimal juhul. Arveldage tegelik maksumus pärast seda, kui kasutus on teada. Võrrelge lüüsi pearaamat teenusepakkujapoolsete kirjetega, et arved oleksid kaitstud.
Selles artiklis kirjeldatakse seda mitme mudeli API-lüüsi juhtimisahelat. See on kasulik, kas lüüs esitab arveid sisemeeskondadele, ettemaksuklientidele, agentuuri klientidele või alljärgnevatele partneritele.
Arveldusprobleem: teenusepakkuja kasutamine ei ole kliendi arve
Fakt: suured tehisintellekti pakkujad ei avalda üht universaalset märgiloendurit ega üht universaalset hinda. OpenAI avaldab mudelipõhised hinnad eraldi sisendi, vahemällu salvestatud sisendi ja väljundi lubade määradega. OpenAI viipade vahemällu salvestamise aruanded vahemällu salvestatud loa kasutamise kohta API vastuse kasutamise väljal. Antroopsed dokumendid eraldavad loendurid tavaliste sisendmärkide, vahemälu loomise sisendmärkide, vahemälu lugemise sisendmärkide ja väljundmärkide jaoks. Kaksikute hinnakujundus eristab sisendi, väljundi ja muid märgikategooriaid, sealhulgas modaalsuspõhist kasutust, nagu helimärgid.
See tähendab, et lüüs ei saa turvaliselt arvet esitada, korrutades total_tokens ühe hinnaga. See vajab pakkuja-spetsiifilisi adaptereid pakkuja-neutraalse arveldusskeemi taga.
Probleem muutub nähtavamaks järgmistes olukordades:
- Ettemakstud krediit: peab lüüs taotlused tagasi lükkama, enne kui üürnik kulutab alla nulli.
- Partneri juurdehindlused: partner vajab oma kliendile suunatud arvet, mitte teenusepakkuja arve koopiat.
- Voogesitus: vastus algab enne, kui loa lõplik kasutus on teada.
- Viiba vahemällu salvestamine: vahemällu salvestatud sisend võib olla odavam kui vahemällu salvestamata sisend, kuid ainult siis, kui seda mõõdetakse eraldi.
- Põhjendus ja tööriistakasutus: mõned mudelid pakuvad täiendavaid kasutusmõõtmeid, peidetud väljundklasse või meediumiühikuid.
- Pakkuja hinnamuudatused: eelmise kuu arve peab olema ka pärast hinnakaardi muutumist reprodutseeritav.
Soovitus: käsitlege arveldust ainult lisatava finantsreskontra, mitte armatuurlaua päringuna päringulogide üle.
Tuumiarhitektuur
Usaldusväärsel arveldusarhitektuuril on kuus komponenti:
- Üürniku konto: klient, tööruum, edasimüüja klient või sisemine kulukeskus.
- Hinnakaardi teenus: teenusepakkuja, mudeli, arveldusklassi, valuuta ja juurdehindlusreegli versioonide hinnad.
- Hindaja: arvutab päringu parameetrite ja mudeli poliitika põhjal esituse pakkumise.
- Broneeringuraamat: hoiab eelarvet enne teenusepakkuja kõne algust.
- Kasutuse normaliseerija: teisendab teenusepakkujapõhised kasutusväljad sisemisteks arveldusüksusteks.
- Arveldus- ja lepitustööd: viimistlege tasud ja võrrelge neid teenusepakkujapoolsete kirjetega.
Juhtimisvoog näeb välja selline:
kliendi taotlus
-> autentige üürnik ja võti
-> valige mudel ja hinnakaardi versioon
-> hinnangu sisend ja maksimaalne väljundkulu
-> üürniku reservjääk
-> kõne pakkuja
-> normaliseerige tagastatud kasutus
-> arveldada tegelikud kulud
-> vabasta kasutamata broneering
-> väljastada arvevalmis pearaamatu sündmusOluline disainivalik on see, et taotlust ei peetaks lihtsalt järgi. Seda kontrollitakse rahaliselt enne ja pärast täitmist.
1. toiming: hinnapakkumine enne teenusepakkuja kõnet
Eelarve hinnapakkumine peaks olema piisavalt pessimistlik, et eelarvet jõustada, kuid piisavalt seletatav, et seda klientidele või partneritele näidata.
Sisendite hulka kuuluvad tavaliselt:
- üürniku ID ja arveldusplaan;
- API võtme ID või projekti ID;
- pakkuja ja mudeli ID pärast marsruutimisreeglite rakendamist;
- hinnangulised vahemällu salvestamata sisendmärgid;
- teatud vahemällu salvestatud sisendi sobivus, kui see on saadaval;
max_tokens,max_output_tokensvõi samaväärne väljundpiirang;- tööriista, pildi, heli või muud modaalsuse parameetrid;
- partneri juurdehindlus, allahindlus või edasimüüja hinnareegel;
- valuuta- ja ümardamispoliitika.
Lihtne tsitaadi valem teksti genereerimiseks võib olla järgmine:
hinnanguline_kulu =
hinnangulised_vahemälustamata_sisendmärgid * sisendi_määr
+ hinnangulised_vahemällu salvestatud_sisendi_märgid * vahemällu salvestatud_sisendi_määr
+ max_väljundi_märgid * väljundkiirus+ taotluse_tasu
+ partneri_märgistusSoovitus: kui väljundi lõplik pikkus pole teada, tehke reserv konfigureeritud maksimaalse väljundi vastu. Kui rakendus jätab väljundi piiri piiramata, peaks lüüs rakendama rentniku või mudeli vaikeseadet. Eelarve jõustamine ei saa olla deterministlik, kui puudub maksimaalne vastutus.
See võib tagasi lükata mõned taotlused, mis oleksid praktikas olnud odavad. See on kompromiss. Ettemakstud süsteemide puhul on turvalisem vaikimisi pessimistlik broneerimine, kus kasutamata raha vabastatakse pärast arveldamist. Arve saanud äriklientidele võivad meeskonnad lubada pehmeid ülehindlusi ja kasutada pakkumist peamiselt hoiatuste jaoks.
2. samm: reserveerige üürniku eelarve
Broneering kaitseb üürniku kontot lubatud saldost suuremate kulutuste eest. See peaks olema tühine: broneerimine õnnestub ja teenusepakkuja kõne võib alata või taotlus lükatakse tagasi enne, kui teenusepakkuja kulud tekivad.
Broneeringu kirje võib sisaldada järgmist:
Kasutage võrgutõrgete ja kliendi katkestuste korral lühikesi broneeringu aegumisi. Puhastustöö peaks vabastama aegunud broneeringud, mis ei jõudnud lahenduseni. Kuid ärge vabastage broneeringut lihtsalt seetõttu, et klient katkestas ühenduse; teenusepakkuja kõne võib siiski lõppeda ja sellega kaasnevad kulud. Jälgige teenusepakkuja taotluse olekut eraldi.
Soovitus: muutke broneering idempotentseks päringu ID või idempotentsuse võtme abil. Klientide, lüüside või töötajate korduskatsed ei tohiks luua sama loogilise päringu jaoks mitut eelarvepiirangut.
3. samm: normaliseerige teenusepakkuja kasutus
Pakkuja vastused tuleks teisendada väikeseks siseskeemiks. Hoidke see stabiilsena isegi siis, kui pakkujad lisavad uusi kasutusvälju.
Praktiline normaliseeritud kasutusskeem:
See skeem ei ole tahtlikult identne ühegi teenusepakkuja vastusega. See salvestab arveldusmõõtmed, mida arved vajavad, säilitades samal ajal teenusepakkujapõhiste üksuste evakuatsiooniluugid.
Vahemällu salvestatud märgid vajavad oma rida
Fakt: viipe vahemällu salvestamise hind võib erineda vahemällu salvestamata sisendi hinnast. Kui vahemällu salvestatud märgid liidetakse sisendtunnuste koguarvuks, võidakse kliendilt võtta üle tasu või lüüs võib teenusepakkuja kulusid alahinnata. Vahemällu salvestatud sisend peaks ilmuma nii pearaamatus kui ka arvel oma arveldusklassina.
Vahemälu kirjutamine ja vahemälu lugemine ei ole alati samad
Mõned pakkujad eristavad vahemälu kirjete loomist ja vahemälust lugemist. Normaliseerija ei tohiks eeldada, et vahemällu salvestatud sisend tähendab alati ühte arveldusmäära. Kui pakkujal on vahemällu kirjutamise ja vahemälu lugemise märgid, kaardistage need eraldi või säilitage need pakkujaspetsiifiliste allüksustena.
Põhjendused ja varjatud väljund vajavad poliitikat
Mõned mudelid paljastavad arutluskäiguga seotud kasutuse või peidetud väljundloendurid. Kui teenusepakkuja esitab nende üksuste eest arveid, peab lüüs otsustama, kas näidata neid otse, koondada need väljundkategooriasse või loetleda need eraldi arve reana.
Soovitus: klientidele esitatud arvetel tuleks kasutada lihtsat keelt. Näiteks: "arutlusväljundi märgid" on selgem kui töötlemata pakkuja välja nimi. Hoidke töötlemata väljad auditi jaoks kättesaadavaks, kuid ärge sundige iga klienti tarnija sisemisi asju mõistma.
4. toiming: tasuge tegelikud kulud
Arveldus teisendab normaliseeritud kasutuse pearaamatu lõppkirjeteks. See peaks olema ainult lisatav ja viitama taotluses kasutatud hinnakaardi versioonile.
Lõpetatud sündmus võib välja näha järgmine:
Kui taotlus oli reserveeritud väärtusele 0,032100 ja arveldati väärtusega 0,010500, vabastab pearaamat 0,021600 vaba saldo juurde.
Soovitus: ärge kunagi arvutage vanu arve ridu praegusest hinnatabelist ümber. Salvestage muutumatud hinnakaardi versioonid ja lisage versiooni ID igale hinnapakkumisele, broneeringule ja arveldussündmusele. Vastasel juhul võib pärast teenusepakkuja mudelihindade värskendamist muutuda võimatuks arve taasesitamine.
Voogesitustaotlused: kõigepealt broneerige, arveldage hiljem
Voogesitus muudab arveldamise keerulisemaks, kuna kasutaja hakkab väljundit vastu võtma enne, kui lüüs saab teada lõplikust kasutusest. Vastus on see, et ärge jätke lennueelseid kontrolle vahele. Lüüs peaks enne voo avamist reserveerima.
Kasutage seda töövoogu:
- Hinnangu sisendmärgid ja maksimaalne väljundkulu.
- Reserveerige üürniku eelarve.
- Avage teenusepakkuja voog.
- Edastage osad kliendile.
- Jäädvustage lõppkasutus, kui teenusepakkuja selle saadab või kui on saadaval järelkasutuskirje.
- Arveldage tegelik hind ja vabastage kasutamata broneering.
Kui lõppkasutus pole saadaval, märkige arveldus hinnanguliseks, mitte ei teeskle, et see on täpne:
"usage_source": "gateway_estimate",
"is_estimated": tõsi,
"reconciliation_status": "ootel"Soovitus: igapäevane kooskõlastamine peaks seadma esikohale hinnangulised voogesituse sündmused, ebaõnnestunud taotlused, ajalõpud ja korduskatsed. Need on valdkonnad, mis tekitavad kõige tõenäolisemalt erinevusi lüüsikirjete ja pakkuja arvete vahel.
Hinnakaardi versiooni- ja märgistamisreeglid
Hinnakaart peaks olema versioonidega objekt, mitte muutuv arvutustabel.
Minimaalsed väljad:
- pakkuja;
- mudeli ID;
- arveldusklass;
- üksus, näiteks luba, päring, pilt, helisekund või tööriistaüksus;
- ühiku hind;
- valuuta;
- efektiivsed alguse ja lõpu ajatemplid;
- ümardamispoliitika;
- üürniku plaan või partneri märgistusreegel;
- allikaviide ja kinnituse metaandmed.
Märgistusreeglid peaksid olema selged. Näiteks:
- Kulu pluss: teenusepakkuja kulu pluss 20%.
- Fikseeritud jaemüük: üürnik maksab fikseeritud tunnushinna sõltumata teenusepakkuja hinnast.
- Tasmeline: kõigepealt 10 miljonit märki ühe määraga, seejärel madalama määraga.
- Kaasatud krediit: kulutab igakuine hüvitis enne ülearveldamise algust.
Mõiste: hinnakaardi versioonide koostamine lisab operatiivset tööd, kuid takistab arvevaidluste muutumist arheoloogiaks. Klienditoe agent peaks suutma selgitada, miks 3. augustil esitatud taotluse eest arveldati kindla määraga, ilma tänast teenusepakkuja hinnakujundust kontrollimata.
Eraldage arveldusraamat analüütikast
Analüütikal ja arveldamisel on erinevad tolerantsid. Analyticsit saab koondada, viivitada, võtta valimeid või parandada. Arveldamine peab olema täielik, tõhus, auditeeritav ja seletatav.
Kasutage analüütikat selliste küsimuste puhul nagu:
- Millised meeskonnad kasutavad kõige rohkem märke?
- Millised mudelid kasvavad kõige kiiremini?
- Kus saab kiire vahemällu salvestamine kulusid vähendada?
- Millised võtmed esitavad ebatavaliselt kulukaid taotlusi?
Kasutage arveldusraamatut selliste küsimuste korral nagu:
- Kas see taotlus autoriseeriti üürniku saldo arvelt?
- Milline hinnakaardi versioon selle tasu tekitas?
- Kas kasutamata broneering vabastati?
- Kas kliendi arve vastab arveldatud kasutusviisile?
- Kas lüüsi kasutus vastab pakkujapoolsele kasutusele?
Fakt: OpenTelemetry GenAI semantilised kokkulepped hõlmavad loa kasutamise atribuute, nagu sisend- ja väljundmärgid. See on kasulik jälgitavuse ja kulusündmustega jälgede ühendamise jaoks. Kuid telemeetria atribuudid ei asenda hinnakaarte, broneeringuid, arveldust, ümardamist ega arve olekut.
Igapäevase vastavusse viimise töövoog
Komplekteerimisel võrreldakse lüüsi arveldatud pearaamatut teenusepakkujapoolse kasutusega. Eesmärk ei ole täiuslik kokkulepe igal vaheväljal. Eesmärk on tuvastada materjali erinevus piisavalt varakult, et arveid, hinnakaarte või adaptereid parandada.
Praktiline igapäevatöö:
- Grupeerige lüüsi pearaamatu sündmused pakkuja, mudeli, rentniku või API võtme, arveldusklassi ja UTC päeva järgi.
- Tooge pakkujapoolne kasutus, mis on rühmitatud saadaolevate dimensioonide (nt API võtme ID, mudeli ja päeva) alusel.
- Võimalusel normaliseerige pakkuja eksportimine sama adapterkoodi kaudu, mida kasutatakse päringu vastuste jaoks.
- Võrdlege koguseid ja kulusid arveldusklasside kaupa.
- Märgistage lävedest suurem dispersioon, näiteks 0,5% koguseline erinevus või mis tahes suur absoluutkulude erinevus.
- Klassifitseerige dispersiooni põhjused: voogesituse prognoosid, korduskatsed, ebaõnnestunud päringud, vahemälu arvestus, mudeli pseudonüümi muudatused, viivitatud pakkuja kirjed või puuduvad päringu ID-d.
- Vanade arveldussündmuste muutmise asemel loo korrigeerimissündmusi.
Soovitus: kasutage teenusepakkuja API võtmeid rentniku kohta, kui see on operatiivselt teostatav, kuna see lihtsustab kooskõlastamist. Kui see tekitab liiga palju võtmehalduskulusid, vastendage sisemised rentniku ID-d pakkuja metaandmetega, kus neid toetatakse, ja säilitage usaldusväärne päringu ID-sild.
Klientidele arusaadavad arve read
Kliendile suunatud arve ei tohiks peegeldada pakkuja JSON-i. See peaks selgitama arvet stabiilsetes äritingimustes.
Kasulikud arveveerud:
- kuupäevavahemik;
- üürniku, projekti või API võtme silt;
- mudel või mudeliprofiil;
- taotluste arv;
- vahemällu salvestamata sisendmärgid;
- vahemällu salvestatud sisendmärgid;
- väljundmärgid;
- kandja- või tööriistaüksused, kui need on olemas;
- allahindlused, krediidid või juurdehindlused;
- kogusumma ja valuuta.
Partneride puhul lisage nii hulgi- kui ka jaehind ainult siis, kui ärimudel seda nõuab. Paljudel edasimüüjate arvetel tuleks näidata ainult jaekasutust, samas kui partnerite armatuurlauad võivad marginaali näidata eraldi.
Komppror: ühtne arveskeem parandab loetavust, kuid teenusepakkujapõhised arveldusandmed vajavad siiski turvaluuke. Hoidke arve read vaikimisi lihtsad ja pakkuge eksporti edasijõudnud klientidele, kes vajavad üksikasjalikke auditivälju.
Rakendamise kontroll-loend
Enne käivitamist
- Määratlege normaliseeritud arveldusklassid kõigi toetatud pakkujate jaoks.
- Looge kehtivuskuupäevadega muutumatuid hinnakaardi versioone.
- Nõuge väljundpiiranguid või rakendage lüüsi vaikeseadeid.
- Rakendage aatomireservatsioonid idempotentsusvõtmetega.
- Määrake iga valuuta jaoks ümardamisreeglid.
- Otsustage, kuidas esitada arveid vahemällu salvestatud žetoonide, arutlusmärkide, meediumiühikute ja tasude taotlemise kohta.
- Testi korduskatsed, ajalõpud, kliendi katkestused ja pakkuja vead.
- Ehitatud sündmuste muutmise asemel looge korrigeerimissündmuste mehhanism.
Taotluse käsitlemise ajal
- Autentige üürnik ja võti.
- Lasendage lõplik mudel pärast marsruutimist ja varupoliitikat.
- Valige õige hinnakaardi versioon.
- Pakkuge halvimal juhul kulu.
- reserveerige saldo või lükake taotlus tagasi.
- Salvestage pakkuja päringu ID, kui see on saadaval.
- Normaliseerige kasutus vastusest.
- Arveldage, vabastage kasutamata broneering ja edastage arvevalmis sündmused.
Pärast päringu käsitlemist
- Käitage igapäevast vastavusseviimist pakkuja, võtme, mudeli, arveldusklassi ja päeva järgi.
- Vaadake üle hinnangulised voogesituse arveldused.
- Märgistage mudeli kasutamine puuduvate hinnakaardi kirjetega.
- Jälgige vahemällu salvestatud märgiarvestuse põhjustatud dispersiooni.
- Loo enne lõplikku arveldamist kliendi arvete eelvaateid.
Prognoosid, mida plaanida
Prognoos: AI API arveldamine muutub mitmemõõtmelisemaks, mitte vähem. Tõenäoliselt laienevad märgiklassid, vahemäluklassid, meediumiüksused, tööriistade täitmine ja arutluskäiguga seotud loendurid mudeli võimaluste muutudes.
Prognoos: kliendid ootavad kasutusselgitusi taotluse, võtme, projekti ja arve tasemel. Igakuine kogusumma ilma jälgitavate reaüksusteta ei ole API-juurdepääsu edasimüümise või ettemakstud eelarvete jõustamiseks piisav.
Prognoos: lüüsid, mis juba eraldavad hinnapakkumise, broneerimise, arvelduse ja kooskõlastamise, kohanduvad kiiremini uute hinnakujundusmudelitega, kuna need saavad lisada arveldusklasse ilma kogu arvesüsteemi ümber kirjutamata.
Tehtitav järeldus
Kui paljastate ühe lüüsi kaudu mitu tehisintellekti pakkujat, koostage arveldusraamat, enne kui arveldusvaidlused probleemi sunnivad. Alustage nelja garantiiga:
- Igale arveldatavale taotlusele esitatakse lennueelne hinnapakkumine.
- Igal ettemakstud või piiratud üürnikul on eelarve reserveeritud enne teenusepakkuja kõne algust.
- Iga pakkuja vastus normaliseeritakse stabiilseteks arveldusklassideks.
- Iga arvet saab võrrelda teenusepakkujapoolse kasutamise ja sel ajal kasutatud täpse hinnakaardi versiooniga.
See juhtimisahel muudab ühtse AI API arveldamise klientidele arusaadavaks, ettemakstud krediitidele jõustatavaks, partnerite juurdehindluste jaoks paindlikuks ja auditeeritavaks, kui teenusepakkuja hinnakujundus või kasutusvormingud muutuvad.