KI-Observability: Monitoring von LLMs und RAG-Pipelines in Kubernetes

Wer klassische Microservices betreibt, weiß: Metriken, Logs und Traces sind die Lebensversicherung. Doch bei KI-Workloads stoßen herkömmliche Monitoring-Ansätze an ihre Grenzen. Eine CPU-Auslastung von 10 % sagt uns nichts darüber aus, ob die Antwortqualität eines Sprachmodells gerade einbricht oder ob die Vektor-Suche ineffizient arbeitet.

Um eine KI-Plattform im Mittelstand produktiv zu betreiben, benötigen wir ein erweitertes Verständnis von Observability, das die Brücke zwischen Infrastruktur (GPU/K8s) und Modell-Performance (LLM) schlägt.

Die drei Ebenen der KI-Observability

Eine vollständige Sichtbarkeit erfordert Daten aus drei unterschiedlichen Schichten:

1. Infrastruktur-Metriken (Die Basis)

Bevor wir über KI-Logik sprechen, müssen die Ressourcen stimmen. Hier nutzen wir Bewährtes, aber mit spezifischem Fokus.

• GPU-Utilization: Wir nutzen den NVIDIA DCGM Exporter, um GPU-Temperatur, Power-Consumption und VRAM-Belegung in VictoriaMetrics zu erfassen.
• Bottleneck-Analyse: Besonders wichtig ist das Monitoring der PCIe-Bandbreite und der NVLink-Auslastung bei verteiltem Training. Staut sich der Datentransfer, langweilen sich die teuren GPUs.

2. Service- & Middleware-Tracing (Die Pipeline)

In einer RAG-Architektur (Retrieval Augmented Generation) ist das LLM nur ein Teil der Kette. Ein langsamer Response liegt oft an der Vektor-Datenbank oder dem Embedding-Service.

• Distributed Tracing: Mit OpenTelemetry verfolgen wir einen Request über den API-Gateway, den Embedding-Service, die Vektor-DB (z.B. Qdrant/Milvus) bis hin zum finalen LLM-Call.
• Vektor-DB Performance: Wir monitoren die Such-Latenz und die Recall-Rate. Wenn die Suche zu lange dauert, leidet die User Experience, noch bevor das Modell ein einziges Token generiert hat.

3. LLM-spezifische Metriken (Die Intelligenz)

Hier verlassen wir den klassischen IT-Pfad. Wir müssen verstehen, was das Modell eigentlich tut.

• Token-Usage: Wie viele Prompt- und Completion-Tokens werden verbraucht? Dies ist die Basis für das interne FinOps-Reporting.
• TTFT (Time To First Token): Die wichtigste Latenz-Metrik für generative KI. Sie bestimmt, wie schnell der Nutzer eine Reaktion sieht.
• Model Evaluation & Drift: Wir tracken die Antwortqualität. Nutzen wir Tools wie Arize Phoenix oder LangSmith, um Halluzinationen oder “Drift” (die Qualität der Antworten lässt über Zeit nach) zu identifizieren.

Architektur: Integration in den ayedo-Stack

Wir bauen diese Observability nicht als isolierte Insellösung. Stattdessen integrieren wir sie nahtlos in den bestehenden Cloud-Native Stack:

1. Collector: Ein OpenTelemetry Collector empfängt Metriken und Traces von den KI-Workloads.
2. Storage: VictoriaMetrics speichert die hochauflösenden GPU-Daten; Grafana Loki übernimmt das Logging der Modell-Interaktionen (natürlich unter Einhaltung der DSGVO/Anonymisierung).
3. Visualization: Spezielle Grafana-Dashboards korrelieren GPU-Last mit Token-Durchsatz. So sehen wir sofort: “Wenn wir 80% GPU-Last haben, sinkt unser Token-Durchsatz pro Sekunde um 20%.”

Fazit: Vertrauen durch Sichtbarkeit

KI im Unternehmen scheitert oft an mangelndem Vertrauen in die Verlässlichkeit. KI-Observability wandelt die “Black Box” LLM in ein messbares System um. Erst wenn Sie sehen, wie Ihre Modelle atmen, können Sie sie sicher skalieren und wirtschaftlich betreiben.

Technical FAQ: KI-Monitoring

Sollten wir alle LLM-Prompts und Antworten loggen? Technisch ja, aber rechtlich und kostentechnisch vorsichtig. Wir empfehlen ein Sampling-Verfahren oder das Logging von Metadaten (Token-Anzahl, Latenz, Sentiment-Score) und nur bei Fehlern den vollen Inhalt (nach Anonymisierung sensibler Daten).

Was ist wichtiger: GPU-Last oder Token-Durchsatz? Definitiv der Token-Durchsatz (Tokens per Second). Eine GPU kann zu 100% ausgelastet sein, während sie nur sehr langsam Tokens generiert (z.B. wegen Speicher-Engpässen). Der Token-Durchsatz ist Ihre primäre “Business-Metrik”.

Können wir Standard-Prometheus für GPU-Metriken nutzen? Ja, der DCGM Exporter liefert Prometheus-kompatible Formate. Aufgrund der hohen Kardinalität und Frequenz der Daten (viele Metriken pro GPU-Kern) ist jedoch ein performanter Storage wie VictoriaMetrics im Langzeitbetrieb oft stabiler und kosteneffizienter.