Model aliases are MLflow’s way of giving a human-readable name to a specific model version, enabling a champion-challenger strategy for managing model deployments.
Let’s see this in action. Imagine we have a model my-fraud-detector and we want to manage its versions using aliases.
First, we log a few versions of our model.
import mlflow
from mlflow.models import infer_signature
from sklearn.linear_model import LogisticRegression
import pandas as pd
# Assume we have some dummy data and a trained model
X_train = pd.DataFrame({'feature1': [1, 2, 3], 'feature2': [4, 5, 6]})
y_train = pd.Series([0, 1, 0])
model_v1 = LogisticRegression()
model_v1.fit(X_train, y_train)
# Log model version 1
with mlflow.start_run(run_name="log_model_v1"):
signature = infer_signature(X_train, model_v1.predict(X_train))
mlflow.sklearn.log_model(
sk_model=model_v1,
artifact_path="model",
registered_model_name="my-fraud-detector",
signature=signature
)
This will register a new model named my-fraud-detector and log the first version. Now, let’s log a second version with improved performance.
# Assume model_v2 is a more performant model
X_train_v2 = pd.DataFrame({'feature1': [1, 2, 3, 4], 'feature2': [4, 5, 6, 7]})
y_train_v2 = pd.Series([0, 1, 0, 1])
model_v2 = LogisticRegression()
model_v2.fit(X_train_v2, y_train_v2)
with mlflow.start_run(run_name="log_model_v2"):
signature_v2 = infer_signature(X_train_v2, model_v2.predict(X_train_v2))
mlflow.sklearn.log_model(
sk_model=model_v2,
artifact_path="model",
registered_model_name="my-fraud-detector",
signature=signature_v2
)
After logging both versions, we can inspect them in the MLflow UI. You’ll see my-fraud-detector with Version 1 and Version 2.
Now, let’s introduce aliases for a champion-challenger setup. We’ll designate Version 1 as the production champion and Version 2 as the staging challenger.
from mlflow.tracking import MlflowClient
client = MlflowClient()
# Set alias for production (champion)
client.set_registered_model_alias(
name="my-fraud-detector",
alias="production",
version="1"
)
# Set alias for staging (challenger)
client.set_registered_model_alias(
name="my-fraud-detector",
alias="staging",
version="2"
)
With these aliases, you can now refer to specific model versions by their alias, abstracting away the version numbers. For example, when deploying, you’d target my-fraud-detector@production or my-fraud-detector@staging.
The core problem aliases solve is managing the lifecycle of models in production without constantly updating deployment configurations with new version numbers. Instead of pointing your deployment to my-fraud-detector/1 or my-fraud-detector/2, you point it to my-fraud-detector@production. When you’re ready to promote Version 2 to production, you simply update the production alias to point to Version 2, and your deployment automatically picks up the new model. This decoupling is crucial for smooth CI/CD pipelines for machine learning.
To retrieve a model using its alias, you’d use:
# Load the model currently aliased as 'production'
production_model_uri = f"models:/my-fraud-detector@production"
loaded_model = mlflow.sklearn.load_model(production_model_uri)
# Make a prediction
predictions = loaded_model.predict(pd.DataFrame({'feature1': [7], 'feature2': [8]}))
print(f"Prediction from production model: {predictions}")
This mechanism allows for A/B testing and gradual rollouts. You could deploy Version 1 to 90% of traffic (production alias) and Version 2 to 10% (challenger alias). Based on performance metrics, you can then decide to promote the challenger.
The MlflowClient is your primary tool for managing aliases programmatically. You can list aliases, search for models by alias, and update them.
# List all aliases for the model
aliases = client.search_registered_model_aliases(name="my-fraud-detector")
print("Current aliases:", aliases)
# Get the version associated with an alias
alias_info = client.get_registered_model_alias(name="my-fraud-detector", alias="production")
print(f"The 'production' alias points to version: {alias_info.version}")
The set_registered_model_alias function is idempotent; calling it multiple times with the same alias and version will have no adverse effect. If you want to change which version an alias points to, you simply call set_registered_model_alias again with the new version.
Crucially, when you update an alias (e.g., move production from v1 to v2), any active deployments or services that are already loaded with the model pointed to by that alias will not automatically update. They will continue to serve the version they loaded initially. The update only affects new requests for the model using the alias, or services that are reloaded or restarted. This is a deliberate design choice to prevent unexpected model switches in live systems.
The next logical step after mastering aliases for champion-challenger is to integrate this into an automated deployment pipeline, where alias updates trigger retraining or promotion based on monitoring metrics.