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

Aggregerat antal begäranden 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 gateway med flera modeller API kan svara på 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 leder flera leverantörer genom en OpenAI-kompatibel 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 meddelandeinnehåll endast under explicit policy.

Läsarproblemet: "Vilken hyresgäst, modell, uppmaning eller hämtningsväg orsakade ä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 vyer i sig förklarar 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 hyresgäst eller API-nyckel orsakade en utgiftsökning?
• Ökade fördröjningen efter att ett modellalias ändrades?
• 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 sammanhangstokens?
• 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, generate_content och text_completion. 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 håll gatewayägda affärsdimensioner i dina egna attribut och redovisningar. 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-observabilitet kommer att bli mindre om isolerade leverantörsinstrumentpaneler och mer om kontrollplan för flera leverantörer. Teamen förväntar 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 livscykeln för begäran 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 spanstruktur

• Gateway request span: begäran accepterad, autentiserad, auktoriserad, hastighetsbegränsad och dirigerad.
• Modelsamtalsspann: leverantör, modell, operation, tokenanvändning, svarsstatus och latens.
• Hämtningspan: index efterfrågat, dokument-ID eller hashade ID:n, antal bitar, hämtningsfördröjning och kontext-tokenandel.
• Verktygsanropsspan: verktygsnamn, status, latens, felklass och biverkningsklassificering.
• Försöksintervall: Försök igen anledning, försöksnummer, leverantörsstatus och inkrementell kostnad.
• Fallback span: originalmodell, reservmodell, trigger, kompatibilitetspolicy och slutresultat.
• Guardrail eller moderation span: policy anropad, beslut, etiketter och om utdata blockerades eller omvandlades.
• Span efter bearbetning: JSON validering, schemareparation, citeringskontroller eller slutlig formatering.

Det överordnade intervallet bör ha stabila korrelationsidentifierare. De underordnade intervallen bör 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, prompt-haschar 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 modellbegäran bör ge en konsekvent registrering, 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": "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"
}

Håll två idéer åtskilda: telemetry 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ärande-ID:n och spårnings-ID:n, 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 reskontrastatus

• accepted: autentisering och policykontroller godkända.
• vidarebefordrad: begäran skickades till en leverantör.
• streaming: leverantören började returnera tokens.
• completed: svaret avslutades.
• user_aborted: klienten kopplades bort innan den slutfördes.
• försökte på nytt: ett ytterligare försök från leverantören gjordes.
• fallback_used: en annan modell eller leverantör valdes efter misslyckande eller policymatchning.
• failed: begäran avslutades utan ett användbart svar.
• avstämt: användnings- eller kostnadsdata från leverantörssidan 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 ger 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:

• hyresgäst-ID, team-ID, återförsäljarkund-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, butik:

• promptmall-ID och version;
• hashar av normaliserade uppmaningar och utdata;
• antal indata, utdata, cachelagrade och kontexttoken;
• svarsschemanamn och valideringsresultat;
• säkerhetsetiketter och policybeslut;
• felsammanfattningar och leverantörsfelklasser;
• hämtning av metadata, inte rådokument.

Välj: kontrollerad innehållsfångst

Om du behöver obearbetat eller redigerat innehåll för djupfelsökning måste du ha en uttrycklig policy. Bra kontroller inkluderar miljötillståndslistor, hyresgästs samtycke, sampling, maximal nyttolastlängd, automatisk redigering, korta lagringsfönster, kryptering, rollbaserad åtkomst, granskningsloggar och en godkännandesökväg för 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änd 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ör varje hämtningssteg, fånga:

• index eller samlingsnamn;
• hämtningsstrategi och inbäddningsmodell;
• dokument-ID eller hashade ID:n;
• chunk count och total context tokens;
• hämtningsfördröjning;
• fördelning av högsta poäng, om tillgänglig;
• citatbevakning;
• om hämtad kontext 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.

Sammanställ 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 kopplar ned: 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 caching: leverantörer kan exponera cachad token-konton på annat sätt.
• Avrundning: små skillnader per begäran kan bli synliga i skala.
• Sats- eller nivårabatter: leverantörsfakturor kan tillämpas på priser 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 känd.

Dashboards som svarar på operativa frågor

Börja instrumentpaneler från läsarproblem, inte fåfängavä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 cachelagd token-besparingsuppskattning;
• felfrekvens för validering av strukturerad utdata;
• bästa promptversioner efter felbudgetbränning;
• RAG-kontexttokendelning per 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å viktiga problem, uttömmande 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 version av routingpolicy.
6. Record metadata: operation, promptmall-ID, schemanamn, prompt-hash 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 kommer 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/återgångsinformation och slutlig begäranstillstånd.
12. Emit statistik från reskontran och span data.
13. Kör daglig avstämning och butiksleverantörsbekräftad kostnad separat från den ursprungliga uppskattningen.

Checklista för lansering

• Definiera kanoniska begärande-ID:n och spårnings-ID:n.
• Anta OpenTelemetry GenAI-attribut för vanlig telemetrimodell.
• Skapa en gatewayanvändningsreskontra med förfrågningstillståndsövergångar.
• Normalisera leverantörs-, modell-, modellalias-, klient-, app- och arbetsflödesdimensioner.
• Håll undersökningsdata med hög kardinalitet borta från mätvärdesetiketter.
• Gör rå prompt och output capture inaktiverade 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ärssammanhang 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 integritetsförst loggning 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 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

• försök igen och reservbeteende i LLM API routing
• prompt caching-kontroll och batchkostnadskontroll mönster
• teamAPI nyckelhantering och utgiftsgränser