Model Registry

A model registry is a centralized system for managing trained model versions and tracking exactly which version is deployed where — the formalized, team-scale version of the artifact management discussed in DL Model Saving.

What a Model Registry Provides

Code — Registering and Promoting a Model (MLflow Example)

import mlflow
from mlflow.tracking import MlflowClient

client = MlflowClient()

# Register a new model version (often done automatically during training, as in the previous note)
model_version = mlflow.register_model(
    model_uri="runs:/abc123/model",
    name="image_classifier"
)

# Promote it to staging for further validation
client.transition_model_version_stage(
    name="image_classifier",
    version=model_version.version,
    stage="Staging"
)

# After validation passes, promote to production
client.transition_model_version_stage(
    name="image_classifier",
    version=model_version.version,
    stage="Production"
)

Why "Which Model Is Actually in Production Right Now" Is a Real Question

Without a registry, this question is often answered informally — a filename convention, a shared document, tribal team knowledge — all of which drift out of sync with reality over time. A model registry makes this an authoritative, queryable fact: exactly one (or a clearly defined set of) model version is tagged "Production" at any time, and that tag can be checked programmatically by the serving system itself.

Rollback — A Critical, Often-Overlooked Registry Benefit

# If a newly deployed model version turns out to perform poorly in production,
# a registry makes rolling back to the previous known-good version straightforward
client.transition_model_version_stage(
    name="image_classifier",
    version=previous_good_version,
    stage="Production"
)
# The serving system, which reads the "Production"-tagged version, now uses
# the rolled-back version -- without needing to retrain or manually locate old files

Common Mistakes

• Relying on filenames or informal conventions (e.g. model_final_v2_ACTUAL.pt) to track which model version is current — this doesn't scale reliably and is a common source of confusion and deployment errors in real teams.
• Not maintaining a straightforward rollback path — without a registry's version history, reverting to a previous known-good model after a bad deployment can require scrambling to relocate old artifacts.

Interview Relevance

Q: "Why does a formal model registry matter for a production ML team, beyond simply saving model files to a shared folder?" A shared folder doesn't inherently track version history, deployment stage, or lineage (which data/code/run produced which model) in a structured, queryable way — this information tends to drift out of sync or rely on informal conventions and tribal knowledge as a team and its model history grow. A registry makes "which model version is currently in production" an authoritative fact the serving system can check directly, and makes rollback to a previous known-good version straightforward if a new deployment causes problems.

Practice Question

A newly deployed model version is causing a spike in prediction errors in production. How does having a model registry make responding to this situation faster and safer?

Related DL Notes

• MLflow
• Model Versioning
• A/B Testing