MLOps: vom Modell
zum produktiven System
MLOps ist die Praxis, Machine-Learning-Modelle zuverlässig in Betrieb zu nehmen und dort zu halten. Phase 06 des Data-Science-Prozesses: Deployment, Monitoring, Nachtraining.
Vom Prototyp in die Produktion
Deployment ist ein kontinuierlicher Prozess. Wir stellen zuverlässigen, wartbaren Betrieb sicher.
Infrastruktur
Produktive Bereitstellung, skalierbar und hochverfügbar.
Überwachung
Kontinuierliches Monitoring mit automatisierten Hinweisen.
Kontinuierliche Verbesserung
Prozesse für Modellaktualisierung bei veränderten Anforderungen.
Production-Monitoring-Dashboard
MLOps: Definition, Abgrenzung zu DevOps und drei Reifegrade
MLOps (Machine Learning Operations) ist die Praxis, ein trainiertes Modell in ein System zu überführen, das im Alltag Entscheidungen unterstützt: versioniert, automatisch getestet, in die Fachanwendung integriert, laufend überwacht und bei Bedarf nachtrainiert. MLOps überträgt die Praktiken der Softwareauslieferung (DevOps) auf Modelle, deren Verhalten nicht nur vom Code, sondern von Daten abhängt.
Ein Modell erzeugt erst dann Wert, wenn es produktiv Entscheidungen unterstützt. Und anders als eine Anwendung verhält es sich morgen anders, sobald sich die Daten ändern, die es sieht: neue Kunden oder eine getauschte Maschine. Deshalb beginnt die Verantwortung für ein Modell am Tag der Inbetriebnahme, statt dort zu enden.
MLOps und DevOps im Vergleich
| Frage | DevOps (Software) | MLOps (Modelle) |
|---|---|---|
| Was wird versioniert | der Code | Code, Daten und Modellstand |
| Was wird getestet | die Funktion des Codes | die Funktion des Codes, die Gültigkeit der Eingangsdaten und die Güte des Modells |
| Was passiert nach der Auslieferung | Betrieb und Fehlerbehebung | Betrieb, Überwachung auf Drift und geregeltes Nachtraining |
| Wann ist ein Release fertig | wenn die Tests bestehen | wenn die Tests bestehen und das neue Modell den bisherigen Stand schlägt |
Drei Reifegrade, in der Sprache des Mittelstands
Manuell
Ein Data Scientist trainiert das Modell auf seinem Rechner, übergibt eine Datei, jemand baut sie ein. Jedes erneute Training ist Handarbeit. Ob der Stand von heute dem von vor drei Monaten entspricht, weiß niemand sicher.
Teilautomatisiert
Training, Test und Bereitstellung laufen als wiederholbare Strecke, die ein Mensch anstößt. Jeder Modellstand ist versioniert und reproduzierbar, das Monitoring meldet Auffälligkeiten, ein erneutes Training bleibt eine bewusste Entscheidung.
Vollautomatisiert
Das System trainiert, prüft und ersetzt Modelle selbst, sobald festgelegte Grenzwerte verletzt werden. Sinnvoll bei vielen Modellen und schnell wechselnden Daten; verlangt eine Testabdeckung und ein Betriebsteam, die erst aufgebaut werden müssen.
ML-Deployment: sechs Schritte vom Code-Push bis zur Produktion
ML-Deployment, die Inbetriebnahme eines Modells, folgt bei uns der Strecke aus dem Diagramm weiter oben auf dieser Seite; Fachleute nennen sie MLOps-Pipeline. Für Sie zählt, dass jeder Schritt nachvollziehbar und wiederholbar ist.
- Code-Push: Eine Änderung an Code, Konfiguration oder Trainingsdaten landet im Repository und stößt die Strecke an. Nichts erreicht die Produktion an diesem Eingang vorbei, auch keine schnelle Korrektur am Freitagnachmittag.
- Test und Validierung: Automatische Tests prüfen den Code, Datenprüfungen die Eingangsdaten, und das neu trainierte Modell tritt gegen den aktuellen Produktionsstand an. Verliert es, endet die Strecke hier.
- Container-Build: Modell, Laufzeitumgebung und Abhängigkeiten werden zu einem Container gebündelt, der auf jedem Server gleich läuft. Der Satz „auf meinem Rechner ging es" verliert seine Grundlage.
- Staging: Der Container läuft in einer Kopie der Produktionsumgebung mit echten Schnittstellen und Datenformaten. Hier fallen Fehler auf, die kein automatischer Test sieht: eine falsche Zeitzone, ein umbenanntes Feld, eine Spalte aus dem ERP, die plötzlich leer ist.
- Canary: Ein kleiner Teil des Verkehrs oder ein einzelner Standort bekommt das neue Modell, der Rest bleibt beim alten. Weichen die Ergebnisse ab, geht es per Rollback zurück, bevor das Tagesgeschäft etwas merkt.
- Produktion: Das Modell übernimmt den vollen Betrieb, versioniert und mit dokumentiertem Stand; von jetzt an übernimmt das Monitoring, und jeder weitere Wechsel läuft wieder über Schritt 1.
Vier Bereitstellungsformen, je ein Anwendungsfall
Batch-Scoring
Das Modell rechnet einmal pro Nacht über alle Datensätze, etwa eine Bedarfsprognose je Artikel. Meist die günstigste Form, weil kein Dienst rund um die Uhr laufen muss.
Schnittstelle (API)
Ein Dienst antwortet auf Anfrage. Im Modul Predictive Maintenance geht der Hinweis, welche Anlage in wie vielen Tagen ausfallen dürfte und welches Wartungsfenster sich empfiehlt, automatisch ins Instandhaltungssystem; die Sensordaten kommen nur lesend aus dem Leitsystem.
Eingebettet im Fachsystem
Die Empfehlung erscheint dort, wo die Entscheidung fällt: im ERP oder in der Planungstafel. Im Mode-Modul zur Abschriften-Steuerung liefert das Modell zunächst Vorschläge, die das Category Management prüft; erst nach ein bis zwei validierten Saisons steigt der Automatisierungsgrad.
Im Browser oder auf dem Gerät
Kleine Modelle laufen direkt beim Nutzer, und die Daten verlassen das Gerät nicht. Unser Selbstversuch mit einem Drum-Modell zeigt diese Form: 397,4 Kilobyte Modellgewichte, die Vorhersage läuft vollständig im Browser, kein Upload.
Modell-Monitoring: Data Drift, Concept Drift und der Weg zum Nachtraining
Ein Modell fällt selten mit einer Fehlermeldung aus. Es wird leise schlechter. Modell-Monitoring misst, wie schnell die Güte sinkt, bevor der Verlust in Entscheidungen ankommt.
Zwei Arten von Drift
Data Drift heißt: Die Eingangsdaten sehen anders aus als im Training. Nach einem Maschinentausch liefert der neue Sensor andere Vibrationswerte, obwohl die Anlage gesund ist. Das Modell hat solche Werte nie gesehen und meldet ein Risiko, das keines ist.
Concept Drift heißt: Die Daten sehen gleich aus, aber der Zusammenhang dahinter hat sich verändert. Beim Saisonwechsel in der Mode reagiert dieselbe Jeans auf denselben Rabatt anders als noch im Frühjahr; ein Preismodell, das den Zusammenhang aus der letzten Saison gelernt hat, empfiehlt zu früh oder zu viel.
Model Drift ist der Sammelbegriff für die Folge beider Arten: Die Vorhersagegüte sinkt. Die Ursache entscheidet über die Antwort: Bei Data Drift reicht oft eine Korrektur der Datenstrecke, bei Concept Drift hilft nur ein neues Training mit aktuellen Daten.
Welche Signale überwacht werden
- Die Verteilung der Eingangsdaten je Merkmal, verglichen mit dem Trainingsstand.
- Die Verteilung der Vorhersagen: Meldet das Modell plötzlich zehnmal so viele Anlagen als kritisch wie in der Vorwoche, stimmt meist etwas mit den Daten nicht.
- Technische Kennzahlen: Antwortzeit, Durchsatz, Fehlerquote, Verfügbarkeit.
- Die Vorhersagequalität, sobald Ist-Werte vorliegen: Erst wenn die Anlage ausgefallen ist oder eben nicht, zeigt sich, ob die Warnung richtig war. Dieser Abgleich mit den Ist-Werten ist die wichtigste Kennzahl und die langsamste.
Das Dashboard im Diagramm zeigt den Aufbau: Antwortzeit im Mittel 42 Millisekunden, 12.400 Vorhersagen, Verfügbarkeit 99,97 Prozent, letztes Nachtraining vor drei Tagen. Diese Werte sind eine Illustration, keine Zusage für Ihr System; welche Werte für Sie zählen, legt Ihre Betriebsvereinbarung fest.
Wann nachtrainiert wird, und was es kostet
Ein Nachtraining wird ausgelöst, wenn ein vorher festgelegter Grenzwert verletzt wird: Die Verteilung eines Merkmals wandert über ein festgelegtes Maß hinaus, oder die gemessene Güte fällt unter die Grenze, die das Modell in der Validierung bestanden hat. Der Grenzwert steht vor dem Betrieb fest, nicht danach. So bleibt das Nachtraining eine geprüfte Entscheidung statt einer Reaktion auf den letzten schlechten Monat.
Die Rechenzeit ist dabei selten der Kostenpunkt; das Drum-Modell aus unserem Selbstversuch trainierte 70 Durchläufe (Epochen) in 12,3 Sekunden auf einer CPU. Teuer sind die Schritte um das Training herum: Ist-Werte einsammeln, das neue Modell gegen das alte prüfen, den Wechsel freigeben und dokumentieren. Wer Nachtraining budgetiert, budgetiert Menschen und Wartezeit, nicht Rechenkerne.
MLOps im Mittelstand: Cloud, on-premises oder beides
Die Frage nach dem Betriebsort entscheidet sich an drei Kriterien, in dieser Reihenfolge. Dürfen die Daten das Haus verlassen: Datenschutz und Kundenverträge? Wie sieht das Lastprofil aus: ein nächtlicher Lauf, Bürozeiten oder rund um die Uhr? Und welches Betriebsteam gibt es bereits?
Für die dritte Frage haben wir gerechnet, und zwar am teuersten Fall, dem GPU-Betrieb von Sprachmodellen. In unserer Kostenanalyse aus 110 datierten, öffentlichen Preisquellen kostet der Einstiegsserver im eigenen Haus 829 Euro Abschreibung im Monat, der Personalanteil für den Betrieb 3.924 Euro, der Strom 121 Euro. Der Mensch kostet mehr als das Vierfache der Maschine. Ein Modell von wenigen hundert Kilobyte ist kein Infrastrukturproblem, wie der Selbstversuch zeigt; die Aufgaben der Menschen bleiben dieselben: überwachen, nachtrainieren, freigeben.
In unserer Rechnung war die gemietete EU-Cloud in jedem Basis-Szenario günstiger als eigene Hardware. On-premises ist trotzdem dann die richtige Wahl, wenn vier Bedingungen zusammenkommen: Die Verarbeitung muss physisch ins eigene Haus, die Last ist hoch und konstant, ein Betriebsteam existiert bereits, und die Qualität frei verfügbarer Modelle reicht für den Anwendungsfall. Selbst in diesem besten Fall für eigene Hardware blieb eine Differenz von rund 4.700 Euro im Monat gegenüber der EU-Cloud-GPU. Diese Differenz ist der Preis dafür, dass die Hardware im eigenen Gebäude steht: eine bezahlte Anforderung, kein Sparprogramm.
Die dritte Antwort verbindet beides: Training dort, wo die Daten liegen, und das fertige Modell als Container dorthin, wo es gebraucht wird; der Container aus Schritt 3 macht diesen Ortswechsel möglich, ohne das Modell anzufassen.
Zu den Werkzeugen nur so viel: Für die Reifegrade 1 und 2 genügen quelloffene Werkzeuge für Versionierung, Experimentverfolgung, Container und Auslieferung; eine MLOps-Plattform mit Lizenz wird erst zum Thema, wenn viele Modelle und mehrere Teams dieselbe Strecke teilen.
Die vollständige Rechnung mit Break-even-Kurven und Sensitivität: Souveräne KI, ehrlich gerechnet: was On-Premises wirklich kostet.Betriebsübergabe: wer das Modell nach dem Projekt betreut
Ein Modell, das niemand betreut, ist nach einem Jahr ein Risiko mit Dashboard. Deshalb ist die Übergabe bei uns ein eigener Projektschritt mit drei Ergebnissen.
Dokumentation
Was das Modell tut, welche Daten es braucht, welche Kennzahlen es bestanden hat, welche Annahmen gelten. Reproduzierbar bis zu Datenstand, Code-Stand und Startwert des Zufallsgenerators.
Runbook
Was Ihr Team tut, wenn eine Warnung kommt: Prüfschritte, Ansprechpartner, Rollback, Entscheidung, ob neu trainiert wird. Ein Runbook ist eine Handlungsanweisung für den Ernstfall, kein Handbuch.
Schulung
Die Menschen, die morgen mit den Vorhersagen arbeiten, verstehen, was das Modell kann und wo es schweigt. Eine Warnung, die niemand einordnen kann, wird ignoriert.
Ziel der Übergabe ist, dass Ihr eigenes Team mit Dokumentation und Runbook übernimmt.
Was Deployment, Monitoring und Betrieb als Leistung umfassen, steht auf der Seite MLOps-Beratung: Deployment, Monitoring und Betrieb als Leistung.Unser Vorgehen
Produktivierung
Vorbereitung für den produktiven Einsatz mit Schnittstellen und Qualitätsprüfungen.
Automatisierter Release
Nachvollziehbarer Deployment-Prozess mit Tests und Rückfallmöglichkeiten.
Monitoring & Alerting
Frühzeitige Erkennung von Veränderungen in Modellleistung und Datenqualität.
Betriebsübergabe
Wissenstransfer, Dokumentation und Prozessetablierung für Ihr Team.
Typische Ergebnisse
Häufige Fragen zu MLOps
Was ist MLOps?
MLOps steht für Machine Learning Operations: die Praxis, ein trainiertes Modell zuverlässig in Betrieb zu nehmen und dort zu halten. Dazu gehören die Versionierung von Code, Daten und Modell, automatische Tests, die Bereitstellung als Dienst oder Batch-Lauf, Monitoring auf Drift und ein geregeltes Nachtraining. Ohne MLOps bleibt ein Modell ein Prototyp mit Verfallsdatum.
Was ist der Unterschied zwischen MLOps und DevOps?
DevOps liefert Software aus, deren Verhalten allein vom Code abhängt. MLOps liefert Modelle aus, deren Verhalten zusätzlich von Daten abhängt. Deshalb versioniert MLOps auch Daten und Modellstände, testet neben dem Code die Gültigkeit der Eingangsdaten und überwacht nach der Auslieferung, ob sich die Daten oder der gelernte Zusammenhang verändert haben.
Was bedeutet ML-Deployment?
ML-Deployment (Machine Learning Deployment) ist die Inbetriebnahme eines Modells: Der geprüfte Modellstand wird als Container gebündelt, in einer Testumgebung gegen echte Schnittstellen geprüft, zunächst einem Teil des Betriebs zugeteilt und dann vollständig freigeschaltet. Bereitstellungsformen sind der nächtliche Batch-Lauf, eine Schnittstelle, die Einbettung ins Fachsystem oder der Betrieb direkt im Browser.
Was ist Model Drift und wie erkennt man ihn?
Model Drift bedeutet, dass die Vorhersagegüte eines Modells im Betrieb sinkt. Ursache ist Data Drift (die Eingangsdaten verändern sich, etwa nach einem Maschinentausch) oder Concept Drift (der Zusammenhang verändert sich, etwa beim Saisonwechsel). Erkannt wird Drift über den Vergleich der Datenverteilungen mit dem Trainingsstand und, sobald Ist-Werte vorliegen, über die gemessene Güte.
Wie oft muss ein Machine-Learning-Modell neu trainiert werden?
So oft, wie die Daten es verlangen, nicht nach Kalender. Neu trainiert wird, wenn ein vorher festgelegter Grenzwert verletzt wird: Die Datenverteilung wandert, oder die gemessene Güte fällt unter die Grenze aus der Validierung. Ein Abschriftenmodell lässt sich erst nach Saisonende bewerten; das Modul rechnet mit ein bis zwei Saisons. Teuer sind Prüfung und Freigabe, nicht die Rechenzeit.
Brauchen wir eine MLOps-Plattform oder reichen Open-Source-Werkzeuge?
Für die Reifegrade 1 und 2 reichen quelloffene Werkzeuge: Versionierung, Experimentverfolgung, Container und eine Auslieferungsstrecke, wie Ihre IT sie für Software kennt. Eine lizenzpflichtige MLOps-Plattform lohnt sich, wenn viele Modelle und mehrere Teams dieselbe Strecke teilen. Entscheidend ist die Passung zu Ihrer vorhandenen IT, nicht die Länge der Funktionsliste.
Kann ein KI-Modell on-premises betrieben werden?
Ja. Modell, Nachtraining und Monitoring lassen sich vollständig im eigenen Rechenzentrum betreiben. Günstiger war in unserer Kostenanalyse in jedem Basis-Szenario die gemietete EU-Cloud; der eigene Betrieb ist eine bezahlte Anforderung. Sinnvoll ist sie, wenn Daten das Haus nicht verlassen dürfen, die Last hoch und konstant ist und ein Betriebsteam existiert. Der größte Posten ist das Personal, nicht der Strom.
Belege zu Deployment, Monitoring und Kosten
Souveräne KI, ehrlich gerechnet: was On-Premises wirklich kostet Predictive Maintenance im Betrieb Modul Markdown-Optimierung für die Mode Der Selbstversuch: eine Webanwendung mit Modell im BrowserLassen Sie uns über Ihr Projekt sprechen
Jedes Projekt ist einzigartig. Schildern Sie uns Ihre Herausforderung.
Kostenloses Erstgespräch buchen