Logging Models, Custom Models and Artifacts in the Snowflake Model Registry

1.Logging a model version with metadata and dependencies

You can use any Snowflake schema as a registry, and it needs no setup. Snowflake recommends a dedicated schema such as ML.REGISTRY. In Python you open it with Registry(session=session, database_name="ML", schema_name="REGISTRY"), then add models by calling log_model. That call serializes the Python model object and creates a Snowflake model object from it. The first call for a given model_name creates the model. Each later call with the same name and a new version_name adds a version. The name and version together must be unique in the schema. If you leave out version_name, Snowflake generates a human-readable one.

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)

You can add metadata after logging too. mv.set_metric("accuracy", 0.769) in Python, or ALTER MODEL … MODIFY VERSION … SET METADATA in SQL, stores metrics on the version. Those values then appear in INFORMATION_SCHEMA.MODEL_VERSIONS, where you can rank every version by accuracy. Tags are different: they belong to the model, not the version, so you can only set them after the first version exists. Aliases are another kind of metadata. An alias is a user-defined label, such as production, that you attach to one version with ALTER MODEL … VERSION … SET ALIAS. It can be used wherever a version name is accepted, and it can be moved to a different version later because it is not part of the version's code. Page 2 covers aliases in detail. You declare dependencies with the arguments below.

Registration has hard limits. The registry's limits table says a model can hold at most 1000 versions, yet the same page also says a model can have unlimited versions. The sources do not reconcile these two statements, so for planning treat 1000 as the documented limit and check the current docs before relying on either number. Each version allows at most 10 methods, 500 arguments per method, 100 KB of metadata including metrics, and 15 GB of total size for warehouse-deployed models. Its config files, including the conda.yml that log_model generates, can total at most 250 KB. A nightly retraining job that logs a new version every run could reach the documented version cap unless it also removes old versions.

Sources123

2.Custom models, pickle files and extracting artifacts

If a model type has no built-in support, you wrap it in a subclass of custom_model.CustomModel. Its artifacts go in a custom_model.ModelContext, which takes keyword arguments. Each value is either an in-memory object of a supported model type or a string path to a file, such as a pickle, a JSON config or a parameter file. Files and serialized models are packaged with the version. If you pass a supported model object, such as an XGBoost model, Snowflake serializes it for you. Files you load yourself in __init__.

model_context = custom_model.ModelContext(
    my_file_path='/path/to/file.pkl',
)

# Define a custom model class that loads the pickled object
class ExampleBringYourOwnModel(custom_model.CustomModel):
    def __init__(self, context: custom_model.ModelContext) -> None:
        super().__init__(context)

        # Use 'my_file_path' key from the context to load the pickled object
        with open(self.context['my_file_path'], 'rb') as f:
            self.obj = pickle.load(f)

Inside the class, always read models through self.context[...]. If you assign an in-memory model straight to an attribute, the closure captures a second copy and the serialized artifact gets much larger. You add helper modules with code_paths. A plain string path copies a file or directory, and its last component becomes the import name. A CodePath(root, filter=...) object includes only part of a directory tree, for example so tests are left out. A separate argument, ext_modules, lists external modules to pickle with the model.

mv = reg.log_model(
    my_model,
    model_name="my_model",
    version_name="v1",
     ? =["src/mymodule"],  # import with: import mymodule
)

Artifacts can also come back out of the registry. mv.export("~/mymodel/") writes a version's files to a local directory and creates the directory if it is missing. Access to artifacts depends on privilege, and the docs word it in two ways. The model-management page says OWNERSHIP includes accessing artifacts, and that READ allows model files and metadata. The registry overview page says you can view or download the artifacts of models you own, and that ownership is required. The Snowsight Files tab, which lists a version's underlying artifacts, is available with either OWNERSHIP or READ. OWNERSHIP is the one privilege every page agrees gives artifact access. A role with only USAGE can run warehouse inference but cannot see code, weights or other artifacts.

Sources4135

3.Validating artifact integrity before and during registration

The registry has several integrity gates. First, the model object passed to log_model must be serializable, which the docs call "pickleable". Second, every model except Snowpark ML models, MLFlow models and Hugging Face pipelines needs either sample_input_data or explicit signatures. These define the feature names and types used to validate input. Third, target_platforms checks whether the model can run where you say it will. If WAREHOUSE is listed and dependencies, GPU needs or size make the model unrunnable there, log_model() fails instead of registering a broken version. Finally, a version cannot be modified after logging, so the artifact you validated is the artifact that gets served.

You can also check artifacts after registration, for example before copying them to another environment. LIST 'snow://model/my_model/versions/V3/'; returns each artifact with its size and an md5 column. You can record those values at registration time and compare them with a later listing or with the files you retrieve with GET. The docs show the md5 column but do not describe a built-in verification procedure, so the comparison is a practice you apply yourself. The docs also note that artifact names and organization vary by model type and might change. Treat code that a model brings with it as a trust decision. When you import a model through Snowsight, the Trust remote code option lets the model download arbitrary code, which the docs call a security risk. Only allow it for models you have thoroughly evaluated and trust.

The PyCaret walkthrough shows the full sequence for a custom model. Test it locally, infer a signature from the test input and output, log it with pinned dependencies and relax_version turned off, confirm it is there with show_models(), then call run. The custom methods must also handle multi-row DataFrames. Server-side batching can combine single-record requests into one frame.

custom_mv = snowml_registry.log_model(
    my_pycaret_model,
    model_name="my_pycaret_best_model",
    version_name="version_1",
    conda_dependencies=["pycaret==3.0.2", "scipy==1.11.4", "joblib==1.2.0"],
    options={"relax_version": False},
    signatures={"predict": predict_signature},
    comment = 'My PyCaret classification experiment using the CustomModel API'
)

Compatibility across environments is the other half of validation. A model loaded with mv.load() works properly only when the target Python environment, meaning the interpreter version and every library version, is identical to the one it was logged from. Passing force=True to the load call loads it even when the environment differs, so use it knowingly, because it skips that protection. To make a dev, test or prod environment match the one hosting the model, download the version's conda.yml from the registry and build a conda environment from it. At logging time, python_version and resource_constraint (for example an architecture such as x86) fix the runtime, and target_platforms fails the log if the model cannot run in a warehouse. Check these before promoting a version to another environment.

session.file.get("snow://model/<modelName>/versions/<versionName>/runtimes/python_runtime/env/conda.yml", "~/")

Sources154

4.Rolling back a version when performance degrades

Because a version never changes after logging, rolling back means pointing production at an older version, not editing the new one. Keep previous production versions so there is something to return to. How you roll back depends on how you promoted. With the default-version scheme, set the default back to the earlier version, and callers of my_model!predict(...) pick it up with no code change. With the alias scheme, unset the alias on the bad version and set it on the earlier one, since an alias can sit on only one version at a time. Callers that use MODEL(my_model, production) follow the alias. Do not drop the bad version first. The default version cannot be dropped, so change the default before you drop anything. Set a policy for how many old versions to keep and for how long.

ALTER MODEL prod_db.prod_schema.prod_model SET DEFAULT_VERSION = V1;

Sources362

Exam traps

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

1. 1.Pinning ==x.y.z in conda_dependencies guarantees that exact version is deployed.Why is that wrong?

   relax_version defaults to True and loosens the pins. Pass options={"relax_version": False} to keep exact versions.

   Covered in Validating artifact integrity before and during registration

2. 2.In a CustomModel, storing the in-memory model on self is equivalent to reading it from the context.Why is that wrong?

   Direct assignment captures a second copy in a closure and inflates the serialized artifact. Always use self.context[key].

   Covered in Custom models, pickle files and extracting artifacts

3. 3.To roll back a bad default version, drop it first and the previous version takes over.Why is that wrong?

   The default version cannot be dropped. Set the default to the earlier version first, then drop the unneeded one if you want.

   Covered in Rolling back a version when performance degrades