Service Level Objectives (SLOs) sind ein zentrales Werkzeug moderner Site Reliability Engineering-Kultur. Sie definieren, was „ausreichend zuverlässig" für einen Dienst bedeutet, und schaffen die Grundlage für evidenzbasierte Entscheidungen über Deployments, Featurereleases und Risikoakzeptanz. Was für klassische Web-APIs oder Datenbankdienste längst etabliert ist, stellt IT-Teams bei KI-Diensten und LLM-APIs vor neue Herausforderungen – denn Zuverlässigkeit bedeutet hier mehr als nur Verfügbarkeit und Latenz.
Warum KI-Dienste andere SLOs brauchen
Klassische SLOs messen Verfügbarkeit (Uptime), Latenz (p99-Response-Time) und Fehlerrate. Bei einem REST-API-Endpunkt sind diese Metriken klar definiert: Entweder antwortet der Service mit HTTP 200 innerhalb des Zeitfensters, oder er tut es nicht.
KI-Dienste sind komplexer. Ein LLM-Endpunkt kann technisch verfügbar sein und dennoch in der Praxis nutzlos sein, wenn:
- die Antwortqualität stark schwankt (z.B. durch Modell-Versionswechsel beim Anbieter)
- die Time to First Token (TTFT) so hoch ist, dass Endnutzer die Anwendung als eingefroren wahrnehmen
- Halluzinationen oder fehlerhafte Ausgaben unentdeckt in downstream Systeme fließen
- Rate-Limit-Fehler (429) unter Last massenhaft auftreten, ohne das SLI-Monitoring zu triggern
Deshalb müssen SLOs für KI-Dienste auf mehreren Ebenen definiert werden: technisch, qualitativ und geschäftlich.
Die richtigen SLIs für LLM-Dienste wählen
Ein SLO beginnt mit der Wahl des richtigen Service Level Indicators (SLI) – also der Metrik, die gemessen wird. Für LLM-APIs und KI-Dienste sind folgende SLIs besonders relevant:
- Availability SLI: Anteil erfolgreicher Requests (HTTP 2xx) am Gesamttraffic. Standard, aber nicht ausreichend allein.
- Latency SLI: Zeit bis zum vollständigen Response oder – bei Streaming – Zeit bis zum ersten Token (TTFT). Nutzerorientierte Anwendungen sind besonders sensibel gegenüber TTFT-Ausreißern.
- Throughput SLI: Token pro Sekunde (TPS) auf Inferenz-Ebene. Relevant für Batch-Verarbeitung und hochlastige Produktionssysteme.
- Quality SLI: Anteil von Antworten, die einen definierten Qualitätsschwellwert erfüllen – gemessen durch automatisierte Evaluierungspipelines (LLM-as-judge, Klassifikatoren oder regelbasierte Checks).
- Rate-Limit Error Rate: Anteil von Anfragen, die mit 429 (Too Many Requests) abgelehnt werden. Häufig übersehen, aber kritisch bei extern angebundenen APIs.
Nicht alle SLIs müssen in einem einzelnen SLO zusammengefasst werden. Sinnvoller ist es, pro Kritikalitätsebene des Dienstes eigene SLOs zu definieren.
SLO-Targets realistisch setzen
Ein häufiger Fehler ist das unreflektierte Übertragen von Verfügbarkeitszielen klassischer Dienste auf KI-APIs. Eine 99,9%-Verfügbarkeit klingt gut – aber wenn der externe LLM-Anbieter selbst nur 99,5% garantiert, ist das interne Ziel illusorisch.
Empfehlenswert ist eine zweistufige Betrachtung:
- Externe SLAs lesen und einplanen: Welche Verfügbarkeit und Latenz garantiert der KI-Anbieter vertraglich? Diese Werte setzen eine reale Untergrenze für interne SLOs.
- Historische Daten auswerten: Was liefert der Dienst in der Praxis? Messungen aus Staging und Produktion über mehrere Wochen geben Aufschluss über realistische SLO-Targets.
Dabei gilt: Ein zu konservatives SLO (z.B. 95% Availability) gibt kaum Signal, wenn der Dienst problemlos auf 99,8% läuft. Ein zu ambitioniertes SLO erzeugt Dauerstress im Error Budget. Ziel ist ein SLO, das zwischen normalem Betrieb und echten Problemen scharf unterscheidet.
Error Budgets für KI-Dienste operationalisieren
Das Error Budget ist die erlaubte Abweichung vom SLO-Ziel innerhalb eines Rollup-Zeitraums (typischerweise 30 Tage). Bei einem Verfügbarkeits-SLO von 99,5% sind das 0,5% der Gesamtanfragen, die fehlschlagen dürfen, ohne das Ziel zu verletzen.
Für KI-Dienste empfehlen sich folgende Anpassungen:
- Separate Error Budgets pro SLI-Typ: Verfügbarkeit und Qualität sollten getrennte Budgets haben. Ein Qualitätseinbruch durch einen Modell-Versionswechsel beim Anbieter sollte nicht das Latenz-Budget verbrauchen.
- Budget-Verbrauchsrate überwachen: Nicht nur das absolute Budget, sondern die Rate, mit der es verbraucht wird, ist entscheidend. Schnelles Budget-Burning ist ein Frühindikator für systemische Probleme.
- Deployment-Gates: Wenn das Error Budget unter einen definierten Schwellwert (z.B. 50% des Monatsbudgets nach 10 Tagen) fällt, werden neue Deployments oder Modellwechsel eingefroren, bis sich der Dienst stabilisiert hat.
Qualitäts-SLOs: Der schwierigste Teil
Während technische SLIs automatisch aus Infrastrukturmetriken extrahiert werden können, erfordern Qualitäts-SLIs eine eigene Evaluierungspipeline. Ansätze dafür sind:
- LLM-as-Judge: Ein separates, oft günstigeres Modell bewertet Ausgaben des Produktionsmodells anhand vordefinierter Kriterien. Erfordert sorgfältige Kalibrierung, um eigene Fehler zu minimieren.
- Regelbasierte Checks: Einfache, deterministische Prüfungen – z.B. enthält die Antwort die erwartete JSON-Struktur, liegt sie innerhalb der erlaubten Längengrenzen, enthält sie verbotene Muster.
- A/B-Testing mit menschlichem Feedback: Stichprobenartige manuelle Bewertung von Produktionsantworten, die als Ground Truth für automatisierte Evaluatoren genutzt wird.
Qualitäts-SLOs sind in der Praxis oft die wichtigsten – und gleichzeitig diejenigen, die am seltensten gemessen werden. IT-Teams sollten schrittweise vorgehen: erst einfache regelbasierte Checks einführen, dann automatisierte Evaluierungspipelines aufbauen.
Tooling und Integration
SLOs für KI-Dienste lassen sich in bestehende Observability-Stacks integrieren. Gängige Metriken-Quellen sind:
- LLM-Gateway-Logs (Latenz, Token-Anzahl, Statuscode, Modell)
- Custom-Metriken aus der Applikationsschicht
- Evaluierungspipeline-Outputs (Qualitätsscore pro Antwort)
Diese Metriken können in Prometheus, Datadog, Grafana oder ähnliche Systeme exportiert werden. SLO-Tracking-Tools wie Sloth (Prometheus-basiert) oder native Dashboards in Cloud-Monitoring-Lösungen unterstützen die Berechnung von Error Budgets und das Alerting bei Budget-Burn-Raten.
Fazit
SLOs für KI-Dienste und LLM-APIs sind kein Luxus, sondern eine notwendige Grundlage für zuverlässigen KI-Betrieb in Produktion. Wer KI-Dienste ohne definierte SLOs betreibt, hat keine Möglichkeit, Zuverlässigkeit objektiv zu messen – und keine Grundlage für Entscheidungen darüber, wann eingegriffen werden muss. Der Aufbau von SLOs für KI-Dienste erfordert neue Metriken und Denkweise, aber die Grundprinzipien des SRE-Ansatzes bleiben dieselben: Ziele klar definieren, messen, Budgets respektieren und aus Abweichungen lernen.
Bildquelle: Unsplash
Quellen
- Google SRE Book – Service Level Objectives: sre.google/sre-book/service-level-objectives
- OpenSLO-Spezifikation: openslo.com
- Sloth – SLO-Tool für Prometheus: sloth.dev
- DORA Research – Accelerate State of DevOps: dora.dev
