Release & Rollout: Continuous Delivery für LLM-Systeme
Einführung · 9 Abschnitte · ~8 Min Lesezeit · Stand
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.
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.
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)
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.
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.
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. |
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ätsregression 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.
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.
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.
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.