# Release & Rollout

> Sicher ändern — CD für LLM: Prompt und Modell als versioniertes Artefakt, Canary, Shadow-Deploy, Rollback-Trigger für Qualitätsregressionen, Modell-Pinning und der Kill-Switch.

Track: [LLM Production Ops](https://physar.tech/learn/llm-production-ops)  
Kanonische Fassung: https://physar.tech/learn/llm-production-ops/release-rollout  
Stand: 2026-07-25  
Interaktiver Teil: 7 Checks (nur im Browser)

## Release & Rollout: Continuous Delivery für LLM-Systeme

### Warum „grüner Build“ hier nichts beweist

Klassisches CD verlässt sich darauf, dass ein deterministischer Build + Tests grün = sicher deploybar heißt. Bei LLM-Systemen bricht diese Kette: dieselbe Eingabe kann bei gleichem Code eine andere Ausgabe erzeugen, und ein geänderter Prompt oder ein neues Modell besteht jeden Unit-Test — und verschlechtert trotzdem die Antwortqualität. Der Build sagt dir, dass der Dienst **läuft**, nicht dass er **gut** antwortet.

_[Abbildung: Ein Release ist erst kontrolliert, wenn ein identifiziertes Artefakt begrenzt ausgerollt, an der erwarteten Wirkung gemessen und bei Bedarf zurückgeführt wird.]_

Dieses Modul behandelt den **Runtime-Rollout**: wie du eine geänderte Variante gegen echten Produktions-Traffic absicherst. Das Offline-Eval-Gate in der CI (misst gegen ein festes Testset **vor** dem Merge) ist ein anderer Hebel — hier geht es um alles **nach** dem grünen Build.

> **Merksatz:** Ein grüner Build heißt „der Dienst startet“ — nicht „die Antworten sind gut“. Qualität zeigt sich erst an echtem Traffic.

### Das Release-Artefakt: was eigentlich deployt wird

Die Ausgabe eines LLM-Features hängt nicht nur am Code, sondern an einer **Kombination**: dem Prompt-Text, der **Modellversion**, den Decoding-Parametern (`temperature`, `top-p`, `max_tokens`) und der Retrieval-Config (`top-k`, Reranking, Schwellen). Liegen diese Werte als verstreute Konstanten in mehreren Dateien und Services, hast du keine wiederherstellbare „Version“ — und damit keinen sauberen Rollback.

Die Ops-Antwort: behandle diese Faktoren als **ein** versioniertes, deploybares Artefakt (eine versionierte Config), das als Einheit ausgerollt und zurückgerollt wird — idealerweise unabhängig vom Code-Release-Zyklus, damit ein Prompt-Fix keinen vollen Image-Rebuild braucht.

- Prompt-Text (Version, nicht nur editierbar)
- Modell-Pin (datierte Version/Snapshot)
- Decoding-Parameter (`temperature`, `top-p`, `max_tokens`)
- Retrieval-/Tool-Config (`top-k`, Reranking, Schwellen)

> **Merksatz:** Reproduzierbarkeit und Rollback setzen voraus, dass alle Faktoren, die die Ausgabe bestimmen, **gemeinsam** versioniert sind. Verstreute Konstanten haben keine Version.

### Die Rollout-Leiter: schrittweise statt Big-Bang

Weil du der Qualität nicht vorab trauen kannst, exponierst du eine neue Variante **schrittweise** und misst live mit. Eine typische Leiter — von risikoärmster zu voller Exposition:

Shadow (0 % Nutzer) → **Canary (kleiner Traffic-Anteil)** → Progressiv hochdrehen → 100 %

Auf jeder Stufe gilt: ein **Gate** aus Live-Metriken entscheidet, ob du hochdrehst — und ein **Rollback-Trigger** plus **Kill-Switch** hängen die ganze Zeit daneben, um bei einer Regression sofort zurückzukönnen.

> **Warum Stufen:** Jede Stufe begrenzt den Blast-Radius: Wenn die neue Variante schlecht ist, sieht es ein kleiner Teil des Traffics — oder gar kein Nutzer.

### Canary: kleiner Anteil, Gate auf Qualitätssignalen

Beim **Canary** bekommt ein kleiner Anteil des echten Traffics (z. B. 5 %) die neue Variante, der Rest bleibt auf der alten. Ein Canary ist aber nur so gut wie seine **Gate-Metrik**: Verfügbarkeitssignale (5xx, Latenz) fangen eine Qualitätsregression **nicht** — die crasht nicht, sie antwortet nur schlechter.

Gate deshalb auf **Proxy-Metriken** für Qualität: Refusal-Rate, Format-Valid-%, Retrieval-Leerquote, Antwortlänge, 👍/👎-Rate — plus Latenz und Fehler. Und lass den Canary lange genug laufen: manche Metriken brauchen Zeit oder eine größere Population, um statistisch zu tragen.

> **Merksatz:** Ein Canary muss die Regression **sehen** können, die du fürchtest. Gate auf Qualitätssignale, nicht nur auf „läuft es noch“.

### Shadow-Deploy: echter Traffic, null Nutzerkontakt

Selbst ein 1 %-Canary zeigt echten Nutzern die neue Ausgabe. Wenn das inakzeptabel ist — hohes Risiko, kritisches Feature — nutzt du **Shadow-Deploy**: Produktions-Requests werden parallel an die neue Variante gespiegelt, ihre Ausgabe wird **verworfen** und nur mit der alten verglichen. Der Nutzer sieht ausschließlich den stabilen Pfad.

Shadow prüft die Variante an der **realen** Traffic-Verteilung, die kein Offline-Testset vollständig abbildet — vor dem ersten Nutzerkontakt. Grenzen: Shadow verdoppelt die Inferenz-**Kosten**, und bei Features mit **Nebenwirkungen** (Tool-Calls, DB-Writes, E-Mails) darfst du diese im Schatten nicht real auslösen — sonst doppelte Effekte. Solche Seiteneffekte musst du stubben oder isolieren.

|  |  |
| --- | --- |
| Canary | Kleiner Anteil echter Nutzer sieht die neue Ausgabe; Gate auf Live-Qualität. |
| Shadow | Null Nutzer sehen sie; Vergleich an realer Verteilung; kostet doppelt, Nebenwirkungen isolieren. |

> **Wann Shadow:** Shadow, wenn schon eine kleine Fehlerquote inakzeptabel ist. Canary, wenn du kontrollierte reale Exposition willst — Qualität zeigt sich manchmal erst, wenn Nutzer wirklich handeln.

### Rollback-Trigger: vordefiniert, nicht im Bauchgefühl

Ein Rollout braucht einen **vor** dem Ausrollen festgelegten Abbruch: welche Metrik, welche Schwelle, welches Zeitfenster, automatisch oder menschlich — und wer im Grenzfall entscheidet. Im Incident ist es zu spät, „gut genug“ zu verhandeln; ohne definierte Schwelle gewinnt der Lauteste, nicht die Daten.

Der Trigger muss die **Qualitäts**regression treffen, nicht nur Crashes: eine Refusal-Rate über X %, Format-Valid unter Y %, 👎-Rate über Baseline + Z. Zu empfindlich ist auch falsch — Nicht-Determinismus und normales Rauschen dürfen kein Dauer-Flapping auslösen. Die Schwelle trennt Signal von Rauschen.

> **Merksatz:** Rollback-Kriterien gehören **vor** den Rollout — messbar, auf die gefürchtete Regressionsart bezogen und gegen Rauschen kalibriert.

### Modell-Pinning: wer bestimmt deinen Release-Zeitpunkt

Providers bieten oft floatende Aliasse („latest“ oder eine Major-Alias) **und** datierte Snapshots an. Rufst du gegen einen floatenden Alias, kann sich das Modell hinter derselben API **still** ändern — deine Ausgabe verschiebt sich ohne einen Deploy deinerseits, und dein Canary/Rollback greift nie, weil du nichts ausgerollt hast.

Deshalb: an eine **feste, datierte Version pinnen** und Upgrades bewusst als Release durch deinen Shadow-/Canary-Prozess ziehen. Der Preis: du musst Pins aktiv **nachziehen**, bevor der Provider sie deprecatet — sonst erzwingt eine Abkündigung irgendwann einen Notfall-Wechsel ohne Testfenster.

> **Merksatz:** Wer nicht pinnt, delegiert seinen Release-Zeitpunkt an den Anbieter. Pinning ist die Voraussetzung dafür, dass Canary und Rollback überhaupt greifen können.

### Kill-Switch: schneller als dein Deploy

Wenn ein LLM-Feature live entgleist — toxische, falsche oder kaputte Ausgabe — brauchst du einen Abschaltpfad, der **schneller** ist als ein Rollback über die CI/Deploy-Pipeline (Minuten). Ein **Kill-Switch** (Feature-Flag) legt das Feature zur **Laufzeit** sofort auf einen sicheren Fallback um: statische Antwort, Nicht-LLM-Pfad, Cache oder menschlicher Pfad.

Zwei Bedingungen: Der Schalter muss **ohne Deploy** greifen (ein Compile-Time-Flag ist so langsam wie ein Rollback), und er muss auf einen **funktionierenden** Fallback zeigen — hartes Aus mit Fehlerseite tauscht nur einen Ausfall gegen einen anderen. Der Fallback-Pfad muss vorab gebaut und gepflegt sein.

> **Merksatz:** Ein Kill-Switch ist unabhängig vom Deploy-Zyklus und zeigt auf einen sicheren, degradierten — aber funktionierenden — Pfad.

### Zusammenfassung — gleich im Check

Du kennst jetzt die sechs Achsen des sicheren LLM-Rollouts: das **Release-Artefakt**, den **Canary** mit Qualitäts-Gate, den **Shadow-Deploy** ohne Nutzerkontakt, den vordefinierten **Rollback-Trigger**, das **Modell-Pinning** und den **Kill-Switch**.

> **Gleich im Check:** In den nächsten Entscheidungen wählst du für konkrete Ops-Szenarien selbst — und siehst pro Option, **warum** sie trägt oder nicht.

## Quellen

- The Site Reliability Workbook (Google) — Kapitel 16: Canarying Releases
- Jez Humble & David Farley — Continuous Delivery (2010): build once, version everything
- Martin Fowler — CanaryRelease & DarkLaunching (martinfowler.com/bliki)
- Pete Hodgson — Feature Toggles (aka Feature Flags), martinfowler.com
- Microsoft Engineering Fundamentals Playbook — Shadow Testing
- The Twelve-Factor App — III. Config
- Martin Fowler — CanaryRelease (martinfowler.com/bliki)
- Martin Fowler — DarkLaunching (martinfowler.com/bliki)
- Google SRE Book — Release Engineering (rollback as first-class operation)
- Provider-Dokumentation zur Modell-Versionierung (datierte Snapshots vs. floatende Aliasse)
- The Site Reliability Workbook (Google) — Kapitel 16: Canarying Releases (Kontrolle über den Release-Zeitpunkt)
- Michael Nygard — Release It! (Circuit Breaker & graceful degradation)
- Google SRE Workbook: Canarying Releases — https://sre.google/workbook/canarying-releases/
- SRE Google: Monitoring Distributed Systems — https://sre.google/sre-book/monitoring-distributed-systems/