Model Registry

Die Model Registry fungiert als zentrales Bestandsverzeichnis ("Single Source of Truth") für alle KI-Modelle innerhalb der Plattform. Sie stellt sicher, dass Modelle nicht wild verteilt liegen, sondern zentral verwaltet, versioniert und kontrolliert bereitgestellt werden.

Anforderungen

Die Verwaltung der Modelle muss folgende Anforderungen erfüllen, um einen sicheren und stabilen Betrieb zu gewährleisten:

• Freigabe-Workflow für neue Modelle: Ein Modell darf nicht ungeprüft in den produktiven Einsatz gelangen. Es ist ein definierter Workflow erforderlich, bei dem ein Modell zunächst importiert (Staging), technisch und fachlich geprüft (Scanning auf Schadcode, Lizenzprüfung) und erst nach expliziter Genehmigung für die Nutzung freigeschaltet wird (Production). Dies verhindert, dass fehlerhafte oder unsichere Modelle von Anwendungen konsumiert werden.

• Speicherung von Modell-Attributen und Templates in einer Datenbank: Ein KI-Modell besteht aus mehr als nur den reinen Gewichtsdateien. Für die korrekte Inferenz sind Metadaten essenziell, die strukturiert (z.B. in einer PostgreSQL-Datenbank) abgelegt werden müssen. Dazu gehören:

  • Prompt-Templates: Das spezifische Format (z.B. ChatML, Alpaca), das das Modell erwartet.
  • Default-System-Prompts: Die Standard-Anweisung, die das Verhalten des Modells steuert.
  • Default-Aufrufparameter: Standardwerte für Parameter wie temperature, top_p oder stop_sequences, um konsistente Antworten zu gewährleisten.

• Verfügbarkeit der Modell-Parameter über einen Object-Store: Die eigentlichen Modelldateien (Weights, z.B. .gguf oder .safetensors) sind oft mehrere Gigabyte groß. Diese Binärdaten dürfen nicht in der Datenbank liegen, sondern müssen in einem skalierbaren Object-Store (S3-kompatibel, z.B. MinIO) gespeichert werden. Die Registry muss sicherstellen, dass die Inference-Engines diese Artefakte performant und zuverlässig laden können.

• Berechtigungsverwaltung (RBAC): Nicht jedes Modell darf von jedem Nutzer oder jeder Anwendung verwendet werden (z.B. aus Lizenzgründen oder wegen der Sensibilität des Fachverfahrens). Die Registry muss eine feingranulare Zugriffskontrolle ermöglichen, die regelt, wer (Benutzer, Service-Account) aus welchem Kontext (Organisation, Team, Anwendung) auf welches Modell zugreifen darf.

Kandidaten für eine Implementierung

MLflow Model Registry

Der Industriestandard für MLOps. Bietet ein vollständiges Lifecycle-Management und Versionierung. * Lizenz: Apache 2.0. * Eignung: Sehr mächtig, bringt aber auch Komplexität mit, die primär auf Training-Szenarien ausgelegt ist.

Harbor (OCI Registry)

Harbor ist eine Container Registry, die auch OCI-Artefakte unterstützt. * Lizenz: Apache 2.0. * Eignung: In Kubernetes-Umgebungen oft schon vorhanden. Bietet starke Sicherheitsfeatures (Vulnerability Scanning, Signing), ist aber bei der Verwaltung von LLM-spezifischen Metadaten (Prompt-Templates) eingeschränkt.

Custom Implementation (MinIO + Datenbank)

Eine Eigenentwicklung auf Basis der Referenzarchitektur-Komponenten (PostgreSQL für Metadaten, MinIO für Blobs). * Eignung: Maximale Flexibilität für spezifische Verwaltungs-Metadaten und schlanke Integration in das LLM-Gateway.