Managed MLflow

Managed MLflow ist die von Databricks im eigenen Workspace betriebene Variante des Open-Source-Werkzeugs MLflow. Als verwalteter Dienst deckt Managed MLflow den Modell-Lebenszyklus ab: Experiment-Tracking (Trainingsläufe mit Parametern, Metriken und Ergebnis-Dateien festhalten), Model Registry (trainierte Modelle als versionierte Objekte verwalten), Deployments (Modelle für die produktive Nutzung freigeben) und GenAI-Evaluation (die Qualität von LLM-Antworten messen). Der Betrieb des Tracking-Servers und der Speicher-Ablage entfällt für das nutzende Team.

Was ist Managed MLflow?

MLflow ist ein 2018 von Databricks initiiertes Open-Source-Projekt für den Umgang mit Machine-Learning-Läufen. Ein Trainingslauf schreibt seine Ergebnisse (welcher Datensatz, welche Parameter, welche Genauigkeit, welche fertige Modelldatei) in einen zentralen Speicher. Diese Sammlung heißt in MLflow Tracking. Der zugehörige Server, der die Läufe entgegennimmt und im Browser sichtbar macht, ist der Tracking-Server. In der Open-Source-Variante muss dieser Server samt Datenbank und Datei-Ablage selbst betrieben werden. Managed MLflow ist die Ausprägung, in der Databricks diesen Server im Workspace bereitstellt und wartet.

Der Funktionsumfang von Managed MLflow entspricht dem der offenen Version, ist aber in die Databricks-Plattform eingebettet. Ein Trainings-Notebook oder ein Job spricht Managed MLflow über dieselben Bibliotheks-Aufrufe an wie das Open-Source-Projekt, etwa mlflow.start_run() und mlflow.log_metric(...). Läufe erscheinen im Databricks-Experiment-UI, verlinken auf das ausführende Notebook oder den Job und behalten die Verbindung zu den verwendeten Trainings-Daten. Modelle werden über mlflow.<framework>.log_model(...) als Artefakt am Lauf abgelegt und optional in die Model Registry aufgenommen.

Die Registry ist der zweite große Baustein. Sie führt Modelle als eigenständige, versionierte Objekte. In der aktuellen Variante liegen sie als Objekte in Unity Catalog unter dem dreistufigen Namen catalog.schema.model_name. Jede neue Ausprägung erhält eine fortlaufende Versionsnummer, jede Version kann Aliases wie @champion oder @challenger tragen. Zugriffsrechte werden über Unity Catalog gesteuert und liegen damit im selben Berechtigungsmodell wie Tabellen, Volumes und Funktionen. Die Registry-Komponente in Managed MLflow wird von Databricks als [Mosaic AI Model Registry](https://docs.databricks.com/aws/en/machine-learning/manage-model-lifecycle/) vermarktet.

Neben klassischem ML deckt Managed MLflow auch generative Anwendungen ab. Prompt-Tracking speichert Prompt-Varianten und LLM-Antworten als Traces, mlflow.evaluate(...) misst deren Qualität mit klassischen Metriken oder mit LLM-as-a-Judge-Bewertungen. Trainings- und Fine-Tuning-Läufe aus Mosaic AI Training werden automatisch getrackt. Als verwalteter Dienst liefert Managed MLflow damit die durchgehende Nachvollziehbarkeit von Trainingsdaten über Modellversion bis zur produktiven Antwort, ohne dass ein Team dafür einen eigenen Tracking-Server, eine Backend-Datenbank oder einen Artefakt-Speicher betreiben muss ([MLflow-Dokumentation](https://mlflow.org/docs/latest/), [Databricks-Dokumentation zu MLflow-Tracking](https://docs.databricks.com/aws/en/mlflow/)).

Abgrenzung: Open-Source MLflow, Mosaic AI Model Registry, Model Serving, Mosaic AI Training

Managed MLflow wird häufig mit Nachbar-Bausteinen im Databricks-Stack vermischt. Vier Begriffe stehen typischerweise im Umfeld.

Der häufigste Verwechslungspunkt ist die Grenze zwischen Managed MLflow und Open-Source MLflow. Der Funktions-Kern ist identisch: dieselben Client-Bibliotheken, dieselben Konzepte (Runs, Experiments, Model Registry, Model Signatures). Der Unterschied liegt im Betriebsmodell und in der Governance. Bei Open-Source MLflow läuft der Tracking-Server auf eigener Infrastruktur, die Model Registry ist an diesen Server gebunden und Berechtigungen werden über Netzwerk- oder Reverse-Proxy-Ebene gesetzt. Bei Managed MLflow läuft der Dienst innerhalb des Databricks-Workspaces, die Registry-Objekte liegen in Unity Catalog und Zugriffsrechte werden per UC-Privileg vergeben.

Mosaic AI Model Registry bezeichnet die UC-native Registry-Komponente innerhalb von Managed MLflow. Der MLflow-Client spricht sie über mlflow.set_registry_uri("databricks-uc") an. Die ältere Workspace-Registry mit den Zuständen None, Staging, Production, Archived gehört ebenfalls zu Managed MLflow, entspricht aber einem älteren Modell außerhalb von Unity Catalog und bleibt vor allem für Bestandslösungen relevant.

Model Serving liegt eine Ebene darüber. Ein Serving-Endpoint verweist entweder fest auf eine Version (.../3) oder folgt einem Alias (.../@champion). Rollouts erfolgen durch Alias-Zuweisung in Managed MLflow; der Endpoint selbst bleibt unverändert. Damit ist der Versionswechsel entkoppelt vom Deployment, ein Rollback setzt den Alias auf die vorige Version zurück.

Mosaic AI Training ist der Trainings-Service für Foundation-Model-Fine-Tuning. Er hinterlegt seine Läufe in Managed MLflow-Experimenten, das fertige Modell landet in der Registry. Aus Sicht der Nachvollziehbarkeit gehören beide zusammen, technisch bleiben es getrennte Dienste.

Beispiel: Klassifikator und GenAI-Assistent im selben Managed-MLflow-Workspace

Ein Data-Science-Team trainiert einen Kundenabwanderungs-Klassifikator in einem Databricks-Notebook. Vor dem Trainingslauf setzt der Code mlflow.set_registry_uri("databricks-uc") und öffnet mit mlflow.start_run() einen neuen Run im Experiment /Users/team/churn. Während des Trainings werden Hyperparameter (mlflow.log_param), Metriken (mlflow.log_metric) und Trainingsdaten-Referenzen protokolliert. Das fertige Scikit-learn-Modell wird über mlflow.sklearn.log_model(model, "model", registered_model_name="prd_models.customer.churn_classifier", signature=signature) gespeichert und automatisch als Version 4 in der Registry angelegt.

Ein nachgelagerter Evaluations-Job zieht Version 4, prüft sie gegen einen Goldset-Datensatz und schreibt die Ergebnisse als Tags an die Modellversion (goldset_accuracy, eval_run_id). Nach bestandener Prüfung setzt ein CI-Prozess den Alias @champion auf Version 4, die vorherige Version 3 erhält den Alias @last_known_good. Der Serving-Endpoint zeigt fest auf models:/prd_models.customer.churn_classifier@champion und übernimmt die neue Version, sobald der Alias umgesetzt ist. Unity Catalog verknüpft die Modellversion mit dem Trainingslauf, dem Notebook und den Silber-Tabellen der Feature-Berechnung.

Für einen GenAI-Support-Assistenten läuft im selben Workspace ein zweiter Prozess. Prompt-Varianten werden über mlflow.log_prompt(...) und mlflow.start_trace(...) als Managed-MLflow-Traces festgehalten, mlflow.evaluate(...) bewertet die Antworten mit einer LLM-as-a-Judge-Metrik gegen ein kuratiertes Testset. Der beste Prompt wird als Prompt-Version in derselben Registry-Struktur abgelegt. Antworten aus der produktiven Nutzung landen über Inference Tables am Serving-Endpoint zurück im Lakehouse; von einer konkreten Antwort ist der Weg zurück über die Inference-Tabelle, die Modellversion, den Trainings- oder Prompt-Run und die Eingangs-Daten ohne zusätzliches Tooling nachvollziehbar. Für Freigabe-Nachweise nach EU AI Act oder ISO/IEC 42001 wird Managed MLflow damit zum zentralen Anker.