Tokenu uzskaites straumēšana AI API vārtejā: galīgais lietojums, atcelšana un daļējas atbildes

Straumēšanas LLM atbildes ir viegli izmantot starpniekserveri un grūti pareizi rēķināties. Ja AI API vārteja pārsūta klientam servera sūtītos notikumus, bet pirmos gabalus uzskata par lietojuma ierakstiem, nomnieka analītika novirzīsies. Novirze parasti parādās strīdos, piemēram: “lietotājs redzēja tikai pusi atbildes”, “pakalpojumu sniedzējs maksāja vairāk, nekā rāda informācijas panelis”, “kvota tika atbrīvota pārāk agri” vai “noildze radīja marķierus, bet nebija rēķina rindas”.

Pamatproblēma ir tā, ka straumētie zvani nav viens notikums. Tie ir secība: pieprasījums pieņemts, augšupējā straume atvērta, baiti piegādāti, gala lietojums ir apturēts, pakalpojumu sniedzējs ir atvienots, vārtejas noildze ir beidzies un norēķini ir nokārtoti. Uzticamai vārtejai šie stāvokļi ir skaidri jāmodelē, nevis jāpieņem, ka pabeigta HTTP atbilde ir vienīgais veiksmīgais ceļš.

Kļūmes režīms: straumēšana slēpj uzskaites robežu

Nestraumētas pabeigšanas parasti atgriež vienu atbildes objektu ar lietojuma metadatiem. Vārteja var normalizēt šo lietojumu, rakstīt virsgrāmatas rindu, atjaunināt kvotu un izdalīt analīzi vienā piegājienā.

Straumēšana maina robežu. Lietotāja pieredze ir pakāpeniska, taču norēķinu patiesība var nonākt beigās, pakalpojumu sniedzējam noteiktā pēdējā notikumā, kumulatīvā delta, izmantojot apkopotu SDK atbildi vai vēlāk, izmantojot pakalpojumu sniedzēja pārskatu API. Ja klients atvienojas pirms pēdējā lietošanas notikuma, vārteja, iespējams, ir sniegusi tikai daļu atbildes, kamēr pakalpojumu sniedzējs joprojām ģenerēja un iekasēja papildu pilnvaras.

Fakts: OpenAI dokumenti, ka straumēšanas zvanītājiem, kuri vēlas lietot datus, ir jāiestata stream_options ar include_usage. OpenAI nodrošina arī organizācijas līmeņa lietojuma un izmaksu galapunktus, vienlaikus ņemot vērā, ka izmantošana un izmaksas ne vienmēr var būt ideāli saskaņotas finanšu nolūkos.

Fakts: antropiskā straumēšana izmanto servera sūtītus notikumus, piemēram, message_start, content_block_delta, message_delta un message_stop. Tās message_delta lietojuma informācija ir kumulatīva, tāpēc vārteja nedrīkst pievienot katru lietojuma delta.

Fakts: Gemini un Vertex stila straumēšanas API var atklāt pakāpeniskas daļas, savukārt SDK var nodrošināt arī apkopotu atbildes objektu. Vārtejas gadījumā šis apkopotais ceļš var būt labāks avots pilnīgai lietošanai nekā atsevišķi redzamie fragmenti.

Izmantojiet straumes stāvokļa mašīnu, nevis Būla veiksmes karogu

Straumētam pieprasījumam ir jābūt noturīgam lietojuma ierakstam pirms augšupējā zvana sākuma. Šim ierakstam vajadzētu pārvietoties pa skaidriem stāvokļiem. Praktiskais minimums ir:

• pieņemts: vārteja autentificēja atslēgu, attiecināja uz nomnieku un izveidoja atvērtu virsgrāmatas rindu.
• first_byte_sent: vismaz viens izvades notikums sasniedza pakārtoto klientu.
• provider_completed: augšējais pakalpojumu sniedzējs izstaro normālu apturēšanas signālu vai pabeidza atbildes objektu.
• client_aborted: pakārtotā ligzda tika aizvērta pirms parastās vārtejas pabeigšanas.
• provider_error: augšējais pakalpojumu sniedzējs atgrieza kļūdu pēc straumes sākuma vai pirms galīgās lietošanas.
• gateway_timeout: vārteja piemēroja latentuma budžetu un beidza pieprasījumu.
• nokārtots: vārteja pārveidoja lietojumu nomnieka izmaksās un kvotas patēriņā.
• saskaņots: rindu apstiprināja vai koriģēja vēlāk pakalpojumu sniedzēja lietojuma vai izmaksu dati.

Šis modelis novērš izplatītu analīzes kļūdu: katras straumes, kurā tika izveidots teksts, atzīmēšana kā “veiksmīga un precīza”. Straume var būt noderīga lietotājam, nepabeigta no nodrošinātāja, aprēķināta norēķinu veikšanai un vienlaikus gaida saskaņošanu.

Ieteicamie virsgrāmatas lauki

Saglabājiet pieprasījuma laika rindu mazu, bet skaidru:

{
  "request_id": "gw_req_...",
  "īrnieka_id": "īrnieks_123",
  "api_key_id": "key_456",
  "provider": "openai|anthropic|gemini|...",
  "provider_request_id": null,
  "modelis": "provider-model-id",
  "state": "pieņemts",
  "straume": taisnība,
  "input_tokens": null,
  "output_tokens_billed": null,
  "output_tokens_delivered_estimate": 0,
  "provider_usage_source": null,
  "billing_status": "pending_conciliation",
  "client_abort_at": null,
  "provider_completed_at": null,
  "settled_at": null,
  "error_class": null
}

Svarīgākā atdalīšana ir output_tokens_billed un output_tokens_delivered_estimate. Lietotājiem ir svarīgi, kas sasniedza viņu pieteikumu. Finansēm ir svarīgi, ko pakalpojumu sniedzējs izrakstījis. Šie skaitļi var atšķirties pēc atvienošanas, rīku izsaukuma straumēm, slēptiem argumentācijas marķieriem, kešatmiņā saglabātiem marķieriem, drošības apstāšanās vai vārtejas taimauta.

Pakalpojumu sniedzēja tveršanas noteikumi

Neitrāla pakalpojumu sniedzēja ar OpenAI saderīga API ir noderīga lietojumprogrammu izstrādātājiem, taču vārtejas adapterim joprojām ir nepieciešami pakalpojumu sniedzējam specifiski uzskaites noteikumi.

Ar OpenAI saderīga straumēšana

OpenAI maršrutiem atklājiet vārtejas opciju, kas iespējo augšējo lietojuma pārskatu sniegšanu, ja tas tiek atbalstīts. Izplatīts modelis ir pieņemt vārtejas līmeņa noklusējuma iestatījumus, piemēram:

{
  "straume": taisnība,
  "stream_options": {
    "include_usage": taisnība
  }
}

Ja pakārtotais zvanītājs to izlaiž, vārteja var izlemt, vai ievadīt to maršrutos, kur tas ir saderīgs. Dokumentējiet šo darbību, jo daži klienti sagaida precīzu vadu savietojamību, un daži modeļi vai augšupējie modeļi var neatbalstīt galīgo lietojumu tādā pašā veidā.

Ieteikums: nekārtojiet īrnieka izmaksas no agrīnām daļām. Turiet virsgrāmatas rindu atvērtu, līdz tiek fiksēts pēdējais lietošanas notikums, pakalpojumu sniedzēja atbilde beidzas bez lietošanas vai straume ievada kļūdas vai atcelšanas ceļu.

Antropiskā straumēšana

Anthropic kumulatīvā lietojuma gadījumā ir nepieciešams cits noteikums. Ja vārteja redz trīs message_delta notikumus ar izvades pilnvaru skaitu 10, 25 un 40, izvades skaits ir 40, nevis 75.

let latestUsage = null;
for wait (konst notikums anthropicStream) {
  if (event.type === "message_delta" && event.usage) {
    if (latestUsage && event.usage.output_tokens < latestUsage.output_tokens) {
      emit("kumulatīvā_lietojuma_regresēta", pieprasījuma ID);
    }
    jaunākaisUsage = event.usage;
  }
  forwardToClient(event);
}
setttleFromLatestCumulativeUsage(latestUsage);

Ieteikums: ierakstiet jaunāko kumulatīvo lietojuma vērtību un izdodiet novērojamības notikumu, ja tas regresē. Regresija var norādīt uz parsētāja kļūdām, dublētiem notikumiem, nodrošinātāja izmaiņām vai jauktām straumēm.

Dvīņu un Vertex stila straumēšana

Gemini atbalsta straumēšanas gabalus, lai samazinātu uztverto latentumu. Vertex stila SDK straumēšana var atklāt gan asinhronu straumi, gan apkopotas atbildes objektu. Vārtejai jāsaglabā šis apkopotais ceļš, ja tas ir pieejams.

const streamingResult = gaidīt model.generateContentStream(request);
for await (const chunk of streamingResult.stream) {
  uz priekšuChunk(gabals);
  countDeliveredBytesOrText(gabals);
}
const aggregated = gaidīt straumēšanasResult.response;
setttleFromAggregatedUsage(agregated);

Ieteikums: neveidojiet visu uzskaiti no redzamiem gabaliem, ja SDK sniedz aizpildītu atbildes ierakstu. Gabali ir paredzēti latentumam. Pēdējais objekts bieži ir labāks norēķiniem un analīzei.

Apstrādājiet klientu atvienojumus kā pirmās klases grāmatvedības notikumus

Klientu atvienošanās ir vieta, kur daudzi vārtejas zaudē naudu vai iekasē klientiem pārmaksu. Pārlūka cilne tiek aizvērta, mobilais tīkls tiek pārtraukts vai lietojumprogramma atceļ pieprasījumu. Vārteja pamana, ka pakārtotā ligzda ir aizvērta, taču augšējais pakalpojumu sniedzējs, iespējams, joprojām ģenerē.

Vārtejai ir jāizdara skaidra politikas izvēle:

• Nekavējoties atcelt augšup: samazina izšķērdētās ģenerēšanas un pakalpojumu sniedzēja izmaksas, taču var tikt pārtraukta darbplūsma, ja aizmugursistēmai joprojām ir nepieciešams rezultāts pēc lietotāja interfeisa atvienošanas.
• Turpināt fonā: var saglabāt darbu servera puses patērētājiem, taču lietotājs var neredzēt visus ģenerētos un apmaksātos marķierus.
• No maršruta atkarīga rīcība: atceliet interaktīvai tērzēšanai, turpiniet darbam līdzīgas darbplūsmas un padariet iestatījumu redzamu nomniekiem.

Praktisks interaktīvās straumēšanas noklusējuma iestatījums ir atcelt augšējo straumi, kad pakārtotais klients atvienojas, un pēc tam atzīmēt virsgrāmatas rindu kā client_aborted. Ja atcelšanas laikā tiek veikts galīgais lietojums, norēķinieties ar šo autoritatīvo lietojumu. Ja nē, atzīmējiet rindu aptuvenais vai gaida_saskaņošanu, nevis izlikties, ka tā ir precīza.

downstream.on("close", async () => {
  if (!providerCompleted) {
    virsgrāmata.markClientAborted(requestId);
    gaidīt upstream.abort().catch(() => {
      virsgrāmata.emit("augšupstraumes_atcelt_neizdevās", pieprasījuma ID);
    });
  }
});

Ieteikums: parādiet pārskatāmas norēķinu iezīmes, piemēram, galīgs, provider_reconciled, aptuvenais, atcelts vai gaida_saskaņošanu. Tas ir vairāk aizsargājams, nekā parādīt katru straumēto zvanu kā tūlītēju precīzu.

Kvotas piemērošana straumes laikā

Precīzi norēķini parasti ir atkarīgi no gala pakalpojumu sniedzēja lietojuma, taču kvotas izpilde ne vienmēr var gaidīt līdz beigām. Īrniekam ar ierobežotu budžetu nevajadzētu ļaut straumēt bezgalīgi, jo lidojuma vidū nav pieejams precīzs lietojums.

Izmantojiet divus mehānismus kopā:

1. Pirmslidojuma rezervēšana: rezervējiet aptuveno maksimālo summu, pamatojoties uz modeli, pieprasītajiem maksimālajiem marķieriem, nomnieka politiku un pašreizējo atlikumu.
2. Straumēšanas spiediena pārbaudes: novērtējiet piegādāto izvadi straumes laikā un apturiet, ja pieprasījums šķērso konfigurētu drošības robežu.

Šis ir kontroles mehānisms, nevis gala rēķins. Pakalpojumu sniedzēji var skaitīt kešatmiņā saglabātos marķierus, argumentācijas pilnvaras, multimodālos marķierus vai slēptos marķierus atšķirīgi no vārtejas aprēķinātāja.

Kompozīcija: reāllaika aprēķini palīdz īstenot budžetus, taču tie var atšķirties no pakalpojumu sniedzēja rēķiniem. Galīgajā norēķinā ir jāizmanto autoritatīvs pakalpojumu sniedzēja lietojums, ja tas ir pieejams, un saskaņošanā vēlāk jāpielāgo aprēķini.

Novērojamības notikumi, kas uztver grāmatvedības kļūdas

Straumēšanas norēķinu kļūmes ir vieglāk atkļūdotas, ja vārteja izstaro mērķtiecīgus notikumus, nevis tikai vispārīgus pieprasījumu žurnālus. Pievienojiet notikumus, piemēram:

• final_usage_missing: straume beigusies bez autoritatīva lietojuma.
• cumulative_usage_regressed: kumulatīvais pilnvaru skaits ir pārvietots atpakaļ.
• stream_ended_without_stop_event: netika novērots normāls pakalpojumu sniedzēja apturēšanas marķieris.
• aborted_after_provider_completion: pakalpojumu sniedzējs pabeidza darbību, bet pakārtotais klients tika aizvērts, pirms vārteja pabeidza pārsūtīšanu.
• settled_from_estimate: nomnieka virsgrāmatā tika izmantots aprēķins, jo galīgais lietojums nebija pieejams.
• reconciliation_adjusted_usage: pakalpojumu sniedzēja ziņojumi vēlāk mainīja rindu.

Fakts: OpenTelemetry GenAI semantiskās konvencijas iesaka izmantot pakalpojumu sniedzēja atgriezto lietojuma informāciju straumēšanas atbildēm, ja tāda ir pieejama, un brīdina par lietojuma metrikas ziņošanu, ja marķieru skaitu nevar iegūt efektīvi vai precīzi.

Attiecībā uz AI lietojuma analīzi tas nozīmē, ka informācijas paneļiem ir jāatbalsta uzticamības līmeņi. Diagramma, kurā apvienotas galīgās, aplēstās un saskaņotās vērtības bez iezīmēm, var izskatīties tīra, taču maldināt finanšu un atbalsta komandas.

Atbilstības testi straumēšanas uzskaitei

Nepaļaujieties uz manuālu testēšanu, izmantojot laimīgā ceļa tērzēšanas uzvedni. Katram nodrošinātāja adapterim ir jābūt atbilstības pārbaudēm gadījumiem, kad tiek pārkāptas virsgrāmatas:

• Parastā straume: pienāk galīgais lietojums, novērots apturēšanas notikums, virsgrāmata tiek uzskatīta par galīgo.
• Rīka izsaukuma straume: rīku izsaukuma deltas tiek pārsūtītas, lietojums tiek fiksēts, strukturētie metadati nebojā marķiera skaitīšanu.
• Drošības vai atteikuma apturēšana: pakalpojumu sniedzējs pārtrauc darbu agri, lietojums joprojām tiek atrisināts pareizi.
• Piespiedu klienta atvienošana: pakārtots tiek aizvērts pēc daļējas izvades; augštecē tiek atcelts vai turpināts saskaņā ar politiku.
• Upstream 5xx pēc daļējas izvades: vārteja reģistrē daļēju piegādi un neatzīmē pieprasījumu kā sekmīgu.
• Vārtejas noildze pirms galīgās izmantošanas: rinda kļūst aptuvenā vai gaida saskaņošanu.
• Trūkst gala notikuma: adapteris izstaro final_usage_missing un izvairās no precīzām norēķinu etiķetēm.

Šajos testos ir jāapliecina stāvokļa pārejas, virsgrāmatas lauki, emitētie novērojamības notikumi un lejupvērsta darbība. Ar baitu baitiem straumes savietojamību nepietiek; grāmatvedības blakusefekti ir daļa no līguma.

Praktiskās ieviešanas kontrolsaraksts

• Pirms iepriekšējā pieprasījuma nosūtīšanas izveidojiet lietošanas virsgrāmatas rindu.
• Veikala nomnieka, atslēgas, lietotāja, modeļa, maršruta, nodrošinātāja un pieprasījuma identifikatori pieprasījuma laikā.
• Iespējojiet pakalpojumu sniedzēja gala lietojuma pārskatus, ja tie tiek atbalstīti, piemēram, ar OpenAI saderīgu stream_options.include_usage.
• Kumulatīviem pakalpojumu sniedzējiem notikumu summēšanas vietā saglabājiet jaunāko lietojuma vērtību.
• Saglabājiet apkopotos atbilžu objektus, kad tos nodrošina SDK.
• Izsekojiet piegādāto izvadi atsevišķi no pakalpojumu sniedzēja rēķina lietojuma.
• Atvienojot savienojumu, atceliet augšup pa straumi saskaņā ar maršruta politiku un atzīmējiet client_aborted.
• Izmantojiet pārskatāmus norēķinu statusus: galīgais, aptuvenais, gaida saskaņošanu, nodrošinātājs saskaņots vai atcelts.
• Izdod uzskaitei raksturīgus novērojamības notikumus.
• Vēlāk saskaņojiet ar pakalpojumu sniedzēja lietojuma vai izmaksu pārskatiem, ja tie ir pieejami, vienlaikus saglabājot pieprasījuma laika nomnieka attiecinājumu.

Ko rādīt īrniekiem

Īrniekiem nav vajadzīgi visi iekšējie notikumi, taču viņiem ir vajadzīgas godīgas etiķetes. Noderīgā lietojuma tabulā var parādīties:

• Statuss: galīgais, aptuvenais vai saskaņotais.
• Pieprasījuma rezultāts: pabeigts, klients pārtraukts, nodrošinātāja kļūda vai vārtejas taimauts.
• Piegādātā izvade: aptuvens klientam nosūtītais teksts vai baiti.
• Rēķina marķieri: pakalpojumu sniedzēja normalizēts lietojums, ko izmanto izmaksām.
• Korekcija: jebkura vēlāka saskaņošanas delta.

Šis dizains samazina atbalsta neskaidrības. Ja lietotājs redzēja tikai daļu atbildes, informācijas panelī var paskaidrot, vai pakalpojumu sniedzējs jau ir pabeidzis darbu, vai vārteja ir atcelta un vai maksa ir galīga vai aprēķināta.

Ieteikumi salīdzinājumā ar prognozēm

Ieteikumi: uztveriet straumētos pieprasījumus kā statusa iekārtas, pirms precīza norēķina gaidiet uzticamu galīgo lietojumu, atdaliet piegādāto izvadi no rēķina lietošanas un godīgi marķējiet aptuvenās rindas. Pakalpojumu sniedzēja adapteriem ir jākodē pakalpojumu sniedzējam specifiska lietojuma semantika, nevis jāsaplacina katra straume vispārīgā baitu starpniekserverī.

Paredzēšana: straumēšanas uzskaite kļūs svarīgāka, jo modeļi atklāj vairāk slēpto darbu: argumentācijas marķieri, kešatmiņā saglabāto marķieru atlaides, multimodāla apstrāde, rīku lietošanas pēdas un drošības apstāšanās. Vārtejas, kas jau atdala pakalpojumu sniedzēja rēķinu lietojumu no klienta redzamās izvades, pielāgosies vieglāk nekā vārtejas, kas uzskaita tikai straumētu tekstu.

Apstrīdams secinājums

Ja jūsu vārteja atbalsta straumēšanu, pārbaudiet vienu ceļu jau šodien: piespiediet klientu atvienot pēc dažām pirmajām daļām un pārbaudiet virsgrāmatas rindu. Ja ir rakstīts “veiksmi” ar precīzu marķieru skaitu, iespējams, jūsu analītika melo.

Labojums ir neatteikties no straumēšanas. Saglabājiet ātru lietotāja pieredzi, taču straumes pabeigšanas, atcelšanas, pakalpojumu sniedzēja kļūdu, galīgā lietojuma trūkuma un saskaņošanas skaidri norādītos uzskaites stāvokļus. Tas nodrošina produktu komandām atsaucīgu rezultātu, finanšu komandām attaisnojamas izmaksas un atbalsta komandām pietiekami daudz pierādījumu, lai izskaidrotu daļējas atbildes bez minējumiem.

Saistīta informācija

• zvaniet
• pievienošanās pēdām, marķieru virsgrāmatām un drošas lietošanas analīzi
ar OpenAI saderīga vārtejas saderības līguma izveide