LLM-Beobachtbarkeit in einem Multi-Modell-API-Gateway: Traces, Token-Ledger, Mandantenanalyse und sichere Eingabeaufforderungsprotokollierung

Aggregierte Anfragezahlen und monatliche Ausgaben reichen nicht aus, wenn ein Kunde fragt, warum ein Workflow gestern langsamer, teurer oder weniger zuverlässig geworden ist. Ein API-Gateway mit mehreren Modellen kann diese Frage beantworten, wenn es die Beobachtbarkeit als Teil der Kontrollebene behandelt: Jede Anfrage erhält einen Trace, jeder Modellaufruf aktualisiert ein Nutzungsbuch, jeder Mandant und Workflow ist zuordenbar und vertrauliche Inhalte sind standardmäßig geschützt.

Dieser Artikel beschreibt ein praktisches Design für KI-Nutzungsanalysen und LLM-Beobachtbarkeit in einem Gateway, das mehrere Anbieter über eine OpenAI-kompatible API bedient. Das Muster ist auch dann nützlich, wenn Sie keinen bestimmten Anbieter verwenden: Instrumentierung einmal am Gateway, Normalisierung der Modelltelemetrie, Beibehaltung der Abrechnungszuordnung und Erfassung von Eingabeaufforderungsinhalten nur unter expliziter Richtlinie.

Das Leserproblem: „Welcher Mandant, welches Modell, welche Eingabeaufforderung oder welcher Abrufpfad hat die Änderung verursacht?“

Die meisten Teams stehen irgendwann vor der gleichen Debugging-Lücke. Anwendungsprotokolle zeigen, dass eine Funktion fehlgeschlagen ist. Anbieter-Dashboards zeigen, dass die Token-Nutzung zugenommen hat. Die Finanzabteilung sieht eine Rechnung. Keine dieser Ansichten allein erklärt den vollständigen Pfad von der Mieteranfrage über den Modellaufruf bis zum Abrufkontext und dem erneuten Versuch, die in Rechnung gestellten Kosten anzuzeigen.

Das Ziel ist kein weiteres Dashboard mit der Gesamtzahl der Token. Ziel ist es, betriebliche Fragen zu beantworten wie:

• Welcher Mandant oder API-Schlüssel hat einen Ausgabenanstieg verursacht?
• Hat sich die Latenz erhöht, nachdem sich ein Modellalias geändert hat?
• Sind Wiederholungsversuche oder Fallbacks mit Kosten verbunden, die doppelt gezählt werden?
• Welche Eingabeaufforderungsversion verbraucht das meiste Fehlerbudget?
• Wurde ein RAG-Workflow teuer, weil beim Abrufen zu viele Kontext-Tokens hinzugefügt wurden?
• Kann das Debuggen eines Vorfalls unterstützt werden, ohne private Benutzeraufforderungen zu lesen?

Fakten, Empfehlungen und Vorhersagen

Fakten: OpenTelemetry dokumentiert semantische Konventionen und Attribute der generativen KI für Modelloperationen, einschließlich Operationsnamen wie Chat, Generate_Content und Text_Completion. In derselben Dokumentation wird davor gewarnt, dass GenAI-Eingabe- und Ausgabenachrichtenattribute vertrauliche Informationen oder PII enthalten können und möglicherweise gefiltert oder gekürzt werden müssen. Große Modellanbieter stellen auch Nutzungs-Dashboards, APIs oder Exporte zur Verfügung, die den anbieterseitigen Abgleich unterstützen können, obwohl die Details je nach Anbieter unterschiedlich sind.

Empfehlungen: Verwenden Sie OpenTelemetry für anbieterneutrale Traces, behalten Sie jedoch Gateway-eigene Geschäftsdimensionen in Ihren eigenen Attributen und Hauptbüchern bei. Speichern Sie standardmäßig keine rohen Eingabeaufforderungen oder Ausgaben. Speichern Sie zuerst Metadaten, Hashes, Token-Anzahl, Eingabeaufforderungsvorlagen-IDs, Schemanamen, Fehlerklassen und Sicherheitskennzeichnungen. Fügen Sie die Inhaltserfassung nur als optionale, zugriffskontrollierte Debugging-Funktion mit kurzer Aufbewahrungszeit hinzu.

Vorhersage: Bei der LLM-Beobachtbarkeit wird es weniger um isolierte Anbieter-Dashboards als vielmehr um anbieterübergreifende Steuerungsebenen gehen. Die Teams erwarten einen Ort, an dem sie Latenz, Kosten, Qualität, Richtlinienereignisse, Mieterverhalten und Abrechnungsunterschiede modellübergreifend untersuchen können.

Referenzarchitektur: Beobachten Sie den gesamten Anforderungspfad

Ein Gateway kann den gesamten Anforderungslebenszyklus sehen, ohne dass jedes Anwendungsteam benutzerdefinierte Telemetriedaten erstellen muss. Ein nützliches Ablaufverfolgungsmodell beginnt mit einem übergeordneten Bereich für die eingehende Kundenanfrage und untergeordneten Bereichen für die Schritte, die sich auf Kosten, Latenz und Qualität auswirken.

Empfohlene Span-Struktur

• Gateway-Anfragespanne: Anfrage akzeptiert, authentifiziert, autorisiert, ratenbegrenzt und weitergeleitet.
• Modellaufrufspanne: Anbieter, Modell, Vorgang, Token-Nutzung, Antwortstatus und Latenz.
• Abrufspanne: abgefragter Index, Dokument-IDs oder Hash-IDs, Blockanzahl, Abruflatenz und Kontext-Token-Freigabe.
• Werkzeugaufrufspanne: Werkzeugname, Status, Latenz, Fehlerklasse und Nebeneffektklassifizierung.
• Wiederholungsspanne: Wiederholungsgrund, Versuchsnummer, Anbieterstatus und inkrementelle Kosten.
• Fallback-Spanne: Originalmodell, Fallback-Modell, Auslöser, Kompatibilitätsrichtlinie und Endergebnis.
• Leitplanke oder Moderationsspanne: aufgerufene Richtlinie, Entscheidung, Bezeichnungen und ob die Ausgabe blockiert oder transformiert wurde.
• Nachbearbeitungsbereich: JSON-Validierung, Schemareparatur, Zitationsprüfungen oder endgültige Formatierung.

Der übergeordnete Bereich sollte stabile Korrelationskennungen tragen. Die untergeordneten Bereiche sollten normalisierte technische Attribute aufweisen. Das Nutzungsbuch sollte dauerhafte Abrechnungs- und Analyseaufzeichnungen enthalten. Vermeiden Sie es, alle Informationen in Kennzahlenbezeichnungen zu zwängen. Werte mit hoher Kardinalität wie Mandanten-IDs, Eingabeaufforderungs-Hashes und Dokument-IDs werden besser in Traces, Protokollen oder Hauptbuchtabellen gespeichert und dann in Dashboards aggregiert.

Normalisieren Sie die bei jedem LLM-Aufruf erfassten Metadaten

Jede Modellanfrage sollte einen konsistenten Datensatz erzeugen, unabhängig vom Anbieter. Das genaue Schema variiert, aber ein praktisches Minimum sieht so aus:

{
  „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“,
  „Anbieter“: „Anbietername“,
  „model“: „provider-model-id“,
  „model_alias“: „fast-support-chat“,
  „prompt_template_id“: „refund_policy_v5“,
  „prompt_hash“: „sha256:…“,
  „response_schema“: „support_answer_v2“,
  „Status“: „abgeschlossen“,
  „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“: „stopp“,
  „retry_count“: 0,
  „fallback_used“: false,
  „content_capture_policy“: „metadata_only“

Behalten Sie zwei Ideen getrennt: Die Telemetrie erklärt, was passiert ist, während das Nutzungsbuch aufzeichnet, was berechnet, abgeglichen und gemeldet werden soll. Sie verweisen mit Anforderungs-IDs und Trace-IDs aufeinander, müssen sich jedoch nicht im selben Speichersystem befinden.

Erstellen Sie ein Token- und Kostenbuch, nicht nur Zähler

Token-Zähler sind für Diagramme nützlich, für die Abrechnung oder Untersuchung von Vorfällen reichen sie jedoch nicht aus. Ein Hauptbuch sollte Zustandsübergänge darstellen. Erstellen Sie eine Zeile, wenn das Gateway eine Anfrage akzeptiert, und aktualisieren Sie sie dann, während die Anfrage fortschreitet.

Nützliche Ledger-Status

• akzeptiert: Authentifizierung und Richtlinienprüfungen bestanden.
• weitergeleitet: Die Anfrage wurde an einen Anbieter gesendet.
• Streaming: Der Anbieter hat mit der Rückgabe von Token begonnen.
• abgeschlossen: die Antwort wurde erfolgreich abgeschlossen.
• user_aborted: Der Client hat die Verbindung vor Abschluss getrennt.
• Wiederholung: Es wurde ein weiterer Provider-Versuch unternommen.
• fallback_used: Nach einem Fehler oder einer Richtlinienübereinstimmung wurde ein anderes Modell oder ein anderer Anbieter ausgewählt.
• fehlgeschlagen: Die Anfrage wurde ohne eine brauchbare Antwort beendet.
• abgeglichen: Anbieterseitige Nutzungs- oder Kostendaten wurden verglichen und angewendet.

Dieses Zustandsmodell hilft dabei, häufige Abrechnungs- und Analysefehler zu erkennen: gestreamte Antworten, bei denen der Client die Verbindung getrennt hat, Wiederholungsversuche, die vom Anbieter in Rechnung gestellt, aber für den Benutzer verborgen wurden, Fallback-Pfade, die das falsche Modell gezählt haben, und Unterschiede bei der Cache-Abrechnung zwischen den Anbietern.

Verwenden Sie die OpenTelemetry GenAI-Konventionen und erweitern Sie sie dann sorgfältig

Die semantischen Konventionen von OpenTelemetry GenAI bieten ein portables Vokabular für Modelloperationen. Verwenden Sie diese Konventionen für allgemeine Attribute wie Vorgangsname, Anbieter, Modell, Anforderungsparameter, Gründe für das Ende der Antwort, Token-Nutzung und Fehlerstatus, wo sie gelten.

Anbieterneutrale Konventionen decken jedoch nicht alle Geschäftsdimensionen in einem Gateway ab. Fügen Sie Gateway-eigene Attribute oder Ledger-Spalten hinzu für:

• Mandanten-ID, Team-ID, Reseller-Kunden-ID und App-ID;
• Gateway-API-Schlüssel-ID und Schlüsselbereich;
• Abrechnungsplan, Ausgabenlimit und Budgetrichtlinie;
• Modellalias und Routing-Richtlinienversion;
• Prompt-Vorlagen-ID und Prompt-Version;
• Workflow-Name und Workflow-Schritt;
• Geschätzte Kosten, endgültig in Rechnung gestellte Kosten und Abgleichsstatus.

Der Kompromiss ist Kardinalität. Diese Felder sind für die Untersuchung wertvoll, aber sie können Metriken teuer und verrauscht machen, wenn sie überall als Metrikbezeichnungen verwendet werden. Eine praktische Regel lautet: Aggregate mit niedriger Kardinalität gehen zu Metriken; Bezeichner mit hoher Kardinalität werden in Traces, Protokolle und Hauptbücher eingefügt.

Entwerfen Sie eine sichere Eingabeaufforderungs- und Ausgabeprotokollierung

Eine vollständige Eingabeaufforderungsprotokollierung erleichtert das Debuggen, erhöht jedoch den Datenschutz, die Compliance, die Speicherung und die Gefährdung durch Insider. Der sicherere Standard ist die Metadaten-erste Beobachtbarkeit.

Standard: nur Metadaten

Speichern Sie für den meisten Produktionsverkehr:

• Prompt-Vorlagen-ID und -Version;
• Hashes normalisierter Eingabeaufforderungen und Ausgaben;
• Eingabe-, Ausgabe-, zwischengespeicherte und Kontext-Token-Zählungen;
• Name des Antwortschemas und Validierungsergebnis;
• Sicherheitskennzeichnungen und Richtlinienentscheidungen;
• Fehlerzusammenfassungen und Anbieterfehlerklassen;
• Metadaten abrufen, keine Rohdokumente.

Opt-in: kontrollierte Inhaltserfassung

Wenn Sie rohe oder redigierte Inhalte für ein umfassendes Debugging benötigen, benötigen Sie eine explizite Richtlinie. Zu den guten Kontrollen gehören Umgebungszulassungslisten, Zustimmung des Mieters, Stichprobenentnahme, maximale Nutzlastlänge, automatische Schwärzung, kurze Aufbewahrungsfenster, Verschlüsselung, rollenbasierter Zugriff, Prüfprotokolle und ein Break-Glass-Genehmigungspfad für sensible Vorfälle.

Behandeln Sie die Redaktion nicht als perfekt. Es reduziert das Risiko; es beseitigt es nicht. Erwägen Sie bei regulierten oder hochsensiblen Arbeitslasten, nur Hashes zu speichern und Probleme in einem synthetischen Kabelbaum mit genehmigten Testdaten wiederzugeben.

RAG-Beobachtbarkeit als separate Ebene hinzufügen

Eine durch Abruf erweiterte Generierung kann sowohl die Qualität als auch die Kosten verändern. Durch die Protokollierung nur des letzten Modellaufrufs wird die Grundursache ausgeblendet, wenn der Retriever zu viele Blöcke, veraltete Dokumente oder irrelevanten Kontext zurückgibt.

Erfassen Sie für jeden Abrufschritt Folgendes:

• Index- oder Sammlungsname;
• Abrufstrategie und Einbettungsmodell;
• Dokument-IDs oder Hash-IDs;
• Chunk-Anzahl und Gesamtkontext-Tokens;
• Abruflatenz;
• Top-Score-Verteilung, falls verfügbar;
• Zitatberichterstattung;
• ob der abgerufene Kontext in der endgültigen Antwort verwendet wurde.

Dadurch können Sie „das Modell wurde schlechter“ von „der Retriever begann, minderwertigen oder übermäßigen Kontext zu senden“ unterscheiden. Es hilft auch dabei, Arbeitsabläufe zu identifizieren, bei denen Kontext-Tokens die Gesamtkosten dominieren.

Gateway-Nutzung mit der Anbieterabrechnung abgleichen

Gateway-Schätzungen sind sofort verfügbar. Abrechnungsdaten auf Anbieterseite sind in der Regel langsamer, aber aussagekräftiger. Benutzen Sie beides.

Ein täglicher Abgleichsjob sollte Gateway-Ledger-Zeilen mit Anbieternutzungs-APIs, Kosten-APIs, Dashboard-Exporten oder Rechnungsexporten vergleichen. Gruppieren Sie Deltas nach Anbieter, Modell, Projekt und Zeitfenster. Verfolgen Sie Unterschiede separat für Eingabe-Tokens, Ausgabe-Tokens, zwischengespeicherte Tokens, Anforderungsanzahlen und Kosten.

Häufige Abstimmungsunterschiede

• Streaming-Unterbrechungen: Das Gateway erkennt möglicherweise einen abgebrochenen Client, während der Anbieter weiterhin generierte Token in Rechnung stellt.
• Wiederholungen: Mehrere Versuche können in Rechnung gestellt werden, auch wenn nur eine letzte Antwort zurückgegeben wird.
• Promptes Caching: Anbieter können die Abrechnung zwischengespeicherter Token unterschiedlich offenlegen.
• Rundung: Kleine Unterschiede pro Anfrage können im Maßstab sichtbar werden.
• Stapel- oder Staffelrabatte: Anbieterrechnungen können Preise enthalten, die der Echtzeitschätzung noch nicht bekannt waren.
• Änderungen auf Anbieterseite: Modellpreise, Tokenisierungsverhalten oder Abrechnungsexporte können sich im Laufe der Zeit ändern.

Wenn bei der Abstimmung ein Delta festgestellt wird, vermeiden Sie, Ihr Hauptbuch stillschweigend zu überschreiben. Speichern Sie die ursprüngliche Schätzung, den vom Anbieter abgeglichenen Wert, die Abgleichsquelle und den Ursachencode, falls bekannt.

Dashboards, die betriebliche Fragen beantworten

Starten Sie Dashboards anhand von Leserproblemen, nicht anhand von Vanity-Metriken. Zu den nützlichen Ansichten gehören:

• Kosten pro Mandant, Team, App und Workflow;
• Kosten pro erfolgreicher Aufgabe, nicht nur Kosten pro Anfrage;
• p50-, p95- und p99-Latenz nach Anbieter, Modell und Modellalias;
• Fallback-Rate und Wiederholungsrate nach Route;
• Timeout-Rate und Anbieterfehlerklassentrends;
• Cache-Trefferquote und geschätzte Einsparungen bei den zwischengespeicherten Token;
• Fehlerquote bei der Validierung strukturierter Ausgaben;
• Top-Prompt-Versionen nach Fehlerbudgetverbrennung;
• RAG-Kontext-Token-Freigabe nach Workflow;
• Leitplankenblöcke und Prompt-Injection-Klassifikatortreffer.

Für die Alarmierung kombinieren Sie technische und geschäftliche Signale. Ein plötzlicher Anstieg der Mieterausgaben kann dringlicher sein als ein kleiner globaler Anstieg der Latenz. Ein Anstieg der Fallback-Rate nach einer Modell-Alias-Änderung kann auf ein Kompatibilitätsproblem hinweisen. Wiederholte 401-, 429- oder 5xx-Antworten können auf wichtige Probleme, Kontingentausschöpfung oder Anbieterinstabilität hinweisen.

Minimaler Implementierungsablauf für einen OpenAI-kompatiblen Proxy

Für einen /chat/completions-Proxy kann der Ablauf einfach sein:

1. Empfangen Sie die Anfrage und weisen Sie request_id zu und verfolgen Sie den Kontext.
2. Authentifizieren Sie den Gateway-Schlüssel und lösen Sie Mandanten-, Team-, App- und Richtlinienbereich auf.
3. Erstellen Sie den übergeordneten Gateway-Bereich.
4. Erstellen Sie eine Hauptbuchzeile mit dem Status akzeptiert.
5. Modellalias in Anbietermodell und Routing-Richtlinienversion auflösen.
6. Metadaten aufzeichnen: Vorgang, Eingabeaufforderungsvorlagen-ID, Schemaname, Eingabeaufforderungs-Hash und Inhaltserfassungsrichtlinie.
7. Starten Sie die Modellaufrufspanne gegebenenfalls mit semantischen GenAI-Attributen.
8. Leiten Sie die Anfrage an den ausgewählten Anbieter weiter.
9. Aktualisieren Sie beim Streaming den Status, wenn der erste Block eintrifft, und zählen Sie die Nutzung so genau, wie es die Anbieterantwort zulässt.
10. Parsen Sie nach Abschluss die Anbieternutzung, den Abschlussgrund, den Status und die Fehlerklasse.
11. Aktualisieren Sie das Hauptbuch mit Tokens, geschätzten Kosten, Wiederholungs-/Fallback-Details und dem endgültigen Anforderungsstatus.
12. Metriken aus den Ledger- und Span-Daten ausgeben.
13. Führen Sie einen täglichen Abgleich durch und speichern Sie die vom Anbieter bestätigten Kosten getrennt von der ursprünglichen Schätzung.

Rollout-Checkliste

• Definieren Sie kanonische Anforderungs-IDs und Trace-IDs.
• Übernehmen Sie OpenTelemetry GenAI-Attribute für allgemeine Modelltelemetrie.
• Erstellen Sie ein Gateway-Nutzungsbuch mit Anforderungsstatusübergängen.
• Normalisieren Sie die Dimensionen Anbieter, Modell, Modellalias, Mandant, App und Workflow.
• Halten Sie Untersuchungsdaten mit hoher Kardinalität von Metrikbezeichnungen fern.
• Machen Sie die Roheingabeaufforderung und die Ausgabeerfassung standardmäßig deaktiviert.
• Fügen Sie explizite Richtlinien für Sampling, Schwärzung, Aufbewahrung und Zugriffskontrolle hinzu.
• Abrufmetadaten für RAG-Workflows erfassen.
• Erstellen Sie Dashboards für Kosten, Latenz, Zuverlässigkeit, Validierung und Mandantenverhalten.
• Gateway-Schätzungen mit Anbieternutzung und Kostenexporten abgleichen.
• Warnung bei Ausgabenspitzen, Latenzrückgängen, Fallback-Sprüngen, Validierungsfehlern und sicherheitsrelevanten Ereignissen.

Schlussfolgerung

Ein Multi-Modell-Gateway ist der richtige Ort für die Implementierung der LLM-Beobachtbarkeit, da es Anfragen sieht, bevor sie einen Anbieter erreichen, und Geschäftskontext anhängen kann, den Anbieter nicht kennen. Das stärkste Design ist nicht „alles protokollieren“. Es handelt sich um ein mehrschichtiges Modell: anbieterneutrale Traces für die Ausführung, ein dauerhaftes Token und Kostenbuch für die Abrechnung, Mandantenanalysen für die Governance, RAG-Metadaten für die Abrufqualität und datenschutzorientierte Eingabeaufforderungsprotokollierung für sicheres Debuggen.

Beginnen Sie mit Metadaten, Zustandsübergängen und Abgleich. Fügen Sie die Inhaltserfassung erst hinzu, wenn die Richtlinien, die Aufbewahrung und die Zugriffskontrollen bereit sind. Diese Sequenz liefert Entwicklern den Beweis, den sie zum Debuggen von Latenz, Qualität und Ausgaben benötigen, ohne dass die Beobachtbarkeit zu einem neuen Risiko für die Offenlegung von Daten wird.

Verwandte Lektüre

• Wiederholungs- und Fallbackverhalten beim LLM-API-Routing
• Prompt-Caching- und Batch-Kostenkontrollmuster
• Team API-Schlüsselverwaltung und Ausgabenlimits