Model Registry

A model registry is a versioned catalog of trained machine learning models. Each entry stores a model artifact, such as a file of model weights, together with the metadata needed to trust it: the training run that produced it, the data version, evaluation metrics such as mean average precision (mAP), input and output schema, owner, and approval status. Deployment pipelines and applications ask the registry for a named version, or for whichever version currently holds the production label, instead of passing weight files around, so every release and every rollback refers to an exact, recorded model. In machine learning operations (MLOps), the registry sits between experiment tracking and model deployment. Widely used registries include the MLflow Model Registry, Amazon SageMaker Model Registry, Vertex AI Model Registry, and the Weights & Biases Registry.

How a Model Registry Works#

A registered model is a name, such as defect-detector, that holds a sequence of versions. Each version is immutable once registered, so new weights always become a new version and version 7 always means the same bytes. A version typically records:

• Lineage: The run ID, code commit, dataset version, and parent model that produced it.
• Evaluation results: Validation metrics, plus latency and memory measured on each target device.
• Signature: The expected input and output schema, so a caller sending the wrong shape fails fast.
• Model card: Documentation of intended use, training data, and known limitations.
• Status: Tags and aliases that mark where the version stands.

Ultralytics Platform keeps this kind of record for every YOLO training run it hosts: the model page lists the parent model, pinned dataset version, Git commit, ultralytics version, hyperparameters, final metrics, and a reproducible yolo train command, and a Custom Metadata field accepts a JSON object for release tracking or governance.

Older registries moved each version through fixed stages such as Staging, Production, and Archived. MLflow deprecated stages in version 2.9.0 in favor of aliases, mutable named pointers such as @champion that a team moves between versions. Amazon SageMaker tracks an approval status of PendingManualApproval, Approved, or Rejected on each version. Promoting a model means moving its alias, and a rollback means moving the alias back:

Registries also control who may change what. Data scientists can register versions, designated reviewers move the production alias, and every change lands in an audit log. Teams often wire these events to automation, so approving a version starts the deployment pipeline, and a model monitoring alert about data drift starts the retraining that registers the next candidate.

MLflow's registry shows the pattern in a few lines. This script trains a small scikit-learn classifier, registers it, points the champion alias at the new version, and loads the model through the alias, the way model serving code finds the current production model:

import mlflow
from mlflow import MlflowClient
from sklearn.datasets import load_iris
from sklearn.linear_model import LogisticRegression

# Keep runs and registered model versions in a local SQLite file
mlflow.set_tracking_uri("sqlite:///mlflow.db")
X, y = load_iris(return_X_y=True)

# Log a trained model inside a run, then register it as a new version
with mlflow.start_run():
    model = LogisticRegression(max_iter=200).fit(X, y)
    info = mlflow.sklearn.log_model(model, name="model")
version = mlflow.register_model(info.model_uri, "iris-classifier")

# Point the "champion" alias at this version; applications load the alias
MlflowClient().set_registered_model_alias("iris-classifier", "champion", version.version)
champion = mlflow.pyfunc.load_model("models:/iris-classifier@champion")
print(f"version {version.version}:", champion.predict(X[:3]))

On a fresh database the script prints version 1: [0 0 0], the registered version and its predicted classes for the first three flowers. Running it again registers version 2, and the same models:/iris-classifier@champion URI follows the alias to it with no change to the loading code.

Model Registry vs. Related Tools#

• Experiment tracking: Records every training run, including the many that are never used. The registry keeps the few candidates worth deploying and links each version back to its run.
• Object storage: Buckets such as Amazon S3 hold the files. A registry adds versions, metadata, and access control, and often stores only a pointer to the file in the bucket.
• Feature store: Versions and serves the input features that models consume, with the models themselves kept in the registry.
• Container registry: Stores the Docker images that run models, so a deployment usually names one image tag and one model version.
• Hugging Face Hub: Hosts public and private models in Git repositories with commit history and a model card on each repository's front page, which makes it a registry for open-weight models.