4: Model Deployment

Learning Objectives

By the end of this chapter, you will be able to:

• Move a data science model into production.
• Determine the effectiveness of a model and retrain if necessary.
• Outline model lifecycle and validation tools.

Executive Summary

• Deployment surface selection is driven by latency budget, batch size, dependency footprint, and GPU requirement rather than by personal preference.
• The Snowflake Model Registry treats a model as a versioned, taggable, first-class schema object whose inference methods are invoked from SQL or Python without the developer managing the underlying stage layout.
• Drift is detected by comparing distributions of features, predictions, or labels against a reference window. Each comparison answers a different operational question and triggers a different remediation.
• Retraining is automated by binding a Snowflake Task to a metric threshold or to a row-count trigger from a Stream, not by hand-running notebooks.

Assumptions

• The reader has registered at least one Snowpark ML model version to a Snowflake Model Registry instance and confirmed it returns predictions via the run() Python method.
• Code samples assume a fictional retail-bank deployment with database ML_PROD_DB, schema SCORING, warehouse ML_INFERENCE_WH, and a churn-prediction model named CHURN_PREDICTOR.
• Snowpark Container Services capacity (compute pools, image repositories) is provisioned by a platform team; this chapter focuses on the data scientist's interface.
• Snowpark Container Services and Model Serving on SPCS are available in commercial AWS, Azure, and Google Cloud regions; government regions are out of scope.