Snowflake Model Registry: Log, Promote and Serve Models

1.Logging a model into the registry

In Snowflake, putting a model into production starts with the Model Registry. Any schema can act as a registry. You don't need to set it up first, but Snowflake recommends a dedicated schema such as ML.REGISTRY. You open the registry with the Registry class, then add models through the reference it returns. The Python API has three main classes: Registry manages the models in a schema, Model represents a model, and ModelVersion represents one version of it.

The registry has built-in support for the most common model types: scikit-learn, xgboost, LightGBM, Prophet, CatBoost, PyTorch, TensorFlow, Keras, Hugging Face pipelines, Sentence Transformer and MLFlow pyfunc. It also accepts other previously trained models and custom processing code. One boundary matters: models trained with Snowflake ML Functions such as FORECAST do not appear in the registry at all.

from snowflake.ml.registry import Registry

reg = Registry(session=session, database_name="ML", schema_name="REGISTRY")

Adding a model is called *logging* it. log_model serializes the Python object, which must be pickleable, and creates a Snowflake model object from it. Each call adds one version. To add another version, call log_model again with the same model_name and a new version_name. The name and version together must be unique in the schema. In the same call you can attach a comment, metrics and a sample of the input data, and you can list conda_dependencies so those packages are deployed with the model. You cannot set tags here: tags belong to the model, and the model object only exists once its first version has been logged. You can add tags afterwards.

from snowflake.ml.model import task, type_hints
mv = reg.log_model(clf,
                   model_name="my_model",
                   version_name="v1",
                   conda_dependencies=["scikit-learn"],
                   comment="My awesome ML model",
                   metrics={"score": 96},
                   sample_input_data=train_features,
                   task=task.Task.TABULAR_BINARY_CLASSIFICATION)

from snowflake.ml.model import task, type_hints
mv = reg. ? (clf,
                   model_name="my_model",
                   version_name="v1",
                   conda_dependencies=["scikit-learn"],
                   comment="My awesome ML model",
                   metrics={"score": 96},
                   sample_input_data=train_features,
                   task=task.Task.TABULAR_BINARY_CLASSIFICATION)

Sources1

2.Retrieving a version and running inference

After a model is logged, you call its methods to run inference. Snowflake treats these methods like functions or stored procedures. From Python, you get the ModelVersion back from the registry by model name and version name.

from snowflake.ml.registry import Registry

registry = Registry(session=session, database_name=DATABASE, schema_name=REGISTRY_SCHEMA)
mv = registry.get_model('my_model').version('my_version')  # returns ModelVersion

The version's run method runs a batch inference job on either a warehouse or an SPCS compute pool. You pass it a Snowpark or pandas DataFrame, and it returns the same kind: pandas in, pandas out. Snowpark DataFrames are evaluated lazily, so nothing runs until you call collect, show or to_pandas.

You can call the same methods from SQL. my_model!predict(...) calls the default version. MODEL(my_model, <version or alias>)!predict(...) calls a specific version by name or alias.

Two arguments of run are worth knowing. function_name names the method to call, such as predict; mv.show_functions lists the methods a version offers. To run on SPCS instead of a warehouse, add the service_name argument to the same call. In SQL, the default-version form is MODEL(<model_name>)!<method_name>(...), with the table that holds the inference data in the FROM clause. To target a specific version, use MODEL(<model_name>,<version_or_alias_name>)!<method_name>(...). A service deployed in SPCS is called with service_name!method_name(...).

remote_prediction = mv.run(input_features, function_name="predict", service_name="example_spcs_service")

Sources21

3.Promoting a version: default version and aliases

The simplest way to manage production is to treat the default version as the production version. Production code calls only the default, and you release a new model by changing which version is the default. When the first version is logged, it becomes the default automatically. Because a model can never be without a default, the docs suggest one workaround if you need to block use before anything is ready: log an initial version that immediately throws an error, and keep it as the default until a real version is ready.

ALTER MODEL my_model SET DEFAULT_VERSION = new_version;

If you need more stages than development and production, use aliases. An alias is a label that can sit on only one version at a time, for example alpha, beta or production. Consumers call MODEL(my_model, production)!predict(...). To promote a version, you move the label, and consumer code stays the same. If a role other than the model owner must approve releases, you can put the live version name in a tag instead and read it with SYSTEM$GET_TAG. Another option is to copy approved models into a separate production schema.

SELECT MODEL(my_model, production)!predict(...) FROM ...;

Sources3

4.Granting access to production consumers

Models are Snowflake objects, so normal role-based access control applies to them. To create a model, a role must own the schema or have CREATE MODEL on it. A model has three privileges, and the one you grant determines which kind of inference the consumer can run.

You can grant either privilege on a single model, on all existing models in a schema, or on future models, for example GRANT USAGE ON FUTURE MODELS IN SCHEMA <schema> TO ROLE <role>;.

Sources3

5.Warehouse or Snowpark Container Services

The registry gives you one interface to two compute engines: the warehouse and Snowpark Container Services (SPCS). Which one to use depends on latency, the type of data and how you need to scale. Warehouse-deployed models have a maximum total size of 15 GB, and that limit is lower on smaller warehouse sizes. A warehouse is also a poor fit when the model requires a GPU, while SPCS suits large models and models that need GPUs.

To serve a model version in SPCS, call create_service on it. It builds an image and runs the model as a service.

Creating a service takes time: up to 10 minutes for a CPU model and up to 20 for a GPU model, and longer if the compute pool is idle or resizing. If you send SQL inference to an SPCS-deployed model, route it through an XSMALL or SMALL warehouse. A larger warehouse sends so many concurrent requests that it can overwhelm the service.

Sources425

6.Calling an externally hosted model with external functions

A model does not have to be hosted in Snowflake. An external function is a type of UDF that holds no code of its own: it calls code stored and executed outside Snowflake, known as the remote service. The remote service must accept JSON inputs, return JSON outputs and expose an HTTPS endpoint.

Snowflake does not call the remote service directly. It calls a proxy service such as Amazon API Gateway, which relays the data and the response. The security information needed to reach the proxy is stored in an API integration. External functions must be scalar, so the remote service must return exactly one row for each row it receives. Rows are sent in batches.

Sources6

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Granting USAGE on a model is enough for a role to call it in Snowpark Container Services.Why is that wrong?

   USAGE covers warehouse inference only. SPCS inference requires READ, which also exposes the model's metadata.

   Covered in Granting access to production consumers

2. 2.You can pass tags to log_model when you register a model for the first time.Why is that wrong?

   log_model adds a version, and the model object only exists once its first version is logged. Tags are added to the model afterwards.

   Covered in Logging a model into the registry

3. 3.create_service creates the compute pool it needs if one does not exist.Why is that wrong?

   The compute pool you name must already exist. The system pools SYSTEM_COMPUTE_POOL_CPU and SYSTEM_COMPUTE_POOL_GPU can be used if the model fits them.

   Covered in Warehouse or Snowpark Container Services