AI API számlázási főkönyv készítése: minden modellhívás árajánlattétele, lefoglalása, rendezése és egyeztetése

Az ügyfelek felé irányuló AI API számlázás nem lehet a nyers szolgáltatói használat havi exportálása. Ha egy átjáró több modellt tesz elérhetővé a bérlők, csapatok vagy partnerek számára, a számlázásnak egy nehezebb kérdésre kell válaszolnia a számla megjelenése előtt: engedélyezni kell-e ezt a kérést most, és hogyan magyarázzák el később a költségét?

A gyakorlati minta egy számlázási főkönyv, amely négy szakaszból áll: ajánlattétel, tartalékolás, elszámolás és egyeztetés. A kérés előtt adja meg a várható költséget. Foglaljon le elegendő bérlői költségvetést a megengedett legrosszabb eset fedezésére. A használat ismertté válása után rendezze a tényleges költséget. Hasonlítsa össze az átjáró főkönyvét a szolgáltatóoldali rekordokkal, hogy a számlák védhetőek maradjanak.

Ez a cikk egy többmodelles API-átjáró vezérlőhurkát írja le. Hasznos, ha az átjáró számláz a belső csapatoknak, az előre fizetett ügyfeleknek, az ügynökségi ügyfeleknek vagy a későbbi partnereknek.

A számlázási probléma: a szolgáltató használata nem ügyfélszámla

Tény: A nagy mesterségesintelligencia-szolgáltatók nem tesznek közzé egyetlen univerzális tokenszámlálót vagy egy univerzális árat. Az OpenAI modellenkénti árakat tesz közzé külön bemeneti, gyorsítótárazott bemeneti és kimeneti token arányokkal. Az OpenAI-kérdések gyorsítótárazása a gyorsítótárazott token-használatot jelenti az API válaszhasználati mezőjében. Az antropikus dokumentumok külön számlálókat tartalmaznak a normál bemeneti tokenekhez, a gyorsítótár létrehozásához szükséges bemeneti tokenekhez, a gyorsítótár olvasási bemeneti tokenekhez és a kimeneti tokenekhez. A Gemini árazás megkülönbözteti a bemeneti, kimeneti és egyéb token-kategóriákat, beleértve a modalitásspecifikus használatot, például az audio tokeneket.

Ez azt jelenti, hogy egy átjáró nem tud biztonságosan számlázni a total_tokens egy árral való megszorzásával. Szolgáltató-semleges számlázási séma mögött szolgáltató-specifikus adapterekre van szüksége.

A probléma az alábbi helyzetekben válik láthatóbbá:

• Előre fizetett jóváírások: az átjárónak el kell utasítania a kéréseket, mielőtt a bérlő nulla alá költene.
• Partner jelölések: a partnernek saját, ügyfélre szóló számlára van szüksége, nem a szolgáltatói számla másolatára.
• Streamelés: a válasz azelőtt kezdődik, hogy a jogkivonat végső felhasználása ismertté válna.
• Azonnali gyorsítótárazás: a gyorsítótárazott bemenet olcsóbb lehet, mint a nem gyorsítótárazott bemenet, de csak külön mérve.
• Érvelés és eszközhasználat: egyes modellek további használati dimenziókat, rejtett kimeneti osztályokat vagy médiaegységeket jelenítenek meg.
• Szolgáltatói árváltozások: a múlt havi számlának a díjtáblázat módosítása után is reprodukálhatónak kell lennie.

Javaslat: kezelje a számlázást csak hozzáfűzhető pénzügyi főkönyvként, ne pedig a kérésnaplók irányítópult-lekérdezéseként.

Az alapvető architektúra

A megbízható számlázási architektúra hat összetevőből áll:

1. Bérlői fiók: ügyfél, munkaterület, viszonteladói ügyfél vagy belső költséghely.
2. Díjtábla szolgáltatás: verziószámú árak a szolgáltatóhoz, modellhez, számlázási osztályhoz, pénznemhez és jelölési szabályhoz.
3. Becslő: kiszámítja a vizsgálat előtti árajánlatot a kérés paramétereiből és a modellszabályzatból.
4. Foglalási főkönyv: a költségvetést a szolgáltatói hívás megkezdése előtt tartja.
5. Használatnormalizáló: a szolgáltató-specifikus használati mezőket belső számlázási egységekké alakítja.
6. Elszámolási és egyeztetési feladatok: véglegesítse a díjakat, és hasonlítsa össze őket a szolgáltató oldali nyilvántartásaival.

A vezérlés folyamata így néz ki:

ügyfél kérése
  -> hitelesítse a bérlőt és a kulcsot
  -> válassza ki a modellt és a díjtáblázat verzióját
  -> becsülje meg a bemeneti és a maximális kimeneti költséget
  -> tartalék bérlői egyenleg
  -> hívja a szolgáltatót
  -> normalizálja a visszaadott használatot
  -> a tényleges költség rendezése
  -> a fel nem használt foglalás feloldása
  -> számlakész főkönyvi esemény kiadása

A tervezés fontos döntése az, hogy a kérést ne csupán figyelembe vegyék. A végrehajtás előtt és után pénzügyileg ellenőrzik.

1. lépés: árajánlat a szolgáltató hívása előtt

Az előzetes árajánlatnak elég pesszimistának kell lennie ahhoz, hogy érvényesítse a költségvetést, de elég magyarázhatónak kell lennie ahhoz, hogy megmutassa az ügyfeleknek vagy partnereknek.

A bemenetek általában a következőket tartalmazzák:

• bérlőazonosító és számlázási terv;
• API-kulcs-azonosító vagy projektazonosító;
• szolgáltató és modellazonosító az útválasztási szabályok alkalmazása után;
• becsült gyorsítótárazott beviteli tokenek;
• ismert, gyorsítótárazott beviteli jogosultság, ha elérhető;
• max_tokens, max_output_tokens vagy ezzel egyenértékű kimeneti korlát;
• eszköz, kép, hang vagy egyéb modalitási paraméterek;
• partneri jelölés, kedvezmény vagy viszonteladói árszabály;
• pénznem és kerekítési szabályzat.

Egy egyszerű idézetképlet a szöveg létrehozásához a következő lehet:

becsült_költség =
  becsült_uncached_input_tokens * input_rate
+ becsült_gyorsítótárazott_bemeneti_tokenek * cached_input_rate
+ max_output_tokens * output_rate+ kérés_díj
+ partner_markup

Javaslat: ha a kimenet végső hossza ismeretlen, tartalékoljon a konfigurált maximális kimenettel szemben. Ha az alkalmazás korlátlanul hagyja a kimeneti korlátot, az átjárónak bérlői vagy modell-alapértelmezést kell alkalmaznia. A költségvetés végrehajtása nem lehet determinisztikus, ha nincs maximális felelősség.

Ez elutasíthat néhány olyan kérést, amelyek a gyakorlatban olcsók lettek volna. Ez a kompromisszum. Az előre fizetett rendszerek esetében a biztonságosabb alapértelmezés a pesszimista foglalás az elszámolás után fel nem használt pénzeszközökkel. Számlázott vállalati ügyfelek számára a csapatok engedélyezhetik a lágy túllépéseket, és az árajánlatot elsősorban figyelmeztetésekre használják.

2. lépés: tartalék bérlői költségkeret

A foglalás megvédi a bérlői fiókot attól, hogy a megengedett egyenlegnél többet költsön. Alaposnak kell lennie: vagy a foglalás sikeres, és elindulhat a szolgáltatói hívás, vagy a kérést a rendszer elutasítja, mielőtt bármilyen szolgáltatói költség felmerülne.

A foglalási rekord a következőket tartalmazhatja:

{
  "reservation_id": "res_01J...",
  "bérlő_azonosítója": "bérlő_123",
  "api_key_id": "key_456",
  "request_id": "req_789",
  "provider": "example_provider",
  "modell": "modell-a",
  "rate_card_version": "2026-08-01",
  "quoted_amount": "0,032100",
  "currency": "USD",
  "status": "fenntartott",
  "expires_at": "2026-08-11T12:05:00Z"
}

Használjon rövid foglalási lejáratokat a hálózati meghibásodások és az ügyfélkapcsolat megszakadása esetén. A tisztítási munkának fel kell szabadítania azokat a lejárt foglalásokat, amelyek soha nem értek el rendezést. Azonban ne engedje fel a foglalást egyszerűen azért, mert az ügyfél megszakadt; a szolgáltatói hívás továbbra is befejeződhet, és költségekkel járhat. A szolgáltató kérésének állapotát külön nyomon követheti.

Javaslat: tegye a foglalást idempotenssé kérésazonosítóval vagy idempotenciakulccsal. Az ügyfelektől, átjáróktól vagy dolgozóktól érkező újrapróbálkozások nem hozhatnak létre több költségkeret-visszatartást ugyanahhoz a logikai kéréshez.

3. lépés: normalizálja a szolgáltató használatát

A szolgáltató válaszait kis belső sémává kell alakítani. Tartsa stabilan akkor is, ha a szolgáltatók új használati mezőket adnak hozzá.

Egy gyakorlati normalizált használati séma:

{
  "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": hamis
}

Ez a séma szándékosan nem azonos egyetlen szolgáltató válaszával sem. Rögzíti a számlázási dimenziókat, amelyekre a számláknak szükségük van, miközben megőrzi a szolgáltató-specifikus egységek biztonsági nyílásait.

A gyorsítótárazott tokeneknek saját sorra van szükségük

Tény: Az azonnali gyorsítótárazás ára eltérő lehet, mint a gyorsítótárazott bemenet. Ha a gyorsítótárazott tokeneket a teljes bemeneti jogkivonatokkal egyesítik, előfordulhat, hogy az ügyfélnek túldíjat kell fizetnie, vagy az átjáró alábecsülheti a szolgáltató költségeit. A gyorsítótárazott bemenetnek saját számlázási osztályaként kell megjelennie a főkönyvben és a számlában is.

A gyorsítótár írása és olvasása nem mindig ugyanaz

Egyes szolgáltatók különbséget tesznek a gyorsítótár-bejegyzések létrehozása és a gyorsítótárból történő olvasás között. A normalizáló nem feltételezheti, hogy a gyorsítótárazott bemenet mindig egy számlázási díjat jelent. Ha egy szolgáltató rendelkezik gyorsítótár-írási és gyorsítótár-olvasási jogkivonatokkal, külön rendelje hozzá őket, vagy őrizze meg őket szolgáltató-specifikus alegységként.

Az érveléshez és a rejtett kimenethez házirendre van szükség

Egyes modellek érveléssel kapcsolatos használatot vagy rejtett kimeneti számlálókat tesznek közzé. Ha a szolgáltató számláz ezekért az egységekért, az átjárónak el kell döntenie, hogy közvetlenül megjeleníti-e őket, vagy egy kimeneti kategóriába sorolja őket, vagy külön számlasorként sorolja fel őket.

Javaslat: az ügyfeleknek szóló számlákon egyszerű nyelvezetet kell használni. Például: a „reasoning output tokens” egyértelműbb, mint a nyers szolgáltató mező neve. Tartsa elérhetővé a nyers mezőket az ellenőrzéshez, de ne kényszerítsen minden ügyfelet arra, hogy megértse a szolgáltató belső tulajdonságait.

4. lépés: rendezze a tényleges költséget

Az elszámolás a normalizált használatot végső főkönyvi bejegyzésekké alakítja. Csak hozzá kell csatolni, és hivatkoznia kell a kéréshez használt díjtáblázat-verzióra.

Egy rendezett esemény így nézhet ki:

{
  "ledger_event_id": "led_01J...",
  "event_type": "elszámolás",
  "bérlő_azonosítója": "bérlő_123",
  "request_id": "req_789",
  "reservation_id": "res_01J...",
  "provider": "example_provider",
  "modell": "modell-a",
  "rate_card_version": "2026-08-01",
  "sorok": [
    {
      "billing_class": "input_uncached_tokens",
      "mennyiség": 1200,
      "egység": "token",
      "unit_price": "0,00000250",
      "összeg": "0,003000"
    },
    {
      "billing_class": "input_cached_tokens",
      "mennyiség": 800,
      "egység": "token",
      "unit_price": "0,00000125",
      "összeg": "0,001000"
    },
    {
      "billing_class": "output_tokens",
      "mennyiség": 650,
      "egység": "token","unit_price": "0,00001000",
      "összeg": "0,006500"
    }
  ],
  "total_amount": "0,010500",
  "currency": "USD",
  "státusz": "letelepedett"
}

Ha a kérés a 0,032100 számra volt lefoglalva, és a kiegyenlítés a 0,010500 értékre vonatkozik, a főkönyv a 0,021600 összeget visszaengedi a rendelkezésre álló egyenleghez.

Javaslat: soha ne számolja újra a régi számlasorokat az aktuális ártáblázatból. Tárolja változatlan díjtáblázat-verziókat, és csatolja a verzióazonosítót minden árajánlathoz, foglaláshoz és elszámolási eseményhez. Ellenkező esetben lehetetlenné válhat a számla reprodukálása, miután a szolgáltató frissíti a modellárakat.

Streamelési kérések: először foglaljon, később rendezzen

A streamelés bonyolítja a számlázást, mivel a felhasználó azelőtt kezdi megkapni a kimenetet, hogy az átjáró megismerné a végső felhasználást. A válasz az, hogy ne hagyja ki a repülés előtti ellenőrzéseket. Az átjárónak le kell foglalnia az adatfolyam megnyitása előtt.

Használja ezt a munkafolyamatot:

1. A bemeneti tokenek és a maximális kimeneti költség becslése.
2. Bérlői költségkeret lefoglalása.
3. Nyissa meg a szolgáltatói adatfolyamot.
4. Továbbítsa a darabokat az ügyfélnek.
5. Rögzítse a végső felhasználást, amikor a szolgáltató elküldi, vagy amikor rendelkezésre áll egy nyomon követési használati rekord.
6. Rendszerezze a tényleges költséget, és engedje fel a fel nem használt foglalást.

Ha a végső felhasználás nem érhető el, jelölje meg a települést becsültként, ahelyett, hogy pontosnak tenné:

"usage_source": "gateway_estimate",
"is_estimated": igaz,
"reconciliation_status": "függőben"

Javaslat: A napi egyeztetés során előnyben kell részesíteni a becsült streamelési eseményeket, a sikertelen kéréseket, az időtúllépéseket és az újrapróbálkozásokat. Ezek azok a területek, amelyek nagy valószínűséggel eltérést okoznak az átjárórekordok és a szolgáltatói számlák között.

Díjtáblázat verziószámítási és jelölési szabályok

A díjtáblázatnak verziószámmal ellátott objektumnak kell lennie, nem pedig változtatható táblázatnak.

Minimális mezők:

• szolgáltató;
• modellazonosító;
• számlázási osztály;
• egység, például token, kérés, kép, hangmásodperc vagy eszközegység;
• egységár;
• pénznem;
• hatékony kezdési és befejezési időbélyegek;
• kerekítési szabályzat;
• bérlői terv vagy partnerjelölési szabály;
• forráshivatkozási és jóváhagyási metaadatok.

A jelölési szabályoknak egyértelműnek kell lenniük. Például:

• Költség plusz: szolgáltatói költség plusz 20%.
• Rögzített kiskereskedelmi: a bérlő fix token árat fizet, függetlenül a szolgáltató árától.
• Részletes: először 10 millió token egy árfolyamon, majd alacsonyabb áron.
• Bellékelt jóváírások: a használat leégeti a havi juttatást, mielőtt elkezdődik a többletszámlázás.

Kiváltás: A díjtáblázat-verziók növelik az operatív munkát, de megakadályozzák, hogy a számlákkal kapcsolatos viták régészetté váljanak. Az ügyfélszolgálati ügynöknek meg kell tudnia magyarázni, hogy egy augusztus 3-i kérést miért számláztak ki meghatározott áron anélkül, hogy ellenőrizné a szolgáltató mai árait.

Válassza el a számlázási főkönyvet az elemzéstől

Az Analytics és a számlázás eltérő tűrésekkel rendelkezik. Az elemzések összesíthetők, késleltethetők, mintavételezhetők vagy javíthatók. A számlázásnak teljesnek, hatékonynak, ellenőrizhetőnek és megmagyarázhatónak kell lennie.

Használja az elemzést az alábbi kérdésekhez:

• Mely csapatok használják a legtöbb tokent?
• Mely modellek nőnek a leggyorsabban?
• Hol csökkentheti a költségeket az azonnali gyorsítótárazás?
• Mely kulcsok hoznak létre szokatlanul drága kéréseket?

Használja a számlázási főkönyvet az alábbi kérdésekhez:

• Engedélyezték ezt a kérést a bérlő egyenlegével szemben?
• Melyik díjtáblázat-verzió hozta létre ezt a terhelést?
• Feloldották a fel nem használt foglalást?
• Az ügyfélszámla megegyezik a kiegyenlített használattal?
• Az átjáróhasználat megegyezik a szolgáltató oldali használattal?

Tény: Az OpenTelemetry GenAI szemantikai konvenciói tartalmazzák a token használati attribútumokat, például a bemeneti és kimeneti tokenek. Ez hasznos a megfigyelhetőség és a nyomok összekapcsolása a költséges eseményekkel. A telemetriai attribútumok azonban nem helyettesítik a díjtáblázatokat, a foglalásokat, az elszámolást, a kerekítést és a számla állapotát.

Napi egyeztetési munkafolyamat

Az egyeztetés összehasonlítja az átjáró rendezett főkönyvét a szolgáltató oldali használattal. A cél nem a tökéletes megegyezés minden köztes területen. A cél az anyagi eltérések elég korai észlelése a számlák, díjtáblázatok vagy adapterek javításához.

Gyakorlati napi munka:

1. Csoportozza az átjáró főkönyvi eseményeit szolgáltató, modell, bérlő vagy API-kulcs, számlázási osztály és UTC-nap szerint.
2. Szállítóoldali használat lekérése elérhető dimenziók, például API kulcsazonosító, modell és nap szerint csoportosítva.
3. Ha lehetséges, normalizálja a szolgáltatói exportálást ugyanazon az illesztőkódon keresztül, amelyet a kérések válaszaihoz használnak.
4. Hasonlítsa össze a mennyiségeket és a költségeket számlázási osztályok szerint.
5. A küszöbértékek feletti eltérések megjelölése, például 0,5%-os mennyiségi különbség vagy bármilyen nagy abszolút költségkülönbség.
6. Osztályozza az eltérések okait: adatfolyam-becslések, újrapróbálkozások, sikertelen kérések, gyorsítótár-elszámolás, modellálnevek változásai, késleltetett szolgáltatói rekordok vagy hiányzó kérésazonosítók.
7. A régi elszámolási események szerkesztése helyett korrekciós eseményeket hozhat létre.

Javaslat: Használjon bérlőnként szolgáltatói API-kulcsokat, ahol ez működésileg megvalósítható, mert leegyszerűsíti az egyeztetést. Ha ez túl sok kulcskezelési többletköltséget okoz, rendelje hozzá a belső bérlői azonosítókat a szolgáltatói metaadatokhoz, ahol ez támogatott, és tartson fenn egy megbízható kérésazonosító hidat.

Az ügyfelek számára érthető számlasorok

Az ügyfélnek szóló számlák nem tükrözhetik a szolgáltató JSON-ját. A számlát stabil üzleti feltételekkel kell magyaráznia.

Hasznos számla oszlopok:

• dátumtartomány;
• bérlő-, projekt- vagy API-kulcscímke;
• modell vagy modellprofil;
• kérelmek száma;
• gyorsítótárazott beviteli tokenek;
• gyorsítótárazott beviteli tokenek;
• kimeneti tokenek;
• adathordozó- vagy eszközegységek, ha vannak;
• kedvezmények, jóváírások vagy felárak;
• teljes összeg és pénznem.

Partnerek esetében csak akkor tüntesse fel a nagykereskedelmi árat és a kiskereskedelmi árat is, ha az üzleti modell ezt megköveteli. Sok viszonteladói számlán csak a kiskereskedelmi felhasználást kell feltüntetni, míg a partnerek irányítópultjain az árrés külön jelenhet meg.

Kiegyenlítés: az egységes számlaséma javítja az olvashatóságot, de a szolgáltató-specifikus számlázási részleteket továbbra is ki kell emelni. Alapértelmezés szerint tartsa egyszerűvé a számlasorokat, és biztosítson exportálást a haladó ügyfelek számára, akiknek részletes ellenőrzési mezőkre van szükségük.

Megvalósítási ellenőrzőlista

Indítás előtt

• Határozzon meg normalizált számlázási osztályokat az összes támogatott szolgáltatóhoz.
• Módosíthatatlan díjtáblázat-verziók létrehozása hatálybalépési dátumokkal.
• Kimeneti korlátokat ír elő, vagy alkalmazza az átjáró alapértelmezett beállításait.
• Idempotency kulcsokkal valósítsa meg az atomfoglalásokat.
• Állítson be kerekítési szabályokat az egyes pénznemekhez.
• Döntse el, hogyan számlázza ki a gyorsítótárazott tokeneket, érvelési tokeneket, médiaegységeket, és kérjen díjakat.
• Tesztelési újrapróbálkozások, időtúllépések, kliens leválasztások és szolgáltatói hibák.
• A rendezett események szerkesztése helyett hozzon létre egy korrekciós-esemény mechanizmust.

Kéréskezelés során

• A bérlő és a kulcs hitelesítése.
• A végső modell megoldása az útválasztás és a tartalék házirend után.
• Válassza ki a megfelelő díjtáblázat-verziót.
• Írjon a legrosszabb költségre.
• Tegyen le egyenleget, vagy utasítsa el a kérést.
• Ha rendelkezésre áll, rögzítse a szolgáltatói kérelem azonosítóját.
• A használat normalizálása a válaszból.
• Egyezze meg, engedje fel a fel nem használt foglalást, és küldjön ki számlakész eseményeket.

Kéréskezelés után

• Futtassa a napi egyeztetést szolgáltató, kulcs, modell, számlázási osztály és nap szerint.
• Tekintse át a becsült adatfolyam-elszámolásokat.
• A modellhasználat megjelölése hiányzó díjtáblázat-bejegyzésekkel.
• A gyorsítótárazott token elszámolás által okozott eltérések figyelése.
• Generál vevői számlák előnézetét a végső számlázás előtt.

A tervezett előrejelzések

Előrejelzés: Az AI API számlázása nem kevésbé, hanem többdimenziós lesz. A token osztályok, a gyorsítótár osztályok, a médiaegységek, az eszközvégrehajtás és az érveléssel kapcsolatos számlálók valószínűleg folyamatosan bővülnek a modell képességeinek változásával.

Előrejelzés: az ügyfelek a kérés, a kulcs, a projekt és a számla szintjén várják a használati magyarázatot. A nyomon követhető sorok nélküli havi végösszeg nem lesz elegendő az API-hozzáférést viszonteladó vagy előre kifizetett költségkeretet érvényesítő csapatok számára.

Előrejelzés: Azok az átjárók, amelyek már különválasztják az árajánlatot, foglalást, elszámolást és egyeztetést, gyorsabban alkalmazkodnak az új árképzési modellekhez, mivel a teljes számlarendszer átírása nélkül adhatnak hozzá számlázási osztályokat.

Intézhető következtetés

Ha több mesterségesintelligencia-szolgáltatót tesz közzé egy átjárón keresztül, készítse el a számlázási főkönyvet, mielőtt a számlázási viták kikényszerítenék a problémát. Kezdje négy garanciával:

1. Minden számlázható kérelemre előzetes árajánlatot kap.
2. Minden előre fizetett vagy korlátozott bérlőnek van lefoglalva költségkerete a szolgáltatói hívás megkezdése előtt.
3. Minden szolgáltatói válasz stabil számlázási osztályokba normalizálódik.
4. Minden számla egyeztethető a szolgáltatói használattal és az aktuális díjtáblázat-verzióval.

Ez a vezérlőhurok érthetővé teszi az egyesített AI API számlázást az ügyfelek számára, végrehajthatóvá az előre fizetett jóváírások esetében, rugalmassá teszi a partnerek felárakat, és ellenőrizhetővé teszi, ha a szolgáltatói árképzés vagy a használati formátum megváltozik.

Kapcsolódó olvasmány

• csatlakozás az LLM nyomkövetéséhez használati és költségrekordokkal
• viszonteladói portálok építése bérlői használat méréssel
• az azonnali gyorsítótár használata, miközben a számlázás érthető marad