Projekt anfragen
Drei Personen besprechen Diagramme auf einem Laptop und auf ausgedruckten Auswertungen an einem Schreibtisch

MLOps · KI-Plattform auf Kubernetes

MLOps und KI-Plattformen: Aufbau, Integration und Betrieb

Aus Notebooks und Einzelskripten wird ein geregelter Betriebsprozess: Modelle reproduzierbar trainieren, nachvollziehbar versionieren, kontrolliert ausrollen und im Betrieb überwachen.

Projekt anfragen Zum Lebenszyklus
  • Pipelines, Tracking, Registry
  • Rollout mit Rückweg
  • Drift-Überwachung

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Ausgangslage

Ein Modell im Notebook ist noch kein Produkt

SKAFFON baut MLOps-Plattformen auf Kubernetes, auf denen Data-Science- und Entwicklungsteams ihre Modelle durch einen festen Ablauf führen. Die Seite richtet sich an IT-Leitung, Plattform- und Data-Verantwortliche und beschreibt Umfang, Werkzeuge und Grenzen.

MLOps ist dabei keine einzelne Software, sondern ein Satz abgestimmter Verfahren und Werkzeuge. Was davon Sie brauchen, hängt davon ab, wie viele Modelle, Teams und Releases Sie haben; für ein einzelnes Modell kann ein kleiner Zuschnitt genügen.

02Symptome

Woran Sie merken, dass Ihnen die Plattform fehlt

  • Ergebnisse lassen sich nicht wiederholen

    Daten, Code, Parameter und Umgebung wurden nicht zusammen festgehalten.

  • Unklar, was produktiv läuft

    Niemand weiß sicher, welche Modellversion gerade im Einsatz ist und womit sie trainiert wurde.

  • Releases per Hand

    Modelle gehen manuell und ohne definierten Rückweg in Betrieb.

  • Stille Qualitätsverluste

    Die Eingabedaten ändern sich, und das produktive Modell wird schlechter, ohne dass es jemand bemerkt.

  • Doppelte Infrastruktur

    Mehrere Teams bauen jeweils eigene Werkzeuge für dasselbe Problem.

03Lebenszyklus

Fünf Stufen, ein Werkzeug je Aufgabe

Die Plattform folgt dem Lebenszyklus eines Modells. Die Werkzeugwahl ist ein Vorschlag, der an Ihre vorhandene Landschaft angepasst wird.

MLOps-Stufen mit Aufgabe und möglichem Werkzeug
StufeAufgabeMögliches Werkzeug
1. PipelineDatenaufbereitung, Training, Evaluation als wiederholbarer AblaufKubeflow Pipelines (Workflows als Graph aus containerisierten Komponenten), alternativ GitLab CI
2. TrackingParameter, Metriken, Artefakte je Lauf festhaltenMLflow Tracking
3. RegistryModellversionen, Freigabestatus, HerkunftMLflow Model Registry (Versionen, Aliase, Lineage zum erzeugenden Lauf)
4. RolloutModell kontrolliert als Dienst bereitstellen, RückwegKServe auf Kubernetes, Release-Prozess in GitLab
5. Drift-MonitoringEingabedaten und Qualität im Betrieb beobachtenMetriken und Alarme; Feature-Konsistenz optional mit Feast

04Zusammenspiel

Vom Registry-Eintrag zum Retraining-Lauf und zurück

Die Verbindung der Stufen ist der eigentliche Wert: Aus einem Registry-Eintrag lässt sich der erzeugende Lauf zurückverfolgen, aus dem laufenden Dienst die Registry-Version, und aus einem Drift-Alarm ein definierter Retraining-Lauf.

MLOps-Lebenszyklus auf KubernetesFünf Stationen im Kreis: Pipeline, Tracking, Registry, Rollout, Drift-Monitoring, mit Rückpfeil Retraining-Auslöser; darunter die Basisschicht Kubernetes und GPU-Knoten. 1 Pipeline Kubeflow Pipelines / GitLab CI 2 Tracking MLflow Tracking 3 Registry MLflow Model Registry 4 Rollout KServe 5 Drift-Monitoring Metriken und Alarme Retraining-Auslöser Drift-Alarm startet neuen Lauf Kubernetes + GPU-KnotenZugriffIdentity, Namespaces, Audit
Kreislauf auf der Basisschicht Kubernetes mit GPU-Knoten; Zugriff über Identity, Namespaces und Audit.
MLOps-Lebenszyklus auf KubernetesFünf Stationen untereinander: Pipeline, Tracking, Registry, Rollout, Drift-Monitoring, mit Rückpfeil Retraining-Auslöser von Drift-Monitoring zurück zur Pipeline; darunter die Basisschicht Kubernetes und GPU-Knoten.1 PipelineKubeflow Pipelines / GitLab CI2 TrackingMLflow Tracking3 RegistryMLflow Model Registry4 RolloutKServe5 Drift-MonitoringMetriken und AlarmeRetraining-AuslöserDrift-Alarm startetneuen LaufKubernetes + GPU-KnotenZugriffIdentity, Namespaces, Audit
Kreislauf auf der Basisschicht Kubernetes mit GPU-Knoten; Zugriff über Identity, Namespaces und Audit.

05Projektverlauf

Erst ein echtes Modell durch alle fünf Stufen, dann die Breite

Der Pilot mit einem realen Modell ist bewusst Pflicht, weil sich Lücken zwischen den Stufen erst im Durchlauf zeigen.

  1. 01

    Assessment

    Ergebnis: Lückenanalyse

    Ist-Zustand von Daten, Modellen, Pipelines und Betrieb.

  2. 02

    Zielbild und Pilot

    Ergebnis: Pilot-Durchlauf

    Eine Pipeline mit einem echten Modell durch alle fünf Stufen, bevor die Plattform verbreitert wird.

  3. 03

    Ausbau

    Ergebnis: weitere Teams

    Weitere Teams und Modelle, Mandantentrennung, Härtung.

  4. 04

    Regelbetrieb

    Ergebnis: geregelter Betrieb

    Die Plattform läuft im Betrieb, durch SKAFFON auf Wunsch oder durch Ihr eigenes Team.

06Was wir bauen

Sechs Bausteine einer MLOps-Plattform

  • Plattformdesign

    Zielarchitektur, Werkzeugauswahl, Mandantenmodell, Integration in Ihr Identity- und Netzwerkkonzept.

  • Aufbau auf Kubernetes

    Pipelines, Tracking-Server mit Datenbank und Artefaktspeicher, Registry, Serving; Bereitstellung als Infrastructure as Code (OpenTofu) und GitOps, gestützt auf unsere Platform-Engineering-Leistung.

  • Release-Prozess

    Freigabestufen, automatisierte Evaluation vor Freigabe, Rollout mit Rückweg.

  • Monitoring

    Serving-Metriken, Datendrift- und Qualitätsüberwachung, Alarmierung.

  • Integration

    Anbindung an CI/CD, Datenplattformen und GPU-Ressourcen.

  • Betrieb und Befähigung

    Runbooks, Schulung, Update-Prozess der Plattformkomponenten; Betrieb durch SKAFFON auf Wunsch. Betrieb und Support bieten wir rund um die Uhr (24/7) an; die Reaktionszeiten je Prioritätsstufe ergeben sich aus dem Servicelevel-Modell unter Managed Services und werden je Vertrag vereinbart.

07Grenzen

Trainings- und Serving-Umgebung getrennt, Modelle mit Herkunft

Zugriff auf Daten, Modelle und Registry folgt Rollen und wird protokolliert. Container-Images stammen aus einer kontrollierten Lieferkette (siehe DevSecOps und Software-Lieferketten).

Modelle sind Artefakte mit eigener Herkunft und erhalten dieselbe Freigabekontrolle wie Software. Für KI-Workloads gilt zusätzlich der Rahmen aus Cybersecurity für Cloud, Daten und KI.

  • Getrennte Trainings- und Serving-Umgebungen
  • Rollenbasierter, protokollierter Zugriff
  • Kontrollierte Lieferkette für Images
Aufgeklappter Laptop mit Quelltext auf dem Bildschirm, daneben ein Notizbuch mit Kugelschreiber

08Eingaben

Was wir von Ihrer Seite zum Start brauchen

  • Anzahl und Art der Modelle (klassisches ML, Deep Learning, LLM-Anwendungen) und der Teams
  • Datenquellen und deren Schutzklassen; vorhandene Datenplattform
  • Vorhandene Kubernetes-Plattform, CI/CD und Identity; vorhandene GPU-Kapazität
  • Compliance-Anforderungen an Nachvollziehbarkeit und Freigaben
  • Wer betreibt die Plattform nach dem Aufbau

09Lieferung und Aufwand

Was Sie erhalten und was den Aufwand bestimmt

Lieferumfang: Plattform-Repository (Infrastructure as Code), Architekturdokumentation, Release- und Freigabeprozess, Monitoring-Dashboards, Runbooks, Einführungsworkshop.

10Passung

Plattform lohnt sich, wenn mehr als ein Modell im Spiel ist

Das passt zu einer MLOps-Plattform

  • Mehrere Modelle, Teams oder regelmäßige Releases
  • Nachvollziehbarkeit und Freigaben müssen belegbar sein
  • Sie wollen eine gemeinsame Basis statt Insellösungen

Besser anders lösen

  • Ein einzelnes, selten geändertes Modell: ein geregelter CI-Job und ein Model-Artefakt genügen oft.
  • Sie suchen Data-Science-Entwicklung: SKAFFON baut die Plattform, nicht Ihre Fachmodelle. Für Engineering-Kapazität siehe Nearshore Engineering Teams.
  • Sie wollen ein vollständig verwaltetes Cloud-Produkt eines Hyperscalers und keine eigene Plattform.

11

Häufige Fragen

Brauche ich für ein einzelnes Modell eine MLOps-Plattform?

Meist nicht. Bei einem einzelnen, selten geänderten Modell genügen oft ein geregelter CI-Job und ein Model-Artefakt; eine Plattform lohnt dann nicht.

Entwickelt SKAFFON auch die Modelle selbst?

Nein. SKAFFON baut die Plattform, nicht Ihre Fachmodelle. Für Engineering-Kapazität siehe Nearshore Engineering Teams.

Sind die genannten Werkzeuge festgelegt?

Nein. Die Werkzeugwahl ist ein Vorschlag, der an Ihre vorhandene Landschaft angepasst wird.

12Angrenzende Themen

Vorher, daneben und darunter

MLOps-Plattform für Ihre Modell- und Teamlandschaft planen

Schicken Sie uns Ihre Modell- und Teamlandschaft; wir melden uns mit einer Einschätzung.

Projekt anfragen