Model-Versionierungsinfrastruktur: ML-Artefakte im großen Maßstab verwalten

Aktualisiert am 11. Dezember 2025

Update Dezember 2025: MLflow 3.0 erweitert die Registry für generative KI und KI-Agenten—verbindet Modelle mit Code-Versionen, Prompts, Evaluierungsläufen und Deployment-Metadaten. Model Versioning verfolgt jetzt nicht nur Gewichte, sondern auch feinabgestimmte Adapter, Prompt-Templates und Retrieval-Konfigurationen. LLMs mit hunderten GB an Gewichten erfordern spezialisierte Infrastruktur jenseits von Git.

MLflow 3.0 hat seine Model Registry erweitert, um generative KI-Anwendungen und KI-Agenten zu handhaben und Modelle mit exakten Code-Versionen, Prompt-Konfigurationen, Evaluierungsläufen und Deployment-Metadaten zu verbinden.¹ Diese Entwicklung spiegelt einen fundamentalen Wandel dessen wider, was „Model Versioning" bedeutet—von der Nachverfolgung einfacher Pickle-Dateien hin zur Verwaltung komplexer Systeme mit mehreren feinabgestimmten Adaptern, Prompt-Templates und Retrieval-Konfigurationen. Organisationen, die produktive KI betreiben, benötigen Infrastruktur, die nicht nur Gewichte versioniert, sondern den gesamten Kontext, der erforderlich ist, um Modelle zuverlässig zu reproduzieren und bereitzustellen.

Anders als bei traditioneller Software-Versionierung umfasst ML Model Versioning die Nachverfolgung massiver Binärdateien, komplexer Trainingskonfigurationen, Dataset-Versionen und Evaluierungsmetriken—all dies unter Wahrung von Reproduzierbarkeits- und Compliance-Anforderungen.² Die Herausforderung potenziert sich bei LLMs, wo feinabgestimmte Modelle schnell proliferieren und Prompt Engineering eine weitere Schicht von Artefakten hinzufügt, die Versionskontrolle erfordern.

Warum Model Versioning wichtig ist

Produktive ML-Systeme scheitern still. Modelle degradieren mit der Zeit, feinabgestimmte Versionen performen unerwartet schlechter, und ohne ordentliche Versionierung können Teams nicht identifizieren, was sich geändert hat, oder zu bekannt funktionierenden Zuständen zurückkehren.

Die Versionierungsherausforderung

Binäre Artefakte: Modellgewichte reichen von Megabytes für klassisches ML bis zu hunderten Gigabytes für Large Language Models. Git kann diese Dateien nicht effizient handhaben; spezialisierte Infrastruktur wird essenziell.

Konfigurationsexplosion: Ein einzelnes Modell umfasst Trainingscode, Hyperparameter, Datenvorverarbeitung, Feature Engineering und Deployment-Konfiguration. Jede Änderung beeinflusst potenziell das Modellverhalten.

Dataset-Abhängigkeit: Modellqualität hängt von Trainingsdaten ab. Ohne Dataset-Versionierung wird die Reproduktion eines Modells selbst mit identischem Code unmöglich.

Evaluierungskopplung: Leistungsmetriken auf spezifischen Testsets bestimmen Deployment-Entscheidungen. Diese Metriken müssen dauerhaft mit Modellversionen verknüpft sein.

Geschäftsanforderungen

Reproduzierbarkeit: Regulatorische Anforderungen in Finanz- und Gesundheitswesen verlangen die Fähigkeit, exakte Modellversionen, die zu jedem Zeitpunkt eingesetzt wurden, neu zu erstellen.³

Prüfbarkeit: Compliance erfordert die Rückverfolgung eingesetzter Modelle zu Trainingsdaten, Code und Entscheidungsträgern, die das Deployment genehmigt haben.

Rollback-Fähigkeit: Produktionsvorfälle erfordern die Rückkehr zu vorherigen Modellversionen innerhalb von Minuten, nicht Stunden.

Kollaboration: Mehrere Data Scientists, die am selben Modell arbeiten, benötigen klare Ownership und Konfliktlösung für Modellartefakte.

Model Registry Architektur

Eine Model Registry dient als zentrales Repository zur Verwaltung des Lebenszyklus von ML-Modellen von der Entwicklung bis zur Produktion:⁴

Kernkomponenten

Versionskontrolle: Jede Modellversion erhält einen eindeutigen Identifier, typischerweise eine Kombination aus Modellname mit semantischer Version (v1.2.3) oder hash-basierten Identifiern.

Metadatenspeicherung: Trainingsparameter, Evaluierungsmetriken, Datenherkunft und Deployment-Historie werden neben Modellartefakten persistiert.

Artefaktspeicherung: Modellgewichte, Konfigurationsdateien und zugehörige Assets werden in skalierbarem Object Storage (S3, GCS, Azure Blob) gespeichert.

Lifecycle-Management: Modelle durchlaufen Phasen—Entwicklung, Staging, Produktion, Archiviert—mit Governance-Kontrollen bei jedem Übergang.

Registry-Workflow

Training Job → Modell registrieren → Staging-Review → Produktions-Deployment
     ↓                ↓                    ↓                      ↓
  Metriken       Versions-ID          Genehmigungen         Traffic-Routing
  geloggt        generiert            aufgezeichnet          überwacht

Registrierung: Training-Pipelines registrieren automatisch erfolgreiche Modelle mit zugehörigen Metadaten: - Training Run ID und Experiment-Kontext - Hyperparameter und Konfiguration - Evaluierungsmetriken auf Held-out-Daten - Datenversionsreferenzen - Code-Commit-Hash

Staging: Kandidatenmodelle durchlaufen Validierung vor der Produktion: - Automatisiertes Testen gegen Benchmarks - Menschliche Review für sensitive Anwendungen - A/B-Testing gegen das aktuelle Produktionsmodell - Performance-Profiling für Inferenz-Latenz

Promotion: Genehmigte Modelle werden in die Produktion deployed: - Traffic wird graduell zur neuen Version verschoben - Monitoring erkennt Degradation - Rollback wird ausgelöst, wenn Metriken sinken

Plattformvergleich

MLflow

MLflow bietet die umfassendste Open-Source Model Registry:⁵

Model Registry Features: - Zentralisierter Modellspeicher mit Versionierung und Aliasing - Lineage-Tracking (Experiment → Run → Modell) - Stage-Übergänge (Staging, Production, Archived) - Annotationen und Metadaten-Tagging - REST API für programmatischen Zugriff

MLflow 3.0 Erweiterungen: - LoggedModel-Entity verbindet Modelle mit Code, Prompts und Evaluierungen - Erweitertes Tracing für generative KI-Anwendungen - Agent-Support für komplexe KI-Systeme - Databricks bietet eine verwaltete Enterprise-Version

Beispiel-Workflow:

import mlflow

# Modell während des Trainings loggen
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 0.001, "epochs": 10})
    mlflow.log_metrics({"accuracy": 0.95, "f1": 0.92})
    mlflow.pyfunc.log_model("model", python_model=trained_model)

# In Model Registry registrieren
model_uri = f"runs:/{run_id}/model"
mlflow.register_model(model_uri, "fraud-detection-model")

# In Produktion promoten
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="fraud-detection-model",
    version=3,
    stage="Production"
)

Am besten für: Organisationen, die umfassende MLOps-Fähigkeiten mit Open-Source-Flexibilität wünschen.

Weights & Biases

W&B betont Experiment-Tracking mit starker Artefakt-Versionierung:⁶

Kernfähigkeiten: - Experiment-Tracking mit reichhaltiger Visualisierung - Artefakt-Versionierung mit Lineage-Graphen - Model Registry mit Aliases (@champion, @production) - Kollaborationsfunktionen für Team-Workflows - Integration mit wichtigen ML-Frameworks

Artefakt-Versionierung:

import wandb

run = wandb.init(project="nlp-models")

# Modell als Artefakt loggen
artifact = wandb.Artifact("bert-classifier", type="model")
artifact.add_file("model.pt")
run.log_artifact(artifact)

# Mit Registry mit Alias verknüpfen
run.link_artifact(artifact, "model-registry/bert-classifier",
                  aliases=["latest", "production"])

Überlegungen: Die Cloud-first-Architektur erfordert das Senden von Daten an externe Server, was mit strengen Datenschutzanforderungen kollidieren kann.

Am besten für: Teams, die Experiment-Tracking und Kollaboration mit minimalem Setup-Aufwand priorisieren.

DVC (Data Version Control)

DVC erweitert Git für große Dateien und Datasets:⁷

Architektur: - Git-ähnliche Befehle (dvc add, dvc push, dvc pull) - Metadatendateien in Git verfolgt, große Dateien im Remote-Storage - Pipeline-Definitionen für reproduzierbare Experimente - Mehrere Storage-Backends (S3, GCS, Azure, SSH)

Aktuelle Entwicklung: DVC ist der lakeFS-Familie beigetreten, wobei lakeFS als Enterprise-Standard für Petabyte-skalierte Datenversionierung dient.

Beispiel-Workflow:

# Große Modelldatei zu DVC hinzufügen
dvc add models/bert-finetuned.pt

# Metadaten in Git committen
git add models/bert-finetuned.pt.dvc .gitignore
git commit -m "Add fine-tuned BERT model v1.0"

# Zu Remote-Storage pushen
dvc push

# Von jedem Commit reproduzieren
git checkout v1.0
dvc checkout

Am besten für: Teams mit bestehenden Git-Workflows, die leichtgewichtige Daten- und Modell-Versionierung wünschen.

Cloud-native Registries

Vertex AI Model Registry (Google Cloud):⁸ - Native GCP-Integration - Direktes Deployment zu Endpoints - Automatisches Lineage-Tracking - Integration mit Vertex AI Pipelines

Amazon SageMaker Model Registry: - AWS-Ökosystem-Integration - Genehmigungs-Workflows - Cross-Account-Modellfreigabe - Integration mit SageMaker Pipelines

Azure ML Model Registry: - Azure-Integration - MLflow-Kompatibilität - Managed Endpoints Deployment

Am besten für: Organisationen, die sich auf bestimmte Cloud-Provider festgelegt haben und native Integration wünschen.

LLM-spezifische Überlegungen

Large Language Models präsentieren einzigartige Versionierungsherausforderungen jenseits von traditionellem ML:⁹

Was versioniert werden sollte

Basismodelle: Verfolgen, welches Foundation Model (Llama 3.1-8B, GPT-4, Claude) als Ausgangspunkt dient.

Feinabgestimmte Gewichte: Vollständiges Fine-Tuning produziert komplett neue Gewichtsdateien; LoRA-Adapter produzieren kleine Delta-Dateien, die auf Basismodelle referenzieren.

Prompt-Templates: System-Prompts, Few-Shot-Beispiele und Instruktionsformate beeinflussen das Modellverhalten erheblich.

Retrieval-Konfigurationen: RAG-Systeme erfordern Versionierung von Embedding-Modellen, Chunking-Strategien und Retrieval-Parametern.

Semantische Versionierung für LLMs

Semantische Versionierung anwenden, um die Bedeutung von Änderungen zu kommunizieren:¹⁰

Major-Version (v2.0.0): - Anderes Basismodell - Architekturänderungen - Breaking API-Changes

Minor-Version (v1.3.0): - Fine-Tuning auf neuen Daten - Signifikante Performance-Verbesserungen - Neue Fähigkeiten hinzugefügt

Patch-Version (v1.2.1): - Bugfixes - Kleinere Optimierungen - Konfigurationsupdates

Adapter-Management

LoRA und QLoRA erzeugen proliferierende Adapter-Dateien, die systematische Organisation erfordern:

base-model/
├── llama-3.1-8b/
│   └── v1.0.0/
│       ├── weights/
│       └── config.json
└── adapters/
    ├── customer-support-v1/
    │   ├── adapter_model.bin
    │   └── adapter_config.json
    ├── code-generation-v2/
    └── summarization-v1/

Adapter-Versionierungsstrategie: - Adapter unabhängig von Basismodellen versionieren - Kompatible Basismodellversionen dokumentieren - Trainingsdaten und Hyperparameter pro Adapter verfolgen - Schnelles Umschalten zwischen Adaptern beim Serving ermöglichen

Deployment-Strategien

Canary Deployments

Kleinen Traffic-Prozentsatz zur neuen Modellversion routen, bevor vollständig ausgerollt wird:¹¹

# Kubernetes Canary-Konfiguration
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: model-service
        subset: v1
      weight: 90
    - destination:
        host: model-service
        subset: v2
      weight: 10

Prozess: 1. Neue Version neben Produktion deployen 2. 5-10% des Traffics zur neuen Version routen 3. Metriken überwachen (Latenz, Fehlerrate, Geschäftsmetriken) 4. Traffic graduell erhöhen, wenn Metriken stabil bleiben 5. Rollout abschließen oder Rollback basierend auf Ergebnissen

Tooling: Istio, Argo Rollouts und Flagger automatisieren Progressive Delivery mit automatischem Rollback bei Metrik-Degradation.

A/B-Testing

Modellversionen vergleichen, um Geschäftsauswirkungen zu messen:¹²

Wesentliche Unterschiede zu Canary: - Canary erkennt Probleme (Minuten bis Stunden) - A/B-Testing misst Auswirkungen (Tage bis Wochen) - Statistische Signifikanz für A/B-Schlussfolgerungen erforderlich

Implementierung: - User-IDs für konsistentes Routing hashen - Conversion-Metriken pro Variante verfolgen - Laufen lassen, bis statistische Signifikanz erreicht ist - Ergebnisse für zukünftige Referenz dokumentieren

Shadow Deployment

Produktions-Traffic zur neuen Modellversion routen, ohne Antworten zu liefern:

Vorteile: - Mit echten Traffic-Mustern testen - Outputs ohne Benutzerauswirkung vergleichen - Edge Cases vor Deployment identifizieren

Implementierung: - Produktionsmodell liefert Antworten - Shadow-Modell verarbeitet dieselben Requests - Outputs werden verglichen, aber nicht an Benutzer zurückgegeben - Diskrepanzen lösen Untersuchung aus

Rollback-Prozeduren

Jedes Deployment benötigt Rollback-Fähigkeit:

Sofortiger Rollback:

# Traffic-Routing-Rollback
kubectl set image deployment/model-service model=model:v1.2.0

# Feature-Flag-Rollback
feature_flags.disable("new_model_v2")

Registry-basierter Rollback: ```py

[Inhalt für Übersetzung gekürzt]