Izgradite AI API knjigu naplate: ponudite, rezervirajte, poravnajte i uskladite svaki model poziva

Korisnička AI API naplata ne može biti mjesečni izvoz neobrađene upotrebe pružatelja usluga. Ako pristupnik izloži više modela stanarima, timovima ili partnerima, naplata mora odgovoriti na teže pitanje prije nego što faktura postoji: treba li ovaj zahtjev biti dopušten upravo sada i kako će se njegov trošak kasnije objasniti?

Praktični obrazac je knjiga naplate s četiri faze: ponuda, rezerva, podmirenje i usklađivanje. Prije zahtjeva navedite vjerojatnu cijenu. Rezervirajte dovoljno proračuna stanara da pokrijete dopušteni najgori slučaj. Podmirite stvarni trošak nakon što postane poznata upotreba. Uskladite glavnu knjigu pristupnika sa zapisima na strani pružatelja tako da fakture ostanu branjive.

Ovaj članak opisuje tu kontrolnu petlju za API pristupnik s više modela. Korisno je bilo da gateway naplaćuje interne timove, prepaid klijente, agencijske klijente ili nizvodne partnere.

Problem s naplatom: korištenje davatelja usluga nije faktura korisnika

Činjenica: glavni pružatelji AI ne izlažu jedan univerzalni brojač tokena ili jednu univerzalnu cijenu. OpenAI objavljuje cijene po modelu s odvojenim ulaznim, predmemoriranim ulaznim i izlaznim cijenama tokena. OpenAI prompt caching izvještava o korištenju predmemoriranog tokena u API polju korištenja odgovora. Anthropic dokumentira zasebne brojače za normalne ulazne tokene, ulazne tokene stvaranja predmemorije, ulazne tokene čitanja predmemorije i izlazne tokene. Gemini cijene razlikuju ulazne, izlazne i druge kategorije tokena, uključujući upotrebu specifičnu za modalitet kao što su audio tokeni.

To znači da gateway ne može sigurno naplaćivati množenjem total_tokens s jednom cijenom. Potrebni su mu adapteri specifični za pružatelja usluga koji stoje iza sheme naplate neutralne prema pružatelju usluga.

Problem postaje vidljiviji u ovim situacijama:

• Unaprijed plaćeni krediti: pristupnik mora odbiti zahtjeve prije nego što stanar potroši ispod nule.
• Partnerske marže: partner treba vlastitu fakturu upućenu klijentu, a ne kopiju računa davatelja usluga.
• Streaming: odgovor počinje prije nego što je poznata konačna upotreba tokena.
• Brzo predmemoriranje: predmemorirani unos može biti jeftiniji od nekošpiranog unosa, ali samo ako se mjeri zasebno.
• Razumovanje i korištenje alata: neki modeli otkrivaju dodatne dimenzije upotrebe, skrivene izlazne klase ili medijske jedinice.
• Promjene cijena pružatelja usluga: faktura od prošlog mjeseca i dalje se mora moći reproducirati nakon promjene cjenika.

Preporuka: tretirajte naplatu kao financijsku knjigu samo za dodavanje, a ne kao upit na nadzornoj ploči preko zapisa zahtjeva.

Osnovna arhitektura

Pouzdana arhitektura naplate ima šest komponenti:

1. Račun zakupca: kupac, radni prostor, klijent prodavača ili interno troškovno mjesto.
2. Usluga cjenika: verzirane cijene za pružatelja usluga, model, klasu naplate, valutu i pravilo marže.
3. Procjenitelj: izračunava ponudu prije provjere iz parametara zahtjeva i politike modela.
4. Knjiga rezervacija: drži proračun prije nego što poziv davatelja započne.
5. Normalizator upotrebe: pretvara polja upotrebe specifična za pružatelja usluge u interne obračunske jedinice.
6. Poslovi nagodbe i usklađivanja: dovršite troškove i usporedite ih sa zapisima na strani pružatelja usluga.

Kontrolni tijek izgleda ovako:

client request
  -> authenticate tenant and key
  -> select model and rate-card version
  -> estimate input and max output cost
  -> reserve tenant balance
  -> call provider
  -> normalize returned usage
  -> settle actual cost
  -> release unused reservation
  -> emit invoice-ready ledger event

Važan izbor dizajna je da se zahtjev ne promatra samo. Financijski je kontroliran prije i poslije izvršenja.

1. korak: ponuda prije poziva davatelja usluge

Ponuda prije leta trebala bi biti dovoljno pesimistična da provede proračune, ali dovoljno objašnjiva da se pokaže klijentima ili partnerima.

Unosi obično uključuju:

• ID stanara i plan naplate;
• API ID ključa ili ID projekta;
• ID pružatelja usluga i modela nakon primjene pravila usmjeravanja;
• procijenjeni nekeširani ulazni tokeni;
• poznata podobnost za predmemorirani unos, ako je dostupna;
• max_tokens, max_output_tokens ili ekvivalentno ograničenje izlaza;
• parametri alata, slike, zvuka ili drugih modaliteta;
• partnerska marža, popust ili pravilo cijena prodavača;
• pravila o valuti i zaokruživanju.

Jednostavna formula citata za generiranje teksta može biti:

estimated_cost =
  estimated_uncached_input_tokens * input_rate
+ estimated_cached_input_tokens   * cached_input_rate
+ max_output_tokens               * output_rate
+ request_fee
+ partner_markup

Preporuka: kada je konačna duljina izlaza nepoznata, rezervirajte prema konfiguriranom maksimalnom izlazu. Ako aplikacija ne ograničava ograničenje izlaza, pristupnik bi trebao primijeniti zadanu zakupca ili model. Izvršenje proračuna ne može biti determinističko ako ne postoji najveća obveza.

Ovo može odbiti neke zahtjeve koji bi u praksi bili jeftini. To je kompromis. Za prepaid sustave, sigurnija zadana vrijednost je pesimistična rezervacija s neiskorištenim sredstvima koja se oslobađaju nakon namire. Za poslovne klijente s fakturiranjem timovi mogu dopustiti blaga prekoračenja i koristiti ponudu uglavnom za upozorenja.

2. korak: rezervirajte proračun stanara

Rezervacija štiti račun stanara od potrošnje veće od dopuštenog salda. Trebao bi biti atomski: ili rezervacija uspije i poziv pružatelja može započeti ili se zahtjev odbija prije nego nastane bilo kakav trošak pružatelja.

Zapis rezervacije može uključivati:

{
  "reservation_id": "res_01J...",
  "tenant_id": "tenant_123",
  "api_key_id": "key_456",
  "request_id": "req_789",
  "provider": "example_provider",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "quoted_amount": "0.032100",
  "currency": "USD",
  "status": "reserved",
  "expires_at": "2026-08-11T12:05:00Z"
}

Koristite kratke rokove isteka rezervacije za kvarove na mreži i prekide veze s klijentima. Posao čišćenja trebao bi osloboditi istekle rezervacije koje nikada nisu dosegle poravnanje. Međutim, nemojte otpuštati rezervaciju samo zato što je klijent prekinuo vezu; poziv davatelja usluga mogao bi ipak završiti i izazvati troškove. Zahtjev pružatelja praćenja navedite odvojeno.

Preporuka: napravite rezervaciju idempotentnom ID-om zahtjeva ili ključem idempotencije. Ponovni pokušaji od strane klijenata, pristupnika ili radnika ne bi trebali stvoriti više proračunskih zadržavanja za isti logički zahtjev.

3. korak: normalizirajte upotrebu davatelja usluga

Odgovori davatelja trebaju se pretvoriti u malu internu shemu. Održavajte ga stabilnim čak i kada davatelji dodaju nova polja upotrebe.

Praktična normalizirana shema upotrebe:

{
  "input_uncached_tokens": 1200,
  "input_cached_tokens": 800,
  "cache_write_tokens": 0,
  "output_tokens": 650,
  "reasoning_or_hidden_output_tokens": 0,
  "tool_or_media_units": [],
  "request_fee_units": 1,
  "provider_request_id": "prov_abc",
  "usage_source": "provider_response",
  "is_estimated": false
}

Ova shema namjerno nije identična bilo kojem odgovoru pružatelja usluga. Hvata dimenzije naplate koje su potrebne fakturama, dok istovremeno čuva izlazne otvore za jedinice specifične za pružatelja usluga.

Predmemorirani tokeni trebaju vlastiti red

Činjenica: promptno predmemoriranje može se naplaćivati drugačije od ulaza bez predmemoriranja. Ako se predmemorirani tokeni spoje u ukupne ulazne tokene, korisniku se može naplatiti više ili pristupnik može podcijeniti cijenu pružatelja. Predmemorirani unos trebao bi se pojaviti kao vlastita klasa naplate i u glavnoj knjizi i na fakturi.

Pisanje i čitanje predmemorije nisu uvijek isto

Neki pružatelji usluga razlikuju stvaranje unosa u predmemoriju i čitanje iz predmemorije. Normalizator ne bi trebao pretpostaviti da predmemorirani unos uvijek znači jednu stopu naplate. Ako pružatelj ima tokene za pisanje u predmemoriju i tokene za čitanje u predmemoriju, mapirajte ih zasebno ili ih sačuvajte kao podjedinice specifične za pružatelja usluga.

Razumovanje i skriveni rezultat trebaju pravilo

Neki modeli otkrivaju korištenje povezano s obrazloženjem ili skrivene izlazne brojače. Ako pružatelj naplati te jedinice, pristupnik mora odlučiti hoće li ih prikazati izravno, uvrstiti u kategoriju izlaza ili ih ispisati kao zasebnu liniju fakture.

Preporuka: fakture upućene kupcima trebaju biti jednostavnim jezikom. Na primjer: "izlazni tokeni obrazloženja" jasniji je od sirovog naziva polja pružatelja. Držite neobrađena polja dostupnima za reviziju, ali nemojte prisiljavati svakog korisnika da razumije interne odredbe pružatelja.

Korak 4: podmirite stvarni trošak

Nagodba pretvara normaliziranu upotrebu u konačne unose u glavnu knjigu. Trebao bi biti samo za dodavanje i upućivati na verziju cjenika koja se koristi za zahtjev.

Dogovoreni događaj može izgledati ovako:

{
  "ledger_event_id": "led_01J...",
  "event_type": "settlement",
  "tenant_id": "tenant_123",
  "request_id": "req_789",
  "reservation_id": "res_01J...",
  "provider": "example_provider",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "lines": [
    {
      "billing_class": "input_uncached_tokens",
      "quantity": 1200,
      "unit": "token",
      "unit_price": "0.00000250",
      "amount": "0.003000"
    },
    {
      "billing_class": "input_cached_tokens",
      "quantity": 800,
      "unit": "token",
      "unit_price": "0.00000125",
      "amount": "0.001000"
    },
    {
      "billing_class": "output_tokens",
      "quantity": 650,
      "unit": "token",
      "unit_price": "0.00001000",
      "amount": "0.006500"
    }
  ],
  "total_amount": "0.010500",
  "currency": "USD",
  "status": "settled"
}

Ako je zahtjev rezerviran za 0.032100 i namiren na 0.010500, glavna knjiga vraća 0.021600 natrag na raspoloživi saldo.

Preporuka: nikada ne preračunavajte stare retke fakture iz trenutne tablice cijena. Pohranite nepromjenjive verzije cjenika i priložite ID verzije svakom događaju ponude, rezervacije i namire. U suprotnom, fakturu bi moglo postati nemoguće reproducirati nakon što pružatelj ažurira cijene modela.

Zahtjevi za strujanje: prvo rezervirajte, riješite kasnije

Streaming komplicira naplatu jer korisnik počinje primati izlaz prije nego pristupnik sazna konačnu upotrebu. Odgovor je ne preskočiti provjere prije leta. Gateway bi trebao rezervirati prije otvaranja streama.

Koristite ovaj tijek rada:

1. Procijenite ulazne tokene i maksimalnu izlaznu cijenu.
2. Rezervirajte proračun stanara.
3. Otvorite tok pružatelja usluge.
4. Proslijedite dijelove klijentu.
5. Zabilježite konačnu upotrebu kada je pružatelj pošalje ili kada je dostupan naknadni zapis o upotrebi.
6. Podmirite stvarni trošak i otpustite neiskorištenu rezervaciju.

Ako konačna upotreba nije dostupna, označite poravnanje kao procijenjeno umjesto da se pretvarate da je točno:

"usage_source": "gateway_estimate",
"is_estimated": true,
"reconciliation_status": "pending"

Preporuka: dnevno usklađivanje treba dati prioritet procijenjenim događajima strujanja, neuspjelim zahtjevima, vremenskim ograničenjima i ponovnim pokušajima. Ovo su područja koja će najvjerojatnije stvoriti odstupanja između zapisa pristupnika i faktura dobavljača.

Verzija cjenika i pravila označavanja

Cjenik bi trebao biti verzionirani objekt, a ne promjenjiva proračunska tablica.

Minimalni broj polja:

• pružatelj;
• ID modela;
• naplatna klasa;
• jedinica, kao što je token, zahtjev, slika, zvučna sekunda ili jedinica alata;
• jedinična cijena;
• valuta;
• efektivne vremenske oznake početka i završetka;
• pravila zaokruživanja;
• plan zakupca ili pravilo označavanja partnera;
• referenca izvora i metapodaci odobrenja.

Pravila označavanja trebaju biti eksplicitna. Na primjer:

• Cijena plus: cijena davatelja plus 20%.
• Fiksna maloprodaja: stanar plaća fiksnu cijenu tokena bez obzira na cijenu pružatelja usluga.
• Slojevito: prvo 10 milijuna tokena po jednoj stopi, zatim nižoj stopi.
• Uključeni krediti: upotreba sagorijeva mjesečni iznos prije nego što počne naplata prekoračenja.

Kompromis: verzija cjenika dodaje operativni rad, ali sprječava da sporovi oko faktura postanu arheologija. Agent korisničke podrške trebao bi moći objasniti zašto je zahtjev od 3. kolovoza naplaćen po određenoj tarifi bez provjere današnjih cijena davatelja usluga.

Odvojite knjigu naplate od analitike

Analitika i naplata imaju različite tolerancije. Analitika se može agregirati, odgoditi, uzorkovati ili ispraviti. Naplata mora biti potpuna, idempotentna, provjerljiva i objašnjiva.

Koristite analitiku za pitanja poput:

• Koji timovi koriste najviše žetona?
• Koji modeli najbrže rastu?
• Gdje brzo predmemoriranje može smanjiti troškove?
• Koji ključevi proizvode neobično skupe zahtjeve?

Koristite knjigu naplate za pitanja poput:

• Je li ovaj zahtjev odobren u odnosu na stanje stanara?
• Koja je verzija cjenika proizvela ovo terećenje?
• Je li neiskorištena rezervacija oslobođena?
• Odgovara li faktura kupca utvrđenoj upotrebi?
• Odgovara li upotreba pristupnika upotrebi na strani pružatelja?

Činjenica: OpenTelemetry GenAI semantičke konvencije uključuju atribute upotrebe tokena kao što su ulazni i izlazni tokeni. To je korisno za vidljivost i spajanje tragova s ​​troškovnim događajima. Ali atributi telemetrije nisu zamjena za cjenike, rezervacije, poravnanje, zaokruživanje i stanje fakture.

Dnevni radni tijek usklađivanja

Usklađivanje uspoređuje obračunsku knjigu pristupnika s korištenjem na strani pružatelja usluga. Cilj nije savršen dogovor o svakom međupolju. Cilj je otkriti materijalnu varijaciju dovoljno rano za ispravljanje faktura, cjenika ili adaptera.

Praktičan svakodnevni posao:

1. Grupiraj događaje glavne knjige pristupnika po pružatelju, modelu, zakupcu ili API ključu, klasi naplate i UTC danu.
2. Dohvaćanje upotrebe na strani pružatelja grupirane prema dostupnim dimenzijama, kao što su API ID ključa, model i dan.
3. Normalizirajte izvoze pružatelja putem istog adapterskog koda koji se koristi za odgovore na zahtjeve gdje je to moguće.
4. Usporedite količine i troškove prema obračunskoj klasi.
5. Označite varijancu iznad pragova, kao što je razlika u količini od 0,5% ili bilo koja velika razlika u apsolutnom trošku.
6. Klasificirajte uzroke varijance: procjene strujanja, ponovni pokušaji, neuspjeli zahtjevi, obračun predmemorije, promjene pseudonima modela, odgođeni zapisi pružatelja ili ID-ovi zahtjeva koji nedostaju.
7. Stvorite događaje poravnanja umjesto uređivanja starih događaja poravnanja.

Preporuka: koristite ključeve pružatelja API po stanarima gdje je to operativno izvedivo jer to pojednostavljuje usklađivanje. Ako to stvara prevelike troškove upravljanja ključevima, preslikajte unutarnje ID-ove zakupaca u metapodatke pružatelja usluga gdje su podržani i održavajte pouzdano premošćivanje ID-a zahtjeva.

Reci fakture koje korisnici mogu razumjeti

Faktura upućena korisniku ne bi trebala odražavati dobavljača JSON. Trebalo bi objasniti račun u stabilnim poslovnim uvjetima.

Korisni stupci fakture:

• datumski raspon;
• zakupac, projekt ili API oznaka ključa;
• model ili profil modela;
• broj zahtjeva;
• nekeširani ulazni tokeni;
• predmemorirani ulazni tokeni;
• izlazni tokeni;
• jedinice medija ili alata, ako je primjenjivo;
• popusti, krediti ili marže;
• ukupni iznos i valuta.

Za partnere uključite i veleprodajnu i maloprodajnu cijenu samo ako to zahtijeva poslovni model. Mnoge fakture preprodavača trebale bi prikazivati samo potrošnju u maloprodaji, dok partnerske nadzorne ploče mogu zasebno prikazivati maržu.

Kompromis: objedinjena shema fakture poboljšava čitljivost, ali pojedinosti o naplati specifične za pružatelja još uvijek trebaju izlazne otvore. Neka redovi fakture budu jednostavni prema zadanim postavkama i omogućite izvoz za napredne klijente koji trebaju detaljna polja revizije.

Popis za provjeru implementacije

Prije pokretanja

• Definirajte normalizirane klase naplate za sve podržane pružatelje usluga.
• Stvorite nepromjenjive verzije cjenika s datumima stupanja na snagu.
• Zahtijevaj ograničenja izlaza ili primijeni zadane postavke pristupnika.
• Implementirajte atomske rezervacije s ključevima idempotencije.
• Postavite pravila zaokruživanja za svaku valutu.
• Odlučite kako fakturirati predmemorirane tokene, tokene obrazloženja, medijske jedinice i naknade za zahtjeve.
• Ponovni pokušaji testiranja, isteci vremena, prekidi veze klijenta i pogreške pružatelja usluga.
• Izgradite mehanizam događaja prilagodbe umjesto uređivanja utvrđenih događaja.

Tijekom obrade zahtjeva

• Autentifikacija stanara i ključa.
• Razriješi konačni model nakon pravila usmjeravanja i zamjene.
• Odaberite ispravnu verziju cjenika.
• Navedite trošak u najgorem slučaju.
• Rezervirajte stanje ili odbijte zahtjev.
• ID zahtjeva davatelja zapisa kada je dostupan.
• Normaliziraj upotrebu iz odgovora.
• Podmirenje, otpuštanje neiskorištene rezervacije i emitiranje događaja spremnih za fakture.

Nakon obrade zahtjeva

• Pokreni dnevno usklađivanje po pružatelju, ključu, modelu, klasi naplate i danu.
• Pregledajte procijenjene obračune strujanja.
• Označite korištenje modela s nedostajućim unosima cjenika.
• Nadzirite odstupanje uzrokovano računovodstvom predmemoriranih tokena.
• Generirajte preglede faktura korisnika prije konačne naplate.

Predviđanja za planiranje

Predviđanje: AI API naplata će postati višedimenzionalna, ne manje. Klase tokena, klase predmemorije, medijske jedinice, izvršavanje alata i brojači povezani s obrazloženjem vjerojatno će se nastaviti širiti kako se budu mijenjale mogućnosti modela.

Predviđanje: kupci će očekivati objašnjenja upotrebe na razini zahtjeva, ključa, projekta i fakture. Mjesečni ukupni iznos bez sljedivih stavki retka bit će nedovoljan za timove koji preprodaju API pristup ili nametnu unaprijed plaćene proračune.

Predviđanje: pristupnici koji već odvajaju ponudu, rezervaciju, poravnanje i usklađivanje brže će se prilagoditi novim modelima cijena jer mogu dodati klase naplate bez ponovnog pisanja cijelog sustava faktura.

Poduzimajući zaključak

Ako izložite više pružatelja umjetne inteligencije putem jednog pristupnika, izgradite knjigu naplate prije nego što sporovi oko naplate izazovu problem. Započnite s četiri jamstva:

1. Svaki naplativi zahtjev dobiva predračunsku ponudu.
2. Svaki pretplaćeni ili ograničeni stanar ima rezerviran proračun prije nego započne poziv pružatelja usluga.
3. Svaki odgovor pružatelja normaliziran je u stabilne klase naplate.
4. Svaka se faktura može uskladiti s korištenjem na strani pružatelja usluga i točnom verzijom cjenika koja se koristila u tom trenutku.

Ta kontrolna petlja čini objedinjenu AI API naplatu razumljivom za klijente, provedivom za unaprijed plaćene kredite, fleksibilnom za partnerske marže i podložnom reviziji kada se promijene formati cijena ili upotrebe kod pružatelja usluga.

Povezano čitanje

• pridruživanje LLM praćenja s korištenjem i evidencija troškova
• izgradnja portala prodavača s mjerenjem korištenja stanara
• upotrebom brzog predmemoriranja dok naplata ostaje razumljiva