SLA & SLO (Service Level Objectives)

SLA & SLO (Service Level Objectives) sind Zielwerte und Vereinbarungen, mit denen Teams die Zuverlässigkeit von KI-Systemen messbar machen – z. B. Verfügbarkeit, Latenz, Fehlerraten oder Antwortqualität. Ein SLO definiert interne Zielwerte (z. B. „99,9% der Requests unter 2 Sekunden“), ein SLA ist die vertragliche Zusage gegenüber Kunden inkl. Konsequenzen bei Nichteinhaltung.

Was bedeutet SLA und was bedeutet SLO?

SLO (Service Level Objective) beschreibt konkrete, messbare Ziele für einen Service. Es ist meist ein internes Steuerungsinstrument für Engineering, Produkt und Betrieb. SLA (Service Level Agreement) ist die externe Vereinbarung (Vertrag/Anhang), die typischerweise auf einem oder mehreren SLOs basiert und oft Kompensation, Credits oder Eskalationswege regelt. Praktisch: Nicht jedes SLO wird automatisch zum SLA – SLAs sind meist konservativer, um rechtliche und finanzielle Risiken zu begrenzen.

Wie funktioniert das in KI-Systemen (LLM, RAG, Agents)?

In KI-Stacks entstehen Ausfälle und Verzögerungen nicht nur im eigenen Backend, sondern auch durch Modellanbieter, Vektorsuche, Tools, Datenquellen oder Workflows. Deshalb definiert man SLOs entlang der Nutzerreise und misst sie über Service Level Indicators (SLIs) wie:

• Verfügbarkeit (z. B. Anteil erfolgreicher Antworten ohne 5xx/Timeout)
• Latenz (z. B. p95/p99 „Time to First Token“ und „Time to Final Answer“)
• Qualität/Erfolg (z. B. „Antwort enthält Quellen“, „Tool-Call erfolgreich“, „RAG-Recall“)
• Fehlerraten (z. B. Rate an Rate-Limits, Parsing-Fehlern, Tool-Failures)
• Kosten (z. B. Token pro Request als Guardrail, um Budget-SLOs einzuhalten)

Ein typischer Ablauf: (1) User-Flow definieren, (2) SLIs messen, (3) SLO-Ziele festlegen, (4) Error Budget ableiten (z. B. 0,1% Ausfall pro Monat), (5) Alerts/Runbooks und Release-Regeln daran koppeln.

Beispiele für SLA/SLO in der Praxis

• Chatbot mit ChatGPT/Large Language Model (LLM): SLO „99,9% erfolgreiche Antworten/Monat“, Latenz-SLO „p95 < 3s bis zur ersten Antwort“. SLA nach außen z. B. „99,5% monatliche Verfügbarkeit“.
• RAG (Retrieval-Augmented Generation) mit Vektordatenbank (Vector Database) und Embeddings: SLO „p95 Retrieval < 300ms“ + „Antwort enthält in 95% der Fälle mindestens 1 valide Quelle“.
• AI Agents (KI-Agenten) mit Function Calling / Tool Use: SLO „Tool-Call Erfolgsrate > 98%“ und „Max. 1 Retry im Mittel“, damit Agenten nicht in Schleifen laufen.
• Automations in n8n / Automatisierung (Automation): SLO „Job-Completion-Rate > 99%“ und „Durchlaufzeit p95 < 2 Minuten“.

Warum sind SLA & SLO für KI wichtig?

KI-Systeme sind probabilistisch: Antworten können schwanken, externe Modelle können drosseln, und Fehler wirken sich direkt auf Nutzervertrauen aus (z. B. durch Halluzinationen (Hallucinations), Timeouts oder fehlende Quellen). SLOs schaffen klare Leitplanken für Produktqualität und Betrieb – und machen Entscheidungen objektiv: Wenn das Error Budget aufgebraucht ist, werden Releases pausiert, Stabilität priorisiert oder Kapazitäten erhöht. Das ist ein Kernprinzip moderner MLOps- und Reliability-Ansätze.

Was kostet es, SLA/SLO umzusetzen?

Es gibt keinen Fixpreis – die Kosten hängen vor allem von Monitoring/Observability, Skalierung und Redundanz ab. Treiber sind z. B. zusätzliche Telemetrie (Tracing, Token-Metriken), Lasttests, Fallback-Modelle, Caching, Multi-Provider-Strategien und Incident-Management. Je strenger das SLA (z. B. 99,99% statt 99,9%), desto überproportional steigen Aufwand und Infrastrukturkosten.

Best Practices (kurz)

• SLOs an Nutzerwert koppeln (Antwort rechtzeitig und nutzbar), nicht nur an „Server lebt“.
• p95/p99-Latenzen und End-to-End-Messung nutzen (inkl. Modell- und Tool-Zeiten).
• Fallbacks definieren (z. B. kleineres Modell, vereinfachte Antwort, späteres Nachreichen von Quellen).
• SLA juristisch sauber formulieren, SLO technisch präzise messen.