SnowPro Specialty: Gen AI Question 43
Single answerUsing Snowflake Model Registry (custom model)A data science team has trained a custom text-classification model outside Snowflake and wants to operationalize it in Snowflake for governed batch inference. They need to version the model, store metadata, and allow other teams to invoke the model consistently without manually managing serialized files in stages. Which approach best meets these requirements using Snowflake Model Registry?
- A
Register the custom model in Snowflake Model Registry, log a new model version with its artifacts and metadata, and use the registry version for inference and lifecycle management.
- B
Upload the model file to an internal stage and have consumers download the file and run predictions locally, because Model Registry is only for Snowflake-provided models.
- C
Store the model weights in a Snowflake table and expose them through a SQL view, because Model Registry does not support versioning for custom models.
- D
Create a Cortex AISQL function for the custom model directly, because all custom models must be deployed through Cortex functions rather than the registry.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake Model Registry to register the custom model and log model versions with associated metadata and artifacts. This aligns with the scenario's requirements: governed operationalization, versioning, metadata tracking, and consistent reuse by downstream teams. Using a stage alone only stores files and leaves versioning and governance to manual processes. Storing weights in tables or views is not how Snowflake manages model assets. Cortex functions are for Snowflake AI capabilities and do not replace the registry for custom model management. In Snowflake best practices, Model Registry is used to manage the lifecycle of ML models, including custom models, with versioned entries and metadata for reproducibility and controlled deployment.
- A. Correct.
Correct. Snowflake Model Registry is designed to manage models, including custom models, with versioning, metadata, and governed lifecycle operations. Registering the model and logging versions allows teams to track changes, attach relevant metadata, and invoke a consistent model version for inference workflows. This is the practical, managed approach compared with ad hoc file handling.
- B. Incorrect.
Incorrect. While storing model files in an internal stage is possible as raw storage, it does not provide the governance, discoverability, model version tracking, and registry-based lifecycle management required in the scenario. The statement that Model Registry is only for Snowflake-provided models is also false; it supports custom models.
- C. Incorrect.
Incorrect. A table or view is not a model management solution. Although metadata about a model could be stored in tables, this does not turn the model into a managed, versioned asset for inference. The claim that Model Registry does not support versioning for custom models is a common misconception and is incorrect.
- D. Incorrect.
Incorrect. Cortex AISQL functions provide access to supported foundation-model capabilities and related AI features, but they are not the required mechanism for registering and governing a team's custom trained model. Custom model lifecycle management is addressed by Snowflake Model Registry, not by forcing all models into Cortex functions.