Model Registry

Eine Modell-Registry ist ein zentralisiertes System zum Organisieren, Versionieren, Verwalten und Abrufen von Modellen für maschinelles Lernen über ihren gesamten Lebenszyklus hinweg. Sie verbindet Modelldateien, wie etwa angelernte Modellgewichte, mit Metadaten, die beschreiben, wie jedes Modell trainiert, evaluiert, genehmigt und bereitgestellt wurde. Als Kernkomponente des Machine Learning Operations (MLOps) bietet eine Registry Teams eine vertrauenswürdige Quelle, um zu entscheiden, welche Modellversion den Produktivverkehr bedienen soll.

Wie eine Modell-Registry funktioniert#

Die Modellregistrierung beginnt, nachdem ein Trainingslauf ein Kandidatenmodell hervorgebracht hat. Die Registry erstellt einen benannten Eintrag, weist eine Version zu und zeichnet Informationen auf, die zum Verständnis und zur Reproduktion des Artefakts erforderlich sind. Ein typischer Eintrag umfasst:

• Modellartefakt: Die serialisierten Gewichte, die Vorverarbeitungslogik, Konfigurationsdateien oder ein Verweis auf ihren Speicherort.
• Version: Ein unveränderlicher Bezeichner, der einen Kandidaten von einem anderen unterscheidet.
• Metriken und Parameter: Validierungsgenauigkeit, Präzision, Recall, Latenz, Dataset-Details, Hyperparameter und andere Messwerte.
• Abstammung (Lineage): Verbindungen zwischen dem Modell, seinem Quellcode, dem Trainingslauf und den Daten.
• Status: Bezeichnungen wie Kandidat, genehmigt (approved), abgelehnt (rejected), Champion oder archiviert.
• Bereitstellungsinformationen: Umgebungen und Endpunkte, die diese Version aktuell verwenden.

Plattformen implementieren diese Konzepte auf unterschiedliche Weise. Der MLflow Model Registry Workflow verwendet registrierte Modelle, Versionen, Aliase und Tags, während die Amazon SageMaker Model Registry Modellgruppen, Genehmigungsstatus, Lineage und Bereitstellungsautomatisierung unterstützt. Einige Systeme erfassen zudem eine Modellsignatur: das erwartete Eingabe- und Ausgabeschema, wie in der Snowflake-Dokumentation zu Modellsignaturen beschrieben.

Aliase wie champion oder production stellen stabile Namen bereit, die zwischen unveränderlichen Versionen verschoben werden können. Wie im Leitfaden zu Modell-Aliasen in Vertex AI erläutert, kann eine Anwendung einen Alias anfordern, ohne eine Versionsnummer hart zu kodieren.

Modell-Registry vs. verwandte Konzepte#

Eine Modell-Registry überschneidet sich mit mehreren ML-Tools, verfolgt jedoch einen eigenständigen Zweck:

• Experiment-Tracking zeichnet Trainingsläufe auf, einschließlich Parametern, Metriken und Zwischenartefakten. Eine Registry erhält ausgewählte Ergebnisse aus diesen Experimenten und verwaltet sie als Release-Kandidaten.
• Artefaktspeicher beherbergen große Dateien. Eine Registry kann diese Dateien direkt speichern, aber sie kann auch als Metadatenindex fungieren, der auf externen Objektspeicher verweist. Die Architektur der Kubeflow Model Registry veranschaulicht dieses auf Metadaten ausgerichtete Design.
• Versionskontrolle versioniert Code, während eine Modell-Registry trainierte Artefakte und deren ML-spezifische Metadaten versioniert. Die GitLab Model Registry kann Modellversionen mit CI/CD-Jobs, Protokollen, Metriken und Parametern verknüpfen.
• Modellbereitstellung macht ein ausgewähltes Modell für die Inferenz verfügbar. Die Registry identifiziert das genehmigte Artefakt; das Bereitstellungssystem führt es aus.
• Modellüberwachung beobachtet das Verhalten in der Produktion nach der Freigabe. Überwachungsergebnisse können die Evaluation, das erneute Training, die Registrierung und das Hochrufen einer Ersatzversion auslösen.

Eine Registry fungiert somit als Kontrollpunkt zwischen Experimentierung und Produktion, anstatt jede Komponente um sie herum zu ersetzen.

Praxisanwendungen#

In einem industriellen Inspektionssystem können Ingenieure einen Defektdetektor jedes Mal neu trainieren, wenn sich Kameras, Materialien oder Produktdesigns ändern. Die Registry kann die Dataset-Referenz jedes Modells, die mittlere durchschnittliche Präzision (mAP), die Inferenzlatenz und das unterstützte Hardwareformat beibehalten. Nachdem Tests bestätigt haben, dass Version 12 die Kratzererkennung verbessert, ohne Fehlalarme zu erhöhen, kann ein Freigabeberechtigter sie hochstufen und Version 11 für einen sofortigen Rollback behalten.

In der medizinischen Bildanalyse können mehrere Teams Tumorerkennungskandidaten evaluieren. Die Registrierung bewahrt die Validierungsergebnisse, die Trainingskonfiguration, den verantwortlichen Eigentümer und den Genehmigungsverlauf für jede Version auf. Produktionsanwendungen können auf überprüfte Modelle beschränkt werden, während ältere Versionen für Audits und die Reproduzierbarkeit verfügbar bleiben. Rollenbasierte Kontrollen, wie sie für die Governance der Snowflake Model Registry beschrieben werden, helfen dabei, unbefugte Ersetzungen oder Inspektionen sensibler Artefakte zu verhindern.

Modellregistrierung in Ultralytics-Workflows#

Ultralytics Platform bietet zentralisiertes Modellmanagement für das Kommentieren von Datasets, das Training, den Ergebnisvergleich, den Export, die Bereitstellung und die Überwachung von Computer-Vision-Modellen. Der dort dokumentierte Workflow für das Plattform-Modellmanagement unterstützt hochgeladene .pt-Gewichte und Modelle, die durch Cloud- oder Remote-Training erzeugt wurden.

Der folgende dokumentierte Workflow trainiert Ultralytics YOLO26 lokal und sendet gleichzeitig das resultierende Modell, die Konfiguration, Metriken und Protokolle an ein benanntes Plattform-Projekt:

import os

from ultralytics import YOLO

# Authenticate remote training with Ultralytics Platform
os.environ["ULTRALYTICS_API_KEY"] = "YOUR_API_KEY"

model = YOLO("yolo26n.pt")

model.train(
    data="coco8.yaml",
    epochs=3,
    project="username/model-registry-demo",
    name="candidate-001",
)

Das Projekt und der Name des Laufs machen den Kandidaten neben verwandten Modellen auffindbar. Teams können ihn evaluieren, die Ultralytics MLflow-Integration für zusätzliches Experiment-Logging nutzen oder den YOLO-Modellexport anwenden, wenn ein registriertes Modell auf spezifischer Cloud- oder Edge-Hardware ausgeführt werden muss.

Praktische Leitlinien für die Registry#

Behandeln Sie jede registrierte Version als unveränderlich. Verwenden Sie für die Bereitstellung menschenlesbare Aliase, bewahren Sie Validierungsnachweise auf und definieren Sie klare Anforderungen für die Hochstufung. Eine Namensrichtlinie basierend auf Semantic Versioning kann Kompatibilitätsänderungen kommunizieren, obwohl automatisch inkrementierte Versionen ebenfalls effektiv sind.

Am wichtigsten ist, dass Sie vollständige Modellpakete anstelle unerklärter Gewichtsdateien registrieren. Fehlende Vorverarbeitungsregeln, Klassennamen, Eingabeschemas, Abhängigkeiten oder Dataset-Referenzen können dazu führen, dass ein anscheinend gültiges Modell unmöglich zu reproduzieren oder unsicher in der Bereitstellung ist. Zugriffskontrollen, automatisierte Tests, Freigabetore, Audit-Logs und Rollback-Verfahren verwandeln eine Modell-Registry von einem Dateikatalog in eine zuverlässige Produktionsabsicherung.