SnowPro Specialty: Gen AI Question 198
Single answerUsing Snowpark Container ServicesA data science team wants to deploy an open-source embedding model inside Snowflake so that sensitive documents never leave the Snowflake security boundary. The application must support bursty internal traffic from several downstream apps, and the team wants to expose the model through an HTTP endpoint that those apps can call. They also want Snowflake to manage scaling of the service instances based on demand. Which approach best meets these requirements?
- A
Package the model in a container image, deploy it as a service in Snowpark Container Services, and expose it through an endpoint managed by Snowflake.
- B
Create a Python UDF that downloads the model from the internet at runtime and serves requests directly over HTTP from the UDF.
- C
Use an external function to call a model server running outside Snowflake, because Snowpark Container Services cannot host model inference workloads.
- D
Store the model files in an internal stage and query them directly with SQL, because staged files automatically scale for concurrent inference requests.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowpark Container Services to run the model as a containerized inference service within Snowflake. This is the practical pattern when an organization needs to keep data and inference inside Snowflake while exposing an application endpoint for internal consumers. Snowpark Container Services supports deploying containerized applications, including GenAI and ML inference services, and is the appropriate choice when the workload needs a persistent service endpoint and managed scaling behavior. By contrast, UDFs and stored procedures are execution constructs rather than HTTP-serving infrastructure, and external functions intentionally route requests to systems outside Snowflake. Snowflake documentation for Snowpark Container Services describes running containerized applications and services in Snowflake, including endpoint exposure and scaling-oriented service deployment patterns.
- A. Correct.
Correct. Snowpark Container Services is designed for running containerized workloads inside Snowflake, including model inference services. A team can package an embedding model and its serving stack into a container image, run it as a service, and expose it through a Snowflake-managed endpoint. This approach keeps inference inside Snowflake's security boundary and supports scaling behavior appropriate for service-based workloads.
- B. Incorrect.
Incorrect. Python UDFs can execute Python logic in Snowflake, but they are not designed to act as long-running HTTP servers. They also should not rely on downloading model artifacts from the public internet at runtime for a production inference pattern. This option confuses batch/function execution with persistent containerized service hosting.
- C. Incorrect.
Incorrect. External functions are useful when Snowflake needs to call services outside Snowflake, but this scenario explicitly requires that sensitive documents remain inside the Snowflake boundary. The statement that Snowpark Container Services cannot host model inference workloads is false; hosting inference is a primary fit for the feature.
- D. Incorrect.
Incorrect. Internal stages are for storing files, not for serving model inference requests directly. Querying staged files with SQL does not create an HTTP inference endpoint or autoscaling model-serving application. This option reflects a misconception that storage primitives alone can replace a serving layer.