LLM-observabilitet i en multi-modell API-gateway: spor, token-ledgers, leietakeranalyse og sikker loggføring

Samlet antall forespørsler og månedlig forbruk er ikke nok når en kunde spør hvorfor en arbeidsflyt ble tregere, dyrere eller mindre pålitelig i går. En multi-modell API-gateway kan svare på det spørsmålet hvis den behandler observerbarhet som en del av kontrollplanet: hver forespørsel får et spor, hvert modellanrop oppdaterer en bruksreskontro, hver leietaker og arbeidsflyt kan tilskrives, og sensitivt innhold er beskyttet som standard.

Denne artikkelen beskriver et praktisk design for AI-bruksanalyse og LLM-observasjon i en gateway som fronter flere leverandører gjennom en OpenAI-kompatibel API. Mønsteret er nyttig selv om du ikke bruker noen spesifikk leverandør: instrument én gang ved gatewayen, normaliser modelltelemetri, bevar faktureringsattribusjon og fange opp spørsmålsinnhold kun under eksplisitte retningslinjer.

Leserproblemet: "Hvilken leietaker, modell, forespørsel eller gjenfinningsbane forårsaket endringen?"

De fleste team møter etter hvert det samme feilsøkingsgapet. Programlogger viser at en funksjon mislyktes. Leverandørdashbord viser at tokenbruken økte. Finans ser en regning. Ingen av disse visningene i seg selv forklarer hele veien fra leietakerforespørsel til modellanrop til hentingskontekst for å prøve på nytt til fakturert kostnad.

Målet er ikke et annet dashbord med totalt antall tokens. Målet er å svare på operasjonelle spørsmål som:

• Hvilken leietaker eller API-nøkkel forårsaket en økning i forbruket?
• Har ventetiden økt etter at et modellalias ble endret?
• Teller nye forsøk eller reserver kostnadene dobbelt?
• Hvilken promptversjon brenner mest feilbudsjett?
• Ble en RAG-arbeidsflyt dyr fordi henting la til for mange konteksttokens?
• Kan støtte feilsøking av en hendelse uten å lese private brukerforespørsler?

Fakta, anbefalinger og spådommer

Fakta: OpenTelemetry dokumenterer generative AI semantiske konvensjoner og attributter for modelloperasjoner, inkludert operasjonsnavn som chat, generer_innhold og tekstfullføring. Den samme dokumentasjonen advarer om at GenAI input og output meldingsattributter kan inneholde sensitiv informasjon eller PII og kan kreve filtrering eller trunkering. Store modellleverandører avslører også bruksdashbord, API-er eller eksporter som kan støtte avstemming på leverandørsiden, selv om detaljene varierer fra leverandør til leverandør.

Anbefalinger: Bruk OpenTelemetry for leverandørnøytrale spor, men behold gateway-eide forretningsdimensjoner i dine egne attributter og reskontro. Ikke lagre rå meldinger eller utdata som standard. Lagre metadata, hasher, tokenantall, ledetekstmal-IDer, skjemanavn, feilklasser og sikkerhetsetiketter først. Legg kun til innholdsfangst som en opt-in, tilgangskontrollert, kortvarig feilsøkingsfunksjon.

Prediksjon: LLM-observasjon vil bli mindre om isolerte leverandørdashboards og mer om kontrollplan på tvers av leverandører. Teamene vil forvente ett sted for å undersøke ventetid, kostnader, kvalitet, policyhendelser, leietakers atferd og faktureringsdeltaer på tvers av modeller.

Referansearkitektur: observer hele forespørselsbanen

En gateway kan se hele forespørselens livssyklus uten at alle applikasjonsteam må bygge tilpasset telemetri. En nyttig sporingsmodell starter med ett overordnet spenn for den innkommende kundeforespørselen og underordnet spenn for trinnene som påvirker kostnad, forsinkelse og kvalitet.

Anbefalt spennstruktur

• Gateway-forespørselsspenn: forespørsel akseptert, autentisert, autorisert, takstbegrenset og rutet.
• Modelanropsspenn: leverandør, modell, drift, tokenbruk, responsstatus og ventetid.
• Hentingspenn: indekssøkt, dokument-ID-er eller hashet-ID-er, antall deler, forsinkelse for henting og delt konteksttoken.
• Verktøyanropsspenn: verktøynavn, status, ventetid, feilklasse og bivirkningsklassifisering.
• Forsøk på nytt: Prøv på nytt årsak, forsøksnummer, leverandørstatus og inkrementell kostnad.
• Reservespan: original modell, reservemodell, trigger, kompatibilitetspolicy og endelig resultat.
• Rekkverk eller modereringsområde: policy påberopt, beslutning, etiketter og om utdata ble blokkert eller transformert.
• Etterbehandlingsspenn: JSON-validering, skjemareparasjon, henvisningskontroller eller endelig formatering.

Det overordnede spennet skal ha stabile korrelasjonsidentifikatorer. Barnespennene skal ha normaliserte tekniske egenskaper. Bruksreskontroen skal inneholde holdbare fakturerings- og analyseoppføringer. Unngå å tvinge all informasjon inn i beregningsetiketter; verdier med høy kardinalitet som leietaker-ID-er, prompt-hasher og dokument-ID-er er bedre lagret i spor, logger eller reskontrotabeller og deretter aggregert i dashboards.

Normaliser metadataene som fanges opp på hvert LLM-anrop

Hver modellforespørsel skal produsere en konsistent registrering, uavhengig av leverandør. Det nøyaktige skjemaet vil variere, men et praktisk minimum ser slik ut:

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "tenant_id": "tenant_123",
  "team_id": "team_456",
  "app_id": "support_bot",
  "gateway_key_id": "key_789",
  "operation": "chat",
  "provider": "leverandørnavn",
  "model": "leverandør-modell-id",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "fullført",
  "error_class": null,
  "latency_ms": 1842,
  "input_tokens": 2110,
  "output_tokens": 384,
  "cached_input_tokens": 1200,
  "estimated_cost_usd": "0,00492",
  "final_billed_cost_usd": null,
  "finish_reason": "stopp",
  "retry_count": 0,
  "fallback_used": usant,
  "content_capture_policy": "bare metadata"
}

Hold to ideer atskilt: telemetri forklarer hva som skjedde, mens bruksreskontro registrerer hva som skal belastes, avstemmes og rapporteres. De refererer til hverandre med forespørsels-IDer og sporings-IDer, men de trenger ikke å bo i samme lagringssystem.

Bygg en token og kostnadsbok, ikke bare tellere

Tokentellere er nyttige for diagrammer, men de er ikke nok for fakturering eller hendelsesundersøkelse. En hovedbok skal representere tilstandsoverganger. Opprett en rad når gatewayen godtar en forespørsel, og oppdater den etter hvert som forespørselen skrider frem.

Nyttige reskontrostatuser

• godkjent: autentisering og policysjekker bestått.
• videresendt: forespørselen ble sendt til en leverandør.
• streaming: leverandøren begynte å returnere tokens.
• fullført: svaret ble fullført.
• user_aborted: klienten koblet fra før fullføring.
• Prøvd på nytt: Det ble gjort et ekstra forsøk fra leverandøren.
• fallback_used: en annen modell eller leverandør ble valgt etter feil eller samsvar med retningslinjer.
• mislyktes: forespørselen ble avsluttet uten et brukbart svar.
• avstemt: leverandørsiden bruk eller kostnadsdata ble sammenlignet og brukt.

Denne tilstandsmodellen hjelper til med å fange opp vanlige fakturerings- og analysefeil: strømmede svar der klienten ble koblet fra, forsøk på nytt som ble belastet av leverandøren, men skjult for brukeren, reservebaner som talte feil modell, og bufferregnskapsforskjeller på tvers av leverandører.

Bruk OpenTelemetry GenAI-konvensjoner, og forleng deretter forsiktig

OpenTelemetry GenAI semantiske konvensjoner gir et bærbart vokabular for modelloperasjoner. Bruk disse konvensjonene for vanlige attributter som operasjonsnavn, leverandør, modell, forespørselsparametere, årsaker til svaravslutning, tokenbruk og feilstatus der de gjelder.

Imidlertid vil ikke leverandørnøytrale konvensjoner dekke alle forretningsdimensjoner i en gateway. Legg til gateway-eide attributter eller hovedbokkolonner for:

• leie-ID, team-ID, forhandlerkunde-ID og app-ID;
• gateway API-nøkkel-ID og nøkkelomfang;
• faktureringsplan, forbruksgrense og budsjettpolicy;
• modellalias og rutingpolicyversjon;
• spørsmåls-ID og ledetekstversjon;
• arbeidsflytnavn og arbeidsflyttrinn;
• estimert kostnad, endelig fakturert kostnad og avstemmingsstatus.

Avveiningen er kardinalitet. Disse feltene er verdifulle for undersøkelser, men de kan gjøre beregninger dyre og støyende hvis de brukes som metriske etiketter overalt. En praktisk regel er: aggregater med lav kardinalitet går til beregninger; identifikatorer med høy kardinalitet går til spor, logger og reskontro.

Design sikker melding og utdatalogging

Full rask logging gjør feilsøking enklere, men det øker personvern, samsvar, lagring og eksponering for innsiderisiko. Den sikrere standarden er metadata-first observability.

Standard: bare metadata

For det meste av produksjonstrafikk, lagre:

• spør mal-ID og versjon;
• hasher av normaliserte meldinger og utganger;
• antall for input, output, bufret og konteksttoken;
• navn på svarskjema og valideringsresultat;
• sikkerhetsetiketter og policybeslutninger;
• feilsammendrag og leverandørfeilklasser;
• hentingsmetadata, ikke rådokumenter.

Velg: kontrollert innholdsfangst

Hvis du trenger rått eller redigert innhold for dyp feilsøking, må du kreve en eksplisitt policy. Gode kontroller inkluderer miljøgodkjenningslister, samtykke fra leietakere, prøvetaking, maksimal nyttelastlengde, automatisk redaksjon, korte oppbevaringsvinduer, kryptering, rollebasert tilgang, revisjonslogger og en godkjenningsbane for sensitive hendelser.

Ikke behandle redaksjon som perfekt. Det reduserer risiko; det eliminerer det ikke. For regulerte eller høysensitive arbeidsbelastninger bør du vurdere å lagre bare hashes og avspillingsproblemer i en syntetisk sele med godkjente testdata.

Legg til RAG-observerbarhet som et eget lag

Generering med utvidet gjenfinning kan endre både kvalitet og kostnad. Logging bare det endelige modellkallet skjuler grunnårsaken når retrieveren returnerer for mange biter, foreldede dokumenter eller irrelevant kontekst.

For hvert gjenopprettingstrinn, ta opp:

• indeks eller samlingsnavn;
• hentingsstrategi og innebyggingsmodell;
• dokument-ID-er eller hashet-ID-er;
• bitantall og totalt konteksttokens;
• forsinkelse for henting;
• toppscorefordeling, hvis tilgjengelig;
• siteringsdekning;
• om hentet kontekst ble brukt i det endelige svaret.

Dette lar deg skille "modellen ble verre" fra "retrieveren begynte å sende lav kvalitet eller overdreven kontekst." Det hjelper også med å identifisere arbeidsflyter der konteksttokens dominerer totalkostnaden.

Avstem gatewaybruk med leverandørfakturering

Gateway-anslag er tilgjengelig umiddelbart. Faktureringsdata på leverandørsiden er vanligvis tregere, men mer autoritative. Bruk begge deler.

En daglig avstemmingsjobb bør sammenligne gateway-reskontrorader med leverandørbruks-APIer, kostnads-APIer, dashbordeksporter eller fakturaeksporter. Grupper deltas etter leverandør, modell, prosjekt og tidsvindu. Spor forskjeller separat for inndatatokener, utdatatokens, bufrede tokens, antall forespørsler og kostnader.

Vanlige avstemmingsforskjeller

• Strøming kobles fra: gatewayen kan se en avbrutt klient mens leverandøren fortsatt fakturerer genererte tokens.
• Forsøk på nytt: Flere forsøk kan bli fakturert selv om bare ett endelig svar returneres.
• Promptbufring: Leverandører kan eksponere bufret-token-kontoer annerledes.
• Avrunding: Små forskjeller per forespørsel kan bli synlige i skala.
• Batch- eller nivårabatter: Leverandørfakturaer kan gjelde priser som sanntidsanslaget ikke kjente ennå.
• Endringer på leverandørsiden: modellpriser, tokeniseringsatferd eller faktureringseksport kan endres over tid.

Når avstemming finner et delta, unngå å stille overskriving av hovedboken. Lagre det opprinnelige estimatet, den leverandøravstemte verdien, avstemmingskilden og årsakskoden hvis kjent.

Dashboards som svarer på operasjonelle spørsmål

Start dashbord fra leserproblemer, ikke forfengelighetsmålinger. Nyttige visninger inkluderer:

• kostnad per leietaker, team, app og arbeidsflyt;
• kostnad per vellykket oppgave, ikke bare kostnad per forespørsel;
• p50, p95 og p99 latens etter leverandør, modell og modellalias;
• reservefrekvens og forsøk på nytt etter rute;
• tidsavbruddsfrekvens og leverandørfeilklassetrender;
• cache-treffforhold og cache-token-spareanslag;
• feilfrekvens for strukturert utdatavalidering;
• toppmeldingsversjoner etter feilbudsjettbrenning;
• RAG-konteksttokendeling etter arbeidsflyt;
• rekkverksblokker og klassifiseringstreff med prompt-injeksjon.

For varsling, kombiner tekniske og forretningssignaler. En plutselig økning i leietakerforbruket kan være mer presserende enn en liten global ventetidsøkning. Et fallback rate-hopp etter en modellaliasendring kan indikere et kompatibilitetsproblem. Gjentatte 401-, 429- eller 5xx-svar kan peke på viktige problemer, kvotebruk eller ustabil leverandør.

Minimal implementeringsflyt for en OpenAI-kompatibel proxy

For en /chat/completions proxy kan flyten være enkel:

1. Motta forespørselen og tilordne request_id og spore kontekst.
2. Autentiser gatewaynøkkelen og finn ut om leietaker, team, app og policyomfang.
3. Opprett det overordnede gatewayområdet.
4. Opprett en hovedbokrad med status accepted.
5. Løs modellalias til leverandørmodell og rutingpolicyversjon.
6. Record metadata: operasjon, ledetekstmal-ID, skjemanavn, ledeteksthash og retningslinjer for innholdsfangst.
7. Start modellanropsspennet med GenAI semantiske attributter der det er aktuelt.
8. Videresend forespørselen til den valgte leverandøren.
9. For strømming, oppdater tilstanden når den første delen kommer og tell bruk så nøyaktig som leverandørens svar tillater.
10. Parse leverandørbruk, årsak til slutt, status og feilklasse ved fullføring.
11. Oppdater hovedboken med tokens, estimert kostnad, gjentatte forsøk/reservedetaljer og endelig forespørselsstatus.
12. Send ut beregninger fra hovedboken og spenndata.
13. Kjør daglig avstemming og butikkleverandørbekreftet kostnad separat fra det opprinnelige anslaget.

Sjekkliste for utrulling

• Definer kanoniske forespørsels-ID-er og sporings-ID-er.
• Bruk OpenTelemetry GenAI-attributter for vanlig modelltelemetri.
• Opprett en gateway-bruksbok med forespørselstilstandsoverganger.
• Normaliser leverandør-, modell-, modellalias-, leietaker-, app- og arbeidsflytdimensjoner.
• Hold undersøkelsesdata med høy kardinalitet borte fra beregningsetiketter.
• Gjør rå melding og utdatafangst deaktivert som standard.
• Legg til eksplisitte retningslinjer for sampling, redaksjon, oppbevaring og tilgangskontroll.
• Fang inn metadata for RAG-arbeidsflyt.
• Bygg oversikter for kostnader, ventetid, pålitelighet, validering og leietakeratferd.
• Forene gateway-estimater med leverandørbruk og kostnadseksport.
• Varsel om forbrukstopper, forsinkelsesregresjoner, reservehopp, valideringsfeil og sikkerhetsrelevante hendelser.

Konklusjon

En multi-modell gateway er det rette stedet for å implementere LLM observerbarhet fordi den ser forespørsler før de når noen leverandør og kan legge ved forretningskontekst som leverandørene ikke kjenner. Den sterkeste designen er ikke «logg alt». Det er en lagdelt modell: leverandørnøytrale spor for utførelse, en holdbar token og kostnadsbok for fakturering, leietakeranalyse for styring, RAG-metadata for gjenfinningskvalitet og personvern-første loggføring for sikker feilsøking.

Start med metadata, tilstandsoverganger og avstemming. Legg til innholdsfangst bare når policy-, oppbevarings- og tilgangskontrollene er klare. Denne sekvensen gir utviklere bevisene de trenger for å feilsøke ventetid, kvalitet og forbruk uten å gjøre observerbarhet til en ny dataeksponeringsrisiko.

Relatert lesing

• retries-API og fallback-adferd href="https://model-gate.com/en/blog/cut-llm-api-costs-batch-jobs-prompt-caching-5/">promptbufring og batchkostnadskontrollmønstre
• FAQ

  Ofte stilte spørsmål

  Bør en LLM-gateway lagre rå meldinger og utdata for observerbarhet?

  Ikke som standard. Lagre metadata, forespørselsmal-IDer, hashes, tokenantall, skjemanavn, sikkerhetsetiketter og feilsammendrag først. Rå eller redigert innholdsfangst skal være opt-in, samplet, kort oppbevaring, tilgangskontrollert og revidert.

  Hvorfor bruke både spor og bruksreskontro?

  Spor forklarer hvordan en forespørsel beveget seg gjennom gatewayen, leverandøranrop, henting, verktøy, gjenforsøk og rekkverk. En bruksreskontro registrerer varige fakturerings- og analysefakta som forespørselsstatus, tokenbruk, estimerte kostnader, avstemte kostnader, leietaker og modellattribusjon.

  Hvor ofte bør gatewaybruk avstemmes med leverandørfaktureringsdata?

  Daglig avstemming er et praktisk utgangspunkt. Sanntids gateway-estimater er nyttige for dashbord og grenser, mens leverandørbruks-APIer eller eksporter hjelper til med å korrigere forskjeller forårsaket av strømmingsavbrudd, gjenforsøk, bufret token-regnskap, rabatter, avrunding eller faktureringsendringer.

  Hvor bør felt med høy kardinalitet som leietaker-ID eller prompt-hash lagres?

  Hold høykardinalitetsfelt i spor, logger eller hovedboktabeller. Bruk aggregater med lavere kardinalitet for måleinstrumentbord for å unngå dyre eller støyende metriske serier.