SnowPro Specialty: Gen AI Question 39
Single answerDifferent ways of bringing your own models into Snowflake (for example, from Hugging Face)A retail company has fine-tuned a Hugging Face sentiment model and wants its Snowflake data science team to use the model directly inside Snowflake for batch scoring of customer reviews stored in a table. The team wants to avoid moving data out of Snowflake, and they need a supported approach for bringing their own model into Snowflake for inference. Which approach should they use?
- A
Package the model artifacts with code in a Snowpark ML model object and run inference in Snowflake using the model registry workflow.
- B
Upload the Hugging Face model to an internal stage and call it directly from SQL as if staged files are executable models.
- C
Convert the model to a file in a Snowflake stage and register it automatically as a Cortex model so it appears in AI_COMPLETE.
- D
Create an external function that sends each review to a Hugging Face endpoint, because Snowflake does not support bringing customer-trained models into Snowflake for in-platform inference.
Show answer and explanation
Correct answer: A
Explanation
For BYOM in Snowflake, the key distinction is between storing model files and operationalizing them for inference. Snowflake supports model lifecycle workflows through Snowpark ML, including registering models and running inference inside Snowflake, which is the best fit when teams want to score Snowflake-resident data without exporting it. Hugging Face models are commonly used in this pattern when wrapped in supported Python code and dependencies. By contrast, stages only store artifacts, not serve them automatically; Cortex SQL functions do not auto-register arbitrary customer models; and external functions are an integration pattern for remote inference, not the primary answer when the requirement is to run the customer model directly in Snowflake. Candidates should recognize the practical tradeoff: use Snowpark ML/model registry for in-Snowflake inference, and use external endpoints only when the model must remain hosted outside Snowflake.
- A. Correct.
Correct. Snowflake supports bringing your own models into Snowflake through Snowpark ML model registry patterns, where model artifacts and inference code can be packaged and registered for execution in Snowflake. This is the appropriate approach when the goal is to keep data in Snowflake and run batch inference close to the data. It aligns with practical BYOM scenarios, including models originating from frameworks and ecosystems such as Hugging Face, as long as the model can be packaged in a supported Python-based workflow.
- B. Incorrect.
Incorrect. A stage is storage, not a model serving mechanism by itself. Simply uploading model files to an internal stage does not make them executable from SQL. The model still needs to be loaded and invoked through supported runtime mechanisms such as Snowpark Python and model registry or related inference workflows.
- C. Incorrect.
Incorrect. Cortex functions such as AI_COMPLETE expose Snowflake-managed models and supported integrations, but uploading an arbitrary model file to a stage does not transform it into a Cortex model. This distractor reflects a common misconception that all models in Snowflake can be surfaced through Cortex SQL functions automatically.
- D. Incorrect.
Incorrect. External functions can be used to call external services, and that may be valid in some architectures, but the statement that Snowflake does not support customer-trained models for in-platform inference is false. For a requirement to avoid moving data out of Snowflake and use a supported in-platform BYOM pattern, packaging and registering the model for execution in Snowflake is the better answer.