Observability

Observability (Beobachtbarkeit) von künstlicher Intelligenz beschreibt die Fähigkeit, die Aktionen und inneren Zustände von KI-Systemen in realen Umgebungen basierend auf ihren externen Daten (Logs, Metriken, Traces) zu verstehen. Im Gegensatz zum reinen Monitoring ("Ist das System an?") beantwortet Observability die Frage: "Warum verhält sich das System so?".

Ziele und Dimensionen

Die Ziele von Observability im KI-Kontext sind zweigeteilt: 1. System-Stabilität: Überwachung von Latenz, Fehlerraten und Ressourcen. 2. Qualität der Generierung: Überwachung von Halluzinationen, Toxizität und fachlicher Korrektheit.

Wir unterscheiden daher zwei fundamentale Sichtweisen auf die Observability:

Dimension	KI-System (Ops & DevOps)	KI Use Case (Data Science & Engineering)
Primärer Fokus	Ganzheitlicher Systemblick (Holistisch)	Verständnis der KI-Logik & Qualität
Datenbasis	Infrastruktur-Metriken, Logs, Service-Health	Prompt-Inhalte, LLM-Parameter, RAG-Kontext, Traces
Metriken	Durchsatz (TPS), Latenz (TTFT), GPU-Memory, Cache-Hit-Rate	RAG-Scores (Precision/Recall), Hallucination Rate, Toxicity
Fehleranalyse	Zur Laufzeit (Timeouts, 500er Fehler, OOM)	Ex-Post (Falsche Antworten, negatives User Feedback)
Typische Tools	Prometheus & Grafana	Arize Phoenix, Langfuse, Ragas

Technologischer Standard: OpenTelemetry

Die Referenzarchitektur setzt konsequent auf OpenTelemetry (OTEL) als Industriestandard. Es ermöglicht, Telemetriedaten (Logs, Metriken, Traces) herstellerunabhängig zu instrumentieren, zu sammeln und zu exportieren.

Besondere Bedeutung haben hierbei die GenAI Semantic Conventions, die standardisieren, wie LLM-spezifische Daten (z.B. Token-Counts, Modell-Namen) in Traces abgebildet werden.

Visualisierung & Analyse (Infrastruktur)

Für das operative Monitoring der Plattform-Komponenten setzt die Referenzarchitektur auf den Cloud-Native Standard-Stack:

Prometheus (Metrik-Erfassung)

Prometheus dient als zentrale Time-Series Database. Es sammelt ("scraped") Metriken von den Containern und Services. Sowohl die Inference-Engine als auch das Gateway stellen hierfür standardisierte Endpunkte bereit (siehe unten).

Grafana (Dashboards)

Grafana visualisiert die Daten aus Prometheus und ermöglicht das Erstellen von Alerts. Typische Dashboards umfassen:

• GPU-Auslastung: Wie stark sind die Karten ausgelastet? Wie viel VRAM wird genutzt?
• Queue-Tiefe: Wie viele Anfragen warten auf Bearbeitung?
• Durchsatz: Tokens pro Sekunde (TPS) über alle Modelle hinweg.

Grafana vLLM Performance-Dashboard

Native Integration der Komponenten

Die Kern-Komponenten der KIVA-Plattform bieten bereits "Out-of-the-Box" Schnittstellen für Prometheus an, ohne dass zusätzliche Exporter benötigt werden.

1. vLLM Metrics

Die Inference-Engine vLLM exponiert standardmäßig einen /metrics Endpunkt. Dieser liefert essenzielle Metriken für den Betrieb:

• vllm:num_requests_running: Anzahl der aktuell bearbeiteten Requests.
• vllm:num_requests_waiting: Anzahl der Requests in der Warteschlange (wichtiger Indikator für Scaling-Bedarf).
• vllm:gpu_cache_usage_perc: Auslastung des KV-Caches (zeigt an, ob PagedAttention effizient arbeitet oder Speicher fehlt).
• vllm:time_to_first_token_seconds: Latenz-Messung direkt an der Engine.

2. LiteLLM Gateway Metrics

Das LiteLLM Gateway verfügt über eine integrierte Prometheus-Integration via Callbacks.

• Konfiguration: Durch Setzen von callbacks: ["prometheus"] in der Config wird ein /metrics Endpunkt gestartet.
• Daten: Es werden Metriken zu Latenz, Fehlerquoten (z.B. ContextWindowExceededErrors) und Budget-Verbrauch (Spend) bereitgestellt.
• Vorteil: Da LiteLLM zentraler Einstiegspunkt ist, erhält man hier den Überblick über die Nutzung aller angeschlossenen Modelle und Provider.

Engineering-Ebene: LLM-Tracing Plattformen

Für die tiefe inhaltliche Analyse (Prompt Engineering, Debugging) werden spezialisierte Tools benötigt, die oft OTLP-Traces empfangen:

• Arize Phoenix: Eine führende Open-Source-Plattform für LLM-Tracing und Evaluation. Unterstützt OpenInference-Standards, bietet einen Prompt-Playground und Werkzeuge zur Analyse von Halluzinationen und RAG-Retrieval-Qualität.
• Langfuse: Fokussiert auf detailliertes Tracing von Chains und Agenten sowie Prompt-Management.

Instrumentation & Datenerfassung

Um die Daten aus den Anwendungen (Frontend, Services) zu extrahieren, werden spezialisierte SDKs genutzt:

OpenLLMetry

OpenLLMetry (Apache 2.0) ist eine Erweiterung von OpenTelemetry speziell für LLMs. Es instrumentiert automatisch gängige Frameworks (LangChain, OpenAI SDK, LlamaIndex) und sendet die Daten an ein beliebiges OTLP-Backend (z.B. Jaeger, Tempo oder Phoenix).

OpenLIT

OpenLIT (Apache 2.0) bietet eine umfassende Instrumentation für AI Engineering inklusive GPU Monitoring.

Metriken

Performance-Metriken

• Time to First Token (TTFT): Zeit bis das erste Wort generiert wird (wichtig für gefühlte Latenz).
• Time between Tokens (TBT): Geschwindigkeit der Generierung (Flüssigkeit).
• Tokens per Second (TPS): Gesamtdurchsatz des Systems.
• Total Latency: Gesamtzeit für den kompletten Request.

Qualitäts-Metriken (RAG & Evals)

Diese Metriken werden oft durch Metrik-Suiten wie Ragas oder DeepEval berechnet:

• Context Precision: War der gefundene Kontext relevant für die Frage?
• Faithfulness: Basiert die Antwort wirklich auf dem Kontext oder halluziniert das Modell?
• Answer Relevance: Beantwortet die Ausgabe tatsächlich die Frage des Nutzers?