SnowPro Specialty: Gen AI Question 40
Single answerDifferent ways of bringing your own models into Snowflake (for example, from Hugging Face)A data science team has selected a sentence-transformer model from Hugging Face to generate embeddings for customer support articles. They want to run the model inside Snowflake so embeddings can be generated close to the data, without calling an external API. The model is not available as a built-in Snowflake model. Which approach should they use?
- A
Package the model artifacts and inference code, stage them in Snowflake, and run inference through a Python UDF or Snowpark-based workflow in Snowflake.
- B
Register the Hugging Face model name directly in Cortex AI_COMPLETE so Snowflake automatically downloads and hosts it for in-database inference.
- C
Create an external function that points to the Hugging Face model card URL so Snowflake can execute the model remotely without additional infrastructure.
- D
Load the model into a SQL stored procedure because SQL procedures can natively import and execute PyTorch transformer models.
Show answer and explanation
Correct answer: A
Explanation
The key requirement is to bring a non-built-in model into Snowflake and run it close to the data without using an external API. In Snowflake, this is typically done by using Snowpark Python or Python UDFs, together with staged model artifacts and inference code. This pattern supports BYOM scenarios when the model is not exposed as a Snowflake-managed model. By contrast, Cortex functions such as AI_COMPLETE are for supported managed models rather than arbitrary Hugging Face model registration. External functions are useful when inference is intentionally delegated to a service outside Snowflake, but that does not satisfy the requirement to run inside Snowflake. Best-practice references include Snowflake documentation on Snowpark Python, Python UDFs, importing files from stages, and Cortex model availability and usage boundaries.
- A. Correct.
Correct. When bringing your own model into Snowflake for in-platform inference, a practical pattern is to package the model and supporting code, place the artifacts in a stage, and execute inference with Python-based Snowflake capabilities such as Python UDFs or Snowpark Python. This aligns with Snowflake's support for running Python code in Snowflake and importing files from stages. It is the best fit when the model is not one of Snowflake's built-in managed models and the goal is to avoid external API calls.
- B. Incorrect.
Incorrect. Cortex AI_COMPLETE does not let users register an arbitrary Hugging Face model name and have Snowflake automatically fetch, host, and serve that custom model. AI_COMPLETE is for invoking supported managed models exposed by Snowflake. A common misconception is to assume all Hugging Face models can be dynamically attached to Cortex in the same way.
- C. Incorrect.
Incorrect. External functions require external infrastructure, such as an API endpoint behind API Gateway or a similar service, and do not execute a model simply by referencing a Hugging Face URL or model card. This option also violates the scenario requirement to run inference inside Snowflake rather than through an external API path.
- D. Incorrect.
Incorrect. SQL stored procedures are not the mechanism for natively importing and executing PyTorch transformer models. Model inference for Python ML libraries typically relies on Python execution environments, not pure SQL procedure logic. Someone might choose this option because stored procedures run in Snowflake, but SQL procedures do not directly provide native transformer model execution.