Die Entscheidung für Self-Hosting ist gefallen. Das Unternehmen betreibt ML-Modelle auf eigener Infrastruktur – aus regulatorischen Gründen, zum Schutz von Betriebsgeheimnissen oder weil das Anfragevolumen eine eigene Infrastruktur wirtschaftlich macht.

Damit beginnt die eigentliche Arbeit. Denn wer Modelle selbst betreibt, übernimmt die Verantwortung für alles, was Cloud-Anbieter sonst im Hintergrund erledigen: Training, Deployment, Versionierung, Qualitätssicherung, Rollback. Die Frage ist nicht mehr ob man MLOps braucht, sondern wie gut das Setup sein muss, damit Self-Hosting in der Praxis funktioniert.

Die gute Nachricht: Ein durchdachtes MLOps-Setup ist kein reiner Kostenfaktor. Es ermöglicht Dinge, die ohne Automatisierung schlicht nicht realisierbar wären.

Was ein gutes MLOps-Setup ermöglicht

Schnellere Iterationen

Wenn das Trainieren, Validieren und Deployen eines Modells ein manueller Prozess ist, wird er selten ausgeführt. Teams optimieren einmal, deployen, und fassen das Modell dann monatelang nicht mehr an – weil jeder Zyklus Aufwand bedeutet.

Automatisierte Pipelines ändern diese Dynamik fundamental. Wenn ein neuer Trainingslauf per Workflow gestartet werden kann, Quality Gates automatisch entscheiden ob das Modell weiterkommt, und das Deployment ohne manuelle Schritte läuft – dann wird Iteration günstig. Neue Hyperparameter testen, einen anderen LoRA-Rank ausprobieren, ein erweitertes Dataset einbinden: Der Aufwand sinkt von Tagen auf eine Workflow-Submission.

Transparenz und Reproduzierbarkeit

Welches Modell läuft gerade in Production? Mit welchen Daten wurde es trainiert? Welche Modellversion wurde letzte Woche durch die aktuelle ersetzt?

In regulierten Branchen sind das keine akademischen Fragen. Ein zentrales Experiment-Tracking mit Model Registry beantwortet sie zuverlässig – nicht über Dokumentation, die veraltet, sondern über Metadaten, die automatisch bei jedem Trainingslauf erfasst werden. Jedes Modell hat eine nachvollziehbare Geschichte: Trainingsparameter, Metriken, Datenversion, Promotion-Pfad. Das ist Data Lineage, die sich aus dem Prozess ergibt, nicht aus nachträglicher Dokumentation.

Erweiterbarkeit bei kontrolliertem Aufwand

Der erste Use Case läuft. Jetzt kommen Anfragen für ein zweites Modell, ein anderes Framework, einen anderen Modelltyp. Ohne ein durchdachtes Setup bedeutet jedes neue Modell einen neuen Ad-hoc-Prozess.

Ein gutes MLOps-Setup trennt Infrastruktur-Patterns von modellspezifischer Logik. Dieselben Workflow-Orchestrierung, dasselbe Experiment-Tracking, dieselbe Promotion-Strategie – ob für ein Computer-Vision-Modell auf einem ONNX-Serving-Stack oder ein Large Language Model auf einem LLM-Serving-Stack. Was sich ändert, sind die Trainings-Scripts und die Serving-Konfiguration. Was gleich bleibt, ist das Betriebsmodell.

Kosten im Griff

GPU-Stunden sind teuer. Ein Cluster, der rund um die Uhr läuft, obwohl Training nur zweimal pro Woche stattfindet, verbrennt Budget. Automatisierte Workflows können GPU-Nodes on-demand hochskalieren und nach Abschluss wieder herunterfahren – Scale-to-Zero für die teuersten Ressourcen. Das funktioniert aber nur, wenn die Pipelines tatsächlich automatisiert laufen. Manuelles Training kann nicht von automatischem Scaling profitieren, weil der Mensch im Loop die Latenz bestimmt.

Datensouveränität – durchgängig

Datensouveränität endet nicht beim Inference. Wenn das Modell auf eigener Infrastruktur läuft, aber die Trainingsdaten über eine externe API laufen, die Evaluation über einen Cloud-Dienst erfolgt, oder die Dataset-Generierung einen externen Service nutzt – dann ist die Souveränität lückenhaft. Ein durchdachtes MLOps-Setup stellt sicher, dass die gesamte Pipeline auf eigener Infrastruktur läuft: Training, Evaluation, Dataset-Generierung, Experiment-Tracking. Kein API-Call verlässt das Netzwerk.

Was macht ein gutes MLOps-Setup aus?

Die konkreten Tools sind austauschbar. Was zählt, sind die Eigenschaften des Gesamtsystems:

Robust: Pipelines laufen zuverlässig durch oder scheitern sauber. Quality Gates verhindern, dass ein schlechtes Modell in Production landet. Rollback-Mechanismen ermöglichen schnelle Rückkehr zum vorherigen Stand. Kein manuelles “lass mal schnell deployen und schauen ob es funktioniert”.

Transparent: Jeder Schritt ist nachvollziehbar. Welches Modell wurde wann mit welchen Daten trainiert, wer hat es promoted, warum wurde die vorherige Version ersetzt. Diese Transparenz entsteht automatisch aus dem Prozess, nicht durch manuelle Dokumentation.

Sicher: Keine statischen Credentials, keine Passwörter in Config-Dateien. Kurzlebige Tokens, rollenbasierte Zugriffskontrolle, Netzwerk-Policies zwischen den Komponenten. Sicherheit als Architektur-Eigenschaft, nicht als Checklisten-Punkt.

Erweiterbar: Ein neues Modell oder ein neuer Serving-Stack sollte keine Neuentwicklung der Pipeline erfordern. Die Infrastruktur-Patterns – Workflow-Orchestrierung, Experiment-Tracking, Promotion-Strategie, Container-Image-Builds – sind wiederverwendbar. Was sich ändert, ist modellspezifisch.

So einfach wie möglich, so komplex wie nötig. Nicht jedes Team braucht von Tag eins die volle Automatisierung. Aber die Architektur sollte es erlauben, Schritte inkrementell zu automatisieren – ohne alles neu aufbauen zu müssen, wenn die Anforderungen wachsen.

Wie das in der Praxis aussieht

Ich habe diese Prinzipien in einem öffentlichen Repository umgesetzt: zwei automatisierte ML-Pipelines auf Kubernetes, die unterschiedliche Modelltypen und Serving-Plattformen abdecken – mit gemeinsamen Infrastruktur-Patterns.

Eine Pipeline trainiert Deep-Learning-Modelle, exportiert sie nach ONNX und deployt sie auf Triton Inference Server. Eine zweite Pipeline fine-tuned LLMs mit QLoRA, deployt LoRA-Adapter mit Zero-Downtime Hot-Loading und evaluiert die Qualität automatisch mit einem LLM-as-Judge – alles self-hosted.

Beide Pipelines nutzen MLflow als zentrale Model Registry mit einer Alias-basierten Promotion-Strategie: Kein Modell erreicht Production ohne automatische Quality Gates, und jeder Promotion-Schritt ist im Registry nachvollziehbar. Wie MLflow dabei als zentrales Control Plane funktioniert – von Experiment Tracking über Dataset Lineage bis zur Decision Auditability – beschreibe ich im Detail in einem separaten Artikel: MLflow as the Control Plane for MLOps.

Der Code, die Argo Workflows, die Kubernetes-Manifeste und die GitHub-Actions-Pipelines sind öffentlich: → mlops-on-kubernetes

Die LLM-Pipeline ist zusätzlich in einer 10-teiligen Blog-Serie (Deutsch) dokumentiert, die den kompletten Weg von der ersten Installation bis zur datensouveränen Evaluation beschreibt – mit echten Debugging-Stories und Trade-off-Analysen: → Self-Hosted LLMs für Datensouveränität

Ich bin ML Engineer mit Hintergrund in Cloud-Infrastruktur und Banking. Ich helfe Unternehmen im DACH-Raum, ML- und AI-Systeme datensouverän auf eigener Infrastruktur zu betreiben. Offen für Austausch und spannende Projekte – schreib mir gerne eine Nachricht.