DevOps vs. MLOps vs. LLMOps: Wie generative KI produktionsreif wurde

Die bekannte Grafik stellt drei Pipelines wie aufeinanderfolgende Generationen dar. Zur Orientierung ist das nützlich, doch der entscheidende Punkt bleibt verborgen: DevOps, MLOps und LLMOps sind weder Konkurrenzprodukte noch Ablösungen füreinander. Sie sind betriebliche Antworten auf Artefakte, die immer schwieriger zu definieren und zu prüfen sind. Software brachte automatisierte Auslieferung, Machine Learning ergänzte Daten und statistisches Verhalten, Foundation Models fügten natürlichsprachlichen Kontext, externe Anbieter, Werkzeuge und semantische Risiken hinzu.

Dies ist die belegte Geschichte dieser Entwicklung und vor allem eine Anleitung dazu, was ein LLMOps-Team tatsächlich betreiben muss. Für MLOps oder LLMOps gibt es kein allgemein anerkanntes Geburtsdatum. Deshalb stützt sich die Zeitleiste auf überprüfbare Meilensteine, statt einen einzelnen Erfinder zu benennen.

Drei Namen, drei zu betreibende Artefakte

Das sind keine starren Teamgrenzen. Ein LLM-Produkt braucht weiterhin CI/CD, Secrets, Netzwerke, Rollbacks und SLOs. Besitzt es eigene Modellgewichte, kommen Datenherkunft und Model Registry hinzu. LLMOps erweitert DevOps und MLOps; es ersetzt sie nicht.

2009: DevOps und das Übergabeproblem

Auf der Velocity 2009 präsentierten John Allspaw und Paul Hammond 10+ Deploys per Day: Dev and Ops Cooperation at Flickr.^[flickr] Schon der Titel formulierte die These: häufige Releases entstehen nicht durch einen Helden, der ein Paket über die Mauer wirft, sondern durch Zusammenarbeit und Automatisierung. Im selben Jahr fand in Gent das erste DevOpsDays statt.^[devopsdays]

Eine dokumentierte Anekdote: Zehn Deployments pro Tag wirkten provokant, als viele Organisationen quartalsweise auslieferten. Die Lehre war nicht die Zahl zehn. Kleine Änderungen verkürzten Feedback und machten Entwicklung und Betrieb gemeinsam verantwortlich. DORA formalisierte später Liefermetriken und zeigte, dass Geschwindigkeit und Stabilität keine Gegensätze sein müssen.^[dora]

2015–2017: Als das Artefakt zu lernen begann

Bei ML entsteht Verhalten nicht mehr nur aus Code. Es hängt von Daten, Transformationen, Hyperparametern und der Einsatzwelt ab. Googles Arbeit über versteckte technische Schulden machte zwei Bilder bekannt: Modellcode ist nur ein kleiner Teil des realen Systems; in einem verflochtenen System kann jede Änderung alles andere beeinflussen.^[debt]

Daraus entstand der Bedarf, den wir heute MLOps nennen: Datensätze und Features reproduzieren, Schemata validieren, Experimente und Modelle registrieren, Training-Serving-Skew vermeiden, Drift überwachen und Retraining auslösen. Der ML Test Score von 2017 beschrieb 28 Tests und Monitoring-Anforderungen für Produktionsreife.^[mltest]

Eine messbare Geschichte: Das TFX-Paper beschreibt, wie Google fragile Glue-Skripte durch standardisierte Komponenten ersetzte. Bei einem Einsatz für Google Play wurden Modelle mit neuen Daten aktualisiert. Die Autoren berichten von schnelleren Experimenten, einem Weg in die Produktion von Monaten auf Wochen und 2 % mehr App-Installationen im Zusammenhang mit besserer Daten- und Modellanalyse.^[tfx] Das ist das Ergebnis dieses Falls, kein allgemeines Versprechen.

MLOps ergänzte CI/CD um Continuous Delivery der ML-Pipeline und Continuous Training. Die Architekturhilfe von Google Cloud unterscheidet den manuellen Prozess, automatisierte ML-Pipelines und vollständige CI/CD-Automatisierung.^[mlops]

2020–2022: Vom Einzelmodell zum Foundation-System

Drei Entwicklungen bereiteten LLMOps vor. RAG verband 2020 parametrisches Gedächtnis mit einem externen Index und ermöglichte aktualisierbares Wissen samt Herkunft.^[rag] Der Stanford-Bericht von 2021 festigte anschließend den Begriff Foundation Model: ein breit trainiertes Modell für viele Aufgaben — mit großer Hebelwirkung und dem Risiko, dass viele Produkte dieselben Fehler erben.^[foundation]

2022 zeigte InstructGPT, dass Human-Feedback die Nützlichkeit stark verändern kann: In der Prompt-Verteilung der Autoren bevorzugten Bewertende das 1,3-Milliarden-Modell gegenüber GPT‑3 mit 175 Milliarden Parametern, obwohl weiterhin einfache Fehler auftraten.^[instruct] HELM forderte im selben Jahr mehrdimensionale, transparente Evaluation statt einer einzelnen Benchmark-Zahl.^[helm]

In diesem Umfeld verbreitete sich der Name LLMOps. Er bedeutet weder „MLOps plus Prompt“ noch setzt er das Training eines Foundation Models voraus. Viele Anwendungen trainieren keine Gewichte: Sie betreiben APIs, Prompts, Retrieval, Tools und Regeln. Ihre Änderungseinheit ist das zusammengesetzte LLM-System.

Was LLMOps tatsächlich betreibt

1. Ein versioniertes Bundle, kein einzelner Prompt

Eine deploybare Version muss mindestens Anbieter und Modellversion, Inferenzparameter, Systemnachrichten und Templates, Tool-Schemata, RAG-Korpus, Parser, Chunking, Embeddings und Index, Sicherheitsrichtlinien, Evaluationssatz und Orchestrierungscode identifizieren. Derselbe sichtbare Prompt kann ein anderes Produkt sein, sobald sich eine dieser Komponenten ändert.

Die Promotion muss unveränderlich sein: app@sha + prompt@sha + index@snapshot + eval@version + policy@version + model@id. Ohne rekonstruierbare Kombination lassen sich Vorfälle weder erklären noch zuverlässig zurückrollen.

2. Evaluation vor Optimierung

Softwaretests erwarten einen Wert. Sprache erlaubt mehrere richtige Formen — und elegante Falschaussagen. LLMOps beginnt daher mit einem Evaluationsdatensatz aus realen Aufgaben, Grenzfällen und vorhersehbarem Missbrauch. Jeder Fall braucht eine Bewertungsrubrik, nicht nur einen Golden String.

• Aufgabenqualität: Korrektheit, Vollständigkeit, Format und Befolgen von Anweisungen.
• RAG: Retriever-Recall, Kontextrelevanz, Antworttreue und Zitatqualität; Retrieval und Generator getrennt bewerten.
• Sicherheit: direkte und indirekte Injection, Datenabfluss, Tool-Missbrauch und unzulässige Inhalte.
• Betrieb: End-to-End-Latenz, Tokens, Kosten, Retries, Fehlerrate und Quoten.

LLM-as-a-Judge skaliert Bewertungen, ist aber selbst ein Modell. Judges müssen gegen Menschen kalibriert, versioniert und auf Abweichungen geprüft werden. Ein Release-Gate kombiniert deterministische Checks, Judges, adversariale Tests und menschliche Stichproben.

3. RAG als Online-Datenpipeline

RAG ist nicht „eine Vektordatenbank anschließen“. Es ist eine Kette: Dokumentberechtigung → Extraktion → Bereinigung → Chunking → Embeddings → Indexierung → Retrieval → Reranking → Kontextaufbau → Generierung → Zitate. Jeder Pfeil kann sich verschlechtern.

Korpus und Index müssen versioniert, Aktualität gemessen, ACLs durchgesetzt und Chunk-IDs in Traces gespeichert werden. Retrieval kann Grounding verbessern, macht eine Ausgabe aber nicht automatisch wahr und beseitigt Prompt Injection nicht; OWASP weist ausdrücklich darauf hin.^[owasp]

4. Semantische Observability und FinOps

HTTP 200 bedeutet nicht, dass eine Antwort geholfen hat. Ein Trace muss Eingabe, Policy, Retrieval, Reranking, Modellaufrufe, Tools, Retries und Endausgabe verbinden. OpenTelemetry definiert Konventionen für Modelle, Tokens, Nachrichten und Tool Calls. Inhaltsaufzeichnung bleibt optional, weil sie sensible Daten enthalten kann.^[otel]

Gute Dashboards verbinden Qualität und Betrieb: Aufgabenerfolg und Groundedness pro Version, p50/p95/p99-Latenz, Ein- und Ausgabetokens, Kosten pro abgeschlossener Aufgabe, Cache-Hit-Rate, Agententiefe, Tool-Fehler und menschliche Eskalationen. Ein günstiges Token wird teuer, wenn ein Agent Schleifen dreht.

SLOs sollten aus Nutzersicht definiert werden — Verfügbarkeit, Latenz und Korrektheit.^[sre] Beispiel: „95 % autorisierter Richtlinienfragen werden in weniger als sechs Sekunden mit gültigem Beleg und ohne tenantübergreifende Offenlegung beantwortet.“

5. Sicherheit, Governance und begrenzte Agency

Das Modell verarbeitet Daten und Anweisungen im selben Kanal. Diese Mehrdeutigkeit macht Prompt Injection zu einem Architekturproblem, nicht zu einem nachträglichen Filter. OWASP führt LLM-spezifische Risiken; das NIST-Profil strukturiert Maßnahmen zum Steuern, Messen und Managen generativer KI.^{[nist][owasp]}

• Abgerufene Texte, Webseiten und Tool-Ergebnisse als nicht vertrauenswürdig behandeln.
• Least Privilege pro Tool; Lesen, Vorschlagen und Ausführen trennen.
• Ausgaben vor SQL, Shell, E-Mail, Zahlung oder Infrastrukturänderung validieren.
• Für irreversible oder folgenreiche Aktionen menschliche Freigabe verlangen.
• Aufbewahrung, PII-Redaktion, Datenresidenz und Trace-Zugriff festlegen.
• Kill Switch, Schritt- und Budgetgrenzen, Timeouts und Rollback bereitstellen.

Eine LLMOps-Produktionspipeline in neun Schritten

1. Aufgabe und Risiko definieren: Zweck, Befugnisse, Verantwortung und verbotene Ergebnisse.
2. Evaluationssatz bauen: Normalfälle, Ränder, Sprachen, relevante Gruppen und Angriffe.
3. Nach Einschränkungen auswählen: Aufgabenqualität, Latenz, Datenschutz, Region, Kontext, Tools und Kosten.
4. Kontext bauen: RAG nur für Wissen oder Nachvollziehbarkeit; ACL, Herkunft und Aktualität bewahren.
5. Vor dem Launch instrumentieren: Versions- und Korrelations-IDs, Spans, Tokens, Kosten, Eval-Ergebnisse.
6. Offline-Gates ausführen: Regression, Sicherheit, Last und Budget.
7. Shadow oder Canary deployen: Reales Verhalten vergleichen, ohne volle Agency zu gewähren.
8. Produktion sampeln: automatische Signale, kontextuelles Feedback, datenschutzkonforme Human Review.
9. Das ganze Bundle promoten oder zurückrollen: Modell, Prompt, Index, Tools und Policy gemeinsam.

Drei Anekdoten, die zu Betriebsregeln wurden

Flickr, 2009: In Erinnerung blieben „zehn Deployments pro Tag“, doch „Dev and Ops Cooperation“ war die dauerhafte Hälfte des Titels. Frequenz war die sichtbare Folge von kurzem Feedback und geteilter Verantwortung.^[flickr]

TFX, 2017: Das Produktionsproblem wurde nicht mit einem besseren Algorithmus gelöst, sondern durch den Ersatz von Ad-hoc-Glue durch eine wiederholbare Plattform. Das ist der Übergang von „wir haben ein Modell“ zu „wir können Modelle betreiben“.^[tfx]

Tay, 2016: Tay entstand vor modernen LLMs und war deshalb kein LLM-Vorfall. Operativ war der Fall dennoch wegweisend. Microsoft schrieb, dass in den ersten 24 Stunden ein koordinierter Angriff eine übersehene Schwachstelle ausnutzte; der Bot wurde offline genommen.^[tay] Labortests, Red Teaming, Live-Beobachtung und Abschaltpfad gehören zum Produkt.

Häufige LLMOps-Fehler

• Ein Prompt-Verzeichnis „Plattform“ nennen — ohne Evaluation, Lineage, Berechtigungen, Traces und Rollback ist es Ablage.
• Nur Halluzinationen messen — Nutzen, Enthaltung, Format, Sicherheit, Latenz und Kosten zählen ebenfalls.
• Alle Prompts ohne Datenschutzregeln loggen — Observability kann zur Schattenkopie sensibler Daten werden.
• Modelle direkt in Produktion tauschen — auch ein „besseres“ Modell verändert Stil, Tool Calls, Länge und Kosten.
• Tools mit Rechten des Service Accounts ausstatten — der Agent braucht den Scope des Nutzers oder einer Minimalidentität.

Die echte Entwicklung: Das Verantwortungsobjekt wird größer

DevOps machte Softwareänderungen betreibbar. MLOps ergänzte veränderliche Daten und Vorhersageverhalten. LLMOps ergänzt Kontext, Absicht und Handlung. Reife zeigt sich daran, fünf Fragen für jede Ausgabe beantworten zu können: Welche Version erzeugte sie, mit welchem Kontext, wie wurde sie bewertet, was durfte sie tun und was kostete sie?

Gibt es diese Antworten, kann das System ohne Glauben verbessert werden. Fehlen sie, bleibt die „LLMOps-Pipeline“ eine Demo mit Netzwerkroute zur Produktion.

Quellen und weiterführende Literatur

Primärliteratur, offizielle Dokumentation und Berichte der beteiligten Organisationen.

1. John Allspaw & Paul Hammond — 10+ Deploys per Day: Dev and Ops Cooperation at Flickr
2. DevOpsDays — Ghent 2009, official event archive
3. DORA / Google Cloud — 2019 Accelerate State of DevOps Report
4. Sculley et al. — Hidden Technical Debt in Machine Learning Systems
5. Breck et al. — The ML Test Score
6. Baylor et al. — TFX: A TensorFlow-Based Production-Scale ML Platform
7. Google Cloud Architecture Center — MLOps: Continuous delivery and automation pipelines
8. Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
9. Bommasani et al. — On the Opportunities and Risks of Foundation Models
10. Ouyang et al. — Training language models to follow instructions with human feedback
11. Liang et al. — Holistic Evaluation of Language Models (HELM)
12. Microsoft — Learning from Tay’s introduction
13. NIST AI 600-1 — Generative AI Profile
14. OWASP GenAI Security Project — Top 10 for LLM Applications
15. OpenTelemetry — Inside the LLM Call: GenAI Observability
16. Google SRE Book — Service Level Objectives