Model stages (staging, production, archived) in MLOps - Commands & Configuration

Introduction

When you train machine learning models, you need a way to organize them by their readiness. Model stages help you separate models that are being tested, models ready for use, and old models you want to keep but not use. This keeps your work clear and safe.

When you want to test a new model version without affecting the current one used in your app.

When you have a model ready and want to mark it as the official one for predictions.

When you want to keep old models for reference or rollback but not use them actively.

When you want to automate deployment steps based on model readiness.

When you want to track model progress clearly in your machine learning workflow.

Commands

This command starts a local server to serve the model from a specific run. It helps you test the model in staging before production.

Terminal

mlflow models serve -m runs:/1234567890abcdef/model -p 1234

Expected Output

2024/06/01 12:00:00 INFO mlflow.models.cli: Starting MLflow model server...

2024/06/01 12:00:01 INFO mlflow.models.cli: Model server listening on port 1234

→

-m - Specifies the model path to serve

→

-p - Sets the port number for the server

This command moves the model version 1 to the Production stage, marking it as ready for real use.

Terminal

mlflow models transition-stage --model-name my-model --version 1 --stage Production

Expected Output

Model version '1' of 'my-model' transitioned to stage 'Production'.

→

--model-name - Specifies the registered model name

→

--version - Specifies the model version number

→

--stage - Specifies the target stage (e.g., Production, Staging, Archived)

This command archives the model version 1, meaning it is kept but not used for serving or training.

Terminal

mlflow models transition-stage --model-name my-model --version 1 --stage Archived

Expected Output

Model version '1' of 'my-model' transitioned to stage 'Archived'.

→

--model-name - Specifies the registered model name

→

--version - Specifies the model version number

→

--stage - Sets the model stage to Archived

This command lists all versions of the model with their current stages, so you can see which are in staging, production, or archived.

Terminal

mlflow models list-versions --model-name my-model

Expected Output

Version  Stage      Run ID

1        Production 1234567890abcdef

2        Staging    fedcba0987654321

3        Archived   1122334455667788

→

--model-name - Specifies the model to list versions for

Key Concept

If you remember nothing else from this pattern, remember: model stages help you safely manage and deploy machine learning models by clearly marking their readiness and use.

Code Example

MLOps

import mlflow
import mlflow.sklearn

# Log a model and set its stage
with mlflow.start_run() as run:
    mlflow.log_param("param1", 5)
    mlflow.sklearn.log_model(sk_model=None, artifact_path="model")
    model_uri = f"runs:/{run.info.run_id}/model"

# Register the model
model_name = "my-model"
result = mlflow.register_model(model_uri, model_name)

# Transition model to staging
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(name=model_name, version=result.version, stage="Staging")

print(f"Model version {result.version} is now in Staging stage.")

Common Mistakes

Trying to serve a model without setting it to Production stage first.

The model might not be stable or ready, causing errors or bad predictions in real use.

Test the model in Staging stage first, then transition it to Production when ready.

Archiving a model version that is still in use by the application.

Archived models are not served or updated, so the app will fail to find the model.

Ensure no active deployments use the model before archiving it.

Not listing model versions to check their stages before deployment.

You might deploy the wrong model version or miss important updates.

Always list and verify model versions and stages before deploying.

Summary

Use model stages to organize models by readiness: Staging for testing, Production for live use, Archived for old models.

Transition models between stages using mlflow CLI or Python client to control deployment safely.

List model versions and their stages to keep track of which models are active or archived.

Practice

1. What is the primary purpose of the staging stage in model lifecycle management?

easy

A. To deploy models for live user traffic

B. To test and validate models before they go live

C. To permanently delete old models

D. To archive models for long-term storage

Solution

1. Step 1: Understand model stages

   The staging stage is used to test and validate models before they are deployed to production.

2. Step 2: Differentiate from other stages

   Production is for live use, archived is for storage, so staging is the testing phase.

3. Final Answer:

   To test and validate models before they go live -> Option B

4. Quick Check:

   Staging = Testing phase [OK]

Hint: Staging means testing before live use [OK]

Common Mistakes:

• Confusing staging with production
• Thinking archived means active use
• Assuming staging is for deleting models

2. Which MLflow command correctly transitions a model version to the production stage?

easy

A. mlflow models transition-version --model-name my_model --version 3 --stage production

B. mlflow model transition-version --model-name my_model --version 3 --to-stage production

C. mlflow models transition-version --model-name my_model --model-version 3 --stage production

D. mlflow models transition --model-name my_model --model-version 3 --stage production

Solution

1. Step 1: Recall MLflow CLI syntax

   The correct MLflow CLI command to transition a model version is mlflow models transition-version with flags --model-name, --version and --stage.

2. Step 2: Identify correct flags and command

   mlflow models transition-version --model-name my_model --version 3 --stage production matches the correct syntax.

3. Final Answer:

   mlflow models transition-version --model-name my_model --version 3 --stage production -> Option A

4. Quick Check:

   Correct MLflow syntax = mlflow models transition-version --model-name my_model --version 3 --stage production [OK]

Hint: Use 'transition-version' with --version and --stage flags [OK]

Common Mistakes:

• Using 'model' instead of 'models'
• Mixing up --model-version and --version flags
• Incorrect command order or missing flags

3. Given this MLflow Python snippet, what will be the stage of the model after execution?

from mlflow import MlflowClient
client = MlflowClient()
client.transition_model_version_stage(
    name="my_model",
    version=2,
    stage="archived"
)

medium

A. Archived

B. Production

C. Staging

D. None (error)

Solution

1. Step 1: Understand the method call

   The method transition_model_version_stage changes the stage of a model version to the specified stage.

2. Step 2: Check the stage argument

   The stage argument is set to "archived", so the model version 2 of "my_model" will be moved to archived stage.

3. Final Answer:

   Archived -> Option A

4. Quick Check:

   transition_model_version_stage with stage='archived' = Archived [OK]

Hint: Stage argument sets the model's new stage directly [OK]

Common Mistakes:

• Assuming default stage if not specified
• Confusing method name with other MLflow functions
• Thinking 'archived' means deletion

4. You run this MLflow CLI command but get an error:

mlflow models transition-version --version 5 --stage production

What is the most likely cause?

medium

A. The command should be mlflow model transition-version (singular 'model')

B. Incorrect stage name; should be 'prod' instead of 'production'

C. Version number must be a string, not a number

D. Missing the --model-name argument

Solution

1. Step 1: Check required arguments for transition-version

   The mlflow models transition-version command requires the --model-name argument to specify which model to update.

2. Step 2: Identify missing argument

   The command lacks --model-name, causing the error.

3. Final Answer:

   Missing the --model-name argument -> Option D

4. Quick Check:

   Missing required flags cause errors [OK]

Hint: Always include --model-name when transitioning versions [OK]

Common Mistakes:

• Assuming stage names are abbreviated
• Using singular 'model' instead of 'models'
• Passing version as string instead of number (both accepted)

5. You have two model versions: v1 in production and v2 in staging. You want to promote v2 to production and archive v1 using MLflow Python API. Which sequence of calls correctly achieves this?

hard

A. client.transition_model_version_stage('model', 2, 'archived') then client.transition_model_version_stage('model', 1, 'production')

B. client.transition_model_version_stage('model', 2, 'production') then client.transition_model_version_stage('model', 2, 'archived')

C. client.transition_model_version_stage('model', 1, 'archived') then client.transition_model_version_stage('model', 2, 'production')

D. client.transition_model_version_stage('model', 1, 'production') then client.transition_model_version_stage('model', 2, 'staging')

Solution

1. Step 1: Archive current production version first

   To free the production stage, first move v1 from production to archived.

2. Step 2: Promote staging version to production

   After archiving v1, promote v2 from staging to production.

3. Final Answer:

   Archive v1 then promote v2 -> Option C

4. Quick Check:

   Archive old before promoting new [OK]

Hint: Archive old production before promoting new [OK]

Common Mistakes:

• Promoting new before archiving old causes stage conflict
• Archiving staging version instead of production
• Reassigning stages incorrectly