So bauen Sie eine LLM-CI/CD-Pipeline mit Divinci AI

Notes from the Release Cycle — Teil I

Als wir das erste Mal versucht haben, ein LLM durch eine gewöhnliche CI/CD-Pipeline auszuliefern, lief der Build grün durch, das Deploy war erfolgreich — und der Kundensupport eröffnete innerhalb von sieben Minuten Tickets.

Nichts war „kaputt“. Alle 4.200 Integrationstests bestanden. Die Latenz war unverändert. Die 200-OK-Rate hielt sich stabil. Aber bei einer bestimmten Klasse juristischer Fragen begann das neue Modell auf einmal leise zu hedgen — es weigerte sich, sich auf Antworten festzulegen, die die vorherige Version korrekt beantwortet hatte. Kein Test hat das erkannt, weil wir noch keinen geschrieben hatten.

Wir haben zurückgerollt — und das Rollback selbst war ein Ereignis. Das Modellartefakt lag an drei Stellen, das Prompt-Template an einer vierten, die Routing-Regeln an einer fünften, und nichts wusste etwas vom anderen. Es dauerte gut zwei Stunden, bis wir wieder im vorherigen funktionsfähigen Zustand waren. Die Kunden, die in diesem Zeitfenster ein Hedging serviert bekamen, waren wenig begeistert.

Dieser Ausfall ist der Grund, warum es diese Pipeline gibt. Was folgt, ist die tatsächliche Pipeline, durch die wir unsere eigenen Releases schicken — und die wir über die Divinci-API für Kunden bereitstellen, die ihre eigenen ausliefern. Sie hat vier Stufen — register, gate, roll, observe — und jeder Schritt hat einen Rollback-Pfad, der nicht davon abhängt, dass ein Mensch wach ist.

Die vier Stufen

Die Stufen sind bewusst starr. Jedes Release durchläuft jede Stufe in dieser Reihenfolge. Einen „Hotfix“-Pfad, der die Evaluierung überspringt, gibt es nicht — den haben wir einmal probiert.

Stufe 1 — Register

Ein Release ist kein Modellgewichts-File. Ein Release ist ein unveränderliches Manifest, das Folgendes bündelt:

• Das Modellartefakt (HF-Repo + Commit-SHA oder ein Vindex-Patch)
• Das Prompt-Template (jede Variable, jede System-Message)
• Die Routing-Regeln (welche Traffic-Klasse landet auf welcher Version)
• Die Datensatzversion, mit der die Gate-Schwellenwerte berechnet wurden
• Die SHA des vorherigen Releases, damit Rollback eindeutig ist

curl -X POST https://api.divinci.ai/v1/releases \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -d '{
    "model_ref": "Divinci-AI/gemma-4-e2b@a7c91f",
    "prompt_template_ref": "templates/legal-qa@v14",
    "routing": { "domain": "legal" },
    "dataset_version": "scored-qa-medical-v3",
    "previous_release": "rel_8f72b1"
  }'
# → { "release_id": "rel_a01c66", "manifest_sha256": "9abaeaf6..." }

Die Manifest-SHA ist der einzige Handle, den irgendjemand in der Pipeline jemals verwendet. Wenn zwei Personen meinen, dasselbe Release zu deployen, die SHAs sich aber unterscheiden, weist die Pipeline das Deploy ab. Diese Regel hat uns bereits zwei Bugs eingefangen.

Stufe 2 — Gate

Das Gate ist der Teil, den die meisten CI-Pipelines falsch machen. Lighthouse-artige Heuristiken — Perplexity, BLEU, ROUGE — lassen eine Regression durch, wenn diese sich auf eine Domäne konzentriert. Aggregatwerte verwässern sie.

Divincis Gate führt die Scored-QA-Suite aus, mit der das Release-Manifest registriert wurde, und wendet einen kategorieweisen Spearman-Schwellenwert an:

Das Release in der obigen Grafik würde ein Aggregat-Gate passieren (Mittelwert 0,64 ist „nah genug“). Es scheitert an Divincis Gate, weil IP-Lizenzierung von vormals 0,68 auf 0,41 einbricht — genau die Art lokalisierter Regression, die ein Notebook nie erwischt.

Wir haben slice-aware Gating nicht aus Spaß erfunden. Es ist der direkt benannte Failure Mode in der aktuellen Welle von LLM-Postmortems. Tianpans Beitrag „The Semver Lie“^[6] beschreibt eine Prompt-Änderung, die „Code-Review bestand, ohne Eval-Gates deployt wurde, ohne User-A/B in Produktion landete und kein automatisches Rollback auslöste“. Was diesen Vorfall katastrophal statt bloß ärgerlich machte: die Regression war auf einen Slice konzentriert — eine einzelne Klasse von User-Journeys — während das Aggregat hielt. Jedes LLM-Release-Tool, das wir 2026 untersucht haben, gated entweder auf einen einzigen globalen Score oder gar nicht. Keines davon sliced das Gate.

Ein Gate-Fail ist keine weiche Warnung. Die release_id wird als gate_fail markiert, das Manifest archiviert, und kein Deploy-Befehl akzeptiert es. Cold-Start-Releases — ein brandneues Modell ohne historische Spearman-Werte zum Vergleich — durchlaufen einen einmaligen --force-gate-override-Pfad, der eine schriftliche Begründung verlangt; die Begründung, die User-ID und eine gate_override_sha256 wandern direkt in den Audit-Trail. Den Override gibt es, weil es legitime Situationen dafür gibt; den Audit-Trail gibt es, weil dein Ich der Zukunft die Begründung lesen muss.

Stufe 3 — Roll

Ein Canary bei Divinci bedeutet drei Checkpoints: 5 %, 25 %, 100 %. An jedem Checkpoint hält die Pipeline entweder für die konfigurierte Dwell Time oder den konfigurierten Request-Count an, je nachdem, was später ist. Default sind 4 Minuten / 1.000 Requests bei 5 %, 15 Minuten / 10.000 Requests bei 25 %.

An jedem Checkpoint müssen drei Monitore halten:

1. p95-Latenz innerhalb des 1,2-fachen der p95 des vorherigen Releases
2. 5xx-Rate innerhalb des 1,5-fachen der Rate des vorherigen Releases
3. Output-Qualitätsmonitor: ein kontinuierliches Replay aktueller Produktions-Traces durch das Kandidaten-Release, bewertet vom selben kalibrierten Judge, der Stufe 2 angetrieben hat

Der dritte Punkt ist derjenige, den keine andere Release-Pipeline ausliefert. SageMaker, KServe, BentoML, Vertex AI — sie alle überwachen Latenz und Fehlerrate. Keines davon bewertet die Outputs des Kandidaten gegen die tatsächlichen Fragen, die die Produktion gerade jetzt stellt. Der Kandidat erhält dieselben Prompts, die das aktive Release gerade bekommen hat, fährt sie auf einem 5-%-Mirror und wir messen das Spearman-ρ der Kandidatenantworten gegen den kalibrierten Grader. Die 5xx-Rate kann sauber bleiben, während das Modell leise hedged, verweigert oder halluziniert. Wir haben das beobachtet. Der Trace-Replay-Monitor ist das, was es einfängt.

Das Replay-Set ist begrenzt — wir kappen bei 50 aktuellen Traces pro Slice pro Checkpoint, damit die Kosten vorhersehbar sind. Das Grading dauert bei 5 % Traffic etwa 90 Sekunden. Langsamer als ein flacher Prozent-Canary, schneller als auf ein Kundenticket zu warten.

# Der Roll-Befehl ist Fire-and-Forget. Die Pipeline hält sich selbst.
curl -X POST https://api.divinci.ai/v1/releases/rel_a01c66/roll \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -d '{ "strategy": "canary", "dwell_5pct_seconds": 240, "dwell_25pct_seconds": 900 }'
# → { "rollout_id": "rol_b3e2", "next_checkpoint_at": "2026-05-26T09:04:00Z" }

Stufe 4 — Observe, Rollback und der Beleg

Das ist die Stufe, die der Pipeline ihre Existenzberechtigung gibt.

Der Observer läuft nach Abschluss des Rollouts kontinuierlich weiter. Er berechnet einen Output-Qualitätsscore pro Minute auf einer rollierenden 5-%-Trace-Replay-Stichprobe. Fällt der Score unter den Rollback-Schwellenwert (Default: 0,85 des Gate-Schwellenwerts, also 0,55 wenn das Gate 0,65 war) für drei aufeinanderfolgende Minuten, feuert das Rollback automatisch. Keine Page, kein Mensch, keine Debatte.

Das Rollback selbst ist eine einzige Anweisung: Routing wieder auf previous_release aus dem Manifest zeigen lassen. Weil das vorherige Release ein vollständig gebündeltes Manifest war, kippt jede Komponente — Gewichte, Prompt, Routing, Datensatz — atomar um.

Dann feuert der Beleg.

Jede Release-Entscheidung — Register, Gate-Pass, Gate-Fail, Gate-Override, Checkpoint-Promote, Checkpoint-Hold, Auto-Rollback, Manual-Rollback — emittiert einen Release-Beleg: ein JSON-mit-SHA-256-Artefakt, hash-verkettet mit dem vorherigen Beleg dieses Kunden und dem vorherigen Beleg dieses Releases, extern verankert auf einem vom Kunden konfigurierten Zeitplan.

Wenn das Release von einem Open-Weights-Modell getragen wird — Gemma, Qwen, Llama, Mistral, GPT-OSS, alles, dessen Gewichte adressierbar und editierbar sind — bettet der Beleg eine Vindex-Attestation ein: einen kryptografischen Beweis, dass die aktiven Gewichte zum Entscheidungszeitpunkt die Gewichte sind, die das Manifest registriert hat. Das ist der Pfad, der die härteren Compliance-Anforderungen erfüllt (GDPR Artikel 17 Recht auf Vergessenwerden, EU AI Act Provenance), weil man nicht nur beweisen kann, was deployt wurde, sondern dass die zugrundeliegenden Gewichte sind, was sie zu sein vorgeben.

Wenn das Release von einem Closed-Weights-Modell getragen wird — OpenAI, Anthropic, Google, alles, was nur über eine intransparente API ausgeliefert wird — deckt der Beleg weiterhin die Entscheidungskette ab (welches Manifest, welches Gate-Ergebnis, welche Monitor-Messung, welcher User welche Aktion ausgelöst hat), kann aber die zugrundeliegenden Gewichte nicht attestieren, weil wir sie nicht sehen können. Das ist keine Limitierung der Pipeline; es ist eine Limitierung dessen, was verifizierbar ist, wenn der Anbieter keine Gewichte offenlegt. Auditoren, denen diese Unterscheidung wichtig ist, bekommen die wahrheitsgemäße Antwort direkt im Beleg.

So oder so: Auditoren bekommen heute Logs. Mit dieser Pipeline bekommen sie Beweise für alles, was tatsächlich beweisbar ist. Wir haben am Markt niemand anderen gesehen, der das ausliefert. Wir erwarten, dass sie das tun werden — die Zeitlinien des EU AI Act machen es irgendwann unausweichlich. Wir haben uns entschieden, es jetzt auszuliefern.

Das sind nicht unsere Zahlen — es sind veröffentlichte Primärquellenzahlen aus echten Postmortems, Plattform-Dokumentationen und dem DORA-Framework. Der Kontrast ist es, der Divincis Design motiviert. Atlassians April-2022-Ausfall^[1] dauerte zwölf Stunden pro Site, weil der Zustand über mehrere Systeme verstreut war, die wieder in Übereinstimmung koordiniert werden mussten. Cloudflares Juni-2022-Ausfall^[2] brauchte vierundvierzig Minuten zum Zurückrollen, weil — in ihren eigenen Worten — Engineers sich gegenseitig die Reverts überschrieben. AWS SageMakers Canary-Deployment-Guardrails^[4] dokumentieren einen Default von zehn Minuten Termination-Wait, bevor das Rollback vollständig abgeschlossen ist. Die DORA-^[3]Elite-Schwelle für Recovery nach fehlgeschlagenem Deployment liegt bei „unter einer Stunde“ — das ist die Latte, die eine High-Performing-Org reißen soll, nicht die Obergrenze.

Zwölf Sekunden sind auch keine Zauberzahl. Es ist die Zeit, die der Routing-Layer braucht, um in-flight Requests zu drainen, das aktive Manifest umzuschalten und den neuen Zustand regionsweit zu acknowledgen. Der langsame Teil ist der In-flight-Drain. Es gibt keinen schnelleren Weg, der nicht Responses mitten in der Generation droppt.

Was das ist — und was andere LLM-Release-Tools nicht sind

Wir haben 2026 zwölf andere Tools untersucht, bevor wir das hier gebaut haben — LangSmith Deployment, W&B Models, MLflow, SageMaker Deployment Guardrails, Vertex AI Endpoints, Seldon Core, BentoCloud, KServe, Humanloop, Braintrust, Patronus AI, Arize Phoenix. Sie clustern sich in zwei Lager, die sich nicht ganz treffen.

Das Eval-CI-Lager — Braintrust, Humanloop, Patronus — gated PR-Merges auf Basis offline-berechneter Eval-Scores. Sie fassen den laufenden Service nie an. Wenn das Modell in Produktion ist und die Qualität fällt, schlagen sie Alarm; jemand anderes muss zurückrollen.

Das Serving-Canary-Lager — SageMaker Deployment Guardrails, KServe, Vertex AI, BentoCloud, Seldon Core — splittet Traffic und rollt automatisch zurück. Aber jedes davon triggert auf Infrastruktur-Metriken: p99-Latenz, Fehlerrate, CloudWatch-Alarme. Keines davon rollt automatisch bei einer Qualitätsregression zurück. Sie können es nicht, weil sie keinen Judge auf Produktions-Output laufen haben.

Die Nahtstelle zwischen „Eval beim PR-Merge bestanden“ und „Live-Canary bewertet auf den User-Journeys, die uns wirklich wichtig sind“ ist eine manuelle Übergabe, die jedes Team derzeit selbst überbrücken muss. Der Blogpost benennt das als den dominanten 2026-Failure-Mode^[6]. Wir haben sie geschlossen. Konkret:

1. Das Gate ist gesliced. Spearman ρ pro Domäne gegen einen human-anchored Grader, nicht ein einziger globaler Score. Slice-Blindheit ist das, was jedes andere Gate hat.
2. Der Canary überwacht Output-Qualität, nicht nur p95. Kontinuierliches Trace-Replay durch den Kandidaten, bewertet vom selben Judge, der das Gate antreibt. Das ist die fehlende Nahtstelle.
3. Jede Entscheidung emittiert einen Release-Beleg. Hash-verkettet, extern verankerbar, im JSON-mit-SHA-256-Format, das auch unsere Compliance-Seiten trägt. Bei Open-Weights-Backings — Gemma, Qwen, Llama, Mistral, GPT-OSS — bettet der Beleg eine Vindex-Weight-Attestation ein, damit Auditoren beweisen können, was die Live-Gewichte tatsächlich waren. Bei Closed-API-Backings deckt der Beleg die Entscheidungskette ab, beansprucht aber keine Gewichts-Provenance, weil der Anbieter keine Gewichte offenlegt. So oder so bekommen Auditoren Beweise für das tatsächlich Beweisbare, nicht nur Logs.

Das war’s. Generischer Canary, Versionsregister, Infrastruktur-Metrik-Rollback — das ist Commodity. Wir haben keinen generischen Canary geschrieben.

Was das nicht löst

Drei ehrliche Limitierungen:

Das Gate ist nur so gut wie der Datensatz. Eine Scored-QA-Suite, die die tatsächlich genutzte Domäne eines Kunden nicht abdeckt, erwischt Regressionen in dieser Domäne nicht. Wir haben das zweimal erlebt. Beide Male war der erste Schritt des Kunden, eine neue Scored-QA-Suite auszuliefern — nicht das Modell zu wechseln. Das ist der richtige Schritt.

Das Rollback geht davon aus, dass das vorherige Release gut war. Wenn eine Regression seit drei Releases live ist und niemand sie bemerkt hat, kauft ein Rollback um ein Release nur ein etwas weniger schlechtes Modell. Der Audit-Trail hilft hier — man kann via SHA auf jedes frühere Manifest zurückrollen, nicht nur auf N-1.

Cold-Start-Releases umgehen den Canary. Ein brandneues Modell ohne Produktionsverkehr zum Vergleich kann nicht sinnvoll canary’d werden. Wir erzwingen stattdessen ein 24-stündiges Shadow-Deployment, das Outputs beobachtet, ohne sie auszuliefern. Es ist langsamer und unbequemer. Es ist auch die einzige ehrliche Antwort.

Die kleinste Variante, die Sie selbst betreiben können

Wenn Sie etwas Vergleichbares ohne Divinci hochziehen wollen, sieht die Minimal-Variante ungefähr so aus:

1. Ein Registry, das Modell + Prompt + Routing + Datensatz als ein einziges unveränderliches Artefakt speichert, adressiert per Content-Hash
2. Ein Judge, kalibriert via Spearman ρ gegen ein human-anchored Panel — und eine Gate-Entscheidung, die pro Slice Scores konsultiert, nicht nur das Aggregat
3. Ein Traffic-Splitter, der an Checkpoints hält und einen frische-begrenzten Qualitätsmonitor konsultiert — wobei der Monitor aktuelle Produktions-Traces durch den Kandidaten replayed, nicht nur synthetische Stichproben zieht
4. Ein Routing-Layer, dessen Zustand atomar getauscht werden kann — inklusive Prompt-Template, nicht nur Gewichte
5. Ein Audit-Log, das für jede Release-Entscheidung einen hash-verketteten, extern verankerbaren Beleg emittiert — plus ein Weight-Attestation-Embed, wenn das Modell Open-Weights ist, da Closed-API-Releases auf Gewichtsebene physisch nicht attestiert werden können

Die meisten Teams haben (1) und (3) bereits. Die schmerzhaften Teile sind (2), (4) und (5). Der Grund, warum Divinci existiert, ist: wir haben alle fünf erst für uns selbst gebaut und dann gemerkt, dass alle anderen sie auch brauchen werden.

Wenn Sie sich den Build sparen wollen, die API-Referenz finden Sie hier, und die Release-Endpunkte im Abschnitt „Release Management“ sind die gesamte Oberfläche dieser Pipeline. Die Compliance-Seite — wie diese Vindex-Belege aussehen und wie sie auf EU AI Act, GDPR Artikel 17, HIPAA und NIST AI RMF abbilden — finden Sie auf der Compliance-Seite. Jeder Befehl in diesem Post ist ein echter Endpunkt.

Referenzen

1. Atlassian — Post-Incident Review: April 2022 Outage. Aus dem Bericht: „The accelerated Restoration 2 approach took approximately 12 hours to restore a site." Die vollständige Wiederherstellung von 883 Kunden-Sites dauerte 14 Tage. Über Infrastruktur, Backups und Site-Validierung verteilter Zustand treibt die Pro-Site-Zahl in Stunden statt Minuten.
2. Cloudflare — Cloudflare outage on June 21, 2022. Wörtlich aus dem Post zitierte Timeline: „06:58: Root cause found and understood. Work begins to revert the problematic change… 07:42: The last of the reverts has been completed." Vierundvierzig Minuten von „wir wissen, was wir zurückrollen müssen" bis „das Revert ist durch" — unter anderem, weil sich Engineers gegenseitig die Reverts überschrieben.
3. DORA — Software delivery performance metrics. Die Elite-Performer-Schwelle für „failed deployment recovery time" ist mit unter einer Stunde dokumentiert. Low Performer messen in den historischen DORA-Reports in Wochen bis Monaten.
4. AWS SageMaker — Use canary traffic shifting und die begleitende Seite Auto-Rollback Configuration and Monitoring. Das Beispiel für TerminationWaitInSeconds ist 600 (zehn Minuten); MaximumExecutionTimeoutInSeconds ist auf 1800 (dreißig Minuten) gedeckelt. Rollback feuert während des Baking-Fensters, sobald ein Alarm auslöst: „If any of the alarms trip during the baking period, then SageMaker AI initiates a rollback and all traffic returns to the blue fleet."
5. Divinci AI — atomarer Routing-Flip via Release-Manifest. Zwölf Sekunden sind die In-flight-Drain-Zeit auf einem Service mit rund 100 Replicas; das Manifest-Swap selbst ist Sub-Sekunden. Die Zahl stammt aus unserem eigenen Service, nicht aus einem Benchmark; die Architektur, die das möglich macht, ist das oben beschriebene gebündelte Manifest (Stufe 1 — Register).
6. Tianpan — The Semver Lie: how an LLM minor update breaks production (April 2026). Der Beitrag benennt das Failure-Muster direkt: „passed code review, deployed without eval gates, hit production without per-user A/B, and triggered no automatic rollback." Ein Begleit-Post — LLM postmortem template — fields SRE missed — listet die Slice- / Journey- / Per-User-Felder auf, die aktuelle Postmortems systematisch auslassen.

Eine Anmerkung dazu, was nicht in diesem Diagramm steht. Die Zeit für kubectl rollout undo in Kubernetes wird von Ihren maxSurge- / maxUnavailable-Settings und dem Pod-Warm-up bestimmt, nicht vom Befehl selbst, und wir konnten keine Primärquelle finden, die eine gemessene Zahl in der Art veröffentlicht, wie es die vier obigen Quellen tun — also haben wir sie weggelassen, statt sie mit einer Schätzung zu füllen.

Als Nächstes in dieser Serie: 10 CI/CD-Release-Ausfälle, die wir in Custom-LMs eingefangen haben — und welche Stufe der Pipeline jeden davon erwischt. Drei der zehn sind slice-aware Regressionen, die ein Aggregat-Gate ausgeliefert hätte. Zwei weitere sind stille Qualitätsabfälle, die ein Infrastruktur-Metrik-Canary durchgewinkt hätte. Der Rest sind die Sorte Failure Mode, die jede Release-Pipeline eigentlich erwischen sollte — wir listen sie, weil es sich lohnt, laut auszusprechen, welche eine Aggregat-gegatete Pipeline tatsächlich von selbst einfängt.