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

Samlet antall forespørsler og månedlige forbruk er ikke nok når en kunde spør hvorfor en arbeidsflyt ble tregere, dyrere eller mindre pålitelig i går. En flermodell 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-observerbarhet 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. Applikasjonslogger viser at en funksjon mislyktes. Leverandørdashbord viser at tokenbruken økte. Finans ser en regning. Ingen av disse visningene i seg selv forklarer den fullstendige 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?
• Økte ventetiden etter at et modellalias ble endret?
• Teller nye forsøk eller reserver kostnadene?
• 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, generate_content og text_completion. 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å bruksoversikter, 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 forventer ett sted for å undersøke ventetid, kostnader, kvalitet, policy-hendelser, 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, ventetid og kvalitet.

Anbefalt spennstruktur

• Gateway request span: request accepted, authenticated, authorized, rate-limited, and routed.
• Modell call span: leverandør, modell, drift, tokenbruk, responsstatus og latens.
• Hentingspenn: indekssøkt, dokument-ID-er eller hashet-ID-er, antall deler, forsinkelse for henting og del av konteksttoken.
• Tool call span: verktøynavn, status, latens, feilklasse og bivirkningsklassifisering.
• Forsøk på nytt: årsak til forsøk, forsøksnummer, leverandørstatus og inkrementell kostnad.
• Fallback span: 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 varige 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 lagres bedre i spor, logger eller reskontrotabeller og samles deretter til dashboards.

Normaliser metadataene som registreres ved hvert LLM-anrop

Hver modellforespørsel bør 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": "provider_name",
  "model": "provider-model-id",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "completed",
  "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": "stop",
  "retry_count": 0,
  "fallback_used": false,
  "content_capture_policy": "metadata_only"
}

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 hovedboktilstander

• accepted: 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øvet på nytt: et ekstra forsøk fra leverandør ble gjort.
• fallback_used: en annen modell eller leverandør ble valgt etter feil eller samsvar med retningslinjer.
• failed: forespørselen ble avsluttet uten et brukbart svar.
• avstemt: bruks- eller kostnadsdata fra leverandørsiden ble sammenlignet og brukt.

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

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:

• leietaker-ID, team-ID, forhandlerkunde-ID og app-ID;
• gateway API nøkkel-ID og nøkkelomfang;
• faktureringsplan, forbruksgrense og budsjettpolicy;
• versjon av modellalias og rutingpolicy;
• spørsmålsmal-ID og promptversjon;
• navn på arbeidsflyt 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 hovedbøker.

Design sikker melding og utdatalogging

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

Standard: bare metadata

For mesteparten av produksjonstrafikken, butikk:

• spørsmålsmal-ID og versjon;
• hasher av normaliserte meldinger og utdata;
• antall for input, output, bufret og konteksttoken;
• navn på svarskjema og valideringsresultat;
• sikkerhetsetiketter og retningslinjer for beslutninger;
• 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 redigering 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

Generasjon med utvidet henting 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 gjenfinningstrinn, 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 fra leverandørsiden er vanligvis tregere, men mer autoritative. Bruk begge.

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 visste 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 forfengelighetsberegninger. 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;
• trender for tidsavbrudd og leverandørfeilklasse;
• cache hit ratio og cache-token spareberegning;
• feilfrekvens for strukturert utdatavalidering;
• toppmeldingsversjoner etter feilbudsjettbrenning;
• deling av RAG-konteksttoken etter arbeidsflyt;
• rekkverksblokker og klassifiseringstreff med prompt-injeksjon.

For å varsle, kombinere tekniske og forretningsmessige signaler. 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å nøkkelproblemer, kvotebruk eller ustabilitet hos leverandøren.

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 spor 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 tilstand accepted.
5. Løs modellalias til leverandørmodell og versjon av rutingpolicy.
6. Record metadata: operasjon, ledetekstmal-ID, skjemanavn, prompt-hash 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 bruken så nøyaktig som leverandørens svar tillater.
10. Parse leverandørbruk, fullføringsårsak, 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 telemetrimodell.
• Opprett en gatewaybruksreskontro 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 henting av RAG-arbeidsflyter.
• Bygg oversikter for kostnader, ventetid, pålitelighet, validering og leietakeratferd.
• Avstem gatewayanslag med leverandørbruk og kostnadseksport.
• Varsel om forbrukstopper, forsinkelsesregresjoner, reservehopp, valideringsfeil og sikkerhetsrelevante hendelser.

Konklusjon

En gateway med flere modeller er det rette stedet å implementere LLM-observabilitet 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 varig token og kostnadsbok for fakturering, leietakeranalyse for styring, RAG-metadata for gjenfinningskvalitet og personvern-første meldingslogging 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

• forsøk på nytt og reserveadferd i LLM API routing
• promptkostnadskontroll og batchkostnadskontroll mønstre
• teamAPI nøkkeladministrasjon og forbruksgrenser