Zgradite knjigo obračunavanja API-ja AI: ponudite, rezervirajte, poravnajte in uskladite vsak modelni klic

Zaračunavanje AI API, usmerjeno k strankam, ne more biti mesečni izvoz neobdelane uporabe ponudnika. Če prehod izpostavi več modelov najemnikom, skupinam ali partnerjem, mora obračunavanje odgovoriti na težje vprašanje, preden obstaja račun: ali je treba to zahtevo dovoliti zdaj in kako bodo njeni stroški pojasnjeni pozneje?

Praktični vzorec je obračunska knjiga s štirimi stopnjami: navedba, rezervacija, poravnava in uskladitev. Pred zahtevo navedite verjeten strošek. Rezervirajte dovolj proračuna za najemnika, da pokrijete dovoljeni najslabši primer. Poravnajte dejanske stroške, ko je uporaba znana. Uskladite glavno knjigo prehoda z zapisi na strani ponudnika, da bodo računi ostali upravičljivi.

Ta članek opisuje to krmilno zanko za prehod API-ja z več modeli. Uporabno je ne glede na to, ali prehod zaračunava notranjim ekipam, predplačnikom, strankam agencije ali nadaljnjim partnerjem.

Težava z obračunavanjem: uporaba ponudnika ni račun stranke

Dejstvo: večji ponudniki umetne inteligence ne izpostavljajo enega univerzalnega števca žetonov ali ene univerzalne cene. OpenAI objavlja cene po modelu z ločenimi vhodnimi, predpomnjenimi vhodnimi in izhodnimi cenami žetonov. Predpomnjenje poziva OpenAI poroča o uporabi predpomnjenega žetona v polju uporabe odgovora API-ja. Antropični dokumenti ločijo števce za običajne vhodne žetone, vhodne žetone za ustvarjanje predpomnilnika, vhodne žetone za branje predpomnilnika in izhodne žetone. Cene Gemini razlikujejo vhodne, izhodne in druge kategorije žetonov, vključno z uporabo, specifično za način, kot so zvočni žetoni.

To pomeni, da prehod ne more varno zaračunavati z množenjem total_tokens z eno ceno. Potrebuje adapterje, specifične za ponudnika, za shemo zaračunavanja, nevtralno od ponudnika.

Težava postane bolj vidna v teh situacijah:

• Predplačniški krediti: prehod mora zavrniti zahteve, preden najemnik porabi pod ničlo.
• Partnerski pribitki: partner potrebuje lasten račun, namenjen stranki, ne kopije računa ponudnika.
• Pretakanje: odgovor se začne, preden je znana končna uporaba žetona.
• Takojšnje predpomnjenje: predpomnjeni vnos je lahko cenejši od nepredpomnjenega vnosa, vendar le, če se meri ločeno.
• Razmišljanje in uporaba orodja: nekateri modeli razkrivajo dodatne dimenzije uporabe, skrite izhodne razrede ali medijske enote.
• Spremembe cene ponudnika: račun iz prejšnjega meseca mora biti še vedno ponovljiv tudi po spremembi cenovnika.

Priporočilo: zaračunavanje obravnavajte kot finančno knjigo, ki je samo dodajanje, ne kot poizvedbo na nadzorni plošči nad dnevniki zahtev.

Osnovna arhitektura

Zanesljiva arhitektura zaračunavanja ima šest komponent:

1. Račun najemnika: stranka, delovni prostor, stranka preprodajalca ali interni stroškovni center.
2. Storitev cenovnega razreda: različice cen za ponudnika, model, obračunski razred, valuto in pravilo pribitka.
3. Ocenjevalec: izračuna ponudbo pred tiskom iz parametrov zahteve in politike modela.
4. Knjiga rezervacij: hrani proračun, preden se začne klic ponudnika.
5. Normalizator uporabe: pretvori polja uporabe, specifična za ponudnika, v notranje obračunske enote.
6. Opravila poravnave in usklajevanja: dokončajte stroške in jih primerjajte z zapisi na strani ponudnika.

Potek nadzora izgleda takole:

zahteva stranke
  -> overi najemnika in ključ
  -> izberite model in različico cenovnika
  -> ocena vhodnih in najvišjih izhodnih stroškov
  -> rezervno stanje najemnika
  -> klic ponudnika
  -> normalizira ponovno uporabo
  -> poravnati dejanske stroške
  -> sprosti neuporabljeno rezervacijo
  -> oddaj dogodek glavne knjige, pripravljen za račun

Pomembna izbira oblikovanja je, da zahteve ne upoštevamo le. Pred in po izvedbi je finančno nadzorovana.

1. korak: ponudba pred klicem ponudnika

Cena pred tiskom mora biti dovolj pesimistična, da uveljavi proračune, vendar dovolj razložljiva, da se pokaže strankam ali partnerjem.

Vnosi običajno vključujejo:

• ID najemnika in obračunski načrt;
• ID ključa API ali ID projekta;
• ID ponudnika in modela po uporabi pravil usmerjanja;
• ocenjeni nepredpomnjeni vhodni žetoni;
• znana primernost predpomnjenega vnosa, če je na voljo;
• max_tokens, max_output_tokens ali enakovredna izhodna omejitev;
• orodja, slike, zvoka ali drugih parametrov modalnosti;
• partnerski pribitek, popust ali pravilo o cenah prodajalca;
• politika valute in zaokroževanja.

Preprosta formula citatov za ustvarjanje besedila je lahko:

ocenjeni_stroški =
  ocenjeni_uncached_input_tokens * input_rate
+ ocenjeni_predpomnjeni_vhodni_žetoni * predpomnjena_vhodna_stopnja
+ max_output_tokens * output_rate+ pristojbina za zahtevo
+ partner_markup

Priporočilo: ko končna izhodna dolžina ni znana, rezervirajte glede na konfigurirano največjo izhodno vrednost. Če aplikacija pusti omejitev izhoda neomejeno, mora prehod uporabiti privzeto najemnika ali model. Izvrševanje proračuna ne more biti deterministično, če ni največje odgovornosti.

To lahko zavrne nekatere zahteve, ki bi bile v praksi poceni. To je kompromis. Za predplačniške sisteme je varnejša privzeta vrednost pesimistična rezervacija z neporabljenimi sredstvi, ki se sprostijo po poravnavi. Za podjetniške stranke, ki prejemajo račune, lahko ekipe dovolijo mehke presežke in ponudbo uporabijo predvsem za opozorila.

2. korak: rezervirajte proračun za najemnika

Rezervacija ščiti račun najemnika pred porabo, ki presega dovoljeno stanje. Biti mora atomičen: ali rezervacija uspe in se lahko začne klic ponudnika ali pa je zahteva zavrnjena, preden nastane kakršen koli strošek ponudnika.

Zapis rezervacije lahko vključuje:

{
  "reservation_id": "res_01J...",
  "tenant_id": "najemnik_123",
  "api_key_id": "ključ_456",
  "request_id": "req_789",
  "ponudnik": "primer_ponudnika",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "quoted_amount": "0,032100",
  "valuta": "USD",
  "status": "rezervirano",
  "expires_at": "2026-08-11T12:05:00Z"
}

Uporabite kratke poteke rezervacij za napake v omrežju in prekinitve povezave odjemalcev. Opravilo čiščenja mora sprostiti potekle rezervacije, ki nikoli niso dosegle poravnave. Vendar ne sprostite rezervacije zgolj zato, ker je odjemalec prekinil povezavo; klic ponudnika se lahko še vedno zaključi in povzroči stroške. Ločeno spremljajte stanje zahteve ponudnika.

Priporočilo: naredite rezervacijo idempotentno z ID-jem zahteve ali ključem idempotence. Ponovni poskusi odjemalcev, prehodov ali delavcev ne bi smeli ustvariti več proračunskih zadržanj za isto logično zahtevo.

3. korak: normalizirajte uporabo ponudnika

Odzive ponudnika je treba pretvoriti v majhno notranjo shemo. Naj bo stabilen tudi, ko ponudniki dodajajo nova polja uporabe.

Praktična normalizirana shema uporabe:

{
  "input_uncached_tokens": 1200,
  "input_cached_tokens": 800,
  "cache_write_tokens": 0,
  "output_tokens": 650,
  "reasoning_or_hidden_output_tokens": 0,
  "orodne_ali_medijske_enote": [],
  "request_fee_units": 1,
  "provider_request_id": "prov_abc",
  "usage_source": "provider_response",
  "je_ocenjeno": napačno
}

Ta shema namenoma ni enaka odgovoru katerega koli ponudnika. Zajame obračunske dimenzije, ki jih potrebujejo računi, hkrati pa ohranja zasilne lopute za enote, specifične za ponudnika.

Predpomnjeni žetoni potrebujejo svojo vrstico

Dejstvo: predpomnjenje poziva se lahko ceni drugače kot nepredpomnjen vnos. Če se predpomnjeni žetoni združijo v skupne vhodne žetone, se lahko stranki zaračuna previsoko ali pa prehod podceni stroške ponudnika. Predpomnjeni vnos mora biti prikazan kot lasten obračunski razred tako v knjigi kot na računu.

Pisanje in branje predpomnilnika nista vedno enaka

Nekateri ponudniki razlikujejo med ustvarjanjem vnosov v predpomnilniku in branjem iz predpomnilnika. Normalizator ne sme domnevati, da predpomnjeni vnos vedno pomeni eno obračunsko stopnjo. Če ima ponudnik žetone za pisanje v predpomnilnik in žetone za branje predpomnilnika, jih preslikajte ločeno ali jih ohranite kot podenote, specifične za ponudnika.

Razmišljanje in skriti rezultat potrebujeta pravilnik

Nekateri modeli razkrivajo uporabo, povezano z razmišljanjem, ali skrite izhodne števce. Če ponudnik zaračuna te enote, se mora prehod odločiti, ali jih bo prikazal neposredno, uvrstil v izhodno kategorijo ali jih navedel kot ločeno vrstico računa.

Priporočilo: računi, namenjeni strankam, morajo biti v preprostem jeziku. Na primer: »reasoning output tokens« je jasnejši od neobdelanega imena polja ponudnika. Neobdelana polja naj bodo na voljo za revizijo, vendar ne silite vsake stranke, da razume notranjost ponudnika.

4. korak: poravnajte dejanske stroške

Poravnava pretvori normalizirano uporabo v končne vnose v glavno knjigo. Biti mora samo za dodajanje in se mora sklicevati na različico cenika, uporabljeno za zahtevo.

Dogovorjeni dogodek bi lahko izgledal takole:

{
  "ledger_event_id": "led_01J...",
  "event_type": "poravnava",
  "tenant_id": "najemnik_123",
  "request_id": "req_789",
  "reservation_id": "res_01J...",
  "ponudnik": "primer_ponudnika",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "črte": [
    {
      "billing_class": "input_uncached_tokens",
      "količina": 1200,
      "enota": "žeton",
      "cena_enote": "0,00000250",
      "znesek": "0,003000"
    },
    {
      "billing_class": "input_cached_tokens",
      "količina": 800,
      "enota": "žeton",
      "cena_enote": "0,00000125",
      "znesek": "0,001000"
    },
    {
      "billing_class": "output_tokens",
      "količina": 650,
      "enota": "žeton","cena_enote": "0,00001000",
      "znesek": "0,006500"
    }
  ],
  "skupni_znesek": "0,010500",
  "valuta": "USD",
  "status": "naseljen"
}

Če je bila zahteva rezervirana za 0,032100 in poravnana na 0,010500, glavna knjiga sprosti 0,021600 nazaj na razpoložljivo stanje.

Priporočilo: nikoli ne preračunavajte starih vrstic računa iz trenutne tabele cen. Shranite nespremenljive različice cenovnih kartic in pripnite ID različice vsaki ponudbi, rezervaciji in dogodku poravnave. V nasprotnem primeru lahko postane nemogoče izdati računa, potem ko ponudnik posodobi cene modela.

Zahteve za pretakanje: najprej rezervirajte, poravnajte pozneje

Pretakanje otežuje obračunavanje, ker uporabnik začne prejemati izhod, preden prehod izve končno porabo. Odgovor je, da ne preskočite pregledov pred letom. Prehod mora rezervirati, preden odpre tok.

Uporabite ta potek dela:

1. Ocenite vhodne žetone in najvišje izhodne stroške.
2. Rezervirajte proračun najemnika.
3. Odprite tok ponudnika.
4. Posredovanje kosov odjemalcu.
5. Zajemite končno uporabo, ko jo pošlje ponudnik ali ko je na voljo nadaljnji zapis o uporabi.
6. Poravnajte dejanske stroške in sprostite neuporabljeno rezervacijo.

Če končna uporaba ni na voljo, poravnavo označite kot ocenjeno, namesto da se pretvarjate, da je točna:

"usage_source": "gateway_estimate",
"is_estimated": res,
"usklajevalni_status": "v teku"

Priporočilo: dnevno usklajevanje mora dati prednost predvidenim pretočnim dogodkom, neuspelim zahtevam, časovnim omejitvam in ponovnim poskusom. To so področja, ki najverjetneje povzročajo razlike med zapisi prehoda in računi ponudnika.

Različica in pravila za označevanje cenovnika

Cenik mora biti predmet z različico in ne spremenljiva preglednica.

Najmanjše število polj:

• ponudnik;
• ID modela;
• obračunski razred;
• enota, kot je žeton, zahteva, slika, zvočna sekunda ali orodna enota;
• cena na enoto;
• valuta;
• dejanski začetni in končni časovni žig;
• politika zaokroževanja;
• najemniški načrt ali pravilo označevanja partnerja;
• referenca vira in metapodatki o odobritvi.

Pravila označevanja morajo biti izrecna. Na primer:

• Stroški plus: stroški ponudnika plus 20 %.
• Fiksna maloprodaja: najemnik plača fiksno ceno žetona ne glede na ceno ponudnika.
• Ravnostopenjsko: najprej 10 milijonov žetonov po eni stopnji, nato nižja stopnja.
• Vključeni krediti: uporaba porabi mesečno nadomestilo, preden se začne zaračunavanje presežka.

Kompromis: različica tarifne kartice dodaja operativno delo, vendar preprečuje, da bi spori glede računov postali arheologija. Agent za podporo strankam bi moral biti sposoben pojasniti, zakaj je bila zahteva 3. avgusta zaračunana po določeni tarifi, ne da bi preveril današnje cene ponudnika.

Ločite računsko knjigo od analitike

Analitika in obračunavanje imata različne tolerance. Analitike je mogoče združiti, odložiti, vzorčiti ali popraviti. Obračunavanje mora biti popolno, idempotentno, revizijsko in razložljivo.

Uporabite analitiko za vprašanja, kot so:

• Katere ekipe uporabljajo največ žetonov?
• Kateri modeli rastejo najhitreje?
• Kje lahko hitro predpomnjenje zmanjša stroške?
• Kateri ključi ustvarijo neobičajno drage zahteve?

Uporabite knjigo obračunov za vprašanja, kot so:

• Ali je bila ta zahteva odobrena v breme stanja najemnika?
• Katera različica cenika je povzročila to bremenitev?
• Je bila neizkoriščena rezervacija sproščena?
• Ali račun stranke ustreza poravnani porabi?
• Ali se uporaba prehoda ujema z uporabo na strani ponudnika?

Dejstvo: Semantične konvencije OpenTelemetry GenAI vključujejo atribute uporabe žetonov, kot so vhodni in izhodni žetoni. To je uporabno za opazljivost in povezovanje sledi s stroškovnimi dogodki. Toda atributi telemetrije niso nadomestilo za cenovnike, rezervacije, poravnavo, zaokroževanje in stanje računa.

Potek dela dnevnega usklajevanja

Uskladitev primerja poravnano knjigo prehoda z uporabo na strani ponudnika. Cilj ni popoln dogovor o vsakem vmesnem področju. Cilj je dovolj zgodaj zaznati materialno odstopanje, da se lahko popravijo računi, tarife ali adapterji.

Praktično vsakodnevno delo:

1. Združi dogodke glavne knjige prehoda po ponudniku, modelu, najemniku ali ključu API-ja, obračunskem razredu in dnevu UTC.
2. Pridobi uporabo na strani ponudnika, razvrščeno glede na razpoložljive dimenzije, kot so ID ključa API, model in dan.
3. Normalizirajte izvoze ponudnika prek iste kode adapterja, ki se uporablja za odgovore na zahteve, kjer je to mogoče.
4. Primerjajte količine in stroške glede na obračunski razred.
5. Označi odstopanje nad pragovi, kot je 0,5-odstotna količinska razlika ali katera koli velika absolutna razlika v stroških.
6. Razvrstite vzroke odstopanj: ocene pretakanja, ponovni poskusi, neuspele zahteve, obračunavanje predpomnilnika, spremembe vzdevkov modela, zakasnjeni zapisi ponudnika ali manjkajoči ID-ji zahtev.
7. Ustvarite prilagoditvene dogodke namesto urejanja starih obračunskih dogodkov.

Priporočilo: uporabite ključe API ponudnika za vsakega najemnika, kjer je to operativno izvedljivo, ker poenostavlja usklajevanje. Če to povzroči prevelike stroške upravljanja ključev, preslikajte notranje ID-je najemnikov v metapodatke ponudnika, kjer so podprti, in ohranite zanesljiv most ID-ja zahteve.

Vrstice računa, ki jih stranke razumejo

Račun, namenjen stranki, ne sme odražati JSON ponudnika. Pojasniti mora račun v stabilnih poslovnih pogojih.

Uporabni stolpci računa:

• časovno obdobje;
• oznaka ključa najemnika, projekta ali API-ja;
• model ali profil modela;
• število zahtev;
• nepredpomnjeni vhodni žetoni;
• predpomnjeni vhodni žetoni;
• izhodni žetoni;
• medijske ali orodne enote, če je primerno;
• popusti, krediti ali pribitki;
• skupni znesek in valuta.

Za partnerje vključite veleprodajne in maloprodajne stroške samo, če to zahteva poslovni model. Številni računi preprodajalcev bi morali prikazovati samo maloprodajno porabo, medtem ko lahko partnerske nadzorne plošče prikazujejo maržo ločeno.

Kompromis: poenotena shema računov izboljša berljivost, vendar podrobnosti zaračunavanja, specifične za ponudnika, še vedno potrebujejo zaščitne lopute. Naj bodo vrstice računa privzeto preproste in zagotovite izvoz za napredne stranke, ki potrebujejo podrobna revizijska polja.

Kontrolni seznam za implementacijo

Pred zagonom

• Določite normalizirane obračunske razrede za vse podprte ponudnike.
• Ustvarite nespremenljive različice cenovnih kartic z datumi veljavnosti.
• Zahtevaj omejitve izpisa ali uporabi privzete nastavitve prehoda.
• Implementirajte atomske rezervacije s ključi idempotence.
• Nastavite pravila zaokroževanja za vsako valuto.
• Odločite se, kako zaračunati predpomnjene žetone, žetone za sklepanje, medijske enote in nadomestila za zahteve.
• Ponovni preizkusi, časovne omejitve, prekinitve povezave odjemalca in napake ponudnika.
• Izdelajte mehanizem za prilagajanje dogodkov namesto urejanja poravnanih dogodkov.

Med obravnavanjem zahteve

• Preverite pristnost najemnika in ključa.
• Razreši končni model po usmeritvi in nadomestni politiki.
• Izberite pravilno različico cenika.
• Navedite najslabši možni strošek.
• Rezervirajte stanje ali zavrnite zahtevo.
• Zabeleži ID zahteve ponudnika, ko je na voljo.
• Normaliziraj uporabo iz odgovora.
• Poravnava, sprostitev neuporabljene rezervacije in oddaja dogodkov pripravljenosti na račun.

Po obdelavi zahteve

• Zaženi dnevno usklajevanje glede na ponudnika, ključ, model, obračunski razred in dan.
• Preglejte predvidene obračune pretakanja.
• Označite uporabo modela z manjkajočimi vnosi v ceniku.
• Spremljaj varianco, ki jo povzroča obračunavanje predpomnjenega žetona.
• Ustvarjanje predogledov računov strank pred končnim obračunom.

Napovedi za načrtovanje

Napoved: obračunavanje API-ja AI bo postalo bolj večdimenzionalno, ne manj. Razredi žetonov, razredi predpomnilnika, medijske enote, izvajanje orodij in števci, povezani z sklepanjem, se bodo verjetno še naprej širili, ko se bodo zmogljivosti modela spreminjale.

Predvidevanje: stranke bodo pričakovale pojasnila uporabe na ravni zahteve, ključa, projekta in računa. Mesečna vsota brez sledljivih elementov vrstic ne bo zadostovala za ekipe, ki preprodajajo dostop do API-ja ali uveljavljajo predplačniške proračune.

Predvidevanje: prehodi, ki že ločujejo ponudbo, rezervacijo, poravnavo in uskladitev, se bodo hitreje prilagodili novim cenovnim modelom, ker lahko dodajajo obračunske razrede, ne da bi prepisali celoten sistem fakturiranja.

Dejanski sklep

Če razkrijete več ponudnikov umetne inteligence prek enega prehoda, zgradite knjigo obračunavanja, preden spori glede obračunavanja povzročijo težavo. Začnite s štirimi jamstvi:

1. Vsaka plačljiva zahteva prejme predračun pred tiskom.
2. Vsak predplačniški ali omejeni najemnik ima rezerviran proračun, preden se začne klic ponudnika.
3. Vsak odziv ponudnika je normaliziran v stabilne obračunske razrede.
4. Vsak račun je mogoče uskladiti z uporabo na strani ponudnika in točno različico tarife, ki je bila takrat uporabljena.

Zaradi te nadzorne zanke je poenoteno zaračunavanje API-ja AI razumljivo za stranke, izvršljivo za predplačniške kredite, prilagodljivo za pribitke partnerjev in revizijsko, ko se cene ponudnika ali formati uporabe spremenijo.

Sorodno branje

• združevanje sledi LLM z zapisi o uporabi in stroških
• izdelava portalov za preprodajalce z merjenjem uporabe najemnikov
• uporaba hitrega predpomnjenja ob ohranjanju razumljivosti zaračunavanja