KI in Production: Monitoring + Drift-Detection

Einordnung

Abschnitt 01

Was zu monitoren ist

Vier Hauptkategorien für KI-Monitoring: (1) Infrastruktur: CPU, RAM, GPU-Auslastung, Disk, Netzwerk. Standard für jeden Server, aber für KI mit besonderem Fokus auf GPU. (2) Service-Health: Request-Rate, Error-Rate, Latenz-Perzentile pro Endpoint. (3) Quality-Drift: Stichproben-Bewertung der KI-Output-Qualität, Vergleich zur Baseline. (4) Cost: Cloud-LLM-API-Costs, Strom-Verbrauch pro Modell-Aufruf, Cost-pro-Customer-Request. Diese vier Kategorien decken 95% der relevanten Monitoring-Themen ab.

Abschnitt 02

Latenz-SLOs definieren

Service Level Objectives (SLOs) pro Service-Typ: KI-Mail-Triage: p50 unter 500 ms, p95 unter 2 s, p99 unter 5 s. Voice-Receptionist: p50 unter 800 ms, p95 unter 1.5 s, p99 unter 3 s (strenger wegen Real-Time-Anforderung). RAG-Search: p50 unter 2 s, p95 unter 5 s. Cloud-LLM-Calls: p50 unter 1.5 s, p95 unter 4 s. Bei Verletzung: Alert nach 5 Minuten kontinuierlicher Verletzung. Die SLOs werden mit Customer-Erwartungen abgestimmt und im SLA dokumentiert.

Abschnitt 03

Grafana + Prometheus Standard

Standard-Stack: Prometheus für Metrics-Scraping (alle 15 Sekunden), Grafana für Visualisierung, AlertManager für Alert-Routing. Standard-Dashboards pro Service: Request-Rate, Error-Rate, Latenz-Histogram, GPU-Auslastung, Memory, Top-Endpunkte. Alle 12 Production-Setups bei DripBack haben identische Dashboard-Struktur, was Wartung deutlich vereinfacht. Dashboard-Templates verfügbar in DripBack-Setup-Kit.

Abschnitt 04

Quality-Drift-Detection

KI-Quality kann ohne Code-Änderung absinken. Gründe: Modell-Updates verändern Output-Stil, neue Daten-Pattern wichern nicht trainiert wurden, Customer-Preferences ändern sich. Drift-Detection-Mechanismen: (1) Random-Sampling: 1% aller Requests werden gespeichert für manuelle Review (wöchentlich durch Domain-Experten). (2) Embedding-Drift: Embedding der Output-Texte vergleichen mit Baseline-Embedding. Bei zu großer Distanz: Alert. (3) User-Feedback: explizite Thumbs-Up/Down von Mitarbeitern, aggregiert. (4) Output-Schema-Validierung: bei strukturierten Outputs (JSON) wird Schema-Konformität geprüft.

Abschnitt 05

Langfuse für LLM-Traces

Langfuse ist ein spezialisiertes LLM-Observability-Tool (Open Source). Funktionen: jeden LLM-Aufruf mit Input/Output/Cost trackbar machen, Multi-Step-Traces visualisieren (bei Agent-Workflows), Cost-Aggregation pro Customer/Endpoint, Quality-Bewertungen mit Custom-Evaluators. Setup: 1 Tag, Self-Hosted oder Cloud-Variante. Wir empfehlen Langfuse als zentrales LLM-Observability-Tool. Vorteil gegenüber generic Logging: spezifisch auf LLM-Workflows zugeschnitten, mit Cost-Trackings, Token-Counts, Modell-Vergleichen.

Abschnitt 06

Cost-Anomaly-Detection

LLM-Costs können schnell aus dem Ruder laufen, besonders bei Cloud-LLM-Nutzung. Anomaly-Detection-Strategien: (1) Tägliche Cost-Übersicht pro Customer mit Vergleich zur 30-Tage-Baseline. (2) Alert bei Cost > 3-Sigma-Standard-Deviation. (3) Pro-Endpoint-Cost-Limits: bei Überschreitung wird der Endpoint temporär deaktiviert. (4) Monthly-Budget-Caps: harte Grenze, bei Erreichung wird API-Key revoked. Bei einem unserer Customers hatten wir im November 2025 einen Bug, der zu 10x-Cost-Explosion geführt hätte — Cost-Anomaly-Detection hat das nach 30 Minuten alarmiert, Total-Schaden 23 € statt 230 €.

Abschnitt 07

Alerts: nicht zu viel, nicht zu wenig

Alerts-Strategie: nur das alerten, was Handlungs-Bedarf erzeugt. Standard-Alerts bei DripBack: Service unavailable (down) für 2+ Minuten. p95-Latenz über SLO für 5+ Minuten. Error-Rate über 5% für 3+ Minuten. GPU-Auslastung über 95% für 10+ Minuten. Disk-Auslastung über 85%. Memory über 90%. Cost-Anomaly. Quality-Drift (wöchentliches Review). Alerts gehen primär an Slack/Telegram, kritische zusätzlich per SMS. Eskalations-Wege definieren: nach 30 Min ohne Reaktion an nächste Stufe.

Abschnitt 08

Incident-Response-Plan

Bei kritischem Alert: dokumentierter Runbook für die häufigsten Szenarien. Runbook für Latenz-Spike: (1) Check GPU-Auslastung. (2) Check ob anderer Process GPU blockiert. (3) Restart KI-Service. (4) Wenn anhaltend: Eskalation an Senior-Engineer. Runbook für Quality-Drift: (1) Sample-Review der letzten 50 Outputs. (2) Vergleich zu Baseline-Outputs. (3) Bei Drift: Modell-Rollback zur letzten bekannten Version. (4) Investigation der Drift-Ursache. Sinnvoll sind Runbooks für die häufigsten Incidents.

Abschnitt 09

Quarterly Drill

Quartalsweise Notfall-Übung mit Customer: simuliertes Incident-Szenario, Reaktions-Zeit gemessen, Verbesserungs-Potenzial identifiziert. Standard-Szenarien: GPU-Hardware-Defekt (Recovery aus Backup), Cloud-LLM-Anbieter-Ausfall (Fallback auf lokales Modell), Datenpannen-Simulation (Vorfalls-Meldungs-Workflow). Dauer pro Drill: 2-4 Stunden. Findings werden in Lessons-Learned dokumentiert und in nächste Wartungs-Zyklen integriert.

Abschnitt 10

Setup-Aufwand realistisch

Vollständiges Monitoring-Setup pro Customer: rund 6-10 Tage. Davon: Prometheus/Grafana-Setup 2 Tage, Custom-Dashboards 2 Tage, Langfuse-Integration 1 Tag, Alert-Konfiguration 1 Tag, Runbook-Anpassung 1-2 Tage, Drill-Vorbereitung 1 Tag. Setup-Kosten: 5.400-8.800 €. Monatliches Hosting + Wartung: 180-280 €. Diese Monitoring-Komponente ist oft das, was den Unterschied zwischen "läuft irgendwie" und "ist verlässlich production-ready" ausmacht.