Računovodstvo strujanja tokena u pristupniku AI API-ja: konačna upotreba, otkazivanja i djelomični odgovori

Streaming LLM odgovore lako je proxy, a teško ih je ispravno naplatiti. Ako AI API pristupnik proslijedi događaje poslane s poslužitelja klijentu, ali tretira prve dijelove kao zapis o korištenju, analitika stanara će se povući. Odstupanje se obično pojavljuje u sporovima kao što su: "korisnik je vidio samo pola odgovora", "pružatelj je naplatio više nego što pokazuje naša nadzorna ploča", "kvota je prerano puštena" ili "vrijeme čekanja proizvelo je tokene, ali nema reda fakture."

Osnovni problem je u tome što strujani pozivi nisu jedan događaj. Oni su slijed: zahtjev prihvaćen, uzvodni tok otvoren, bajtovi isporučeni, konačna upotreba prijavljena, pružatelj zaustavljen, klijent prekinut, pristupnik je istekao i naplata je podmirena. Pouzdan pristupnik trebao bi eksplicitno modelirati ta stanja umjesto da pretpostavlja da je dovršeni HTTP odgovor jedini uspješan put.

Način neuspjeha: strujanje skriva granicu obračuna

Dovršavanja bez strujanja obično vraćaju jedan objekt odgovora s metapodacima o upotrebi. Gateway može normalizirati tu upotrebu, napisati red glavne knjige, ažurirati kvotu i emitirati analitiku u jednom prolazu.

Streaming mijenja granicu. Korisničko iskustvo je inkrementalno, ali istina o naplati može stići na kraju, u konačnom događaju specifičnom za pružatelja usluga, u kumulativnoj delti, kroz agregirani SDK odgovor ili kasnije putem API-ja za izvješćivanje pružatelja. Ako klijent prekine vezu prije posljednjeg događaja korištenja, pristupnik je možda isporučio samo dio odgovora dok je pružatelj još uvijek generirao i naplatio više tokena.

Činjenica: OpenAI dokumentira da pozivatelji strujanja koji žele podatke o upotrebi trebaju postaviti stream_options s include_usage. OpenAI također pruža krajnje točke upotrebe i troškova na razini organizacije, uz napomenu da upotreba i troškovi možda neće uvijek biti savršeno usklađeni u financijske svrhe.

Činjenica: Anthropic streaming koristi događaje poslane s poslužitelja kao što su message_start, content_block_delta, message_delta i message_stop. Njegove informacije o korištenju message_delta su kumulativne, tako da gateway ne smije dodati svaku deltu korištenja zajedno.

Činjenica: API-ji za strujanje u stilu Gemini i Vertex mogu izložiti inkrementalne dijelove dok SDK-ovi također mogu pružiti agregirani objekt odgovora. Za pristupnike taj agregirani put može biti bolji izvor za dovršenu upotrebu od samih vidljivih dijelova.

Koristite stroj stanja toka, a ne Booleovu oznaku uspjeha

Streaming zahtjev trebao bi imati trajnu evidenciju korištenja prije nego što započne uzlazni poziv. Taj bi se zapis trebao kretati kroz eksplicitna stanja. Praktični minimum je:

• prihvaćeno: pristupnik je potvrdio autentičnost ključa, dodijelio stanara i stvorio otvoreni red glavne knjige.
• first_byte_sent: najmanje jedan izlazni događaj dosegao je nizvodni klijent.
• provider_completed: uzvodni pružatelj emitirao je normalan signal za zaustavljanje ili objekt završenog odgovora.
• client_aborted: nizvodna utičnica zatvorena prije normalnog završetka pristupnika.
• provider_error: uzlazni pružatelj vratio je pogrešku nakon početka prijenosa ili prije nego što je stigla konačna upotreba.
• gateway_timeout: pristupnik je nametnuo svoj proračun latencije i završio zahtjev.
• podmireno: pristupnik je pretvorio upotrebu u trošak stanara i potrošnju kvote.
• usklađeno: kasniji podaci o korištenju ili troškovima davatelja usluga potvrdili su ili prilagodili red.

Ovaj model sprječava uobičajenu pogrešku analitike: označavanje svakog toka koji je proizveo tekst kao "uspješan i točan". Stream može biti koristan korisniku, nedovršen od davatelja usluga, procijenjen za naplatu i u isto vrijeme čeka usklađivanje.

Preporučena polja knjige

Neka redak vremena zahtjeva bude mali, ali eksplicitan:

{
  "request_id": "gw_req_...",
  "stanar_id": "stanar_123",
  "api_key_id": "ključ_456",
  "provider": "otvoren|antropski|gemini|...",
  "provider_request_id": null,
  "model": "id-modela-davatelja",
  "stanje": "prihvaćeno",
  "stream": točno,
  "input_tokens": null,
  "output_tokens_billed": null,
  "output_tokens_delivered_estimate": 0,
  "provider_usage_source": null,
  "billing_status": "čeka_usklađivanje",
  "client_abort_at": null,
  "provider_completed_at": null,
  "settled_at": nula,
  "class_error": null
}

Važno razdvajanje je output_tokens_billed u odnosu na output_tokens_delivered_estimate. Korisnicima je bitno što je stiglo do njihove aplikacije. Financije brinu što je pružatelj naplatio. Ti se brojevi mogu razlikovati nakon prekida veze, streamova poziva alata, skrivenih tokena obrazloženja, tokena u predmemoriji, sigurnosnih zaustavljanja ili isteka vremena pristupnika.

Pravila snimanja specifična za pružatelja usluga

API kompatibilan s OpenAI-om koji je neutralan prema pružatelju usluga, koristan je za programere aplikacija, ali adapter pristupnika i dalje treba računovodstvena pravila specifična za pružatelja usluga.

Streaming kompatibilan s OpenAI

Za OpenAI rute, izložite opciju pristupnika koja omogućuje prijavu upotrebe uzvodno tamo gdje je to podržano. Uobičajeni obrazac je prihvaćanje zadane postavke na razini pristupnika kao što je:

{
  "stream": točno,
  "opcije_streama": {
    "include_usage": točno
  }
}

Ako ga nizvodni pozivatelj izostavi, pristupnik može odlučiti hoće li ga ubaciti za rute gdje je to kompatibilno. Dokumentirajte ovo ponašanje jer neki klijenti očekuju točnu kompatibilnost žice, a neki modeli ili uzvodni kanali možda neće podržavati konačnu upotrebu na isti način.

Preporuka: nemojte podmirivati troškove stanara iz ranih dijelova. Držite red knjige otvorenim sve dok se ne uhvati posljednji događaj upotrebe, odgovor pružatelja ne završi bez upotrebe ili dok tok ne uđe u pogrešku ili stazu otkazivanja.

Antropsko strujanje

Kumulativna upotreba Anthropica zahtijeva drugačije pravilo. Ako pristupnik vidi tri događaja message_delta s brojem izlaznih tokena 10, 25 i 40, izlazni broj je 40, a ne 75.

neka latestUsage = null;
za čekanje (const događaj anthropicStream) {
  if (event.type === "message_delta" && event.usage) {
    if (latestUsage && event.usage.output_tokens < latestUsage.output_tokens) {
      emit("cumulative_usage_regressed", requestId);
    }
    najnovijaUsage = event.usage;
  }
  proslijediKlijentu(događaj);
}
settleFromLatestCumulativeUsage(latestUsage);

Preporuka: zabilježite posljednju kumulativnu vrijednost upotrebe i emitirajte događaj vidljivosti ako se smanji. Regresija može ukazivati na pogreške parsera, duplicirane događaje, promjene pružatelja usluga ili miješane tokove.

Streaming u stilu Gemini i Vertex

Gemini podržava strujanje dijelova kako bi se smanjila percipirana latencija. U SDK-ovima u stilu Vertexa strujanje može izložiti i asinkroni tok i agregirani objekt odgovora. Gateway bi trebao sačuvati taj skupni put kada je dostupan.

const streamingResult = čekaj model.generateContentStream(request);
za čekanje (const chunk of streamingResult.stream) {
  naprijedČunk(komad);
  countDeliveredBytesOrText(chunk);
}
const aggregated = čekaj streamingResult.response;
settleFromAggregatedUsage(agregirano);

Preporuka: izbjegavajte izgradnju cjelokupnog računovodstva od vidljivih dijelova ako SDK daje dovršeni zapis odgovora. Dijelovi su za kašnjenje. Konačni objekt često je bolji za naplatu i analitiku.

Prekid veze s klijentom tretirajte kao prvorazredne računovodstvene događaje

Klijentovi prekidi veze su mjesta gdje mnogi pristupnici gube novac ili preplaćuju klijente. Kartica preglednika se zatvara, mobilna mreža pada ili aplikacija poništava zahtjev. Gateway primjećuje da je nizvodna utičnica zatvorena, ali uzlazni pružatelj možda još uvijek generira.

Gateway bi trebao napraviti izričit izbor pravila:

• Odmah poništi uzvodno: smanjuje uzaludnu proizvodnju i troškove pružatelja usluga, ali može prekinuti tijekove rada gdje pozadina i dalje treba rezultat nakon prekida veze korisničkog sučelja.
• Nastavak uzvodno u pozadini: može sačuvati posao za korisnike na strani poslužitelja, ali korisnik možda neće vidjeti sve generirane i naplaćene tokene.
• Ponašanje ovisno o ruti: otkažite za interaktivni chat, nastavite za tijek rada sličan poslu i učinite postavku vidljivom zakupcima.

Praktična zadana za interaktivno strujanje je otkazivanje uzlaznog kanala kada se nizvodni klijent prekine, a zatim označi red knjige kao client_aborted. Ako konačna uporaba stigne tijekom otkazivanja, podmirite iz te ovlaštene uporabe. Ako nije, označite red estimated ili pending_reconciliation radije nego da se pretvarate da je točan.

downstream.on("close", async () => {
  if (!providerCompleted) {
    ledger.markClientAborted(requestId);
    čekaj uzvodno.abort().catch(() => {
      ledger.emit("upstream_cancel_failed", requestId);
    });
  }
});

Preporuka: izložite transparentne oznake naplate kao što su final, provider_reconciled, estimated, waived ili pending_conciliation. To je lakše obraniti od prikazivanja svakog strujanog poziva kao neposrednog.

Provedba kvote tijekom streama

Točna naplata obično ovisi o konačnoj upotrebi pružatelja usluga, ali provedba kvote ne može uvijek čekati do kraja. Zakupcu s ograničenim proračunom ne bi se smjelo dopustiti strujanje na neodređeno vrijeme jer točna upotreba nije dostupna tijekom leta.

Koristite dva mehanizma zajedno:

1. Rezervacija prije leta: rezervirajte procijenjeni maksimum na temelju modela, maksimalnog traženog tokena, pravila zakupca i trenutnog stanja.
2. Provjere pritiska strujanja: procjena isporučenog izlaza tijekom strujanja i zaustavljanje ako zahtjev prijeđe konfiguriranu sigurnosnu granicu.

Ovo je kontrolni mehanizam, a ne konačni račun. Pružatelji mogu brojati predmemorirane tokene, tokene rezoniranja, multimodalne tokene ili skrivene tokene drugačije od procjenitelja pristupnika.

Kompromis: procjene u stvarnom vremenu pomažu u provedbi proračuna, ali se mogu razlikovati od tokena koje naplaćuje pružatelj usluga. Konačna nagodba trebala bi koristiti mjerodavnu upotrebu pružatelja usluga kada je dostupna, a usklađivanje bi trebalo prilagoditi procjene kasnije.

Događaji vidljivosti koji otkrivaju greške u računovodstvu

Kvarove naplate strujanja lakše je otkloniti kada pristupnik emitira ciljane događaje umjesto samo generičkih zapisa zahtjeva. Dodajte događaje kao što su:

• final_usage_missing: stream je završio bez autoritativne upotrebe.
• cumulative_usage_regressed: kumulativni broj tokena pomaknut je unatrag.
• stream_ended_without_stop_event: nije primijećena normalna oznaka zaustavljanja pružatelja usluga.
• aborted_after_provider_completion: pružatelj je dovršio, ali se klijent na donjem dijelu zatvorio prije nego što je pristupnik završio prosljeđivanje.
• settled_from_estimate: knjiga stanara upotrijebila je procjenu jer konačna upotreba nije bila dostupna.
• reconciliation_adjusted_usage: izvješćivanje pružatelja kasnije je promijenilo red.

Činjenica: OpenTelemetry GenAI semantičke konvencije preporučuju korištenje informacija o korištenju koje vraća pružatelj usluga za strujanje odgovora kada su dostupni i upozoravaju da se ne izvještava o metrici upotrebe ako se broj tokena ne može dobiti učinkovito ili točno.

Za analizu upotrebe umjetne inteligencije to znači da bi nadzorne ploče trebale podržavati razine pouzdanosti. Grafikon koji kombinira konačne, procijenjene i usklađene vrijednosti bez oznaka može izgledati čisto, ali dovesti u zabludu timove za financije i podršku.

Testovi usklađenosti za strujanje računovodstva

Nemojte se oslanjati na ručno testiranje s upitom za chat za sretan put. Svaki adapter davatelja trebao bi imati testove usklađenosti za slučajeve koji kvare knjige:

• Normalni tok: stiže konačna upotreba, promatra se događaj zaustavljanja, knjiga se slaže kao konačna.
• Tok poziva alata: delte poziva alata se prosljeđuju, korištenje se bilježi, strukturirani metapodaci ne oštećuju brojanje tokena.
• Sigurnosno ili odbijajuće zaustavljanje: pružatelj prestaje rano, korištenje se i dalje pravilno rješava.
• Prisilno isključivanje klijenta: nizvodno se zatvara nakon djelomičnog izlaza; uzvodno se otkazuje ili nastavlja u skladu s politikom.
• Uzvodno 5xx nakon djelomičnog izlaza: pristupnik bilježi djelomičnu isporuku i ne označava zahtjev kao čisti uspjeh.
• Istek vremena pristupnika prije konačne upotrebe: red postaje procijenjen ili čeka usklađivanje.
• Nedostaje završni događaj: adapter emitira final_usage_missing i izbjegava točne oznake naplate.

Ovi bi testovi trebali potvrditi prijelaze stanja, polja glavne knjige, emitirane događaje vidljivosti i nizvodno ponašanje. Kompatibilnost toka bajt za bajt nije dovoljna; računovodstvene nuspojave dio su ugovora.

Kontrolni popis za praktičnu primjenu

• Stvorite redak knjige korištenja prije slanja uzvodnog zahtjeva.
• Pohranite zakupca, ključ, korisnika, model, rutu, davatelja i identifikator zahtjeva u trenutku zahtjeva.
• Omogućite konačno izvješće o korištenju davatelja usluga tamo gdje je to podržano, kao što je stream_options.include_usage kompatibilno s OpenAI.
• Za kumulativne pružatelje, pohranite najnoviju vrijednost upotrebe umjesto zbrajanja događaja.
• Sačuvajte agregirane objekte odgovora kada ih SDK-ovi daju.
• Pratite isporučeni rezultat odvojeno od upotrebe koju naplaćuje pružatelj usluga.
• Nakon prekida veze, otkažite uzvodno prema politici rute i označite client_aborted.
• Koristite transparentne statuse naplate: konačni, procijenjeni, na čekanju za usklađivanje, davatelj usklađen ili odustao.
• Emitira događaje vidljivosti specifične za računovodstvo.
• Kasnije uskladite s izvješćima o korištenju ili troškovima pružatelja usluga kada su dostupna, uz očuvanje atribucije zakupca u vrijeme zahtjeva.

Što pokazati stanarima

Zakupci ne trebaju svaki interni događaj, ali trebaju poštene etikete. Korisna tablica upotrebe može prikazati:

• Status: konačni, procijenjeni ili usklađeni.
• Ishod zahtjeva: dovršen, klijent prekinut, pogreška pružatelja ili isteklo vrijeme pristupnika.
• Isporučeni rezultat: približan tekst ili bajtovi poslani klijentu.
• Naplaćeni tokeni: normalizirana upotreba davatelja usluga koja se koristi za trošak.
• Prilagodba: svaka kasnija delta usklađivanja.

Ovaj dizajn smanjuje dvosmislenost podrške. Ako je korisnik vidio samo dio odgovora, nadzorna ploča može objasniti je li pružatelj već dovršio, je li pristupnik otkazao uzvodno i je li naplata konačna ili procijenjena.

Preporuke nasuprot predviđanjima

Preporuke: tretirajte strujane zahtjeve kao automate stanja, pričekajte mjerodavnu konačnu upotrebu prije točne nagodbe, odvojite isporučeni izlaz od naplaćene upotrebe i pošteno označite procijenjene retke. Adapteri pružatelja usluga trebali bi kodirati semantiku upotrebe specifičnu za pružatelja usluga, a ne izravnavati svaki tok u generički bajt proxy.

Predviđanje: računovodstvo strujanja postat će važnije kako modeli otkrivaju sve više skrivenog rada: tokene za razmišljanje, popuste za tokene u predmemoriji, multimodalnu obradu, tragove upotrebe alata i sigurnosna zaustavljanja. Pristupnici koji već odvajaju korištenje koje naplaćuje pružatelj usluga od izlaza vidljivog klijentu lakše će se prilagoditi od pristupnika koji broje samo strujani tekst.

Zaključak koji se može poduzeti

Ako vaš gateway podržava strujanje, provjerite jedan put danas: prisilite klijenta da prekine vezu nakon prvih nekoliko dijelova i pregledajte red knjige. Ako piše "uspjeh" s točnim brojem tokena, vaša analitika vjerojatno laže.

Rješenje nije u napuštanju strujanja. Zadržite brzo korisničko iskustvo, ali neka budu eksplicitna računovodstvena stanja završetka streama, otkazivanja, pogrešaka pružatelja usluga, nedostatne konačne upotrebe i usklađivanja. To daje proizvodnim timovima odgovarajući rezultat, financijskim timovima obranjive troškove, a timovima za podršku dovoljno dokaza za objašnjenje djelomičnih odgovora bez nagađanja.

Povezano čitanje

• dizajniranje knjige naplate iza svakog modela poziva
• praćenja pridruživanja, knjige tokena i analitiku sigurne upotrebe
• izrada ugovora o kompatibilnosti pristupnika kompatibilnog s OpenAI