LLM-waarneembaarheid in een API-gateway met meerdere modellen: traceringen, tokengrootboeken, huurderanalyses en veilige promptregistratie

Het totale aantal verzoeken en de maandelijkse uitgaven zijn niet voldoende als een klant vraagt ​​waarom een ​​workflow gisteren langzamer, duurder of minder betrouwbaar werd. Een multi-model API-gateway kan die vraag beantwoorden als de waarneembaarheid als onderdeel van het controlevlak wordt behandeld: elk verzoek krijgt een tracering, elke modelaanroep werkt een gebruiksgrootboek bij, elke tenant en workflow is toewijsbaar en gevoelige inhoud wordt standaard beschermd.

Dit artikel beschrijft een praktisch ontwerp voor AI-gebruiksanalyse en LLM-waarneming in een gateway die meerdere providers ondersteunt via een OpenAI-compatibele API. Het patroon is zelfs nuttig als u geen specifieke leverancier gebruikt: instrumenteer één keer bij de gateway, normaliseer modeltelemetrie, behoud factureringsattributie en leg promptinhoud alleen vast onder expliciet beleid.

Het probleem met de lezer: 'Welke tenant, model, prompt of ophaalpad heeft de wijziging veroorzaakt?'

De meeste teams worden uiteindelijk geconfronteerd met dezelfde foutopsporingskloof. Uit toepassingslogboeken blijkt dat een functie is mislukt. Providerdashboards laten zien dat het tokengebruik is toegenomen. Financiën ziet een wetsvoorstel. Geen van deze weergaven verklaart op zichzelf het volledige pad van het huurderverzoek naar de modelaanroep, de ophaalcontext en de nieuwe poging tot de gefactureerde kosten.

Het doel is niet nog een dashboard met totaal aantal tokens. Het doel is om operationele vragen te beantwoorden zoals:

• Welke tenant of API sleutel veroorzaakte een uitgavenpiek?
• Is de latentie toegenomen nadat een modelalias is gewijzigd?
• Zijn nieuwe pogingen of fallbacks dubbeltelling van kosten?
• Welke promptversie verbrandt het meeste foutenbudget?
• Is een RAG-workflow duur geworden omdat het ophalen te veel contexttokens toevoegde?
• Kan ondersteuning voor het debuggen van een incident zonder de aanwijzingen van privégebruikers te lezen?

Feiten, aanbevelingen en voorspellingen

Feiten: OpenTelemetry documenteert generatieve AI-semantische conventies en attributen voor modelbewerkingen, inclusief bewerkingsnamen zoals chat, generate_content en text_completion. Dezelfde documentatie waarschuwt dat GenAI-invoer- en uitvoerberichtkenmerken gevoelige informatie of PII kunnen bevatten en mogelijk moeten worden gefilterd of ingekort. Grote modelaanbieders bieden ook gebruiksdashboards, API's of exports aan die afstemming aan de providerzijde kunnen ondersteunen, hoewel de details per provider verschillen.

Aanbevelingen: Gebruik OpenTelemetry voor providerneutrale traceringen, maar bewaar bedrijfsdimensies die eigendom zijn van de gateway in uw eigen attributen en grootboeken. Sla standaard geen onbewerkte aanwijzingen of uitvoer op. Bewaar eerst metagegevens, hashes, tokenaantallen, promptsjabloon-ID's, schemanamen, foutklassen en veiligheidslabels. Voeg het vastleggen van inhoud alleen toe als een opt-in, toegangsgecontroleerde foutopsporingsfunctie met korte bewaartijd.

Voorspelling: De waarneembaarheid van LLM zal minder gaan over geïsoleerde dashboards van providers en meer over controlevlakken tussen verschillende providers. Teams verwachten dat er één plek is waar ze latentie, kosten, kwaliteit, beleidsgebeurtenissen, tenantgedrag en factureringsverschillen in verschillende modellen kunnen onderzoeken.

Referentiearchitectuur: bekijk het hele verzoekpad

Een gateway kan de volledige levenscyclus van verzoeken bekijken zonder dat elk applicatieteam aangepaste telemetrie hoeft te bouwen. Een nuttig traceringsmodel begint met één bovenliggende reeks voor het binnenkomende klantverzoek en onderliggende reeksen voor de stappen die van invloed zijn op de kosten, latentie en kwaliteit.

Aanbevolen overspanningsstructuur

• Gatewayverzoekbereik: verzoek geaccepteerd, geverifieerd, geautoriseerd, met beperkte snelheid en gerouteerd.
• Modelaanroepomvang: provider, model, bewerking, tokengebruik, reactiestatus en latentie.
• Ophaalduur: opgevraagde index, document-ID's of gehashte ID's, aantal chunks, vertraging bij het ophalen en delen van contexttokens.
• Tool call span: toolnaam, status, latentie, foutklasse en classificatie van bijwerkingen.
• Repogingsperiode: reden van nieuwe poging, aantal pogingen, providerstatus en extra kosten.
• Fallback-spanne: origineel model, fallback-model, trigger, compatibiliteitsbeleid en eindresultaat.
• Guardrail- of moderatiebereik: beleid aangeroepen, beslissing, labels en of de uitvoer is geblokkeerd of getransformeerd.
• Naverwerkingsperiode: JSON validatie, schemareparatie, citatiecontroles of uiteindelijke opmaak.

De bovenliggende reeks moet stabiele correlatie-ID's bevatten. De onderliggende overspanningen moeten genormaliseerde technische kenmerken hebben. Het gebruiksgrootboek moet duurzame facturerings- en analysegegevens bevatten. Vermijd het forceren van alle informatie in statistische labels; Waarden met een hoge kardinaliteit, zoals tenant-ID's, prompt-hashes en document-ID's, kunnen beter worden opgeslagen in traceringen, logboeken of grootboektabellen en vervolgens worden samengevoegd in dashboards.

Normaliseer de metagegevens die bij elke LLM-oproep worden vastgelegd

Elk modelverzoek moet een consistent record opleveren, ongeacht de provider. Het exacte schema kan variëren, maar een praktisch minimum ziet er als volgt uit:

{
  "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"
}

Houd twee ideeën gescheiden: telemetrie legt uit wat er is gebeurd, terwijl het gebruiksgrootboek registreert wat er in rekening moet worden gebracht, afgestemd en gerapporteerd. Ze verwijzen naar elkaar met verzoek-ID's en trace-ID's, maar ze hoeven niet in hetzelfde opslagsysteem te wonen.

Maak een token- en kostengrootboek, niet alleen tellers

Tokentellers zijn nuttig voor diagrammen, maar zijn niet voldoende voor facturering of incidentonderzoek. Een grootboek moet staatsovergangen vertegenwoordigen. Maak een rij wanneer de gateway een verzoek accepteert en update deze naarmate het verzoek vordert.

Handige grootboekstatussen

• geaccepteerd: verificatie- en beleidscontroles geslaagd.
• doorgestuurd: het verzoek is verzonden naar een provider.
• streaming: de provider begon tokens terug te sturen.
• voltooid: het antwoord is succesvol voltooid.
• user_aborted: de client heeft de verbinding verbroken voordat deze voltooid was.
• opnieuw geprobeerd: er is een extra providerpoging gedaan.
• fallback_used: er is een ander model of andere provider geselecteerd na een fout of beleidsovereenkomst.
• mislukt: het verzoek eindigde zonder een bruikbaar antwoord.
• afgestemd: gebruiks- of kostengegevens aan de providerzijde werden vergeleken en toegepast.

Dit statusmodel helpt bij het opsporen van veelvoorkomende facturerings- en analysefouten: gestreamde reacties waarbij de client de verbinding verbrak, pogingen om opnieuw te proberen die in rekening zijn gebracht door de provider maar verborgen zijn voor de gebruiker, reservepaden die het verkeerde model telden en verschillen in cacheboekhouding tussen providers.

Gebruik OpenTelemetry GenAI-conventies en breid ze vervolgens voorzichtig uit

OpenTelemetry GenAI semantische conventies bieden een draagbare woordenschat voor modelbewerkingen. Gebruik deze conventies voor algemene kenmerken, zoals de naam van de bewerking, de provider, het model, de aanvraagparameters, de redenen voor het voltooien van de respons, het tokengebruik en de foutstatus waar ze van toepassing zijn.

Provider-neutrale conventies zullen echter niet elke bedrijfsdimensie in een gateway dekken. Voeg attributen of grootboekkolommen toe die eigendom zijn van de gateway voor:

• Tenant-ID, team-ID, klant-ID van de reseller en app-ID;
• gateway API sleutel-ID en sleutelbereik;
• factureringsplan, bestedingslimiet en budgetbeleid;
• modelalias en routeringsbeleidsversie;
• promptsjabloon-ID en promptversie;
• workflownaam en workflowstap;
• geschatte kosten, uiteindelijk gefactureerde kosten en afstemmingsstatus.

De afweging is kardinaliteit. Deze velden zijn waardevol voor onderzoek, maar kunnen meetgegevens duur en luidruchtig maken als ze overal als meetlabels worden gebruikt. Een praktische regel is: aggregaten met een lage kardinaliteit gaan naar metrieken; ID's met een hoge kardinaliteit gaan naar traceringen, logboeken en grootboeken.

Ontwerp veilige prompt- en uitvoerregistratie

Volledige registratie van prompts maakt foutopsporing eenvoudiger, maar vergroot de privacy, compliance, opslag en blootstelling aan insiderrisico's. De veiligere standaard is dat metadata eerst waarneembaar zijn.

Standaard: alleen metadata

Voor het meeste productieverkeer slaat u op:

• promptsjabloon-ID en -versie;
• hashes van genormaliseerde aanwijzingen en uitvoer;
• Aantallen van invoer-, uitvoer-, cache- en contexttokens;
• naam van het antwoordschema en validatieresultaat;
• veiligheidslabels en beleidsbeslissingen;
• foutoverzichten en foutklassen van providers;
• Metagegevens ophalen, geen onbewerkte documenten.

Aanmelden: gecontroleerde inhoudregistratie

Als je onbewerkte of geredigeerde inhoud nodig hebt voor diepgaande foutopsporing, heb je een expliciet beleid nodig. Goede controles omvatten toelatingslijsten voor de omgeving, toestemming van huurders, steekproeven, maximale lengte van de payload, automatische redactie, korte bewaarperioden, versleuteling, op rollen gebaseerde toegang, auditlogboeken en een goedkeuringspad voor gevoelige incidenten.

Beschouw redactie niet als perfect. Het vermindert het risico; het elimineert het niet. Voor gereguleerde of zeer gevoelige werkbelastingen kunt u overwegen alleen hashes op te slaan en problemen opnieuw af te spelen in een synthetisch harnas met goedgekeurde testgegevens.

Voeg RAG-waarneembaarheid toe als een afzonderlijke laag

Generering door middel van ophalen kan zowel de kwaliteit als de kosten veranderen. Door alleen de laatste modelaanroep te loggen, wordt de hoofdoorzaak verborgen wanneer de retriever te veel chunks, verouderde documenten of irrelevante context retourneert.

Vul voor elke ophaalstap het volgende vast:

• index- of collectienaam;
• ophaalstrategie en inbeddingsmodel;
• document-ID's of gehashte ID's;
• aantal segmenten en totaal aantal contexttokens;
• ophaallatentie;
• distributie van de topscore, indien beschikbaar;
• citatiedekking;
• of de opgehaalde context is gebruikt in het uiteindelijke antwoord.

Hiermee kun je onderscheid maken tussen 'het model werd slechter' en 'de retriever begon context van lage kwaliteit of buitensporige context te verzenden'. Het helpt ook bij het identificeren van workflows waarbij contexttokens de totale kosten domineren.

Gatewaygebruik afstemmen op facturering via provider

Gatewayschattingen zijn onmiddellijk beschikbaar. Factureringsgegevens aan de providerzijde zijn doorgaans langzamer, maar gezaghebbender. Gebruik beide.

Bij een dagelijkse afstemmingstaak moeten gatewaygrootboekrijen worden vergeleken met API's voor providergebruik, API's voor kosten, dashboardexports of factuurexports. Groepeer delta's op provider, model, project en tijdvenster. Houd verschillen afzonderlijk bij voor invoertokens, uitvoertokens, tokens in het cachegeheugen, aantal verzoeken en kosten.

Gemeenschappelijke afstemmingsverschillen

• Streaming wordt verbroken: de gateway ziet mogelijk een afgebroken client terwijl de provider de gegenereerde tokens nog steeds in rekening brengt.
• Opnieuw proberen: er kunnen meerdere pogingen in rekening worden gebracht, zelfs als er maar één laatste reactie wordt geretourneerd.
• Prompt caching: providers kunnen de boekhouding van tokens in de cache anders weergeven.
• Afronding: kleine verschillen per verzoek kunnen op schaal zichtbaar worden.
• Batch- of stapkortingen: op facturen van leveranciers kunnen prijzen van toepassing zijn die de realtime schatting nog niet kende.
• Wijzigingen aan de providerzijde: modelprijzen, tokenisatiegedrag of factureringsexports kunnen in de loop van de tijd veranderen.

Wanneer de afstemming een delta vindt, vermijd dan het stilzwijgend overschrijven van uw grootboek. Bewaar de oorspronkelijke schatting, de door de provider afgestemde waarde, de afstemmingsbron en de redencode, indien bekend.

Dashboards die operationele vragen beantwoorden

Start dashboards op basis van lezersproblemen, niet op basis van ijdelheidsstatistieken. Nuttige weergaven zijn onder meer:

• kosten per tenant, team, app en workflow;
• kosten per succesvolle taak, niet alleen de kosten per verzoek;
• p50-, p95- en p99-latentie per provider, model en modelalias;
• terugvalpercentage en percentage nieuwe pogingen per route;
• time-outpercentage en trends in providerfoutklassen;
• Cachehitratio en schatting van besparingen op gecachte tokens;
• Faalpercentage bij validatie van gestructureerde uitvoer;
• Top promptversies op basis van foutbudgetverbranding;
• RAG-contexttoken delen per workflow;
• vangrailblokken en classificatorhits met snelle injectie.

Combineer technische en zakelijke signalen voor waarschuwingen. Een plotselinge piek in de uitgaven van huurders kan urgenter zijn dan een kleine mondiale latentietoename. Een sprong in het terugvalpercentage na een wijziging van een modelalias kan duiden op een compatibiliteitsprobleem. Herhaalde 401-, 429- of 5xx-antwoorden kunnen wijzen op belangrijke problemen, uitputting van quota of instabiliteit van de provider.

Minimale implementatiestroom voor een OpenAI-compatibele proxy

Voor een /chat/completions proxy kan de stroom eenvoudig zijn:

1. Ontvang het verzoek en wijs request_id toe en traceer de context.
2. Authenticeer de gatewaysleutel en bepaal het bereik van de tenant, het team, de app en het beleid.
3. Maak de bovenliggende gatewayreeks.
4. Maak een grootboekrij met staat accepted.
5. Modelalias omzetten in providermodel en routeringsbeleidsversie.
6. Metagegevens vastleggen: bewerking, aanwijzingssjabloon-ID, schemanaam, aanwijzingshash en beleid voor het vastleggen van inhoud.
7. Start de modelaanroepreeks met behulp van semantische GenAI-kenmerken, waar van toepassing.
8. Stuur het verzoek door naar de geselecteerde provider.
9. Voor streaming: update de status wanneer het eerste deel arriveert en tel het gebruik zo nauwkeurig als de reactie van de provider toestaat.
10. Ontleed na voltooiing het gebruik van de provider, de reden, de status en de foutklasse.
11. Werk het grootboek bij met tokens, geschatte kosten, details over opnieuw proberen/terugvallen en de status van het definitieve verzoek.
12. Statistieken uit het grootboek en spangegevens verzenden.
13. Voer de dagelijkse afstemming uit en sla de door de provider bevestigde kosten afzonderlijk van de oorspronkelijke schatting op.

Checklist voor uitrol

• Definieer canonieke verzoek-ID's en trace-ID's.
• Gebruik OpenTelemetry GenAI-kenmerken voor algemene modeltelemetrie.
• Maak een grootboek voor gatewaygebruik met verzoekstatusovergangen.
• Normaliseer de dimensies van provider, model, modelalias, tenant, app en workflow.
• Houd onderzoeksgegevens met hoge kardinaliteit buiten de statistieklabels.
• Maak het vastleggen van onbewerkte prompts en uitvoer standaard uitgeschakeld.
• Voeg expliciet beleid toe voor steekproeven, redactie, bewaring en toegangscontrole.
• Vastleggen van metagegevens voor het ophalen van RAG-workflows.
• Bouw dashboards voor kosten, latentie, betrouwbaarheid, validatie en tenantgedrag.
• Recilieer gatewayschattingen met providergebruik en kostenexports.
• Waarschuwing bij uitgavenpieken, latentieregressies, terugvalsprongen, validatiefouten en veiligheidsrelevante gebeurtenissen.

Conclusie

Een gateway met meerdere modellen is de juiste plaats om LLM-waarneming te implementeren, omdat deze verzoeken ziet voordat deze een provider bereiken en zakelijke context kan koppelen die providers niet kennen. Het sterkste ontwerp is niet ‘alles loggen’. Het is een gelaagd model: provider-neutrale traces voor uitvoering, een duurzaam token- en kostengrootboek voor facturering, tenantanalyses voor beheer, RAG-metagegevens voor ophaalkwaliteit en privacy-first prompt-logboekregistratie voor veilig debuggen.

Begin met metadata, statusovergangen en afstemming. Voeg het vastleggen van inhoud alleen toe als het beleid, de retentie en de toegangscontrole gereed zijn. Deze reeks geeft ontwikkelaars het bewijs dat ze nodig hebben om latentie, kwaliteit en uitgaven te debuggen zonder waarneembaarheid te veranderen in een nieuw risico op gegevensblootstelling.

Gerelateerd leesgedrag

• opnieuw proberen en terugvalgedrag in LLM API routing
• prompt caching en batchkostencontrole patronen
• team API sleutelbeheer en bestedingslimieten