Reliabilität, SLOs & Incident

Das Ops in LLMOps

Ein LLM-Feature ist im Betrieb ein besonderer Dienst: Er ist nicht-deterministisch (dieselbe Eingabe, verschiedene Ausgabe), teuer und ratelimitiert, hängt an einem externen Anbieter — und wenn er „falsch“ antwortet, gibt es keinen Stacktrace. Trotzdem gelten die klassischen SRE-Prinzipien: messbare Ziele, Fehler-Budgets, graceful degradation, geübte Incident-Response.

Dieses Modul ist die Brücke zur SRE-Praxis, angewandt auf LLM-Eigenheiten. Es geht nicht um Modellauswahl oder Prompt-Qualität, sondern darum, den fertigen Dienst zuverlässig laufen zu lassen: beobachten, Ziele setzen, unter Last und Ausfall stabil bleiben, im Zwischenfall richtig handeln.

SLIs, SLOs und die Fehler-Taxonomie

Ein SLI (Service Level Indicator) ist eine gemessene Kennzahl deines Dienstes, ein SLO (Service Level Objective) das Ziel darauf — z. B. „99,5 % der Anfragen liefern in unter 8 s eine gültige Antwort“. Ein SLI muss in Echtzeit maschinell messbar sein, sonst kannst du weder alarmieren noch ein Fehler-Budget führen.

Deshalb ist „die Antwort ist inhaltlich falsch“ kein brauchbarer Verfügbarkeits-SLI: Korrektheit erfordert Ground-Truth oder ein (selbst probabilistisches, teures, langsames) Urteil — das gehört ins Offline-Eval und ins Drift-Monitoring, nicht auf den Pager. Der Verfügbarkeits-SLI stützt sich auf einen maschinell prüfbaren Antwort-Vertrag und eine klare Fehler-Taxonomie:

Ein SLO impliziert ein Fehler-Budget: 99,5 % Ziel = 0,5 % erlaubte Fehler. Das Budget ist Betriebsmittel — es finanziert Deploys und Experimente. Ein 100-%-Ziel ist bei einem probabilistischen, fremd-gehosteten Dienst weder erreichbar noch sinnvoll.

Tail-Latenz: der Median lügt

Generative Aufrufe sind langschwänzig (heavy-tailed): Die Antwortdauer hängt an der erzeugten Token-Zahl, und Retries auf transiente Fehler starten die ganze Generierung neu. Der Median (p50) sieht dann harmlos aus, während p95/p99 weit darüber liegen — und genau diese langsamen Anfragen sind die, die Nutzer als „hängt“ erleben.

Bei Fan-out verschärft sich das: Wartet eine Anfrage auf mehrere Aufrufe, bestimmt der langsamste die Gesamtlatenz — schon moderate p99 einzelner Aufrufe summieren sich („the tail at scale“). Betreibe und alarmiere deshalb gegen p95/p99, nicht gegen Mittelwert oder Median.

Der Timeout ist keine technische Nebensache, sondern eine SLO-/UX-Entscheidung: Er kappt den Schwanz. Zu kurz → viele abgeschnittene Anfragen (die einen Fallback brauchen); zu lang → Nutzer warten, Verbindungen und Kapazität bleiben gebunden. Wähle ihn bewusst am Tail entlang, mit einem definierten Verhalten für die gekappten Anfragen.

Graceful degradation: lieber schwächer als tot

Fällt der Anbieter aus oder ist überlastet, ist ein harter Fehler die schlechteste Antwort — er macht aus einer Teil-Störung eine Voll-Störung. Graceful degradation hält die Kernfunktion teilweise am Leben, statt hart zu scheitern.

• Cache: vorhandene oder ähnliche Antwort ausliefern statt neu generieren.
• Kleineres/sekundäres Modell: günstiger, schwächer, aber verfügbar.
• Statische/regelbasierte Antwort: vordefiniert, für den Notfall.
• Reduzierter Funktionsumfang: die teure Fähigkeit deaktivieren, den Rest liefern.

Rate-Limits sind deine Kapazitätsgrenze

Anbieter begrenzen dich über RPM (requests per minute) und TPM (tokens per minute) bzw. Quotas. Das ist deine reale Kapazitätsdecke — nicht deine CPU. Mehr Worker oder Concurrency erzeugen gegen ein festes RPM/TPM nur mehr 429er, keine Kapazität.

Ein 429 heißt „langsamer“, nicht „mehr versuchen“. Wer bei 429 sofort und synchron retried, baut einen Retry-Sturm (thundering herd) und verschärft die Drosselung, die er beheben will. Lastspitzen gehören geformt, nicht durchgeprügelt:

• Queue / Client-seitiger Rate-Limiter: Demand glätten, unter der Decke bleiben.
• Backpressure: dem Aufrufer signalisieren, langsamer zu senden.
• Load-Shedding: unwichtige/niedrigpriore Last früh abwerfen, um die wichtige zu schützen.
• Backoff mit Jitter, `Retry-After` beachten: Retries entzerren, statt sie zu synchronisieren.

Der Incident ohne Stacktrace

„Das System halluziniert seit heute Früh vermehrt“ oder „verweigert plötzlich gültige Anfragen“ — Health-Checks grün, Latenz normal, keine Errors im Log. Ein Qualitäts-Incident produziert kein Crash-Signal, ist aber echter Nutzer-Schaden. Fehlen eines Stacktraces ist nicht die Abwesenheit eines Incidents.

Wie bei jedem Incident gilt: Severity nach Nutzer-Wirkung einstufen und die Blutung zuerst stoppen. Ohne Stacktrace kann die Root-Cause-Analyse lange dauern — also erst mitigieren, dann diagnostizieren. Sichere Mitigation ist der Rücksprung auf einen bekannt-guten Stand (Rollback / Kill-Switch auf Fallback), nicht ein Vorwärts-Fix live.

1. erkennen
2. →Severity einstufen
3. →mitigieren
4. →diagnostizieren
5. →kommunizieren

Provider-Risiko: ein Anbieter, ein Single Point of Failure

Hängt dein Produkt an einem Anbieter, ist dessen Ausfall dein Ausfall — Retries helfen nicht, wenn die einzige Abhängigkeit komplett weg ist. Eine Multi-Provider-Strategie (ein zweiter Anbieter als Fallback) reduziert dieses Risiko, kostet aber real: Prompt-Parität (Anbieter verhalten sich unterschiedlich), doppelte Evals, eine gepflegte Abstraktion, mehr Kosten.

Deshalb ist es eine Abwägung, kein Automatismus: Ein zweiter Anbieter rechtfertigt sich, wenn das Verfügbarkeitsziel über dem liegt, was ein Anbieter allein liefert, und das Feature geschäftskritisch ist. Ein zweiter API-Key oder eine zweite Region desselben Anbieters ist keine echte Redundanz — der Ausfall ist korreliert.

Zusammenfassung — gleich im Check

Du kennst jetzt die Betriebs-Achsen eines LLM-Dienstes: SLIs/SLOs & Fehler-Taxonomie, Tail-Latenz & Timeout, graceful degradation, Rate-Limits als Kapazitätsgrenze, Incident ohne Stacktrace und Provider-Risiko.