Betrieb von Modellen

Was ist MLOps?

Machine Learning Operations

MLOps bündelt die Verfahren, mit denen ein Team Modelle reproduzierbar trainiert, versioniert, ausrollt und überwacht. Aus einem Experiment im Notebook wird damit ein Dienst, auf den sich andere Systeme und andere Abteilungen verlassen können.

Sobald ein Modell aus dem Versuchsstadium heraus soll, steht die Frage im Raum, wer es künftig ausrollt, überwacht und im Zweifel wieder zurückdreht.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Kommt von: DevOps, übertragen auf Modelle und Daten
Versioniert: Daten, Code, Modell und Konfiguration
Überwacht: Datenqualität, Drift und Vorhersagegüte
Verwechselt mit: Reinem Deployment

Die Bausteine einer Pipeline

Am Anfang steht die Version der Daten. Ohne einen festgehaltenen Stand des Trainingsdatensatzes lässt sich ein Ergebnis später nicht reproduzieren, egal wie sauber der Code verwaltet ist. Danach folgt die Vorverarbeitung als Code statt als Handgriff im Notebook, damit beim späteren Betrieb genau dieselben Schritte laufen wie beim Training.

Der Trainingslauf protokolliert Parameter, Metriken und die verwendete Codeversion. Das fertige Modell landet mit diesen Angaben in einer Registry, die für jede Version festhält, woher sie stammt und ob sie freigegeben ist. Das Ausrollen erfolgt dann als reguläres Deployment, meist als Container hinter einer Schnittstelle, mit einem Weg zurück auf die vorherige Version.

Den Abschluss bildet die Überwachung, und zwar nicht nur der technischen Verfügbarkeit. Interessant sind die Verteilungen der Eingaben und die Qualität der Ausgaben, denn ein Modell kann fehlerfrei antworten und trotzdem falsch liegen.

Warum Modelle im Betrieb altern

Ein Modell lernt die Welt in dem Zustand, in dem sie zum Trainingszeitpunkt war. Ändert sich das Verhalten der Kundschaft, kommt ein neues Produkt dazu oder liefert ein Vorsystem ein Feld plötzlich in anderem Format, weichen die Eingaben von dem ab, worauf trainiert wurde. Die Vorhersagen werden schleichend schlechter, ohne dass irgendwo ein Fehler auftaucht.

Deshalb gehört zu jedem produktiven Modell die Frage, woran ein Nachtrainieren ausgelöst wird: an einem Zeitplan, an einer gemessenen Abweichung in den Eingabedaten oder an einer gefallenen Qualitätskennzahl. Wer das nicht vorab festlegt, merkt das Problem erst, wenn sich die Fachabteilung beschwert.

Der Fehler, der am meisten kostet

Der teuerste Zustand ist ein Modell in Produktion, das niemand nachbauen kann, weil der Trainingsstand der Daten fehlt, das Notebook seither weiterbearbeitet wurde und die verwendeten Bibliotheksversionen nirgends stehen. Fällt es aus oder wird es auffällig, bleibt nur der Neuanfang.

Genauso oft fehlt der Rückweg. Eine neue Modellversion wird ausgerollt, weil sie in der Messung besser aussah, und erst im Betrieb zeigt sich das Gegenteil. Ohne die vorherige Version in der Registry und ohne einen geprobten Rückschalter wird daraus ein langer Abend.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

MLOps und was oft damit gleichgesetzt wird

MLOps gegen DevOps

Die Grundidee ist dieselbe, das Artefakt ist ein anderes. Bei MLOps gehören die Daten zur Version dazu, und die Qualität hängt nicht nur vom Code ab, sondern von einem Datenstand, der sich weiter verändert.

MLOps gegen Model Deployment

Das Ausrollen ist ein einzelner Schritt innerhalb von MLOps. Ohne Versionierung davor und Überwachung danach ist ein Deployment nur ein Modell, das erreichbar ist.

MLOps gegen LLMOps

Beim Betrieb von Sprachmodellen verschiebt sich der Schwerpunkt: Statt Trainingsläufen verwaltest du Prompts, Bewertungsdatensätze und Tokenkosten. Registry, Versionierung und Monitoring bleiben aber dieselben Bausteine.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Der Bruch liegt zwischen Training und Betrieb

Der teuerste Fehler ist, dass Merkmale beim Training anders berechnet werden als später im Betrieb. Im Notebook entsteht ein Wert aus einer sauber aufbereiteten Tabelle, im laufenden System aus einem Aufruf mit anderer Rundung, anderer Zeitzone oder fehlenden Feldern. Das Modell sieht dann etwas anderes als das, worauf es trainiert wurde, und die Güte fällt ohne erkennbare Ursache.

Dazu kommt, dass Modelle altern, weil sich die Welt ändert: neue Produkte, andere Kundschaft, ein umgestelltes Vorsystem. Wer nur Verfügbarkeit und Antwortzeit überwacht, sieht davon nichts, denn die Anwendung läuft ja. Beobachten musst du die Verteilung der Eingaben und die Trefferquote der Vorhersagen, letztere oft erst mit Wochen Verzug, weil das tatsächliche Ergebnis erst später bekannt wird.

Und es muss einen Rückweg geben. Zu einem Modell im Betrieb gehören die Version der Daten, der Code, die Parameter und die Möglichkeit, in Minuten auf den Vorgänger zurückzuschalten. Ohne das wird jede Aktualisierung zu einem Ereignis, das niemand gern anfasst.

MLOps lernen

Wie eine Pipeline von der Datenversion bis zum Rückschalter aussieht, bauen die Kurse zum produktiven Ausrollen von Modellen einmal komplett auf.

Welche Hardware und welche Betriebsform darunter sinnvoll ist, behandeln die Angebote rund um KI-Infrastruktur und Administration .

Wissen prüfen

Sitzt MLOps schon?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Wissenstest KI Grundlagen QuizTeste dein Verständnis für Sprachmodelle, Kontextfenster, Halluzinationen und den sicheren Umgang mit KI im Job. Quiz starten

Kurse, die MLOps behandeln

Häufige Fragen

Brauche ich MLOps auch, wenn ich nur fertige Modelle einkaufe?

Ja, in abgespeckter Form. Auch ein eingekauftes Modell hat Versionen, die sich beim Anbieter ändern, und deine Ergebnisse ändern sich mit. Ohne festgehaltene Version, gespeicherte Prompts und einen Testsatz kannst du nach einem Anbieterwechsel nicht belegen, ob es besser oder schlechter geworden ist.

Was gehört mindestens in eine Modell-Registry?

Zu jeder Version die Herkunft: welcher Datenstand, welche Codeversion, welche Parameter, welche Metriken auf welchem Testsatz, wer sie freigegeben hat und ob sie gerade produktiv ist. Damit lässt sich jede Frage aus einer Prüfung beantworten, ohne im Chatverlauf zu suchen.

Wie oft sollte man neu trainieren?

So oft, wie sich die Daten ändern, und nicht nach Gefühl oder festem Kalender. Bei stabilen technischen Prozessen kann ein Modell lange tragen, bei Preisen oder Kundenverhalten deutlich kürzer. Sinnvoll ist, die Abweichung der Eingabedaten zu messen und daran den Auslöser zu hängen.

Passt thematisch dazu

Wie die einzelnen Schritte im Alltag zusammengreifen, vom verpackten Artefakt bis zum Rollback in Minuten, beschreibt der Weg vom Notebook zur überwachten Schnittstelle .

Persönlich für dich da