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 ein OpenAI-kompatibles API verbindet. Das Muster ist auch dann nützlich, wenn Sie keinen bestimmten Anbieter verwenden: Instrumentieren Sie es einmal am Gateway, normalisieren Sie die Modelltelemetrie, behalten Sie die Abrechnungszuordnung bei und erfassen Sie Eingabeaufforderungsinhalte 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 Mandantenanforderung über den Modellaufruf bis zum Abrufkontext und dem erneuten Versuch, die in Rechnung gestellten Kosten zu ermitteln.

Das Ziel ist kein weiteres Dashboard mit Gesamttokens. Ziel ist die Beantwortung operativer Fragen wie:

• Welcher Mandant oder API Schlüssel verursachte einen Ausgabenanstieg?
• Hat sich die Latenz erhöht, nachdem ein Modellalias geändert wurde?
• Sind Wiederholungsversuche oder Fallbacks doppelt gezählte Kosten?
• 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 generative KI-Semantikkonventionen und -Attribute 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 und mehr um anbieterübergreifende Steuerungsebenen gehen. Die Teams erwarten, dass sie an einem Ort Latenz, Kosten, Qualität, Richtlinienereignisse, Mieterverhalten und Abrechnungsdifferenzen 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 Trace-Modell beginnt mit einem übergeordneten Span für die eingehende Kundenanfrage und untergeordneten Spans 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: Indexabfrage, 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.
• Nachbearbeitungsspanne: JSON Validierung, Schemareparatur, Zitatprüfungen oder endgültige Formatierung.

Der übergeordnete Bereich sollte stabile Korrelationskennungen tragen. Die untergeordneten Bereiche sollten normalisierte technische Attribute tragen. 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",
  "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"
}

Behalten Sie zwei Ideen getrennt: 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, aber für die Abrechnung oder Untersuchung von Vorfällen reichen sie 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 begann mit der Rückgabe von Token.
• abgeschlossen: Die Antwort wurde erfolgreich abgeschlossen.
• user_aborted: Der Client hat die Verbindung vor Abschluss getrennt.
• wiederholt: 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.
• reconciled: 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.

OpenTelemetry GenAI-Konventionen verwenden und dann sorgfältig erweitern

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; Identifikatoren mit hoher Kardinalität werden in Traces, Protokolle und Hauptbücher eingefügt.

Entwerfen Sie eine sichere Eingabeaufforderungs- und Ausgabeprotokollierung

Die 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

Für den meisten Produktionsverkehr speichern Sie:

• Prompt-Vorlagen-ID und -Version;
• Hashes normalisierter Eingabeaufforderungen und Ausgaben;
• Anzahl der Eingabe-, Ausgabe-, Cache- und Kontext-Tokens;
• 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, fordern Sie eine explizite Richtlinie. Zu den guten Kontrollen gehören Umgebungszulassungslisten, Zustimmung des Mieters, Stichproben, 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 Schwärzung 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

Die durch den 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;
• Zitatabdeckung;
• ob der abgerufene Kontext in der endgültigen Antwort verwendet wurde.

Damit 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 Provider-Abrechnung abgleichen

Gateway-Schätzungen sind sofort verfügbar. Abrechnungsdaten auf Anbieterseite sind in der Regel langsamer, aber aussagekräftiger. Benutze 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;
• Zeitüberschreitungsrate und Trends bei Anbieterfehlerklassen;
• Cache-Trefferquote und Schätzung der eingesparten Token;
• Fehlerrate 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-Span.
4. Erstellen Sie eine Hauptbuchzeile mit Status accepted.
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 Antwort des Anbieters 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

• Kanonische Anforderungs-IDs und Trace-IDs definieren.
• Übernehmen Sie OpenTelemetry GenAI-Attribute für allgemeine Modelltelemetrie.
• Erstellen Sie ein Gateway-Nutzungsbuch mit Anforderungsstatusübergängen.
• Anbieter-, Modell-, Modellalias-, Mandanten-, App- und Workflow-Dimensionen normalisieren.
• Untersuchungsdaten mit hoher Kardinalität von Metrikbezeichnungen fernhalten.
• Roheingabeaufforderung und Ausgabeerfassung standardmäßig deaktivieren.
• 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 Debugging.

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 Fallback-Verhalten in LLM API Routing
• promptes Caching und Batch-Kostenkontrolle Muster
• Team API Schlüsselverwaltung und Ausgabenlimits