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

Het totaal aantal verzoeken en de maandelijkse uitgaven zijn niet voldoende als een klant vraagt ​​waarom een ​​workflow gisteren trager, duurder of minder betrouwbaar werd. Een API-gateway met meerdere modellen 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-observatie in een gateway die meerdere providers ondersteunt via een OpenAI-compatibele API. Het patroon is zelfs handig 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 tenantverzoek naar modelaanroep, naar ophaalcontext en nieuwe poging naar 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 dubbeltellingskosten?
• 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, genereer_content en text_completion. In dezelfde documentatie wordt gewaarschuwd dat GenAI-invoer- en uitvoerberichtkenmerken gevoelige informatie of PII kunnen bevatten en mogelijk moeten worden gefilterd of ingekort. Grote modelaanbieders stellen ook gebruiksdashboards, API's of exports beschikbaar 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 retentie.

Voorspelling: de waarneembaarheid van LLM zal minder gaan over geïsoleerde dashboards van providers en meer over controlevlakken tussen 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 aanvragen 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, in snelheid beperkt en gerouteerd.
• Modeloproepbereik: provider, model, werking, tokengebruik, reactiestatus en latentie.
• Ophaalduur: opgevraagde index, document-ID's of gehashte ID's, aantal chunks, vertraging bij het ophalen en delen van contexttokens.
• Tooloproepbereik: 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.
• Bewakings- of moderatiebereik: aangeroepen beleid, beslissing, labels en of de uitvoer is geblokkeerd of getransformeerd.
• Naverwerkingsperiode: JSON-validatie, schemareparatie, citatiecontroles of definitieve 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

Elke modelaanvraag moet een consistent record opleveren, ongeacht de provider. Het exacte schema zal 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": "ondersteuning_bot",
  "gateway_key_id": "key_789",
  "werking": "chatten",
  "provider": "provider_naam",
  "model": "provider-model-id",
  "model_alias": "snelle ondersteuningchat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "ondersteuning_antwoord_v2",
  "status": "voltooid",
  "error_class": null,
  "latency_ms": 1842,
  "invoer_tokens": 2110,
  "output_tokens": 384,
  "cached_input_tokens": 1200,
  "geschatte_kosten_usd": "0,00492",
  "final_billed_cost_usd": null,
  "finish_reason": "stoppen",
  "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 leven.

Bouw een token- en kostengrootboek op, niet alleen maar tellers

Tokentellers zijn handig voor grafieken, maar 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: authenticatie- 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 een andere provider geselecteerd na een fout of een beleidsmatch.
• mislukt: het verzoek is beëindigd 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 tot opnieuw proberen die door de provider in rekening zijn gebracht maar voor de gebruiker verborgen zijn, reservepaden die het verkeerde model telden en verschillen in cacheboekhouding tussen providers.

Gebruik de 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:

• huurder-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;
• werkstroomnaam en werkstroomstap;
• 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 het volgende op:

• sjabloon-ID en -versie vragen;
• 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;
• haal metagegevens op, geen onbewerkte documenten.

Opt-in: gecontroleerde opname van inhoud

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 bewaartermijnen, encryptie, 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 retrieval 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.

Leg voor elke ophaalstap het volgende vast:

• index- of collectienaam;
• ophaalstrategie en inbeddingsmodel;
• document-ID's of gehashte ID's;
• aantal fragmenten en totaal aantal contexttokens;
• ophaallatentie;
• Topscoreverdeling, 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.

Het gatewaygebruik afstemmen op de facturering aan de 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 de cache, aantal verzoeken en kosten.

Gemeenschappelijke afstemmingsverschillen

• Streaming wordt verbroken: de gateway ziet mogelijk een afgebroken client terwijl de provider de gegenereerde tokens nog steeds factureert.
• Opnieuw proberen: er kunnen meerdere pogingen in rekening worden gebracht, zelfs als er maar één definitieve 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 trapskortingen: leveranciersfacturen kunnen prijzen toepassen die de realtime schatting nog niet kende.
• Wijzigingen aan de providerzijde: modelprijzen, tokenisatiegedrag of factureringsexporten kunnen in de loop van de tijd veranderen.

Wanneer de afstemming een delta vindt, voorkom dan dat u uw grootboek stilletjes overschrijft. 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 de foutklasse van de provider;
• cachehitratio en geschatte besparingen op gecachte tokens;
• Faalpercentage gestructureerde uitvoervalidatie;
• toppromptversies op basis van fout budget burn;
• 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-reacties 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 het proces 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 de status geaccepteerd.
5. Modelalias omzetten in providermodel en routeringsbeleidsversie.
6. Metagegevens vastleggen: bewerking, promptsjabloon-ID, schemanaam, prompt-hash en beleid voor het vastleggen van inhoud.
7. Start de modelaanroepreeks met behulp van semantische attributen van GenAI, indien van toepassing.
8. Stuur het verzoek door naar de geselecteerde provider.
9. Voor streaming update je de status wanneer het eerste deel arriveert en tel je 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 de grootboek- en spangegevens verzenden.
13. Voer de dagelijkse afstemming uit en bewaar de door de provider bevestigde kosten afzonderlijk van de oorspronkelijke schatting.

Checklist voor de 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 onbewerkte prompts en het vastleggen van 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 huurdergedrag.
• Stem schattingen van de gateway af op het gebruik van de provider en de exportkosten.
• Waarschuwing bij uitgavenpieken, latentieregressies, terugvalsprongen, validatiefouten en veiligheidsrelevante gebeurtenissen.

Conclusie

Een gateway met meerdere modellen is de juiste plaats om LLM-observatie 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 sporen voor uitvoering, een duurzaam token- en kostengrootboek voor facturering, huurderanalyses 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 observatie te veranderen in een nieuw risico op gegevensblootstelling.

Gerelateerd leesgedrag

• gedrag bij nieuwe pogingen en terugval in LLM API-routing
• prompt caching- en batchkostenbeheersingspatronen
• team API-sleutelbeheer en uitgaven grenzen