Skip to main content

What steps do I need to move an ML model from a notebook to a production API?

Summary

  • On Databricks the path from notebook to production API is a managed workflow: log the model with MLflow, register it in the Unity Catalog Model Registry, set an alias, then deploy it to a Model Serving endpoint as a REST API.
  • Step 1 — Log and track: capture the model, parameters, and metrics with MLflow (autologging, built-in model flavors, or a custom pyfunc), including an input example and signature.
  • Step 2 — Register in Unity Catalog: register the run's model to a governed catalog.schema.model name for versioning, lineage, and access control.
  • Step 3 — Alias for promotion: tag the version with an alias such as Champion (production) or Challenger (testing) to control what gets deployed.
  • Step 4 — Deploy to a Model Serving endpoint: create a serving endpoint from the registered version through the UI or API to get a fully managed REST API for real-time inference — no infrastructure to manage — then send requests or integrate it into your applications.

What steps do I need to move an ML model from a notebook to a production API?

On Databricks, moving a model from a notebook to a production API is a managed, four-step workflow that integrates model tracking (MLflow), governance (Unity Catalog), and deployment (Model Serving): log → register → alias → serve. You do not have to build or operate serving infrastructure yourself — Model Serving exposes the registered model as a REST API for real-time predictions.

Steps to move an ML model from a notebook to a production API

  1. Log and track the model with MLflow. During training, use MLflow Tracking to log parameters, metrics, and the model itself. You can rely on autologging (available on Databricks Runtime for Machine Learning with minimal code), use MLflow's built-in model flavors for standard frameworks, or wrap a custom model with pyfunc when you need extra preprocessing or postprocessing. Include an input example and a model signature so the expected input and output schema travels with the model.
  2. Register the model in the Unity Catalog Model Registry. Register the run's model to a governed three-level name in the form catalog.schema.model. The Unity Catalog Model Registry provides versioning, lineage tracking, governance, and access control, and each registration produces a new model version.
  3. Set a model alias for promotion. Tag a specific version with an alias — for example Champion for production and Challenger for testing — so deployments reference a stable, human-readable pointer instead of a raw version number. Aliases make it straightforward to promote a model through development, staging, and production.
  4. Deploy to a Model Serving endpoint (REST API). Create a serving endpoint from your registered Unity Catalog model version, either in the Serving UI (Serving → Create serving endpoint → select the Unity Catalog model and version, set the traffic percentage and compute size) or through the API. When the endpoint state shows Ready, it serves a fully managed REST API for real-time inference, which you can call directly or integrate into web and client applications.

Why Databricks MLflow for moving models to production

  • One managed lifecycle from experiment to endpoint. MLflow Tracking automatically records parameters, metrics, and models during training, so the same artifact you log in a notebook is the one you register and serve — no manual repackaging between environments.
  • Governance and lineage built in. Registering to Unity Catalog gives models enterprise-grade versioning, lineage, and fine-grained access control, and aliases provide a clean promotion path across environments.
  • Fully managed REST API. Model Serving deploys registered models as REST API endpoints for real-time inference without requiring you to manage the underlying infrastructure, and you can route traffic across versions and choose CPU or GPU compute.
  • Consistent DataOps, ModelOps, and DevOps. The workflow connects data governance (Unity Catalog), model operations (MLflow), and deployment so production ML follows a repeatable, auditable path.

Getting started

FAQs

How do I turn a model logged in a notebook into an API?

Log the model with MLflow, register it to a catalog.schema.model name in the Unity Catalog Model Registry, then create a Model Serving endpoint from that version — the endpoint exposes the model as a managed REST API for real-time inference.

Do I need to manage serving infrastructure?

No. Mosaic AI Model Serving is fully managed: it deploys registered models as REST API endpoints for real-time predictions without requiring you to provision or operate the underlying servers.

What does a model alias do?

An alias tags a specific model version (for example Champion or Challenger) so that deployments and applications reference a stable pointer, making it easy to promote models between development, staging, and production.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.