Betrieb

MLOps (LLMOps)

Definition

MLOps bündelt die Praktiken, um KI-Anwendungen zuverlässig in Produktion zu bringen und zu halten - Versionierung, automatisiertes Testen, Deployment, Überwachung und kontrolliertes Aktualisieren.

Ein Modell im Notebook ist kein Produkt. MLOps (für Sprachmodelle auch LLMOps) überträgt die Disziplin moderner Softwareauslieferung auf KI: Prompts, Modelle und Datenquellen werden versioniert, Änderungen automatisiert gegen Evaluations-Testsätze geprüft, Releases kontrolliert ausgerollt und im Betrieb überwacht.

Das ist entscheidend, weil KI-Systeme sich verändern, ohne dass man den Code anfasst: Ein Anbieter aktualisiert sein Modell, Nutzerverhalten verschiebt sich, Daten veralten. Ohne MLOps bemerkt man Qualitätsabfall erst durch Beschwerden. Mit MLOps schlagen automatische Prüfungen und Monitoring an, bevor Nutzer betroffen sind - die Grundlage für verantwortbaren Dauerbetrieb.

In der Praxis

Ein technischer Großhändler bemerkt einen stillen Modellwechsel

Ein Großhändler für Antriebstechnik mit 400 Mitarbeitenden betreibt im Online-Shop einen Beratungsassistenten, der aus Datenblättern die passende Komponente vorschlägt. Er läuft seit acht Monaten ohne Auffälligkeiten. An einem Dienstag im Frühjahr häufen sich Rückfragen des Innendienstes: Der Assistent nenne plötzlich Alternativartikel, die gar nicht mehr im Sortiment sind. Am Code hat niemand etwas geändert.

Der Grund war ein planmäßiges Modell-Update beim Anbieter. Die aufgerufene Modellbezeichnung zeigte nicht auf eine feste Version, sondern auf „die jeweils aktuelle“ - und das neue Modell interpretierte eine Formulierung im System-Prompt anders als sein Vorgänger. Ohne Versionsangabe, ohne automatischen Testlauf und ohne protokollierte Anfragen begann die Fehlersuche bei null: Drei Entwickler brauchten anderthalb Tage, um überhaupt zu belegen, dass sich nicht die eigene Anwendung verändert hatte.

Danach wurde nachgerüstet, was MLOps ausmacht - und der Aufwand war überschaubar: Die Modellversion wird ausdrücklich festgeschrieben statt implizit gewählt. Prompts liegen versioniert im Repository, nicht in der Datenbank. Vor jedem Ausrollen läuft ein Testsatz aus 80 typischen Beratungsfällen automatisch durch, und derselbe Satz läuft zusätzlich einmal pro Nacht gegen die Produktivumgebung. Der nächste Anbieterwechsel war damit kein Vorfall mehr, sondern ein Termin im Kalender: Version testen, Abweichungen ansehen, umschalten.

Abgrenzung

Nicht zu verwechseln mit

DevOps: DevOps sorgt dafür, dass sich Code zuverlässig bauen, testen und ausliefern lässt. MLOps kommt mit den Artefakten hinzu, die kein Code sind und sich trotzdem auf das Verhalten auswirken: Prompts, Modellversionen, Wissensbestände, Bewertungskriterien. Wer MLOps für „DevOps mit anderem Namen“ hält, versioniert am Ende die Anwendung und nicht das, was ihr Verhalten bestimmt.
Observability: Observability ist ein Baustein von MLOps, nicht sein Ersatz: Sie zeigt, was im Betrieb passiert. MLOps umfasst zusätzlich den Weg dorthin - Versionierung, automatisierte Prüfung vor dem Ausrollen, kontrollierte Freigabe und den Rückweg im Fehlerfall.
Evaluation: Evaluation ist das Messverfahren, MLOps die Maschinerie, die dieses Verfahren verlässlich zum richtigen Zeitpunkt auslöst - vor jedem Ausrollen, nach jedem Modellwechsel, regelmäßig im Betrieb. Eine Evaluation, die nur läuft, wenn jemand daran denkt, ist noch kein Betrieb.

Fehlerbilder

Worauf es ankommt

Prompts leben außerhalb der Versionierung
Prompts landen aus Bequemlichkeit in einer Datenbanktabelle oder in einem Konfigurationsfeld der Oberfläche, wo sie jederzeit jemand ändern kann. Sechs Wochen später weiß niemand mehr, welcher Wortlaut zu welchem Zeitpunkt aktiv war - und damit lässt sich weder eine Verschlechterung zuordnen noch ein früherer Stand wiederherstellen. Prompts gehören in dieselbe Versionsverwaltung wie der Code, mit Autor, Datum und Begründung.
Die Modellversion nicht festgeschrieben
Wer auf eine gleitende Bezeichnung wie „das aktuelle Modell“ zeigt, übergibt einem Dritten die Kontrolle über das Verhalten der eigenen Anwendung. Das Update kommt dann an einem beliebigen Tag und ohne Ankündigung im eigenen Kalender. Schreiben Sie die Version ausdrücklich fest und wechseln Sie bewusst - nach einem Testlauf, zu einem Zeitpunkt, an dem jemand hinsieht.
Kein Rückweg vorgesehen
Viele KI-Projekte können ausrollen, aber nicht zurückrollen: Der neue Prompt ist eingespielt, der alte nicht mehr auffindbar, die Wissensbasis wurde bei der Gelegenheit gleich neu indexiert. Damit wird aus einer Verschlechterung sofort ein Notfall. Ein definierter Rückweg auf den letzten bekannten guten Stand - Prompt, Modellversion, Index - kostet einmalig Aufwand und spart einen Krisentag.
Niemand ist nach dem Projektende zuständig
KI-Anwendungen werden häufig als Projekt finanziert und dann „fertig“. Es gibt aber keinen Zustand, in dem eine KI-Anwendung fertig ist: Modelle ändern sich, Inhalte veralten, Nutzung verschiebt sich. Benennen Sie vor dem Produktivgang, wer die Auswertungen ansieht, wer über einen Modellwechsel entscheidet und aus welchem Budget der laufende Betrieb bezahlt wird.

Häufige Fragen

Was zu MLOps (LLMOps) oft gefragt wird

Brauchen wir MLOps auch für eine einzelne kleine KI-Anwendung?

In abgespeckter Form ja. Vier Dinge lohnen sich ab dem ersten Produktivgang unabhängig von der Größe: Prompts in der Versionsverwaltung, eine festgeschriebene Modellversion, ein kleiner Testsatz, der vor jeder Änderung läuft, und ein definierter Rückweg. Das ist die Arbeit von wenigen Tagen. Alles Weitere - automatisierte Pipelines, Auswertungsdashboards, kontrollierte Teilausrollungen - können Sie nachrüsten, wenn die Anwendung wächst.

Können wir unsere bestehende CI/CD-Pipeline für KI nutzen?

In der Regel ja, und das ist auch der sinnvolle Weg. Die vorhandene Pipeline muss im Kern um zwei Schritte ergänzt werden: Der Evaluations-Testsatz läuft als zusätzlicher Prüfschritt mit, und Prompts sowie Modellversionen werden wie Artefakte behandelt, die zu einem Release gehören. Der Unterschied zu klassischem Software-Testing ist, dass das Ergebnis eine Quote ist und kein Grün oder Rot - Sie brauchen also eine Schwelle, ab der ein Release durchfällt.

Wer betreibt KI-Anwendungen in einem mittelständischen Unternehmen?

In der Praxis fast immer das bestehende Team, das schon die übrige Software betreibt - für den laufenden Betrieb braucht es keine eigene Abteilung. Neu ist eine zweite Rolle daneben: jemand aus dem Fachbereich, der die Qualität beurteilt, Testfälle pflegt und bei Abweichungen entscheidet, ob sie relevant sind. Diese fachliche Rolle wird beim Zuschnitt gern vergessen und ist erfahrungsgemäß der Engpass, nicht die Technik.

Was kostet MLOps?

Der Aufbau der Grundlagen bewegt sich bei einer einzelnen Anwendung im Bereich weniger Personentage, weil die meisten Bausteine - Versionsverwaltung, Pipeline, Monitoring - im Unternehmen bereits vorhanden sind und nur erweitert werden. Der laufende Anteil ist vor allem Disziplin und ein regelmäßiger Blick auf die Auswertungen. Teuer ist die Alternative: Fehlersuche ohne Protokolle, Qualitätsabfall, den Kunden zuerst bemerken, und Änderungen, die niemand mehr zuordnen kann.

Verwandte Begriffe