Der Fehler, den fast jeder in seiner KI-Überwachung macht

Der Fehler, den fast jeder in seiner KI-Überwachung macht

Jul 06, 2026 ai monitoring llm operations observability ai infrastructure production ai latency metrics ai reliability mlops

Warum herkömmliches Monitoring bei KI-Anwendungen versagt

Mal ganz ehrlich: Wenn du deine LLM-Anwendung genauso überwachst wie deine API-Endpunkte, hast du keine Ahnung, was eigentlich los ist.

Das sehe ich ständig. Teams richten ihren KI-Service ein, hängen ihn an ihr bestehendes Monitoring-System, sehen grüne Lämpchen – und werden dann überrascht, wenn Nutzer sich über die Antwortqualität beschweren oder die monatliche Rechnung dreimal so hoch ausfällt wie geplant. Die Tools zeigen: alles in Ordnung. Ist es aber nicht.

Das Problem liegt tiefer als nur die falschen Metriken zu wählen. KI-Systeme brechen grundlegend die Annahmen, auf denen unsere Überwachungsinfrastruktur aufgebaut wurde.

Das Web-Services-Modell passt nicht

Traditionelles Web-Monitoring funktioniert mit einem klaren Signal: Eine Anfrage kommt rein, Arbeit passiert, eine Antwort geht raus. Erfolg oder Misserfolg – binär. Latenz ist Latenz. Dein 99. Perzentil sagt dir etwas Konkretes.

LLMs zerstören jede einzelne dieser Annahmen.

Eine Antwort kommt nicht auf einmal – sie wird Token für Token generiert. Das bedeutet: „Latenz" sind eigentlich mindestens drei verschiedene Zahlen, je nachdem wo du in der Generierung stehst. Ein HTTP 200 sagt nichts über die Ausgabequalität. Kosten skalieren mit Tokens, nicht mit Requests. Und die gefährlichsten Fehler sind komplett lautlos: Das Modell liefert überzeugenden Unsinn mit einem perfekten HTTP-Statuscode.

Time to First Token: Die Zahl, die Nutzer wirklich spüren

Wenn jemand einen Prompt an deine KI-Funktion sendet, erlebt er zuerst eines: Warten. Genauer gesagt warten sie auf das erste Token auf dem Bildschirm. Das ist Time to First Token (TTFT) – und das ist das Äquivalent zur gefühlten Latenz in der LLM-Welt.

Was TTFT tricky macht: Es wächst mit der Prompt-Länge. Wenn du ein RAG-System baust, das massive Kontextfenster in jeden Request stopft, um die Genauigkeit zu verbessern, dann verschlechterst du gleichzeitig die gefühlte Performance. Das ist ein fundamentaler Tradeoff, den traditionelles Monitoring nicht für dich aufdeckt.

Inter-Token Latency: Der Flow-Faktor

Sobald der Stream beginnt, entwickeln Nutzer Erwartungen an ihre Lesegeschwindigkeit. Inter-Token Latency (ITL) – die Lücke zwischen aufeinanderfolgenden Tokens – bestimmt, ob die Ausgabe sich flüssig anfühlt oder abgehackt.

Nutzer sind erstaunlich tolerant gegenüber einem langsamen, aber gleichmäßigen Stream. Sie hassen einen schnelleren Stream, der einfriert und stottert. Dein Monitoring sollte zwischen diesen Erlebnissen unterscheiden – selbst wenn der reine Durchsatz in Ordnung aussieht.

End-to-End Latency: Kontext ist alles

Die p99-Metrik, die wunderbar für deine REST-API funktioniert, wird dich bei KI-Requests komplett in die Irre führen. Warum? Weil eine 50-Token-Klassifizierungsaufgabe und eine 2.000-Token-Berichterstellung völlig unterschiedliche Latenzprofile haben – und sie zusammenzuwerfen ergibt eine Zahl, die nichts repräsentiert.

Tracke Latenz pro Anwendungsfall. Jede Metrik sollte einer Workload mit konsistenten Eigenschaften entsprechen. Sonst optimierst du für eine Abstraktion, die nicht existiert.

Das Problem der lautlosen Fehler

Hier wird es unangenehm: Die schlimmsten Produktionsprobleme mit KI-Systemen erzeugen oft null Alerts.

Dein Modell beginnt, überzeugende Halluzinationen zu generieren. Dein Prompt-Drift führt subtile Verzerrungen ein. Der abgerufene Kontext wird zugunsten von Trainingserinnerungen ignoriert. All das liefert HTTP 200, ist in akzeptabler Zeit fertig und sieht im Dashboard perfekt gesund aus.

Mit Uptime-Checks fängst du das nicht ab. Du brauchst Output-Quality-Monitoring – und das ist schwerer zu instrumentieren, aber absolut unverzichtbar.

Was wirklich zählt

Gruppiere deine KI-Metriken nach den Fragen, die sie beantworten:

  • Ist es schnell? TTFT, ITL, per-use-case Latenzperzentile
  • Kann es skalieren? Token-Durchsatz, Queue-Tiefen, Kontext-Auslastung
  • Ist es korrekt? Task-Completion-Rates, Fehlermuster in den Ausgaben
  • Hält es wirtschaftlich? Kosten pro Task, Token-Effizienz, Modellkonsistenz
  • Wie verhält es sich? (Für Agents) Task-Completion, Step-Counts, Loop-Detection

Einige dieser Zahlen bekommst du umsonst von deiner Infrastruktur. Die meisten nicht. Custom-Instrumentierung für KI-Workloads ist kein Luxus – es ist der einzige Weg zu sehen, was wirklich passiert.

Die Teams, die das richtig machen, nutzen keine besseren Dashboards. Sie stellen bessere Fragen.

Read in other languages:

RU BG EL CS UZ TR SV FI RO PT PL NB NL HU IT FR ES DA ZH-HANS EN