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
| Capability | Why It Matters |
|---|---|
| Version tracking | Every registered model gets a version number, with full history preserved |
| Stage management | Models move through defined stages (e.g. staging → production → archived), with a clear record of what's currently live |
| Metadata and lineage | Which data, code, and experiment run produced this specific model version |
| Approval workflows | Often supports requiring review/approval before a model transitions to production, adding a safety checkpoint |
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 filesCommon 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?
