Express deployments for model serving endpoints

This page describes how to use express deployments on your model serving endpoints. Express deployments lower deployment times and keep the model serving environment the same as the model training environment.

note

Express deployments were previously called serverless optimized deployments.

What are express deployments?

Express deployments package and stage model artifacts in serverless notebook environments during model registration. This speeds up endpoint deployment and keeps the training and serving environments consistent.

In non-express deployments, model artifacts and environments are packaged into containers at deployment time, so the serving environment may not match the one used during model training.

Standard vs express deployments

The following table compares a standard deployment and an express deployment.

Aspect	Standard deployment	Express deployment
When the environment is built	A container image is built at deployment time.	Artifacts and the environment are packaged when you register the model.
Training and serving environment	The serving environment might not match the training environment.	The serving environment is identical to the notebook environment you registered from.
Deployment speed	Slower. The deployment waits for a container image build.	Faster. The deployment skips the container image build.
Registration speed	Standard.	Adds seconds to a minute for packaging, depending on model and environment size.
Deployment event log	Shows container image creation events.	Does not show container image creation events.

Aspect	Standard deployment	Express deployment
When the environment is built	A container image is built at deployment time.	Artifacts and the environment are packaged when you register the model.
Training and serving environment	The serving environment might not match the training environment.	The serving environment is identical to the notebook environment you registered from.
Deployment speed	Slower. The deployment waits for a container image build.	Faster. The deployment skips the container image build.
Registration speed	Standard.	Adds seconds to a minute for packaging, depending on model and environment size.
Deployment event log	Shows container image creation events.	Does not show container image creation events.

Express deployments move the one-time packaging work to model registration, which adds seconds to a minute to a register_model call, depending on model and environment size. In exchange, deployment is significantly faster: it skips the container image build entirely. That build is also a common source of deployment failures (dependency resolution, image build errors), so skipping it removes a whole class of problems. The deployment event log for an express model contains no container build events.

Requirements

Express deployment endpoints have the same requirements as a model serving endpoint. See Requirements.

In addition:

• The model must be a custom model
• The model must be logged and registered in a Serverless Notebook using version 3 or later
• The model must be logged and registered with mlflow>=3.12 and databricks-sdk>=0.102.0
• The model must be registered in Unity Catalog and served on CPU compute. Register from a regular serverless notebook.
• The model's max environment size is 200GB

The env_pack parameter

Enable express deployment by passing env_pack to register_model:

Python

import mlflow
from mlflow.utils.env_pack import EnvPackConfig

mlflow.register_model(
    model_info.model_uri,
    model_name,
    env_pack=EnvPackConfig(name="databricks_model_serving"),
)

env_pack packs and stages the model artifacts and the dependencies you added to the notebook session at registration time, which is why registration takes longer than a call without env_pack.

EnvPackConfig accepts an install_dependencies parameter (True by default). When True, the model's dependencies are installed in the current environment to confirm the environment is valid.

note

Registration can fail in workspaces without internet access, or when the model depends on custom libraries, if install_dependencies is True. In these cases, set install_dependencies to False.

You can substitute the string "databricks_model_serving" for EnvPackConfig(...) as a shorthand. It is equivalent to EnvPackConfig(name="databricks_model_serving", install_dependencies=True).