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

Naplata AI API-ja okrenuta korisniku 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 dopustiti upravo sada i kako će njegov trošak biti objašnjen kasnije?

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 promptno predmemoriranje izvještava o korištenju predmemoriranog tokena u polju upotrebe odgovora API-ja. Antropički dokumenti odvajaju brojače za normalne ulazne tokene, ulazne tokene za stvaranje predmemorije, ulazne tokene za čitanje 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 usluge.
• 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 upotreba 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 započne poziv davatelju usluge.
5. Normalizator upotrebe: pretvara polja upotrebe specifična za pružatelja usluga u interne obračunske jedinice.
6. Poslovi nagodbe i usklađivanja: finalizirajte troškove i usporedite ih sa evidencijom na strani pružatelja usluga.

Kontrolni tok izgleda ovako:

zahtjev klijenta
  -> provjera autentičnosti stanara i ključa
  -> odaberite model i verziju cjenika
  -> procjena ulaznih i maksimalnih izlaznih troškova
  -> rezervni saldo stanara
  -> davatelj usluga poziva
  -> normalizirati ponovnu upotrebu
  -> podmiriti stvarni trošak
  -> oslobodi neiskorištenu rezervaciju
  -> emitiraj događaj knjige spreman za račun

Važan izbor dizajna je da se zahtjev ne promatra samo. Financijski se kontrolira 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;
• ID ključa API-ja ili ID projekta;
• pružatelj i ID modela nakon primjene pravila usmjeravanja;
• procijenjeni nekaširani ulazni tokeni;
• poznata podobnost za predmemorirani unos, ako je dostupna;
• max_tokens, max_output_tokens ili ekvivalentno izlazno ograničenje;
• parametri alata, slike, zvuka ili drugih modaliteta;
• partnerska marža, popust ili pravilo cijena prodavača;
• politika valute i zaokruživanja.

Jednostavna formula citata za generiranje teksta može biti:

procijenjeni_trošak =
  procijenjeni_necaširani_input_tokeni * input_rate
+ procijenjeni_predmemorirani_input_tokeni * predmemorirani_ulazni_stopa
+ max_output_tokens * output_rate+ naknada za zahtjev
+ 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 meka 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 stanja. Trebao bi biti atomičan: ili rezervacija uspijeva 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...",
  "stanar_id": "stanar_123",
  "api_key_id": "ključ_456",
  "request_id": "req_789",
  "provider": "example_provider",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "citirani_iznos": "0,032100",
  "currency": "USD",
  "status": "rezervirano",
  "expires_at": "2026-08-11T12:05:00Z"
}

Koristite kratke isteke rezervacija 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. Odvojeno stanje zahtjeva davatelja usluga.

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.

Korak 3: normalizirajte upotrebu pružatelja usluga

Odgovori davatelja usluga trebali bi 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,
  "alat_ili_medijske_jedinice": [],
  "request_fee_units": 1,
  "provider_request_id": "prov_abc",
  "usage_source": "provider_response",
  "is_estimated": netočno
}

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

Predmemorirani tokeni trebaju vlastitu liniju

Č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 ista

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 politiku

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, prebaciti ih u izlaznu kategoriju ili ih navesti kao zasebnu liniju fakture.

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

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 korištenu za zahtjev.

Dogovoreni događaj može izgledati ovako:

{
  "ledger_event_id": "led_01J...",
  "event_type": "naselje",
  "stanar_id": "stanar_123",
  "request_id": "req_789",
  "reservation_id": "res_01J...",
  "provider": "example_provider",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "linije": [
    {
      "billing_class": "input_uncached_tokens",
      "količina": 1200,
      "jedinica": "žeton",
      "jedinična_cijena": "0,00000250",
      "iznos": "0,003000"
    },
    {
      "billing_class": "input_cached_tokens",
      "količina": 800,
      "jedinica": "žeton",
      "jedinična_cijena": "0,00000125",
      "iznos": "0,001000"
    },
    {
      "klasa_naplate": "izlazni_tokeni",
      "količina": 650,
      "jedinica": "žeton","jedinična_cijena": "0,00001000",
      "iznos": "0,006500"
    }
  ],
  "ukupni_iznos": "0,010500",
  "currency": "USD",
  "status": "naseljen"
}

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 svakoj ponudi, rezervaciji i događaju 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": točno,
"status_usklađivanja": "na čekanju"

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, audio sekunda ili jedinica alata;
• jedinična cijena;
• valuta;
• efektivne vremenske oznake početka i završetka;
• politika zaokruživanja;
• plan zakupca ili pravilo označavanja partnera;
• referenca izvora i metapodaci o odobrenju.

Pravila označavanja trebaju biti eksplicitna. Na primjer:

• Cost plus: trošak pružatelja plus 20%.
• Fiksna maloprodaja: zakupac plaća fiksnu cijenu tokena bez obzira na cijenu pružatelja.
• Slojno: prvo 10 milijuna tokena po jednoj stopi, zatim nižoj stopi.
• Uključeni krediti: korištenje 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 korisnika podmirenoj 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 prema 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 ID ključa API-ja, model i dan.
3. Normalizirajte izvoze pružatelja putem istog koda adaptera 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 usluga ili ID-ovi zahtjeva koji nedostaju.
7. Stvorite događaje poravnanja umjesto uređivanja starih događaja poravnanja.

Preporuka: koristite ključeve API-ja pružatelja po stanarima gdje je to operativno izvedivo jer to pojednostavljuje usklađivanje. Ako to stvara prevelike troškove upravljanja ključevima, preslikajte interne ID-ove stanara na metapodatke pružatelja usluga gdje su podržani i održavajte pouzdani most za ID zahtjeva.

Reci računa koji korisnici mogu razumjeti

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

Korisni stupci fakture:

• datumski raspon;
• oznaka ključa stanara, projekta ili API-ja;
• model ili profil modela;
• broj zahtjeva;
• nekeširani ulazni tokeni;
• spremljeni 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 cijenu i maloprodajnu cijenu samo ako to zahtijeva poslovni model. Mnoge fakture preprodavača trebale bi prikazivati samo potrošnju u maloprodaji, dok nadzorne ploče partnera mogu odvojeno prikazivati maržu.

Kompromis: objedinjena shema fakture poboljšava čitljivost, ali detalji o naplati specifični 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.
• Izradite mehanizam prilagodbe događaja umjesto uređivanja dogovorenih događaja.

Tijekom obrade zahtjeva

• Provjerite autentičnost stanara i ključa.
• Razriješite konačni model nakon politike usmjeravanja i zamjene.
• Odaberite ispravnu verziju cjenika.
• Navedite trošak u najgorem slučaju.
• Rezervirajte stanje ili odbijte zahtjev.
• Zabilježi 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

• Pokrenite dnevno usklađivanje prema 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 za klijente prije konačne naplate.

Predviđanja za planiranje

Predviđanje: AI API naplata postat će 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: korisnici ć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 provode 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.

Zaključak koji se može poduzeti

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 zakupac ima rezerviran proračun prije nego započne poziv pružatelja.
3. Svaki odgovor pružatelja normaliziran je u stabilne klase naplate.
4. Svaka faktura može se uskladiti s korištenjem na strani pružatelja usluge i točnom verzijom cjenika koja se koristila u tom trenutku.

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

Povezano čitanje

• pridruživanje praćenja LLM-a s evidencijom korištenja i troškova
• izrada portala za preprodavače s mjerenjem upotrebe zakupca
• upotreba brzog predmemoriranja dok naplata ostaje razumljiva