Računovodstvo pretočnih žetonov v prehodu AI API: končna uporaba, preklici in delni odgovori

Pretočne odgovore LLM je enostavno posredovati in jih je težko pravilno zaračunati. Če prehod API-ja AI posreduje dogodke, ki jih pošlje strežnik, odjemalcu, vendar prve dele obravnava kot zapis o uporabi, bo analitika najemnika odpadla. Odmik se običajno pojavi v sporih, kot so: »uporabnik je videl samo polovico odgovora«, »ponudnik je zaračunal več, kot je prikazano na naši nadzorni plošči«, »kvota je bila sproščena prezgodaj« ali »časovna omejitev je povzročila žetone, vendar ni vrstice na računu.«

Osnovna težava je, da pretočni klici niso en dogodek. So zaporedje: zahteva sprejeta, odprt tok navzgor, dostavljeni bajti, prijavljena končna uporaba, ponudnik ustavljen, odjemalec prekinjen, prehod je potekel in obračun poravnan. Zanesljiv prehod bi moral izrecno modelirati ta stanja, namesto da predpostavlja, da je dokončan odziv HTTP edina uspešna pot.

Način napake: pretakanje skrije obračunsko mejo

Nepretočna dokončanja običajno vrnejo en odzivni objekt z metapodatki o uporabi. Prehod lahko normalizira to uporabo, napiše vrstico glavne knjige, posodobi kvoto in odda analitiko v enem prehodu.

Pretakanje spremeni mejo. Uporabniška izkušnja je postopna, vendar lahko resnica o zaračunavanju prispe na koncu, v končnem dogodku, specifičnem za ponudnika, v kumulativni delti, prek združenega odgovora SDK ali pozneje prek API-jev za poročanje ponudnika. Če odjemalec prekine povezavo pred končnim dogodkom uporabe, je prehod morda poslal le del odgovora, medtem ko je ponudnik še vedno ustvaril in zaračunal več žetonov.

Dejstvo: OpenAI dokumentira, da morajo pretočni klicatelji, ki želijo podatke o uporabi, nastaviti stream_options s include_usage. OpenAI zagotavlja tudi končne točke uporabe in stroškov na ravni organizacije, pri čemer upošteva, da uporaba in stroški morda niso vedno popolnoma usklajeni za finančne namene.

Dejstvo: Antropično pretakanje uporablja dogodke, ki jih pošlje strežnik, kot so message_start, content_block_delta, message_delta in message_stop. Njegovi podatki o uporabi message_delta so kumulativni, zato prehod ne sme sešteti vsake delte uporabe skupaj.

Dejstvo: API-ji za pretakanje v slogu Gemini in Vertex lahko razkrijejo inkrementalne dele, medtem ko SDK-ji lahko zagotovijo tudi objekt združenega odziva. Za prehode je lahko ta združena pot boljši vir za dokončano uporabo kot samo vidni kosi.

Uporabite stroj stanja toka in ne logične zastavice za uspeh

Pretočna zahteva mora imeti trajen zapis uporabe, preden se začne klic navzgor. Ta zapis bi se moral premikati skozi eksplicitna stanja. Praktični minimum je:

• sprejeto: prehod je overil ključ, dodelil najemnika in ustvaril odprto vrstico glavne knjige.
• first_byte_sent: vsaj en izhodni dogodek je dosegel nižjega odjemalca.
• provider_completed: zgornji ponudnik je oddal običajni zaustavitveni signal ali dokončan odzivni objekt.
• client_aborted: nižja vtičnica se je zaprla pred normalnim zaključkom prehoda.
• provider_error: zgornji ponudnik je vrnil napako po začetku toka ali preden je prispela končna uporaba.
• gateway_timeout: prehod je uveljavil svoj proračun za zakasnitev in končal zahtevo.
• poravnano: prehod je pretvoril uporabo v stroške najemnika in porabo kvote.
• usklajeno: kasnejši podatki o uporabi ali stroških ponudnika so potrdili ali prilagodili vrstico.

Ta model preprečuje običajno napako analitike: označevanje vsakega toka, ki je ustvaril besedilo, kot »uspešnega in natančnega«. Tok je lahko uporaben za uporabnika, nepopoln s strani ponudnika, predviden za zaračunavanje in hkrati čaka na uskladitev.

Priporočena polja glavne knjige

Vrstica s časom zahteve naj bo majhna, a nazorna:

{
  "request_id": "gw_req_...",
  "tenant_id": "najemnik_123",
  "api_key_id": "ključ_456",
  "ponudnik": "odprti|antropski|dvojček|...",
  "provider_request_id": nič,
  "model": "id-modela-ponudnika",
  "stanje": "sprejeto",
  "tok": res,
  "input_tokens": nič,
  "output_tokens_billed": nič,
  "output_tokens_delivered_estimate": 0,
  "provider_usage_source": nič,
  "billing_status": "čakajoča_uskladitev",
  "client_abort_at": nič,
  "provider_completed_at": nič,
  "settled_at": nič,
  "razred_napake": nič
}

Pomembna ločitev je output_tokens_billed od output_tokens_delivered_estimate. Uporabnikom je vseeno, kaj je doseglo njihovo aplikacijo. Finance skrbi, kaj je ponudnik zaračunal. Te številke se lahko razlikujejo po prekinitvah povezave, tokovih klicev orodij, žetonih skritega sklepanja, predpomnjenih žetonih, varnostnih zaustavitvah ali časovnih omejitvah prehoda.

Pravila za zajemanje, specifična za ponudnika

API, združljiv z OpenAI, ki je nevtralen glede ponudnika, je uporaben za razvijalce aplikacij, vendar vmesnik prehoda še vedno potrebuje računovodska pravila, specifična za ponudnika.

Pretakanje, združljivo z OpenAI

Za poti OpenAI razkrijte možnost prehoda, ki omogoča poročanje o uporabi navzgor, kjer je podprto. Pogost vzorec je sprejetje privzete vrednosti na ravni prehoda, kot je:

{
  "tok": res,
  "možnosti_toka": {
    "include_usage": drži
  }
}

Če ga spodnji klicatelj izpusti, se lahko prehod odloči, ali ga bo vstavil za poti, kjer je to združljivo. Dokumentirajte to vedenje, ker nekateri odjemalci pričakujejo natančno združljivost žice in nekateri modeli ali navzgor morda ne bodo podpirali končne uporabe na enak način.

Priporočilo: stroškov najemnika ne poravnajte iz zgodnjih kosov. Vrstica glavne knjige naj bo odprta, dokler se ne zajame končni dogodek uporabe, odgovor ponudnika ne konča brez uporabe ali tok ne vstopi na pot napake ali preklica.

Antropsko pretakanje

Kumulativna uporaba Anthropica zahteva drugačno pravilo. Če prehod vidi tri dogodke message_delta s številom izhodnih žetonov 10, 25 in 40, je izhodno število 40 in ne 75.

let latestUsage = null;
for await (konstantni dogodek anthropicStream) {
  if (event.type === "message_delta" && event.usage) {
    if (latestUsage && event.usage.output_tokens < latestUsage.output_tokens) {
      emit("cumulative_usage_regressed", requestId);
    }
    latestUsage = event.usage;
  }
  forwardToClient(dogodek);
}
settleFromLatestCumulativeUsage(latestUsage);

Priporočilo: zabeležite zadnjo kumulativno vrednost uporabe in oddajte dogodek opaznosti, če se zmanjša. Regresija lahko kaže na napake razčlenjevalnika, podvojene dogodke, spremembe ponudnika ali mešane tokove.

Pretakanje v slogu Gemini in Vertex

Gemini podpira pretočne dele za zmanjšanje zaznane zakasnitve. V SDK-jih v slogu Vertex lahko pretakanje izpostavi tako asinhroni tok kot objekt združenega odziva. Prehod mora ohraniti to združeno pot, ko je na voljo.

const streamingResult = await model.generateContentStream(request);
for await (const chunk of streamingResult.stream) {
  forwardChunk(kos);
  countDeliveredBytesOrText(kos);
}
const aggregated = await streamingResult.response;
settleFromAggregatedUsage(agregirano);

Priporočilo: izogibajte se ustvarjanju celotnega obračunavanja iz vidnih kosov, če SDK daje izpolnjen odgovor. Kosi so za zakasnitev. Končni objekt je pogosto boljši za zaračunavanje in analitiko.

Prekinitve povezave s strankami obravnavajte kot prvovrstne računovodske dogodke

Pri prekinitvi povezave med odjemalci številni prehodi izgubijo denar ali strankam zaračunajo previsoke stroške. Zavihek brskalnika se zapre, mobilno omrežje prekine ali aplikacija prekliče zahtevo. Prehod opazi, da je nižja vtičnica zaprta, vendar ponudnik navzgor morda še vedno ustvarja.

Prehod mora izrecno izbrati pravilnik:

• Takoj prekliči navzgor: zmanjša izgubljeno proizvodnjo in stroške ponudnika, vendar lahko prekine delovne tokove, kjer zaledje še vedno potrebuje rezultat po prekinitvi povezave uporabniškega vmesnika.
• Nadaljevanje navzgor v ozadju: lahko ohrani delo za uporabnike na strani strežnika, vendar uporabnik morda ne bo videl vseh ustvarjenih in zaračunanih žetonov.
• Vedenje, odvisno od poti: prekličite za interaktivni klepet, nadaljujte za poteke dela, podobne opravilom, in naredite nastavitev vidno najemnikom.

Praktična privzeta vrednost za interaktivno pretakanje je preklic navzgor, ko nižji odjemalec prekine povezavo, nato pa vrstico glavne knjige označite kot client_aborted. Če končna uporaba prispe med odpovedjo, poravnajte iz te avtoritativne uporabe. Če ni, označite vrstico estimated ali pending_reconciliation, namesto da se pretvarjate, da je točna.

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

Priporočilo: izpostavite pregledne oznake za obračunavanje, kot so končno, provider_reconciled, estimated, waived ali pending_reconciliation. To je bolj zagovorljivo kot prikazovanje vsakega pretočnega klica kot takojšnjega točnega.

Uveljavljanje kvote med tokom

Natančno zaračunavanje je običajno odvisno od končne uporabe ponudnika, vendar uveljavljanje kvote ne more vedno čakati do konca. Najemniku s trdim proračunom ne bi smeli dovoliti pretakanja za nedoločen čas, ker natančna uporaba med letom ni na voljo.

Uporabite dva mehanizma skupaj:

1. Rezervacija pred letom: rezervirajte predvideno največjo vrednost glede na model, zahtevano največje število žetonov, politiko najemnika in trenutno stanje.
2. Preverjanja tlaka pretakanja: ocenite dostavljen izhod med tokom in se ustavite, če zahteva prestopi konfigurirano varnostno mejo.

To je nadzorni mehanizem, ne končni račun. Ponudniki lahko štejejo predpomnjene žetone, žetone sklepanja, multimodalne žetone ali skrite žetone drugače kot ocenjevalec prehoda.

Kompromis: ocene v realnem času pomagajo uveljavljati proračune, vendar se lahko razlikujejo od žetonov, ki jih zaračuna ponudnik. Pri končni poravnavi bi morala biti uporabljena verodostojna uporaba ponudnika, ko je na voljo, in uskladitev bi morala prilagoditi ocene pozneje.

Dogodki opazljivosti, ki odkrijejo računovodske napake

Napake pri zaračunavanju pretakanja je lažje odpraviti, ko prehod oddaja ciljne dogodke namesto samo splošnih dnevnikov zahtev. Dodajte dogodke, kot so:

• final_usage_missing: tok se je končal brez avtoritativne uporabe.
• cumulative_usage_regressed: kumulativno število žetonov premaknjeno nazaj.
• stream_ended_without_stop_event: opaziti ni bilo običajnega označevalca za zaustavitev ponudnika.
• aborted_after_provider_completion: ponudnik je dokončal, vendar se je nižji odjemalec zaprl, preden je prehod končal posredovanje.
• settled_from_estimate: knjiga najemnikov je uporabila oceno, ker končna uporaba ni bila na voljo.
• reconciliation_adjusted_usage: poročanje ponudnika je pozneje spremenilo vrstico.

Dejstvo: semantične konvencije OpenTelemetry GenAI priporočajo uporabo informacij o uporabi, ki jih vrne ponudnik, za pretakanje odgovorov, ko so na voljo, in svarijo pred poročanjem o meritvah uporabe, če števila žetonov ni mogoče pridobiti učinkovito ali natančno.

Za analizo uporabe umetne inteligence to pomeni, da morajo nadzorne plošče podpirati stopnje zaupanja. Grafikon, ki meša končne, ocenjene in usklajene vrednosti brez oznak, je lahko videti čist, vendar zavaja finančne in podporne ekipe.

Preizkusi skladnosti za pretočno obračunavanje

Ne zanašajte se na ročno testiranje s pozivom za klepet s srečno potjo. Vsak adapter ponudnika mora imeti teste skladnosti za primere, ki pokvarijo glavne knjige:

• Običajni tok: končna uporaba prispe, opazovan dogodek zaustavitve, knjiga se poravna kot končna.
• Tok klica orodja: delte klica orodja so posredovane, uporaba je zajeta, strukturirani metapodatki ne poškodujejo štetja žetonov.
• Varnostna ali zavrnitvena zaustavitev: ponudnik se predčasno ustavi, uporaba se še vedno pravilno poravna.
• Prisilna prekinitev povezave z odjemalcem: nižji tok se zapre po delnem izhodu; navzgor je preklican ali se nadaljuje v skladu s pravilnikom.
• Navzgor 5xx po delnem izhodu: prehod zabeleži delno dostavo in zahteve ne označi kot čisto uspešno.
• Časovna omejitev prehoda pred končno uporabo: vrstica postane ocenjena ali čaka na uskladitev.
• Manjkajoči končni dogodek: adapter odda final_usage_missing in se izogne natančnim oznakam za obračun.

Ti testi morajo potrditi prehode stanj, polja glavne knjige, oddane dogodke opazljivosti in vedenje na nižji stopnji. Združljivost tokov bajt za bajt ni dovolj; stranski učinki računovodstva so del pogodbe.

Kontrolni seznam za praktično izvajanje

• Ustvarite vrstico knjige uporabe, preden pošljete zahtevo navzgor.
• Shrani identifikatorje najemnika, ključa, uporabnika, modela, poti, ponudnika in zahteve ob času zahteve.
• Omogočite končno poročanje o uporabi ponudnika, kjer je to podprto, na primer stream_options.include_usage, združljivo z OpenAI.
• Pri kumulativnih ponudnikih shranite zadnjo vrednost uporabe namesto seštevanja dogodkov.
• Ohranite združene odzivne objekte, ko jih zagotovijo SDK-ji.
• Sledenje dostavljenemu rezultatu ločeno od uporabe, ki jo zaračuna ponudnik.
• Ob prekinitvi povezave prekličite navzgor v skladu s politiko poti in označite client_aborted.
• Uporabite pregledna stanja zaračunavanja: končno, ocenjeno, čakajoča na uskladitev, ponudnik usklajeno ali opuščeno.
• Oddajanje dogodkov opazovanja, specifičnih za računovodstvo.
• Pozneje uskladite s poročili o uporabi ali stroških ponudnika, ko so na voljo, hkrati pa ohranite dodelitev najemnika v času zahteve.

Kaj pokazati najemnikom

Najemniki ne potrebujejo vsakega notranjega dogodka, potrebujejo pa poštene oznake. Uporabna tabela uporabe lahko prikazuje:

• Stanje: končno, ocenjeno ali usklajeno.
• Rezultat zahteve: dokončana, odjemalec prekinjen, napaka ponudnika ali časovna omejitev prehoda.
• Dostavljen izhod: približno besedilo ali bajti, poslani odjemalcu.
• Zaračunani žetoni: normalizirana uporaba ponudnika, uporabljena za stroške.
• Prilagoditev: vsaka kasnejša delta uskladitve.

Ta zasnova zmanjšuje dvoumnost podpore. Če je uporabnik videl le del odgovora, lahko na nadzorni plošči pojasni, ali je ponudnik že dokončal, ali je prehod preklical navzgor in ali je plačilo končno ali ocenjeno.

Priporočila proti napovedim

Priporočila: obravnavajte pretočne zahteve kot državne stroje, počakajte na avtoritativno končno uporabo pred natančno poravnavo, ločite dostavljeni rezultat od zaračunane porabe in pošteno označite ocenjene vrstice. Adapterji ponudnika bi morali kodirati semantiko uporabe, specifično za ponudnika, namesto da bi sploščili vsak tok v generični bajtni proxy.

Predvidevanje: pretočno obračunavanje bo postalo pomembnejše, saj bodo modeli razkrili več skritega dela: žetoni sklepanja, popusti za predpomnjene žetone, multimodalna obdelava, sledenje uporabe orodij in varnostni postanki. Prehodi, ki že ločujejo porabo, ki jo zaračuna ponudnik, od izhoda, vidnega odjemalcem, se bodo lažje prilagodili kot prehodi, ki štejejo samo pretočno besedilo.

Dejanski sklep

Če vaš prehod podpira pretakanje, pregledajte eno pot še danes: prisilite stranko, da prekine povezavo po prvih nekaj delih in preglejte vrstico glavne knjige. Če piše "uspeh" z natančnimi štetji žetonov, vaša analitika verjetno laže.

Popravek ni v tem, da opustite pretakanje. Ohranite hitro uporabniško izkušnjo, vendar naj bodo zaključek toka, preklic, napake ponudnika, manjkajoča končna uporaba in usklajevanje izrecna računovodska stanja. To daje proizvodnim ekipam odziven rezultat, finančnim ekipam upravičljive stroške in podpornim ekipam dovolj dokazov za razlago delnih odgovorov brez ugibanja.

Sorodno branje

• oblikovanje obračunske knjige za vsakim modelom klic
• sledi pridruževanja, knjige žetonov in analitika varne uporabe
• izdelava pogodbe o združljivosti prehoda, združljive z OpenAI