LLM-observbarhet i en API-gateway med flera modeller: spår, tokenreskontra, hyresgästanalys och säker loggning

Aggregerat antal förfrågningar och månatliga utgifter räcker inte när en kund frågar varför ett arbetsflöde blev långsammare, dyrare eller mindre tillförlitligt igår. En API-gateway för flera modeller kan besvara den frågan om den behandlar observerbarhet som en del av kontrollplanet: varje begäran får ett spår, varje modellanrop uppdaterar en användningsreskontra, varje hyresgäst och arbetsflöde kan tillskrivas och känsligt innehåll skyddas som standard.

Den här artikeln beskriver en praktisk design för AI-användningsanalys och LLM-observerbarhet i en gateway som frontar flera leverantörer genom ett OpenAI-kompatibelt API. Mönstret är användbart även om du inte använder någon specifik leverantör: instrument en gång vid gatewayen, normalisera modelltelemetri, bevara faktureringsattribution och fånga upp promptinnehåll endast under explicit policy.

Läsarproblemet: "Vilken hyresgäst, modell, uppmaning eller hämtningsväg orsakade förändringen?"

De flesta team möter så småningom samma felsökningsgap. Programloggar visar att en funktion misslyckades. Providers instrumentpaneler visar att tokenanvändningen ökade. Finans ser en räkning. Ingen av dessa åsikter förklarar i sig hela vägen från hyresgästbegäran till modellanrop till hämtningskontext för att försöka igen till fakturerad kostnad.

Målet är inte en annan instrumentpanel med totalt antal tokens. Målet är att svara på operativa frågor som:

• Vilken klient eller API-nyckel orsakade en utgiftsökning?
• Har latensen ökat efter att ett modellalias ändrats?
• Dubbelräknar kostnaden för omförsök eller reservförsök?
• Vilken promptversion förbränner mest felbudget?
• Blev ett RAG-arbetsflöde dyrt eftersom hämtning lade till för många kontexttokens?
• Kan stödja felsökning av en incident utan att läsa meddelanden från privata användare?

Fakta, rekommendationer och förutsägelser

Fakta: OpenTelemetry dokumenterar generativa AI-semantiska konventioner och attribut för modelloperationer, inklusive operationsnamn som chatt, generera_innehåll och textkomplettering. Samma dokumentation varnar för att GenAI in- och utgående meddelandeattribut kan innehålla känslig information eller PII och kan kräva filtrering eller trunkering. Stora modellleverantörer avslöjar också användningsöversikter, API:er eller exporter som kan stödja avstämning på leverantörssidan, även om detaljerna skiljer sig åt mellan olika leverantörer.

Rekommendationer: Använd OpenTelemetry för leverantörsneutrala spår, men behåll gatewayägda affärsdimensioner i dina egna attribut och reskontra. Lagra inte råa uppmaningar eller utdata som standard. Lagra metadata, hash, tokenantal, promptmall-ID:n, schemanamn, felklasser och säkerhetsetiketter först. Lägg bara till innehållsfångst som en opt-in, åtkomstkontrollerad, kortvarig felsökningsfunktion.

Prognos: LLM-observbarhet kommer att bli mindre om isolerade leverantörsinstrumentpaneler och mer om kontrollplan över leverantörer. Team kommer att förvänta sig ett ställe för att undersöka latens, kostnad, kvalitet, policyhändelser, hyresgästers beteende och faktureringsdelta mellan olika modeller.

Referensarkitektur: observera hela sökvägen för begäran

En gateway kan se hela begärans livscykel utan att varje applikationsteam behöver bygga anpassad telemetri. En användbar spårningsmodell börjar med ett överordnat intervall för den inkommande kundförfrågan och underordnade intervall för de steg som påverkar kostnad, latens och kvalitet.

Rekommenderad spännstruktur

• Gateway-begäran: begäran accepterad, autentiserad, auktoriserad, hastighetsbegränsad och dirigerad.
• Modellsamtalsintervall: leverantör, modell, drift, tokenanvändning, svarsstatus och latens.
• Hämtningsintervall: indexsökt, dokument-ID eller hashade ID:n, antal bitar, hämtningsfördröjning och kontext-tokenandel.
• Verktygsanropsspann: verktygets namn, status, latens, felklass och biverkningsklassificering.
• Försöksintervall igen: Försök igen anledning, försöksnummer, leverantörsstatus och inkrementell kostnad.
• Reservspann: originalmodell, reservmodell, trigger, kompatibilitetspolicy och slutresultat.
• Räcke eller modereringsområde: anropad policy, beslut, etiketter och om utdata blockerades eller omvandlades.
• Omfång efter bearbetning: JSON-validering, schemareparation, citeringskontroller eller slutlig formatering.

Det överordnade spannet bör ha stabila korrelationsidentifierare. De underordnade intervallen ska ha normaliserade tekniska attribut. Användningsreskontran bör innehålla hållbara fakturerings- och analysposter. Undvik att tvinga in all information i måttenhetsetiketter; värden med hög kardinalitet som hyresgäst-ID, prompthaschar och dokument-ID:n lagras bättre i spår, loggar eller reskontratabeller och aggregeras sedan i instrumentpaneler.

Normalisera metadata som samlas in vid varje LLM-samtal

Varje modellförfrågan bör ge en konsekvent post, oavsett leverantör. Det exakta schemat kommer att variera, men ett praktiskt minimum ser ut så här:

{
  "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": "chatta",
  "provider": "leverantörsnamn",
  "model": "leverantör-modell-id",
  "model_alias": "snabb-support-chatt",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "avslutad",
  "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": "sluta",
  "retry_count": 0,
  "fallback_used": false,
  "content_capture_policy": "metadata_only"
}

Håll två idéer åtskilda: telemetri förklarar vad som hände, medan användningsreskontra registrerar vad som ska debiteras, stämmas av och rapporteras. De refererar till varandra med begäran-ID och spårnings-ID, men de behöver inte bo i samma lagringssystem.

Skapa en token och kostnadsbok, inte bara räknare

Tokenräknare är användbara för diagram, men de räcker inte för fakturering eller incidentutredning. En reskontra ska representera tillståndsövergångar. Skapa en rad när gatewayen accepterar en begäran och uppdatera den sedan när begäran fortskrider.

Användbara reskontratillstånd

• accepterat: autentisering och policykontroller godkända.
• vidarebefordrat: begäran skickades till en leverantör.
• strömning: leverantören började returnera tokens.
• slutfört: svaret avslutades.
• user_aborted: klienten kopplades bort innan den slutfördes.
• försökte igen: ett ytterligare försök från leverantören gjordes.
• fallback_used: en annan modell eller leverantör valdes efter misslyckande eller policymatchning.
• misslyckades: begäran avslutades utan ett användbart svar.
• avstämd: leverantörssidans användning eller kostnadsdata jämfördes och tillämpades.

Denna tillståndsmodell hjälper till att fånga upp vanliga fakturerings- och analysfel: strömmade svar där klienten kopplade bort, försök igen som debiterades av leverantören men gömdes för användaren, reservvägar som räknade fel modell och skillnader i cache-redovisning mellan leverantörer.

Använd OpenTelemetry GenAI-konventioner och förläng sedan försiktigt

OpenTelemetry GenAI semantiska konventioner tillhandahåller en bärbar vokabulär för modelloperationer. Använd dessa konventioner för vanliga attribut som operationsnamn, leverantör, modell, förfrågningsparametrar, skäl för svarsslut, tokenanvändning och felstatus där de gäller.

Men leverantörsneutrala konventioner täcker inte alla affärsdimensioner i en gateway. Lägg till gatewayägda attribut eller reskontrakolumner för:

• gäst-ID, team-ID, återförsäljares kund-ID och app-ID;
• gateway API-nyckel-ID och nyckelomfång;
• faktureringsplan, utgiftsgräns och budgetpolicy;
• version av modellalias och routingpolicy;
• promptmall-ID och promptversion;
• arbetsflödesnamn och arbetsflödessteg;
• uppskattad kostnad, slutlig fakturerad kostnad och avstämningsstatus.

Avvägningen är kardinalitet. Dessa fält är värdefulla för undersökning, men de kan göra mätvärden dyra och bullriga om de används som metriska etiketter överallt. En praktisk regel är: aggregat med låg kardinalitet går till mätvärden; identifierare med hög kardinalitet går till spår, loggar och reskontra.

Design säker prompt och utdataloggning

Fullständig loggning gör det lättare att felsöka, men det ökar integritet, efterlevnad, lagring och exponering för insiderrisker. Den säkrare standarden är metadata-first observability.

Standard: endast metadata

För den mesta produktionstrafiken, lagra:

• fråga mall-ID och version;
• hashar för normaliserade uppmaningar och utgångar;
• antal indata, utdata, cachade och kontexttoken;
• svarsschemanamn och valideringsresultat;
• säkerhetsetiketter och policybeslut;
• felsammanfattningar och leverantörsfelklasser;
• metadata för hämtning, inte rådokument.

Välj in: kontrollerad innehållsfångst

Om du behöver rått eller redigerat innehåll för djupfelsökning måste du kräva en tydlig policy. Bra kontroller inkluderar miljötillståndslistor, hyresgästs samtycke, provtagning, maximal nyttolastlängd, automatisk redaktion, korta lagringsfönster, kryptering, rollbaserad åtkomst, granskningsloggar och en väg för godkännande av känsliga incidenter.

Behandla inte redigering som perfekt. Det minskar risken; det eliminerar det inte. För reglerade eller högkänsliga arbetsbelastningar bör du överväga att endast lagra hash- och uppspelningsproblem i en syntetisk sele med godkända testdata.

Lägg till RAG-observbarhet som ett separat lager

Hämtningsförstärkt generation kan förändra både kvalitet och kostnad. Loggning endast av det slutliga modellanropet döljer grundorsaken när retrievern returnerar för många bitar, inaktuella dokument eller irrelevant kontext.

Fånga in:

• index eller samlingsnamn;
• hämtningsstrategi och inbäddningsmodell;
• dokument-ID eller hashade ID:n;
• antal bitar och totala sammanhangstokens;
• hämtningsfördröjning;
• fördelning av högsta poäng, om tillgänglig;
• citat täckning;
• om det hämtade sammanhanget användes i det slutliga svaret.

Detta låter dig skilja "modellen blev sämre" från "retrievern började skicka låg kvalitet eller överdrivet sammanhang." Det hjälper också att identifiera arbetsflöden där kontexttokens dominerar den totala kostnaden.

Avstämma gatewayanvändning med leverantörsfakturering

Gateway-uppskattningar är tillgängliga omedelbart. Faktureringsdata från leverantörssidan är vanligtvis långsammare men mer auktoritativ. Använd båda.

Ett dagligt avstämningsjobb bör jämföra gateway-reskontrarader med API:er för leverantörsanvändning, kostnads-API:er, instrumentpanelsexporter eller fakturaexporter. Gruppera delta efter leverantör, modell, projekt och tidsfönster. Spåra skillnader separat för indatatoken, utdatatoken, cachade tokens, antal begäranden och kostnad.

Vanliga avstämningsskillnader

• Streaming kopplas från: gatewayen kan se en avbruten klient medan leverantören fortfarande fakturerar genererade tokens.
• Återförsök: flera försök kan faktureras även om endast ett slutligt svar returneras.
• Prompt cachning: leverantörer kan exponera cachad token-konton på olika sätt.
• Avrundning: små skillnader per begäran kan bli synliga i skala.
• Sats- eller nivårabatter: Leverantörsfakturor kan tillämpa prissättning som realtidsuppskattningen inte kände till ännu.
• Ändringar på leverantörssidan: modellprissättning, tokeniseringsbeteende eller faktureringsexport kan ändras över tiden.

När avstämning hittar ett delta, undvik att tyst skriva över din reskontra. Lagra den ursprungliga uppskattningen, det leverantörsavstämda värdet, avstämningskällan och orsakskoden om den är känd.

Dashboards som svarar på operativa frågor

Börja instrumentpaneler från läsarproblem, inte fåfänga mätvärden. Användbara vyer inkluderar:

• kostnad per hyresgäst, team, app och arbetsflöde;
• kostnad per framgångsrik uppgift, inte bara kostnad per begäran;
• p50, p95 och p99 latens efter leverantör, modell och modellalias;
• reservfrekvens och försök igen per rutt;
• trender för tidsgräns och leverantörsfelklass;
• cacheträffförhållande och cachad token-besparingsuppskattning;
• felfrekvens för strukturerad utdatavalidering;
• bästa promptversioner efter felbudgetbränning;
• RAG-kontexttokendelning efter arbetsflöde;
• räckesblock och snabbinsprutningsklassificeringsträffar.

För varning, kombinera tekniska och affärssignaler. En plötslig ökning av utgifterna för hyresgäster kan vara mer brådskande än en liten global fördröjningsökning. Ett fallback-hastighetshopp efter en modellaliasändring kan indikera ett kompatibilitetsproblem. Upprepade 401-, 429- eller 5xx-svar kan peka på nyckelproblem, uttömning av kvoter eller instabilitet hos leverantören.

Minimalt implementeringsflöde för en OpenAI-kompatibel proxy

För en /chat/completions proxy kan flödet vara enkelt:

1. Ta emot begäran och tilldela request_id och spåra sammanhang.
2. Autentisera gatewaynyckeln och avgöra omfattningen av klient, team, app och policy.
3. Skapa det överordnade gateway-intervallet.
4. Skapa en redovisningsrad med status accepted.
5. Lös modellalias till leverantörsmodell och routingpolicyversion.
6. Spela in metadata: operation, promptmall-ID, schemanamn, prompthash och policy för innehållsfångst.
7. Starta modellanropsintervallet med GenAI semantiska attribut där så är tillämpligt.
8. Vidarebefordra begäran till den valda leverantören.
9. För streaming, uppdatera tillståndet när den första delen anländer och räkna användningen så exakt som leverantörens svar tillåter.
10. När det är klart, analysera leverantörsanvändning, slutorsak, status och felklass.
11. Uppdatera reskontran med tokens, beräknad kostnad, återförsök/reservinformation och slutlig begäran om status.
12. Skicka ut mätvärden från redovisningen och spanndata.
13. Kör daglig avstämning och lagra leverantörsbekräftad kostnad separat från den ursprungliga uppskattningen.

Checklista för utrullning

• Definiera kanoniska begärande-ID:n och spårnings-ID:n.
• Anta OpenTelemetry GenAI-attribut för vanlig modelltelemetri.
• Skapa en gateway-användningsreskontra med övergångar av begäranstillstånd.
• Normalisera leverantörs-, modell-, modellalias-, klient-, app- och arbetsflödesdimensioner.
• Håll undersökningsdata med hög kardinalitet från mätetiketter.
• Gör rå prompt och utdatainsamling inaktiverad som standard.
• Lägg till explicita policyer för sampling, redigering, lagring och åtkomstkontroll.
• Hämta metadata för RAG-arbetsflöden.
• Skapa instrumentpaneler för kostnad, latens, tillförlitlighet, validering och klientbeteende.
• Sammanställ gatewayuppskattningar med leverantörsanvändning och kostnadsexport.
• Varning om utgiftstoppar, latensregressioner, reservhopp, valideringsfel och säkerhetsrelevanta händelser.

Slutsats

En gateway med flera modeller är rätt ställe att implementera LLM-observerbarhet eftersom den ser förfrågningar innan de når någon leverantör och kan bifoga affärskontext som leverantörerna inte känner till. Den starkaste designen är inte "logga allt". Det är en skiktad modell: leverantörsneutrala spår för exekvering, en hållbar token och kostnadsbok för fakturering, hyresgästanalys för styrning, RAG-metadata för hämtningskvalitet och loggning av integritetsförst för säker felsökning.

Börja med metadata, tillståndsövergångar och avstämning. Lägg bara till innehållsfångst när policyn, lagringen och åtkomstkontrollerna är klara. Den sekvensen ger utvecklare de bevis som de behöver för att felsöka latens, kvalitet och spendera utan att förvandla observerbarhet till en ny risk för dataexponering.

Relaterad läsning

• retries-API och fallback
href="https://model-gate.com/en/blog/cut-llm-api-costs-batch-jobs-prompt-caching-5/">mönstren för promptcaching och batchkostnadskontroll
• FAQ

  Vanliga frågor

  Bör en LLM-gateway lagra råa uppmaningar och utdata för observerbarhet?

  Inte som standard. Lagra metadata, promptmall-ID, hash, tokenantal, schemanamn, säkerhetsetiketter och felsammanfattningar först. Rått eller redigerat innehållsfångst ska vara opt-in, sampling, kortlagring, åtkomstkontrollerad och granskad.

  Varför använda både spår och en användningsreskontra?

  Spår förklarar hur en förfrågan rörde sig genom gatewayen, leverantörssamtal, hämtning, verktyg, återförsök och skyddsräcken. En användningsreskontra registrerar varaktiga fakturerings- och analysfakta såsom begäranstillstånd, tokenanvändning, uppskattad kostnad, avstämd kostnad, hyresgäst och modelltillskrivning.

  Hur ofta ska gatewayanvändning stämmas av med leverantörsfaktureringsdata?

  Daglig avstämning är en praktisk utgångspunkt. Uppskattningar av gateway i realtid är användbara för instrumentpaneler och gränser, medan API:er eller exporter för leverantörsanvändning hjälper till att korrigera skillnader som orsakas av strömningsavbrott, återförsök, cachad token-redovisning, rabatter, avrundning eller faktureringsändringar.

  Var ska fält med hög kardinalitet som hyresgäst-ID eller snabbhash lagras?

  Håll fält med hög kardinalitet i spår, loggar eller reskontratabeller. Använd aggregat med lägre kardinalitet för mätinstrumentpaneler för att undvika dyra eller bullriga mätserier.